CSS-live.ru

HTML5

«Готов» ли HTML?

2

Перевод статьи Is HTML «complete»? с сайта brucelawson.co.uk, автор — Брюс Лоусон.

Не так давно Тим Брей написал интересный пост под названием </html>, в котором он заявляет:

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

На мой взгляд, HTML готов. Это ни в коем случае не означает, что я считаю, будто вся платформа веб-программирования находится в надлежащем состоянии…

Давайте отложим инструменты и сосредоточимся на более важных проблемах.

Когда <button> не лучший выбор (она медленнее создается, отображается и с трудом стилизуется)

14

Перевод статьи When <button> isn’t the best choice (it’s slow to create and render and problematic to style) с сайта benfrain.com, автор — Бен Фрейн.

Элемент <button> значительно медленнее при создании в JavaScript, он медленнее отображается в браузере и крайне трудно стилизуется кроссбраузерно. Несмотря на то, что <button>, это «правильный» выбор для задач кнопки, это не обязательно должен быть «лучший» выбор.

Представьте картину. Я пытаюсь убедить главного инженера программного обеспечения использовать более семантические элементы в разметке, а не только общие элементы, типа div  и span. Такие семантические элементы, как sectionheaderfooter и nav. Разговор выглядел примерно следующим образом. «Нам нужно проверить, что они не медленнее при создании в JavaScript», — говорит он. «Конечно, нет проблем», — отвечаю я, с полной уверенностью.

Про пояса HTML и подтяжки ARIA: неявная ARIA-семантика по умолчанию, которую от вас хотели скрыть

4

Перевод статьи Стива Фолкнера «On HTML belts and ARIA braces» с сайта html5doctor.com

Надо ли добавлять HTML-элементам атрибуты ARIA role, чтобы раскрыть их семантику — один из тех вопросов, что всплывают с завидным постоянством. Ответ — «может быть» для некоторой части элементов, но обычно (и чем дальше, тем больше) — «нет».

Создание аудиоплеера при помощи HTML5. Часть 3: микроданные и внешний вид

8

Перевод статьи Making An Audio Player With HTML5, Part 3: Microdata and Skinning с сайта demosthenes.info, c разрешения автора — Дадли Стори.

В первых двух статьях этого цикла я представил концепцию и код для собственного аудиоплеера. Прототип, который сконструирован к этому моменту – «сырой», без какого-либо оформления: HTML5 и JavaScript был написан на скорую руку, чтобы убедиться, что базовая концепция работает. В этой статье я сосредоточусь на улучшении внешнего вида плеера и добавлении микроданных, прежде чем вводить дополнительные функции в четвёртой статье.

Создание аудиоплеера при помощи HTML5. Часть 2: прототипирование

2

Перевод статьи Making An Audio Player With HTML5, Part 2: Prototyping с сайта demosthenes.info, c разрешения автора — Дадли Стори.

Существует два подхода для создания почти чего угодно. Первый – это взяться за дело с наскока, разрабатывая от целого к частному, набивая шишки о проблемы по мере их появления и надеясь, что вы во всём разберётесь. Второй – это создать ряд простых тестов: разрабатывая от частного к целому, проверяя каждый шаг, прежде чем использовать плоды своих трудов для создания окончательного, законченного произведения.

Создание аудиоплеера при помощи HTML5. Часть 1: функции и дизайн

1

Перевод статьи Making An Audio Player With HTML5, Part 1: Features and Design с сайта demosthenes.info, c разрешения автора — Дадли Стори.

Возможно, вы не настолько стары, чтобы помнить дни WinAmp-а, который был (в своём первноначальном воплощении) основной программой для проигрывания MP3 с "киллер-фичей" в виде настраиваемых тем. Сегодня у вас есть возможность создать свой собственный плеер, используя  HTML5 и JavaScript, и настроить его внешний вид при помощи CSS. Планирование и разработка этого плеера позволит разработчикам познакомиться с HTML5-мультимедиа, JavaScript DataViews и WebAudio API.

Спецификации HTML5 W3C и WHATWG — документированные различия

0

Перевод статьи W3C vs. WHATWG HTML5 Specs — The Differences Documented с сайта developer.telerik.com, c разрешения автора — Аурелио Де Роса.

Несколько недель назад HTML5 получил статус W3C-рекомендации. Я воспользовался этим событием, чтобы обсудить на SitePoint пять интересных, но уже устаревших вещей. Проблема в том, что W3C-спецификации — это лишь одна сторона медали. Начиная с этой версии HTML, разработчики и производители браузеров могут выбирать между двумя разновидностями одного и того же языка разметки: спецификациями, разработанными консорциумом W3C, и тех, что разработаны WHATWG.

Долговременная веб-семантика

14

Перевод статьи Long Term Web Semantics с сайта infrequently.org, c разрешения автора — Алекса Рассела.

Что-то раздражает меня во фразе «семантичный HTML».

Подразумеваемый смысл вполне ясен: использование HTML так, чтобы он был читаемым, описание вещей простым языком. Но «семантика» означает совсем не это. Можно было сказать просто «хорошо написанный» или «проверенный редактором». Это подошло бы лучше. Разметка, которую мы сегодня называем «несемантичной», на самом деле не такова: для конечных пользователей-то смысл есть, просто он передается слишком многословной разметкой. Рассусолено, но не «несемантично» (т.е. не «бессмысленно»).

Замысловатое и ускользающее от понимания — вроде того, что выходит из-под моего пера — плохо. Простое и ясное — хорошо. Сложно определить, что такое «просто» и «ясно», поскольку здесь замешаны вопросы значения и то, чего авторы (веб-разработчики) могут ожидать от читателей (браузеров). Для этого есть специальные фразы, напр. «Чтение на уровне 8 класса». Расчет на продвинутого читателя позволяет писать кратко и передавать тонкие оттенки. Знатокам не нужно разъяснять термины. Есть реальная польза в повышении общей грамотности в сообществе.

Употребление слова «семантичный», при котором речь идет о простоте, и подразумеваемое при этом значение этого слова говорят о глубокой путанице насчет того, как работает язык, роли разработчиков в донесении этого значения и реального потенциала смыслового развития для веба. Почему это важно? И чем плох «семантичный HTML»?

Дорога к «пятерке» (о статусе W3C Recommendation для HTML5)

3

Перевод статьи Стива Фолкнера «The ride to 5» с сайта html5doctor.com

Вперёд

В последние недели я обращался к примерно 40 людям из числа тех, кто без устали трудился над HTML5 и/или без умолку рассказывал о нем. Я поинтересовался их точкой зрения на то, что HTML5 стал рекомендацией W3C. Ниже слова 28 ответивших, в основном в порядке попадания их ответов в мой почтовый ящик.

HTML5 стал рекомендацией W3C. Ваши мысли?

Тим Бернерс-Ли:

Директор Консорциума Всемирной сети (W3C), места, где согласуются веб-стандарты

HTML начался 25 лет тому назад, предоставив контент и ссылки, изначальные «плоть» и «скелет» веба. HTML5 до сих пор является основой веба ссылок и контента, но теперь он — еще и часть целой вычислительной платформы, отвечающая за пользовательский интерфейс. Теперь каждую страничку можно программировать, как компьютер. Это великая перемена, и мы можем лишь воображать, что будет создано в будущем на базе открытой веб-платформы.

Почему viewport — метатег?

0

Адам Брэдли спросил:

Брюс, <meta> — это ведь данные о данных, так почему же viewport — метатег, если он командует браузеру, что делать, а не описывает себя?

Маркос Касерес ответил:

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

HTML никогда не требовал наличия элементов <html>, <head> и <body> (только валидатор XHTML требовал этого). Так что если открыть тест 1 в любом браузере и просмотреть исходник, вы увидите, что этих трех элементов там нет. Но если изучить DOM в любом соотв. инспекторе, вы увидите, что браузер вставил эти элементы.

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

29

Перевод статьи 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 входят:

Посередине с элементом <center>

20

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

Элемент <center> — это потрясающе. Почему я избегал его все эти годы?

Это легче

Допустим, я собираюсь отцентрировать некий текст. В процессе поиска решения мой мозг сталкивается с «вилкой»:

  1. Я использую элемент <center>.
  2. Я не использую элемент <center>, а выбираю решение из множества вариантов на базе CSS.

«Блочные» Сcылки в HTML5

5

Одной из новых и захватывающих вещей, которые можно реализовать в HTML5 является возможность оборачивания ссылками блочных элементов.

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

Очевидно, что каждая новость должна иметь заголовок, и наверняка появится желание также добавить иллюстрацию и сделать эти блоки кликабельными. Разметка, вероятно, будет выглядеть как-то так:

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

45

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

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

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

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

Блок-схема алгоритма выбора структурных (секционных) элементов HTML5

15

Лёгкая для понимания блок-схема алгоритма выбора структурных (секционных) элементов HTML5. Она сможет помочь вам разобраться в предназначении некоторых новых элементов HTML5.

Здесь можно увидеть эту схему «в полный рост».

Источник схемы