SelenIT

Раздел 14.2 спецификации CSS 2.1, 4-й абзац. Во многих старых статьях еще иногда можно прочитать, что это правило действует для страниц с text/html, но не application/xhtml+xml (и пр., включающих XML-режим парсинга). Когда-то давно так и было (даже в спецификации!), но как минимум с 2009 года это больше неактуально — теперь background одинаково работает при обоих режимах.

Подозреваю, что не нужно. За всю свою долгую и нелегкую жизнь видел буквально пару раз, когда zoom использовался действительно по назначению, а не ради побочного эффекта — включения layout в старых IE. А для body и это не имеет смысла, т.к. там у него layout был по умолчанию. Опера и Fx, судя по всему, не добавляют, потому что не знают такого свойства. А вебкитные браузеры знают, но, насколько я в курсе, zoom:1 там не влияет ни на что.

Firefox, судя по всему, выводит составные свойства типа border только по частям, вроде borderLeftWidth и borderLeftStyle (либо через getPropertyValue('border-left-width') и т.п.). IE9+ при правильном доктайпе ведет себя аналогично ему. А в более старых IE вместо getComputedStyle(elem) был elem.currentStyle: http://jsfiddle.net/bYdmj/17/

В рисовании одноцветной границы блоком. Есть же свойство border (border-left и т.п.). Не говоря о том, что линия суммарной толщиной 103px (во всяком случае, не меньше 100 — толщины паддинга), пожалуй, уже не совсем линия, а как минимум полоса

Нельзя. В атрибуте нельзя использовать селекторы, только свойства со значениями. Атрибут — это как то, что внутри фигурных скобок, а селекторы — снаружи.

Если ничего не путаю, после небольшого пинка — нарисует. А если фон страницы однородный, то и пинок не нужен.

Всё нормально, он является разрешенным для HTML5 (хотя и не рекомендуется) И, похоже, такая ерунда только на главной странице, у которой даже заходов с IE5.x (не знающих других режимов, кроме Quirks) ощутимое количество. На поиске по картинкам и т.п. уже доктайп нормальный.

Почему двойную? Скорее, предлагаю заменить привычные комменты для себя (типа <!-- меню -->...<!-- конец меню -->) семантическими метками, понятными и человеку, и (возможно) поисковику Но это лишь один из множества вариантов. Можно пользоваться коротким доктайпом и удобностями типа autocomplete (это всё работает и в IE6+), но не пользоваться новыми структурными тегами, ограничиваясь логичной иерархией заголовков. Можно отдавать старым IE (по статистике IE8 <4%, еще более старые — на уровне шума) упрощенную чисто текстовую версию. Надо смотреть по специфике проекта, аудитории и т.п.

Byte Order Mark (метка порядка байт — указывает, в какой последовательности идут байты в многобайтных символах). Еще есть смысл проверить настройку default_charset в php.ini.

IE6-8 не поддерживает только стилизацию новых структурных элементов. Ничто не мешает использовать их только для семантического разделения в расчете на тех, кто понимает, а оформление вешать на старые добрые дивы. Если переформулировать вопрос как «есть ли польза от этих новых структурных элементов», то последнее время вокруг него опять поднимаются споры, и есть мнение, что для семантики важнее выделить наиболее важные элементы с помощью добрых старых микроформатов или модных новых микроданных (со словарями schema.org). Но в широком смысле пользоваться HTML5 сегодня приходится, альтернатив просто нет.

Огромное спасибо за поздравления, друзья! Буду стараться оправдать ваши лестные отзывы о моей скромной персоне и не подвести ваших ожиданий!

Доктайп поставьте — начиная с 8-й версии IE обе проблемы должны исчезнуть.

Простите слоупока... Запоздало присоединяюсь ко всем поздравлениям!

Нет. Это разные вещи для разных задач: <p> — для логической разбивки (или наоборот, логической группировки, если угодно), <br> — для визуальной, в пределах одной логической единицы. Использовать <br> для "разбивки абзацев" — такая же халтура, как <b><big>...</big></b> для заголовков. Совершенно верно. И это не баг, а особенность языка HTML, нравится нам это или нет. О которой нужно как минимум знать (а то мало ли, вдруг кто-то захочет сделать вложенный абзац или вложенную ячейку без таблицы).

Зря, вещь-то хорошая. Если очень не хочется, то не обязательно

Как более жизненный пример можно привести перебор цепочки предков HTML-элемента вплоть до корневого элемента. Вместо next подставить parentNode, логика та же

Как вариант — ячейкам добавить прозрачные (transparent) бордеры по бокам (кроме внешних сторон крайних ячеек), а внутреннюю рамку сделать тенью. Еще вариант — увеличить-таки border-spacing до 20px, а для tbody указать display: table; margin: 0 -10px;. Но вообще нужна ли тут именно таблица?

Как я понимаю задумку HTML5, смысл <article> — в сохранении смысла его содержимого в отрыве от остальной страницы, т.е. его можно целиком перенести, скажем, в RSS-фид. Анонсы статей в RSS-фиде, имхо, вполне уместны, а значит, и <article> для них в тему. Есть еще хорошая цитата про него (тут перевод). Несколько section-ов в article — тоже вполне нормально, если того требует логика иерархии заголовков. Другое дело, что алгоритм иерархии заголовков, учитывающий вложеность section-ов и им подобных, находится под риском удаления из спеки HTML5.0 версии W3C (что для меня странно, ведь половина браузеров этот алгоритм уже использует. А поскольку section-ы, по большому счету, только для этого алгоритма и нужны, всё чаще высказывается мысль, что и их, дескать, есть смысл выбросить нафик-с...

Верно. Но HTML 4.01 (и XHTML 1.x) уже история, для браузеров есть только HTML5 (точнее, просто HTML)

Там с форматами веселуха была . В Firefox, судя по всему (см. Known issues), осталась с mp3.

Забудьте . Уже давно можно (а с прошлого декабря это можно считать окончательно узаконенным W3C). Тоже забудьте . Смотрите на Content model каждого конкретного элемента и на общую логику (где текст, где иерархия структуры, где интерактивность и т.п.).

Неужели (см. 2-й пример)? А вообще по сабжу вот

Всё логично, по-моему. Сдвигается и то и другое, но граница строки лучше видна визуально.

Строго говоря, во-первых, уже довольно давно не только IE (хотя до 100% далековато, да). А во-вторых, речь-то не о голом JS, а о jQuery, как я понял...

«BRяки» достаточно часто использую в почтовых адресах и т.п., и в дизайнерских блоках, где критично расположение каждого слова. «HRеновины» использую в основном как самый «легкодоступный» разделитель при экспериментах и отладке серверных вещей (а-ля «сравнить вход с выходом»). Ненужный (при text/html) концевой слеш в обоих не ставлю из принципа