Perché i CSS non consentono commenti a riga singola? [chiuso]

Comprendo che CSS supporta solo commenti su più righe come tali

/* foobar */

Perché non c'è supporto per i commenti a riga singola.

// foobar

Sono altrettanto comuni nella programmazione e sembrano particolarmente utili per un linguaggio come CSS in cui ogni regola si trova sulla propria linea.

Se non vi fosse alcun motivo storico particolare per questa decisione, cosa ha impedito ai browser di spostarsi verso il supporto?

Compatibilità con le versioni precedenti

L'introduzione di commenti a riga singola nella sintassi CSS potrebbe modificare il significato dei file che attualmente utilizza il token //. I fornitori di browser sono molto riluttanti a introdurre modifiche che potrebbero potenzialmente spezzare le pagine esistenti.

Il CSS è definito con regole di analisi molto precise "tolleranti agli errori", il che significa che anche se scrivi qualcosa di sintatticamente illegale, ci sono regole precise su come dovrebbe procedere l'analisi. Se //viene rilevata una sequenza illegale di caratteri (come ) all'interno di una dichiarazione, la dichiarazione corrente viene scartata e tutto viene ignorato fino al punto e virgola successivo.

CSS è progettato in questo modo per consentire l'introduzione di una nuova sintassi senza rompere i vecchi browser. I vecchi browser salteranno semplicemente la dichiarazione che contiene una sintassi non supportata e continueranno dopo.

Ma questa logica presuppone che la "unità" sia elaborata o ignorata sia la dichiarazione. Se sono stati introdotti commenti a riga singola, ciò significa che l'analisi dopo //dovrebbe saltare fino alla successiva interruzione di riga anziché fino al punto e virgola successivo, che modifica quali regole vengono analizzate e quali vengono ignorate. Ciò potrebbe potenzialmente cambiare il significato dei file CSS esistenti in modi sorprendenti.

Un esempio:

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

Qui ho erroneamente raddoppiato la barra. La conseguenza è che la dichiarazione dei caratteri viene ignorata, ma tutto il resto funziona bene. Se //venisse introdotto il supporto per i commenti, all'improvviso la parentesi graffa di chiusura verrebbe commentata, potenzialmente rompendo tutto il resto del foglio di stile.

Ora potresti dire che è colpa mia da quando ho fatto un errore, ma ciò non cambia che un numero sconosciuto di pagine su Internet potrebbe rompersi o renderizzarsi in modo strano per ragioni oscure.

Qualsiasi modifica che rompa la compatibilità con le versioni precedenti deve essere considerata con molta attenzione e probabilmente i commenti a riga singola non sono abbastanza convincenti per il rischio, poiché l'unico vantaggio è che consente di risparmiare alcune sequenze di tasti.

Quindi, se i CSS dovessero avere commenti a riga singola, probabilmente avrebbero dovuto essere introdotti dall'inizio. Ma i CSS iniziarono come un linguaggio molto semplice e avere due diverse sintassi dei commenti sarebbe stato visto come una complessità inutile al momento. (Anche ANSI C non aveva commenti a riga singola.)

Supportare ancora un altro elemento di sintassi non è così semplice: ci sono molti strumenti che dovrebbero essere in grado di gestire ancora uno stile di commento aggiuntivo. In realtà, non sarei sorpreso di vedere che la maggior parte dei tokenizer / parser semplicemente ignora le nuove righe, probabilmente sostituendole con ;.

Se fosse essenziale per il linguaggio, ovvero rendere la vita degli sviluppatori molto più semplice, ciò potrebbe essere fatto. Ad esempio, non avere alcun tipo di commento nei CSS farebbe schifo, e varrebbe la pena lo sforzo di aggiungere specifici elementi di sintassi che delimitano i commenti. //in stile commenti d'altro canto? ... Non vedo il punto. Vedi /* Hello, World! */,: un commento di una riga.

In realtà, probabilmente ti aspetti //commenti in stile perché ti sei abituato in C ++ o in linguaggi simili. Tuttavia, CSS non eredita dal C ++, quindi aspettarsi simili funzioni di sintassi è piuttosto strano.

Allo stesso modo, un programmatore di Python affermerebbe che anche i CSS dovrebbero avere #commenti in stile; quindi ora, dobbiamo supportare entrambi gli stili? Poi un ragazzo da Haskell mondo avrebbe chiesto di includere --e {- -}pure, e ti chiedersi perché non si riconosce il codice CSS più.

Il piccolo vantaggio //è che non è necessario digitare altri tre caratteri alla fine del commento a riga singola (in realtà, se iniziamo a contare i caratteri, i CSS dovrebbero utilizzare i commenti in stile Python). Tuttavia, se si utilizza un editor di testo decente, si commenta / rimuove il testo semplicemente premendo comunque una scorciatoia.

Sembrano [...] particolarmente utili per un linguaggio come CSS in cui ogni regola si trova sulla propria riga.

Come ho spiegato, sono solo leggermente utili, per un piccolo sottoinsieme di programmatori, usando un piccolo sottoinsieme di editor di testo. Per quanto riguarda la tua osservazione su ciascuna regola sulla sua stessa linea (non sono d'accordo con la tua osservazione, a proposito), questo mi ha fatto riflettere su un altro punto: come i commenti vengono effettivamente utilizzati.

Ecco l'uso dei commenti CSS che mi viene in mente:

• Come intestazione di file (informazioni sul copyright, elementi di vanità, ecc.)
• Come delimitatore di un gruppo di stili.
• Come una spiegazione di un hack.
• Come dettaglio di un particolare stile o proprietà.

Nei primi tre casi, utilizzerai comunque i commenti in stile multilinea. Questo è ovvio per l'intestazione del file e la spiegazione di un hack (la maggior parte degli hack richiede almeno una frase e un collegamento ipertestuale a StackOverflow o un articolo di blog); come per i delimitatori:

/**
 * Footer and sitemap styles.
 */

Il commento in stile C è molto più visibile di:

// Footer and sitemap styles.

sepolto nel testo.

Il problema è che la maggior parte delle lingue con commenti (ad es. C #, Java) sono lingue compilate e il compilatore elimina TUTTI i commenti prima di presentare il contenuto al consumatore (la CPU). CSS non è compilato; generalmente il file viene inviato invariato durante lo sviluppo del designer, quindi non è possibile eliminare i commenti. Il commento in stile // richiede quindi sia il simbolo // sia un avanzamento riga per mantenere la correttezza sintattica.

Sì, esistono dei minificatori e sì, JavaScript consente questo tipo di commento. Javascript consente anche eval (), quindi non credo che vogliamo prenderlo come modello.