SelenIT

Тут рамка - позиционированный родитель img_box-а, поэтому в ней создается своя "стопка" (stacking context), а z-index самой рамки лишь поднимает всю эту "стопку" целиком над остальной страницей. Опустить потомка ниже родителя можно разве что отрицательным z-index'ом, но без гарантии кроссбраузерности. По-хорошему, лучше сделать рамку отдельным элементом и разместить его на одном уровне с img_box-ом.

Именно!

Это медвежья услуга форумного движка (как бы перестраховка от XSS). Другое дело, что метка "javаscript:" в обработчиках событий вида onчто-то вообще ни к селу ни к городу не пристала

Нужно еще body растянуть на весь экран, например, как-нибудь так: html { height: 100%; } body {min-height: 100%;}

Так и должно. У разных браузеров при разных темах оформления разная ширина скроллбара, рамки окна могут быть, а могут не быть, нередко бывают всякие боковые панели и т.п. В современных браузерах задачу можно решить вообще без скриптов, через media queries в CSS, типа такого: Но для IE пока без скриптов/экспрешнов, к сожалению, никак...

А под какое разрешение красотулька заточена? А то 301×347 пикселей для какой-то RSS-иконки — не жирновато ли даже в эпоху FullHD-мониторов? Или, может, в этом блоке всё-таки и текст какой-то предполагался?

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

Имхо, косвенно сказано: т.е. этот самый контент у элемента должен быть, хотя бы потенциально (и псевдоэлементы добавляются рядом с ним внутри элемента). А input — пустой элемент, не имеющий никакого контента по определению. А Опера — продвинутая, у нее свойство content определяется для любого элемента. Видимо, для единообразия и псевдоэлементы она пихает туда же...

Насчет required я в основном имел в виду привязку для скрипта валидации, всё-таки по конкретному атрибуту привязываться удобнее, чем шерстить классы (если не брать готовые решения типа JQ Validation). Ну а в новых браузерах заодно добавится нативная валидация при выключенном скрипте — чем не progressive enhancement?

Теоретически можно — выбрать всё подходящее через getElementsByName, перебрать циклом, проверить координаты каждого, если очередной окажется в поле зрения — выйти из цикла на следующем, сделав ему scrollIntoView. Но сначала рекомендуется помедитировать на троллейбус . Не проще ли сделать name-ы разными, как им и положено быть (напр., общая основа - подчеркивание - номер вхождения)?

Поздравляю! Рассказывают, что в советское время преподы военных кафедр любили подкалывать студентов, приходивших на зачет в джинсах: "Почему вы в одежде наиболее вероятного противника?" Студенты обычно терялись, а между тем на этот вопрос существовал правильный ответ: "Потому что она является наиболее вероятным трофейным имуществом!" Возможно, подтекст плаката где-то аналогичен...

Я под таковым подразумевал как раз XHTML 1.0 (чья пресловутая совместимость с HTML-браузерами по факту держится на неправильной поддержке ими HTML4!). Тут ничего не поделаешь, названия прижились, хотя "CSS-совместимый" режим, наверное, по смыслу звучал лучше. Главное, имхо — что браузер не не отступает от стандартов намеренно, как бывает при Transitional-доктайпах или вообще без таковых. IE6 с коротким доктайпом ведет себя так же предсказуемо, как и с длинным стриктовым — для него и подавно разницы нет. А возможность без приступов валидаторофобии использовать атрибуты autocomplete="off" (незаменимый, например, в каптче), required (вместо мороки с классами) и вообще любые с data-префиксом — неплохой бонус!

Дайте другой глобус другие браузеры. Беспощадная правда жизни в том, что короткий доктайп переводит их ровно туда же, куда и длинный HTML4 Strict/XHTML1 Strict. Так что минус этот общий для них всех. А если не видно разницы, зачем платить больше (писать лишний код и тратить лишнее время на ублажение валидатора несуществующего в природе языка)? А вот для Transitional-доктайпов добавляются новые минусы в виде "почти стандартного" режима aka "limited quirks mode".

В том разделе, 9.4.1, написано примерно такое: а в разделе 8.3.1 Collapsing margins, третьим пунктом списка — Получается, что в таких блоках margin-ы схлопываются только у потомков друг с другом, но не у родителя с потомками...

Хм... ротейтнуть табличку на 90° (любым доступным способом, сейчас их много развелось), а содержимое каждой ячейки обернуть в отдельный контейнер и ротейтнуть его обратно?

Тем, что создает отдельный контекст форматирования.

Грубо говоря, body="vcard hproduct" с соотв. потомками обоих типов. На мой взгляд, помешать одно другому не должно. Впрочем, "матрешка" из разных микрофоматов друг в друге тоже не должна помешать, если поля не пересекаются...

Холиворная это тема, даже у абсолютных пунктов есть приверженцы . Лично я тоже за пиксели: браузеры, не умевшие их масштабировать (главный мотив em-мании трех-четырехлетней давности), считай что вымерли, зато у нас будет абсолютный контроль над межстрочными интервалами и т.п. (c em-ами нет-нет да сползет где-нибудь из-за округления) на любом уровне вложенности. А пункты — для печатной версии. Но у других точек зрения есть свои аргументы.

А что говорят на эту тему яндексовский валидатор и FF-овский Operator? Интуитивно, дробить один hCard на ошмётки как-то не по феншую. А вот назначить для одного контейнера классы от двух микроформатов — будь лично я парсером, я бы такое точно распознал . Плюс не вижу очень страшной беды продублировать название в скрытом спане (для кадендарных событий поначалу еще не такую бяку с title предлагали)...

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

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

Мне еще удавалось добиться неплохих результатов (уменьшения веса картинки вдвое против фотошопного с сохранением прозрачности и без сильно заметной потери качества) за счет ужатия палитры в 512-1024 цвета с помощью прожки Color Quantizer.

Наткнулся на занятную презентацию: расстановка точек над доктайпом в исполнении Вадима Макеева aka pepelsbey.

Автоматически никак. Можно в том же цикле, кот. расставляет onclick-и, ставить 'if (validate(form)) form.submit()', а в ф-ции validate() возвращать либо результат валидации, либо всегда true (в зависимости от формы). Но лучше всё-таки переделать, завязка на включенный скрипт для отправки формы считается существенным ограничением доступности.

Есть тут путаница (исторически сложившаяся), скриптовый submit() onsubmit-а не вызывает. Придется явно вызывать form.onsubmit() перед form.submit(). Но вообще, неужели никак не застилизовать нормальную кнопку submit, что пришлось изворачиваться скриптом?