Пустые элементы в HTML5 можно закрыть либо с помощью />, либо просто >. Внешние элементы (т. Е. Элементы из пространства имен MathML и пространства имен SVG), однако, могут быть самозакрывающимися, и do требует, чтобы их открывающий тег был заполнен />.
Поскольку спецификация HTML5 не дает подробных указаний о том, какой путь будет лучше, мы должны учитывать другие аспекты при принятии решения закрыть Void Elements с помощью \> или >. Вот следующие аспекты, которые я хотел бы учитывать при принятии этого решения для проекта:
Ремонтопригодность
Лично мне гораздо легче обнаруживать ошибки, особенно ошибки сопряжения тегов, и вообще понимать файл, если он использует закрытие тегов /> для пустых элементов. Это еще более верно, когда есть и внешние элементы, так как эти должны использовать /> закрытия тегов.
Я также обнаружил, что многие наборы правил подсветки синтаксиса не на 100% совместимы с HTML5 и могут запутаться из-за , а не , использующего закрытия тегов /> с элементами, которые не имеют отдельного закрывающего тега. Конечно, это зависит от редактора, и многие IDE имеют более надежную подсветку синтаксиса, чем другие более простые редакторы, поэтому ваш опыт может отличаться, но если важна удобство обслуживания и простота редактирования, это один из факторов, который часто упускают из виду.
Размер страницы
Если у вас большое количество пустых элементов и производительность страницы имеет решающее значение для вашего приложения, удаление ненужных символов поможет уменьшить размер полезной нагрузки для вашей страницы. Это означает, что ваш ответ может быть отправлен в меньшем количестве пакетов, а это означает, что требуется меньше циклов , что в целом приводит к более быстрому ответу.
Однако для 99% приложений существует много других вещей, на которые нужно потратить время и силы на оптимизацию, что будет иметь гораздо большее влияние на время загрузки страницы, чем удаление посторонних / символов из пустых элементов.
Машинная читаемость
По тем же правилам, что и правила подсветки синтаксиса, не такие гибкие, какими они должны быть, вы, вероятно, обнаружите, что то же самое относится и к библиотекам обработки HTML и / или XML, которые вы можете использовать для обработки страницы HTML. Вы, вероятно, найдете синтаксис, который ближе к XML, лучше поддерживается библиотеками обработки, и если вы ожидаете, что другие разработчики будут обрабатывать ваш HTML, использование наиболее широко поддерживаемого синтаксиса позволит им использовать более широкий набор инструментов.
Заключение
Если, в конце концов, вы решите, что вам по-прежнему необходимо уменьшить размер страницы, который вы можете получить, удалив лишние / символов, я думаю, что лучший путь - это пропустить весь ваш HTML через фильтр который может анализировать HTML и автоматически удалять символы, если позволяет спецификация HTML5. Это дает преимущество в , а не , жертвуя обслуживаемостью, но при этом сокращая размер страницы. Вы даже можете выбрать , а не , чтобы передавать свои выходные данные через этот фильтр, если вы знаете, что запрос предназначен для анализа другим кодом, что также позволяет вам сохранять аспект читабельности компьютера.
Недостатком является то, что у вас есть дополнительный шаг обработки в вашем конвейере, который добавляет сложности и может компенсировать или не компенсировать любое увеличение скорости загрузки страницы, которое вы получаете.
В конечном счете, вы должны измерить скорость и размер полезной нагрузки ваших страниц и объединить эти измерения с тем, как вы хотите расставить приоритеты в аспектах, перечисленных выше, и сделать вызов для вашего конкретного проекта. Единого ответа на все вопросы не существует, но правильный выбор - , вероятно , своего рода золотая середина.