SelenIT

Причем не просто внутри, а непосредственно внутри (как child node). <section><header><div></div></header></section> — уже не возьмет.

Ах точно, Оперу забыл, нехорошая она капризная северная красавица . Хотя для однородного фона и ее можно "уломать", еще одним слоем без заливки и с толстым скругленным бордером фонового цвета. Для неоднородного фона — видимо, только SVG.

Собственно, я к тому и веду, что строка <ul><li><table> <tbody><tr><td><p>Test</p></td></tr> </tbody> </table></li></ul>точно так же требует... и далее по тексту дословно. И видимость четкой и упорядоченной структуры — не более чем видимость. Можно "на автомате" всунуть между <p> и </p>, например, заголовок — и тоже удивиться, отчего результат не совпадает с ожидаемым. И без закрывающего </p>, возможно, догадаться о причине произошедшего будет даже проще...

Формально можно, но большого смысла нет. Новые логические теги служат для деления страницы на смысловые секции и построения "плана страницы" (document outline), а в ячейках таблицы они оказываются заперты в отдельные клетки и в общий план не попадают. И оказываются почти бесполезны для анализаторов на базе нового алгоритма. Можно. Надо смотреть по ситуации. Возможно, больше подойдет <nav>, а то и <header>. Имхо, вполне.

Ну если очень захотеть...

НЕЛЬЗЯ! В табличные теги можно вставлять только элементы таблиц. Что-то другое можно вставлять или внутрь <td>, или оставлять снаружи <table>. Таблица — как котёнок: <table> — шкура, <tbody> — мягкие ткани, <tr> — брюшная полость, <td> — желудок. И только в желудок можно вкладывать разные вкусняшки. А когда живодёры пихают что попало таблице под шкуру или в брюшную полость мимо желудка — ей больно, и от боли она может вести себя непредсказуемо.

Сорри, можно ссылку на источник такого перевода? Верно. Но если английское line-height однозначно и может значить только расстояние между соседними базовыми, то французско-русские варианты меняли своё значение по мере перехода от металлического набора к электронному (о чем говорится по моей ссылке выше), поэтому в разных справочниках можно наткнуться на разные их определения. В спецификации CSS есть и оба этих понятия, и leading (и даже half-leading, адекватного русского перевода которому я так и не нашел). Я как раз говорю о том, что в английском путаница со всем этим безобразием минимальна, поэтому лучше разбираться с ним в первоисточнике, а не в переводах. (P.S. По абсолютно непроверенным слухам, возможно, в ближайшем будущем на css-live.ru появится что-то уникальное именно на эту тему, так что рекомендую следить за обновлениями!

Хорошо, опыт промышленной эксплуатации, предполагающий парсинг кода собственным парсером на регулярках — ОК, принято. А другие фанаты сторонники этого правила чем его аргументируют? Аргумент про "порядок" прошу не предлагать — история топика ясно показывает, что порядка один голый факт закрытия тегов не гарантирует. Гарантирует порядок лишь понимание логики разметки. И для него, имхо, осознание, что элементы в HTML разные (по назначению, модели контента и т.п.) — только плюс, а причесывание их под одну гребенку ("нечего думать, закрывать надо!") не только не приближает к этому пониманию, а хорошо если не уводит от него...

Просто здесь (как много где в IT) ситуация, что английский термин понятнее и однозначнее, чем его перевод (который в другом контексте может означать совсем другой термин). С line-height'ом запутаться трудно, а вот с "интерлиньяжем" — увы...

Значит, это неидеальное решение, т.к. не выдерживает проверки суровой правдой жизни...

С термином "интерлиньяж" есть путаница. Иногда им называют междустрочный вертикальный пробел (по-ненашему "leading"), а иногда — именно расстояние между базовыми линиями соседних строк, которое складывается из высоты литеры и этого пробела (это и есть line-height по факту). Сама приставка "интер-" ("между-") в нем сбивает с толку. Но я склоняюсь к тому, что сейчас правильно называть интерлиньяжем именно line-height, а для тёти Вики нужна небольшая правка Кто хочет дойти до самой сути и вникнуть в историю вопроса (либо запутаться окончательно и попрощаться со своей крышей ) — можно начать с этой статьи

Ух ты, не задумывался о таком, а ведь это еще один реальный аргумент за незакрытие тегов!

Пардон? Почему парсить без явных тегов проще? Хотя, имхо, если всё равно нужно парсить потенциально любую, заранее неизвестную разметку — разницы вообще быть не должно, алгоритм-то один. А дискового пространства, да, понадобится на какие-то доли процента меньше

alexandr_v-vich, и верно . Перемудрил я. Спасибо за поправку!

Как-то так?

andreyjvasilev, при стандартном доктайпе цепочка 100%-й высоты должна тянуться от самого корня, т.е. от HTML (смотрю, это уже есть). Осталось поменять height на min-height для body и добавить overflow: hidden для .container (чтобы плавающие элементы из него не "вываливались"), а лучше убрать float у футера (зачем он там?).

Ух ты... такого PUBLICчного слона я и не приметил Viper, спасибо за глазастость и за объяснение! Действительно, банальный квирксмод, всего лишь. А я тоже было уж понадеялся на новую фишку (наподобие того, как 3-4 года назад из браузеров и спеки тихонечко убрали различие в заливке фона между text/html и application/xhtml+xml)...

Полагаю, ключевая фраза там И описывается алгоритм, как эта ширина учитывается. Дальше вступает в силу ширина самого containing block-а (т.е. для абсолютов, по определению, предка с relative) — для display: block это п. 10.3.3 спеки, для инлайн-блоков — п. 10.3.9, и т.д.

Насколько я понимаю, дело в разной ширине containing block'а, от которого пляшет вычисление ширины абсолюта. У блочного родителя это "во весь контейнер", а у инлайнового (а также табличного и плавающего) — ширина обычного контента, в данном случае — ноль. Поэтому во втором примере абсолют и ужимается до предела.

ПОЗДРАВЛЯЮ!!!

Вот еще одна проблема из-за закрытых тегов А Гугл, тем временем, советует не закрывать (и не открывать) всё, что можно (надеюсь, что по тем же мотивам, что и я).

Тоже пытались "вложить в абзац" список, заголовок или таблицу?

А теперь мне объясните, пожалуйста... почему body на всю высоту вьюпорта (во всём кроме IE), хотя у html высота не задана (и никакой магии типа absolute навскидку не видно)? Что за революцию я проспал в очередной раз?

Не надо ничего обходить. Надо лучше продумать интерфейс, чтобы он был логичен и не вступал в противоречие с привычками пользователей и дефолтными настройками браузеров. Всплытие попапа при наведении (а не клике) — поведение более чем нелогичное, непривычное, неприличное, в конце концов. И люто, бешено раздражающее!

screen.width вообще бесполезен для чего-либо, кроме статистики (и то уже сомнительно). Начиная с тривиальщины, что юзер не обязан открывать окно на весь экран, и заканчивая тем, что он измеряет размер не в тех пикселях, что браузер (особенно на новых устройствах с "ретиной", где, кроме пикселей, есть еще пикселёчки ). Лучше всего раскрыл тему небезызвестный PPK в двух статьях и презентации.