SelenIT

Так и должно быть по стандарту. С норм. доктайпом в IE будет так же.

Ого как. Спасибо за поправку! Но всё равно, имхо, такая логика попахивает побочным эффектом какой-то внутренней "оптимизации". На MSDN я упоминания о такой особенности createElement не нашел (может, плохо искал).

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

http://css-live.ru/articles/plany-dokumentov.html (см. в конце).

Абсолютно нормально. Никаких противопоказаний я не вижу и нигде не встречал. Единственное, от чего спека прямо предостерегает — не надо добавлять эти элементы только для оформления. Если без доп. элемента для этих целей совсем никак, лучше использовать старый добрый <div>.

Поддержка XML тут ни при чем (кстати, она в IE5+ есть, это у application/xhtml+xml нет поддержки, а при */xml не применяется CSS, подключенный не через <?xml stylesheet?>). Это именно самовольство IEшного алгоритма парсинга HTML (впрочем, насколько я понимаю, формально не нарушающее спеку HTML 4). А стилизация «незнакомцев» после соотв. createElement очень сильно смахивает на недокументированную особенность реализации самого createElement-а в IE.

Ну так IE7 и никак не назвать новым браузером... да и IE8 уже тоже Но рендеринг — отдельная тема. Рендерятся и Strict с Transitional чуть по-разному. А парсинг, да, в IE (особенно старых) самый специфический.

При отдаче как text/html странички с любым Strict-доктайпом HTML 4.x/XHTML 1.x либо HTML5-доктайпом каждый браузер парсит и рендерит одинаково. Старые браузеры — как "исторически захардкодано", новые — по алгоритму из спеки HTML5 (во многом основанного на изучении работы старых, ради максимальной совместимости). Между стандартным режимом и Quirks mode у некоторых браузеров бывали различия при парсинге (напр. тот же IE в Quirks mode позволял вкладывать в <p> таблицу, а какая-то Мозилла, ЕМНИП, по-разному реагировала на двойной дефис в комментариях), но это редкие и не принципиальные исключения. Фичу с "частичной поддержкой выборочных неймспейсов" для нового алгоритма, насколько я понимаю, позаимствовали как раз у IE, из его манеры встраивать в HTML-разметку VML-графику (хотя детально я вопрос не изучал, но на беглый взгляд очень похоже).

Функционально эти доктайпы эквивалентны (более того, для HTML5 они оба валидны!). Парсер не в доктайпе, а в браузере. Если он совсем не понимает неймспейсов — он не поймет их с любым доктайпом (при text/html). Если понимает выборочно (для VML в IE5.5+ или для SVG и MathML в новых браузерах) — то опять же с любым доктайпом он будет раскидывать знакомые элементы по знакомым неймспейсам, а любые незнакомые (даже с двоеточием в имени) сваливать в дефолтный (как велит ныне узаконенный алгоритм парсинга).

Возможно, речь о чем-то таком (рядом с минусом): Хотя лично я для набора длинного тире поступаю по старой ламерской привычке — жму Alt+0151...

rus, это официально разрешено.

В плане оформления HTML5 практически ничего нового не добавил. Новые структурные элементы — не для оформления, а для логического структурирования страницы (ну и поддерживать такой код проще, в </footer></section></article> сразу видно, где какая часть кончается, в отличие от безликих </div></div></div>). Для оформления всё осталось по-старому — классы и CSS.

NeoXidizer, позицию я понял. И даже где-то готов согласиться с ней, если речь о сверхдинамичном веб-приложении, где все действия имеют примерно один и тот же смысл, причем исключительно "здесь и сейчас" (класть в букмарки или отсылать другу нечего). Но для классических сайтов остаюсь при своём мнении. Почему тогда не <span>? Он тоже не является "блочным элементом" (впрочем, <input> с button-ом — тоже, ну да ладно), его размером управлять не сложнее, чем размером <a>, браузеры задают ему еще меньше специфичных стилей, чем <a> (цвет, подчеркивание и т.п.), и в onclick-е для него нужно писать на целый "; return false" меньше. Плюс при отключенном JS (да, редкость, но бывает — у аддона NoScript для FF более 2 млн. юзеров) такая кнопка не делает ничего (не помогает, но и не мешает), а кнопка из <a> дает сбивающий с толку прыжок к началу страницы. Вот что меня удивляет. Я бы еще понял, если бы в href кноп ссылки в форме поиска тем же скриптом подставлялся адрес будущего результата (как в поиске по картинкам и т.п. на Яндексе), тогда кнопка будет полноценной и полноправной ссылкой. Но ведь так делают единицы. Вообще-то эта "прихоть" называется доступностью (accessibility). И дает реальный плюс в виде экономии запроса (и, соответственно, ускорения отклика формы вдвое) в Опере Мини, где JS выполняется на сервере (и доля которой в Рунете больше суммы всех старых IE). Да и просто здравый смысл — использовать для разных (хотя и похожих) задач специально предназначенные для них инструменты. А не забивать гвозди отверткой (хотя гвозди и шурупы выполняют одно предназначение — скреплять детали), потому что мастер к отвертке привык и из прихоти "не хочет разнообразить работу" [/сарказм]. Конечно, любые крайности и слепой фанатизм в любую сторону — зло, тут я согласен. Но в любой ситуации нужно исходить именно что не из "прихоти разработчика" (как ему проще, привычнее и приятнее), а прежде всего из специфики задачи — со всеми ее нюансами. И руководствоваться здравым смыслом и заботой о пользователе (а не прикрываться "заботой" о нем).

Есть еще такой подход.

Почему же тогда кнопки на мышке (или тачпаде) не имеют вид кнопок (имхо, даже клавиш) клавиатуры? Ведь тоже выполняют одно действие — отправку некой информации приложению по нажатию? Пользователю было бы удобнее и привычнее видеть одинаковые нажимаемые элементы, логично? Или всё-таки на каком-то уровне абстракции уместно остановиться? Например, что кнопки клавиатуры выполняют одинаковое преднозначение — ввод (хоть и разных объектов — букв и цифр), а кнопки мышки выполняют другое действие — выбор объекта по указанным координатам? Как и ссылки выполняют одно действие — переход (хоть и по разным адресам), а кнопки формы — другое (подтверждение ввода), и неплохо бы, чтобы это функциональное различие было очевидно для юзера (как разница между клавиатурой и мышкой)? Все перечисленные действия однотипны и действительно являются ссылками по смыслу. Поэтому <a href="..."> в едином оформлении для них уместно и правильно. Но на этой странице есть еще одна кнопка, выполняющая совсем другую задачу и — внимание — оформленная совсем по-другому. Это кнопка в форме поиска. Она не ведет ни на какой определенный URL, класть ее в закладки бессмысленно и бесполезно. Чего ж ради ее оформили через <a id="store_search_link" onclick="var form = $(this).up('form'); if ( form.onsubmit() ) form.submit(); return false;" href="#"> <img src="http://cdn.store.steampowered.com/public/images/blank.gif"> </a>кому какой в этом толк и профит?

Если именно ссылка, ведущая на URL (что я наблюдаю в примерах), которую можно кинуть в закладки, открыть в новом табе и т.п. — никаких вопросов, естественно, странно было бы видеть тут что-то другое, кроме <a> . Недоумение у меня вызывают мутанты с href="javascript:void(0)" (и то в относительно лучшем случае) в качестве весьма далеких от ссылок вещей — типа той же сабмитилки формы. Вот хоть убей не могу согласиться, что логическое предназначение ссылки (со всеми ее специфичными ссылочными радостями, см. выше) и кнопки отправки формы (которая не имеет смысла в отрыве от формы и вводимых в нее данных) одинаково. Вот единообразие оформления — аргумент, согласен (хотя тут возникает вопрос к дизайнерам — зачем делать такие функционально разные элементы визуально одинаковыми). Получается, основная причина — сложность кроссбраузерной стилизации нативных кнопок и лень/неопытность верстальщиков в таковой? Или я в упор не вижу еще чего-то очевидного?

А зря . Книжка книжкой, а сама спецификация понемногу правится и уточняется, не говоря о ее трактовках...

<div> + javascript + нестандартное оформление, при условии, что всё это великолепие скриптом и навешивается — понимаю и принимаю. Но <a>-то зачем, объясните наконец мне слоупоку?

Есть еще варианты в виде <button> и <input type="image">. А ссылка — совсем не вариант.

У 4-го айфона с точки зрения CSS (включая media queries для width/height) разрешение такое же, как у предшественников — 320?480. Просто шрифты рисуются вдвое четче (и, потенциально, уменьшенные картинки тоже). Сузить экран десктопного Сафари до таких размеров — имхо, да, даст близкое представление об отображении в айфоне, если для страницы задать <meta name="viewport" content="width=320">. Но вообще, боюсь, статью (можно в переводе) поизучать всё-таки придется — нюансов там действительно много...

Clearfix тоже может давать проблемы, типа ненужной зависимости от других колонок. Имхо, отдельный контекст всё-таки как-то понадежнее. Проблема с выпадушками возникает только если у контейнера впридачу к overflow стоит position:relative (по крайней мере в стандартных браузерах). Имхо, тут вопрос достаточно холиворный, может есть смысл обсудить его отдельно?

Всё-таки не "ни за что ни про что", а за не совсем адекватную (имхо) реакцию на указание на орфогр. ошибку. И ну о-очень косвенно

Можно пруф? Вероятно, что-то типа этого. Хотя тамошние небредовые ограничения куда объемистее. По мне, ставить пустой alt всё-таки как-то спокойнее (может, до сих пор под влиянием пионерской страшилки начала 2000-х про черные-черные браузеры, которые при отсутствии alt выводят на его месте адрес картинки...), хотя умом я всецело за прогресс и против ненужного хлама

Есть еще похожая с персонажами "Звездных войн", но версия Стандартисты (Эстель Вейл) полнее и, на мой взгляд, лучше отражает масштабы

Не "почему-то", а по причине более высокой специфичности...