SelenIT

Я и говорю — дело вкуса. Может быть удобно, да, но знать о подводных камнях стоит (дисклеймер: у меня лимит 8 Гб у домашнего ADSL и 250 Мб через мобильник — жизнь такая ). И возвращаясь к исходному топику Катерины — там речь шла об использовании вспомогательных фич онлайнового валидатора (в частности, проверятора структуры заголовоков). Да, в Хроме для этого есть отдельная встроенная фича, но есть приверженцы и других браузеров. Официальный валидатор — универсальный инструмент, не зависящий от индивидуальных настроек и предпочтений кодера. Да, для него есть альтернативы, но что плохого в знании множества вариантов, из которых можно выбрать оптимальный именно для себя? Беда валидатора — он фокусирует внимание не на тех ошибках, о которых важнее всего знать новичку. В аналогии со строительством дома, валидатор укажет на неоштукатуренную вовремя стену или косо вставленное окно без шпингалетов (и будет прав, такое нужно исправлять!), но вполне может пропустить, например, то, что туалет оказался замурован наглухо (без единого дверного проема), а на кухню можно попасть только через балкон соседней квартиры (т.к. валидатор не телепатор, замысел архитектора ему неизвестен — вдруг так и задумано? А монтаж перекрытий вполне соответствует ГОСТам и СНИПам...). Я за то, чтобы новичок научился сначала правильно решать задачи архитектора — чтобы все помещения в доме (и DOMе ), который он строит, были доступны, логика документа была стройной и прозрачной и т.п. И только после этого можно переходить к наведению красоты в мелочах. В общем, я за то, чтобы у новичка вырабатывалась привычка к красивому и логичному собственному коду, а не к зеленому огоньку валидатора (который этой красоты, увы, не гарантирует, как и понимания разметки). Кстати, когда такая привычка появится, то и проблем с валидатором не будет (в отличие от верстки "от балды", когда один невпопад воткнутый тег порождает три-четыре сообщения об ошибке — в месте открытия, в начале следующего тега, в месте закрытия и перед "итого", вот такие вещи с непривычки действительно демотивируют). C валидацией XHTML, при отсутствии понимания разметки (а взяться этому пониманию неоткуда — куча постоянно тиражируемых статей и написанных по ним книг превозносит мифические преимущества XMLности, обвиняет HTML в несуществующих грехах типа "там можно писать <а><b></a></b>" и скрывает правду об обработке XHTML в браузерах ), всё еще хуже. Валидатор вполне может пропустить <div /> или <br></br> (оба — валидные XML-теги), но браузер воспримет их совсем иначе, и новичок вообще не сможет понять, откуда ошибка... А ЖHTML — это я так сокращенно "Живой [стандарт] HTML" называю, который вместо HTML5 у WHATWG. Мне казалось, что на этом форуме это сокращение уже почти прижилось

Именно так. Элементы парсятся с учетом их content model, а только потом к ним применяются стили. А валидаторы про стили вообще ничего не знают.

В HTML5 <a> больше не строчный, а... похож на <ins> и <del> прежде (если сам внутри строчного, то допускает только строчное содержимое — точнее, "phrasing content" по-новому, если среди блоков, то может содержать блоки и внутри). Это по факту работает во всех браузерах вплоть до IE6. Прочитать можно, например, у HTML5-докторов. А учили правильно. Более того, именно в CSS это правило особенно важно, т.к. там за правильной иерархией боксов (блочные только в блочных, рядом с блочными только блочные и т.п.) следить некому, кроме автора страницы (рендерер, конечно, выкрутится добавлением анонимных блочных боксов где надо, но не факт, что результат автору понравится. Вот только роли HTML-элементов CSS менять не может (CSS применяется к элементам уже отпарсенной DOM, и если парсер не допускает, к примеру, существования блочных элементов внутри <p>, то никакой CSS не поможет их туда затолкать — он приходит, когда их судьба уже решена). Ну и про HTML5 troll всё верно написал...

При каждом обновлении странички? Т.е. 100 раз обновил страничку в процессе разработки — незаметно для себя потратил 100 * вес странички исходящего трафика? Нет, я всё понимаю, "в цивилизованном мире" давно такими мелочами не заморачиваются... но есть же и те, у кого небезлимитный инет через мобильник... Но тут, конечно, да, вопрос вкуса и привычки (мне удобнее, когда действия браузера происходят под моим контролем и по моему желанию, кому-то удобнее, когда браузер делает всё сам и дает готовый результат). Я бы выделил не "сразу", а "вдумчиво" . А слепое валидаторопоклонство именно для новичков этой вдумчивости анализа ошибок скорее мешает (вместо того, чтобы разобраться с неверной логикой верстки, приведшей к ошибке — часто возникает стремление "заткнуть" или "обмануть" валидатор, замаскировав ошибку костылем, нередко скриптовым). Валидность — всего лишь аналог орфографии, не допускать орфографических ошибок в словах, конечно, важно, но куда важнее при изучении языка научиться правильно строить фразы, адекватно выражающие мысли. А этому валидатор, к сожалению, помочь не может. Поэтому я и советую обращаться к валидатору лишь под конец работы (когда автор вдумчиво разобрался с логикой верстки, как мог), а не держаться всё время за его ручку. На самом деле у него есть два режима проверки, второй — вполне совпадает с официальным. Но само наличие путаницы огорчает. Плюс была (как сейчас не знаю, давно не юзал) проблема с HTML5 (он же "ЖHTML" ). ОК, Validity для Chrome — хороший плагин для валидации, разобрались . Но речь-то была не тупо о проверке "валидно/не валидно", а об использовании дополнительных опций официального валидатора. Плагин умеет работать с ними? P.S. Спор о важности валидатора, имхо, интересен, но в этой теме явно махровый оффтоп. Может быть, модераторы отделят его и перенесут, скажем, во Флейм?..

Это действительно проблема — для поисковиков и поисковой оптимизации. Какой-никакой текст у ссылок должен быть обязательно. На самый худой случай — в виде alt-текстов картинок. Хотя лучше нормальным текстом, используя техники замены его картинкой

Полагаю, в поисковике, как-то так.

А ЖHTML/HTML5 он уже проверяет? Кроме того, "каждый раз лазить" и не надо — достаточно одного раза, когда считаешь, что верстка уже готова. Если изначально верстать аккуратно и "семантично", соблюдая иерархию элементов (логические блоки — текстовые блоки — текстовые фрагменты), валидность, как правило, получается сама, побочным продуктом. Кроме того, надо еще разбираться, что именно эти плагины/аддоны проверяют (напр. популярный аддон "HTML Validator" для FF по дефолту работает в режиме Tidy, пропуская некоторые ошибки формальной валидности, зато придираясь к формально валидным вещам типа пустых спанов — которые, конечно, зло, но для кроссбраузерной реализации некоторых вещей еще бывают необходимы). Поэтому постоянно смотреть на иконку валидатора и делать ее зеленой любой ценой бесполезно и бессмысленно, это отвлекает от более приоритетных задач. И вообще валидатор в браузере — вещь явно лишняя. Вот в редакторе он бы не помешал. Главная задача валидатора — отлов глупых ошибок/опечаток по невнимательности (которые бывают и у мастеров), больше особого толку от него нет. Зеленая иконка далеко не гарантирует качества, да и красная — при одной-двух ошибках типа незнакомого атрибута при строгом доктайпе — не обязательно показывает, что верстка плохая. И официальный валидатор от W3C соотносится с безымянными плагинами примерно как платиновый метр из парижской палаты мер и весов с китайской пластмассовой линейкой...

Скорее всего. У оперы наследственная беда с дробными процентами. Возможно, корень беды — в margin-left:-0.5%; у контейнера.

По поводу <br> vs. <br/> vs. <br /> — ЖHTML как раз навсегда покончил с этим спором, пишите, как вам привычнее, браузерам пофиг, а валидатору и подавно . Конечно, если нужен именно визуальный разрыв строки (напр., при оформлении адреса или верстке стихов). С остальными одиночными тегами аналогично. Но вот </br> не должно быть никогда. Даже в XHTML (где бредовая конструкция <br></br> проходит формальную валидацию, но нарушает совместимость с HTML, т.к. в любом HTML закрывающий тег для пустых элементов запрещен).

Вставлять логотип через плагин — уж точно не решение, по-моему. Можно поколдовать с заменой текста на SVG-рисунок, но, честно говоря, я даже не сталкивался с готовыми примерами — будете в числе первопроходцев (и фоллбэк для IE8- всё равно понадобится). С точки зрения баланса трудозатрат и кроссбраузерности, видимо, растровая картинка с запасом по разрешению еще минимум год-другой будет вне конкуренции. Нет, исключительно CSS-спецэффекты. Правда, до кроссбраузерности тут тоже далековато (IE8- не держит трансформации, а text-shadow нет даже в IE9)... Имхо, это всё-таки претензия к дизайнеру/разработчику движка, верстальщик здесь лишь стрелочник...

У W3Cшного валидатора тоже есть опция "Show outline" (чекбокс вверху, сама outline показывается внизу)

А слабо логотип вообще текстом зафигачить, типа такого?

Имхо, сильно зависит от ситуации. В случае меню здесь оно убивает двух зайцев — задает высоту полосе и центрирует текст по вертикали. А стыковать его ни с чем не нужно, так что даже издержки масштабирования верстки не поломают. Имхо, тут всё оправдано. А вот для логотипа, да, рискованно. И кнопку "read more", на мой взгляд, вполне можно было попробовать сделать без картинки, бордер-радиусом и градиентами (раз уж общий прицел на перспективу, тот же бордер-радиус всё равно используется в др. местах и т.п.).

Псевдоэлемент.

Плохие примеры — с выключенным сглаживанием, в IE сглаживание своё, независимое от ОС. Если включить сглаживание в ОС (clear-type), будет везде примерно как в IE. По-другому не лечится (не считая архиизвратных костылей с text-shadow). Имхо, XP и так вымирает, а доля XP без сглаживания падает еще быстрее (я вообще не понимаю, откуда эти XP без сглаживания берутся — сколько сам ставил, у меня всегда сглаживание по умолчанию было включено!), так что можно особо этим не заморачиваться. Конечно, если именно такая XP у Самого Главного Заказчика — тогда хуже...

Для IE8 еще можно выкрутиться двумя ПЭ и двумя фонами. Но проблему красивой стыковки углов это (в отличие от border-image), увы, не решает...

У td родитель - tr. Соответственно, в каждом tr к первой td применяется только правило по классу, ко второй (как к не первому ребенку) — оно же + правило с соседским селектором. А br им ни разу не старший брат (а всего лишь двоюродный прадедушка — брат table, родителя tbody, который родитель tr-кам), поэтому ни на что не влияет.

.hackcss — любой элемент с классом "hackcss" * + *.hackcss (эквивалентно * + .hackcss, звездочка специфичности не меняет) — любой элемент с классом "hackcss", непосредственно следующий за любым элементом (т.е. не первый ребенок у своего родителя). * ~ *.hackcss (эквивалентно * ~ .hackcss, звездочка специфичности не меняет) — любой элемент с классом "hackcss", идущий после любого элемента (т.е. тоже не первый ребенок у своего родителя). Если первый див является первым ребенком родителя, к нему применяется только правило для .hackcss. Если перед ним идет <br> — он уже не первый ребенок, поэтому к нему применются оба правила. Второй див всегда не первый ребенок, поэтому к нему всегда применяются оба правила. IE6 соседских селекторов тупо не понимает. IE7-8, по идее, понимает +, но не должен понимать ~ (насколько мне известно). По-моему, всё логично

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

А в чем прикол? У меня (Хром 16, ФФ10б, IE9, дальше не проверял), вроде бы, всё работает ожидаемо: первый див (подпадающий только под селектор класса) - синий, второй (подпадающий также под соседский селектор) - красный жирный. Или я в упор не вижу чего-то очевидного?

Сделать можно через объект с соотв. полями: var img_counts = {} $('.imgcl').each( function(i,el) { img_counts["id_" + $(el).attr('src')] = 0; } ); for (var i in img_counts) alert(i + ': ' + img_counts[i]); Но действительно незачем. Картинка, если она уже была загружена, при последующих запросах и так будет грузиться мгновенно (из кеша). И для закрытия попапа, имхо, совсем необязательно знать предысторию загрузки картинок в него. Покажите более полный пример - вместе набросаем простое и изящное решение без таких подвывертов...

Одной оберткой, имхо, не отбиться. Кратность высоты контента высоте орнамента же не гарантирована, а сдвинутый орнамент у нижней границы - безобразие. И это не считая нетривиальностей при стыковке углов... Я бы посоветовал как раз взять border-image для нормальных браузеров, а старью оставить деградацию до обычного бордера (solid, dotted или double - по вкусу, я бы выбрал последнее).

Соответствует нику...

В новых браузерах можно, через media queries (напр., здесь). Но IE8 и ниже, к сожалению, не новые...

Имхо, 7-й сдохнет быстрее, чем 6-й. За 6-й кое-где цепляются из-за заточенного под него корпоративного софта, с 7-м такой проблемы не будет, т.к., во-первых, такая проблема появилась до него, во-вторых, любой из более новых можно перевести в режим его эмуляции. Кроме того, 6-ка — последняя версия, на которую можно проапгрейдиться под Win 9x (не в этом ли причина его сверхпопулярности в Китае?), а везде, где работает 7-ка, можно бесплатно проапгрейдиться хотя бы до 8-ки (и сама MS мягко, но настойчиво это предлагает). Не случайно даже в том же Китае 7-й IE уже почти уполз ниже 5%-ного барьера, господствуют 6-я и 8-я версии (предельные для своих веток Windows) и заметно растет 9-я...