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

Будущее уже здесь: в W3C задумались о браузерах для роботов

Нет, речь идет не о поисковых и т.п. «ботах», а о настоящих роботах из металла и пластика. Это не шутка и не фантастика. Вчера W3C (кстати, недавно отметивший 20-летие) анонсировал предложение организовать группу для проработки вопросов использования браузеров и веб-технологий для управления роботами и взаимодействия с ними — общественную группу по браузерам и робототехнике.

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

Руководство по SVG-анимациям (SMIL)

Перевод статьи A Guide to SVG Animations (SMIL) с сайта css-tricks.com, автор — Сара Суэйдан. Публикуется с разрешения автора.

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

Введение

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

  • <animate> — позволяющий анимировать скалярные атрибуты и свойства в течение периода времени;
  • <set> — являющийся удобным сокращением для animate, что удобно для задания анимаций для нечисловых атрибутов и свойств, наподобие свойства visibility;
  • <animateMotion> — позволяющий двигать элемент по заданной траектории;
  • <animateColor> — изменяющий значение цвета каких-либо атрибутов или свойств с течением времени. Заметьте, что элемент <animateColor> устарел, и вместо него рекомендуется использовать обычный элемент animate для свойств, принимающих значения цвета. Тем не менее, он всё еще есть в спецификации SVG 1.1, где он явно помечен как устаревший; из спецификации SVG 2 он удален полностью.

В дополнение к анимационным элементам, определенным в спецификации SMIL, SVG включает расширения, совместимые со спецификацией SMIL animations; эти расширения включают атрибуты, расширяющие функциональность элемента <animateMotion>, и дополнительные анимационные элементы. В расширения SVG входят:

(далее…)

«Живой стандарт» WHATWG HTML включил информацию о поддержке браузерами

Спецификация WHATWG HTML, имеющая статус «живого стандарта» и недавно получившая новый постоянный адрес https://html.spec.whatwg.org/multipage/, стала удобнее для веб-разработчиков. С недавнего времени прямо в спецификации в начале многих разделов (напр. об элементе video) отображается врезка с информацией о поддержке данного раздела браузерами, получаемая с сайта caniuse.com.

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

Правда, реализация пока далека от идеала, на момент публикации на врезке почему-то отображается не минимальная поддерживающая версия, а последняя версия, о которой имеется информация на caniuse.com (т.е. версия для «обозримого будущего»). Будем надеяться, что WHATWG исправит это и доведет такое полезное нововведение до ума.

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

Снова равномерное выравнивание блоков по ширине: постепенное улучшение до Flexbox

Задача равномерного выравнивания горизонтальных элементов (например, пунктов меню) по всей ширине контейнера стабильно остается актуальной в верстке. Два года назад Максим Усачев (psywalker) написал обстоятельнейший разбор ее решений, который заслуженно стал самой популярной статьей на CSS-live.ru. Были рассмотрены 4 варианта:

  1. Вариант с разносторонним выравниванием (на базе float), к сожалению, не способный претендовать на универсальность;
  2. Вариант с дополнительным контейнером (в принципе, работоспособное решение, но только для фиксированной ширины элементов);
  3. Вариант с text-align: justify для инлайн-блоков и дополнительным элементом-распоркой (приемлемое решение);
  4. То же самое, но с заменой элемента-распорки на псевдоэлемент :after (лучшее решение).

У двух последних решений была изюминка в виде двух малоизвестных свойств CSS3 (text-align-last и text-justify), по иронии судьбы с незапамятных времен работающих в IE (где они и появились).

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

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>. Даже в тех браузерах, где эти новые теги и не работают без пинка. Как это может быть? (далее…)