— Il n’est pas possible d’appeler une définition depuis une autre définition, ce qui oblige à des doublons dans les définitions : par exemple, on définirait un style « police-helvetica », un style « taille-10 », et dans une autre définition on pourrait indiquer qu’on intègre les styles « police-helvetica » et « taille-10 », que l’on panacherait avec un fond coloré, etc.
C'est faux : si je fais
<style><!--
p, span, q {
font-size: 10pt;
}
--></style>
j'aurai bien <p>rouge</p><span>bleu</span><q>jaune</q>
En revanche, vous n’avez pas accès à la seconde lettre du paragraphe, vous ne pouvez pas définir un style qui s’appliquerait à une ligne de tableau sur deux
Sinon pour le XHTML, il existe toujours la solution idéale pour un front-end XHTML valide : pourquoi faire du XHTML plutôt que du HTML ? Pour pouvoir utiliser une source XML, transformée par XSLT en une page XHTML. Là, y'a vraiment de quoi faire, on peut bien étendre CSS pour pallier à ses limitations actuelles, en mettant par exemple une classe supplémentaire sur une balise sur deux ( <li class="xyz pair">...</li> <li class="xyz impair">...</li>, etc.)
XHTML, ça ne sert pas qu'à montrer à ses lecteurs que l'on a fait attention aux standards, et ce n'est pas qu'un buzzword. Ça peut aussi montrer qu'on a su faire plus simple que du code métier mélangé avec la présentation HTML 4, en ayant un corps métier en XML et une sortie indépendante du média (web, wap, RSS, PDF via XSL-FO, etc)
L'excellent livre "Comprendre XSLT" aborde notamment ces aspects.
# Quelques précisions
Posté par Nicolas Y . En réponse au journal Un article intéressant sur (X)HTML/CSS. Évalué à 7.
C'est faux : si je fais
<style><!--
p, span, q {
font-size: 10pt;
}
p { color: red; }
span { color: blue; }
q { color: yellow; }
--></style>
j'aurai bien <p>rouge</p><span>bleu</span><q>jaune</q>
Ok, pas encore dans CSS 2.1, mais dans CSS 3 ça y sera, cf http://gallery.theopalgroup.com/selectoracle/(...)
Je ne sais pas trop où en est l'implémentation, mais c'est prévu.
Sinon pour le XHTML, il existe toujours la solution idéale pour un front-end XHTML valide : pourquoi faire du XHTML plutôt que du HTML ? Pour pouvoir utiliser une source XML, transformée par XSLT en une page XHTML. Là, y'a vraiment de quoi faire, on peut bien étendre CSS pour pallier à ses limitations actuelles, en mettant par exemple une classe supplémentaire sur une balise sur deux ( <li class="xyz pair">...</li> <li class="xyz impair">...</li>, etc.)
XHTML, ça ne sert pas qu'à montrer à ses lecteurs que l'on a fait attention aux standards, et ce n'est pas qu'un buzzword. Ça peut aussi montrer qu'on a su faire plus simple que du code métier mélangé avec la présentation HTML 4, en ayant un corps métier en XML et une sortie indépendante du média (web, wap, RSS, PDF via XSL-FO, etc)
L'excellent livre "Comprendre XSLT" aborde notamment ces aspects.