Собрался с духом и установил Internet Explorer 8 beta 2. Обновление прошло гладко, никаких запросов на проверку оригинальной версии Висты и тд.

После рестарта было немного непонятно куда тыкать, так как иконка и надпись к ней не изменились. Но все установилось, версия поменялась. Решился я на этот шаг из-за того, что с тех пор как я вынуждено перелез на Висту, я пользуюсь отличной программой под названием IE Tester, которая в разных табах рендерит веб-документы в той версии IE, в которой попросишь, начиная с IE5.5 и заканчивая IE8 beta1.

Впечатления от IE8 двоякие. Как собственно и от всех продуктов семейства Мелкомягких. Вроде бы все работает в Standards Compliance Mode, поддержка CSS 2.1, интересные утилитки, такие как Developer Tools, Accellerators, Web-Slices и тд, но сыро. Скоропалительных выводов делать не стоит, но создается ощущение что где-то тебя имеют.

А основывается оно вот начем. Во-первых, на части моих проектов, которые вылизаны и оттестированы везде где только можно, настойчиво выдается подозрительная ошибка “Permission denied” в первой строке и скрипты не отрабатывают. Лаконично, но малоинформативно. Во-вторых, CSS как-то подозрительно нестабилен. Где-то есть поддержка :first-letter, где-то нет. Тоже самое с :before и :after. Обычный div, с указаным min-width, не превышающим ширину экрана выдает горизонтальный скролл пока не укажешь ему max-width: 99.8%… Чудеса.

Все это конечно только поверхностное рассмотрение, да еще и beta-версии, которые по традиции в Microsoft называют вместо alpha. Есть и приятные моменты. Большинство ежедневных плясок с бубном можно будет забыть, более качественная поддержка стандартов налицо. Встроенные Developer Tools, с дебаггером, работой со стилями и тд — очень не плохо. CSS-хаки для предыдущих версий IE игнорируются, что есть гуд. На данный момент не обнаружены CSS-хаки для IE8, но Conditional Comments никто не отменял

С Conditonal Comments есть небольшая проблема — когда в IE8 включен Compatibility Mode (IE8 предлагает включить его при любой возможности, но вы можете включить его вручную), то веб-документы рендерятся как в IE7, но Conditional Comments в данной ситуации все равно остаются как для IE8. То есть, если файл стилей для IE7 у вас подключен через четкое указание версии, то IE8 его не увидит даже в Compatibility Mode.

Для тех из вас, кто уже хочет потрогать очередное детище Мелкомягких за вымя, я приготовил небольшую шпаргалку по Conditional Comments, которая поможет решить вышеописанную проблему и некоторые другие:

<!--[if IE 8]> Вызов файла стилей/код/стили < ![endif]--> - если Интернет Эксплорер 8
<!--[if !(IE 8)]> Вызов файла стилей/код/стили < ![endif]--> - если не Интернет Эксплорер 8
<!--[if lt IE 8]> Вызов файла стилей/код/стили < ![endif]--> - если меньше чем Интернет Эксплорер 8 (lt = lower than)
<!--[if gt IE 7]> Вызов файла стилей/код/стили < ![endif]--> - если больше чем Интернет Эксплорер 7 (gt = grater than)
<!--[if lte IE 7]> Вызов файла стилей/код/стили < ![endif]--> - если Интернет Эксплорер 7 и ниже (lte = lower than or equal)
<!--[if (IE 7)|(IE 8)]> Вызов файла стилей/код/стили < ![endif]--> - если Интернет Эксплорер 7 или 8
<!--[if (gte IE 6)&(lte IE 8)]> Вызов файла стилей/код/стили < ![endif]--> - если Интернет Эксплорер между 6 и 8 включительно
<!--[if !IE]> --> Вызов файла стилей/код/стили <!-- <![endif]--> - если любой браузер, исключая Интернет Эксплорер

Вот собственно и все что я успел заметить во время первого знакомства с IE8. Надеюсь что к релизу замеченные недочеты и ляпы будут исправлены и мы наконец-то получим браузер, способный брать качеством, а не количеством. Аминь.

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

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

Сейчас это конечно уже в прошлом, существуют решения с использованием 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 вот так или так.

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

Ссылка в тему: Расправляемся с багом позиционирования в IE6 (z-index).

Появилась возможность авторизироваться через OpenID для комментирования, поддержка Gravatar, ну и по мелочам.

В ближайшие дни буду отлавливать баги.

Дин, спасибо за помощь с базой.

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

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

29-30 Мая в Лондоне прошла четвертая конференция для веб-разработчиков @Media. Мне посчастливилось на ней побывать и я, как и обещал, публикую отчет о поездке. Для начала немного общих сведений о конференции:

@Media проводится уже в четвертый раз и обычно это происходит в Сан Франциско, Лондоне и Гонг Конге с промежутком в неделю, в течении месяца. В этом году конференция проводилась только в Лондоне, не смотря на то, что изначально была заявлена и в Сан Франциско. Причина отмены американской части конференции мне не известна.

Ежегодно в конференции принимают участие многие мастистые и известные разработчики и дизайнеры из разных стран. Фактически каждый год конференцию почитают своим присутствием представители Google, Yahoo, W3C, Clear Left, 37 Signals и других известных компаний и веб-студий.

Доклады на конференции идут в виде своеобразного марафона - один за другим, с небольшими перерывами на обед и кофе, в течении двух дней, с 9.00 до 17.00. Лекции идут параллельно в двух разных аудиториях, что с одной стороны создает свободу выбора, а с другой - ставит иногда перед участниками диллему выбора.

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

Конференцию открыл Джеффри Вин из Google (до мая 2008). Джефф хороший докладчик и сразу создал благоприятную атмосферу, и свою открывающую речь продолжил докладом “Designing Our Way Through Data”. Основная мысль доклада состояла в том, чтобы предоставляя информацию посетителям сайта, не заставлять их думать. Все должно быть наглядным и не вызывать сомнений.

Все было бы чудесно, если бы в последствии я не узнал что в своем докладе Джефф использовал солидные куски из доклада на @Media 2006. Это конечно не сделало сам доклад хуже, но оставило небольшой осадок.

Следующий доклад вела Инди Янг из компании Adaptive Path. Сессия называлась “Mental Models: Sparking Creativity Through Empathy” и речь в ней велась в основном об организации рабочего процесса, создании атмосферы для производства креативных решений и подобным вещам. Говорились правильные вещи, но мне доклад не очень понравился, возможно из-за манеры речи.

Вслед за Инди, я был на сессии с интригующим названием “Getting Your Hands Dirty with HTML5″, которую вели Джеймс Грэхем и Лаклэн Хант. Ребята старались доказать преимущества HTML5 перед XHTML2, объясняя на пальцах общие моменты и мотивируя все обратной совместимостью.

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

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

После этого доклада был большой перерыв на обед. Кормили кстати на конференции неплохо и помимо обеда во время всех докладов действовали буфеты, в которых можно было заправиться кофе, чаем, соком и кондитерскими изделиями. Естественно все было бесплатным (еще бы, стоимость участия в конференции, составляющая более 500 фунтов за два дня покрывает такие “мелочи”).

Послеобеденную часть конференции открыл доклад Дрю Маклиллана о CMS’ках. У меня были определенные надежды на эту сессию, но к сожалению они разбились о суровую реальность. Доклад получился сухим, неинтересным и в конце концов свелся к ненавязчивой рекламе собственной разработки его студии. Стоит ли говорить о том, что ближе к концу доклада я стал клевать носом, как и многие другие?

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

К счастью, на выручку страждущим явился Дэн Рубин, который работает с сайтами известных СМИ и ведет начало своей деятельности из типографии. Дэн наглядно показал, что в течении 20 минут, с помощью гридов и работы с текстом в CSS можно превратить неудобоваримый сайт Fox News во что-то более пристойное и подобное хотя бы сайту CNN.

Затем он пошел дальше и показал макет собственной версии Fox News, который по моему мнению уже можно было смело нести в агенство и предлагать им на продажу. В общем и в целом, Дэн показал себя профессионалом и интересным докладчиком, что немного сгладило мои немного печальные ощущения от первого дня конференции.

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

С горя дернув чуть ли не залпом литр пива я вышел покурить и… сразу же наткнулся на Nate Koechley, ведущего Фронт-енд Инженера Yahoo и Peter-Paul Koch’a, в народе известного как PPK и ведущего сайт http://www.quirksmode.org. Завязалась беседа, в ходе которой я понял что они тоже недовольны первым днем конференции и попытался выснить причины происходящего, а заодно спросил у Питера почему он не выступает с докладом в этот раз.

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

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

И вот с этими мыслями я пополз в гостиницу в ожидании второго дня конференции.

Продолжение следует.

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

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

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

4 Интересуйся тем, что ты делаешь. Изучай разносторонне даже те вопросы, на которые, как тебе кажется, у тебя уже есть ответ.

5 Инспектируй время от времени свои старые работы. Если при рассмотрении одной из них окажется что ты совсем ничего не хотел бы в ней изменить — пора подумать о смене профессии

Передаю эстафету Павлу Ловцевичу

Все советы

• Александр RMcreative Макаров
• Виталий Харисов
• Никита Селецкис
• Александр Исаков
• Алекс Iline
• Юрий Дроздов
• Марат Таналин
• Вадим Макеев
• Юрий Артюх
• Павел Корнилов
• kizu.ru

CSS, которому уже 12 лет, изначально был задуман и разрабатывался как средство для описания внешнего вида документа. С тех пор утекло много воды и технология претерпела значительные изменения и дополнения. На данный момент, рабочая версия по стандарту W3C, принятая в 2006 году - Уровень 2.1. Уровень 3 находится в состоянии разработки (есть черновик), и ожидается с нетерпением многими разработчиками.

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

И те и другие утверждения имеют право на существование в определенных ситуациях, так как ситация неоднозначна. Но переменные - это еще ничего. Как на счет анимации элементов? До сих пор анимация является прерогативой Javascript’a, который может быть потеснен с этой должности, по крайней мере частично.

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

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

Может быть я сгущаю краски и все не так сложно. Давайте рассмотрим такую ситуацию. Предположим, в теории, что Эра CSS наступила и все самые смелые планы по расширению и выделению CSS в новый язык сбылись. Как я вижу это?

Использование переменных на уровне файла стилей вырастет в желание использовать глобальные переменные. В каждом проекте, состоящем больше чем из 3/5/10 страниц будет глобальный мастер-файл стилей с переменными, файл стилей, отвечающий за анимацию, файл, отвечающий за типографику и тд. Будет путаница с переменными, так как не ясно каков будет приоритет их применения. Построчно, как чтение CSS-файла сейчас, или нет? Можно ли будет выносить переменные?

Javascript станет транспортом информации от клиента к серверу и абстрагируется от оформления окончательно. Так как возможностей CSS не будет хватать для полного управления элементом (я просто не верю, что этот момент наступит), то часть разработчиков будет продолжать использовать JS для создания динамики страниц. Порядка это не добавит.

Разметка документов упростится до минорной, в любом случае, немалая ее часть будет генерироваться JS и видоизменяться в CSS. div’ы (divisions) станут основными базовыми элементами разметки. С помощью CSS они будут принимать любую форму, от круга до многоугольника. Возможностей станет гораздо больше и у дизайнеров не будут скованы руки.

Веб от всего этого только выиграет. Откроется большой простор для деятельности и креатива. Читая по кофейной гуще о возможных путях развития CSS, у меня уже чешутся руки создать что-нибудь эдакое!

А теперь ушат ледяной воды. Кто-нибудь спросил разработчиков браузеров, в частности MSIE, о их планах на будущее? Или все прогрессивные разработчики будут писать сайты исключительно для альтернативных браузеров (а не для людей)? А остальные по-старинке, будут оформлять контент с помощью CSS2.1(2.9?), где динамика, анимация и прочее останутся вотчиной ECMA Script’a?

Любые фундаментальные изменения должны быть четко структурированы и осмыслены; роли ведущих игроков должны быть распределены и расписаны, иначе не избежать неразберихи. А еще хорошо бы, чтобы такие глобальные вещи как языки разметки, программирования и оформления перестали быть Рекомендациями и превратились бы в Стандарты, за спиной которых стоит Организация, требующая их выполнения и соблюдения.

Развитие CSS - несомненное благо. И оно всенепременно затронет другие компоненты Веба. Вопрос только в том, что из фантазий войдет в реальность, а что так и останется нереализоваными мечтами? Время покажет.