Je ne vois pas pourquoi tu dis non. ce n'est pas parce qu'un widget est plus qu'un élément d'un langage de markup que ça n'en est pas un.
Ok tu te sens d'écrire un truc du genre
if </b>
Moi pas.
C'est pas le contenu, c'est la forme du contenu.
La forme du contenu, c'est le contenu. Sinon c'est de l'information brute. Le truc c'est que la mise en page du contenu dépend à la fois de l'appli elle-même et des traitements qu'elle fait que des CSS GTK3. Et comme le DOM est en vrac il n'y a pas possibilité de tracer la séparation. C'est comme si dans OpenOffice ton texte s'ouvrait différament en fonction de ton choix de thème. C'est idiot.
pourquoi CSS n'est il pas adapté
J'ai déjà répondu aussi. Un widget N'EST PAS un balisage. Je donne plus d'exemple pour que tu saisisses le problème, mais ca ne passe pas apparament.
CSS est un descripteur de mise en forme qui fonctionne par selection. Si on fait plus que de la mise en forme et/ou que l'on ne dispose pas de sélecteurs puissants (en l'occurence les deux dans GTK3) il faut autre chose. CSS n'est pas fait pour décrire l'ensemble de ce que peut être un widget. A partir de là il ne peut pas le sélectionner dans toutes les nuaunces et donc il ne peut pas le peindre correctement. Même en HTML c'est javascript qui s'occupe de ce boulot. Et c'est pas en rajoutant des sélecteurs attributs par paquets de 50 (elem:was_left_clicked_20_seconds_ago_but_lightly:was_originally_created_elsewhere_then_imported_here) qu'on va résoudre le problème. Bien au contraire.
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Kaane . En réponse au journal Conseils aux libristes, 2ème partie: résister à la tentation de la réécriture à partir de zéro. Évalué à 3. Dernière modification le 13 août 2012 à 16:44.
Je ne vois pas pourquoi tu dis non. ce n'est pas parce qu'un widget est plus qu'un élément d'un langage de markup que ça n'en est pas un.
Ok tu te sens d'écrire un truc du genre
Moi pas.
C'est pas le contenu, c'est la forme du contenu.
La forme du contenu, c'est le contenu. Sinon c'est de l'information brute. Le truc c'est que la mise en page du contenu dépend à la fois de l'appli elle-même et des traitements qu'elle fait que des CSS GTK3. Et comme le DOM est en vrac il n'y a pas possibilité de tracer la séparation. C'est comme si dans OpenOffice ton texte s'ouvrait différament en fonction de ton choix de thème. C'est idiot.
pourquoi CSS n'est il pas adapté
J'ai déjà répondu aussi. Un widget N'EST PAS un balisage. Je donne plus d'exemple pour que tu saisisses le problème, mais ca ne passe pas apparament.
CSS est un descripteur de mise en forme qui fonctionne par selection. Si on fait plus que de la mise en forme et/ou que l'on ne dispose pas de sélecteurs puissants (en l'occurence les deux dans GTK3) il faut autre chose. CSS n'est pas fait pour décrire l'ensemble de ce que peut être un widget. A partir de là il ne peut pas le sélectionner dans toutes les nuaunces et donc il ne peut pas le peindre correctement. Même en HTML c'est javascript qui s'occupe de ce boulot. Et c'est pas en rajoutant des sélecteurs attributs par paquets de 50 (elem:was_left_clicked_20_seconds_ago_but_lightly:was_originally_created_elsewhere_then_imported_here) qu'on va résoudre le problème. Bien au contraire.