Помогите выровнять различный текст с помощью CSS

Я не могу понять, как создать одну строку текста, чтобы она выглядела так:
Список цен: $49.99

У меня тоже есть два разных элемента, которые выглядят так, как мне нужно, но я не могу понять/не вспомнить, как их выровнять по горизонтали.

То, что у меня есть в html, пока выглядит так:

Список цен:

$99.99

И мой CSS выглядит так:

.pricingInfo {

плыть налево;

}

#список цен {

отступ-верх: 1em;

начертание шрифта: жирный;

}

#listPriceAmt { отступ: 1em 0 1em 1em; оформление текста: сквозное; } Я знаю, что проблема во мне, и исправить ее очень просто, поэтому буду признателен за небольшой совет. Спасибо . . .

Хорошо.
ли > б просто означает, что правило влияет только б которые являются прямыми потомками ли. Это означает, что это:

 
<li><span><b>something else</b></span></li>

Код (разметка): на него влияет правило, а это:

  <li><b>something</b></li> 

Код (разметка): нет, так как есть охватывать между ли и б. Для Ли Дел, Ли Спэн правило, оно работает только с обоими селекторами - оба ли дель и Ли Спан. Запятая просто разделяет разные селекторы с одинаковым внешним видом. Если вам нужна помощь еще в чем-то, не бойтесь спрашивать. (О, и <дел> это просто элемент, который обычно отображается в визуальных браузерах как сквозной).

Спасибо, PoPSiCLe . . . Ваше решение работает отлично.

Я не могу понять, как именно это работает, но это работает.

Сначала я думал, что список может сработать, но потом я подумал, что если я пойду этим путем, то это будет неправильный путь, поэтому я не пошел по этому маршруту.



Имея в виду, что я, очевидно, ничего не знаю о CSS (я думал, что разбираюсь в этом, но когда я сталкиваюсь с проблемой, и вы, ребята, мне помогаете, это создает гораздо больше вопросов), поэтому вам придется объяснить, как для меня это работает - особенно li > b и li del, li span - это для меня совершенно новое.

Еще раз спасибо . . .

Господа.

. . большое спасибо за ваш вклад, советы и предложения.

Я до сих пор поражаюсь тому, как много разных способов и мнений существует для того, чтобы что-то сделать.

Теперь мне еще больше хотелось бы, чтобы все могли собраться вместе и принять один стандартизированный способ работы с HTML, CSS, PHP и всем остальным.

Но опять же, если бы они это сделали, чтение наверняка было бы скучным.

РЖУ НЕ МОГУ

Я не уверен насчет 340 пикселей.

Итак, мой первый вопрос: на правильном ли я пути?

Следующий вопрос: если я на правильном пути, существуют ли стандартные максимальные ширины, с которыми мне следует работать, кроме приведенных выше?

И, наконец, если у вас есть какие-либо предложения по улучшению чего-либо из этого, поделитесь со мной.

Большое спасибо за помощь.

. .

Вы пробовали что-то простое, как

 
<p class="list-price"><span>List Price:</span> $49.99</p>

.list-price span {

font-weight: bold;}

Код (разметка): Вы не сообщаете нам структуру контекста. Другой элемент-контейнер может быть более подходящим, но концепция будет той же. ваше здоровье, Гэри

Я продолжаю вам говорить.

. . чем больше я пытаюсь учиться, тем меньше я знаю, лол, и я ценю терпение, отвечая на все мои глупые вопросы. В любом случае, если быть совершенно честным, я не знаю, как лучше всего выстроиться в очередь на этом сайте, когда экран сужается.

Какие-либо предложения? Изначально я думал, что хочу, чтобы на странице отображалось изображение, затем #productinfo под ним, затем #purchaseInfo под ним, но опять же, я понятия не имею, как лучше всего представить это пользователям.

. Кстати, я начал использовать CamelCase в результате взаимодействия с Deathshadow.

Он высказал хорошее мнение (на мой взгляд) по поводу его использования, поэтому я применил его к своему кодированию.

Попытка изучить все эти вещи очень расстраивает из-за множества разных подходов и мнений о том, как это следует делать, чтобы делать это правильно.

Судя по тому, что я читал по этому поводу, мнения кажутся 50 на 50. Жаль, что кто-то не может выбрать стандартизированный способ сделать все это, и все делают это либо так, либо иначе.

Но в любом случае, еще раз спасибо за ваш вклад и мнения, и я с нетерпением жду, когда у вас появится немного свободного времени, чтобы рассказать мне, что я делаю неправильно или не понимаю, что такое медиа-запросы и как сделать страницу отзывчивой.

это список...

 
li {

list-style-type: none;

max-width: 20em;

margin-bottom: 1em;
}
li .price {

color: #D49353;
}
li > b {

width: 5em;

display: inline-block;
}
li del, li span {

text-align: left;

display: inline-block;

margin-left: 2em;
}

Код (разметка): CSS:

  <ul> <li><b>List Price:</b> <del>$99.99</del></li> <li><b>Your Price:</b> <span><b class="price">$49.99</b> with Free shipping</span></li> <li><b>You Save:</b> <span class="price">$50.00</span></li> </ul> 

Код (разметка): ДжсФиддл: https://jsfiddle.net/mjfoat7t/

@kk5st -- Гэри, правда? Что делает этот грамматический абзац? Следующее, что вы знаете, вы будете без веской причины добавлять одиночные теги изображений в . @PoPSiCLe - тем более то, что делает эти названия именами собственными или юридическими лицами.

Это просто текст, который там есть.

Даже если бы они были представлены жирным шрифтом, я бы не стал использовать вокруг них тег B. с этой же целью цена не является именем собственным или юридическим лицом (например, корпорация, ответчик по судебному делу или БРАЙАН БЛАССЕД -- хотя последний раз семантически единственный раз, когда я бы использовал одновременно B, STRONG и BIG), хотя, если это ПРЕДЛОЖЕННАЯ цена, не хотелось бы, ох, я не знаю... сделать что-то вроде... БОЛЬШЕ АКЦЕПТА? Он же <сильный>. Хотя я согласен, это похоже на список информации, поэтому UL — хороший выбор.

Аналогично, DEL совершенно прав.

и я бы, наверное, подчеркнул экономию. Я бы также провел класс по UL, так как маловероятно, что вы захотите охватить с помощью этого все UL и LI, которые Джо взорвал на странице.

 
.prices {
list-style:none;
max-width:20em;
}

.prices li {
padding-bottom:1em;
}

.prices strong,
.prices em {
color:#D49253;
font-style:normal;
}

.prices span {
display:inline-block;
width:5em;
text-align:right;
font-weight:bold;
}

Код (разметка): НЕ доволен диапазоном, но фиксированной шириной для выравнивания по правому краю:/

Я бы подумал о том, чтобы обернуть всю строку в STRONG, DEL и EM и использовать диапазон для отмены этих значений, поскольку с точки зрения грамматики/синтаксиса это может иметь больше смысла, но стилизация будет сложнее.

Я бы, вероятно, увеличил ширину UL, а не LI, поскольку IE8 время от времени этим занимается, использовал бы отступы вместо полей, поскольку нет мешающего стиля, и избегаю головной боли, связанной с схлопыванием полей, из-за поднятия своей уродливой морды,

  <ul class="prices"> <li><span>List Price:</span> <del>$99.99</del></li> <li><span>Your Price:</span> <strong>$49.99</strong> with FREE shipping</li> <li><span>You Save:</span> <em>$50.00</em></li> </ul> 

Код (разметка): Что касается полного кода страницы, черт возьми, это выглядит знакомо, но...



Как может быть H3 без предшествующего H2? Поскольку большая часть страницы будет статичной, почему вы так разбиваете включения? У вас есть очень хороший #footer, чтобы сказать ясно:оба на гораздо менее хорошем контентеWrapper, который вы могли бы установить переполнение:скрыто, для чего, черт возьми, там этот раздел ясно-оба? Это не 2003 год.

Что касается медиа-запросов, как уже упоминалось, вы просто используете их, чтобы, когда макет сломается из-за ширины, вы переупорядочили макет по размеру.

Вот и все, чем на самом деле является «адаптивный» макет, — это внесение корректировок для добавления/удаления необычных элементов представления и более эффективного использования доступного пространства экрана.

Это может повлечь за собой удаление столбцов, сокрытие презентационных изображений, разрешение масштабирования изображений контента до максимальной ширины и множество других изменений.

Все, что вам нужно помнить, это то, что любой код внутри запроса применяется только тогда, когда условие истинно, перегружая любые значения, которые вы установили перед ними в коде.

Это не ракетостроение, хотя нужно немного привыкнуть к идее перегрузки существующей декларации. У меня прямо противоположное мнение.

но вы знаете, что говорят о мнениях. Для меня дефисы - это неразборчивая чушь без пробелов вокруг них.

(признаюсь, я псих, который говорит то же самое о неразборчивом кислотном трипе, то есть цветовой подсветке синтаксиса); и это не значит, что мы здесь вычитаем значения.

Символы подчеркивания более разборчивы, но я предпочитаю использовать их в качестве разделителей для префиксов, а не для замены пробелов. ... и на самом деле я ПРЕДПОЧИТАЮ CamelCase по другой причине: согласованность с соглашением об именах, которое я использую в PHP и JavaScript.

То, что каждый проклятый Джо язык, который мы используем, имеет РАЗЛИЧНЫЙ подход к именованию, ЧЕРТ раздражает; поэтому я выбрал один и использую его для всего.

и это означает, что CamelCase для обычных вещей, prefix_camelCase для связанных вещей и CamelCase для классов объектов. Хотя в JS мало различий между классом и экземпляром, это может сбить с толку.

но именно это и дает вам свободное приведение типов и встраивание объектов в синтаксис C любым старым способом.

Бывают моменты, когда мне очень хочется выследить Брендана Эйха и выкинуть его в мусор.

Затем помогите ему подняться, пожмите ему руку и обнимите за то, что он НЕ пошел по схеме.

Это любовь/ненависть.

Привет, Гэри, Спасибо за вклад, но я испортил свой исходный пост.

Я забыл добавить, что у меня есть строка через прейскурантную цену.

Вот почему в моем коде выше он оформлен одним способом для «Прейскурантной цены:» и другим способом для $99,99 — где я собираюсь оформить его для сквозной линии. Думаю, именно с этой частью у меня проблемы. Я пытаюсь, чтобы это выглядело так: Еще раз спасибо . . .

Мне просто не нравится CamelCase.

Не знаю, почему, правда, у меня это не работает.

Обычно я трачу немного больше времени на чтение длинного имени в верблюжьем регистре, чем на то же имя с подчеркиванием.



Я использую в основном подчеркивания для любого языка, хотя в JS я по какой-то причине склонен назначать переменные с помощью CamelCase (в основном для того, чтобы было легче различать пост-переменные, отправляемые через AJAX, где я обычно называю имя пост-переменной и переменная содержимого — то же самое, только сообщение написано простыми строчными буквами (с подчеркиванием, если необходимо), а содержимое — верблюжьим регистром, чтобы его было легче читать.

Ну... в принципе, Скрытая информация :: Авторизуйтесь для просмотра »
-queries не для изготовление страницы отзывчивы, но для корректировка поток и стиль, поэтому он динамически подходит для экранов с разными разрешениями и размерами.

Может показаться, что разница не такая уж большая, но было бы хорошо, если бы это было ясно.

Поскольку сейчас у меня нет времени просмотреть код, я не смогу с ним помочь прямо сейчас, но я посмотрю позже, когда у меня будет время.

Насколько я понимаю, вы хотите, чтобы два элемента #productInfo и #purchaseInfo находились ниже друг друга, когда экран становится уже? А они нет?



Кстати, следует избегать использования CamelCase для идентификаторов и классов (и других элементов в HTML). Во всяком случае, это совершенно правильно, но хорошее эмпирическое правило — использовать подчеркивание или дефисы для облегчения чтения HTML (хорошее правило — основывать его на XHTML, где верблюжий регистр вообще не разрешен). Однако использование CamelCase в JavaScript вполне допустимо.

Ничего. Это структурный абзац, который правильно используется в языке структурной разметки.

Если вы заботитесь о грамматических определениях, как вы отмечаете другие грамматические сущности? Предложения разных типов? Наречия и прилагательные? А как насчет предложений внутри абзаца? Или абзац — единственный случай, когда настаивают на грамматической разметке?

Я не могу понять, почему вы настаиваете на использовании исключительно грамматического определения и умышленно игнорируете структурное определение абзаца.

на языке структурной разметки. Что касается изображений, они представляют собой встроенные заменяемые элементы и в конечном итоге превращаются в текст.

То же самое относится и к элементу объекта.

Элемент P является текстовым контейнером самого низкого порядка и подходит, если только не используется более конкретный элемент контейнера, например.

Хх, применимо. Гэри