Веб разработкой я занимаюсь давно, и помню еще IE3 и NN4.xx. Многое изменилось с тех пор, много воды утекло. Пришло понимание всех технологий не на уровне «HTML — это текстовый файлик, в котором попадаются какие-то слова в скобочках», а понимание логики построения самого языка разметки, его абстракций.
Начало разработки спецификаций HTML5 и CSS3 уже не вызывала у меня щенячьего восторга и бурной радости, а воспринималась как вполне эволюционное событие. Заглядывал я в рабочие черновики изредка, отмечая для себя основные направления развития. Но чем больше спецификации приближаются к финалу, тем страшнее мне становится. Это не то направление развития, которое требует рынок!
Возникает резонный вопрос, куда делись все те люди, которые разрабатывали стандарты 10 лет назад? Куда делись инновации? Почему w3c создает стандарт, который, по некоторым меркам, уже устарел?
Давайте разберемся.
Одними из самых непонятных мне тегов являются del и ins. Они грязным хаком прошли по всей структуре языка, имея при этом весьма сомнительную пользую. Попытки перенести логику офисных документов на веб-страницу закончатся полным фиаско. Почему? Да очень просто! Если вам нужно получить историю изменений документа, то сделать это можно внешними программами, не перенося этот функционал внутрь языка. История правок нужна менее чем одной сотой доле процента пользователей, все остальные спокойно довольствуются текущей актуальной версией данных на момент поиска информации. Парсинг кода с учетом этих двух «замечательных» тегов будет сплошным негативом, потому что нарушается стройность и логичность языка, его предсказуемость.
Второй прикол, это попытка всунуть в HTML вещи, которые нельзя было туда добавлять ни в коем случае. Это атрибуты contenteditable, draggable и прочие интерактивы. Это должно быть вынесено в CSS, DOM, куда угодно, только не в HTML. Это интерактивы, а не разметка. Интерактив должен быть управляемым, и для управления есть замечательный JS и великолепный CSS. Писать эти атрибуты прямо в HTML — очень сильно попахивает HTML образца версии 3.2.
Третий прикол, это жалкие попытки структурировать документ, путем введения дополнительных структурных элементов. Это просто цирк какой-то. За эти слова в меня будут кидаться тапками, но, надеюсь, ряд людей поймет, почему я так говорю. Отойдем от этой темы в сторону и порассуждаем о том, зачем же нужен HTML. А нужен он для того, чтобы сделать разметку некой информации. На данный момент времени разметка включает не только контент, но и дизайнерские изыски. Итак, у нас есть мухи отдельно (структуры, которые нужны для оформительских целей), и котлеты отдельно (непосредственно сам контент). Для контента HTML подходит на ура, а вот с дизайнерскими изысками большие проблемы. Да и с логическими структурами страницы тоже проблемы. У одного на сайте меню, сайдбар и контент, а у второго — шапка с главным меню, второстепенное меню, два сайдбара слева и справа, рекламный бокс, список товаров и прочее. Как их подружить? Да легко! Нужно всего лишь позволить придумывать свои теги! XML для оформления страницы, HTML — для оформления контента. Почему бы сразу не использовать XML? С ним будет больше сложностей для поисковиков. На рынке есть удачное решение проблем поиска при такой структуре документов — микроформаты. Создав, например, атрибут behavior, который будет содержать описание поведения элемента, можно спокойно рассказывать поисковым системам где и что у тебя организовано.
Насоздавали всевозможные типы форм ввода. Забыли только придумать, как это все богатство стилизовать. Понимаю, что однообразие интерфейса важная вещь, но стилизация может быть как позитивным, так и негативным фактором в развитии веб-интерфейсов. Рынок требует этого, значит нужно это делать.
Вот мы и подошли плавно к теме CSS3
Продолжим тему веб-форм. Рынок веб-интерфейсов ожидает контроллируемую стилизацию полей ввода. На практике это означает, что я хочу из любого элемента сделать любое поле ввода. Я хочу сделать чекбокс со своим собственным дизайном, хочу сделать селектбокс со своим оформлением, каждую опцию создавать из своей собственной XML-структуры и так далее. Что мы видим в рабочем варианте спецификации? А ничего.
Темплейты отображения (Template Layout) сперва меня вдохновили, потом, после моделирования реальных ситуаций, я понял, что это работать не будет вообще. Если контент статичен, то такой подход работать будет. Но как только появляется динамика…
Возьмем вполне нормальную ситуацию: у нас есть четыре блока, которые, в зависимости от ширины контента или окна браузера, должны выстраиваться друг за другом, и занимать или одну строку, или две, три, четыре строчки. Обычные float'ы. Все, коллапс, ведь темплейт не описывает поведение блока и перемещение его в случае, если он не влазит в некое пространство. Позиция блока в темплейте четко зафиксирована, адаптивную верстку делать будет крайне затруднительно. А это требует рынок, а это сейчас делается при помощи костылей. Кроме этого не совсем понятно, как при изменении DOM дерева, блок, у которого прописана четкая позиция в темплейте на странице, будет себя вести. Но это никого не волнует, мы из веб-страничек делаем журнальную верстку. Я писал про это Д. Барону, но эффект нулевой.
Вернемся еще к одной очень важной вещи, под названием точка отсчета. Точка отсчета на данный момент времени выбрана одна — левый верхний угол. Рассчет позиции того же фона ведется именно из этого места. Но в мире существуют не только те, кто читает слева направо, а еще и те, кто читает справа налево, сверху вниз и так далее. Теперь попробуйте без костылей сделать мультиязыковый дизайн. А решение проблемы у всех под носом — нужно всего лишь изменить точку отсчета, и позиция фона для жителей Саудовской Аравии, чудным образом осталась бы неизменной, например 10px 10px, и находилась бы в верхнем правом углу, ровно на данное смещение. Развивая идею с точкой отсчета, можно обнаружить более управляемый контроль позиции абсолютных элементов, контроль трансформации объектов и много полезного. Но этого я не нашел в спецификации.
Перечислять неувязки можно долго. Не думайте, что моя задача очернить работу w3c, там работают очень умные люди. Просто за время создания новой спецификации часть изначальных целей перестала быть актуальной. Рынок развивается очень быстрыми темпами, и от w3c требуется больше интерактива с разработчиками. Моя же основная цель — заставить людей задуматься над тем, что они делают и как они думают.
UPD: Огромное спасибо всем за позитивную и негативную карму!
UPD2: Изменил абзац про темплейты отображения
Начало разработки спецификаций HTML5 и CSS3 уже не вызывала у меня щенячьего восторга и бурной радости, а воспринималась как вполне эволюционное событие. Заглядывал я в рабочие черновики изредка, отмечая для себя основные направления развития. Но чем больше спецификации приближаются к финалу, тем страшнее мне становится. Это не то направление развития, которое требует рынок!
Возникает резонный вопрос, куда делись все те люди, которые разрабатывали стандарты 10 лет назад? Куда делись инновации? Почему w3c создает стандарт, который, по некоторым меркам, уже устарел?
Давайте разберемся.
HTML5
Одними из самых непонятных мне тегов являются del и ins. Они грязным хаком прошли по всей структуре языка, имея при этом весьма сомнительную пользую. Попытки перенести логику офисных документов на веб-страницу закончатся полным фиаско. Почему? Да очень просто! Если вам нужно получить историю изменений документа, то сделать это можно внешними программами, не перенося этот функционал внутрь языка. История правок нужна менее чем одной сотой доле процента пользователей, все остальные спокойно довольствуются текущей актуальной версией данных на момент поиска информации. Парсинг кода с учетом этих двух «замечательных» тегов будет сплошным негативом, потому что нарушается стройность и логичность языка, его предсказуемость.
Второй прикол, это попытка всунуть в HTML вещи, которые нельзя было туда добавлять ни в коем случае. Это атрибуты contenteditable, draggable и прочие интерактивы. Это должно быть вынесено в CSS, DOM, куда угодно, только не в HTML. Это интерактивы, а не разметка. Интерактив должен быть управляемым, и для управления есть замечательный JS и великолепный CSS. Писать эти атрибуты прямо в HTML — очень сильно попахивает HTML образца версии 3.2.
Третий прикол, это жалкие попытки структурировать документ, путем введения дополнительных структурных элементов. Это просто цирк какой-то. За эти слова в меня будут кидаться тапками, но, надеюсь, ряд людей поймет, почему я так говорю. Отойдем от этой темы в сторону и порассуждаем о том, зачем же нужен HTML. А нужен он для того, чтобы сделать разметку некой информации. На данный момент времени разметка включает не только контент, но и дизайнерские изыски. Итак, у нас есть мухи отдельно (структуры, которые нужны для оформительских целей), и котлеты отдельно (непосредственно сам контент). Для контента HTML подходит на ура, а вот с дизайнерскими изысками большие проблемы. Да и с логическими структурами страницы тоже проблемы. У одного на сайте меню, сайдбар и контент, а у второго — шапка с главным меню, второстепенное меню, два сайдбара слева и справа, рекламный бокс, список товаров и прочее. Как их подружить? Да легко! Нужно всего лишь позволить придумывать свои теги! XML для оформления страницы, HTML — для оформления контента. Почему бы сразу не использовать XML? С ним будет больше сложностей для поисковиков. На рынке есть удачное решение проблем поиска при такой структуре документов — микроформаты. Создав, например, атрибут behavior, который будет содержать описание поведения элемента, можно спокойно рассказывать поисковым системам где и что у тебя организовано.
Насоздавали всевозможные типы форм ввода. Забыли только придумать, как это все богатство стилизовать. Понимаю, что однообразие интерфейса важная вещь, но стилизация может быть как позитивным, так и негативным фактором в развитии веб-интерфейсов. Рынок требует этого, значит нужно это делать.
Вот мы и подошли плавно к теме CSS3
CSS3
Продолжим тему веб-форм. Рынок веб-интерфейсов ожидает контроллируемую стилизацию полей ввода. На практике это означает, что я хочу из любого элемента сделать любое поле ввода. Я хочу сделать чекбокс со своим собственным дизайном, хочу сделать селектбокс со своим оформлением, каждую опцию создавать из своей собственной XML-структуры и так далее. Что мы видим в рабочем варианте спецификации? А ничего.
Темплейты отображения (Template Layout) сперва меня вдохновили, потом, после моделирования реальных ситуаций, я понял, что это работать не будет вообще. Если контент статичен, то такой подход работать будет. Но как только появляется динамика…
Возьмем вполне нормальную ситуацию: у нас есть четыре блока, которые, в зависимости от ширины контента или окна браузера, должны выстраиваться друг за другом, и занимать или одну строку, или две, три, четыре строчки. Обычные float'ы. Все, коллапс, ведь темплейт не описывает поведение блока и перемещение его в случае, если он не влазит в некое пространство. Позиция блока в темплейте четко зафиксирована, адаптивную верстку делать будет крайне затруднительно. А это требует рынок, а это сейчас делается при помощи костылей. Кроме этого не совсем понятно, как при изменении DOM дерева, блок, у которого прописана четкая позиция в темплейте на странице, будет себя вести. Но это никого не волнует, мы из веб-страничек делаем журнальную верстку. Я писал про это Д. Барону, но эффект нулевой.
Вернемся еще к одной очень важной вещи, под названием точка отсчета. Точка отсчета на данный момент времени выбрана одна — левый верхний угол. Рассчет позиции того же фона ведется именно из этого места. Но в мире существуют не только те, кто читает слева направо, а еще и те, кто читает справа налево, сверху вниз и так далее. Теперь попробуйте без костылей сделать мультиязыковый дизайн. А решение проблемы у всех под носом — нужно всего лишь изменить точку отсчета, и позиция фона для жителей Саудовской Аравии, чудным образом осталась бы неизменной, например 10px 10px, и находилась бы в верхнем правом углу, ровно на данное смещение. Развивая идею с точкой отсчета, можно обнаружить более управляемый контроль позиции абсолютных элементов, контроль трансформации объектов и много полезного. Но этого я не нашел в спецификации.
Перечислять неувязки можно долго. Не думайте, что моя задача очернить работу w3c, там работают очень умные люди. Просто за время создания новой спецификации часть изначальных целей перестала быть актуальной. Рынок развивается очень быстрыми темпами, и от w3c требуется больше интерактива с разработчиками. Моя же основная цель — заставить людей задуматься над тем, что они делают и как они думают.
UPD: Огромное спасибо всем за позитивную и негативную карму!
UPD2: Изменил абзац про темплейты отображения