Пробел перед закрытием Slash?

Я часто видел пробел перед закрывающей косой чертой в тегах XML и HTML. Разрыв строки XHTML, вероятно, является каноническим примером:

<br />

вместо:

<br/>

Пространство кажется излишним. На самом деле, я думаю, что это лишнее.

В чем причина написания этого пространства?

Я читал, что пространство решает некоторые проблемы обратной совместимости. Какие проблемы обратной совместимости? Являются ли эти проблемы все еще актуальными или мы все еще добавляем дополнительные пробелы ради, скажем, совместимости с IE3? Существует ли какая-то спецификация с окончательным ответом на это?

Если не обратная совместимость, то это проблема чтения? Как и в случае с Большом открытием Curly Brace?

void it_goes_up_here() {

int no_you_fool_it_goes_down_there()
{

Я могу, конечно, уважать разные стилистические мнения, поэтому я буду рад узнать, что писать пространство просто вопрос вкуса.

Ответ 1

Ответ: люди хотят придерживаться Приложения C спецификации XHTML1.0. Что вам нужно сделать, только если вы обслуживаете XHTML как текст /html. Что большинство людей делает, потому что реальный MIME-тип XHTML (application/html + xml) не работает в Internet Explorer.

Никакой текущий браузер не заботится о пространстве. Браузеры очень терпимы к этим вещам.

Пространство, которое требуется для обеспечения того, чтобы парсеры HTML обрабатывали конечную косую черту как непризнанный атрибут.

Ответ 2

Являются ли эти проблемы актуальными или мы все еще добавляем дополнительные пробелы ради, скажем, совместимости с IE3?

Вы были близки - это для Netscape 4.

Интересно видеть другие рационализации, но все это предназначалось для.

Ответ 3

Поддержка 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), но не только я не смог найти хорошую доказательство и конкретную версию стандарта, Я даже не мог понять правильное поведение, соответствующее стандарту. Так мало ссылок для ссылки:

Уведомление валидатора w3c, в котором упоминается проблема с закрывающейся косой чертой и указывается на
Пустые элементы в SGML, HTML, XML и XHTML @www.cs.tut.fi/~jkorpela/
Остерегайтесь XHTML: Null End Tags (NET), заявив, что

Тем не менее, есть еще некоторые небольшие пользовательские агенты, которые правильно поддерживают теги Null End. Одним из наиболее известных пользовательских агентов, которые его поддерживают, является валидатор W3C.

(Невозможно воспроизвести его сейчас, но поддерживает выражение Ли Ковалковски о нескольких браузерах, затронутых этим.)

XML W3C Working Draft 07-Aug-97 - проект последних спецификаций, который включает ссылку Null End Tag в фрагменте DTD: NET "/>"

Ответ 4

Нет, пространство не требуется, но для некоторых старых браузеров необходимо правильно их обработать. Правильный способ сделать это без лишнего пространства, поскольку это то, что XHTML унаследовал от XML.

Ответ 5

В XHTML теги br должны быть закрыты, но пространство не нужно. Это стилистическая вещь. В HTML теги br не могут быть закрыты, поэтому оба неверны.

Ответ 6

Пространство просто делает метки более читабельными. Я большой сторонник форматирования для более читаемого кода. Маленькие вещи, как это, долгий путь. Без пространства закрывающий тег смешивается с открывающим тегом. Мне нужно всего лишь мгновение дольше, чтобы обработать его, поскольку я быстро читаю код.

Ответ 7

Я думаю, что пробел - это способ укрепить идею о том, что этот тег пуст, и он закрывается.

Сегодня я больше не использую пустое пространство, потому что у меня никогда не было проблем без пробелов.

Ответ 8

Что, если бы там был очень ленивый html писатель или, может быть, он боялся кавычек. Подумайте о следующем, если вы были его гусеничным роботом...

<img src=http://myunquotedurl.com/image.jpg />

против

<img src=http://myunquotedurl.com/image.jpg/>

Это может показаться небольшим, но посмотрите, что он может сделать, если пространства там нет. Робот не будет знать, является ли косая черта частью URL-адреса или части закрывающего тега.

Ответ 9

Для меня это зависит от того, что визуальная студия делает с моим HTML/XML:-) Это непротиворечиво, но это не имеет значения из функционального вида (это только вопрос стиля).