Dlaczego CSS nie pozwala na komentarze jednowierszowe? [Zamknięte]

Rozumiem, że CSS obsługuje tylko takie komentarze wielowierszowe

/* foobar */

Dlaczego nie ma obsługi komentarzy jednowierszowych?

// foobar

Są one równie powszechne w programowaniu i wydają się szczególnie przydatne w języku takim jak CSS, w którym każda reguła ma swoją własną linię.

Jeśli nie było konkretnego historycznego powodu tej decyzji, co uniemożliwiło przeglądarkom przejście na jej obsługę?

Kompatybilność wsteczna

Wprowadzenie do składni CSS komentarzy jednowierszowych może zmienić znaczenie plików, które obecnie używają tokena //. Dostawcy przeglądarek bardzo niechętnie wprowadzają zmiany, które mogą potencjalnie uszkodzić istniejące strony.

CSS jest zdefiniowany z bardzo precyzyjnymi regułami parsowania „tolerującymi błędy”, co oznacza, że ​​nawet jeśli napiszesz coś nielegalnie składniowo, istnieją dokładne reguły dotyczące tego, jak parsować. Jeśli //w deklaracji zostanie wykryta niedozwolona sekwencja znaków (jak ), bieżąca deklaracja zostanie odrzucona, a wszystko do następnego średnika zostanie pominięte.

CSS został zaprojektowany w ten sposób, aby umożliwić wprowadzenie nowej składni bez przerywania starych przeglądarek. Stare przeglądarki po prostu pomijają deklaracje zawierające nieobsługiwaną składnię i kontynuują po.

Ale ta logika zakłada, że ​​„jednostka” do przetworzenia lub pominięcia jest deklaracją. Jeśli wprowadzono komentarze jednowierszowe, oznaczałoby to, że parsowanie po //powinno przeskoczyć do następnego podziału linii zamiast do następnego średnika, co zmienia, które reguły są analizowane, a które pomijane. Może to potencjalnie zmienić znaczenie istniejących plików CSS w zaskakujący sposób.

Przykład:

P { font: 12px//16px; }
... hundreds of additional lines of CSS...

Tutaj omyłkowo podwoiłem cięcie. W konsekwencji deklaracja czcionki jest ignorowana, ale cała reszta działa dobrze. Gdyby wprowadzono obsługę //komentarzy, nagle nawias zamykający zostałby skomentowany, potencjalnie niszcząc całą resztę arkusza stylów.

Teraz możesz powiedzieć, że to moja wina, ponieważ popełniłem błąd, ale to nie zmienia faktu, że nieznana liczba stron w Internecie może się zepsuć lub dziwnie renderować z niejasnych powodów.

Każda taka zmiana, która narusza wsteczną kompatybilność, powinna być rozważana bardzo ostrożnie, a komentarze w jednym wierszu prawdopodobnie nie są wystarczająco przekonujące ze względu na ryzyko, ponieważ jedyną korzyścią jest zaoszczędzenie kilku naciśnięć klawiszy.

Więc jeśli CSS powinien mieć komentarze pojedynczej linii, to prawdopodobnie powinien być wprowadzony od samego początku. Ale CSS zaczynał jako bardzo prosty język, a stosowanie dwóch różnych składni komentarzy byłoby wówczas postrzegane jako niepotrzebna złożoność. (Nawet ANSI C nie miał komentarzy jednowierszowych.)

Obsługa kolejnego elementu składniowego nie jest taka prosta: istnieje wiele narzędzi, które powinny być w stanie obsłużyć jeszcze jeden styl komentarzy. W rzeczywistości nie byłbym zaskoczony, widząc, że większość tokenizerów / parserów po prostu ignoruje nowe linie, prawdopodobnie zastępując je ;.

Jeśli byłoby to niezbędne dla języka, tj. Znacznie ułatwiło życie programistom , można to zrobić. Na przykład, nie mając jakichkolwiek komentarzy w CSS będzie ssać, a byłoby to warte wysiłku, aby dodać konkretne elementy składniowe, które ograniczają komentarze. //- z drugiej strony komentarze w stylu? ... Nie widzę sensu. Zobacz /* Hello, World! */: komentarz jednowierszowy.

Właściwie prawdopodobnie spodziewasz się //komentarzy w stylu, ponieważ przyzwyczaiłeś się do nich w C ++ lub podobnych językach. Jednak CSS nie dziedziczy po C ++, więc oczekiwanie podobnych funkcji składniowych jest dość dziwne.

Podobnie programista Python twierdziłby, że CSS powinien również mieć #komentarze w stylu; czy teraz musimy wspierać oba style? Wtedy facet ze świata Haskell poprosiłby o uwzględnienie, --a {- -}także, a ty zadajesz sobie pytanie, dlaczego nie rozpoznajesz już kodu CSS.

Niewielką zaletą //jest to, że nie musisz wpisywać trzech dodatkowych znaków na końcu komentarza jednowierszowego (w rzeczywistości, jeśli zaczniemy liczyć znaki, CSS powinien używać komentarzy w stylu Python). Jeśli jednak korzystasz z przyzwoitego edytora tekstu, komentujesz / odkomentujesz tekst, po prostu i tak naciskając skrót.

Wydają się [...] szczególnie przydatne w języku takim jak CSS, w którym każda reguła ma swoją własną linię.

Jak wyjaśniłem, są one tylko nieznacznie przydatne dla małego podzbioru programistów, używającego niewielkiego podzbioru edytorów tekstu. Jeśli chodzi o twoją uwagę na temat każdej reguły na własnej linii (swoją drogą, nie zgadzam się z twoją uwagą), to skłoniło mnie do zastanowienia się nad inną kwestią: w jaki sposób komentarze są faktycznie używane.

Oto użycie komentarzy CSS, o których mogę myśleć:

• Jako nagłówek pliku (informacje o prawach autorskich, marności itp.)
• Jako ogranicznik grupy stylów.
• Jako wyjaśnienie włamania.
• Jako szczegół na temat określonego stylu lub właściwości.

W pierwszych trzech przypadkach i tak użyjesz komentarzy w stylu wieloliniowym. Jest to oczywiste w przypadku nagłówka pliku i wyjaśnienia włamania (większość włamań wymaga co najmniej zdania i hiperłącza do StackOverflow lub artykułu na blogu); co do ograniczników:

/**
 * Footer and sitemap styles.
 */

Komentarz w stylu C jest znacznie bardziej widoczny niż:

// Footer and sitemap styles.

pochowany w tekście.

Problem polega na tym, że większość języków z komentarzami (tj. C #, Java) to języki skompilowane, a kompilator usuwa WSZYSTKIE komentarze przed przedstawieniem treści konsumentowi (procesorowi). CSS nie jest kompilowany; generalnie plik jest wysyłany w niezmienionej postaci w miarę jego opracowywania, więc nie ma możliwości usunięcia komentarzy. Komentarz // w stylu wymaga więc zarówno symbolu // ORAZ wysuwu wiersza, aby zachować poprawność składniową.

Tak, istnieją minizatory i tak, javascript pozwala na tego typu komentarze. JavaScript pozwala także na eval (), więc nie sądzę, że chcemy brać to za model.