Архив автора: SelenIT

W3C HTML5 вышел на финишную прямую

Прошедшая неделя в W3C выдалась довольно богатой на новости, сразу несколько рабочих групп «разродились» новыми спецификациями либо существенными обновлениями старых. В частности, «первая очередь» спецификации HTML5 по версии W3C — HTML5.0 — обновила свой статус до предложенной рекомендации (Proposed Rec., PR). Это означает, что спецификация теоретически готова, реализована как минимум в двух браузерах и только простая формальность (в виде положенного по процедуре месячного «испытательного срока») отделяет ее от окончательного утверждения в статусе рекомендации (что в W3C соответствует понятию «стандарт»).

Таким образом, планы W3C по поэтапному утверждению HTML5 — первой части до конца 2014 года, а оставшейся части до конца 2016-го — имеют все шансы выполниться в намеченный срок, и старые страхи о том, что «HTML5 не будет готов до 2022-го», можно забыть.

Стоит отметить, что, хотя почти завершенный статус спецификации производит впечатление стабильности и «солидности», на самом деле ни для разработчиков браузеров, ни для веб-разработчиков этот статус не так уж важен. Стабильные «отпечатки» (snapshots) спецификаций нужны главным образом патентным юристам, как требует патентная политика W3C. Фактически же еще в момент публикации эти документы являются устаревшими. Важные для разработчиков реализаций новинки содержатся в текущем редакторском черновике W3C, а также в «живом стандарте» WHATWG. Кстати, последний недавно как раз переехал на новый адрес — https://html.spec.whatwg.org/. К сожалению, последнее время редакторы обеих ветвей HTML5 не особо ладили друг  с другом, и расхождения между спецификациями всё накапливаются.

В дополнение к HTML5.0 W3C выпустил первый черновик отдельной спецификации для отличий HTML5 от HTML4. Прежде это был небольшой раздел в HTML5. В частности, одна глава новой спецификации посвящена новой классификации моделей содержимого и ее отличиям от устаревшего и вечно вызывавшего путаницу деления элементов на «блочные и строчные». Возможно, в W3C прочитали нашу давнюю статью?:)

CSS-свойство display и контексты форматирования

Я давно собирался написать эту статью, но на прошлой неделе W3C дал замечательный повод… впрочем, обо всём по порядку. Кстати, спецификации W3C зря считают скучными: порой они могут дать фору любому детективу. В хорошем детективе всё выясняется лишь на последней странице. Но бывало ли, чтобы ключевая деталь детектива ― например, что злодеев было не двое, а трое ― раскрывалась вообще не в тексте, а… в списке найденных опечаток, на отдельном листке, вклеенном в книгу?

Так вот, в спецификациях W3C бывает еще и не такое. Например, всем нам знакомая спецификация CSS2.1: уже три года как она в статусе рекомендации, по идее, никаких изменений в ней быть не должно. Как вы думаете, сколько в этой спецификации описано наших любимых контекстов форматирования: два ― инлайновый и блочный? А вот и нет: три! Через год после «совсем-совсем-окончательного» утверждения спецификации ее авторы внезапно поняли, что на самом деле в ней описан еще один, ни на что не похожий, контекст форматирования ― табличный. Но поскольку менять окончательно утвержденную спецификацию по правилам игры нельзя, то единственное, куда можно было внести изменение ― список замеченных ошибок (errata). Так что внимательно читайте спецификации, и не только основной текст, но и добавочные ссылки! Кстати, кто пройдет квест на внимательность в оглавлении этой самой спецификации и найдет ее «секретный уровень» с одной загадочной фразой?

Но хватит вступлений, пора переходить к нашей первой теме, и это…

Контексты форматирования в CSS

Итак, какие они вообще бывают, по состоянию на середину-конец 2014 года? (далее…)

10 популярных мифов о валидности и валидации

Миф 1. Валидность — некая единая, универсальная характеристика для любого кода

Примеры употребления: «Поменяй доктайп с X на Y, а то невалидно».

Реальность: валидность — понятие конкретное и относительное. Валидность документа на языке разметки означает соответствие определенной схеме. Указанной (напр. DTD в доктайпе) или подразумеваемой (в HTML5). Схемы бывают разные, и требования у них тоже (аналог из жизни: к строительству жилых домов и атомных электростанций применяются разные СНиПы), поэтому документ, валидный по одной схеме, наверняка будет невалидным по другой (хороша была бы АЭС, построенная по нормативам жилого дома!).

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

(далее…)

МаCSSаракш. Размышления о стандартах CSS

Пролог, или Невероятное происшествие в парижском бюро мер и весов

Представьте ситуацию: вы приходите в магазин и просите килограмм муки. Продавец с порога огорошивает вас новостью, что вчера в международном эталоне килограмма была обнаружена неточность, поэтому, пока эталон уточняется, с сегодняшнего дня все переходят на старинные фунты и пуды. Вы, чертыхаясь, достаете калькулятор, пересчитываете килограмм в фунты, отвешиваете эту жуткую дробь и идете домой готовить пирог. Когда пирог уже готов, выясняется, что ваш калькулятор считал в русских фунтах, а продавец использовал английские — и рецепт оказался безнадежно испорчен. Вы идете в магазин ругаться (почему вам не уточнили, в каких фунтах надо было считать) и… видите в руках у продавца новенькие гири с маркировкой «1 килограмм»! Но по виду похожие на «дореформенные» пятикилограммовые.

Бред? Конечно! Есть же какие-то базовые стандарты, которые не могут так внезапно меняться по прихоти. Да, они могут уточняться и совершенствоваться — но не так, что прежние эталоны вдруг станут полностью негодными, а потом радикально изменят своё значение. Улучшение стандартов — однонаправленный, поступательный процесс исправления мелких неточностей, а не чередование периодов относительной ясности с полосами полной неразберихи, то туда, то обратно. Так требует здравый смысл.

Почему же не менее бредовые истории оказались возможны в вебе?

(далее…)

HTML5: пути WHATWG и W3C опять расходятся?

Как известно, с начала возобновления в W3C работы над новой версией стандарта HTML (известной как HTML5) велись параллельно. WHATWG (самостоятельная рабочая группа по технологиям гипертекстовых веб-приложений, образованная представителями разработчиков браузеров и инициировавшая работу над новой версией HTML) поддерживает и развивает «живой стандарт HTML», а рабочая группа по HTML в W3C периодически выпускает «снимки» (snapshots) спецификации в соответствии с утвержденным W3C рабочим процессом (по которому спецификация постепенно «дозревает», последовательно меняя статус от черновика до окончательной рекомендации). До сих пор главным (и фактически единственным) редактором обеих спецификаций был один и тот же человек — Иэн Хиксон (известный также под ником Hixie).

Со временем между двумя версиями спецификации стали накапливаться расхождения. Сначала W3C попытался разделить спецификацию на несколько отдельных документов (в частности, от основной спецификации были отделены 2D Сanvas API, серверные события и т.п.), что в итоге привело к путанице, и WHATWG вернулись к модели единой большой спецификации. Затем стало понятно, что цели обеих групп тоже расходятся. Как поясняет в своем письме Хиксон, в WHATWG старались создавать «каноническое описание HTML и смежных технологий», исправляя ошибки спецификации по мере их обнаружения и добавляя новинки, как только они оказываются востребованными и пригодными к реализации. Для W3C на первом плане оставались формальные критерии смены статусов, предусмотренные их рабочим процессом. Поэтому руководство рабочей группы HTML в W3C и сам Хиксон решили окончательно разделить работу над спецификацией на два фронта: Хиксон сосредоточится над WHATWG-версиейживым стандартом»), а у W3C-версий (HTML5 и отделившихся от нее спецификаций) появится свой новый редактор.

Таким образом, с данного момента у нас появляются две разных, независимых спецификации HTML5.

К какой из спецификаций будут прислушиваться разработчики браузеров? В IRC-канале Хиксон утверждает, что «надеется, что это будет версия WHATWG», хотя «поживем — увидим». Но он уверяет, что в долгосрочной перспективе версия WHATWG будет отвечать состоянию дел в браузерах (т.е. учитывать состояние реализации тех или иных «фич»). Он также высказывает опасения, что задержка спецификации (отставание ее от реальности) приведет к тому, что браузеры начнут внедрять собственные новинки на свой лад.

Некоторые замечают в нынешней ситуации аналогии с 2004-м годом, когда расхождение в целях между W3C («зацикленным» тогда на XML и XHTML) и разработчиками браузеров как раз привело к возникновению WHATWG и HTML5. Пока трудно сказать, как эта новость скажется на дальнейшем развитии HTML5 и веба вообще. Так что следите за новостями!

Двойной праздник от W3C: статус рекомендации для Media Queries… и еще один сюрприз!

Буквально час назад рабочая группа CSS в W3C порадовала веб-разработчиков двумя хорошими новостями. Во-первых, спецификация Media Queries («медиазапросы» или «медиавыражения», главная основа адаптивной вёрстки) с сегодняшнего дня официально приобрела финальный статус рекомендации. Это означает признание ее полностью готовой, ее реализаций — проверенными и совместимыми между собой, и практически гарантирует, что меняться она уже не будет. Так что отбросьте последние сомнения и пользуйтесь на здоровье!

(далее…)

Как избавиться от префикса для -webkit-device-pixel-ratio

Решили некогда вебкитовцы, что было бы полезным медиавыражение для разрешения экрана. Но вместо того, чтобы использовать уже стандартизированное выражение resolution, они изобрели -webkit-device-pixel-ratio. Медиавыражение resolution принимает лишь «количество точек на дюйм» и «количество точек на сантиметр», тогда как -webkit-device-pixel-ratio принимает «количество точек на px». Но все они в своей основе — одно и то же, поскольку 1in = 96px = 2.54cm. (Справедливости ради, не всё из этого было так понятно в 2006-м, так что простим вебкитовцам их отсебятину).

(далее…)

«Блочных и строчных элементов» в HTML больше нет

Для тех, кому лень читать всю статью: в HTML нет «блочных» и «строчных» элементов. Это деление — историческая ошибка, чистая условность и анахронизм времен конца 90-х. Элементы HTML различаются между собой не формой и внешним видом, а смыслом и предназначением (структурные, текстовые, интерактивные и т.п.), именно оно определяет, что во что можно вкладывать. А «блочностью», «инлайновостью», любыми их комбинациями и др. чисто внешними чертами заведует исключительно CSS.

Остальное — для тех, кто до сих пор не верит или просто желает разобраться до конца.

(далее…)

Адаптивные изображения в HTML5: конец первого раунда

Брюс Лоусон, среда, 16 мая 2012

После Великого Апрельского Браузерно-Префиксного Тарарама пришла Великая Майская Адаптивно-Картиночная Шумиха 2012-го.

Адаптивные изображения — очередная неразгаданная загадка «отзывчивого» веб-дизайна. Вы отдаете большие картинки высокого разрешения, подходящие для экранов типа «ретины», которые устройства с меньшим разрешением показывают уменьшенными, зря расходуя трафик? Или вы отдаете картинки низкого разрешения, которые мерзко выглядят, будучи растянутыми на большом экране? Вебмастерам приходится рассчитывать на искусные хаки, чтобы отдавать различные контентные картинки (т.е. <img> в HTML, а не CSS-фоны) для разных типов устройств.

(далее…)

О семантике HTML и архитектуре веб-фронтенда

Перевод статьи Николаса Галлахера «About HTML semantics and front-end architecture», переводчик — SelenIT

Собрание мыслей, опыта, идей, которые мне нравятся и идей, с которыми я экспериментировал последний год. Они охватывают семантику HTML, компоненты и подходы в архитектуре веб-фронтенда, способы именования классов и HTTP-сжатие.

Мы не прервем своих исканий,
И под конец всех странствий наших
Придем туда, откуда вышли,
Узнав впервые этот край.

Т. С. Элиот — «Маленький Гиддинг»

(далее…)

Главный секрет HTML5

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

И тем не менее, HTML5 повсюду. Даже там, где его не ждали. Даже там, где нет модного короткого доктайпа <!DOCTYPE html> (кстати, тоже без цифры 5), даже без модных "семантичных" (хотя об их смысле не всегда могут договориться сами разработчики спецификаций, не говоря уже о простых вебмастерах) элементов типа <article> и <nav>. Даже в тех браузерах, где эти новые теги и не работают без пинка. Как это может быть? (далее…)

Каждый раз, когда вы называете проприетарную фичу словом «CSS3», в мире умирает котенок

Перевод статьи «Every Time You Call a Proprietary Feature “CSS3,” a Kitten Dies» из журнала A List Apart, автор — Лиа Веру, переводчик — SelenIT

Минздрав Интернета предупреждает: каждый раз, когда вы называете проприетарную фичу словом «CSS3», в мире умирает котенок. Любая -webkit-фича, не входящая в спецификации (хотя бы в редакторский черновик) — никакой не CSS3. Да, их часто выдают за него, но они вообще даже не часть CSS. Различать эти вещи — не просто педантство. Это важно, потому что эта путаница мотивирует некоторых производителей браузеров (с таким, кхе-кхе, яблочком на лого…) идти в обход процесса стандартизации, реализовывать в WebKit свою отсебятину, а потом подавать ее вебмастерам как невиданную вкусность. Новые блестящие игрушки ослепляют нас, и мы сами начинаем превозносить их, усиливая эхо рекламного шума. (далее…)

Flexbox умер, да здравствует Flexbox!

(перевод заметки из блога Тэба Эткинса, участника рабочей группы CSS в W3C, редактора ряда спецификаций)

Я вот уже месяц собираюсь написать этот пост. Плоховато у меня с планированием времени.

Если вы следили за моим блогом в последний год или около того, вы наверняка в курсе, что я — основной редактор спецификации CSS Flexbox. Я взялся за эту спецификацию, потому что посчитал, что исходная спецификация была слишком буквально "слизана" с XUL, и что мы можем сделать лучше. В частности, я надеялся переписать спецификацию так, чтобы можно было использовать обычные свойства боксовой модели (ширину, высоту, отступы, поля), придавая им гибкость напрямую. Покопавшись в моих архивах, вы найдете несколько попыток переписать ее в таком ключе.

(далее…)