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

14

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ę?

Gęś
źródło
3
To kiepska decyzja. Powinny umożliwiać komentarze w jednym wierszu.
Tulains Córdova
1
@ Goose: czy spojrzałeś na sass-lang.com ?
kevin cline
2
powiązane: stackoverflow.com/questions/2479351/…
Eric King
1
@ TulainsCórdova Nie poparłem odpowiedzi, wskazałem tylko, że ta dyskusja już się odbyła.
Eric King,
2
To pytanie otrzymało odpowiedź, która jest bardziej techniczna niż odpowiedzi tutaj. „CSS traktuje znaki nowej linii jak wszystkie inne białe znaki i nie byłby w stanie określić końca komentarza bez ogranicznika kończącego”.
Goose

Odpowiedzi:

9

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.)

JacquesB
źródło
Och, // czy token jest w CSS? Powiedz.
Michael Blackburn
Obecnie //zostaną podzielone na dwa „tokeny rozdzielające”, z kolei nigdzie w gramatyce nie jest dozwolone. Aby uzyskać szczegółowe informacje, patrz w3.org/TR/css-syntax-3/#tokenization .
JacquesB
+1 dla MainMa, dlaczego zaczął /**/, ale akceptując ten, ponieważ odpowiada również, dlaczego się nie zmienił.
Goose
8

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.

Arseni Mourzenko
źródło
JavaScript obsługuje także //komentarze jednowierszowe .
Tulains Córdova
Twierdziłbym, że //jest to bardzo powszechne w wielu językach, a jego koncepcja polega na czymś więcej niż na składni, a także działa inaczej. To powiedziawszy, jest to jak dotąd najbardziej szczegółowa odpowiedź.
Goose
Nie wydaje mi się, żeby w ogóle był to mały podzbiór. Prawie każdemu, kto pisze CSS na surowo, łatwiej byłoby dodawać komentarze za pomocą //. Ale punkt kompatybilności wstecznej sprawia, że ​​jest on dyskusyjny.
O'Rooney
-5

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.

Michael Blackburn
źródło
3
Ta odpowiedź nie ma żadnego sensu. „Nie ma możliwości usunięcia komentarza” - oczywiście, że jest on usuwany przez analizator składni dokładnie tak, jak w każdym innym języku. W przeciwnym razie w jaki sposób CSS może mieć /* */komentarze?
JacquesB
Miałem na myśli zewnętrznego pośrednika między projektantem a konsumentem. Kompilator jest tym pośrednikiem w skompilowanych językach. „Analizator składni”, o którym mówisz, jest podsystemem przeglądarki, ostatecznym konsumentem treści.
Michael Blackburn,
Po co więc parserowi usuwać //komentarze, kiedy można je usuwać /* */?
JacquesB
1
Może, ale potem musi szukać // i nowego wiersza, a wiersze to głównie treść semantyczna, a nie składniowa. Zaprojektowany CSS traktuje wszystkie białe znaki tak samo. Aby wesprzeć //, masz teraz „specjalne” białe znaki, a ponadto, że „specjalne” białe znaki mogą być jednym znakiem (\ n) i może być dwoma (\ r \ n).
Michael Blackburn
3
@MichaelBlackburn: DSSSL (który jest poprzednikiem CSS przy użyciu składni S-expression) ma również komentarze jednowierszowe. Nie ma to nic wspólnego z językami imperatywnymi i deklaratywnymi.
JacquesB