Bert Bos, coordinateur de l'activité
styleCopyright © 1994–2023 W3C® Privacy policy
Last updated lun. 11 sept. 2023 17:41:20
Ceci est une traduction. Elle peut avoir des erreurs ou être dépassée par rapport à la version anglaise. Traducteur(-trice): Anne-Marie Luigi
CSS est à la fois une norme et une technologie en développement. Savoir quelle partie de CSS est terminée et quelle partie ne peut pas encore être utilisée est un challenge. C'est comme ça depuis de nombreuses années et c'est susceptible de le rester pour un peu plus longtemps : la partie standard se développe lentement, la partie encore en développement s'est également développée, mais devrait éventuellement diminuer.
Cet article explique comment le groupe de travail CSS assure lui-même le suivi. Cela vous sera peut-être utile la prochaine fois que vous verrez une nouvelle publication sur le site du W3C et que vous vous demanderez à quel point elle est proche d'une norme.
Pour les fabricants de logiciels, il existe un moyen facile de savoir quelles parties de CSS doivent être implémentées et quelles parties ne le sont pas encore. Depuis 2007, le groupe de travail publie des instantanés qui expliquent exactement cela. Une grande partie du texte de cet article est en fait tirée de l'instantané de 2010.
Jusqu'à présent, il y a eu quatre instantanés, le plus récent s'appelle CSS Snapshot 2017. L'intention est d'en faire apparaître de nouveaux tous les un ou deux ans, en fonction du degré de stabilité de CSS au cours de cette période. L'instantané le plus récent peut toujours être trouvé à cette adresse URL :
Les implémenteurs intéressés par les fonctionnalités expérimentales, et tous ceux qui veulent aider à développer le CSS, peuvent également trouver la page de travail actuel du CSS utile : elle montre l'état actuel et une brève description de toutes les parties existantes du CSS.
Pour les utilisateurs de CSS, la situation est malheureusement moins claire. Même si une partie du CSS devient une norme (c'est-à-dire une recommandation du W3C), cela signifie seulement que cette partie a été correctement mise en œuvre dans un certain nombre d'implémentations. Cela ne signifie pas que toutes les implémentations de CSS le supportent. La méthode par tâtonnements et des solutions de secours restent nécessaires.
À l'origine, en 1994-1995, il était prévu de créer une seule spécification CSS, de taille comparable, mais avec des caractéristiques légèrement différentes de celles du niveau 2 actuel ( avec mise en page du template, titres en enfilade, colonnes, polices téléchargeables et en-têtes et pieds de page, mais sans positionnement absolu). Ce serait un langage de feuille de style "temporaire", suffisamment bon pour éviter des choses comme les balises FONT et l'utilisation abusive des tableaux HTML pour une période qui pourrait aller jusqu'à dix ans. L'expérience aiderait à créer un successeur meilleur et plus puissant.
Les choses ne se sont pas passées comme ça. Il est rapidement devenu évident que les fabricants de navigateurs de l'époque n'étaient pas encore assez compétents en typographie et en texte structuré, et que CSS devait être beaucoup plus simple si nous voulions qu'il soit implémenté. Cela a conduit à la scission entre les niveaux 1 et 2. Plus tard, nous avons également découvert que les utilisateurs ne voulaient pas remplacer CSS et voulaient plutôt le faire évoluer.
Le groupe de travail CSS a choisi d'adopter une approche modulaire pour CSS au-delà du niveau 2, où chaque module définit une partie de CSS, plutôt que d'écrire une seule spécification monolithique. Cela divise la spécification en blocs plus faciles à gérer et permet une amélioration plus immédiate et incrémentale de CSS.
Un document séparé, le CSS snapshot, définit la portée et l'état actuels de CSS. Il ne comprend que des modules que le groupe de travail considère comme stables et pour lesquels il y a suffisamment d'expérience de mise en œuvre pour être sûr de cette stabilité.
Les spécifications listées dans le snapshot ne sont cependant pas complètement gelées. Elles comprennent les W3C Candidate Recommendations (voir ci-dessous). Mais même les W3C Recommendations (normes) peuvent encore faire l'objet d'errata.
Module et snapshot sont deux types de documents. Le groupe de travail CSS utilise ces appellations comme expliqué ci-dessus, mais d'autres groupes de travail peuvent les utiliser de différentes façons. D'autre part, pour indiquer la stabilité de chaque document, le W3C a un vocabulaire que tous les groupes de travail partagent :
D'après l'expérience du CSS WG, la procédure de recommandation n'est pas linéaire. La révision plus large déclenchée par un LCWD donne souvent lieu à au moins un autre projet de travail, voire plusieurs. Plus significatif encore, l'expérience montre que de nombreuses spécifications entrent deux fois dans le CR, parce que les tests de mise en œuvre mettent souvent en évidence des problèmes importants dans la spécification et la renvoient donc à l'ébauche de travail. Par conséquent, bien que CSS WG ait une idée claire de la stabilité des spécifications CSS, il est difficile pour quelqu'un de l'extérieur du groupe de travail d'arriver à cette même compréhension basée sur le statut officiel d'une spécification. Pour cette raison, un CSS Snapshot n'inclut pas nécessairement tous les documents du CR : le groupe de travail peut déjà savoir qu'un certain CR devra être révisé.
Cascading Style Sheets n'a pas de versions au sens traditionnel, mais plutôt des niveaux. Chaque niveau CSS s'appuie sur le précédent, affinant les définitions et ajoutant des fonctionnalités. L'ensemble de caractéristiques de chaque niveau supérieur est un sur-ensemble de tout niveau inférieur, et le comportement autorisé pour une caractéristique donnée dans un niveau supérieur est un sous-ensemble de celui autorisé dans les niveaux inférieurs. Un agent utilisateur qui se conforme à un niveau supérieur de CSS est donc également en conformité avec tous les niveaux inférieurs.
Bert Bos, coordinateur de l'activité
styleLast updated lun. 11 sept. 2023 17:41:20