SelenIT

Не согласен, масштабирование фона — не баг, а фича, без него будет совсем не так, как-то «куце». Другое дело, что выбор gif-формата для картинки с кучей градиентов — как-то действительно не комильфо. Я бы попробовал jpeg.

Самозакрытие тегов работает только в XML. В данном случае им не пахнет. P.S. Что-то у меня вообще страничка грузиться перестала

Страница отдается с типом контента text/html, т.е. разбираться браузерами будет по HTML-правилам (новыми браузерами — по HTML5-правилам). В этом режиме от XHTML-доктайпа нет никаких выгод, а вот ограничения Strict-версии (если всё-таки стремиться к валидности) сильно осложняют жизнь. Поэтому реалистичный валидатор (см. ссылку в прошлом посте) подчеркивает этот доктайп как устаревший.

Ну почему грубейшей? Формально-то всё валидненько . Другой вопрос — к чему там столько <pre>: вроде, ни примерами кода, ни ASCII-артом там особо не пахнет...

Немножко дополню wildhind: не совсем пробел, а отступ базовой линии шрифта (нужный для размещения нижних выносных элементов — свисающих вниз «хвостиков» букв), по которой по умолчанию (vertical-align:baseline) выравнивается нижний край картинки. Кроме смены display, это можно убрать заданием vertical-align:top/bottom. Еще эта особенность не проявляется при Transitional-доктайпах, в «почти стандартном» режиме браузеров. Но этим не стоит злоупотреблять, т.к. в этом режиме возможны непредвиденности с инлайн-блоками и т.п.

Придумался вариант без лишнего запроса. Правда, webkit-only. Опера всегда покажет низкое разрешение (возможно, придется подстраховать селектор — -webkit-min-device-pixel-ratio мобильная Опера вроде уже понимает), что лучше чем ничего, но вот мозилловые покажут лишь альт-текст, что хуже (но для мобильной верстки, где доля мозилловых мала — имхо, в ряде случаев сойдет). А вот применение их к картинке, подгружаемой через content — не очень. Та же Опера, например, этого не делает. Да и картинки в псевдоэлементах на указание размеров не реагируют (что логично, ведь их в одном псевдике может быть много разных). Так что добрая воля вебкитов на поверку смахивает на баг, который, возможно, когда-нибудь исправят. Но идея подхода мне самому очень и очень нравится!

Вроде работает, но есть пара нюансов: 1) версия из src картинки всё равно грузится — она, конечно, мелочь по сравнению с хайрезом, но лишний запрос не радует, и 2) картинка автоматом масштабируется лишь при указанных width/height, иначе она оказывается вдвое больше (т.к. CSS оперирует CSS-пикселами, а не экранными)...

Всё равно проверьте гипотезу про BOM. Возможность сохранить в UTF-8 без BOM в дримвивере тоже есть.

Интересное кино. Постараюсь поизучать тему на досуге (если доживу до этого досуга). До сих пор верил в масштабный коэффициент "двойка", а оказывается, и тут надо доверять, но проверять...

Это по умолчанию так? В <meta viewport> еще никакая магия не закралась? Меня тоже эта его фича лишь радует. Блоки выстраиваются так, как задумал дизайнер, а текст — так, как удобно читать. Согласен с PPK, что хорошо бы всем это перенять)

Можно об этом чуть поподробнее? Я был уверен, что вьюпорт как был, так и остался 1024px (в альбомном положении), только сами пиксели стали счетверенными. Это не так и это не связано со шрифтами? Это про древнеандроидный браузер "Браузер", который упихивает все тексты в умещающуюся на экран колонку?

А сохраняете, случаем, не в UTF-8 в Блокноте? Он любит вставлять BOM-метку (три байта). Если это она, попробуйте открыть файл нормальным редактором (напр. Notepad++) и сохранить в виде UTF-8 без BOM (там обязана быть такая опция).

Например, запоминать последний открытый блок в переменной. При открытии любого другого блока старый (из переменной) закрывать. P.S. js — это и есть сокращение для Javascript. Может, имелся в виду jquery?

Ну почти как буква . Слова с дефисами большинство браузеров ведь тоже переносит, но не растягивает justify-ем. Здесь аналогично. Теоретически CSS позволяет растягивать и сами слова, за счет расстояний между буквами. Но работает это, как ни странно, только в IE (с нестандартным значением text-justify:newspaper).

wwt, так li-шки одного уровня вложенности стилизуются одинаково, независимо от того, есть ли ul в них или нет. А топикстартеру нужно различить эти случаи.

Inline-block считается за одну букву в слове.

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

Хм, надо будет тоже осилить как-нибудь (при всей моей непереносимости к неразвлекательным видео длиннее 3 минут). Из презентации я "объяснений на пальцах" не заметил (много рекламы про то, как короткий доктайп классно действует и ничему не мешает, но толком непонятно, чем так уж плохи старые, кроме "многобуквенности"). Вот объяснение, что старые доктайпы в реальности (кроме редких лабораторных примеров) тупо не работают вообще — это уже что-то

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

Разметка — это инструмент для решения задачи. И коловорот (HTML3.2), и дрель (HTML4), и сверлильный станок (XHTML1.x), и перфоратор (HTML5) — инструменты для сверления отверстий (разметки веб-страниц). Но одно дело — сверлить в железном листе, другое — в бетонной стене. И согласитесь, что делать последнее сверлильным станком (держа его на весу положенным на бок и как-то избавившись от мешающей станины) несколько, гм... неудобно

Ну так делайте. По тому типу документа, который допускает <script> без многословных атрибутов и <input> без непременных блочных оберток и бессмысленных (в реальности) концевых слешей. Зачем... играть в шахматы непременно стоя в гамаке с аквалангом? 100%-я валидность должна естественным образом вытекать из логичности кода, а не требовать бессмысленных жертв, как туземный идол.

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

А зачем вам доктайп XHTML 1.0 Strict, если вы явно не собираетесь отдавать страницу с XML-ным типом контента, а Strict-ограничения вам лишь мешают? Почему не взять что-то более реалистичное?

Мда, Хром всё больше и больше напоминает старые IE... Разумных объяснений происходящему по-прежнему не вижу.

Отступ имеется в виду снизу, под кнопкой (в Хроме есть, в FF нет)? Методом тыка замечено, что он исчезает, если убрать float у .btn. Логику пока сам не постиг, сильно смахивает на баг...