В четвёртом выпуске «говорильного подкаста» говорим с техдиректором «Аймобилки» Сергеем Чикуёнком про ХТМЛ 5, Флеш, ИЕ6 и веб-разработку вообще.

Среди затронутых тем:

• ХТМЛ 5 — круто ли это? Почему так долго? Как стандарты отстают от жизни.
• Валидность и чистота кода. Ценность валидного кода против ценности хорошего сайта. Как донести до любителя валидности, что это не важно? А может быть невалидный код — признак неряшливости разработчика? Как спецификация и валидатор по-разному понимают стандарты. Закрывать ли теги, брать ли атрибуты в кавычки — не технический вопрос, а дело вкуса. Когда валидность и функциональность вступают в противоречие.
• Флеш, какова его роль в вебе? Флеш и видео, кодеки, в чём природа спора, и почему не получается уже договориться. Обсуждаем появившиеся в последнее время весёлые демки, когда видео взаимодействует с остальной страницей.
• Аджакс и ИЕ, история вопроса. Сергей рассказывает о том, какой крутой браузер ИЕ6 (не шутка). Куча всего появилась в ИЕ6 раньше, чем где-либо, а через годы это записали в стандарты, но по-другому. Виноват ли в этом ИЕ?
• Гугль и все другие крутые компании перестали поддерживать ИЕ6. Правда ли это? Оказывается, нет, но плохие веб-разработчики используют непонимание людьми этих анонсов, чтобы не поддерживать ИЕ6. Подавляющее большинство пользователей ИЕ6 не меняют браузер, потому что не могут, а не потому, что не хотят. Одно из достижений ИЕ6 — победа над идиотской бокс-моделью В3Ц. Пользователи ИЕ6 охотнее расстаются с деньгами, поэтому не поддерживать ИЕ6 невыгодно.
• Мы как разработчики очень любим Вебкит!

Слушать прямо тут

Скачать выпуск можно на Арподе (или по прямой ссылке), там же можно подписаться на подкаст. Разговаривали мы часа два, но я оставил от этого традиционные 50 с небольшим минут.

Кстати, с кем и про что, на ваш взгляд, ещё нужно поговорить?

На блоге WHAT WG — о том, почему атрибут alt перестал быть обязательным в HTML 5.

Если коротко, смысл в том, что иногда картинки являются контентом сами по себе до такой степени, что просмотр страницы без картинок или чтение её голосом совершенно лишены смысла. В самой спецификации, что удивительно, сформулировано лучше, чем в статье:

In certain rare cases, the image is simply a critical part of the content, and there might even be no alternative text available. This could be the case, for instance, in a photo gallery, where a user has uploaded 3000 photos from a vacation trip, without providing any descriptions of the images. The images are the whole point of the pages containing them.

Если что, HTML 5 вовсе не пропагандирует отказ от альта, а лишь предлагает отказаться от механических бессмысленных альтов в пользу их отсутствия в тех случаях, когда осмысленные альты в принципе неоткуда взять.

Анне Ван Кестерен опубликовал описание ключевых отличий HTML 5 от HTML 4. Среди приятных мелочей:

[The new element] article represents an independent piece of content of a document, such as a blog entry or newspaper article.

The a and area elements have a new attribute called ping that specifies a space separated list of URIs which have to be pinged when the hyperlink is followed.

A new autofocus attribute can be specified on the input (except when the type attribute is hidden), select, textarea and button elements. It provides a declarative way to focus a form control during page load.

The new required attribute applies to input […] and textarea. It indicates that the user has to fill in a value in order to submit the form.

You can now disable an entire fieldset by using the disabled attribute on it.

The input element has a bunch of other new attributes to specify contraints: autocomplete, min, max, pattern and step.

The style element has a new scoped attribute which can be used to enable scoped style sheets. Style rules within such a style element only apply to the local tree.

The draggable attribute [on any element] can be used together with the new drag & drop API.

The menu element is redefined to be useful for actual menus.

HTML5 has none of the presentational attributes that were in HTML4 (including cellpadding and cellspacing).

getElementsByClassName() to select elements by their class name.

innerHTML as an easy way to parse and serialize an HTML or XML document. This attribute was previously only available on HTMLElement in web browsers and not part of any standard.

activeElement and hasFocus to determine which element is currently focused and whether the Document has focus respectively.

classList is a convenient accessor for className and the object it returns exposes methods, such as has(), add(), remove() and toggle().

Что ж, ждём имплементации. Думаю, в Опере 9.5 многое из этого будет реализовано. Какие-то из фич, связанных с формами, кажется, уже есть.

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

Для нижних и верхних индексов в ХТМЛе есть элементы sub и sup. К сожалению, при использовании их в тексте равенство высот строк ломается, и образуются неприятные дыры:



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

Элементы sub и sup для выравнивания используют свойство vertical-align со значениями sub или super. Именно они и влияют на высоту строки. Стало быть, нам нужно вместо них использовать какой-нибудь vertical-align, оставляющий строку прежней высоты, и сдвигать индексы иным способом, например, с помощью position: relative.

Я уже давно почти везде использую примерно вот такую конструкцию:

sup, sub {
  vertical-align: middle;
  position: relative;
  font-size: 75%;
}
sup { bottom: 0.5em; }
sub { top: 0.5em; }

В результате получается нормальный текст:

Наверное об этом уже писали, но почему-то очень многие никак не хотят понять. Поэтому я напишу тоже. Вдруг, мало ли.

Итак, распространённая точка зрения: «Wiki-синтаксис придумали для тех, кто не знает HTML, чтобы им проще было. Но я-то знаю HTML, зачем мне тратить время на то, чтобы учить Wiki? Я буду пользоваться HTML».

На самом деле Wiki придумали те, и для тех, кто знает HTML и сыт им по горло. Для тех, кто хочет просто спокойно писать, и выделять нужные слова курсивом, а ненужные — зачёркивать. Для тех, кто не хочет переключать ракладки клавиатуры каждый раз на английский только для того, чтобы вставить чёртовы угловые скобки, которые, к тому же, нужно нажимать с Shift’ом. Для тех, кто не хочет писать по миллиону тегов ради простой таблицы:

Таблица	Число HTML-тегов	Вероятность забыть, про что таблица
2×2	14	25%
3×4	34	75%
4×10	миллион	150%

...Или простого списка:

• Чтобы сделать список на HTML, нужно заключить его в <ul></ul> или <ol></ol>
• Каждую строку списка нужно заключить в <li></li>
• Полученную кашу абсолютно невозможно читать, особенно когда начинается word wrap
• Добавить в список ещё одну строку будет трудно, если вы вдруг закрыли li и ul на одной строке

А теперь попробуйте открыть блокнот и набрать следующую строчку:

<a href="http://yandex.ru">Ссылка на <i>Яндекс</i></a>

Сколько секунд у вас это заняло? Сколько раз вы переключили раскладку клавиатуры? Сколько раз вы нажали backspace? Сколько нервов вы потратили?

Некоторые люди будут всю жизнь тратить на то, чтобы писать заметки в блоге на HTML вместо того, чтобы потратить 1 минуту и понять вики. «Выучить вики» звучит даже как-то глупо, примерно как выучить правила игры в «крестики нолики».

Есть ещё совсем странный аргумент против Wiki-синтаксиса — недостаточная выразительность. Дескать, на HTML можно больше всего сделать, чем на Wiki. Люди, опомнитесь, зачем вам супер-богатые возможности разметки, когда вы пишете заметку в блог? Чего именно вам не хватает в Wiki?

...А верстать на нём сайты никто и не предлагает.

The Daily WTF:

I’ve always felt that seeing the words HTML Programmer on a resume tell quite a bit about the candidate (for a programmer job). I can somewhat understand inflating your «skillset» with items like HTML, typing, breathing, etc; recruiters like to see those. But for a «programmer» to consider markup using a few angle-brackets as «programming» that... well... shows a lot. But after seeing how Mike Jervis’ colleague programs HTML, maybe I was thinking about thinking about it the wrong way...

По-русски:

Мне всегда казалось, что термин HTML-программист в резюме говорит о кандидате достаточно много (если он хочет получить работу программиста). Можно, конечно, понять людей, которые указывают в резюме такие свои навыки как HTML, умение печатать, дышать, и так далее — агентам по найму это нравится. Но если «программист» считает разметку с помощью нескольких угловых скобок «программированием»... ну... это о многом говорит. Однако, когда я увидел, как коллега Майка Джервиса программирует на HTML, я подумал, что, может быть, я и зря так рассуждал на эту тему...

Продолжение.

I was trying to work out why parts of this website would appear as blank pages [in Opera]. It turns out they employ something called «HTML Protector» to make the source code unreadable.

Забавно, что только не продают дуракам (я про этот HTML Protector).

Всего сутки отладки — и я вкурсе, что под Mozilla у форм, находящихся в <iframe style="display: none"> не работает метод submit (). Никаких предупреждений об ошибках, никаких записей в javaScript Console. Просто всё работает так, как будто метод submit () в том и заключается, чтобы ничего не делать. Bah.

(Mozilla Firefox 0.9.2)

Update: Да, безопасность на уровне, особенно учитывая, что тупая замена display: none на border: 0; width: 0; height: 0 решает проблему.

Давно думаю, что часто табличная вёрстка лучше, чем CSS, даже если и ты, и браузеры его очень хорошо знаете.

Насколько я понимаю, табличная вёрстка deprecated в связи с тем, что таблицы, вроде как, не для этого придумали, а для таблиц: там, дебет — кредит. И, разумеется, это правильно — избавляться от таблиц в качестве элементов вёрстки. Точно так же, как правильно избавляться от <p></p><p></p> или, например <br /><br /><br /> в качестве отступов.

Тем не менее, идеология табличной вёрстки хороша и даже, как я уже сказал, часто работает лучше CSS. Мне кажется, что был бы весьма полезен элемент типа <mt> (markup table), который работает так же, как <table>, но а) никогда не рассматривается как смысловая таблица, и б) не имеет никаких зашитых в браузер стилей отображения.

Например, есть у нас <p>, а есть <div>. Они почти одинаковые, только <div> не несёт смысловой нагрузки и не имеет полей. Вот был бы <mt>, у которого нет полей, cellspacing’а и прочего cellpadding’а — жизнь была бы в радость.

А ещё Мозилла рендерит одну и ту же страницу по-разному, в зависимости от того, где находилась полоса прокрутки в момент нажатия F5. По-моему, такого поведения можно добиться, только если целенаправленно его запрограммировать...

Вопрос по существу. Стандарты не позволяют выровнять элемент по нижнему краю страницы либо экрана, в зависимости от того, что из этого выше. Однако табличная вёрстка с такой задачей с успехом справлялась, когда table height="100%". Вроде бы, справляется она и сейчас: я делаю 100% таблицу из двух ячеек, одна под другой; внутри верхней делаю всё то, что должно быть на странице, используя нормальную CSS-вёрстку, а внутри нижней пишу копирайты и всё, что нужно.

Как это всегда у меня и бывает, всё это отлично работает и в IE, и в Opera, и даже в Netscape 7, а в Mozilla и Firefox работать не хочет. Самое смешное, что совсем недавно я делал другую страницу ровно по тому же принципу, и она-таки работала везде.

Кто знает надёжное решение этой проблемы?

Update: немного перекроил дивы — стало работать.

XHTML 2.0 — оказывается и такое бывает

Вот здесь календарь наезжает на Шарапову.

Календарь — это <div class="right_calendar">:

div.right_calendar {
  position: absolute;
  top: -100px;
  left: 60%;
  width: 40%;
}

Если его просто убрать из HTML, то надпись «Мария Шарапова выиграла Wimbledon» смещается чуть ниже — как раз туда, где она должны быть, чтобы не пересекаться с календарём. Если вернуть, надпись поднимается выше пикселей на 30. Эффект наблюдается в IE 6 и Netscape 7. В Опере, естественно, не наблюдается. С каких пор у нас абсолютно позиционированные элементы affect normal flow? Кто умный, как сделать, чтобы не сползало?

Если сначала написать link и привязать stylesheet к страничке, а потом base href, который указывает на ту папку, относительно которой stylesheet, то stylesheet не загрузится. Нужно сначала base href, а потом link писать.

(Opera 7.50 Final)

Я вот подумал, что невалидные исходники кругом потому, что неправильно HTML преподают. Людям рассказывают про тэги, про то, что сначала пишется <html>, потом <head> и люди запоминают это просто как строчки. Если одну строчку забыл — браузеру всё равно, он добрый. Вот и получаются незакрытые тэги и обломки таблиц.

Однажды я видел даже такое:
<h1></b>Заголовок</h1>

Имеется в виду следующее. По умолчанию h1 жирный, а нам нужен обычный. Поэтому мы пишем «выключить жирность».

Люди не видят за тэгами элементов.

Я считаю, что сегодня нужно начинать обучать HTMLу c объяснения XML. Рисовать дерево, а не писать исходник. Говорить, какие элементы бывают, и какой у них смысл. Что такое node, attribute и #PCDATA. Как такое дерево описывает страницу.

А потом уже говорить, как оно выглядит в файле с расширением HTML.

(Кто напишет в комментариях, что у меня невалидный исходник, тот дурак.)