SelenIT

Для жестко фиксированной высоты можно так.

Поздравляю! И +1 ко всему вышесказанному!

У меня Page Info в FF там показывает такое: И xml-пролог не закомменчен. А на xiper.net — обычный "маркетинговый" text/html.

В его примере текст остался от моего, где действительно не схлопывались. А тут, да, текст оказывается правдивым только в IE7 и ниже

В браузерах с HTML5-парсером даже так

Отнюдь. Он тупо находит элемент со странным именем "test:div" в дефолтном для HTML5 неймспейсе, и работает с ним как с любым неизвестным...

Может, в браузере масштаб "съехал" (напр., от неловкого движения колесиком мышки при зажатом Ctrl)? Ctrl+0 не помогает?

Можно чуть подробнее? Я понял вопрос автора темы как "Почему на большинстве популярных сайтов стоит доктайп XHTML 1.x", т.к. из сайтов, действительно использующих XHTML ("технический", а не "маркетинговый", XHTML по определению Генри Сивонена) сходу могу назвать лишь xpoint.ru. Что никак не тянет на "большинство". С обычным же Content-type text/html, насколько я в курсе, любая разметка (независимо от доктайпа и "строгости синтаксиса") парсится либо как HTML5 (FF 4+, Хром 7+, Опера 11.6+), либо "как исторически сложилось" (достаточно похоже на HTML5 по построению за вычетом новых тегов), и уж совсем непохоже на XML. И это подтверждается моим личным опытом и всеми авторитетными источниками, что мне попадались...

Нет никакого HTML4, XHTML1, HTML5 - есть просто HTML. Неважно, что автор пишет (или думает, что пишет), важно, что (и как) браузер парсит.

Это смотря какой версии происхождения слова придерживаться. Имхо, при такой постановке вопроса наиболее вероятна первая

+100500! Строго говоря, в IE5-7 создается "layout", который во многом похож по поведению на контекст форматирования блоков. Но не во всём.

Это опять же нюансы CSS-представления, одного поля с псевдоэлементами ::before/::after (те тоже создают добавочные CSS-боксы для одного элемента). Content-model про эти дополнительные боксы не знает и знать не может, она же не ясновидящая

Именно потому, что этот clear сидит в своем отдельном блочном контексте (образованном его родительским float-ом). Честно говоря, именно определения "КФБ - это..." я там не вижу. И главного свойства отдельного контекста (изолированности внутренних блоков от соседей) из этих абзацев, имхо, не вытекает, оно описано в др. разделах (в частности, в описаниях флоатов и margin collapsing-а). Не может быть коллапса с их потомками. Друг с дружкой, если они сами сидят в одном контексте - запросто.

У меня и validator.w3.org, и html5.validator.nu выдают ошибку. Но зачем задавать 100%-ную ширину атрибутом, когда есть CSS?

Как я понимаю (хотя явного определения в спеке мне найти не удалось, но из описания поведения блоков в ней это логично вытекает) контекст форматирования показывает, что блоки в нем никак не взаимодействуют с другими блоками, находящимися вне контекстов. Т.е. прямоугольная область, полностью охватывающая все живущие в ней блоки (включая плавающие), со всеми их margin-ами и другими выступающими частями тела. Я когда-то пытался продемонстрировать это в этой демке (без создания контекста желтый верхний margin заголовка и "хвост" высокого поплавка торчат из зеленого блока наружу и цепляют соседние блоки, а при создании контекста "запираются" внутри него). Вот еще немножко по теме вдогонку) Как раз тут HTML5 абсолютно ни при чем. Контексты форматирования (блочный и строчный) — это исключительно CSS (пока что 2.1). И это надолго

Их в HTML никогда и не было. Они как были, так и остались в CSS. Именно так. Непосредственным потомком ul может быть только li и ничто иное, а уже внутри li — формально почти что угодно, но нужно смотреть по здравому смыслу. Display у него может быть какой угодно, хоть inline, хоть table-cell, хоть вообще none. CSS применяется к уже построенному DOM-дереву, а ограничения на Content-model действуют на этапе ее построения. Браузер сначала определяет, какой элемент и где у него создается (напр. конструкция <div><div> создает два дива один в другом, а <li><li> — два пункта списка рядом, т.к. открывающий <li> после <li> неявно закрывает предыдущий), и только потом к этим элементам применяется CSS, позволяющий до неузнаваемости менять их внешнее представление.

В HTML5 больше нет "блочного" и "строчного", теперь вместо них Flow content и Phrasing content соответственно (в первом приближении то же самое, но на базе логической роли в документе, а не дефолтного отображения в браузере). Эл-т <li> может содержать Flow content, т.е. фактически что угодно. Правда, в спецификации есть ремарка, что если понадобилось вложить в элемент списка заголовок — скорее всего список используется неправильно (т.к. любой заголовок неявно создает новую секцию, а список, по своей логике, должен бы сидеть в одной).

Так alexandr_v-vich выше уже показал. Сложности начались только с появлением сектора.

Мда... напомнило 2012-й же год на дворе, НТML5 c CSS3 всякие, какие к черту таблицы, какой к черту JS для hover-эффекта? <a class="hoverable" href="/primer.html"> <p><img src="/img/01_c.jpg"></p> <p>Картинка</p> </a> .hoverable { display: table; background: url(/img/01.jpg) top center no-repeat; } .hoverable:hover img { visibility: hidden; } Одна картинка фоном, вторая поверх, при наведении фон просвечивает. Никакой задержки, никаких скриптов...

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

У меня тоже первая ассоциация с игрой Конвея была . Только сейчас с удивлением узнал, что эта известная фигурка, оказывается, по совместительству, еще и неофициальная эмблема хакеров. Кстати, интересно, можно ли по правилам этой игры сделать периодическую фигуру из надписи "CSS"? Можно было бы анимировать ее при наведении...

Пример для Оперы с "покрышкой" вот. Насчет SVG я грешным делом имел в виду вставку его прямо в разметку (одна из приятных фич HTML5, работающая во всём новом, включая даже IE9). Для кроссбраузерности при цейтноте, имхо, лучше всего взять библиотеку типа Rapha?l, там вопросы совместимости (включая конвертацию в VML для IE8-), по идее, решены. Сам, честно признаюсь, с SVG пока серьезных дел не имел, поэтому личным опытом, увы, поделиться не могу...

Нет. Такое может быть, если файл будет называться просто "0" (без расширения), а вместо строгого сравнения (!==) использовать нестрогое (!=), которое не учитывает различие типов.

Боюсь, что нет(. Потому что есть риск нарваться на справочник, где "межстрочным интервалом" (или интерлиньяжем) будет назван не line-height, а leading. Видимо, из чего-то подобного скопипастили в Вики ту ересь, которая чуть не сбила с панталыку Radiocity в 5-м посте топика Поэтому я как раз советую изучать эту тему по англоязычным источникам (прежде всего самой спецификации) — там line-height может быть только line-height'ом, т.е. расстоянием от базовой до базовой, и ничем иным. А сочетание "вертикальный пробел" мне вообще до сих пор ни разу не попадалось, Яндекс тоже его не находит. И вообще "пробел" для align — странно. Поэтому я и спросил, где такой перевод нашелся. Очень многие термины, относящиеся к форматированию текста, пришли в CSS из печатной типографии. Но значение многих из них существенно изменилось (напр. если в металлическом наборе кегль шрифта — он же font-size — был реальной физической высотой металлической площадки с буквой, то в CSS он стал, по сути, математической условностью). Так что напрямую эти термины, может быть, с веб-версткой и не сильно связаны, но знание "истории вопроса" и происхождения того или иного понятия часто очень помогает понять их логику.

Результат readdir($d) присваивается переменной $e, и уже эта переменная сравнивается с булевским false. Ф-ция readdir возвращает false, когда ей больше нечего читать, поэтому если в переменной $e оказалось false — это значит, что все файлы директории уже перебраны, и цикл пора завершать. А до этого момента в эту переменную будет заноситься имя очередного прочитанного файла. Строгое сравнение нужно потому, что возможен, например, файл с именем "0" (строка из одного нуля). При нестрогом сравнении эта строка оказалась бы "равной" false, и цикл мог бы прерваться, не перебрав все файлы до конца.