SelenIT

Дайте телепательную машинку протестирую. Скрипт пытается менять св-во element.style. А это свойство отражает — сюрприз! — то, что задано в атрибуте style этого эл-та, а не его действующий стиль. Отсюда и наблюдаемый результат... Действующий стиль виден в window.getComputedStyle(element) (в старых IE — в element.currentStyle).

В контекстном селекторе.

В строке "Продвижение по службе" в конце лишняя пустая ячейка, которая и распирает всю таблицу. Потому что там написано "<td>Пройти все 10 ступеней карьеры Бизнес<td>" — открывающий тег вместо закрывающего (который для td, вообще говоря, необязателен).

Bolder и lighter — это "жирнее" и "тоньше" относительно текущего. Для Thin, Light и т.п. можно использовать числовые значения (как-то так). Важно, чтобы заданный font-weight для @font-face совпадал с font-weight у элемента, для которого этот @font-face применяется (иначе браузеры некрасиво и все по-разному пытаются сжимать/раздувать шрифты сами: статья раз, статья два). По крайней мере, насколько я сам это понимаю

Два последних точно существуют, только не в HTML (и пишутся чуть иначе). Первый, оказывается, существовал в ископаемом черновике HTML 3.0, но так и не был принят (а жалко).

Ни в коем случае! Это — как раз CSS (в первых двух случаях изменяемый через jQuery, в третьем — подставляемый в чистом виде), в нем 'px' необходим! Ошибка — именно путать эти случаи (атрибуты HTML и свойства CSS).

Нестыковка есть, т.к. экраны очень редко "знают" свой честный физический размер и могут сообщить его браузеру. Поэтому стандарт предписывает "приблизительно подгонять" CSS-овский пиксель таким целым числом физических пикселей экрана, которое ближе всего к 1/96 дюйма (хотя возможен разброс). Для большинства существующих экранов это число равно 1, для "ретины" нового айпада — двум. Конечно, в итоге получается бардак, что размер CSS-дюйма может неслабо отличаться от дюйма физического, но разработчики стандарта решили, что в сложившейся действительности это меньшее зло...

Отдельно . Выше я упомянул его лишь для примера — как один из критериев уместности <article> вместо <section>. Так же, как в любом другом: min-width/max-width для внешнего контейнера и т.д. Резиновость и т.п. — это CSS, семантика тут никаким боком.

А если присмотреться, то видно, что рекомендует это дизайнер с привычками первой половины 90-х и происходит это за три года до того, как браузерная реальность в лице 1in = 72pt = 96px была высечена в граните зафиксирована в CSS-стандарте .

Такова жизнь, IE6 тоже был нормальным (более чем!) для своего времени (11 лет назад)...По вопросу — да, или доп. обертка (как выше), или рисовать границу тенью (а для старых IE так и сяк костыли). И еще: желательно беспрефиксный вариант писать последним, а -webkit-border-radius и тем более -khtml-border-radius уже несколько лет неактуальны (насчет -moz-border-radius можно поспорить, но лично я и в нем много смысла не вижу).

Меня смущает "безголовый" <article> в "наших координатах". Имхо, если считать "карточку" с координатами "самодостаточной единицей контента, пригодной для агрегации и т.п.", то логичнее внешний section заменить на article, а если нет — внутренний article вообще ни к селу ни к городу... И в "карточке" всё-таки должен фигурировать fn с названием организации. Навскидку вижу два решения — либо продублировать его в "наших координатах" в виде спана с display: none, либо поставить class="vcard" внешнему контейнеру и использовать главный заголовок. Сам затрудняюсь выбрать, что лучше и что хуже, надеюсь, другие знатоки подскажут. Тем, что подразумевает использование своего содержимого как целостной информационной единицы в другом контексте, напр. в RSS-агрегаторе. В комбинации "новости + контакты" я такой целостности не вижу. Cами по себе вложенные article — не преступление. Напр. в древовидных комментах вполне может быть самодостаточная сущность "коммент с ответами на него", где каждый ответ — тоже самодостаточная (напр. для RSS-потока комментов) сущность следующего порядка (по крайней мере, именно так учит размечать древовидные комментарии сам великий и ужасный Й. Хиксон). Но главный критерий — именно осмысленность использования article как единой сущности, и в данном примере я ее действительно не наблюдаю...

Если важна семантика — рекомендую обратить внимание на микроформаты/микроданные!!!!!!!! Для контактной информации просто напрашивается микроформат hCard. Для "пресс-центра", может быть (чтобы сказать точнее — надо видеть реальные примеры), подойдет hCalendar. Слоган, насколько я в курсе, ничем особым выделять не нужно, в плане семантики это обычный абзац текста.

Возможно, верстка уже заточена под нюансы "почти стандартного" режима. Тогда, действительно, можно валидностью особо не заморачиваться.

Количество ошибок — еще не показатель. С кодом типа <div/> при XHTML-доктайпе валидатор может радостно светиться зелененьким, но результат в браузере может о-очень сильно отличаться от желаемого Чем плохи Transitional-доктайпы? Идейно — тем, что не помогают сделать вёрстку логичнее и осмысленнее, разрешая все безобразия типа тега <font> и атрибутов align, от которых отказались еще в конце 90-х. Практически — тем, что включают в браузерах не стандартный, а "почти стандартный" режим, в котором браузеры имеют право не соблюдать стандарты в отдельных мелочах (и временами злоупотребляют этим правом — напр. Опера отказывается выравнивать inline-block'и по вертикали). Ошибочные width='500px' height='335px' и т.п. я бы исправил на валидные в HTML (это ж не CSS!) width='500' height='335'. Остальное можно оставить, оно ни на что не повлияет.

Просто выбирайте схему, где это — не ошибка, а штатная ситуация (не считая того, что в новых браузерах любые доктайпы, кроме <!DOCTYPE html> — самообман). А на ошибки валидации под <!DOCTYPE html> уже можете и не смотреть, они некритичны (хотя "px" из HTML-атрибутов я бы всё равно убрал — они при любом доктайпе там не нужны) Мнения по поводу "ошибок" в JS и не расходились, их я тоже ошибкой не считаю . Мнения, кажется, разошлись по поводу оправданности доктайпа XHTML Transitional (чем плох Transitional — я выше пояснил).

Валидатор совершенно справедливо (другой вопрос — оправданно ли в данном случае) ругается на неведомую хрень в XML-синтаксисе. Которая совершенно справедливо не сможет работать (больше того — вообще парситься), если страницу всё-таки захотят отдать именно как XHTML (ну мало ли чего в жизни не случается) При валидации как HTML5 ругается на незнакомый метатег, на отсутствие src у картинки и на "px" в ее width/height вместо числа (т.к. это разметка, а не CSS). Работоспособности страницы ничего из перечисленного не мешает.

Ну простота весьма относительная . А учитывая стремительно падающую долю и "немодный" статус непонимающих браузеров, вполне можно просто подпереть их костылями типа такого...

Стоит. Это результат нарушения правила №1 из моего коммента выше. Зачем "геройски сражаться" с ограничениями XML-синтаксиса, если не собираетесь использовать его преимущества (а использовать не получится, не игнорируя IE8-)? Поменяйте доктайп на человеческий (<!DOCTYPE html>) и половину "ошибок" как рукой снимет. P.S. XHTML Transitional — самая дурацкая схема из когда-либо созданных. Разрешен весь бардак в структуре (все deprecated-теги и атрибуты HTML4) и на этот бардак наложена куча XML-ограничений в синтаксисе, никогда не используемых по назначению. И смысл мучиться? А еще с ним inline-block в Опере не работает как надо

Валидатор проверяет соответствие разметки выбранной схеме. Не больше и не меньше. Для того, чтобы валидная верстка стала правильной, нужно изначально выбрать ту схему, которая лучше прочих решает поставленную задачу (а не ту, что лишь зря ограничивает); понимать, что в разметке для чего, и использовать вещи по назначению, а не перебирать элементы наугад, "пока валидатор не устанет ругаться". Без соблюдения этих правил от валидности мало проку, при их соблюдении она, как правило, получается автоматом. С учетом нынешней реальности нет смысла валидировать что-то другое, кроме HTML5.

Тестовый пример безобразия: http://jsfiddle.net/SYhDr/1/ Задача элементарная: нужно отпозиционировать табличку к правому краю и растянуть на определенный процент контейнера заранее неизвестной ширины и высоты. Казалось бы, проблем нет: при абс. позиционировании 100% высоты всегда известны (это фактическая высота containing block'а — предка с position: relative), подставляй числа и радуйся. С обычным дивом так и выходит. Но с табличкой ожидаемый результат получается только в Опере и... IE8. Хром 19, Сафари 5.1.5 и Огнехвост 12 в один голос отказываются растягивать табличку на заданную высоту, а в IE9 и вовсе происходит леденящий душу маразм. Причем пунктом 17.5.3 спеки (как пытаются мозилловцы в этом баге, явно родственном), тут не отбиться: высота таблицы-то — вот она, 20%! Кстати, из комментов к тому же багу явствует, что как минимум в 7-й версии Огнехвост вёл себя так же, как Опера (к сожалению, прямо сейчас проверить не могу). Неужели такой баг во всех новых браузерах, кроме Оперы? Или я не понимаю чего-то сильно неочевидного, но очень важного, в спеке? Заранее спасибо за любые подсказки и наводки! P.S. Поведению IE9 придает особую пикантность влияние top: c ненулевым значением всё немножко иначе (хотя гориз. позиционирование, увы, менее бредовым не стало)...

Насколько я в курсе, уже нет, теперь он позволяет переключаться между движками Trident/WebKit, причем второй стоит по умолчанию и новее, чем у Хрома Не исключено, что некоторые счетчики и заносят его в "Хром" и "IE" соответственно, в зависимости от используемого движка. По крайней мере, у netmarketshare.com есть занятные строчки "Chrome 18.0 - Maxthon Edition" и "Microsoft Internet Explorer 8.0 - Maxthon Edition". Правда, в сумме они набирают всего 0,35%...

http://www.impressivewebs.com/browser-usage-stats/ (в3шулерз != объективная статистика, и вообще). Его объективно очень мало. Максимум, что смогли нацедить даже его фанаты — порядка полутора процентов (явно завышено). Нет.

А, ну тут я согласен. Рендерер (притом оперный) я привел чисто для иллюстрации. Но понятия "верх и низ лайнбокса" (явно наводящие на мысль о нем как о прямоугольном контейнере) есть и в спеке (в самом низу)

С логикой построения этого прямоугольника я не спорю. Но не вижу проблемы, почему бы благородным донам не рассмотреть его как "типа контейнер" . К тому же есть как минимум одна ситуация, когда сразу нужна именно нижняя граница этого "контейнера", вне зависимости от положения базовой линии (вышеупомянутый случай vertical-align: bottom).

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