Tout à fait, on oublie trop souvent qu'une page web a pour objectif d'être un document et d'être lu. Mais d'un autre côté, la richesse des possibilités des standards est une réalité. L'auteur de l'article prend le parti de la décrire sans la souligner. Je trouve finalement son point de vue partial au moins pour cela.
CSS n'est pas un langage de programmation, oui. Et alors ? Pour programmer, il y a DOM et JavaScript !
Mais effectivement, quand on commence à intégrer des notions de programmation, on s'éloigne de l'approche document qui est celle vers laquelle HTML et CSS convergent. Le document prend de l'intelligence, avec les surcouts que l'on connait (accessibilité [si toute la page est d'origine masquée via CSS et peut être affichée via un appel javascript uniquement, que va voir le visiteur qui ne peut éxécuter le javascript ou qui utilise un média alternatif ?], compatibilité, performances diverses des navigateurs pour le meme fragment de code éxécuté, etc...).
Il est cependant possible de bénéficier à la fois des avantages de séparation forme/contenu de CSS et de la souplesse de DOM/javascript combinés. A condition pour le visiteur d'avoir un navigateur configuré pour accepter ces technologies, et pour le développeur de se forcer à maintenir cette séparation forme/contenu dans le cadre très permissif de javascript, pour maintenir l'accessibilité des contenus dans les navigateurs non-compatibles et/ou alternatifs. C'est là que le bât blesse bien souvent.
Que l'auteur de l'article trouve cela difficile en l'état aujourd'hui ne veut pas dire que les standards sont mauvais, incomplets ou inadaptés, c'est peut-être tout simplement un champ d'investigation possible pour élaborer des solutions basées sur les standards d'aujourd'hui, permettant de les exploiter encore plus aisément demain...
[^] # Re: Boff ....
Posté par Cali_Mero . En réponse au journal Un article intéressant sur (X)HTML/CSS. Évalué à 7.
CSS n'est pas un langage de programmation, oui. Et alors ? Pour programmer, il y a DOM et JavaScript !
Mais effectivement, quand on commence à intégrer des notions de programmation, on s'éloigne de l'approche document qui est celle vers laquelle HTML et CSS convergent. Le document prend de l'intelligence, avec les surcouts que l'on connait (accessibilité [si toute la page est d'origine masquée via CSS et peut être affichée via un appel javascript uniquement, que va voir le visiteur qui ne peut éxécuter le javascript ou qui utilise un média alternatif ?], compatibilité, performances diverses des navigateurs pour le meme fragment de code éxécuté, etc...).
Il est cependant possible de bénéficier à la fois des avantages de séparation forme/contenu de CSS et de la souplesse de DOM/javascript combinés. A condition pour le visiteur d'avoir un navigateur configuré pour accepter ces technologies, et pour le développeur de se forcer à maintenir cette séparation forme/contenu dans le cadre très permissif de javascript, pour maintenir l'accessibilité des contenus dans les navigateurs non-compatibles et/ou alternatifs. C'est là que le bât blesse bien souvent.
Que l'auteur de l'article trouve cela difficile en l'état aujourd'hui ne veut pas dire que les standards sont mauvais, incomplets ou inadaptés, c'est peut-être tout simplement un champ d'investigation possible pour élaborer des solutions basées sur les standards d'aujourd'hui, permettant de les exploiter encore plus aisément demain...