Spacja przed zamknięciem Slash?

Często widziałem spację poprzedzającą zamykający ukośnik w tagach XML i HTML. Podział wiersza XHTML jest prawdopodobnie kanonicznym przykładem:

<br />

zamiast:

<br/>

Przestrzeń wydaje się zbędna. Właściwie uważam, że jest to zbędne.

Jaki jest powód napisania tego miejsca?

Czytałem, że przestrzeń rozwiązuje niektóre „problemy ze zgodnością wsteczną”. Jakie problemy ze zgodnością wsteczną? Czy te problemy są nadal aktualne, czy też nadal dodajemy dodatkowe spacje ze względu na, powiedzmy, zgodność z IE3? Czy istnieje jakaś specyfikacja z ostateczną odpowiedzią na ten temat?

Jeśli nie kompatybilność wsteczna, czy jest to problem z czytelnością? Podobnie jak w przypadku debaty dotyczącej Wielkiej Otwartej Kręconej Brace?

void it_goes_up_here() {

int no_you_fool_it_goes_down_there()
{

Z pewnością szanuję różne opinie stylistyczne, dlatego z przyjemnością dowiem się, że pisanie przestrzeni to po prostu kwestia gustu.

Odpowiedź brzmi: ludzie chcą stosować się do Załącznika C specyfikacji XHTML1.0 . Co musisz zrobić tylko wtedy, gdy udostępniasz XHTML jako tekst / html . Co robi większość ludzi, ponieważ prawdziwy typ MIME XHTML (aplikacja / html + xml) nie działa w przeglądarce Internet Explorer.

Żadna obecna przeglądarka nie dba o to miejsce. Przeglądarki są bardzo tolerancyjne w stosunku do tych rzeczy.

Przestrzeń była wymagana, aby parsery HTML traktowały końcowy ukośnik jako nierozpoznany atrybut.

Wspieranie odpowiedzi bobince'a ze zrzutem ekranu Netscape 4.80 pokazującym dokumenty

data:text/html,<title>space</title>foo<br />bar

(u góry po lewej, renderowane podziały wierszy) i

data:text/html,<title>no space</title>foo<br/>bar

(na dole po lewej, podział wiersza zignorowany).

Wysyłanie jako odpowiedź, aby pokazać zdjęcie

Związane stycznie: w rzeczywistości miałem obszerną odpowiedź identyfikującą przyczynę takiego niewłaściwego zachowania starożytnych przeglądarek (i wynikającą z niej rekomendację uwzględnienia spacji) w niezrozumianych specyfikacjach SGML, a mianowicie SGML Null End Tag ( NET ) (gdzie 1<tag/2/3równa się 1<tag>2</tag>3tak 1<tag/>2właściwie oznaczałaby 1<tag>>2), ale nie tylko nie byłem w stanie znaleźć dobrego dowodu i konkretnej wersji normy, nie byłem nawet w stanie pojąć właściwego zachowania zgodnego z normami. Tak mało nieprzetworzonych linków w celach informacyjnych:

• notatka walidatora w3c wspominająca o problematycznym zamykającym ukośniku i wskazująca na
• Puste elementy w SGML, HTML, XML i XHTML @ www.cs.tut.fi/~jkorpela/
• Uważaj na XHTML: Null End Tags (NET) stwierdzające, że

  Jednak nadal istnieją mniejsze programy klienckie, które poprawnie obsługują tagi zerowe. Jednym z bardziej znanych programów użytkownika, które go obsługują, jest walidator W3C.

(Obecnie nie można tam odtworzyć, ale popiera stwierdzenie Lee Kowalkowskiego dotyczące wielu przeglądarek, których to dotyczy).

• Wersja robocza XML W3C 07 sierpnia 97 - najnowsza wersja robocza specyfikacji, która zawiera odniesienie do zerowego znacznika końcowego we fragmencie DTD:NET "/>"

Czy te problemy są nadal aktualne, czy też nadal dodajemy dodatkowe spacje ze względu na, powiedzmy, zgodność z IE3?

Byliście blisko - to dla Netscape 4.

Ciekawie jest zobaczyć inne racjonalizacje, ale to wszystko, do czego było przeznaczone.

Nie, miejsce nie jest wymagane, ale niektóre starsze przeglądarki muszą poprawnie renderować te tagi. Właściwy sposób to zrobić bez dodatkowego miejsca, ponieważ jest to coś, co XHTML odziedziczył po XML.

W XHTML tagi br muszą być zamknięte, ale spacja nie jest konieczna . To kwestia stylistyczna. W HTML tagów br nie można zamknąć, więc oba są błędne.

Spacja sprawia, że ​​tagi są bardziej czytelne. Jestem wielkim zwolennikiem formatowania dla bardziej czytelnego kodu. Takie drobne rzeczy mogą się przydać. Bez spacji tag zamykający wtapia się w tag otwierający. Przetwarzanie go zajmuje mi tylko chwilę dłużej, ponieważ szybko czytam kod.

Co by było, gdyby był tam bardzo leniwy autor HTML, a może bał się cudzysłowów. Weź pod uwagę następujące kwestie, jeśli byłeś jego robotem indeksującym strony ...

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

przeciw

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

To może wydawać się małe, ale zobacz, co może zrobić, jeśli nie ma miejsca. Robot nie będzie wiedział, czy ukośnik jest częścią adresu URL, czy częścią tagu zamykającego.

Myślę, że biała przestrzeń to sposób na wzmocnienie idei, że ten tag jest pusty i zamyka się sam.

Dzisiaj nie używam już spacji, ponieważ nigdy nie miałem problemu z brakiem spacji.