С приходом HTML5, принесшим с собой новые элементы, возникла нужда в адаптации CSS-ресета. Что и было сделано. На сайте html5doctor.com опубликована адаптированая под нужды HTML5 версия CSS-ресета от Eric Mayer. Вот она:

/*
html5doctor.com Reset Stylesheet
v1.6
Last Updated: 2010-08-18
Author: Richard Clark - http://richclarkdesign.com
Twitter: @rich_clark
*/

html, body, div, span, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
abbr, address, cite, code,
del, dfn, em, img, ins, kbd, q, samp,
small, strong, sub, sup, var,
b, i,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, figcaption, figure,
footer, header, hgroup, menu, nav, section, summary,
time, mark, audio, video {
    margin:0;
    padding:0;
    border:0;
    outline:0;
    font-size:100%;
    vertical-align:baseline;
    background:transparent;
}

body {
    line-height:1;
}

article,aside,details,figcaption,figure,
footer,header,hgroup,menu,nav,section {
    display:block;
}

nav ul {
    list-style:none;
}

blockquote, q {
    quotes:none;
}

blockquote:before, blockquote:after,
q:before, q:after {
    content:'';
    content:none;
}

a {
    margin:0;
    padding:0;
    font-size:100%;
    vertical-align:baseline;
    background:transparent;
}

/* change colours to suit your needs */
ins {
    background-color:#ff9;
    color:#000;
    text-decoration:none;
}

/* change colours to suit your needs */
mark {
    background-color:#ff9;
    color:#000;
    font-style:italic;
    font-weight:bold;
}

del {
    text-decoration: line-through;
}

abbr[title], dfn[title] {
    border-bottom:1px dotted inherit;
    cursor:help;
}

table {
    border-collapse:collapse;
    border-spacing:0;
}

/* change border colour to suit your needs */
hr {
    display:block;
    height:1px;
    border:0;
    border-top:1px solid #cccccc;
    margin:1em 0;
    padding:0;
}

input, select {
    vertical-align:middle;
}

Что нового в адаптированой версии?

Сначала автор удалил нежелательные в HTML5 элементы, такие как acronym, center, и big. Затем добавил новые элементы из HTML5, чтобы обнулить их дефолтные значения и прописал свойство display: block; для тех из них, которые должны рендериться как блочные элементы.

Свойство outline: 0; на событии :focus тоже было удалено из ресета, так как автор адаптированой версии считает что уж лучше дефолтное выделение на событии :focus, чем никакого. Я склонен согласиться с этим мнением. Дело в том, что Eric Mayer добавил это свойство в CSS-ресет в надежде на то, что разработчики будут описывать его сами. По факту этого не происходит или происходит редко. Поэтому уж лучше дефолтное выделение.

В ресет добавлены стили для нового элемента mark, созданного для маркировки текста в контексте. Мне не совсем ясно почему автор выбрал именно те стили и свойства, которые он выбрал, так что обращаю на это ваше внимание.

Адаптированый ресет распространяется с лицензией Creative Commons, так что его можно использовать в персональных и коммерческих проектах. Можно скачать с Google Code.

Послесловие

Этот CSS-ресет ни в коем случае не претендует быть окончательным и истиной в высшей инстанции. Мне например не ясно зачем автор добавил в ресет следующие свойства:

a {
    margin:0;
    padding:0;
    font-size:100%;
    vertical-align:baseline;
    background:transparent;
}

Этот ресет можно использовать как заготовку для написания собственного, с учетом HTML5.

Дерзайте, делитесь результатами.

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

Проблема в том, что стандарт еще не доработан, большинство “вкусностей” еще впереди, хочется верить. Ну и как обычно, Internet Explorer не поддерживает фактически ничего из этого стандарта. Да что там фактически, ничего. Даже отрисовку элементов из HTML5 приходится задавать через Javascript.

До недавнего времени было довольно сложно валидировать документы на HTML5, так как валидаторы плевались на DOCTYPE без ссылки на DTD.

DOCTYPE HTML5:

<!DOCTYPE html>

Существовал только один HTML5 валидатор, да и тот в разработке.

На данный момент этот валидатор все еще находится в разработке, но работает уже довольно корректно. Помимо этого, валидатор всех валидаторов от отцов из W3C уже поддерживает валидацию HTML5, не без помощи Mozilla Foundation. Появилось расширение для Firefox.

Так что можете смело пробовать себя, учиться, смотреть примеры и создавать что-то свое.

Скачать и установить Internet Explorer 9 Platform Preview можно на специальной странице. На ней же можно посмотреть на демки поддержки HTML5, CSS3 и SVG(!).

Устaнавливать эту сборку можно не опасаясь, она не имеет никакого отношения к Интернет Эксплореру, установленому на вашей системе. Минимальные требования для установки — Windows Vista SP2 и выше. Видимо и с релизом будет так же.

Из интересных вещей стоит отметить высокую скорость рендеринга и поддержку некоторых аспектов CSS3 и HTML5. Поддерживается свойство border-radius и CSS3 селекторы. Поддерживается тег video на http://youtube.com. Фильтры из предыдущих версий IE не поддерживаются.

Поддержка CSS3 пока что на невысоком уровне, по крайней мере если смотреть на http://css3please.com. Более того, замечены глюки с некоторыми свойствами и псевдоклассами из CSS2, например :first-letter. Тем не менее, мне кажется что направление выбрано правильное и результаты не заставят себя ждать. Уже то, что в Microsoft поняли, что цикл разработки продукта не может продолжаться 6 лет, уже о чем-то да говорит.

С одной стороны радостно от того, что все участники “гонки вооружений” скоро обзаведутся современными браузерами, а с другой грустно от того что зоопарк только ширится.

IE 6/7/8/9, Firefox 3.6, Opera 10.5, Safari 4, Chrome 4 – уже 8 браузеров, это не говоря о мобильных. У верстальщиков всегда будет хлеб. С маслом.

1. Быстрое решение:

.ie8only { color /*\**/: #fff\9 }

Работает только в Standards Mode

2. Более разумный подход к вопросу:

В файле стилей для IE, подключеном через условный комментарий создаем такую структуру:

html>/**/body #id { property: value; }

Почему именно в отдельном файле? Потому что такую конструкцию прочтут все современные браузеры, включая IE8. Нужно помнить, что в таком случае все остальные хаки, предназначеные для IE6/7, должны быть прописаны через их собственные специфичные хаки (тогда IE8 ничего не заподозрит):

• IE 6 — * html
• IE 7 — *+html

Это детище мелкомягких, срок выдержки которого поболее чем у лучших коньяков, не желает становиться лучше с годами (видимо надо было хранить в дубовых бочках). И нам, веб-разработчикам, приходится с этим мириться. Количество версий Интернет Эксплорера, которые надо поддерживать – растет, и эпопея эта затянулась. Со времени выхода 7-ой и 8-ой версии Интернет Эксплорера появилось несколько утилит, позволяющих тестировать верстку в нескольких версиях IE одновременно.

Вот скромный список вариантов “борьбы” с Интернет Эксплорером:

• Multiple IE
• IE Tester
• IE Collection
• Виртуальные машины
• Выйти на пенсию

А теперь немного подробнее:

Multiple IE. Живет это зверь здесь. Вернее жил. На данный момент проект закрыт и не поддерживается, но утилита доступна для скачивания и более-менее функцию свою выполняет. Тем не менее я решил отказаться от ее использования из-за того что она стала “привирать” а иногда откровенно глючить. Кроме того, появились более удачные “конкуренты”.

IE Tester. Ребята из DebugBar пошли дальше и создали утилиту, позволяющую иметь одновременно установленными 5.5, 6, 7 и 8 версии Интернет Эксплорера одновременно, с собственными javascript-движками. Причем выполнено это все в виде одного браузера, в каждой отдельной вкладке которого можно открыть нужную вам версию IE. Программа работает как в ХРюне, так и в Висте. Интерфейс правда немного подкачал, ибо выглядит как китайский MS Office 2007, но это не главное.

По большому счету, на этом можно было бы и остановиться, но. При ежедневном ее использовании на Windows XP, были обнаружены некоторые странности:

• Иногда не подхватываются стили из файла, вынесенного с помощью условных комментариев.
• Иногда вкладка с IE6 просто тихо умирает и не реагирует.
• Несколько раз замечены несоответствия отрисовки страницы в IE Tester и в IE6, установленном нативно.

Причем дома, на Windows Vista, таких проблем замечено не было. Вам решать. Двигаемся дальше.

IE Collection. Об этой утилите я узнал совершенно случайно недавно, в контексте беседы о разработке под IE. В ней на выбор предоставлены фактически ВСЕ версии IE:

• Internet Explorer 1.0 (4.40.308)
• Internet Explorer 1.5 (0.1.0.10)
• Internet Explorer 2.01 (2.01.046)
• Internet Explorer 3.0 (3.0.1152)
• Internet Explorer 4.01 (4.72.3110.0)
• Internet Explorer 5.01 (5.00.3314.2100)
• Internet Explorer 5.5 (5.51.4807.2300)
• Internet Explorer 6.0 (6.00.2800.1106)
• Internet Explorer 6.0 (6.00.2900.2180)
• Internet Explorer 7.0 (7.00.5730.13)
• Internet Explorer 8.0 (8.00.6001.18702)

Даже если принять во внимание, что первые шесть позиций в списке нужны только эстетствующим bdsm-щикам, а седьмая Яндексоидам, то все остальные очень нам подойдут. И все это чудо, начиная с 4-ой версии должно работать стабильно во всех ОСях Майкрософт, начиная с XP. На сайте есть таблица совместимости. Вроде бы “кричали женщины Ура и в воздух чепчики бросали”, но. Опять но. При попытке установить все это добро на Висту, инсталятор отказался выдать мне 7 и 8 версии IE. Ну 8 у меня и так есть, обойдусь. А вот с 7-ой как быть? Буду проверять с чем конфликтует.

Вот для таких “проблемных” как я, умные люди придумали виртуальные машины:

• Internet Explorer Application Compatibility VPC Image – мелкомягкое изделие, срок действия которого заканчивается 30 Апреля :) Не спрашивайте меня почему. Посмотрим какие цифры там будут стоять 1-ого Мая. Работает через Virtual PC, естественно на ХР и Висте.
• Virtualbox – кросс-платформенное решение, полноценная виртуальная машина, со всеми вытекающими. Из минусов – при отсутствии готовых образов придется создавать свои, с установкой и сексом.
• VMware Player – дублировать предыдущий абзац не буду. Читайте выше.

Я с виртуальными машинами работать не люблю. Не люблю и все тут. При открытом Фотошопе, полной кошелке браузеров, редакторе, файловом менеджере и еще каком нибудь плеере в фоне еще открыть две виртуальные машины? Увольте. Видимо мне пора на пенсию :) А вы сами решайте.

Речь в статье пойдет о такой, казалось бы изжеваной и изъезженой теме, как валидация веб-документа по одной из DTD-схем, которые в свою очередь определяются с помощью DOCTYPE.

Тема эта нетривиальна; преимущества и недостатки того или иного способа валидации на первый взгляд не всегда являются явными. Поэтому я решил что упомянуть о них еще раз будет не лишним.

В последнее время, многие редакторы и CMS’ки автоматически проставляют DOCTYPE для документа, что само по себе является прорывом, но к сожалению этого недостаточно, так как зачастую это именно Transitional схема. Начинающие разработчики не уделяют этому должного внимания, а зачастую вобще не подозревают что у них есть выбор.

Перед тем как перейти к самой сути вопроса давайте вспомним что такое Transitional схема. Она была создана как переходная, для облегчения перехода от HTML3.2 к HTML4, сохраняя унаследованые элементы и атрибуты.

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

Современная веб-разработка зиждется на трех китах – разметка (html/xhtml/xml), оформление (css) и функционал с эффектами (javascript). Причем акцент здесь приходится на четкое разделение между ними. Разметка является логическим разделением документа на семантические, смысловые составляющие. Стилевые правила, вынесеные в отдельный файл(ы), отвечают за оформление документа относительно устройств отображения. Скрипты, отвечающие за взаимодействие между документом и пользователем, а так же за эффекты, также вынесены в отдельные файлы. Смешение всех этих компонентов в одном документе считается моветоном и заметно усложняет жизнь веб-разработчика и порядочно увеличивает время загрузки и отображения документа браузером.

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

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

А что же собственно делать?Использовать Strict DTD — строгую, однозначную схему валидации документа, которая как раз создана для того чтобы отделить содержимое от стилей и скриптов. Как это сделать? Очень просто. В следующем вашем проекте просто поменяйте DOCTYPE на один из этих:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Кстати, W3C однозначно рекомендует использовать Strict.

“This is the HTML 4.01 Transitional DTD, which includes presentation attributes and elements that W3C expects to phase out as support for style sheets matures. Authors should use the Strict DTD when possible, but may use the Transitional DTD when support for presentation attribute and elements is required.”

Чего вы лишаетесь, переходя на строгую схему валидации:

Список запрещеных элементов: applet, basefont, center, dir, font, iframe, isindex, menu, noframes, s, strike, u

Список запрещеных атрибутов:

• Атрибут alink запрещен для body
• Атрибут background запрещен для body
• Атрибут bgcolor запрещен для body, table, td, th, tr
• Атрибут border запрещен для img, object, но может быть использован в < em>table
• Атрибут clear запрещен для br
• Атрибут language запрещен для script
• Атрибут link запрещен для body
• Атрибут name запрещен для form, img, но может быть использован в a, button, input, map, meta, object, param, select, textarea
• Атрибут noshade запрещен для hr
• Атрибут nowrap запрещен для td, th
• Атрибут start запрещен для ol
• Атрибут target запрещен для a, area, base, form, link
• Атрибут text запрещен для body
• Атрибут type запрещен для li, ol, ul, но может быть использован в a, button, input, link, object, param, script, style
• Атрибут value запрещен для li, но может быть использован в button, input, option, param
• Атрибут vlink запрещен для body

Структурные изменения: элементы a, abbr, acronym, b, bdo, big, br, button, cite, code, dfn, em, i, img, input, kbd, label, map, object, q, samp, select, small, span, strong, sub, sup, textarea, tt, var и текст не могут быть дочерними для blockquote, body, form, noscript. Другими словами – элементы blockquote, body, form, noscript могут иметь только блочные элементы в дочерних элементах первого уровня.

Отказ от атрибута target=”_blank” для ссылок. Во-первых, указывать пользователю на то, как и где открывать ссылку — не красиво. Во-вторых, если необходимо, это можно сделать простым способом и продвинутым.

Что вы приобретаете?

• Хорошо структурированую разметку
• Четкое отделение содержимого от оформления
• Возможность более быстрой и легкой работы и поддержки кода
• Дисциплину в написании кода
• Респект и уважуху ;)

Когда стоит использвать Transitional? Тут есть два основных момента. Переходная схема хороша, когда вы работаете с большим количеством чужого кода, поменять который не представляется возможным. Хороший пример — большинство CMS. В большинстве случаев невозможно изменить их код, не залезая в ядро, что автоматически исключает возможность обновлений.

Второй момент — использование iframe. Если вы используете в своих проектах iframe, то он не оставляет вам выбора. Используте Transitional.

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

Существуют различные методы визуального разграничения информации в таблицах для большего удобства восприятия. Такие как разделение строк таблицы различным цветом. Этот способ известен под названием “Полосатые таблицы“

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

Сейчас это конечно уже в прошлом, существуют решения с использованием JS, CSS3 и всевозможных js-фрэймворков. Мы их рассматривать сейчас не будем, благо поисковики никто не отменял.

Существует простое, кроссбраузерное решение, основаное только на HTML/CSS. А именно colgroup. Решение это совсем не ново, но почему-то незаслужено забыто многими разработчиками. Перейдем прямиком к разметке:

<table>
		<caption>Столбцы / колонки:</caption>
		<colgroup>
			<col />
			<col class="alt" />
			<col />
			<col class="alt" />
			<col />
		</colgroup>
		<tr>
			<th>FF2/3</th>
			<th>IE6/7</th>
			<th>Opera</th>
			<th>Safari</th>
			<th>Other</th>
		</tr>
		<tr>
			<td>Да</td>
			<td>Нет</td>
			<td>Да</td>
			<td>Нет</td>
			<td>Да</td>
		</tr>
		<tr>
			<td>Да</td>
			<td>Нет</td>
			<td>Да</td>
			<td>Нет</td>
			<td>Да</td>
		</tr>
		<tr>
			<td>Да</td>
			<td>Нет</td>
			<td>Да</td>
			<td>Нет</td>
			<td>Да</td>
		</tr>
		<tr>
			<td>Да</td>
			<td>Нет</td>
			<td>Да</td>
			<td>Нет</td>
			<td>Да</td>
		</tr>
	</table>

Чем этот код отличается от обычной разметки таблицы? Наличием тегов colgroup и col. Собственно colgroup является родительским контейнером для элементов col, которые и определяют нужные нам столбцы. Достаточно указать тому или иному столбцу класс и вуаля — у нас есть колонки, выделенные по вашему вкусу.

Вот так выглядит CSS:

table {
border: 1px solid #333;
border-collapse: collapse;
}
th, td {
padding: 2em;
text-align: center;
border-spacing: 1em;
}
th {
background: #ddd;
color: #fff;
}
/*Стиль для столбца*/
col.alt {
background: #ddf;
}

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

Проверено в FF2/3, IE6/7, Opera 9.5, Safari|(Win)

Список поддерживаемых стилевых правил. Спецификация.

Ситуация закономерная и соответствует развитию рынка мониторов и стремлениям дизайнеров/разработчиков. Я уже размышлял над этим год назад. Так вот, год спустя мои мысли приобрели немного другое направление.

Количество посетителей сайтов с разрешением 800х600 не только не уменьшится, а увеличится. Связано это напрямую с развитием субноутбуков, кпк, мобильников и прочих переносимых девайсов. Добрая половина субноутбуков уже сейчас имеет разрешение 1024х600, но сайт, оптимизированый под 1024х768, открытый на таком экране, в большинстве случаев будет неудобоваримым так как займет всё окно браузера. А в дизайне, как известно, важны пустоты.

Поэтому я предлагаю перестать игнорировать 800х600 и начать смотреть на этот вопрос под другим углом. Мне кажется разумным:

• Создавать отдельный файл стилей, оптимизированый под маленькие разрешения экрана, для всех мобильных устройств .
• С помощью PHP/JS создать функциональную возможность переключения файла стилей для владельцев настольных компьютеров с малым разрешением экрана.

Таким образом, мы убиваем одним выстрелом двух зайцев. У сайта появляется полноценная мобильная версия, и мы заботимся о посетителях с маленьким… разрешением.

Добавление файла стилей для мобильных устройств делается так:

<link rel="stylesheet" type="text/css" media="handheld" href="mobile.css" />

Про корректное оформление мобильной версии сайта можно почитать на старом добром ресурсе A List Apart.

Переключать стили можно с помощью JQuery вот так или так.

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

Часть первая.

Второй день конференции начался с жестокого похмелья доклада Nate Koechley под названием “Professional Front-End Engeneering”. Как Нэйт и обещал, он толкнул зажигательную речь о Front-End’е и его значении в веб-разработке. Особый упор был сделан на том, что Front-End веб-разработка по сути своей ни чем не отличается от архитектуры и поэтому отношение к ней, со стороны разработчика и его начальства не должно быть другим. Архитектор, проектируя здание, не позволяет себе махнуть рукой на то, что будет с домом через 5—10 лет, проект наполняется чертежами, схемами, документацией и тд. Так почему разработка сайтов должна отличаться?

Он призвал веб-разработчиков не пренебрегать своей работой даже если они убеждены, что проект, который они делают, не важен и не будет развиваться. Веб, как известно, среда динамическая и постоянно расширяющаяся, по сему любой, даже самый маломальский проект может “выстрелить” и его надо будет срочно расширять, дорабатывать и развивать. Соответственно не стоит экономить на документации, комментировании собственного кода, стоит помнить возможности повторного использования элементов интерфейса и возможности для расширения.

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

Понравилась фраза Нэйта — We are responsible for the “View source”!

Вслед за Нэйтом на сцену поднялся Jonathan Snook, известный канадский веб-разработчик — фрилансер. Его доклад, “Building on the Shoulders of Giants”, основывался на том, что многие веб-разработчики любят каждый раз изобретать велосипед. Само по себе это не так уж и плохо, особенно в начале профессионального пути, так как помогает понять основы и приобрести свои наработки. Но подобный подход в конкурентной среде является серьезным минусом, так как обладая какой-либо идеей и затрачивая огромное время на ее разработку с нуля, вы рискуете прийти на рынок далеко не первым; всем известно что одинаковые идеи приходят различным людям в голову одновременно и побеждает тот, кто реализует задуманное быстрее остальных.

Джонатан призвал использовать опыт гигантов отрасли для своих нужд и реализовывать идеи быстро, с минимальными затратами ресурсов и времени. Основная мысль в том, чтобы используя открытые наработки, API, библиотеки и базы знаний реализовать первичную версию своего проекта, “застолбить территорию” и после этого спокойно продолжать разработку, заодно получая бесплатный bug-track от бета-тестеров и фокус-групп. В докладе Джонатан привел пример реализации простого приложения, основанного на API Twitter и Jquery, в котором твиты располагались на странице в виде временной шкалы. По его словам, это приложение он написал за несколько часов, вечером перед конференцией. Дополнителый пример, уже пользующийся успехом в Северной Америке, приведенный на конференции, MyMileMarker. Кстати любители римейков могут попробовать реализовать подобный сервис в Рунете ;)

Любопытный момент, о котором говорил Джонатан, заключается в том, что при использовании открытых API, разработчик выступает в роли посредника между сервисом и пользователями и в случае сбоев в работе сервиса/API, например Twitter’a, пользователи разработанного вами приложения будут винить именно вас, а не Twitter. Поэтому такие моменты нужно обдумывать заранее и стараться предотвращать.

Следующий доклад доклад был посвещен Javascript-библиотекам и вел его никто иной как John Resig, создатель и главный разработчик Jquery. Само название доклада “The Why and Which of JavaScript Libraries” уже создавало проблему так как Джон, как лицо лично заинтересованое, не мог дать объективное объяснение того, какая библиотека лучше и ее стоит использовать. Он конечно же сам это понимал и поэтому посторил доклад на сравнении библиотек по различным характеристикам.

Начал издалека, с общих сведений, прошелся по статистике использования (большинство разработчиков используют Jquery(32%) и Prototype(32%), остальное делят между собой YUI(20%), Dojo и иже с ними), пробежался по характеристикам. Доклад получился обзорным, почти без конкретики, но по моему мнению только из-за тотальной нехватки времени. В сухом остатке, Jquery и Prototype — лидеры, без сюрпризов.

В конце доклада снова не осталось времени на вопросы и я добавил свой вопрос “Как вы относитесь к идее добавления популярных Javascript-библиотек в браузеры в виде компонентов/плагинов?” в секцию Вопросов и Ответов, которая была запланирована на конец дня. Забегая вперед, должен сказать что к сожалению до этого вопроса добраться так и не успели.

После обеденного перерыва с докладом “WAI(Web Accessibility Initiative) – ARIA(Accessible Rich Internet Applications) – It’s Easy” выступил Steve Faulkner из Paciello Group, который является директором The Web Accessibility Tools Consortium (WAT-C). Речь шла о доступности веб-приложений и сервисов для людей с ограниченными визуальными возможностями. В роли подопытного кролика снова выступал многострадальный Twitter. На примере использования дополнительных атрибутов в разметке, Стив хотел показать относительную легкость создания документов, которые будут более корректно обрабатываться Screen Reader’ами и управление ими будет более доступным. Но все оказалось не таким простым.

Примеры, которые приводил Стив, работали только на синтетических тестах, код которых Стив не показал. Кроме того, документы в которых добавляются атрибуты от WAI-ARIA становятся невалидными, так как WAI-ARIA еще не стала рекомендацией W3C. Не обошлось и без курьеза. Во время одной из демонстраций, Screen Reader JAWS, подключеный к общим колонкам, решил выступить с самостоятельной речью со скоростью 120 слов в минуту. Разволновавшийся Стив довольно долго не мог его успокоить и зал довольно долго хихикал иногда переходя на сдавленое ржание :)

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

Заключительный доклад конференции, на который я пошел, был “Exploring the Server Side: Rails & Django”, который вели по очереди James Adam и Simon Willison. Цель доклада заключалась в представлении серверных технологий Front-End разработчикам для общего развития и для того чтобы заинтересовать потенциальных пользователей. Доклады получились легкими, полными примеров и “живого” написания кода во время доклада. В моем случае доклады достигли цели, так как я, незнающий ни Ruby ни Django, заинтересовался и буду пробовать :)

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

Собственно на этом доклады закончились и началась секция Вопросов и Ответов. На секции долго решали как же все таки правильнее называть Front-End Web Developer или Front-End Engeneer. В конце концов решили что не в названии дело, а в важности этой профессии в процессе веб-разработки. До моего вопроса про Javascript-библиотеки так и не дошли.

Общие впечатления:

Первый день конференции немного подкачал, но это субъективное мнение. Второй день исправил положение но чувствовалась нехватка конкретики и все время присутствовало ощущение типа “ну, вот-вот, сейчас будет, сейчас зажгут”, но как-то оно не очень оправдалось.

Очень порадовала возможность общения с другими веб-разработчиками, обмен мнениями и опытом, ощущение если не братства, то гильдии :)

В целом @Media — выдающееся событие, конференция привлекает огромное количество веб-разработчиков со всего мира, которые создают в нем отличную атмосферу для общения и обмена знаниями. Мне кажется что сейчас организаторы стоят на пороге решения как должна выглядеть конференция в будущем. Уверен что они сделают правильные выводы и я постараюсь поехать туда и в следующий раз.