Comprendo che i CSS supportano solo commenti su più righe come questi
/* foobar */
Perché non esiste il supporto per i commenti a riga singola.
// foobar
Sono altrettanto comuni nella programmazione e sembrano particolarmente utili per una lingua come CSS in cui ogni regola si trova sulla propria riga.
Se non c'era una ragione storica particolare per questa decisione, cosa ha impedito ai browser di spostarsi per supportarlo?
Compatibilità con le versioni precedenti
L'introduzione di commenti a riga singola alla sintassi CSS potrebbe modificare il significato dei file che attualmente utilizzano il token // . I fornitori di browser sono molto riluttanti a introdurre modifiche che potrebbero potenzialmente violare le pagine esistenti.
Il CSS è definito con regole di parsing "tolleranti agli errori" molto precise, il che significa che anche se scrivi qualcosa di sintatticamente illegale ci sono regole precise su come procedere con l'analisi. Se viene rilevata una sequenza illegale di caratteri (come // ) all'interno di una dichiarazione, la dichiarazione corrente viene scartata e tutto viene saltato fino alla prossima virgola.
I CSS sono progettati in questo modo per consentire l'introduzione di nuove sintassi senza rompere i vecchi browser. I vecchi browser salteranno semplicemente le dichiarazioni che contengono sintassi non supportate e continueranno dopo.
Ma questa logica presuppone che la "unità" da elaborare o saltare sia la dichiarazione. Se fossero introdotti commenti a riga singola, significherebbe che l'analisi dopo // dovrebbe saltare fino alla prossima interruzione di riga anziché fino alla prossima virgola, che cambia le regole che vengono analizzate e che vengono saltate. Questo 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 font viene ignorata, ma tutto il resto funziona bene. Se fosse stato introdotto il supporto per // -commenti, improvvisamente la parentesi di chiusura sarebbe stata commentata, rompendo potenzialmente tutto il resto del foglio di stile.
Ora si potrebbe dire che è colpa mia da quando ho fatto un errore, ma questo non cambia il fatto che un numero sconosciuto di pagine su Internet potrebbe rompersi o renderlo stranamente per motivi oscuri.
Qualunque cambiamento che rompa la retrocompatibilità dovrebbe essere considerato con molta attenzione, e i commenti su una singola riga probabilmente non sono abbastanza convincenti per il rischio, dal momento che l'unico vantaggio è che ti consente di risparmiare alcune sequenze di tasti.
Quindi, se i CSS dovessero avere commenti in linea singola, probabilmente sarebbe stato introdotto sin dall'inizio. Ma i CSS iniziarono come un linguaggio molto semplice e avere due diverse sintassi dei commenti sarebbe stata vista come una complessità inutile al momento. (Anche ANSI C non aveva commenti a riga singola.)
Supportare l'ennesimo elemento di sintassi non è così semplice: ci sono molti strumenti che dovrebbero essere in grado di gestire uno stile di commento aggiuntivo. In realtà, non sarei sorpreso di vedere che la maggior parte dei tokenizer / parser semplicemente ignorano le newline, probabilmente sostituendole con ; .
Se sarebbe essenziale per la lingua, cioè rendere le vite degli molto degli sviluppatori più facili, ciò potrebbe essere fatto. Ad esempio, non avere alcun tipo di di commenti in CSS farebbe schifo, e varrebbe la pena di aggiungere specifici elementi di sintassi che delimitano i commenti. // -style commenti d'altra parte? ... Non vedo il punto. Vedi, /* Hello, World! */ : un commento su una riga.
In realtà, probabilmente ti aspetti i commenti in stile // perché sei abituato a loro in C ++ o lingue simili. Tuttavia, i CSS non ereditano dal C ++, quindi aspettarsi caratteristiche di sintassi simili è piuttosto strano.
Allo stesso modo, un programmatore Python affermerebbe che anche i CSS dovrebbero avere commenti in stile # ; quindi ora abbiamo bisogno di supportare entrambi gli stili? Quindi un ragazzo del mondo Haskell chiederà di includere -- e {- -} , e ti chiederai perché non riconosci il codice CSS.
Il piccolo vantaggio di // è che non devi digitare altri tre caratteri alla fine del tuo commento a riga singola (in realtà, se iniziamo a contare i caratteri, i CSS dovrebbero usare i commenti in stile Python). Tuttavia, se si utilizza un editor di testo decente, si commenta / decommenta il testo semplicemente premendo una scorciatoia comunque.
They [...] seem particularly useful for a language like CSS where each rule is on it's own line.
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 sulle singole regole sulla propria linea (non sono d'accordo con la tua osservazione, comunque), questo mi ha fatto riflettere su un altro punto: come vengono effettivamente utilizzati i commenti.
Ecco l'uso dei commenti CSS che mi viene in mente:
Nei primi tre casi, userete comunque 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 del 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 esempio C #, Java) sono lingue compilate e il compilatore elimina TUTTI i commenti prima di presentare il contenuto al consumatore (la CPU). Il CSS non è compilato; generalmente il file viene inviato invariato man mano che il designer lo ha sviluppato, quindi non vi è alcuna possibilità di eliminare i commenti. Il // commento di stile richiede quindi sia il // simbolo AND un avanzamento di riga per mantenere la correttezza sintattica.
Sì, esistono i minifiers e sì, javascript consente questo tipo di commento. Javascript consente anche eval () quindi non penso che vogliamo prenderlo come modello.