Html что это хабр

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

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

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

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

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

Читайте также:  Text when hover css

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

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

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

Читайте также:  Php composer phar could not open

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

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

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

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

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

Источник

HTML — это не XML

Многие считают, что html — это подмножество xml. И, соответственно, пишут код в том же стиле. Но это не так, между этими разметками есть различия. Есть некоторые правила xml, которые неприменимы в html.

Я рассмотрю три основные ошибки тех, кто пытается писать html в стиле xml.

1. Самозакрывающиеся теги

Первая и самая распространенная ошибка. Я много раз видел, как кто-то пытается закрыть html тег с
помощью/> Например, или
.
Но даже если элемент не имеет содержимого, все равно так писать нельзя. Потому как в отличие от xml
в html закрывать теги с помощью/> запрещено. Тег можно закрывать только явно, с помощью . Это не просто хороший стиль. Браузер воспринимает символ «/» внутри элемента как ошибку и игнорирует его. Элемент просто не закрывается.

Давайте посмотрим, как браузер обрабатывает такие теги. Выполним следующий html:

 
Красный
Продолжение красного
Следующий элемент

Все вроде бы нормально, но выглядеть это будет так:

Как видно, браузер не закрыл элемент, завершающийся/>. Его нужно было закрывать при помощи явного

.

И кстати, даже серьезные компании, бывает, пишут неправильно.

Html что это хабр

Яндекс.Метрика пишет свой img тег так:/>

2. Закрытие тегов

Хорошо, теги нужно явно закрывать. Значит, нужно всегда писать ? Нет. Не все так просто. Согласно спецификации в html некоторые теги нужно обязательно закрывать, некоторые необязательно, а некоторые запрещено.

  • Обязательно нужно закрывать div, span, script, table и footer;
  • Такие теги, как option, li, tr, body можно закрывать, а можно и нет. С точки зрения качества кода, конечно, лучше всегда закрывать теги, но стандарт разрешает не делать этого;
  • А вот некоторые теги, такие как input, br, img и hr закрывать запрещено. Если написать или
    — то это будет невалидный html. Такие теги нужно оставлять незакрытыми.

3. Запись булевых атрибутов

Как записывать булевы атрибуты в html (такие как checked и disabled)? Те, кто пишет html в стиле xml, случается, записывают их так:
Так делать не нужно. В html нет значения «true». Стандарт говорит, что если атрибут заявлен в разметке, то его значение уже true.

Можно выбрать один из трех вариантов записи:

Я предпочитаю использовать короткий третий вариант, вроде: .

P.S. Эти правила относится к html, а не к xhtml. Однако даже если ваша страница оформлена как xhtml, браузер будет
разбирать ее как html, если сервер отдает ее с mime-type ‘text/html’. Для того, чтобы странице стать действительной xhtml, ее mime-type должен быть ‘application/xhtml+xml’. Только тогда браузер будет парсить эту страницу по xml правилам.

Источник

Оцените статью