Я часто видел пробел перед закрывающей косой чертой в тегах XML и HTML. Разрыв строки XHTML, вероятно, является каноническим примером:
<br />
вместо:
<br/>
Пространство кажется излишним. На самом деле, я думаю, что это лишнее.
В чем причина написания этого пространства?
Я читал, что пространство решает некоторые проблемы обратной совместимости. Какие проблемы обратной совместимости? Являются ли эти проблемы все еще актуальными или мы все еще добавляем дополнительные пробелы ради, скажем, совместимости с IE3? Существует ли какая-то спецификация с окончательным ответом на это?
Если не обратная совместимость, то это проблема чтения? Как и в случае с Большом открытием Curly Brace?
void it_goes_up_here() {
int no_you_fool_it_goes_down_there()
{
Я могу, конечно, уважать разные стилистические мнения, поэтому я буду рад узнать, что писать пространство просто вопрос вкуса.
Ответ: люди хотят придерживаться Приложения C спецификации XHTML1.0. Что вам нужно сделать, только если вы обслуживаете XHTML как текст /html. Что большинство людей делает, потому что реальный MIME-тип XHTML (application/html + xml) не работает в Internet Explorer.
Никакой текущий браузер не заботится о пространстве. Браузеры очень терпимы к этим вещам.
Пространство, которое требуется для обеспечения того, чтобы парсеры HTML обрабатывали конечную косую черту как непризнанный атрибут.
Являются ли эти проблемы актуальными или мы все еще добавляем дополнительные пробелы ради, скажем, совместимости с IE3?
Вы были близки - это для Netscape 4.
Интересно видеть другие рационализации, но все это предназначалось для.
Поддержка bobince answer с снимком экрана Netscape 4.80, показывающим документы
data:text/html,<title>space</title>foo<br />bar
(вверху слева, рендеринг строки) и
data:text/html,<title>no space</title>foo<br/>bar
(в левом нижнем углу, игнорирование строки).
Проводка в качестве ответа для показа изображения
Тангенциально связанный: на самом деле у меня был длинный ответ, определяющий причину такого неправильного поведения древних браузеров (и результирующая рекомендация включить пространство) в непонятные спецификации SGML, а именно SGML Null End Tag (NET) (что делает x<b>y</b>z эквивалент x<b/y/z, поэтому x<br/>y на самом деле означает x<br>>y), но не только я не смог найти хорошую доказательство и конкретную версию стандарта, Я даже не мог понять правильное поведение, соответствующее стандарту. Так мало ссылок для ссылки:
Тем не менее, есть еще некоторые небольшие пользовательские агенты, которые правильно поддерживают теги Null End. Одним из наиболее известных пользовательских агентов, которые его поддерживают, является валидатор W3C.
(Невозможно воспроизвести его сейчас, но поддерживает выражение Ли Ковалковски о нескольких браузерах, затронутых этим.)
NET "/>"Нет, пространство не требуется, но для некоторых старых браузеров необходимо правильно их обработать. Правильный способ сделать это без лишнего пространства, поскольку это то, что XHTML унаследовал от XML.
В XHTML теги br должны быть закрыты, но пространство не нужно. Это стилистическая вещь. В HTML теги br не могут быть закрыты, поэтому оба неверны.
Пространство просто делает метки более читабельными. Я большой сторонник форматирования для более читаемого кода. Маленькие вещи, как это, долгий путь. Без пространства закрывающий тег смешивается с открывающим тегом. Мне нужно всего лишь мгновение дольше, чтобы обработать его, поскольку я быстро читаю код.
Я думаю, что пробел - это способ укрепить идею о том, что этот тег пуст, и он закрывается.
Сегодня я больше не использую пустое пространство, потому что у меня никогда не было проблем без пробелов.
Что, если бы там был очень ленивый html писатель или, может быть, он боялся кавычек. Подумайте о следующем, если вы были его гусеничным роботом...
<img src=http://myunquotedurl.com/image.jpg />
против
<img src=http://myunquotedurl.com/image.jpg/>
Это может показаться небольшим, но посмотрите, что он может сделать, если пространства там нет. Робот не будет знать, является ли косая черта частью URL-адреса или части закрывающего тега.
Для меня это зависит от того, что визуальная студия делает с моим HTML/XML:-) Это непротиворечиво, но это не имеет значения из функционального вида (это только вопрос стиля).