HTML5

Всем привет, меня зовут Лена. Сейчас я делаю фронтенд в компании AISA и борюсь за вёрстку кнопок кнопками. В сообществе могу быть известна пока что только тем, что модерирую чат Веб-стандартов в Телеграме. В свободное время катаюсь на разных досках. Ну, и погнали к докладу.

Знаком ли вам такой диалог?

— А вы поддерживаете доступность на своём сайте?
— Да, у нас есть версия для слабовидящих.

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

Нет. Не нужно.

Не секрет, что в последние годы веб развивается крайне стремительно. Периодически выходят новые библиотеки, фреймворки и другие полезные для нас инструменты. Всё это безусловно помогает нам решать повседневные задачи. Но в погоне за популярными новинками мы совсем не обращаем внимание на истоки. Многие начинающие разработчики начинают знакомство с кодом именно с инструментов, а не с фундаментальных вещей. Обычно это связывают с тем, что сегодня подавляющее большинство вакансий для фронтенд-разработчиков напичканы «модными» и «хайповыми» словечками вроде «React», «Vue», «styled-components», и множеством других. Поэтому разработчикам важно изучать именно эти вещи, чтобы не остаться без работы. Но разве причина только в этом? Именно поэтому разработчикам не важны основы? Думаю, что только отчасти.

А в чём, собственно, проблема, и она точно есть?

Перевод статьи The failed promise of Web Components с сайта lea.verou.me, опубликован на CSS-live.ru с разрешения автора — Лии Веру

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

От веб-компонентов ждали такого же удобства, но для намного более широкого спектра HTML-элементов, и гораздо быстрее, поскольку никому не нужно было бы ждать весь цикл стандартизации и реализации. Просто подключим скрипт, и бац — в нашем распоряжении стало еще больше элементов!

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

Вот как выглядят корни дерева баньян. Фото Дэвида Стенли на Flickr (лицензия CC-BY).

С таким провокационным призывом на днях обратился к своим читателям в Твиттере не кто-нибудь, а Таб Аткинс, главный редактор львиной доли спецификаций CSS. Конечно, речь шла не о любых тегах, а об опциональных (необязательных), которые разрешает не ставить сам стандарт HTML. Но всё равно призыв Таба многих шокировал, очень уж вразрез он шел со всем, чему нас учили с самого начала веб-карьеры.

Может, Таб просто всех троллил? Или же в его совете есть рациональное зерно? Попробуем непредвзято разобраться.

Перевод статьи Why don’t we add a <lovely> element to HTML? с сайта www.brucelawson.co.uk, опубликовано на css-live.ru с разрешения автора — Брюса Лоусона

Вчера был интересный разговор, который начала Сара Суайдан:

твит Сары Суайдан (@SaraSoueidan), 8 октября 2018 г. в 16:36:

Вот что я хотела бы увидеть в HTML:
<color value=“” />
Просто. Чрезвычайно полезно, особ. для дизайн-систем сегодня.

Тут, пока никто второпях не подумал «но ведь цвет — это не контент, а оформление!», Сара говорила о страницах с палитрами образцов цвета. В этом случае цвета — именно контент. Кажется, что это хороший кандидат в семантические элементы, потому что у него есть значение.

На правах Древнего Старожила Веба, я сел и пораздумывал над этим.

Перевод статьи Understanding why Semantic HTML is important, as told by TypeScript с сайта medium.com для css-live.ru, автор — Мэнди Майкл

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

Из-за того, что внимание во фронтенд-разработке всё больше сосредотачивается на JavaScript, а про HTML все как будто забывают, недавно мне пришлось потратить какое-то время, пытаясь понять, как объяснить разработчикам, нацеленным на JavaScript, почему важно изучать и понимать HTML

Это натолкнуло меня на идею:

«Почему семантический HTML важен, и как Typescript помогает это понять»

Перевод статьи Links vs. Buttons in Modern Web Applications с сайта marcysutton.com для CSS-live.ru, автор — Марси Саттон

Github: ссылки или кнопки?

Одна из вечных тем во фронтенд-доступности — неразбериха между ссылками и кнопками. Ну, HTML-элементы, которые открывают ссылки в новом окне или отправляют форму, знаете? В веб-приложениях на JavaScript мы по-прежнему путаемся, какой элемент выбрать для пользовательского действия. Чтобы развеять туман, я покажу примеры использования для ссылок и кнопок в приложениях с отрисовкой на клиенте и помогу вам принимать лучшие решения с точки зрения UI.

Перевод статьи «The Document Outline Dilemma» с сайта css-tricks.com, опубликовано на css-live.ru с разрешения автора — Амелии Беллами-Ройдз

В последние несколько недель среди веб-стандартистов было много разговоров о HTML-заголовках. Возможно, вы видели какие-то записи в блогах, твиты и обсуждения разных ишью на Гитхабе. Заголовки — часть HTML начиная с самых первых сайтов в ЦЕРНе, так что может показаться странным, что спустя 25 лет в них нашлись какие-то противоречия. Я хочу сначала вкратце рассказать, почему это всё еще стоит обсуждения, а потом добавить собственные соображения по теме. Если вы сами следили за недавней дискуссией, можете перейти сразу к разделу «Более важная дилемма».

Перевод статьи Do we need a new heading element? We don’t know с сайта jakearchibald.com, опубликовано на css-live.ru с разрешения автора — Джейка Арчибальда.

В спецификацию HTML предлагают добавить новый элемент <h>. Это решает довольно частую задачу. Возьмем такой пример HTML:

Перевод статьи Understanding semantics с сайта tink.uk, опубликовано на css-live.ru с разрешения автора — Леони Уотсон.

Слово «семантический» уже слилось с веб-разработкой. Мы произносим «семантический код» и «семантика» элемента, но что это значит на самом деле и почему так важно?

Слово семантика происходит от французского «semantique» — «несопоставимый». А в английском у него есть три значения:

Перевод статьи Regressive Web Apps с сайта adactio.com, опубликовано на css-live.ru с разрешения автора — Джереми Кита.

На конференции Google I/O в этом году было немало докладов о разработке для веба. Приятная перемена по сравнению с прошлыми годами, когда о вебе едва вспоминали и можно было скорей подумать, что  Google I/O — конференция для разработчиков приложений под Андроид.

Последняя конференция показала, что Гугл очень большой и у него нет какой-то единой генеральной линии по поводу веба и нативных приложений. Хотя были доклады о сервис-воркерах и производительности для веба, были также представлены «Мгновенные Андроид-приложения» — неприкрытая атака на веб. Если вас раздражало, что сайты назойливо тыкали вам под нос всплывающие окошки с предложением установить их приложения, то подождите, скоро они смогут и не спрашивать.

Перевод статьи BEMantic: DRY Like You Mean It с сайта https://medium.com, опубликовано на css-live.ru с разрешения автора — Мэтта Стоу.

Недавняя статья Тима Бакстера на A List Apart, «Осмысленный CSS: описывайте стилями свою логику», подбросила дровишек в костер тому мнению, будто фронтендеры, предпочитающие объектно-ориентированный подход к CSS (БЭМ или что-то вроде), как-то напрочь забывают о семантической разметке и доступности.

Лично я считаю, что так думать просто обидно. Не понимаю, почему БЭМ и семантику HTML считают взаимоисключающими. Я тешу себя надеждой, что я хороший разработчик: я горжусь как своим HTML (включая семантику и ARIA-атрибуты), так и своим CSS, где вовсю используются Sass и БЭМ.

Перевод статьи Developer Fallacies с сайта heydonworks.com, опубликовано на css-live.ru с разрешения автора — Хейдона Пикеринга.

Время от времени веб-разработчики (и вообще программисты) находят неудачные аргументы в защиту своего выбора технологий, рабочих процессов или организационных схем, а также для принижения чужого выбора. Я видел такое не раз, да и сам порой не удерживался от крепкого словца по такому поводу. Мы особенно уязвимы для неудачных аргументов, поскольку привыкли считать себя логичными. Как же сильно мы порой заблуждаемся.

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

Перевод статьи Easy content organisation with HTML5  с сайта paciellogroup.com, опубликовано на css-live.ru с разрешения автора — Стива Фолкнера.

Чаще всего дизайнеры и веб-разработчики делят страницы на крупные области контента (будем называть их регионами). Поиск по картинкам на запрос «типовая структура страницы в HTML5» выдает множество примеров схематических изображений страниц, на которых обозначены похожие регионы:

Перевод статьи On PPK’s moratorium on new browser features с сайта https://dev.opera.com/, с разрешения автора — Брюса Лоусона

Знаменитый разработчик и автор множества статей Питер Пол Кох (PPK) недавно призвал к «мораторию на новые браузерные функции на год или около того». Если вы не читали его статью «Хватит толкать веб вперед», просмотрите ее: он выдвигает интересные тезисы, как всегда.