Онлайн экранирование кода для вставки в HTML
Удобный функциональный онлайн генератор для экранирования кода работает на лету без перезагрузки страницы. Просто вставьте ваш код и нажмите кнопку Копировать.
Данный инструмент позволяет на лету без перезагрузки страницы экранировать код для дальнейшей вставки его в HTML, заменяя в коде символы < > & » ` на соответствующие им коды Unicode.
Такое экранирование нужно для того, чтобы без проблем встраивать демонстрационные фрагменты кода в HTML-документы и страницы сайта.
Вставьте код:
Результат:
Ниже приведены символы и Unicode значения для них, которые заменяет данный генератор:
Описание настроек
Данное экранирование не зависит от языка программирования и нужно исключительно для вставки кода в HTML, потому что если не заменить упомянутые выше символы на unicode, браузер будет воспринимать их как часть HTML и проинпретирует (обработает) код как часть html.
Обернуть код тегами pre code
Данная настройка обернёт полученный результат тегами <pre><code></code></pre> .
Добавить класс языка в тег code
Эта настройка добавит в тег code класс с идентификатором языка. Пример class=»language-html» . Это нужно если блок pre обрабатывается скриптами осуществляющими подсветку синтаксиса кода.
Работает только если включена настройка "Добавить класс языка в тег code".
Языки
Выбор языка — эта настройка укажет в class=»language-. » выбранный язык.
Работает только если включена настройка "Обернуть код тегами pre code".
Шпаргалка для разработчика: создаём безопасное веб-приложение
Эта статья — своего рода ‘cheat sheet’ для веб-разработчика. Она даёт представление о «программе-минимум» для создания веб-приложения, защищённого от самых распространённых угроз.
Экранирование пользовательского ввода
Что это?
В случае если данные пользовательского ввода, отображаемые в браузере, не предполагают наличия активного контента (HTML-разметки, CSS-стилей, JavaScript), данные пользовательского ввода должны быть закодированы (экранированы) перед использованием (отображением). Экранирование предполагает замену специальных символов (набор специальных символов зависит от контекста — HTML, JavaScript и т.д) для того, чтобы обработанные данные трактовались как тест, а не как активный контент. С точки зрения безопасности это делается главным образом для защиты от XSS.
Что делать?
Следует избегать хранения закодированных данных. Кодирование должно выполняться на стороне клиента, как можно ближе к месту использования данных. Главным образом это связано с тем, что только клиент знает, в каком контексте данные отображаются и от чего зависит необходимый тип кодирования.
Возможные контексты экранирования:
HTML-контекст — необходимо экранирование для HTML.
HTML-атрибут — необходимо экранирование для HTML-атрибута.
JavaScript — необходимо экранирование для JavaScript.
URL — необходимо экранирование для URL.
Кроме того, хранение закодированных данных может привести к двойному экранированию. Многие фреймворки экранируют текст по умолчанию (например ASP.NET Core).
Многие фреймворки предоставляют встроенный набор методов для данных целей.
Примеры
Экранирование HTML
Экранирование HTML-атрибута
Экранирование JavaScript
Экранирование JSON
Экранирование URL
Санитайзинг пользовательского ввода
Что это?
В случае если данные пользовательского ввода, отображаемые в браузере, предполагают наличие активного контента (HTML-разметки, CSS-стилей, JavaScript), необходимо выполнять санитайзинг пользовательского ввода — удаление/экранирование всего неразрешённого (например, в контексте HTML это касается тегов и атрибутов). С точки зрения безопасности это делается главным образом для защиты от XSS.
Что делать?
Предпочтительным подходом в таком случае является whitelisting — явное перечисление того, что разрешено. Конкретная логика и список разрешённых тегов и атрибутов сильно зависят от конкретного приложения. Реализовать санитайзинг безопасным образом в целом довольно сложно, предпочтительно использовать готовые протестированные решения и библиотеки. В контексте ASP.NET таким решением может быть использование Html Agility Pack — HTML-парсера, на основе которого можно создать необходимую логику санитайзинга HTML, удовлетворяющую необходимым требованиям приложения.
Пример
Пользователь может оставлять комментарии, содержащие теги <strong>. Пользовательский ввод:
Пользовательский ввод после санитайзинга:
Контроль над произвольным пользовательским вводом
Что это?
В большинстве случаев данные пользовательского ввода должны проходить проверку на соответствие допустимым значениям, бизнес-правилам и т.п. Проверка может осуществляться как на клиентской, так и на серверной стороне. Проверка на клиентской стороне положительно влияет на user experience, позволяя получить более ранний отклик, но сама по себе не является достаточной. Проверка на сервере должна проводиться обязательно, вне зависимости от наличия клиентской проверки. С точки зрения безопасности это делается главным образом для защиты от фишинга.
Что делать?
Валидация пользовательского ввода
Пример
Система принимает сообщение об ошибке как часть URL:
Данное сообщение затем отображается в HTML-разметке:
Примечание: В данном случае система также уязвима к XSS-атаке (защита достигается путём экранирования данных — см. следующий пункт).
Поскольку в данном случае система принимает абсолютно любое сообщение, система открыта для фишинга. Например:
Если набор ошибок известен заранее, более безопасным методом передачи типа ошибки будет использование перечисления:
Программная логика затем производит маппинг кода ошибки и заранее известного текста ошибки, который уже и отображается на HTML-странице.
Явное акцентирование на данных, не прошедших валидацию
В случае отсутствия контроля над данными, когда необходимо принимать произвольный пользовательский ввод, необходимо акцентировать внимание конечного пользователя на данном факте.
Пример
В контексте предыдущего примера, в случае если источником текста ошибки является внешняя система (например, в случае интеграции) можно добавить в пользовательский интерфейс сообщение, поясняющее конечному пользователю, что источником данного сообщения является иная система и что сообщение отображается «как есть».
Контроль за легитимностью запросов на изменение данных
Что это?
Позволяет удостовериться, что запрос к системе на изменение данных действительно инициирован пользователем. Основной целью данного механизма контроля является защита от таких атак как CSRF и фишинг.
Что делать?
Antiforgery токены
Каждый запрос, потенциально меняющий состояние данных на сервере, должен включать уникальный токен, привязанный к сессии пользователя. Значение токена должно быть либо случайным, либо получено с использованием шифрования.
Пример
Потенциально уязвимая форма:
Форма с токеном, включённым в виде скрытого поля:
На каждом запросе веб-приложение должно валидировать токен.
Использование атрибута SameSite для куки пользовательской сессии
Если приложение использует куки для хранения пользовательской сессии, крайне желательно использование атрибута SameSite со значением Strict или Lax. Это предотвратит отправку авторизованных запросов, источником которых не является само веб-приложение.
Пример
Подтверждение действия от пользователя
Механизм подтверждения действия от пользователя с помощью дополнительного диалога либо 2FA крайне затруднит атаку. Так как данный подход требует дополнительных действий со стороны пользователя, его имеет смысл использовать для наиболее важных действий.
GET-запросы не должны изменять данные на сервере
HTTP-запросы GET должны быть идемпотентными; в данном контексте — не вносить изменения в данные на сервере. Это связано главным образом с тем, что GET-запрос сделать намного проще, чем, например, POST, и намного сложнее сделать безопасным, если запрос меняет данные. Даже использование antiforgery токенов не гарантирует безопасности, т. к. GET-запросы не имеют тела, все их параметры являются частью URL, и относительно велика вероятность утечки токена через историю браузера, логи и т.д.
Валидация источника запроса
Проверка HTTP-заголовков Origin и/или Referer. Данный механизм защиты может рассматриваться в качестве дополнительного к вышеперечисленным методам, но не в качестве единственного, т. к. значение заголовков зачастую может быть пустым (по целому ряду причин — из-за VPN, firewall и т. д.) и также может быть потенциально недостоверным.
Контроль над фреймингом
Что это?
Контроль над фреймингом предполагает реализацию явной политики относительно того, может ли веб-приложение (сайт) отображаться во фрейме (HTML-тег <iframe>), какие части приложения могут отображаться во фрейме и при каких условиях. Основной целью такой политики является защита от clickjacking.
Что делать?
Использование HTTP-заголовка Content-Security-Policy
Данный заголовок позволяет с помощью директивы frame-src указать, в каких случаях ресурс может быть отображён в iframe.
Примеры
Фрейминг разрешён только для страниц самого веб-приложения:
Использование HTTP-заголовка X-Frame-Options
Данный заголовок не является стандартным. Тем не менее, он полезен для браузеров, не поддерживающих CSP (например, Internet Explorer) . Данный заголовок позволяет указать, в каких случаях ресурс может быть отображён в iframe.
Пример
Фрейминг разрешён только для страниц самого веб-приложения:
Использование специализированных HTTP-заголовков безопасности
Что это?
Различные HTTP-заголовки, позволяющие настраивать относящиеся к безопасности аспекты коммуникации через протокол HTTP.
Что делать?
Content-Security-Policy
Позволяет контролировать, какой контент и откуда может использовать веб-приложение (скрипты, стили, шрифты, изображения), в каких случаях приложение может отображаться в iframe, политику использования HTTPS и другие аспекты, связанные с безопасностью веб-приложения. Чем строже политика, заданная в CSP-директивах, тем лучше с точки зрения безопасности. Различные аспекты политики предоставляют защиту от различных видов атак. Например, директива script-src, предоставляющая контроль над разрешёнными источниками для JavaScript, является отличным средством защиты от XSS. Директива frame-src является хорошим подспорьем в борьбе с clickjaсking.
Пример
Разрешены скрипты, стили, шрифты и встроенный контент из файлов, предоставляемых самим сайтом; встроенные скрипты и стили запрещены.
Отправка форм — только с самого сайта.
Все запросы из страниц выполняются только по HTTPS.
Permissions-Policy (ex-Feature-Policy)
Данный HTTP-заголовок позволяет явным образом указать, какие клиентские (JavaScript) API может использовать приложение. Это может быть особенно полезно для ограничения использования камеры, микрофона и т. д.
Пример
Политика ниже запрещает использование микрофона, камеры, payment API. Геолокация разрешена только для самого приложения:
Strict-Transport-Security
Данный заголовок помогает реализовать политику использования защищённого HTTPS-соединения и в целом может быть полезен в контексте борьбы с утечкой данных, а также с атаками типа Man in the middle (подробнее см. в разделе «HTTPS»).
Referrer-policy
Данный заголовок помогает предотвратить утечку данных из URL в случае перехода из приложения по внешним ссылкам (подробнее см. в разделе «Меры по предотвращению утечки данных»).
X-Frame-Options
Данный заголовок не является стандартным. Тем не менее, он может быть полезен для браузеров, не поддерживающих CSP. Данный заголовок позволяет указать, в каких случаях ресурс может быть отображен в iframe (подробнее — в разделе «Контроль над фреймингом»).
X-XSS-Protection
Этот подход менее гибок и используется реже, чем Content-Security-Policy. Тем не менее, он полезен для браузеров, не поддерживающих CSP (например, Internet Explorer). Данный заголовок разрешает браузеру использовать встроенный механизм борьбы с XSS (если браузер имеет таковой) в режиме блокирования страницы либо удаления потенциально опасного кода.
Пример
Конфигурация ниже блокирует страницы, содержащие подозрительный (с точки зрения возможной XSS-атаки) код:
X-Content-Type-Options
Данный заголовок может быть полезен в контексте борьбы с различными атаками, связанными с выполнением содержимого файлов приложения. Использование данного заголовка полезно в том случае, если приложение предоставляет возможность хранения/работы с файлами (подробнее в разделе «Правильная организация хранения файлов и доступа к ним»).
HTTP-заголовки не должны быть основным и единственным средством защиты
Насколько перечисленные выше HTTP-заголовки эффективны — целиком и полностью зависит от уровня поддержки и качества реализации в конкретном браузере. Таким образом, HTTP-заголовки не должны рассматриваться как единственная мера защиты для каждого конкретного вектора атаки, и механизмы защиты на стороне сервера тоже необходимы.
Управление пользовательской сессией
Что это?
Механизм пользовательской сессии позволяет приложению распознавать запросы от уже аутентифицированного пользователя, не вынуждая его вводить логин и пароль для отправки каждого запроса. В общем случае это осуществляется путём использования некоего уникального идентификатора пользователя, который присваивается после успешной процедуры логина и затем отправляется с каждым запросом. С точки зрения безопасности особенно важно, чтобы выбранный механизм управления пользовательской сессией не был уязвим для таких атак, как session hijacking и session fixation.
Что делать?
Значение идентификатора сессии должно быть случайным
Значение должно быть случайным, сложным для предугадывания и не поддаваться простому перечислению.
Ротация идентификатора сессии
При каждом новом входе в систему пользователю должен присваиваться новый идентификатор сессии. Предыдущий идентификатор должен быть инвалидирован.
Пример
Чтобы предотвратить переиспользование идентификатора сессии в ASP.NET, куки с идентификатором необходимо инвалидировать в процессе разлогирования пользователя:
Защита куки сессии
Куки сессии должны использовать следующие атрибуты:
HttpOnly
Использование данного атрибута поможет предотвратить возможность получения значения идентификатора сессии с помощью клиентского скрипта.
Secure
Данный флаг предотвратит передачу идентификатора сессии по незащищённому HTTP-протоколу.
SameSite
Значения Strict и Lax данного атрибута предотвращают отправку куки с запросами, источниками которых не является сайт, создавший куки. Это помогает предотвратить CSRF-атаки.
Также для таких куки не должно быть установлено свойство Domain
Установка данного свойства открывает доступ к куки для поддоменов, что нежелательно, если не все поддомены находятся под контролем автора приложения.
Пример
Конфигурация для ASP.NET в файле web.config:
Избегать передачи незакодированного идентификатора сессии в URL
Некоторые приложения могут передавать идентификатор сессии как часть URL. Если идентификатор не закодирован, это может привести к утечке идентификатора, например через лог запросов на сервере, историю браузера. Использование куки для хранения идентификатора сессии является предпочтительным.
Использование HTTPS
Что это?
Приложение, не использующее протокол HTTPS, по умолчанию является уязвимым: данные передаются по сети в незашифрованном виде, что делает приложение подверженным таким атакам, как Man in the middle или content sniffing. Возможна утечка персональных данных, паролей и т. д. Любое приложение, имеющее дело с персональными данными и/или паролями, должно использовать протокол HTTPS.
Что делать?
Перенаправление всех запросов с HTTP на HTTPS либо отказ в обслуживании запросов HTTP
Веб-приложение должно осуществлять перенаправление всех запросов с HTTP на HTTPS. Данный подход работает в случае, если клиентом является браузер. В остальных случаях (например, мобильное или десктопное приложение) вместо перенаправления необходимо отвергать запрос с ошибкой.
HTTP-заголовок Strict-Transport-Security
Позволяет обеспечить доступ к ресурсу исключительно по протоколу HTTPS в случае, если клиентом ресурса является браузер. После ответа на первый запрос, содержащий данный заголовок, все последующие запросы браузер будет выполнять с использованием защищённого протокола HTTPS.
Пример
Использование HSTS с директивой preload
Браузер не имеет возможности заранее, до первого запроса, определить, требует ли ресурс доступа только по HTTPS. Например, пользователь запрашивает в браузере ресурс http://mysite.com. Данный запрос выполняется по протоколу HTTP. Если в ответе на этот запрос содержится заголовок Strict-Transport-Security, все последующие запросы будут выполняться по протоколу HTTPS. Очевидно, что первый запрос всё ещё может быть уязвим. Предотвратить этот риск помогает использование директивы preload и добавление ресурса в так называемый preload list (подробнее см. https://hstspreload.org).
Пример
Запрет HTTP-запросов к API — только HTTPS
В случае если клиентом API является не только браузер, существует вероятность, что перенаправление с HTTP на HTTPS (например, с помощью HSTS) не будет корректно обработано клиентом. В целом для API предпочтительно отвергать запросы по HTTP.
Защищённые куки
Что это?
Куки могут содержать важную с точки зрения безопасности информацию, например идентификатор пользовательской сессии. Передача таких куки по незащищённому HTTP-соединению и возможность доступа из клиентского кода могут стать источником таких атак, как session hijacking.
Что делать?
Флаг HttpOnly
Предотвращает возможность доступа к куки с помощью клиентского скрипта. Флаг должен быть установлен для всех куки, доступ к которым из клиентского скрипта не предполагается.
Флаг Secure
Куки с данным флагом будут переданы с запросом только в случае, если запрос выполняется по протоколу HTTPS.
Атрибут SameSite
Данный атрибут может принимать несколько значений. Значения Lax или Strict предотвратят отправку куки с запросами, выполняемыми не из приложения, что может сильно затруднить атаку типа CSRF.
Пример
HTTP-заголовок, устанавливающий куки “SessionId”:
Пример конфигурации в web.config для ASP.NET:
Правильная организация хранения файлов и доступа к ним
Что это?
В случае если приложение предоставляет пользователям возможность загрузки файлов и их хранения, данная функциональность должна быть реализована с учётом необходимости защиты от возможных атак и нецелевого использования.
Что делать?
Валидация и санитайзинг имён файлов
Имена файлов как минимум не должны иметь расширений, приводящих к выполнению кода на стороне сервера или на клиенте (например, .bat, .cmd, .vbs).
Ограничение типов файлов, разрешённых для загрузки
Типы файлов должны быть ограничены с использованием подхода whitelisting (явное задание списка разрешённых типов файлов).
Использование HTTP-заголовка X-Content-Type-Options
Использование данного заголовка помогает предотвратить выполнение содержимого файлов в браузере.
Пример
Хранение файлов в домене, отличном от домена приложения
Файлы должны храниться в домене, отличном от домена приложения (не в том же домене и не в его поддомене), с как можно более строгими политиками CSP и Permissions Policy, по возможности полностью запрещающими выполнение скриптов и использование различных клиентских API.
Пример
Данные, с утечкой которых надо бороться
Что это?
К таким данным относятся пользовательские данные и технические данные о работе приложения (сообщения об ошибках, стеки ошибок и т. п.).
Что делать?
Контроль над сообщениями об ошибках
Данная техника предполагает строгое ограничение информации об ошибках, доступной пользователям системы. Содержимое сообщения об ошибках должно быть строго определено. Сообщения об ошибках должны быть полезны для конечного пользователя, но не должны содержать излишних технических подробностей о системе либо других важных с точки зрения безопасности, но не важных для конечного пользователя данных (идентификаторов, информации о структуре хранилища данных, стеков ошибок и т. д.).
Пример
Для ASP.NET-приложения обработчик Application_Error в Global.asax файле может быть использован для перехвата необработанных ошибок:
Для ASP.NET Core обработчик исключений может быть зарегистрирован в методе Configure класса Startup:
URL не должен содержать конфиденциальные данные
В целом URL не должны содержать потенциально конфиденциальные данные, т. к. URL могут быть сохранены как часть внешней инфраструктуры логирования (история браузера, логи серверов; такие HTTP-заголовки, как Referer, и т. д.). В случае если передача таких данных через URL необходима, данные должны быть зашифрованы.
Использование HTTP-заголовка Referrer-Policy
Данный заголовок позволяет ограничить информацию, передаваемую в заголовке Referer. Может быть использован для исключения передачи параметров строки запроса либо URL целиком.
Пример
Исключение из ответа на HTTP-запрос HTTP-заголовков, раскрывающих детали серверной реализации приложения
Некоторые технологии и платформы по умолчанию добавляют в ответы на HTTP-запросы определённое количество различных HTTP-заголовков. Некоторые из них могут раскрывать такие технические подробности, как версия сервера, платформы и т. д. Данные заголовки, если они не несут функциональности для конечного пользователя, должны быть убраны из ответа на запрос.
Пример
Некоторые заголовки для IIS + ASP.NET, по умолчанию включённые в запрос:
Заголовок “Server” может быть удалён с помощью URL Rewrite rule:
Заголовок “XPowered-By” может быть удалён через конфигурацию IIS (“HTTP response headers item”).
Заголовок “X-AspNetMvc-Version» может быть удалён при использовании следующего кода в событии Application_Start:
Заголовок “X-AspNet-Version“ может быть удалён при помощи конфигурации в файле web.config:
Контроль за перенаправлением на внешние ресурсы
Что это?
Если приложение может перенаправлять пользователя на внешние ресурсы и такие перенаправления не валидируются, это может способствовать фишинговым атакам, особенно в случае, если URL внешнего ресурса является частью ввода (например, параметр строки запроса URL).
Что делать?
Валидация адресов внешних ресурсов
Адрес перенаправления всегда должен валидироваться. Если по каким-либо причинам валидация невозможна, необходимо предупреждать пользователя о том, что он будет перенаправлен на внешний ресурс. Это можно сделать с помощью промежуточной страницы или диалогового окна, требующего действия от пользователя.
Безопасное использование пользовательского ввода в параметрах запросов к БД
Что это?
Если какой-либо запрос к БД принимает один или более параметров, параметры должны быть должным образом закодированы (в контексте SQL) перед использованием. В противном случае система может быть уязвима к SQL-инъекциям. Это особенно актуально для SQL-запросов, использующих данные пользовательского ввода (поля форм, часть строки запроса URL и т. д.) в качестве параметров запроса.
Что делать?
Параметризация запросов
Большинство платформ для работы с БД предоставляют такие возможности. Например, Microsoft Entity Framework по умолчанию не является уязвимым к такому типу атаки, т. к. весь пользовательский ввод преобразуется в SQL-параметры. Но в то же время фреймворк даёт возможность выполнения «сырых» запросов напрямую, и в таком случае обязанностью разработчика является передача ввода в качестве параметров запроса.
Пример
Запрос, уязвимый к SQL-инъекции:
Политика предоставления наименьших необходимых разрешений
Политика предоставления наименьших необходимых разрешений также является полезной мерой защиты с точки зрения минимизации вреда в случае SQL-инъекции. Например, использование различных аккаунтов на чтение и доступ может предотвратить возможность изменения данных даже в случае успешной SQL-инъекции.
Заключение
Конечно, это руководство не исчерпывающее. Бывают и более экзотические виды атак, да и любой сайт можно взломать, если постараться. Однако реализация мер, приведённых в этой статье, обеспечит защиту от наиболее распространённых угроз и достойный уровень безопасности приложения в целом.
How to make html ignore code that is part of text?
You can use <pre> tag. Each time you insert any texts within the <pre> tag it wont get parsed as html document. One caveat though, if you try to put an opening HTML tag inside the pre tag, you have to do it like this:
Use the xmp tag. It is easier and quicker than using an HTML encoder. Example:
You can use a combination of the <pre> and <code> tags. The <pre> tag retains the formatting , and the <code> tag outputs in monospaced font. Wrap the <code> tag in <pre> tag, and paste whatever block of code in the <code> elements body. This will output like the following:
Some people might crucify me not escaping my code. But this worked for me.
same answer as Ibu but maybe you want a fast way to encode your tags.
To not escape any characters at all, you can use a textarea:
Run the snippet and notice the <li> and </li> tags render verbatim rather than being converted to a bullet.
Now why do we need the CSS and the extra HTML tags and attributes?
The CSS removes all the styling from textarea since the textarea will typically include styling for borders, resize gripper, and will use "input" style fonts. The textarea tag needs the "readonly" attribute so users can’t edit it. The extra div tag around the textarea makes the textarea insert more correctly into the document flow.
It has some extra steps and it changes the DOM considerably but if you really need to show text strictly without escaping any characters at all for whatever reason.
Name already in use
html-best-practices / README.ru.md
- Go to file T
- Go to line L
- Copy path
- Copy permalink
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
Лучшие практики HTML
Для написания поддерживаемых и масштабируемых HTML-документов
Начните с DOCTYPE
DOCTYPE требуется для активации стандартного режима.
Не используйте устаревший или недействительный DOCTYPE
DOCTYPE больше не предназначен для DTD, будьте проще.
Не используйте XML Declaration
Вы уверены, что хотите писать XHTML?
По возможности избегайте использования ссылок на символы
Если вы пишете HTML-документ с использованием UTF-8, почти все символы (включая Emoji) могут быть записаны напрямую.
Экранирование & , < , > , » и ‘ с именованными ссылками на символы
Чтобы HTML-документ не содержал ошибок, эти символы следует всегда экранировать.
Используйте числовые ссылки на символы управления или невидимые символы
Эти символы легко перепутать с другим символом. Кроме того, спецификация не гарантирует определение человеко-понятного имени для этих символов.
Поместите пробелы вокруг содержимого комментария
Некоторые символы нельзя использовать сразу после открытия комментария или до закрытия комментария.
Не пропускайте закрывающий тег
Я думаю, вы не понимаете правила пропуска закрывающего тега.
Не смешивайте пустой формат элемента
Последовательность — залог удобного чтения.
Не ставьте пробелы вокруг тегов и значений атрибутов
Для этого нет никаких причин.
Не смешивайте регистры символов
Он также придает консистенцию.
Не смешивайте кавычки
То же, что и выше.
Не разделяйте атрибуты двумя или более пробелами
Ваше странное правило форматирования сбивает кого-то с толку.
Пропустите логическое значение атрибута
Писать легко, не так ли?
Опустите пространства имен
SVG и MathML можно использовать непосредственно в HTML-документе.
Не используйте атрибуты XML
Мы пишем HTML-документ.
Не смешивай data-* , Microdata, и RDFa Lite атрибуты с обычными атрибутами
Строка тега может быть очень сложной. Это простое правило поможет прочитать такую строку тегов.
Предпочитайте неявную семантику ARIA по умолчанию
Какой-то элемент имеет ARIA role неявно в HTML-документе, не указывайте его.
Добавьте атрибут lang
Атрибут lang поможет перевести HTML-документ.
Держите значение атрибута lang как можно короче
Японский язык используется только в Японии. Поэтому код страны не нужен.
По возможности избегайте data-*
Соответствующий атрибут может быть правильно обработан браузерами.
Добавить элемент title
Значение для элемента title используется различными приложениями, не только браузером.
Не используйте элемент base
Абсолютный путь или URL безопаснее как для разработчиков, так и для пользователей.
Укажите MIME-тип второстепенных связанных ресурсов
Это подсказка о том, как приложение работает с этим ресурсом.
Не ссылайтесь на favicon.ico
Почти все браузеры получают /favicon.ico автоматически и асинхронно.
Добавьте ссылку на apple-touch-icon
Путь запроса по умолчанию для сенсорного значка был неожиданно изменен.
Добавьте атрибут title к альтернативным таблицам стилей
Удобная для понимания человеком метка помогает людям выбрать подходящую таблицу стилей.
Для URL используйте элемент link
Значение атрибута href может быть преобразовано в URL.
Укажите кодировку символов документа
UTF-8 пока не используется по умолчанию во всех браузерах.
Не используйте устаревший формат кодирования символов
HTTP-заголовки должны задаваться сервером, будь проще.
Сначала укажите кодировку символов
Спецификация требует, чтобы кодировка символов была указана в первых 1024 байтах документа.
При использовании UTF-8 вы можете свободно использовать Emoji.
Для URL используйте элемент link
В HTML значение атрибута type элемента style по умолчанию равно text/css .