HTML — это и есть веб

Автор оригинала: Pete Lambert
  • Перевод
Что нынче с HTML во фронтенде? В последнее время я разговаривал со многими разработчиками. Похоже, что некоторые даже не разбираются в HTML. В смысле, кое-что они понимают. Они понимают, что такое div и что такое span, и когда всё выглядит хорошо и работает по щелчку, им этого хватает. До такой степени, что многие на вопрос о HTML отвечают: «О, да я сейчас всё делаю в React или Vue». Но на самом деле не имеет значения, что вы пишете только Javascript. Если вы разрабатываете веб-сайты, то HTML — это самое главное для вас. Это и есть веб.

Речь о том, что потребляется пользователем. Это UI и UX. Вот весь пакет. В порядке убывания важности: HTML, CSS и поведение (которое может быть обеспечено Javascript — а может и нет).

Я вижу проблему внизу этой технологической пирамиды. Наименьший общий знаменатель Сети. Основа. Ритм-группа. Савоярди всех десертов веба. Это HTML. И мне всё больше кажется, что целый пласт фронтенд-инженеров не знают или не понимают главной технологии фронтенда.

Веб-страница — это документ. Любой компонент, будь то шаблон блога, новостной сайт, панель маркетинговой статистики или регистрационная формы — это часть документа. У документов есть структура. В интернете речь идёт не только о визуальных элементах или архитектуре, что предоставляет ваша платформа. Речь идёт о выборе семантически правильных элементов, чтобы ваша веб-страница, компонент, что угодно, была правильно структурно отформатирована. Заголовки должны быть заголовками, списки должны быть списками, кнопки должны быть кнопками, а таблицы должны быть таблицами. Вы можете стилизовать их (в значительной степени), как вам нравится — заголовок не обязан быть большим и жирным с отступом внизу. Это зависит от вас, но это определённо должен быть заголовок, и я могу с вами подраться, если сделаете его как div.

HTML ведь не так трудно выучить, особенно если вы уже знаете JavaScript-фреймворки. Я не считал, но вполне уверен, что там всего около 116 элементов, и большинство вам никогда не понадобится. Почему бы не выучить их?

Я из тех ребят, которые работают на самом краю фронтенда. Я занимаюсь HTML и CSS, поэтому мне легко призывать всех выучить то, что я уже знаю (для записи, я не знаю всего — у нас в офисе по-прежнему идут горячие дебаты, как лучше всего пометить определённый компонент). Дело не в том, что моя работа важнее вашей. Если вы пишете код, который что-то отображает в браузере, то это однозначно ваша работа.

Речь идёт о юзабилити и доступности. Если вы не считаете важной семантическую структуру вашей веб-страницы или приложения, по сути, вы говорите: «Ну, у меня всё работает, можно выпускать». Не думаю, что Javascript здесь достаточно, как и CSS. Поисковые системы должны читать ваш контент, а не наслаждаться стремительными анимациями или причудливыми градиентами. Скрин-ридер должен читать ваш контент. Пользователи без мыши должны работать с вашим сайтом. Кто знает, какая технология будет следующей и как она воспримет ваше приложение, но готов поспорить на последний биткоин, что ей наверняка поможет возможность легко читать, анализировать и перемещаться по контенту. Все эти технологии должны воспринимать содержимое как цельный контент, а не просто строки текста, завёрнутые в бессмысленные теги. Они должны видеть, что такое таблица и как её представить, что такое список и как его представить, что такое кнопка и что такое флажок. Сделайте всё div'ами — и им придётся чертовски потрудиться, чтобы распознать такие вещи.

«Но мой фреймворк берёт всё на себя. Я просто пишу шаблоны .jsx»

Нет. Напишите правильный HTML в своём JSX. Вы можете это сделать. Просто потому что вы используете React или Vue или что-то ещё, вы не обязаны всё писать div'ами. Не обязаны.

«Эта библиотека везде добавляет атрибуты WAI-Aria, так что с доступностью всё в порядке»

Отлично. Если бы вы написали правильный HTML, большинство этих атрибутов вообще не понадобилось бы. Вы бесплатно получаете целую кучу функций accessibility, просто используя реальный button вместо div с обработчиком событий onClick. БЕСПЛАТНО. Это доступность, производительность и удобство для пользователя, бесплатно. БЕСПЛАТНО!

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

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

  • Узнайте, как разметить документ в HTML. Попробуйте простые мысленные упражнения, когда смотрите на концертный плакат или газетную страницу — и представляете, как она будет структурирована в HTML. Если есть время, напишите этот HTML. Используйте эти знания в повседневной работе.
  • MDN — отличный ресурс с блогами, учебниками и полезными ссылками.
  • Обратитесь к людям в сообществе. Читайте блоги (например, недавний пост Энди Белла об использовании семантического HTML) и смотрите видео.
  • Когда я учился, просмотр исходников был ещё полезен. Мы коллективно сломали это для нынешнего и будущих поколений, но могу впечатлить вас мощью «Инструментов разработчика» в браузере
  • Узнайте, как работают в вебе ассистивные технологии
  • Посмотрите на спецификации HTML или даже просто на список HTML-элементов и примеры их использования
  • Если вы работаете в команде, обсудите разметку. Реально поспорьте, будет правильно вставить какой-то элемент в виде table или dl (Description List Element, MDN). Будет очень весело, обещаю.
  • Узнайте, кто в вашей команде лучший знаток HTML, и попросите его просмотреть ваш код. Если это я, всегда рад поговорить.
Поддержать автора
Поделиться публикацией

Комментарии 39

    +1
    Веб — это давно уже не просто документы. Теперь это в основном приложения, исполняющиеся в браузере. И HTML тут является просто контейнером для кода приложения и языком разметки страниц.
      +11
      И всё-таки автор прав насчёт того, что в JSX или .vue не обязательно использовать только div'ы.
        –3
        Проблема в том что HTML пытаеться усидеть на двух стульях. К примеру админка сайта — это приложение исполняющееся в браузере и там семантика не нужна. А сам сайт это привычный всем HTML где важно донести структурированный контент. Вот и разрывается бедняга.
          0

          Пользователь не смотрит на разметку, контент структурируется для него визуально, используя (сюрприз!) JavaScript и CSS.


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

            0
            Проблема в том, что многие программисты/верстальщики не знают, что страница, далеко не всегда, делается только для того чтобы ее увидел посетитель в окне браузера.
            Например — страница должна быть верно понята поисковым роботом, что в рамках React, Vue и прочих замечательных реактивных фреймворков (а точнее того как их привыкли использовать) превращается в трудно выполнимую задачу. Даже с использованием SSR.

          +10
          Проблема в том, что когда, например, мне кто-нибудь прислал ссылку на какую-то статью, я хочу прочитать эту статью. Я как пользователь хочу увидеть буквы на экране, и больше не хочу ничего. Страница со статьёй — это как раз таки «просто документ». Делать из сайта со статьями single-page application — это просто верх оверинжиниринга. Такой сайт можно сделать вообще без строчки JS, тем не менее, мне пару раз попадалось нечто, где отдаваемая с сервера страница не содержала даже текста статьи, он подгружался дополнительным ajax-запросом и появлялся секунд через 10 после начала загрузки. Вы считаете, что так и должно быть?
            0
            Мой первый сайт был в одном файле index.php… О времена )
              +1
              Мой первый сайт был в index.htm, а php тогда еще был малоизвестным и динамику клепали через CGI в основном на perl/bash.
              И да, я не очень представляю, как можно знать javascript, знать JS фреймворки и не знать HTML..., тем более что на HTML+CSS можно делать многие вещи без JS вообще.
              0
              О да! Плюсануть не могу (кармой не вышел), но всеми руками «за». В этом как раз и выражается современный веб. Научить на курсах использовать вагон фреймворков могут легко, а вот думать «зачем» — нет. Мы уже тонем во всём этом. Растущие мощности железа явно не успевают за результатами плодящихся методом курсования веб-разработчиков.
                0
                Да тут даже не «думать зачем», а понимать их внутреннее устройство и, следовательно, уместность использования в том или ином проекте. В современном программировании, по-моему, в целом не принято о таких мелочах думать. Чем больше низкоуровневого от себя спрячешь за ненужными абстракциями — тем лучше. Определённые инструменты полезны в одних ситуациях и вредны в других, но в программировании почему-то считается, что есть какая-то одна истина для всех, и она в том, чтобы непременно быть в тренде. Это вот всякие вещи уровня «почему ты верстаешь таблицами в 2019». Да, я верстаю таблицами, а не дивами, а на календарь посмотреть забыл, простите. Моя вёрстка подсвечивает нужные пиксели на экране нужными цветами и, прости господи, даже в IE6 не разъезжается, что вам ещё-то нужно?!
                  0
                  Чем больше низкоуровневого от себя спрячешь за ненужными абстракциями — тем лучше.

                  В целом так оно и есть, да. И этому есть логичное объяснение: так быстрее и дешевле разрабатывать (если не перегибать палку, конечно, с абстракциями). Грубо говоря, сделать "статический" сайт со статьями на голом PHP+MySQL+HTML+CSS+совсем немного JS дольше и дороже, чем сделать примерно ту же функциональность, "обернув" сайт на основном стэке SPA на Laravel+Eloquent+React+Redux

                    0
                    Все так. Увы. Слепое следование за модой. И еще больше фреймворков! Потому, нынче, чтобы положить любой комп на лопатки не нужны никакие специфические программы — просто откройте побольше вкладок браузера.
              –1

              Автор очень однобоко смотрит на ситуацию ставя лозунги о доступности и мертвую семантику превыше всего.

                +4

                Автор может и сгущает краски по поводу доступности, однако текущее состояние фронтенда таково, что реакт бездумно засовывают даже туда, где более уместна просто семантичная верстка с минимумом js.

                  +4

                  Ну Реакт головного мозга — это хоть и наболевшая, но, все-же, отдельная проблема. Ей также стоило бы посвятить статью.

                    0

                    Что вы считаете более правильным в общем случае: react с семантичным html или статическую вёрстку на дивах?

                    +1

                    Как раз та семантика, про которую говорит автор – живая (правильный тег дает браузеру минимально необходимую функциональность, скринридеру – правильную роль, и т.д.). Не вся семантика одинаково бесполезна:)

                    +6
                    Можно ездить на «Феррари» и ничего не понимать в ДВС.
                    Но нельзя собирая автомобиль не знать принципа работы четырехтактного двигателя.
                    Вот что хотел донести автор.
                    Сегодня многие «разработчики» грешат тем что не знают основы, в данном случае HTML.
                    И потом появляется такое -
                    Я сделал автомобиль


                      +2
                      Забавно наблюдать как меняется мода в вебе, сначала писали нативные onclick и properties (2000-й год), потом решили, что так писать не правильно, начали выносить биндинги в отдельные js-модули и визуальную часть в отдельные css-модули (2010-й год), потом на современных фреймворках стало модно опять писать рядом с тегами биндинги (jsx) и стили (styled-components). Некоторым создателям современных решений полезно было бы почитать историю технологий и понять, почему в своё время сообществом был принят тот или иной подход, вместо того, чтобы промотировать ошибки 20-летней давности.
                      Автор этой статьи подходит довольно категорично, но нельзя не согласиться, что при современном подходе к разработке большая часть старых нароботок просто выбрасывается на помойку, причём не потому, что устарела, а просто из за невежества и неосведомлённости об их существовании.
                        +1

                        От нативных onclick в свое время отказались потому что типа нельзя навесить несколько разных обработчиков, да и делегирование событий не получится. Современные фреймворки эту проблему решают на своей стороне, ибо все шаблоны парсятся и компилируются в JS и делегирование событий работает само из коробки. Шаблоны уже не HTML, а некий DSL (даже шаблоны vue, которые выглядят валидным HTML).


                        А вот styled-components действительно выглядит шагом назад. Выглядят они противоестественно, писать их больно, а преимущество только одно — стили находятся рядом с разметкой.

                          +2
                          В JSX тоже нельзя навесить несколько обработчников на один элемент. Можно вызывать несколько сторонних функций из функции-обработчика, но это можно было сделать и с нативными биндингами html. Вообще паттерн Observer повсеместно использовался в vanilla-js именно из за возможности делать слабую связанность и отложенный биндинг. В React решили всё это выкинуть и сделать просто передачу функции. Что, приложения в наше время стали проще? Или разработчики менее компетентны? Мне кажется второе.
                            0

                            Никто не мешает вам в didmount/use effect вешать листенеры.

                          +1

                          С одной стороны вы правы, но с другой 20 лет назад условия были несколько другими. И то, что было отвергнуто тогда, сейчас может быть актуальным. И наоборот, то, что было лучшими походами тогда, сейчас, может быть, должно умереть, а не "диды так верстали и я буду".

                          +3
                          Просто нужно чётко проводить грань — что есть веб-приложения, а что есть набор объединённых «гипертекстовых» документов (контентный веб-сайт) размещённых в интернете.

                          Обычно при старте проекта отвечаю себе на такие вопросы:

                          1) Это что-то публичное и/или сео-чувствительное? Значит пишем по-нормальному — многостраничный сайт, с серверным роутингом и серверным рендерингом, в котором возможные личные кабинеты или сервисы заворачиваем в мини-spa. Немножко нужно с webpack-ом подшаманить. Но, допустим, в symfony он уже нормально интегрирован, очень удобно.

                          2) Если это внутренний сервис/инструмент… оно же веб-приложение — однозначно SPA (возможно в отдельный микросервис/репозиторий ). Ибо неизвестно куда заведут требования.

                          Параллельная команда клепает контентные (!) сайты на Ангуляре. При чём решение принимал вроде тим-лид. Без улыбки не взглянешь, столько боли постоянно: то маркетологов морозят от их требований, то героически SSR прикручивают, метр джаваскрипта на каждой странице (на которой только текст), мего спиннер при старте, 10 баллов в google-page-speed, зато роутинг клиентский… круто..)
                            +1
                            Если кратко о состоянии дел в отрасли:
                            <div class="site_wrap">
                              +7
                              Посыл статьи был ведь не в том, что React — это плохо, или Angular — это плохо, или не нужно делать SPA.
                              А в том, что если нужен заголовок, то почему не взять для этого тег заголовка (h1-h6), Почему нужно брать div?
                              Если нужна кнопка, это должна быть именно кнопка, а не кликабельный div, или span, или что-либо ещё.
                              Почему не взять для чекбокса input с типом checkbox, почему нужно городить что-то своё непонятное?
                              И в данном вопросе я готов подписаться под каждым словом автора.
                              И совершенно не важно что мы разрабатываем: сайт, админку, crm… Просто нужно использовать html-элементы по их прямому назначению.
                              Точно так, как мы стилизируем кликабельный div под требования дизайна, мы можем взять button и тоже придать ему необходимый вид. В чём проблема? Но в последнем случае, мы будем использовать элемент для того, для чего он и предназначен.
                              И писать правильно можно как на чистом html, так и в том же jsx. Ровно как и наоборот.
                                +1

                                Иногда очень сложно реализовать задумку дизайнера на семантически подходящих элементах. Вплоть до вроде бы они есть в Dom, но пользователь их не видит, фокус на них не получить ему никак.

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

                                  Но суть не в этом. Это все частные случаи. Здесь же речь идет о тотальной «дивизации» и полном игнорировании html как инструмента.
                                  +1
                                  Вот как раз со стилизацией нативных компонентов иногда всё плохо. Попробуйте, например, стилизовать select, округлые края, другая стрелочка, цвет фона… С другой стороны зачем трогать стандартный паттерн UI, который к тому же будет удобно выглядеть на всяких Android/iOS браузерах?
                                  +2

                                  При чтении таких статей с грустью вспоминаю про сайт Gmail.

                                    +2
                                    То что необходимо по-максимуму использовать семантические элементы — автор прав и это не обсуждается.

                                    Причина, по которой мы вынуждены отступать от семантики кроется в том, что в 99% случаев дизайнер рисует нам кастомный чекбокс, радио, select, switch(которого на минуточку вообще нет в браузере как такового), выпадающие списки, и вот это всё. И у нас есть несколько (от 2-х до 5-ти) браузеров, где вот это всё должно выглядеть одинаково и одинаково работать. Но разработчики браузеров по какой-то причине до сих пор (2019 год!) не реализовали возможность делать нативные чекбоксы (радио, select и пр.) кастомными без танцев с псевдоэлементами и js. Вот мы и вынуждены делать пляски в js.

                                    То что касается: раньше делали так, сейчас так и т.д. Друзья, раньше был dial-up, http, 2g интернет, сильно маломощное железо на пк и не было смартфонов (особенно с количеством памяти как сейчас). Вот и делали так, чтобы всё грузилось как можно скорее и как можно меньше запросов.

                                    Сейчас всё иначе, зачем нам оптимизировать какие-то 10-15 килобайт кода и изворачиваться ради этого, если у нас есть 8 гигов памяти на смартфоне и 4g! Естественно подходы поменялись. Сейчас у нас http2, es modules, мощное железо и вот это всё, даже в бандлах отпадает смысл. Разумеется, если ваша ЦА сидит в IE до сих пор на пентиумах 1, то никто не запрещает вам разрабатывать проект под это всё. Но давайте будем честны — мир изменился и продолжает меняться. Уверен, через несколько лет мы будем писать бэк на golang и фронт на flutter(dart) и все эти темы, которые обсуждаются сейчас станут неактуальными. Мир меняется)
                                      +2
                                      Я даже не поленился восстановить пароль, чтобы ответить на ваш коммент
                                      Стилизация чекбоксов, радио — это одна из самых простых вещей, label for + before
                                      Касательно select, switch уже менее принципиально, но тоже можно стилизовать
                                      И всегда можно послать дизайнера исправлять свое детище, если он не компетентен и нарисовал откровенную чушь

                                      «Вот мы и вынуждены делать пляски в js.»
                                      Велосипеды :)
                                        0
                                        Каждый раз, когда в глубинке по GPRS или за рубежом, по тарифам роуминга, пытаюсь найти крайне важную информацию, вспоминаю это «зачем нам оптимизировать какие-то 10-15 килобайт кода и изворачиваться ради этого, если у нас есть 8 гигов памяти на смартфоне и 4g»… А еще, когда на моем макбуке, при загрузке страницы стартует вентилятор, который молчит даже при просмотре 4К видео.
                                          0
                                          если у нас есть 8 гигов памяти на смартфоне и 4g!

                                          Достаточно отойти от берега на лодке миль на 10, и Фэйсбук уже перестает грузиться. Даже на сравнительно цивилизованной Средиземноморке.
                                            0
                                            если у нас есть 8 гигов памяти на смартфоне и 4g!

                                            У вас-то оно есть… а у ваших пользователей? ;)

                                              0

                                              При серьёзной ориентации на маломощные девайсы я всегда прошу у начальства эталонные. Не дают — отклоняю баги "тормозит" с причиной "не могу вопсроизвести".

                                              0
                                              Эй там, полегче! Если ты купил себе тело с восемью гигами памяти, то это не значит, что такое же тело автоматически появляется у всех остальных.
                                                +1
                                                Причина, по которой мы вынуждены отступать от семантики кроется в том, что в 99% случаев дизайнер рисует нам кастомный чекбокс, радио, select, switch(которого на минуточку вообще нет в браузере как такового), выпадающие списки, и вот это всё. И у нас есть несколько (от 2-х до 5-ти) браузеров, где вот это всё должно выглядеть одинаково и одинаково работать. Но разработчики браузеров по какой-то причине до сих пор (2019 год!) не реализовали возможность делать нативные чекбоксы (радио, select и пр.) кастомными без танцев с псевдоэлементами и js. Вот мы и вынуждены делать пляски в js.


                                                Лайфхак. Можно вообще не договариваться с дизайнером.)

                                                Уже давно объявил бойкот кастомным контролам от дизайнеров (особенно чекбоксам, радио кнопкам и выпадающим спискам). Браузер лучше всего отрисует контрол так как положено, как привыкли пользователи этого браузера. Максимум инпуты и cta-кнопки делаю как нарисовали. Более того, если это продукт для внутренних пользователей — даже кастомные попапы не делаю, обхожусь нативными алертом/prompt/confirm — т.к. именно для этого они и были придуманы и автоматом делают все действия (блокировка ui и т.д.), которые пришлось бы делать самому или подключать либу.

                                                Схема работает больше двух лет:
                                                Прилетает макет. Делаешь не обращая внимания на креативные контролы дизайнера, оставляешь их нативными. Более того, если с чем-то не согласен, делаешь по своему… как лучше (вы же знаете, да? фронтендер всегда доделывает за дизайнером..))
                                                Сделал. Закрываешь задачу. Приступаешь к следующей.

                                                Как правило, всех всё устраивает, т.к. главное это функционал. Более того, даже могут и не заметить разницу до 30% с макетом. Потому что опять же, на макет толком никто не смотрел, и внимательно сверять никто не будет. Ваша задача сохранить цветовую палитру, шрифты, контент и отступы.
                                                Если всё-таки замечают, что контролы не такие — заводят баг. Руководству говорим — что можем тратить время на кастомизацию контролов, а можем использовать это время для новой фичи. Как правило, баг остаётся в багтрекере навсегда, и никто по этому поводу не переживает.

                                                А потому что что? Потому что пользователям плевать на дизайн www.slideshare.net/AlexanderKirov/ss-19366795
                                                Главное — грамотный пользовательский сценарий и контент.

                                                Кстати, дизайнеры как правило отдают макет и на этом взаимоотношения заканчиваются. Поэтому и договариваться особо не с кем. Если же в команде есть продуктовый дизайнер в штате — то опять же… ставим вопрос на обсуждение… мы возимся с чекбоксами, или будет делать что-то более приоритетное?
                                                  0
                                                  «Хорошая» реклама места, где вы работаете. Если клиент хочет определенный дизайн и на это были отведены определенные сроки — значит они ожидают увидеть тот дизайн, который вы им продали, или есть определенная аналитика, возможно так же проработан рынок и очень странно, если вы «так» поступаете с вашими клиентами.
                                                  Не уверен, что в другой компании в нашей сфере вам нашлось бы место с таким подходом.

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

                                              Самое читаемое