SelenIT

Мой тот ужасный экспрешн, к сожалению, вызывает зависание в конвульсиях у IE9 beta (в режиме соотв. эмуляции). Поэтому советовать его я не берусь. С картинкой, конечно, проще (ее высота всегда известна, рассчитать половину разности ее и родительской элементарно), но всё равно это очень кривой костыль. Другое дело, что здесь картинка всё равно грузится скриптом — можно скриптом же ее и подвинуть (по <img onload>). Но зачем такие сложности, когда таблица может сделать это сама, и она уже есть?

"Волны перекатывались через мол и падали вниз стремительным домкратом" Можно, img:hover {...} или li:hover img {...} Но тут, по-моему, это едва ли поможет — тут явно глюк браузера. Сильно похоже, что это какая-то пре-альфа релиза, которого вообще не было, причем больше пяти лет назад... К сожалению, нельзя. Только в теге <style> или внешнем CSS. А у меня встречный вопрос к автору темы — как сейчас достукиваться до %username%.at.tut.by? В штатном интерфейсе я заветной ссылки не нахожу с самого переезда тутбаевской почты на gmail...

Так проблема в IE7 — какой display:table-cell? Вообще на дивах с фиксированной высотой в IE7 не сделать. Можно сделать на inline-block'ах с дополнительной вертикальной "подпоркой". Но мне непонятно, зачем там вообще аж два дива-обертки. Можно ведь вставить картинку напрямую в td, и border задать самой td-шке, раз таблица уже есть. И всё будет автоматом центрироваться везде...

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

Уже не вылезет. Не успеет

Имхо, есть замечательная и наглядная вещь CanIUse.com. Накладываем ее на свою (оринтировочную) статистику и смотрим: если ярко-зеленый явно преобладает — смело юзаем фичу, если же красные пятна расползаются больше чем на 10% — лучше повременить... месяцок-другой. И пользователи целы, и разработчик сыт. Имхо, извраты будут востребованы еще о-о-очень долго. Полет фантазии дизайнеров всегда будет на два шага обгонять штатные технические возможности: дали нам простые тени — дизайнеры захотят сделать их текстурными, дали круголки — дизайнеры захотят выгибать их внутрь и украшать барочными завитками, и т.д., и т.п. А тем более, когда отовсюду доносятся отголоски войны префиксов (а с безверсионной моделью развития префиксы будут всегда). А тут еще массовые 3D-экраны на подходе, штатные средства в CSS для этого появятся хорошо если года через три, а дизайнеры захотят сразу...

Я пропагандировал (и сейчас активно пропагандирую) новый доктайп, атрибуты типа autocomplete и data-что-угодно, вышеупомянутые блочные ссылки и т.п. — то, что и так давно работает везде, а по новому стандарту еще и валидно. За немедленное повсеместное внедрение новых тегов, новых элементов форм и прочих соблазнительных, но пока сильно экспериментальных вещей я никогда не ратовал. Спека большая, можно брать из нее те части, котороые лучше устоялись и лучше отвечают текущим практическим запросам — прагматично, без фанатизма (а там и не заметишь, как и другие части подтянутся). Просто остальные спеки, как правило, отвечают этим запросам еще хуже...

Браузеры вообще по жизни работали не по спецификации, а по "здравому смыслу" разработчиков. Который к тому же менялся. Только сейчас ситуация меняется, но и то лишь потому, что авторы спеки перешли на позицию "что вижу, то пою документирую". В FF2 вообще вкладывать что-либо блочное в "незнакомые" теги можно было только в application/xhtml+xml. В FF3, насколько я понимаю, сделали некий компромисс — грубо говоря, если первый же потомок строчного/непонятного очевидно блочный, то со скрипом натянуть это строчное/непонятное на него, а если нет (потомок тоже строчный/непонятный) — действовать, как привыкли. В Опере, по-моему, по большому счету тоже, хотя и чуть "поинтеллектуальнее" (когда-то натыкался на обсуждение этого "новшества" мозилловцами, но сейчас сходу не нашел — видимо, затерялось за давностью)... Так что лично я бы в проектах для серьезного заказчика™ с новыми тегами чуть повременил, вынужденно довольствуясь добрыми старыми дивами с соотв. классами (как когда-то HTML5-доктора советовали). Еще месяца три хотя бы. Зато уже к концу года браузеры с новым парсером составят не менее 70% рынка, и наступит всем счастье!

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

Для не очень новых парсеров де-факто тоже (при text/html). Именно потому разрешили, что браузеры поддерживали и поддерживают. А поддерживают, по сути, потому, что не используют SGML-грамматику. Т.е. легендарная "HTML-совместимость" XHTML 1.0 все эти годы держалась на... неполной (формально) поддержке браузерами HTML 4.0, такой вот парадокс Упс, чуть не пропустил... Особыми секретными подробностями я сам не владею. Но в общих чертах — алгоритм парсинга описан в 11-й главе "живой спеки" (нудно, но достаточно подробно), алгоритм писался с оглядкой на некое "усредненное" поведение реальных браузеров (в т.ч. в нештатных ситуациях типа <b><i></b></i>). И где-то в 2007-м году Генри Сивонен (по совместительству один из разработчиков FF и участник WHATWG, если я ничего не путаю) написал реализацию этого алгоритма, которая и лежит в основе validator.nu (а оттуда ее позаимствовал и validator.w3.org). И мало-помалу эту реализацию дорабатывает. В ранних FF3.6 этот парсер уже был как опция, но глючил, потом его убрали, а к 4-й версии Генри довел его до ума. Этот парсер доступен и отдельно. Его дополнительные плюшки — возможность работать с отпарсенной структурой как с XML-ным деревом (XPath, внедрение других неймспейсов — SVG и MathML, и еще что-то). Так что этот парсер можно юзать и для анализаторов существующих страниц. У новых Вебкитов, если я правильно смог разобраться, реализация алгоритма своя, но они стараются делать ее совместимой (тесты, которые которые мозилловцы и эппловцы сообща накидали, оба парсера проходят вроде как одинаково).

Чаво, пардон? Дописать к ссылкам, ведущим на эту страницу, "решетку" и этот самый ID.

И не надо. Зато бихевиоры будут, если поговорить с ними "по-взрослому" (подробности по ссылке выше)

swetlana, а можно пример, где article и section по-разному ведут себя в этом плане? В теории, насколько я могу судить, до прихода нового парсера они должны интерпретироваться одинаково — как аналоги <span>... Если не ошибаюсь, он по крайней мере идентичен парсеру из HTML5-валидатора (точнее, он самый и есть). Так что крут или нет, а другим теперь волей-неволей придется равняться именно на него...

Через месяц-другой этому безобразию конец. Нынешний RC FF4 неофициально признали де-факто релизом, так что официальный выход буквально на носу, обновляется FF быстро. И новый парсер зохватит мир!

Имхо, нет. А вообще лучше у автора спросить — он тут бывает

Есть шаманство типа такого. Но надо проверять в 9-ке...

Причем, как выяснилось, наиболее избирательный хак. Надо же, до сего дня я был уверен, что это синоним *+html...

Рендеринг — процесс отрисовки страницы. Инструменты — Developer Tools (те, что по F12) плюс интуитивная догадка (смотрел на перекрытие рамок соседних пунктов и чесал репу, чему именно такой сдвиг может соответствовать, потом попробовал поредактировать текст ссылки — догадка подтвердилась)...

С точки зрения валидации — да. С точки зрения браузеров — скорее, в mime-тип. Это же закреплено в новом "живом стандарте": при text/html любой доктайп должен парситься по правилам HTML5 с опциональными тегами, при что-то/что-то+xml — любой доктайп, хоть никакого, парсится как XML. Меня ткнули носом на Хабре. Я долго не верил...

Верстальщики-то знают. А вот браузеры...

У уважающих себя ЦМС, по-моему, бывает опция "выдавать генерируемый код в одну строку для экономии трафика и вообще". Если речь о собственном шаблоне, его тоже всегда можно подправить, чтобы элементы шли подряд без зазоров. При автоматической генерации, имхо, проблема как раз менее актуальна. А насчет опаски, после знакомства с вышеупомянутым багом IE7-, я как раз стал с опаской относиться к закрывающим тегам (где они опциональны) — как к источнику потенциальной неоднозначности (на практике, в теории-то должно быть наоборот)...

Неправильно только с точки зрения синтаксиса XML, поэтому неприменимо в XHTML (настоящем). Семантике пофигу (в чем-то даже чуточку лучше — меньше незначащей разметки), браузерам, при типе контента text/html, тоже. Плюс единообразие с IE7- (он закрывающие </li> в любом случае игнорирует). Практических минусов, честно говоря, не вижу...

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

Да чего там показывать? Просто не закрывать <li> явно... <ul> <li> <h3>Inline-block</h3> <p>Удобная вещь, но с нюансами.</p> <li> <h3>Float</h3> <p>Старый проверенный метод, но требует подпорок.</p> <li> <h3>Table/table-cell</h3> <p>Блок никуда не убежит, но ширина тоже может скукожиться.</p> </ul>

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