Spacje przed ukośnikiem w html5 - dawać je czy nie?

Question

Czy pisząc w html-5 nadal należy dawać spacje przed ukośnikami w tagach takich jak <meta />, <link />, <br />, <hr />,  czy może powinno się już pisać <meta/>, <link/>, <br/>, <hr/>?

Mirosław Zelent w jednym ze swoich filmów namawiał,  żeby sposób zapisu ze spacją i ukośnikiem w samozamykających się tagach, traktować jako normę i dobrą praktykę.

Zauważyłem że spacja przed ukośnikami jest usuwana z e-książek przez księgarnię Kobo, jeśli zmienić rozszerzenie .epub na .zip i wejść do środka folderu, to można zobaczyć że spacje z samozamykających się tagów są usunięte. Szczęśliwie zostawione są ukośniki. Podobnie jest z przykładowymi książkami w formacie epub, na stronie aplikacji Adobe Digital Editions.

Czy mamy jakąś wojnę na spacje w internecie, pomiędzy twórcami oprogramowania a twórcami standardów?

1.) Czy osoby które chcą pisać swój kod w sposób uporządkowany, powinny mimo to nadal wpisywać spację przed ukośnikiem, czy to już po prostu nie ma sensu?

2.) Czy html5 jest mniej porządny od xhtml5, czy może w przypadku piątki nie ma już różnicy?

3.) Czy w html-5 który ma przyjemniej wyglądający doctype można pisać w sposób uporządkowany tak jak w xhtml-u, i czy to będzie przeglądarkom i wyszukiwarkom przeszkadzało i utrudniało im życie?

Poza tym, jak osoba z tego forum o imieniu Kornel (taki facet w żółtymi sombrero) słusznie zauważył, tag <image> bez ukośnika wygląda głupio. Ja także wolę taga <image/> z ukośnikiem a najlepiej  ze spacją i ukośnikiem <image />, bo takie tagi wydają mi się piękniejsze. Chyba możemy pisać kody które są piękne?

W nawiązaniu do Kornela, z tego co on pisze to ja zrozumiałem że pisanie w xhtml-u szkodzi internetowi. A html w porównaniu z xhtml`em nie jest gorszy. Ale niestety, moim zdaniem, sprzyja bałaganiarstwu.

Jak zatem pisać Panie i Panowie, żeby było pięknie, prosto i uporządkowanie?

a.) sporządzać dokument html-5 ?

b.) sporządzać dokument  html-5, ale pisać posługując się składnią xhtml ?

c.) sporządzać dokument w xhtml-5, i oczywiście pisać ze składnią xhtml ?

A tak przy okazji, czasami spotyka się koderów którzy każdą dodatkową kreskę traktują jak kamień młyński u szyi, a przecież to nic nie powinno szkodzić w tym że kod będzie trochę dłuższy, no i co z tego że strona będzie się trochę dłużej wczytywała, to niech się dłużej wczytuje. W realnym fizycznym świecie są książki grubsze i chudsze, ale nikomu szczęśliwie nie przyszło do głowy żeby książki pocieniać, żeby łatwo się ładowały do ciężarówki która je powiezie do księgarni. Radziłbym nie przejmować się wielkością kodu, bo w końcu można by dojść do wniosku, że najlepszy kod to taki który nie ma kodu, a najlepsza treść ta taka która nie ma treści. Bo przecież treść strony internetowej czy e-booka także potrzebuje czasu żeby się załadować, prawda. A na szczęście nikt jeszcze nie ogranicza treści  po to tylko żeby się szybko wczytywała. To dlaczego kod ma być ograniczany? Przecież kod także jest treścią, i ta treść także powinna przyjemnie i pięknie wyglądać, jak się w nią wejrzy. Ograniczanie kodu powoduje to, że autor kodu nie może się połapać w kodzie, który sam przed miesiącem napisał.

Dariusz

Z miłymi pozdrowieniami

Answer 1

1.) Czy osoby które chcą pisać swój kod w sposób uporządkowany, powinny mimo to nadal wpisywać spację przed ukośnikiem, czy to już po prostu nie ma sensu?

Zacznijmy od tego, że sam ukośnik jest nonsensem i bełkotem pozostałym po "erze XHTML": http://kornel.ski/xhtml http://kornel.ski/xhtml/rip

 2.) Czy html5 jest mniej porządny od xhtml5, czy może w przypadku piątki nie ma już różnicy?

Powtarzasz jakieś stare głupoty. XHTML NIGDY nie był porządniejszy. To po prostu inny zapis składni HTML-a, zgodny z XML-em. Niczym więcej się to nie różni. Ba, w erze pre-HTML5 de facto KAŹDY dokument XHTML był niepoprawnym HTML-em (bo był serwowany ze złym typem MIME).

3.) Czy w html-5 który ma przyjemniej wyglądający doctype można pisać w sposób uporządkowany tak jak w xhtml-u, i czy to będzie przeglądarkom i wyszukiwarkom przeszkadzało i utrudniało im życie? 

A co ma XHTML do uporządkowanego kodu?

W HTML5 dozwolona jest składnia HTML i XHTML, bo gdyby tego nie zrobiono, to 90% stron w Sieci byłaby niepoprawna składniowa… Z tego też powodu specyfikacja HTML5 pozwala na syf. A w rzeczywistości NIE POWINNA zezwalać na używanie ukośnika poza ścisłym trybem XML (czyli typie MIME application/xhtml+xml).

Poza tym, jak osoba z tego forum o imieniu Kornel (taki facet w żółtymi sombrero)  

porneL nie jest z tego forum :D Ten gościu jest legendą polskiej sceny webdevu → http://ferrante.pl/life/ludzie-front-endu/ludzie-front-endu-kornel-pornel-lesinski/

 Chyba możemy pisać kody które są piękne?

Co jest pięknego w ukośniku? Jeśli dla Ciebie składnia XML-a jest piękna z powodu ukośnika, to… musisz jeszcze XML poznać ;)

A html w porównaniu z xhtml`em nie jest gorszy. Ale niestety, moim zdaniem, sprzyja bałaganiarstwu.

Jeśli piszesz w XHTML i nie ślesz tego jako application/xhtml+xml, to de facto produkujesz DOKŁADNIE taki sam kod… więc nie rozumiem tego argumentu. Co więcej: XHTML5 istnieje TYLKO przy tym typie MIME – w każdym innym przypadku jest to HTML.

Artykuły porneLa w całości odpowiadają na Twoje pytania.

Radziłbym nie przejmować się wielkością kodu

Czyli można produkować nadmiarowy kod, bo jest… piękny? Polecam poczytać o optymalizacjach pod sieć mobilną i podstawowe kwestie związane z zaprojektowaniem HTTP/2.

Bo przecież treść strony internetowej czy e-booka także potrzebuje czasu żeby się załadować, prawda. A na szczęście nikt jeszcze nie ogranicza treści  po to tylko żeby się szybko wczytywała. To dlaczego kod ma być ograniczany? Przecież kod także jest treścią, i ta treść także powinna przyjemnie i pięknie wyglądać, jak się w nią wejrzy.

Sorry, ale to jest bzdura. Owszem, kod HTML stwarza szkielet semantyczny treści, ale to nie oznacza, że ma być rozbuchany… To szkielet treści, a szkieletu się odwiedzającym nie pokazuje. Bo to po prostu obrzydliwe. Szkielet ma być ściśle określonych rozmiarów (bo inaczej to deformacja!) i ukryty w środku (bo inaczej to złamanie otwarte lub jeszcze coś gorszego…).

Ograniczanie kodu powoduje to, że autor kodu nie może się połapać w kodzie, który sam przed miesiącem napisał.

Kod developerski: https://github.com/Comandeer/comandeers-homepage

Kod produkcyjny: https://www.comandeer.pl

Jeśli autor kodu opiera się na kodzie produkcyjnym, zoptymalizowanym pod środowiska produkcyjne, to znaczy, że coś robi źle ;) W obecnym świecie, gdzie istnieje git i inne systemy kontroli wersji + wszelakie build tools problem, o którym mówisz nie istnieje.