Содержание
«Не закрывайте теги!» — CSS-LIVE
С таким провокационным призывом на днях обратился к своим читателям в Твиттере не кто-нибудь, а Таб Аткинс, главный редактор львиной доли спецификаций CSS. Конечно, речь шла не о любых тегах, а об опциональных (необязательных), которые разрешает не ставить сам стандарт HTML. Но всё равно призыв Таба многих шокировал, очень уж вразрез он шел со всем, чему нас учили с самого начала веб-карьеры.
Может, Таб просто всех троллил? Или же в его совете есть рациональное зерно? Попробуем непредвзято разобраться.
Какие теги можно не закрывать?
Так и хочется воскликнуть «Никакие!» :). Но давайте всё-таки обратимся к стандарту. Он разрешает опускать не только 19 закрывающих тегов, но и 5 открывающих. Все они, вместе с условиями, когда это можно делать, явно перечислены в целом одном страшно секретном разделе 12.1.2.4. И еще 14 тегов закрывать просто нельзя.
В таблицах ниже я попытался максимально упростить формулировку условий из спецификации (если где-то перестарался — прошу поправить):
Необязательные открывающие теги
| Тег | Когда можно не писать |
|---|---|
<html> | Если перед ним не идет <!-- комментарий --> |
<head> | Если перед ним не идет <!-- комментарий --> |
<body> | Если body начинается не с <!-- комментария -->, пробела, либо одного из тегов, который может быть и в head |
<tbody> | Перед <tr>, если перед ним нет незакрытого thead, tfoot или другого tbody |
<colgroup> | Перед <col>, если перед ним нет незакрытого другого colgroup |
Нельзя опускать открывающий тег, если у него есть какие-либо атрибуты (напр.
lang для <html>). Также открывающий <body> необходим, если его первым потомком должен быть script, link или другой элемент, который может быть и в head — иначе он попадет именно туда.
Необязательные закрывающие теги
| Тег | Когда можно не писать |
|---|---|
</html> | Если после него не идет <!-- комментарий --> |
</head> | Если после него не идет <!-- комментарий --> или пробел |
</body> | Если после него не идет <!-- комментарий --> |
</li> | Перед <li> или </ul>/</ol> |
</dt> | Перед <dt> или <dd> |
</dd> | Перед <dt>, <dd> или концом родителя |
</p> | Перед открывающим тегом любого не-фразового потокового («блочного» по-старому:) элемента, либо закрывающим тегом родительского элемента (если у того не прозрачная модель контента) |
</rt> и </rp> | Перед <rt>, <rp> или </ruby> |
</optgroup> | Перед <optgroup> или </select> |
</option> | Перед <option>, <optgroup>, </optgroup> или </select> |
</colgroup> | Если после него не идет <!-- комментарий --> или пробел |
</caption> | Если после него не идет <!-- комментарий --> или пробел |
</thead> | Перед <tbody> или <tfoot> |
</tbody> | Перед другим <tbody>, <tfoot> или </table> |
</tfoot> | Перед </table> |
</tr> | Перед <tr> или концом родителя |
</td> и </th> | Перед <td>, <th> или концом родителя |
Общее правило: закрывающие теги обычно не нужны для однородных сущностей в специализированных контейнерах (пунктов списков, внутренних частей таблиц и т.
п.). Напрямую вложенными друг в друга они не бывают, ничего другого в их родителе тоже быть не может, так что если начался следующий — логично, что предыдущий закончился.
У правила для <p> общая логика похожа, но оно сложнее и потому стоит особняком (мы к нему еще вернемся).
А условие про HTML-комментарий означает лишь требование предсказуемости итоговой DOM. Например, что без явного тега нельзя вставить этот комментарий снаружи элемента. Это всё равно не будет ошибкой, просто в итоговой DOM комментарий окажется внутри него.
Теги, закрывать которые нельзя
Это пустые (void) элементы: area, base, br, col, embed, hr, img, input, link, meta, param, source, track, wbr.
Многие поспешат возразить: «Это же самозакрывающие(ся) теги, у них свой способ закрытия — слеш перед >!».
Что ж, их ждет сюрприз: в HTML этот слеш… не значит ничего! Он не считается ошибкой, чтобы было легче переходить с XHTML, но «самозакрытыми», точнее, не требующими закрытия, их делает не слеш, а «зашитый» в алгоритм парсинга список этих пустых элементов. И «закрыть» по аналогии, скажем, <div /> нельзя — для HTML это будет открывающий тег (притом уже с ошибкой). Только для SVG- и MathML-элементов (напр. <g />) этот слеш означает честное «самозакрытие» (т.е. сокращение для <g></g>).
Аргументы против незакрытия тегов
«Это невалидный код!»
Необязательные теги — часть стандарта HTML. Значит, код, использующий их по правилам, валиден (точнее, соответствует этому стандарту). Так что это — невалидный аргумент:)
Нельзя полагаться на механизм исправления ошибок в браузерах
Вообще-то, в HTML5 алгоритм исправления ошибок «зашит» в стандартный алгоритм парсинга, и все браузеры клянутся, что соблюдают этот стандарт.
Так что ошибочная запись <a href="...">раз<a href="...">два</a> везде даст две ссылки подряд, а не вложенную ссылку.
Но я согласен: полагаться на ошибочное поведение чего бы то ни было — очень, очень плохая идея.
Вот только разрешенные необязательные теги — не ошибка. А хоть и непривычный, но вариант правильного HTML-кода. И этот аргумент валидный — но мимо:)
Хрупкость
Часто говорят, что код с незакрытыми тегами легче сломать чем-то непредвиденным. Но давайте поищем конкретную ситуацию, где это проявится.
Например, вдруг в нашем шаблоне появился HTML-комментарий. Давайте честно: на что может повлиять, добавится этот комментарий внутрь неявного <head> или <body> или снаружи?
Или возьмем динамически генерируемый список. Если внутрь нашего пункта списка попадет другой <li>, то пункт развалится на два — но это произойдет независимо от того, явно он был закрыт или неявно.
Еще в <head>...</head> нередко попадает то, что не может там находиться. Например, что-то, что браузер считает выводимым на экран текстом (в подключаемых PHP-шаблонах это часто могла быть BOM-метка). Это сразу же неявно закрывает </head> и открывает <body>. И снова независимо от того, где и как стояли соотв. теги.
Другое дело, если кто-то возьмет и не закроет другой тег, скажем, </div> или тот же </a>. Но это уже проблема нарушения стандарта (равно как и закрытие тега в неподходящем месте!). Ее решение — валидация кода (в т.ч. автоматическая, на этапе сборки/CI). И оно снова не зависит от наличия/отсутствия необязательных тегов!
Может быть, в комментариях вы подскажете более убедительный пример, где именно легально незакрытый тег будет причиной хрупкости?
Несовместимость с XML (и JSX)
Факт: HTML и XML — разные языки (а JSX — вообще де-факто третий, хоть отчасти и «косплеит» XML внешне), и правила у них разные.
Если нужно соблюсти и те, и те, то, конечно, без явного закрытия тегов никак. Другой вопрос, где и зачем сегодня нужна совместимость HTML с XML?..
Несовместимость с редакторами и IDE
Многие редакторы кода при подсветке синтаксиса, сворачивании ветвей и т.п. привязываются к явным закрывающим тегам. Некоторые даже закрывают их автоматически. Что ж, правила инструментов тоже желательно соблюдать. Только стоит отличать их от правил языка.
Несовместимость с кодстайлами и рабочими процессами
Аналогично: если в проекте принят какой-то дополнительный стандарт оформления кода помимо синтаксической корректности HTML — будь то лимит длины строк или требование явно закрывать теги — его тоже надо соблюдать. Но он не должен становиться самоцелью: если на его соблюдение уходит слишком много сил и он мешает использовать какую-то стандартную возможность языка, удобную для конкретной задачи — может, легче будет его пересмотреть или перейти на другой?
Трудность чтения
Большинству из нас, наверное, читать код с незакрытыми тегами труднее: нет привычных маркеров конца элемента.
Правда, это во многом вопрос привычки и форматирования исходника (см. далее). Но привычка — важный фактор, не поспорить. Особенно в команде.
Сложность правил для запоминания
Таблицы с правилами, когда какой тег можно не закрывать, выглядят внушительно. И это я еще их упростил! Даже сам Таб Аткинс в исходном твиттерском треде запутался, какие теги неявно закрывают <p>, а разница между случаями, когда открывающий <body> обязателен, а когда нет, навскидку еще менее интуитивна. Не лучше ли вместо этого вот всего запомнить одно простое правило «всегда закрывай все теги!»?
Увы: одним простым правилом от HTML не отделаешься:). Как минимум 14 исключений — пустые элементы, которые закрывать нельзя — помнить всё равно надо. А что еще важнее, явное закрытие тега не гарантирует, что элемент действительно закончится именно в этом месте (мы уже мельком видели пару примеров, дальше будет больше). Но разве в других языках нет таких «странных» правил? Одна таблица приведения типов в JS чего стоит.
Простота записи поощряет бардак в коде
Занятно, что этот аргумент часто сочетается с предыдущим.
Да, код в стиле «ляпнул открывающий тег и вперёд» может показаться небрежным и «несерьезным». Но это тоже вопрос привычки. Пример обратного — Markdown: одна звездочка — один пункт списка и никаких «закрывающих тегов», при этом в коде полный порядок и читать его — одно удовольствие. Но да, Markdown и HTML — тоже разные языки:)
В любом случае, закрыть тег много ума не надо не так уж сложно (тем более часто это на автомате делает IDE). Сложнее поставить его там, где надо, по правилам языка. Но не поставить его там, где можно по стандарту и уместно по задаче — сложность примерно сопоставимая. Ниже мы увидим, что чтобы писать правильный HTML — хоть с явными тегами, хоть без — его всё равно придется знать.
Явное лучше неявного
Безусловно!
Когда между ними действительно есть выбор.
Увы, с HTML это не всегда так (подробности чуть ниже).
Аргументы за незакрытие тегов
Всего лишь сокращенная запись
В XML были две равнозначные записи элемента без содержимого — полная (<tag></tag>) и сокращенная (<tag/>). Вторая почему-то до сих пор популярна даже в HTML, хотя там этот слеш ничего не значит (см. выше).
Точно так же и в HTML по сути есть две равнозначные записи конструкции «конец элемента и начало следующего» — полная (напр. </p><p>) и сокращенная (напр. <p>). Т.е. формально в обоих случаях эти теги закрыты, просто не всегда очевидным образом.
Экономия трафика
Принцип прост: если не видно разницы — зачем платить писать (и гонять по сети) больше. Древний «гайд» по оформлению HTML/CSS от Google так этот совет и формулировал: «байты — деньги».
Это может быть и вправду актуально для Гугла с его объемами трафика. Для остальных это скорее всего экономия на спичках. Особенно с gzip или еще лучшими новыми алгоритмами сжатия.
Но протестировать всё равно не помешает:)
Экономия памяти
Любые символы между тегами — включая пробелы и переносы строк — попадают в DOM в виде текстовых нод. В эпоху верстки инлайн-блоками эти ноды-пробелы доставляли немало хлопот (и одним из решений как раз было не закрывать теги:). Сейчас это неактуально, но сами ноды никуда не делись. Так что в DOM списка с закрытыми тегами <li> на самом деле будет вдвое больше нод, чем в DOM списка с незакрытыми (при обычном форматировании исходника, без минификации):
See the Pen
poJKLzb by Ilya Streltsyn (@SelenIT)
on CodePen.
И эти лишние ноды — полноценные DOM-объекты, с кучей свойств и методов. Другой вопрос, так ли много места они занимают в памяти и сильно ли это влияет на производительность страницы (как всегда, надо тестировать и измерять!)
По правде, этот аргумент выходит не столько за незакрытие тегов, сколько за минификацию кода для продакшна, с убиранием всех ненужных пробелов и т.
д. Хотя тот же минификатор можно настроить и на вырезание необязательных тегов. Если тесты покажут, что от этого есть толк. Добавлено 26.03.2020: к счастью, проблемы минификаторов 10-летней давности, не всегда умевших отличить необязательный тег от обязательного, остались в прошлом – нынешняя версия html-minifier использует честный HTML5-парсер и, если не злоупотреблять опциями с «невалидным HTML» на выходе, ничего не сломает.
«Защита от дурака»
Вопреки стереотипу, что «явно закрытые теги надежнее», эти добавочные сущности в DOM — еще и новые потенциальные точки отказа, если случайно поставить закрывающий тег не там:
See the Pen
KKpGBqO by Ilya Streltsyn (@SelenIT)
on CodePen.
Причем для абзацев это и валидатор пропустит. Неявно же элементы закрываются только сразу перед другим элементом, и такой неуправляемый «неприкаянный» текст заведомо не появится.
Удобство чтения
Как ни странно, некоторым проще читать код без закрывающих тегов. Для людей программистского склада, привыкших держать все сущности в контейнерах, это звучит дико, но тем, кто больше работает с текстом, часто привычнее думать о разделителях абзацев, пунктов списка и ячеек таблицы. Именно разделители используются в редакторах типа Word, вышеупомянутом Markdown… и HTML задумывался так же (в одном из ранних черновиков те же <p>, <li> и т.п. так и были одиночными разделителями, вроде <br>).
Сравните две разметки таблицы с внешне идентичным результатом:
<table>
<caption>Цены на продукты<caption>
<thead>
<tr>
<th>Продукт</th>
<th>Февраль</th>
<th>Март</th>
</tr>
</thead>
<tbody>
<tr>
<th>Гречка</th>
<td>80</td>
<td>120</td>
</tr>
<tr>
<th>Соль</th>
<td>5</td>
<td>15</td>
</tr>
<tr>
<th>Икра</th>
<td>1500</td>
<td>900</td>
</tr>
</tbody>
</table>
<table>
<caption>Цены на продукты
<thead>
<tr>
<th>Продукт <th>Февраль <th>Март
<tbody>
<tr>
<th>Гречка <td>80 <td>120
<tr>
<th>Соль <td>5 <td>15
<tr>
<th>Икра <td>1500 <td>900
</table>
Правда, тут повезло, что вся таблица и текст в ячейках короткие, а хороший кодстайл должен быть универсальным и не зависеть от везения.
.:)
Лучшее понимание специфики HTML и защита от сюрпризов
Этот аргумент Таба я вынес отдельно, чтобы он не затерялся (и выделил ключевые, на мой взгляд, слова жирным):
Еще одна причина привыкнуть к этому [не ставить необязательные теги] — то, что HTML-парсер будет делать это [достраивать DOM] в любом случае, и вы сможете заодно выучить соответствующие правила, так что не споткнетесь на этом. Если вы используете закрывающие теги с бездумным фанатизмом, вы можете *полагать*, что знаете, где заканчивается элемент, но окажетесь неправы!
Частый вопрос на форумах, StackOverflow, да и в жизни верстальщика: «Почему мой список внутри абзаца не отображается как надо?» Во всех руководствах по HTML <p>...</p> — пример блочного контейнера. С детства мы помним, что абзац — это «законченная мысль», так что если она включает в себя список чего-либо, подводку к нему и некий итог — логично, чтобы всё это было в одном абзаце.
Вот открывающий <p>, вот список внутри, вот закрывающий </p>, всё закрыто в правильном порядке… Почему же в DOM-инспекторе список оказался снаружи абзаца?
Да, иногда привычка «мыслить контейнерами» и безоговорочно доверять явным тегам может оказать медвежью услугу не только новичку, маскируя неочевидное поведение парсера. А новичку здесь и валидатор мало поможет: «Найден закрывающий тег без открывающего…» — ну как же его нет, когда вот он? Ладно, <p> допускает лишь «фразовое» («строчное», по-старому) содержимое, а список к нему не относится — но ведь другие теги, даже насквозь «строчный» <span>, от точно такой же неправильной вложенности не рвутся!
А вот знание, что закрывающий </p> необязателен, и открывающий тег любого «блочного» (по-старому) элемента — его стандартный эквивалент, эту ситуацию бы предотвратило. Мы бы сразу обернули эту «мысль» не в <p>., а во что-то другое, без неявного закрытия — хоть 
..</p><div>. Что, кстати, рекомендует и спецификация.
Аргумент против тегов вообще
Браузерам, по большому счету, вообще плевать на теги. Они отображают не разметку, а DOM, и оперируют лишь DOM-элементами и их свойствами. DOM может строиться по-разному, и в современном мире куда чаще она строится скриптами, а не парсится прямо из разметки. Разметка — лишь один из способов описания будущей DOM в текстовом формате, в принципе не лучший для машины, зато более понятный для человека.
А люди в наше время тоже редко пишут разметку руками. Чаще эту скучную механическую работу за нас делают инструменты — препроцессоры, шаблонизаторы и всё такое прочее. И это их задача — ставить те теги, которые надо, где надо и как надо, чтобы парсеры, со всеми их странностями и документированными причудами, всё правильно поняли. Их, а не наша.
Не в том ли причина многих проблем нынешней веб-отрасли, что истинную природу веб-платформы от разработчиков всю их жизнь вольно или невольно скрывают — сначала за тегами (и пустяками типа их регистра, словно мы до сих пор в 90-х), а затем за абстракциями фреймворков?.
.
Заключение
Думаю, подытожить эту статью можно примерно так:
- Необязательные теги — не ошибка, не «магия», не «браузерная самодеятельность» и т.п. (как часто считают), а документированная особенность стандарта. По сути — еще один инструмент HTML, такой же, как и закрывающие теги. Можно спорить, входят ли они в «The good parts» языка HTML (скорее всего нет!:), но в некоторых задачах (напр. для экстремальной оптимизации) они могут быть полезны;
- Почти все валидные аргументы и за, и против необязательных тегов сводятся к двум фразам: «делайте, как вам удобнее», и «делайте, как у вас (в проекте, в команде, в настройках окружения и т.д.) заведено». Ну и еще «смотрите по задаче и тестируйте!».
Поэтому в подавляющем большинстве случаев все необязательные теги лучше всё-таки ставить. Не потому, что «Так Надо, Ибо Воистину ©», или будто это автоматически «сделает код надежнее», а лишь потому, что:
- так удобнее и понятнее большинству разработчиков;
- так настроено по умолчанию большинство инструментов.
Код должен решать свою задачу. Задача исходников — не столько инструкция для браузеров (им-то стиль кода не важен), сколько коммуникация между разработчиками. Понятнее для большинства — коммуникация лучше.
Но не забывайте, что бывают люди и с другими предпочтениями. И увидев у кого-то непривычный стиль валидного кода, не спешите тыкать пальцем «гы-гы, вот ламер, даже теги не закрыл». Лучше поинтересуйтесь, почему так сделано. Некрасиво — не обязательно плохо, а непривычно — не всегда некрасиво. Иногда красота проявляется лишь в целой картине.
А вообще в веб-платформе масса вещей, куда более важных, чем стиль написания тегов или спор между табами и пробелами. Та же доступность хотя бы!
И всё-таки, к одному из аргументов я хотел бы вернуться. В общем-то, ради него я и затеял эту статью:)
Веб-платформа большая и сложная. В ней много неизвестного и непонятного — даже для авторов спецификаций. Сложность и неизвестность пугает. Это естественно.
И людям естественно успокаивать себя, отгораживаться от своих страхов приметами и ритуалами. Сплюнул через левое плечо — «беда обойдет». Успел потрогать пуговицу перед черной кошкой — «неудача отступит». Написал тег со слешем — «код не сломается». И т.п.
Не надо так. Приметы не работают. Единственная настоящая защита против неизвестности — знание. Не бойтесь узнавать новое. Даже в том, что другие считают «элементарным». В технике нет мелочей. А HTML — давно не смешные буквы в угловых скобках, а целая колоссальная экосистема. В ней надолго хватит места самым неожиданным открытиям.
А лучший способ изучить что-либо — эксперимент. И у веба огромное преимущество перед, скажем, ядерной физикой или генетикой, что здесь в экспериментах «для себя» иногда можно нарушать правила и смотреть, что из этого выйдет — ничего действительно страшного не случится. Зато станет понятнее, почему правила именно такие. И вообще — а правила ли это (а не реликт совсем другой эпохи с совсем другими ограничениями, скажем — это я не про закрытие тегов, а абстрактно:)
Так что не бойтесь экспериментировать! И пусть с каждым днем всё больше особенностей веб-платформы становится для вас не странной «магией», а понятным и предсказуемым инструментом.
Который при ненадобности всегда можно отложить в дальний ящик, но иногда, если задача того потребует, использовать на радость себе и пользователям.
P.S. Это тоже может быть интересно:
Знакомство с тегами.
Урок 3.
Прежде чем разобраться в структуре созданной нами страницы, нужно понимать, что такое теги. Теги являются основной составляющей html.
С помощью тегов мы можем добавить на нашу страницу различные объекты (текст, таблицы, картинки, ссылки). Так же с помощью тегов мы можем влиять на внешний вид этих объектов (цвет, размер). В созданной нами странице написано «Здравствуйте! Это моя первая веб-страница!», данный текст написан без использования тегов. С помощью определенных тегов, мы можем сделать так, чтобы эта надпись выводилась браузером на экран, например курсивом, либо жирным шрифтом.
Этот урок один из самых важных. Я рекомендую отнестись к нему серьезно. Если Вы прочитаете первую половину урока и что-то не поймете — не огорчайтесь, приступите к выполнению практической части, она, как правило помогает разобраться во всех вопросах.
Правила написания тегов.
Теги всегда пишутся в треугольных скобках. Сначала идет открывающийся тег, он состоит из треугольных скобок и названия самого тега. Внутри тега находиться какой-либо контент (текст). Далее тег нужно закрыть. Закрывающийся тег выглядит так же как открывающийся, но перед названием тега ставиться слэш.
Пример написания тега:
Бывают теги которые не нужно закрывать, для их работы нужно только открыть тег. Таких тегов очень мало, о них мы поговорим позже. Практически все теги необходимо закрывать, если не закрыть тег, который по своим правилам требует закрытия, то это будет грубейшая ошибка. Один не закрытый тег может сделать так, что вся ваша html страница будет отображаться браузером некорректно.
Правило закрытия тегов.
Часто бывает, что внутри тега, помимо текста располагаются еще другие теги. В этом случае теги закрываются в зеркальном порядке, то есть первым будет закрыт тот тег, который был открыт последним.
Пример правильного закрытия тегов:
Параметры тегов.
С помощью параметров (атрибутов) тега мы можем задать нужный нам цвет или размер текста, находящегося внутри этого тега. Значение параметра пишется в кавычках.
Пример написания тега с параметром (атрибутом):
Параметров у тега может быть несколько. Например цвет и размер. В этом случае параметры указываются через пробел.
Пример написания тега с несколькими параметрами:
Применим знания на практике.
Нажимаем правой кнопкой мыши на созданный нами файл и выбираем «Edit with Notepad++» (открыть с помощью Notepad++).
Открыв файл мы видим уже знакомый нам html код, который мы вставляли ранее:
В этом уроке мы будем акцентировать внимание на строке с текстом «Здравствуйте! Это моя первая веб-страница!». Пока что не обращайте внимание на другие строки, это структура html страницы, ей будет уделен следующий урок.
Текст «Здравствуйте! Это моя первая веб-страница!» написан без использования тегов и параметров (атрибутов), соответственно при запуске файла через браузер, данный текст имеет стандартный размер и цвет.
Теперь сверните Notepad++ и давайте параллельно откроем наш файл в браузере. Сейчас наша страница выглядит так:
Первый тег, который мы изучим на практике — это тег <b>. Данный тег служит для того, чтобы сделать текст жирным. Тег <b> требует закрытия, по этому правильное применение будет выглядить так:
Теперь давайте вернемся в Notepad++ и добавим тег <b> в наш html код. Мы сделаем нашу надпись «Здравствуйте! Это моя первая веб-страница!» жирной. Для этого мы заключаем данный текст в тег <b>.
Теперь наш код выглядит так:
* Все html коды которые я размещаю — нельзя скопировать, это сделано специально для того, чтобы Вы прописывали все теги в ручную. Это полезно.
Итак, тег <b> успешно добавлен в код, и теперь, чтобы изменения вступили в силу, нам нужно их сохранить. Для этого нажимаем в верхнем меню кнопку «Файл», далее нажимаем «Сохранить». Так же процедуру сохранения можно делать с помощью горячих клавиш (Ctrl + S), это удобней.
Теперь заходим в браузер, в котором открыта наша страница. Мы внесли изменения в код и сохранили их, но браузер этого еще не знает. Чтобы сообщить браузеру об изменениях, нужно обновить страницу, для этого нажимаем на клавиатуре «F5».
Сейчас Вы должны увидеть результат применения тега <b>, надпись должна стать жирной, как на рисунке:
Теперь давайте удалим из нашего кода тег <b> и пропишем вместо него тег <font>. Данный тег так же необходимо закрыть. Теперь наш код выглядит так:
Сохраните изменения в notepad (нажатием Ctrl + S), зайдите в браузер, обновите страницу (нажав F5). Сейчас мы видим, что надпись отображается обычно, так же как до использования тегов. Это значит, что тег <font> ничего не поменял. Это все потому, что данный тег не работает без параметров (атрибутов). Тег <font> лишь указывает браузеру на то, что внутри него (между <font> и </font>) находится текст.
Для этого тега мы можем задать параметры color (цвет) и size (размер текста).
Сейчас давайте сделаем нашу надпись зеленой. Для этого мы зададим тегу <font> параметр color (цвет) и дадим ему значение green (зеленый). Теперь наш код выглядит так:
После добавления параметра и значения в наш код html, Вы заметили, что они отличаются по цвету от всех других символов и тегов на странице. Это сделано специально для того, чтобы html код легче нам читался. Все теги обозначаются синим цветом, все атрибуты — красным, а значения атрибутов — фиолетовым.
Сейчас сохраняем изменения в Notepad++ (нажатием Ctrl + S), заходим в браузер и обновляем страницу (нажав F5). Сейчас наша надпись должна стать зеленой как на рисунке:
Теперь, чтобы закрепить материал, давайте добавим к тегу <font> еще один атрибут size. Данный параметр отвечает за размер текста. Он может иметь значение от 1 до 7, мы будем использовать значение 6, так как это мое любимое число! Мы сейчас добавляем второй параметр для тега, важно не забыть, что если параметров несколько, то между ними пробел! После добавления параметра size наш код выглядит следующим образом:
Теперь, как обычно, сохраняем изменения в файле (Ctrl + S), заходим в браузер и обновляем страницу (F5).
Сейчас наш текст должен стать большим, как на рисунке:
Если все получилось, то поздравляю, Вы освоили основной принцип работы тегов и их атрибутов. Это уже большой шаг!
Вы что-то не поняли из этого урока? Спрашивайте!
— [email protected]
ВАДИМ, ТЫ ОЧЕНЬ СИЛЬНО МНЕ ПОМОГ, Я ХОЧУ ОТБЛАГОДАРИТЬ ТЕБЯ
WebD2: общие теги HTML
Ниже приведены некоторые факты о тегах HTML (а также несколько фактов о тегах XHTML):
DOCTYPE: определение вашей версии HTML
Каждая веб-страница должна начинаться с объявления DOCTYPE. Это должен быть самый первый элемент в самой первой строке вашего кода HTML или XHTML. Это сообщает браузерам, в какой версии HTML была закодирована веб-страница, что помогает им узнать, как обрабатывать код. До появления HTML5 объявления DOCTYPE были длинными и сложными.
Например, вот объявление DOCTYPE для XHTML 1.1:
В HTML5 DOCTYPE Объявление намного проще:
Понимание следующих таблиц:
Общие теги HTML представлены ниже, сгруппированные в четыре таблицы в зависимости от их назначения. Первая таблица включает теги, управляющие общей структурой веб-страницы. Вторая и третья таблицы включают теги, которые размечают большую часть содержимого веб-страницы. Теги-контейнеры (содержащие контент) представлены во второй таблице, а теги, не являющиеся контейнерами (самостоятельные) — в третьей таблице. Последняя таблица содержит теги, которые используются в разметке HTML-таблиц, которые рассматриваются в Модуле 5 этого раздела.
Структура документа
| Открывающий тег | Закрывающий тег | Описание |
|---|---|---|
| Открывает и закрывает документ HTML | ||
| <голова> | Первый из двух основных разделов документа HTML. Раздел используется для предоставления информации о документе для использования главным образом поисковыми системами и браузерами. | |
| <название> | Название документа. Этот элемент вложен в секцию. В HTML5 это единственный обязательный тег, кроме объявления DOCTYPE. | |
| <тело> | Второй из двух основных разделов документа HTML. Раздел содержит все содержимое веб-страницы. |
Теги содержимого (контейнера)
HTML5
Семантические Теги
HTML5 представил несколько новых тегов, называемых семантическими тегами.
Эти теги были разработаны, чтобы сообщать о функциях блоков контента, которые были распространены на многих веб-страницах. До HTML5 разработчики просто использовали теги
| Открывающий тег | Закрывающий тег | Описание |
|---|---|---|
| <заголовок> | Содержит вводный контент для страницы (например, баннер) или раздел страницы. | |
| <навигация> | Содержит содержимое навигации, например меню навигации веб-сайта. | |
| <основной> | Содержит основное содержимое веб-страницы. | |
| <в сторону> | Содержит контент, косвенно связанный с основным контентом страницы (часто он представлен на боковой панели). | |
| <нижний колонтитул> | Содержит нижний колонтитул страницы или раздела страницы. Обычно нижний колонтитул содержит информацию о содержании, такую как автор и заявление об авторских правах. |
Пустые (неконтейнерные) бирки
| Ярлык | Описание |
|---|---|
| Разрыв строки. | |
| | Вставляет изображение на веб-страницу. |
Столы
| Открывающий ярлык | Закрывающий тег | Пример атрибутов | Описание | ||
|---|---|---|---|---|---|
| <таблица> | Добавляет таблицу | ||||
| Строка таблицы (начало и конец). | |||||
| <й> | область = «строка» область = «столбец» | При создании таблицы для отображения данных используйте этот тег, чтобы выделить первую строку или столбец ячеек в качестве ячеек заголовков для всех остальных ячеек в том же столбце или строке. Браузеры обычно отображают этот элемент жирным шрифтом и располагают по центру ячейки таблицы. Атрибут scope определяет, является ли это заголовком строки или столбца. | |||
| <тд> | Ячейка данных таблицы. | ||||
| colspan=»число» | Используйте с элементами | или | . Распределяет ячейки по нескольким столбцам. | ||
| рядов = «число» | Используйте с элементами | или | . Распределяет ячейки по нескольким строкам. |
Необязательные закрывающие теги в HTML – Tempertemper
Опубликовано 18 июня 2020 г.
в
Разработка
Одной из интересных особенностей HTML5 является его (очень преднамеренная) гибкость. Одна вещь, которую я всегда находил странной, это то, что некоторым элементам HTML не нужен закрывающий тег.
Например, вы можете написать список, не закрывая
- Красный
- Зеленый
- Синий
Это может быть потому, что Я писал HTML до того, как спецификация HTML5 стала поддерживаться в браузерах (XHMTL довольно строго относился к закрывающим тегам!), но, несмотря на то, что это допустимо, мне это кажется немного странным.
Помимо того, что выглядит странно , есть несколько веских причин, по которым я отталкиваю тех, кого обучаю HTML, от такого типа кода.
Это не для каждого элемента
Существует относительно короткий список элементов, с которыми вы можете это сделать. Таким образом, вы можете попасть в ловушку, опуская закрывающий тег из
- , ошибочно думая, что вам разрешено делать это со списками, когда разрешен только элемент списка (
-
-
<голова> -
<тело> -
-
-
<дт> -
<дд> -
<опция> -
<заголовок> -
-
<тело> -
<тд><фут>Если ошибиться, все сломается
Если вы пропустите это
Это может остаться незамеченным посетителями, которые используют новую блестящую версию Chrome на последней версии macOS, но, как известно каждому разработчику внешнего интерфейса, люди используют всевозможные технологии для чтения наших веб-сайтов; эти старые браузеры, устаревшие операционные системы, программы для чтения с экрана и голосовые контроллеры могут быть не столь прощающими…
Усложняет отладку
Иногда неработающий HTML трудно обнаружить; особенно если вы проверяете свой код вручную. Найти отсутствующий закрывающий тег, вызывающий проблемы с проверкой, гораздо сложнее, если везде есть (совершенно действительные) отсутствующие закрывающие теги.
Сложно найти свое место
Даже если нет ошибок проверки, отсутствие закрывающего
- могут содержать все виды других элементов (
Время, потраченное на размышления
Подобно тому, как вложение в CSS или JavaScript выглядело бы без закрывающей скобки (не пытайтесь — вы определенно сломаете!), вложенный HTML, в котором отсутствуют некоторые закрывающих тегов, а не другие, не имеет визуального заказ. Я начинаю пересматривать свой код, а это значит, что я трачу дополнительное время на его написание.
Итак, давайте закроем наши HTML-элементы
Опустить некоторые закрывающих тегов — это нормально с технической точки зрения; это может даже означать, что ваш файл на несколько байтов меньше! Но это может вызвать проблемы, и для меня, чем меньше проблем я столкнусь во время работы, тем лучше!
Подписаться
В последний день каждого месяца я отправляю информационный бюллетень, содержащий:
- Обзор опубликованных мною статей
- Горячий выбор из моих архивов
- Несколько интересных сообщений из Интернета
Адрес электронной почты
Я не собираю никаких данных о том, когда, где и открывают ли люди электронные письма, которые я им отправляю.
Вот элементы, которые вы можете оставить незакрытыми:
Браузеры делают все возможное, чтобы заполнить пробелы, и может случиться так, что ваша страница не выглядит такой уж испорченной, но когда что-то ломается тонкими способами, неверный код может в конечном итоге быть опубликован.
