Pourquoi CSS n'autorise-t-il pas les commentaires sur une seule ligne? [fermé]

Je comprends que CSS ne prend en charge que les commentaires sur plusieurs lignes tels que

/* foobar */

Pourquoi les commentaires sur une seule ligne ne sont-ils pas pris en charge?

// foobar

Ils sont tout aussi courants en programmation et semblent particulièrement utiles pour un langage comme CSS où chaque règle est sur sa propre ligne.

S'il n'y avait pas de raison historique particulière pour cette décision, qu'est-ce qui a empêché les navigateurs d'aller vers la prise en charge?

Rétrocompatibilité

L'introduction de commentaires sur une seule ligne dans la syntaxe CSS pourrait changer la signification des fichiers qui utilisent actuellement le jeton //. Les éditeurs de navigateurs sont très réticents à introduire des modifications susceptibles de casser les pages existantes.

CSS est défini avec des règles d'analyse très précises "tolérantes aux erreurs", ce qui signifie que même si vous écrivez quelque chose de syntaxiquement illégal, il existe des règles précises sur la façon dont l'analyse doit se dérouler. Si une séquence illégale de caractères (comme //) est détectée dans une déclaration, la déclaration actuelle est ignorée et tout jusqu'à ce que le point-virgule suivant soit ignoré.

CSS est conçu comme ceci pour permettre l'introduction d'une nouvelle syntaxe sans casser les anciens navigateurs. Les anciens navigateurs ignoreront simplement les déclarations contenant une syntaxe non prise en charge et continueront après.

Mais cette logique suppose que "l'unité" à traiter ou à ignorer est la déclaration. Si des commentaires sur une seule ligne étaient introduits, cela signifierait que l'analyse après //devrait sauter jusqu'au prochain saut de ligne au lieu du prochain point-virgule, ce qui change les règles qui sont analysées et celles qui sont ignorées. Cela pourrait potentiellement changer la signification des fichiers CSS existants de manière surprenante.

Un exemple:

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

Ici, j'ai doublé par erreur la barre oblique. La conséquence est que la déclaration de police est ignorée, mais tout le reste fonctionne bien. Si le support des //commentaires était introduit, soudainement l'accolade de fermeture serait commentée, ce qui pourrait casser tout le reste de la feuille de style.

Maintenant, vous pouvez dire que c'est ma faute puisque j'ai fait une erreur, mais cela ne change pas qu'un nombre inconnu de pages sur Internet puisse se casser ou s'afficher étrangement pour des raisons obscures.

Tout changement de ce type qui rompt la compatibilité descendante doit être considéré avec beaucoup d'attention, et les commentaires sur une seule ligne ne sont probablement pas suffisamment convaincants pour le risque, car le seul avantage est qu'il vous permet d'économiser quelques frappes.

Donc, si CSS devait avoir des commentaires sur une seule ligne, il aurait probablement dû être introduit depuis le début. Mais CSS a commencé comme un langage très simple et avoir à l'époque deux syntaxes de commentaires différentes aurait été considéré comme une complexité inutile. (Même ANSI C n'avait pas de commentaires sur une seule ligne.)

La prise en charge d'un autre élément de syntaxe n'est pas si simple: il existe de nombreux outils qui devraient être capables de gérer un style de commentaire supplémentaire. En fait, je ne serais pas surpris de voir que la plupart des tokéniseurs / analyseurs ignorent simplement les nouvelles lignes, les remplaçant probablement par ;.

S'il serait essentiel à la langue, à savoir rendre la vie des développeurs beaucoup plus facile, cela pourrait se faire. Par exemple, ne pas avoir toute sorte de commentaires en CSS serait sucer, et il serait en vaut la peine d'ajouter des éléments de syntaxe spécifiques qui délimitent des commentaires. //-les commentaires de style d'autre part? ... Je ne vois pas l'intérêt. Voir /* Hello, World! */,: un commentaire d'une ligne.

En fait, vous vous attendez probablement à //des commentaires de style car vous y êtes habitué en C ++ ou dans des langages similaires. Cependant, CSS n'hérite pas de C ++, donc s'attendre à des fonctionnalités de syntaxe similaires est plutôt étrange.

De même, un programmeur Python prétendrait que CSS devrait également avoir #des commentaires de style; alors maintenant, devons-nous prendre en charge les deux styles? Ensuite, un gars du monde Haskell demanderait d'inclure --et {- -}aussi, et vous vous demanderez pourquoi ne reconnaissez-vous plus le code CSS.

Le petit avantage de //est que vous n'avez pas à taper trois caractères supplémentaires à la fin de votre commentaire sur une seule ligne (en fait, si nous commençons à compter les caractères, CSS devrait utiliser des commentaires de style Python). Cependant, si vous utilisez un éditeur de texte décent, vous commentez / décommentez le texte simplement en appuyant sur un raccourci de toute façon.

Ils semblent [...] particulièrement utiles pour un langage comme CSS où chaque règle est sur sa propre ligne.

Comme je l'ai expliqué, ils ne sont que légèrement utiles, pour un petit sous-ensemble de programmeurs, utilisant un petit sous-ensemble d'éditeurs de texte. Quant à votre remarque sur chaque règle sur sa propre ligne (je suis en désaccord avec votre remarque, soit dit en passant), cela m'a fait réfléchir à un autre point: comment les commentaires sont réellement utilisés.

Voici l'utilisation des commentaires CSS auxquels je peux penser:

• En tant qu'en-tête de fichier (informations de copyright, trucs de vanité, etc.)
• Comme délimiteur d'un groupe de styles.
• Comme explication d'un hack.
• En tant que détail sur un style ou une propriété particulière.

Dans les trois premiers cas, vous utiliserez quand même des commentaires de style multiligne. Cela est évident pour l'en-tête du fichier et l'explication d'un hack (la plupart des hacks nécessitent au moins une phrase et un lien hypertexte vers StackOverflow ou un article de blog); quant aux délimiteurs:

/**
 * Footer and sitemap styles.
 */

Le commentaire de style C est beaucoup plus visible que:

// Footer and sitemap styles.

enterré dans le texte.

Le problème est que la plupart des langages avec commentaires (c'est-à-dire C #, Java) sont des langages compilés, et le compilateur supprime TOUS les commentaires avant de présenter le contenu au consommateur (le CPU). CSS n'est pas compilé; généralement, le fichier est envoyé tel quel au fur et à mesure que le concepteur l'a développé, il n'est donc pas possible de supprimer les commentaires. Le commentaire de style // nécessite alors à la fois le symbole // ET un saut de ligne pour conserver l'exactitude syntaxique.

Oui, des minificateurs existent et oui, javascript autorise ce type de commentaire. Javascript autorise également eval () donc je ne pense pas que nous voulons le prendre comme modèle.