@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 любым старым способом. Бывают моменты, когда мне очень хочется выследить Брендана Эйха и выкинуть его в мусор. Затем помогите ему подняться, пожмите ему руку и обнимите за то, что он НЕ пошел по схеме. Это любовь/ненависть.
