SelenIT

Тут дело такое: XHTML 1.x, как многим известно, существовал в двух "ипостасях" — реальной, но мало где использовавшейся и не работавшей в IE (с Content-type: application/xhtml+xml и прилагающимися к нему всеми XML-ными плюшками, но и драконовским контролем ошибок) и виртуальной, работавшей везде, но по факту XHTMLем не являвшейся (с обычным Content-type:text/html и либеральным HTML-парсингом). Так вот, HTML5 обратно совместим с обеими разновидностями. Для text/html теперь безразлично, <br> или <br/> (как, впрочем, и для браузеров), оба синтаксиса уравнены в правах и сведены к вопросу вкуса, а доктайп оставлен исключительно для перевода браузеров в стандартный режим — опять же, как это исторически сложилось. А в application/xhtml+xml по-прежнему работают все плюсы и минусы XMLности (интеграция с другими XML-неймспейсами а-ля SVG и MathML, XPath, драконовский контроль ошибок веллформности)... и оно по-прежнему не работает в IE8- (но вроде как обещает работать в IE9). Доктайп в application/xhtml+xml теперь не нужен вообще — браузерам на него плевать (application/xhtml+xml рисуется в строгом режиме и без него), а DTD у HTML5 попросту нет (там другой, более совершенный алгоритм валидации). И вот этот вариант HTML5, отдаваемый как application/xhtml+xml и соответствующий всем XML-требованиям, и называют сокращенно "XHTML5". Вообще спецификация HTML5 строится так, что по факту все страницы считаются HTML5-страницами — возможно, содержащими ошибки, но тем не менее. Другое дело, что ни один современный браузер не поддерживает эту спецификацию полностью. Да и сама спецификация еще не совсем готова...

Фиг там. Это исходник скрипта, генерирующего код документа. Валидатора он интересует не больше, чем посетителя ресторана — цвет скорлупы яиц, из которых делается заказанный им омлет. Дайте тот исходник, который видит браузер (и валидатор, соотв-но). Без всяких там <?php?>, <%ASP%> и прочих серверных полуфабрикатов.

<meta name="description" content="та самая полезная информация">?

сорри, поторопился

А там случаем не поле ввода должно быть, стилизованное под бумажный бланк?

И действительно . О настолько простом фиксе я и не подумал (засело в мозгу откуда-то про "html всегда наследует размеры viewport-а" и мешало думать в правильную сторону). Вот и тройные знания в копилку . Спасибо, mishka2! Единственное, что чуть смущает — не помешает ли такой способ корректно снять скриптом внутренние размеры окна (напр., для показа красивого тултипа)?

Господа, а ни у кого случайно нет на примете галерейки навроде этой, можно без вывода подробностей по картинкам и верхней навигации, но сохраняющей работоспособность даже при плохом коннекте, если часть картинок не догрузилась? И желательно полегче и бесплатной для коммерческого пользования . Годится вариант для одного фиксированного размера картинок и тумбов, плавая смена слайдов а-ля айфон очень желательна, но готов рассмотреть др. варианты. Буду также весьма благодарен за наводку на учебник/туториал, как сваять подобную штуку на JQ самостоятельно (к каким событиям грамотнее привязаться, как проверить статус каждой картинки и т.п.).

Имхо, да... хвала ютубу!

Сорри, min-width для body еще нужен. Я его просто на автомате ставлю, если сайт не должен сжиматься меньше опред. лимита, поэтому до меня не сразу дошло, что его нет в примере. И еще, вариант с display:table для html у меня порвал цепочку 100%-й высоты (FF 3.6.11), чтоб ее починить, пришлось еще добавить display:table-cell для body.

Я обычно решал эту проблему одним html { background: #fff; }. Дело в том, что по спеке, если фон указан только для body, он автоматом переносится на html. А если указано и то, и то — такой путаницы нет... P.S. Да, еще я в таких случаях всегда ставлю min-width для body.

Насчет применимости DL для диалогов — хотя это и разрешено в HTML 4/XHTML 1, но я согласен с этими аргументами (в том, что касается именно диалогов, дальше автор явно перегибает палку). Просто инлайн-блока не хватит, особенно если реплики должны быть выравнены ровным столбцом. Как вариант, можно пример из текущего HTML5 можно оформить как-то так: <!doctype html> <style> time { display: none; } p { margin-left: 15%; } p b { float: left; width: 15%; margin-left: -15%; } </style> <p> <time>14:22</time> <b>egof</b> I'm not that nerdy, I've only seen 30% of the star trek episodes <p> <time>14:23</time> <b>kaj</b> if you know what percentage of the star trek episodes you have seen, you are inarguably nerdy <p> <time>14:23</time> <b>egof</b> it's unarguably <p> <time>14:23</time> <i>* kaj blinks</i> <p> <time>14:24</time> <b>kaj</b> you are not helping your case Или, если всё-таки табличкой — можно в нормальных браузерах задействовать td:first-child, а в старых IE <col> (там он позволяет больше, чем по стандарту)...

Сорри, но... что за планета на фоне? И что за "юбилейные даты" скрываются за непонятным планетоидом на переднем плане (это ведь явно не Луна!), неужто пресловутый майянский 2012? Ну и то, что "статьи и литература" в буквальном смысле отнесены до далекой звезды, какбэ символизирует Еще, имхо, логотипный шрифт плохо сочетается с Arial-ом, его бы визуально "отгородить" чем-нибудь... но я не дизайнер, поэтому судить не берусь. И вообще космос меня всегда завораживает, во всех видах. Правда, Байконур ассоциируется у меня с чем-то более "околоземным" и родным, а не таким "транснептуново-экзопланетным", но... всё равно красиво!

Я тоже наступал на эти грабли, вводя в гугл -moz-что-то прямо с начальным дефисом (в гугловом синтаксисе минус перед словом означает "только результаты без этого слова") . Просто moz-что-то (без дефиса) ищет и находит. По всему выходит, что элемент с таким display начинает вести себя как XUL-элемент stack (+ ссылка "подробнее" оттуда), только вписанный в строчный бокс. Это последнее обстоятельство и помогает эмулировать им inline-block в FF2...

Предполагаю, что в схлопывании полей (второй сценарий).

Только вот такого не будет . В старых (X)HTML абзац не вкладывается в <a>, в HTML5 вкладывается, но нет якорей <a name="...">. Просто и универсально — так: Проблемы поддержки :target в старых IE это, правда, не решит (всё равно понадобятся JS-костыли, если эффект критичен), но поможет избежать других сюрпризов от DOM.

Будет де-факто инлайн-блок, т.к. hasLayout есть благодаря размерам. Интересно. Float:left, оказывается, тоже "включает" маргин. Т.е., получается, маргин не пропадает, когда блок так или иначе привязан не к самому body, а к его текстовому содержимому. Какая-никакая логика вроде вырисовывается...

Сорри, пожалуй, я поторопился. Сам элемент ведь тоже сдвигается (тоже позиционирование?). Опытным путём выяснил, что маргин начинает применяться, если обернуть элемент в контейнер с ненулевым паддингом или бордером. А совсем отказаться от маргина в пользу паддинга родителя никак нельзя?

Проблема в margin collapsing-е у body. Во всех браузерах маргин дива вываливается, в IE6-7 нет (т.к. у body всегда hasLayout по дефолту). А создаваемый скриптом элемент css3-container, в который пихаются VML-костыли, имеет стиль z-index: -1; position: absolute; top: 0px; left: 0px; относительно body...

Авторитаризм, увы, тоже не всегда выход (вон, авторитарно ввели в первом CSS противоинтуитивную боксовую модель назло всем тогдашним реальным браузерам — и скольким поколениям верстальщиков приходится городить дикие слоёные пироги ради элементарной дизайнерской задачи "резиновая ширина с отступом"). Ответственность нужна в первую очередь, перед сообществом и всей отраслью, которую консорциум успел "приручить". "Но люди забыли эту старую истину... ©"

Средствами HTML/CSS — нельзя. Нужен Javascript, есть масса готовых плагинов, напр. jQuery tooltip.

Только не засовывайте <form> между <table> и <tr>, так делали ламеры в 90-х и браузеры до сих пор это ненавидят. Лучше, наоборот, засовывать таблицу в форму, а в ячейках таблицы уже размещать инпуты как требуется.

Подписываюсь под словами Дэвида. Похоже, рабочая группа CSS — самая ретроградская и упёртая в игнорировании объективного мира во всём консорциуме (благо, модульная природа спеки открыла кучу приятных песочниц типа трансформаций-анимаций, в которых так удобно по-страусиному спрятать голову от актуальных проблем. Но вообще мне непонятно: среди авторов последней редакции CSS2.1 числится тот же самый Иэн Хиксон, который по совместительству главный автор HTML5, где он весь из себя такой сторонник "pave the cowpaths" и вообще отталкиваться от сложившейся действительности, а не идеалистических мечт (в отличие от коллеги Хокона Ли). Неужели человеку с таким авторитетом слабо "разбудить" и коллег по CSS-цеху? Или у него раздвоение личности — реалист в разметке, прожектёр в оформлении?..

Режим рендеринга страницы браузером связан с типом документа лишь косвенно. У IE6 и IE7 есть только два режима — квирковый и "как бы стандартный" (насколько они эти стандарты понимают). У мозилловых, вебкитных и Оперы три режима — квирковый, стандартный и "почти стандартный" (всё как в стандартном, только картинки в таблицах ведут себя по-квирковому), этот "почти стандартный" режим включается при Transitional-доктайпах (как HTML4, так и XHTML1). У IE8 есть эти же три режима плюс режим эмуляции IE7 (к счастью, он с доктайпом не связан), у IE9 будут 6 режимов — три как у новых браузеров плюс эмуляция всех режимов IE8 и IE7, но это уже отдельная тема. Так вот, с коротким доктайпом HTML5 все браузеры новее NS6 переходят в самый стандартный режим, который только умеют (без каких-либо "почти"). Очень подробная статья про доктайпы и режимы (на англ.) — здесь.

Не, LunatiK как раз пытается отталкиваться от интуитивного здравого смысла. А вот чего употребляли, например, создатели боксовой модели content-box в CSS... А вообще прав был старик Галилео — всё относительно. Даже пиксели (особенно на принтерах и новых айфонах)

Ух ты, какой кавай няшный вырисовывается ==! Получается, все актуальные браузеры нагло нарушают почти принятую спеку (CR!), а W3C смотрит на это сквозь пальцы и, на всякий случай, аккуратненько обходит сторонкой (судя по моим наблюдениям) проблемный момент в официальном наборе тестов? Оригинальненько-с...