SelenIT

Для меня ответ был совершенно не очевиден . Да, у каждого пункта — своя картинка. Но это явно не конкретные блюда, а скорее подразделы сайта (типы блюд), картинки явно старательно подобраны дизайнером, адаптированы под общую тему оформления и явно не предназначены для вставки с бухты-барахты секретаршей. А если ресторан настолько серьезный, что это меню будет меняться регулярно и новые пункты будет добавлять, скажем, директор , то им вполне по силам заплатить программистам, чтобы сделать для этого меню отдельную админку, с автоматической обрезкой картинки, подгонкой ее гаммы и т.п. — которая будет генерировать на выходе тот HTML+CSS, который удобнее пользователям и поисковикам, строгий и лаконичный. А в наш век адаптивности всего и вся для отображения этого же меню на мобильнике, например, явно будет удобнее обнулить фон, чем грузить десятки картинок с display: none...

Указать на вывеске, что блюдо приготовлено из 100%-органических продуктов с фермы тётушки Франни, и реально пустить клиента на кухню и дать ему увидеть процесс — две очень большие разницы . На вывеске можно написать что угодно (под личиной Апача с ПХП запросто может скрываться IIS с чем попало, а некоторые сервера по приколу говорят о себе, что работают на Спектрумах), и клиенту (обычному, HTTP-шному) никак не узнать, обманывают ли его.

До кучи: http://kizu.ru/fun/legends-and-headings/

Поисковик, как и браузер — это клиенты, то бишь посетители ресторана. Которым официант по имени Протокол Эйчтитипи выносит готовое блюдо. Из чего вы это блюдо готовите — из PHP-скриптов, JSP-сервлетов, ASP.NET-компонентов, SSI-вставок, CGI-скриптов с обработчиками хоть на ассемблере — клиенту даже знать не надо, на кухню ни в одном ресторане его просто не пустят

Добавлять пустые пункты не надо. Закругления можно поставить фоном крайних пунктов из имеющихся.

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

Один из принципов HTML5 — обратная совместимость с существующим зоопарком (изящная деградация и всё такое). Скорее, в HTML5 закрытость этих тегов не зависит от наличия в них концевого слеша.

Нет, имею в виду строчки 373-374 исходника страницы по ссылке в первом сообщении: <p style="clear: both;" class="subscribe-to-comments"> <input type="checkbox" name="subscribe" id="subscribe" value="subscribe" style="width: auto;" checked="checked" <label for="subscribe">Оповещать меня о новых комментариях на почту</label> </p> Поисковикам вообще плевать на доктайп. Единственное назначение доктайпа в HTML5 — перевести браузеры в стандартный режим отображения. Поэтому доктайпы HTML 4.x Strict и XHTML 1.x Strict, вообще-то, тоже являются валидными доктайпами HTML5 . Но зачем писать больше, если ни для кого, кроме валидатора, нет разницы?

Раздел 14.2 спецификации CSS2.1 (3-й абзац): т.е. приблизительно Но вообще высота корневого элемента не должна быть нулевой, по умолчанию она должна наследовать высоту просмотра...

Имхо — затем, что легализует, документирует и приводит к общему знаменателю (не сразу, но постепенно) многие полезности, уже давно работающие в браузерах (canvas, autocomplete, contenteditable...) и поисковиках (микроданные). Ну и слека упрощает жизнь, позволяя не зацикливаться на неважных нюансах синтаксиса (с какого конца разбивать яй как закрывать эл-т BR — > или />), а сосредоточиться на функциональности проекта.

Только зазоры под картинками могут появиться. Но это моментально лечится через img { vertical-align: bottom; } и еще кучей способов. Вообще поменять доктайп на HTML5 будет честнее, чем маяться ерундой со слешами в <img>, на которые браузерам чихать с высокой башни. Вот один <input> на приведенной странице (в форме подписки) действительно не закрыт (нет ">") и из-за этого проглотил следующий <label>, превратив его в кучу невалидных атрибутов...

Селекторы — это в CSS. В HTML5 nav — это структурный элемент (раздел документа), содержащий ссылки на другие документы или разделы.

Николя223, где была спрятана ваша анабиозная камера? Трюк с document.createElement('nav'), после которого IE8 (и даже IE6!) по волшебству начинает понимать и стилизовать этот элемент (и с остальными аналогично) известен как минимум с 2009-го. А 80% современных браузеров (FF4+, Хром 7+ и Опера 11.6+) не понимают никакого другого (X)HTML, кроме HTML5. А по сабжу — формально всё валидно, но по сути, конечно, разделители между пунктами меню, а тем более закругления, никак не тянут на самостоятельные пункты списка. Обычные фоновые картинки для них — самое место.

Зачем у h3.moduletitle и у span-а в нем стоит float? Почему бы не заменить float у второго на display: inline-block, а у первого убрать вообще? Для чего здесь "плавание"? Ну или, на крайняк, добавить .moduletitle + .content { clear:left; }... но лучше устранить причину, чем плодить костыли для борьбы со следствиями.

Иллюзия прозрачности (картинка с фрагментом фоновой текстуры, накрывающая тень) в данном случае не подойдет?

Вообще JSfiddle, имхо, не лучшая площадка для выставления целых примеров вёрстки, т.к. не дает полного контроля. Всё содержимое окна "html" запихивается в <body> (так что указывать там доктайп и <head> с содержимым бесполезно — Фидл всё равно вставит своё), "нормализация CSS" (по факту обычный ресет) делает много не всегда нужного типа table { border-collapse:collapse } и т.п. Фидл хорош для демонстрации отдельных фрагментов, принципиальных возможностей (proof-of-concept) и т.п.

У меня тупейшим алгоритмом (как в далеком детстве на бейсике) получилось так. Вот так, наверное, чуть умнее и продвинутее.

1) <input type="file"> особенный и чуть волшебный, до HTML5 он был единственным «мостиком» между двумя разными мирами — вебом и локальной файловой системой юзера, которым нельзя взаимодействовать напрямую по соображениям безопасности. Внешний вид у него тянется из традиций разных ОС. Есть куча способов заменить его чем-то однотипным (см. поиск по «стилизация input file» и т.п.), основной прием — сделать его полностью прозрачным, подложив снизу нужную картинку. 2) ПХП (и большинство других серверных языков) сами берут на себя черную работу по раскодировке.

Справедливости ради, в Firefox изобразить нечто сродни желаемого топикстартером можно. Но даже в таком специфическом случае, конечно, применять background-* нужно к тому элементу, который растягивается на всю ширину, а не к одной "плитке" его фона. Повторяющиеся квадраты можно генерировать CSS-градиентами (вдохновляющие примеры).

Это как раз верный способ отправить выравнивание фтопку, как только картинка окажется другой высоты. Наличие таблицы на vertical-align потомков ссылки не влияет. В Опере вертикальное выравнивание в строке, бывало, могло ломаться при Transitional-доктайпах, но в Firefox подобного не видал... Это нормально, инлайновое форматирование так и работает.

1) Все псевдоклассы (как и классы) дают одинаковый вклад в специфичность. Поскольку наведенная ссылка одновременно является либо посещенной, либо нет, при перечислении псевдоклассов по отдельности к ней применяется какой-то один — тот, что идет последним. Чтобы все классы применялись, рекомендуют указывать их в последовательности link/visited/hover/(focus)/active (есть специальные запоминалки, типа «LoVe/HAte» или «Lord Vader Hates Furry Animals», лично я предпочитаю свою — «Links, even Visited, Have to be Fully Accessible». 2) Судя по всему, дело в ограничениях на стилизацию посещенных ссылок ради безопасности. До его введения через них можно было «выведать», какие страницы посещал юзер (напр., дергая шпионский скрипт через background-image для них). Поэтому современные браузеры (как минимум, Хром и ФФ) разрешают менять для посещенных ссылок лишь ограниченный набор свойств, не сказывающихся на отображении других элементов: color, background-color, border-*-color, outline-color, column-rule-color, fill и stroke (подробности со ссылками на англ.).

Значит, что-то перебивает этот vertical-align. Проверьте файрбагом, что именно. Чудес не бывает, у всего есть рациональные объяснения... как правило

Раньше обнуление родительского шрифта глючило в вебкитах, оттуда у меня привычка им не доверять. Сейчас, да, работает, так что из чисто CSSных хаков для борьбы с пробелами — наименьшее зло. first-child в IE7+ работает. Насчет таблицы я думал как-то по аналогии с чикуёнковским решением (не считая тривиального, но некрасивого решения с реальным отрывом кнопок в др. строку). Признаю, поторопился (как раз вебкит подкачал, у него с таблицами вообще сложно).

Обнулять тоже не супер-айс. Лучший вариант — честно убрать пробелы из кода, остальное хаки разной степени кривизны и надежности. Но «магические» -0.43 и -0.31 — это, конечно... Ну а по теме, если блоки не должны перескакивать при изменении ширины контейнера, то, имхо, самый доступный вариант решения — CSS-таблица. Еще правильнее было бы использовать флексбоксы, но это надо смотреть на планируемую аудиторию.

Сама постановка вопроса неправильная. Верстать сайт таблицами или дивами — то же самое, что строить дом только из водопроводных труб или только из кафельной плитки В HTML больше 100 тегов, у каждого свое предназначение (table — для табличных данных, p — для абзацев текста, address — для контактной информации о странице, nav — для навигационных блоков и т.п.), в соответствии с этим предназначением их и надо использовать. А с помощью CSS можно придать любому элементу любой вид... пока, к сожалению, теоретически и с ограничениями (оттого современная вёрстка всё еще полна грязных хаков и вынужденных компромиссов), но эти ограничения стремительно уходят в историю.