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


13

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?


3
C'est une mauvaise décision. Ils doivent autoriser les commentaires sur une seule ligne.
Tulains Córdova

1
@Goose: avez-vous consulté sass-lang.com ?
kevin cline


1
@ TulainsCórdova Je n'ai pas approuvé les réponses, je viens de souligner que cette discussion a déjà eu lieu.
Eric King

2
Cette question a obtenu une réponse plus technique que les réponses ici. "CSS traite les sauts de ligne comme tous les autres espaces, et ne serait pas en mesure de déterminer la fin du commentaire sans un délimiteur de fin."
Goose

Réponses:


8

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


Oh, // est un jeton en CSS? Dis-le.
Michael Blackburn

Actuellement //sera analysé en deux "jetons de délimitation" avec à son tour n'est pas autorisé n'importe où dans la grammaire. Voir w3.org/TR/css-syntax-3/#tokenization pour plus de détails.
JacquesB

+1 pour MainMa pour savoir pourquoi il a commencé /**/, mais en acceptant celui-ci car il explique également pourquoi il n'a pas changé.
Goose

8

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.


JavaScript prend également en charge les //commentaires sur une seule ligne .
Tulains Córdova

Je dirais que //c'est très commun dans de nombreuses langues et le concept derrière c'est plus que la syntaxe, il fonctionne également différemment. Cela dit, c'est la réponse la plus approfondie à ce jour.
Goose

Je ne pense pas que ce soit un petit sous-ensemble du tout. Presque n'importe qui écrivant du CSS à l'état brut trouverait plus facile d'ajouter des commentaires avec //. Mais le point de compatibilité ascendante le rend sans objet.
O'Rooney

-5

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.


3
Cette réponse n'a aucun sens. "Il n'y a aucune possibilité de supprimer le commentaire" - bien sûr, le commentaire est supprimé par l'analyseur exactement comme dans n'importe quelle autre langue. Sinon, comment CSS pourrait-il avoir les /* */commentaires?
JacquesB

Je voulais dire un tiers intermédiaire entre le concepteur et le consommateur. Le compilateur est cet intermédiaire dans les langages compilés. L '"analyseur" auquel vous faites référence est un sous-système du navigateur, le consommateur final du contenu.
Michael Blackburn

Alors, pourquoi le parseur ne peut-il pas supprimer les //commentaires alors qu'il peut se retirer /* */?
JacquesB

1
Il pourrait le faire, mais il doit alors rechercher à la fois le // et le fil de ligne, et les fils de ligne sont principalement du contenu sémantique et non syntaxique. CSS, tel que conçu, traite tous les espaces de la même manière. Pour prendre en charge // vous avez maintenant un espace "spécial" et en outre, cet espace "spécial" peut être un caractère (\ n) et deux (\ r \ n).
Michael Blackburn

3
@MichaelBlackburn: DSSSL (qui est un prédécesseur de CSS utilisant la syntaxe d'expression S) a également des commentaires sur une seule ligne. Cela n'a rien à voir avec les langages impératifs et déclaratifs.
JacquesB
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.