5171 sujets

Le Bar du forum

“What's Wrong With CSS”

Bonsoir,

Je passe juste poster ce lien, désolé de ne pas faire plus de commentaires.

-> What's Wrong With CSS

En tous cas ça me parle, parce que j’utilise également des techniques particulières pour générer le CSS (pour contourner le fait qu’il n’existe pas de variables en CSS par exemple)

Par exemple ici, LESS extends CSS, j’aime beaucoup l’exemple “Nested rules”, une chose dont je pense au souvent au fond de moi même qu’elle manque cruellement à CSS.

N.B. En fait j’utilise autre chose que ça (je viens de le découvrir, je vais l’essayer), j’utilise un script SED que j’applique à des fichiers source pour générer les CSS.

EDIT -- Comme j’ai donné le lien vers LESS, je donne également le lien vers SASS pour être équitable. Malheureusement, les deux reposent sur Ruby (pfff... encore du bazar à installer, donc finalement je crois que je vais éviter et continuer avec mon truc léger).
Modifié par hibou57 (07 Aug 2010 - 17:39)
@les modos: oui, je sais, je répond au topic sans modifier le sujet initial, mais j’ai une raison.

Pour les gens qui aurait déjà lu le sujet, je tiens à revenir sur un point : j’ai dit que je n’allais pas essayer parce qu’il fallait encore installer un usine de 50M juste pour une application qui qui fait du traitement sur des fichiers texte ; mais par curiosité, j’ai quand-même tenté, et effectivement, LESS est vraiment très bien fait, et le superlatif est bien mérité. C’est parfaitement homogène vis à vis du CSS, ça en reprend parfaitement la syntaxe, à tel point que je me demande si un jour CSS ne va pas introduire les innovations apportés par LESS dans son standard. N’hésitez pas à l’essayer pour la seule raison de m’avoir vu hésiter, ce serait dommage.

Et puis note en marge : Ruby n’est peut-être pas un nième langage qui n’a rien à apporter, je viens de lire une introduction à son sujet, son créateur, Japonnais, Yukihiro Matsumoto, c’est inspiré de Smalltalk, Eiffel, Ada et Lisp (de bonnes références pour les paradigmes, que je cautionne). C’est plutôt bon signe. Alors je vais profiter de l’occasion pour découvrir.
Modifié par hibou57 (07 Aug 2010 - 21:51)
D'accord à 66% avec les arguments soulevés (2 sur 3).

Je cite les défauts notés:
Jeff Atwood a écrit :
* Vertical alignment is a giant, hacky PITA. (Tables work great for this though!)

Si les tables marchent bien pour ça, alors display:table-cell marchera bien pour ça aussi. CSS2.1, implémenté dans tous les navigateurs modernes. Si pas possible de l'utiliser là tout de suite, merci de critiquer IE7 et non pas CSS. Smiley smile

Cela dit, j'aimerais bien que CSS permette d'aller plus loin, avec une solution élégante directement destinée à la production de designs en grilles (flexibles, les grilles). Le Flexible Box Layout Module permet de faire des choses intéressantes aussi, et c'est implémenté au moins dans Gecko et Webkit, mais là encore c'est pas tout à fait destiné à la constructions de grilles.

Pour les grilles CSS, on ne sait toujours pas dans quelle direction ça part. On a deux working drafts: CSS Grid Positioning, mis à jour en 2007, et CSS Template Layout, mis à jour plus récemment et un peu plus abouti, mais pas encore au point. Je n'ai pas analysé le premier qui semble abandonné, mais le second ne me plait pas des masses, du moins pour ce qui est de la syntaxe. Réutiliser les propriétés CSS position et display ainsi est pour moi une bêtise, mieux vaut clarifier en créant des propriétés ad hoc (avec des noms comme layout-template et layout-position, par exemple). Le pseudo-élément ::slot() est une solution intéressante (même si je n'aime pas le nom).

Enfin bref, ce serait cool si le CSS Working Group analysait les deux propositions, demandait le feedback des implémentateurs et des utilisateurs potentiels, et se décidait sur une des solutions (une des deux ou un mix si pertinent) pour la finaliser.

Jeff Atwood a écrit :
* Lack of variables so we have to repeat colors all over the place.

Je suis d'accord, pour les couleurs, certaines dimensions, et les déclarations de fontes notamment.
À noter que CSS n'a pas besoin de variables mais de constantes, sauf à vouloir pouvoir modifier la valeur d'une variable CSS programmatiquement via une API JavaScript/DOM. Des variables pourraient être une fonctionnalité intéressante, tiens, mais utile à 0,1% des sites, alors que des constantes (beaucoup plus simple à implémenter, donc arrivée plus rapide dans les navigateurs...) seraient utiles à la majorité des sites.

En passant, je m'étonne que Jeff Atwood, un développeur «back», parle de variables alors que le besoin qu'il décrit correspond à des constantes.

Jeff Atwood a écrit :
* Lack of nesting so we have to repeat huge blocks of CSS all over the place.

Plutôt d'accord aussi. Mais quand je rencontre ce type de problème, ce n'est pas nécessairement la faute de CSS. Le problème le plus courant c'est d'avoir à copier-coller dix ou trente lignes de CSS (qui définissent un élément d'interface pour une page donnée) pour en faire un style presque identique ailleurs (pour un autre élément d'interface). Une solution serait de définir ce style en utilisant un nom de classe générique qui peut être utilisé à plusieurs endroits dans le site (ex: pas #news d'un côté et #documents de l'autre, mais .callout-box pour les deux). Le problème, c'est que le plus souvent le designer a introduit de petites différences sans penser à la factorisation et la maintenabilité de l'interface.

Dans ce genre de situation:
- Il faudrait souvent pouvoir éclaircir les choses avec le designer, et demander des modifications du design si pertinent.
- Une solution du type <div id="news" class="callout-box"> / <div id="documents" class="callout-box">, avec styles partagés d'un côté et styles spécifiques séparés... ben ça marche déjà pas mal.
- Une solution de factorisation du code CSS telle que proposée par LESS marche aussi, et évite d'avoir à placer une classe commune dans le code HTML, mais est-ce un gain si net que ça? Le seul cas de figure ou ça me semble intéressant, c'est si on n'a pas le contrôle du code HTML (par exemple pour un thème de CMS qui exploite un code HTML standard).
Florent V. a écrit :
Cela dit, j'aimerais bien que CSS permette d'aller plus loin, avec une solution élégante directement destinée à la production de designs en grilles

Au moins ça fait preuve de compréhension à l’égard des gens qui ont longtemps continuer à faire des présentations avec des tables.

Florent V. a écrit :
Réutiliser les propriétés CSS position et display ainsi est pour moi une bêtise

Ça me fait penser à ce que je trouve être une autre bêtise déjà faite : display et float traités séparéments (avis personnel, je ne m’étonnerais pas non-plus d’une riposte à cette phrase).

Florent V. a écrit :
À noter que CSS n'a pas besoin de variables mais de constantes

Oui, mauvais choix des mots. Mais en LESS ou dans le script SED que j’utilise, ce sont effectivement des constantes, évidement.

En plus des constantes, il y a la question des expressions, pour exprimer par exemple que le padding d’un élément est égale à sa largeur totale souhaitée (une constante définie) moins la taille de sa bordure. Ça évite de changer une valeur en oubliant d’en mettre une autre (dépendante) à jour.

Florent V. a écrit :
Jeff Atwood, un développeur «back»

C’est quoi un « développeur back » ?

Florent V. a écrit :
Plutôt d'accord aussi. Mais quand je rencontre ce type de problème, ce n'est pas nécessairement la faute de CSS. Le problème le plus courant c'est d'avoir à copier-coller dix ou trente lignes de CSS

C’est aussi une question de lisibilité et de maintenabilité.

Florent V. a écrit :
Une solution serait de définir ce style en utilisant un nom de classe générique qui peut être utilisé à plusieurs endroits dans le site

LESS permet ça, avec les Mixins (entre autre choses qu’il ajoute encore, comme les espaces de nom)

Ce modèle de mixin est pratique pour justement bien utiliser CSS et éviter certains de ces dérapages qui consistent à utiliser les classes comme des styles “in-line” (genre une classe .color-red, juste un exemple). On peut par exemple, si la logique de la présentation le veut, donner des propriétés communes aux H2 et aux TH, sans qu’il en soit nécessaire de donner une classes commune aux TH et aux H2. C’est possible actuellement, évidement (de même qu’on peut toujours écrire n’importe quel programme en langage machine), mais en dupliquant, et en prenant bien soin de ne pas oublier de mettre à jour la moindre instance de chacune des copies si jamais quelque chose doit changer. C’est lourd, et ça fait plutôt “low-level” (je préfère le terme anglais que l’équivalent français « bas-niveau » qui n’inspire pas la même connotation je trouve)

Florent V. a écrit :
mais est-ce un gain si net que ça? Le seul cas de figure ou ça me semble intéressant, c'est si on n'a pas le contrôle du code HTML

Pas seulement quand on a pas la main sur le HTML, mais aussi quand on ne souhaite pas le changer à chaque fois que l’on change la logique du partage des propriétés. Normalement, le HTML ne devrait pas être mêlé à ça. C’est faisable en CSS dans son état actuel ; la question est Comment, et de savoir si c’est d’une bonne manière.

Et ça améliore là aussi la maintenabilité et la compréhension, en respectant le principe « Un rôle = un emplacement / une source »
Modifié par hibou57 (08 Aug 2010 - 00:44)
hibou57 a écrit :
une autre bêtise déjà faite : display et float traités séparéments

Réponse:
div#machin {
  position: relative; right: -20px;
  display: table;
  width: 30%;
  float: right;
}

Il est vrai que float «annule» les propriétés d'un certain nombre de types de rendu (display:inline, display:block, à vérifier pour display:inline-block), mais pas de tous. De plus il faudrait avoir un display:float-left et un display:float-right, ce qui n'est pas d'une élégance folle.

Même remarque pour une hypothétique fusion de position et float (position:float-right).

Cela dit, les cas de figure où on a besoin de combiner ces propriétés sont assez rares. Si cette possibilité de combinaison n'existait pas, on en viendrait sans doute à utiliser deux éléments imbriqués pour obtenir le même rendu, ce qu'on fait dans d'autres cas de figure.

hibou57 a écrit :
En plus des constantes, il y a la question des expressions, pour exprimer par exemple que le padding d’un élément est égale à sa largeur totale souhaitée (une constante définie) moins la taille de sa bordure.

Voir calc() en CSS3.

hibou57 a écrit :
C’est quoi un « développeur back » ?

C'est pas un développeur «front». Smiley smile
What is front-end development?

hibou57 a écrit :
Le problème le plus courant c'est d'avoir à copier-coller dix ou trente lignes de CSS

C’est aussi une question de lisibilité et de maintenabilité.
Bien sûr, c'est ce que je sous-entendais. Faire un copier-coller n'est pas difficile en soi, ce sont les implications d'un code dupliqué qui sont problématiques (principe DRY).

La technique des mix-ins est intéressante. Mais je ne suis pas 100% persuadé de son intérêt pratique.

En passant, tu as déjà entendu Nicole Sullivan sur la modularisation du code CSS (pour des sites de grande taille)?
En vidéo:
http://www.dailymotion.com/video/xbe8py_css-peut-il-etre-oriente-objet-y-ni_tech
http://www.stubbornella.org/content/2009/03/23/object-oriented-css-video-on-ydn/
Florent V. a écrit :
Voir calc() en CSS3.

Ça c’est pour la théorie. Et pour la pratique, il faudra attendre le siècle prochain ?

Florent V. a écrit :
La technique des mix-ins est intéressante. Mais je ne suis pas 100% persuadé de son intérêt pratique.

Elle permet d’éviter de devoir ajouter à un élément, une classe qu’il n’a pas besoin d’avoir... sémantiquement (voir ci-après à ce sujet)

Florent V. a écrit :
En passant, tu as déjà entendu Nicole Sullivan sur la modularisation du code CSS (pour des sites de grande taille)?
En vidéo:
http://www.dailymotion.com/video/xbe8py_css-peut-il-etre-oriente-objet-y-ni_tech
http://www.stubbornella.org/content/2009/03/23/object-oriented-css-video-on-ydn/

Non, je ne connaissais pas, merci, c’était intéressant (je n’ai vu que le fr, j’ai du mal avec l’anglais oral).

Alors je viens de regarder, et des commentaires :

Si je peux le dire de la manière lourde : c’est tout sauf sémantique ce qu’elle présente. D’ailleurs tout à la fin, quelqu’un semblait vouloir poser une question au sujet des classes sémantiques, mais malheureusement, le temps était apparemment trop court et il n’y a pas eu de réponse à cette question.

Le Template CSS

Le cas du Template : j’ai essayé ça, au début, et j’ai abandonné. Le CSS se promène pas tout seul, il s’accroche sur quelque chose, le HTML. Et cette manière de penser Template CSS impose une structure au HTML. C’est à dire qu’il faut concevoir le HTML de sorte à ce qu’un CSS en particulier puisse venir s’y fixer.

À terme, et pourtant le site n’est pas si complexe, ça a abouti à une architecture HTML trop complexe, ... trop d’élément HTML qui n’avaient pas à être là, et qui n’étaient que pour la présentation. J’ai fini par tout nettoyer, et revenir à un CSS conçu pour le HTML, et non pas l’inverse (un HTML conçu pour le CSS).

C’est vrai qu’elle aborde justement cette question du conflit entre les deux, mais je ne suis pas d’accord avec sa conclusion. Elle dit : « c’est normal que ce soit la sémantique visuelle qui gagne, parce c’est ce que l’utilisateur voit ». Alors le mieux c’est peut-être de faire des sites tout en PDF (le PDF est justement fait pour tout axer sur la présentation). À la limite, c’est faire du CSS/HTML, en regrettant que ce soit cette plateforme qui ce soit imposé et en regrettant que ça n’ait pas été autre chose.

Des efforts sont faits pour améliorer la structure sémantique des documents : pour l’accessibilité (même si elle souvent trop imparfaite, c’est mieux que pire), pour les moteurs de recherche (enfin, s’ils sont capables d’en tirer parti), et aussi pour que les documents web puissent être des sources de données. C’est pour tout ça qu’un certain Saint Graal actuel s’appel Sémantique.

J’irai voir sur GitHub pour me faire une idée, mais je ne crois pas vraiment que ce que j’y verrai me fera changer d’avis.

Le H3, .h6

Ça aussi, je l’ai essayé, et récemment. Ça faisait partie du cas que je citai comme exemple précédemment, ou pour des raisons de « sémantique visuelle » on peut souhaiter par exemple qu’un TH ait le look’n feel d’un H2. J’avais une petite fraction de seconde pensé à donner une classe commune à H2 et TH, mais finalement non, pour des raisons similaire à celles évoquées juste au dessus : structure du document... et même quand il ne s’agit pas d’un document au sens propre (c’est pour les boites de dialogue de mon éditeur).

donner une classe .h6 à des H3... ce n’est pas que la classe s’appel .h6 qui me perturbe, c’est qu’il faille donner une classe à un élément, juste pour sélectionner la présentation à donner à cette élément.

Je vais me répéter, mais là encore, si on veut tout orienter sur la présentation et que ce soit elle qui domine entièrement en effaçant le reste au prétexte que l’utilisateur ne le voit pas, alors HTML/CSS n’est pas le choix à faire. Maintenant, s’il est choisi parce qu’il est imposé et qu’on veut malgré tout en faire autre chose, c’est une autre histoire.

Le #id1 #id2 #id3 #id4 #id5 ....

Ses remarques au sujet du bon usage des sélecteurs (j’ai bien aimé son histoire des petites guéguéres qui font s’allonger les sélecteurs), même si je m’étend moins à ce sujet (comprendre qu’il faut donner autant d’importance), était vraiment bien. Tout à fait d’accord que les sélecteurs sont un élément fondamentale de CSS et que c’est une erreur de ne pas les intégrer dans la logique de la conception.

Sa remarque sur la nécessité de définir des styles globaux aussi.

Ah, justement à ce propos, les idées mises en oeuvre dans LESS mettent justement l’accent sur les sélecteurs finalement. En même temps, c’est vrai qu’il peut aussi permettre de générer ces fameux sélecteurs à rallonge peut-être trop facilement.
Modifié par hibou57 (08 Aug 2010 - 03:40)
hibou57 a écrit :
Ça c’est pour la théorie. Et pour la pratique, il faudra attendre le siècle prochain ?

Pour la pratique il faut attendre quelques années, voire dix ans si le but est de supporter le vieux IE8 (d'ici quelques années) et pas de faire une interface d'application pour un moteur de rendu donné.

Dans la partique aussi, on peut se renseigner sur ce qui est déjà implémenté, et comprendre que dans 90% des cas où on exprime un besoin pour calc(), on pourrait en fait (et on aurait souvent intérêt) à utiliser une solution plus directe. Et 90%, je suis gentil, j'ai bien envie de dire 99.

Pistes à suivre:
- Comprendre le fonctionnement de display:block (spéciale dédicace à ceux qui remplissent leurs feuilles de styles de width:100%... you're doing it wrong).
- Propriété box-sizing.
- display:table-cell dans certains cas de figure.
- display:box dans d'autres.
- position:absolute avec top:X;bottom:Y ou left:X;right:Y, dans d'autres encore.

hibou57 a écrit :
Elle permet d’éviter de devoir ajouter à un élément, une classe qu’il n’a pas besoin d’avoir... sémantiquement
(...)
c’est tout sauf sémantique ce qu’elle présente

Le choix d'une classe n'est jamais «sémantique». Si tu veux que tes noms de classe aient un rapport avec le contenu plutôt que la mise en forme, c'est ton choix, mais ce n'est qu'une convention de nommage sans le moindre impact sur la sémantique de ta page web. Donc, pour le dire de manière un peu lourde, on s'en fiche pas mal et la notion de «classe sémantique» est une erreur. Smiley smile

Dans un projet donné, la convention de nommage utilisée pour les identifiants et les classes doit viser la productivité et la maintenabilité. Certainement pas la «sémantique».

En passant, on peut faire du PDF sémantique et accessible.

hibou57 a écrit :
donner une classe .h6 à des H3... ce n’est pas que la classe s’appel .h6 qui me perturbe, c’est qu’il faille donner une classe à un élément, juste pour sélectionner la présentation à donner à cette élément.

Dans certains cas c'est une approche très pertinente. Par exemple, pour un gros projet avec intervenants multiples sur le code HTML produit, un développeur front expert crée des gabarits HTML de référence et les feuilles de styles. Les styles CSS sont alors conçus pour être polyvalents, et pour permettre à divers intervenants d'appliquer les styles de référence souhaités à des contenus qu'ils créent, sans toucher au CSS. Les feuilles de styles sont accompagnées de documentations à l'intention des rédacteurs, des développeurs et d'intégrateurs exécutants, et ces docs détaillent les classes de référence qui peuvent être utilisées.

hibou57 a écrit :
Je vais me répéter, mais là encore, si on veut tout orienter sur la présentation et que ce soit elle qui domine entièrement en effaçant le reste au prétexte que l’utilisateur ne le voit pas, alors HTML/CSS n’est pas le choix à faire.

Je dirais plutôt que c'est toi qui te méprends sur la nature de (certaines parties de) HTML et CSS.
Les CSS c'est de la présentation, ça c'est plié.
Quant à HTML, il y a effectivement une sémantique HTML et elle est importante (accessibilité, référencement, dans une certaine mesure ça impacte aussi la lisibilité du code...). Mais les attributs id et class et leurs valeurs n'ont pas de portée sémantique. HTML4 dit explicitement que id et class servent de points d'accroche aux styles. D'autres usages sont listés, mais aucun n'a de rapport avec la sémantique HTML:
http://www.w3.org/TR/REC-html40/struct/global.html#adef-id

Pour les sélecteurs à rallonge, je m'efforce de rédiger chaque sélecteur pour qu'il soit aussi succinct que possible. Ça marche très bien pour les petits et moyens projets. Pour les gros projets, édicter des règles internes au projet pour standardiser la longueur des sélecteurs. Par exemple, on peut définir des conteneurs de premier niveau et des modules de deuxième niveau. Un style «générique» pour le contenu d'un conteneur de premier niveau aura un sélecteur CSS tel que:
#container_name h2 {...}
Un style «spécifique» pour le contenu d'un module aura un sélecteur CSS tel que:
#root #module_name h2 {...}
Avec un <body id="root"> ou <div id="root"> comme conteneur global, on résoud ainsi les problèmes éventuels de priorité des sélecteurs.
Florent V. a écrit :
styles de width:100%... you're doing it wrong

Oui, width:auto c’est bien aussi.

Florent V. a écrit :
Propriété box-sizing.
[...]
display:box dans d'autres.

CSS3... malhreusement quand ça parle CSS, je vais encore immédiatement à la référence CSS2 que j’ai sous la main. Même sur css3.info, je n’avais pas vu mention de ces box et box-sizing. Dès qu’il manque un document complet, même Working Draft (un brouillon), c’est bloquant. On peut entendre parler de certaines propriétés populaires, comme border-radius, mais les autres, c’est faciles de les manquer et de ne pas en être informés.

Je vais quand-même chercher encore ce soir, pour voir si c’est possible de compiler tous les modules.

Actuellement, w3.org/TR/css3-roadmap/ fait beaucoup de références à CSS2. Ça se comprend, parce que beaucoup seront reprises ; mais ça laisse des vides. Par exemple depuis “8 Box Model”, aucun moyen d’arriver à broder-radius.

Bref, c’est pas la fête en ce moment pour avoir le semblant d’un tout.

Florent V. a écrit :
Le choix d'une classe n'est jamais «sémantique». Si tu veux que tes noms de classe aient un rapport avec le contenu plutôt que la mise en forme, c'est ton choix, mais ce n'est qu'une convention de nommage sans le moindre impact sur la sémantique de ta page web.

Ça n’en a pas formellement, parce que ça n’est défini nul-part, mais c’est sûrement une pratique courante, parce que le besoin s’en fait sentir. Exemple: l’utilisation de classes qui reprennent les noms d’éléments HTML5.

Florent V. a écrit :
Donc, pour le dire de manière un peu lourde, on s'en fiche pas mal et la notion de «classe sémantique» est une erreur.

Pourquoi une erreur ? Parce que ça a de mauvaises conséquences ? Parce que c’est une illusion ? Autre(s) raison(s) ?

Florent V. a écrit :
Dans un projet donné, la convention de nommage utilisée pour les identifiants et les classes doit viser la productivité et la maintenabilité. Certainement pas la «sémantique».

Oui, mais il y a sémantique et sémantique, il n’y a pas pas que de celle du texte. “.menu” et “.popup” sont aussi sémantiques. Et cette convention, comme il faudrait apparemment l’appeler, sert la maintenabilité (c’est une banalité de le dire).

Maintenant si ce n’est qu’une divergence sur l’utilisation du mot Sémantique, c’est pas bien grave, et pas besoin de disputer à ce sujet, tant qu’on se comprend.

Florent V. a écrit :
Dans certains cas c'est une approche très pertinente. Par exemple, pour un gros projet avec intervenants multiples sur le code HTML produit, un développeur front expert crée des gabarits HTML de référence et les feuilles de styles. Les styles CSS sont alors conçus pour être polyvalents, et pour permettre à divers intervenants d'appliquer les styles de référence souhaités à des contenus qu'ils créent, sans toucher au CSS. Les feuilles de styles sont accompagnées de documentations à l'intention des rédacteurs, des développeurs et d'intégrateurs exécutants, et ces docs détaillent les classes de référence qui peuvent être utilisées.

J’ai bien lu et relu trois fois, mais pour que ça me parle vraiment, j’aimerais bien un exemple: sources HTML + CSS + surtout ces fameuses documentations comprises. Est-il possible d’en voir un exemple quelque part sans dévoiler des choses privées ou internes ? Un exemple qui peut être consulté publiquement ?

Je n’ai aucune idée de ce contexte, même si j’essaie de m’en faire une (d’idée) : je n’ai jamais travaillé pour une boite dans ce domaine (et puis même mon activité indépendante je l’ai arrêté pour cause de charges trop lourdes). Une occasion de voir à quoi ça ressemble, ça m’apprendrait quelque chose.

Florent V. a écrit :
Je dirais plutôt que c'est toi qui te méprends sur la nature de (certaines parties de) HTML et CSS. Les CSS c'est de la présentation, ça c'est plié.

Je n’ai jamais dit le contraire. Mais c’est un peu la roue arrière (le terme est fort, je sais, c’est pour ça que je dis « un peu » pour modérer). Avant lui, il y a le HTML, qui l’a d’ailleurs largement précédé.

Si on reprend la bonne analogie de Jeff Atwood (voir liens dans les précédents messages) avec le design Modèle Vue Contrôleur : le modèle, c’est le HTML (quoiqu’il peut être une vue intermédiaire, un modèle de second niveau), la vue, c’est le CSS et le contrôleur, c’est le navigateur (ou le programme JavaScript selon les points de vue, mais ça revient quasiment au même + la partie serveur même si elle se fait oublier). Je pense que c’est OK pour ça.

Bon... ce serait bien étonnant que la vue ait son mot à dire sur le modèle [*] Smiley eek ou même qu’elle influence le modèle Smiley eek . On cré une vue pour un modèle, et non pas un modèle pour une vue (ça n’aurait pas de sens)

[*] Sauf qu’on peut évidement par exemple déceler un défaut dans le modèle à travers la vue, c’est à dire que la vue peut jouer un rôle dans le vie et l’évolution du modèle. Mais ce n’est pas le centre de la question.

Je ne dis pas ça pour jouer au puriste déconnecté de la réalité, c’est que c’est justement la réalité.

Quand on commence à créer quelque chose, on commence par un modèle et une vue brute, une vue très proche du modèle ; pas de CSS ou un CSS plus que basique, des formulaires brutes au lieu de menus + JavaScript, etc. C’est ce qui arrive en premier et c’est ce qui reste au centre.

Reprise:
Florent V. a écrit :
Je dirais plutôt que c'est toi qui te méprends sur la nature de (certaines parties de) HTML et CSS.

HTML c’est un modèle ou un modèle de second niveau, et CSS, c’est une vue... qui peut d’ailleurs être variable. Et justement comment pourrait-elle être variablen si le centre, la où doit être la constance (plus ou moins), n’était pas le modèle HTML ?

Possible que j’ai mal compris ce que j’ai lu aussi. Si c’est le cas, désolé.

Florent V. a écrit :
Mais les attributs id et class et leurs valeurs n'ont pas de portée sémantique. HTML4 dit explicitement que id et class servent de points d'accroche aux styles. D'autres usages sont listés, mais aucun n'a de rapport avec la sémantique HTML:
http://www.w3.org/TR/REC-html40/struct/global.html#adef-id

Il n’y a pas de sémantique définie standard, mais il y a une sémantique locale à l’application.

Ce n’est pas comme H1, H2 etc, mais ils ont une sémantique quand-même. Il n’y a que le modèle qui permette de bien les choisir. Un modèle peut être mal conçu, alors peut le corriger, la vue peut faire mettre le doigt sur ces défauts de conception, mais ce n’est pas la vue qui va dire ce qu’est le modèle. Ou alors c’est que le coupable entre les deux est trop fort... et d’ailleurs, il devrait être à sens unique. Et ce n’est pas de la théorie, c’est de la pratique.

(en même temps, je me demande de plus en plus si j’ai vraiment bien compris le message auquel je répond... m’enfin, verra bien)


-- EDIT -- --------------------------------------------------------------------------

Hibou57 a écrit :
Actuellement, w3.org/TR/css3-roadmap/ fait beaucoup de références à CSS2. Ça se comprend, parce que beaucoup seront reprises ; mais ça laisse des vides. Par exemple depuis “8 Box Model”, aucun moyen d’arriver à broder-radius.


Je viens de voir, ici, c’est plus commode : Cascading Style Sheets Current Work. En fait border-radius n’est plus dans Box Model comme l’était border-xxx dans CSS2, mais dans Backgrounds and Borders Module.
Modifié par hibou57 (08 Aug 2010 - 21:57)
hibou57 a écrit :
Même sur css3.info, je n’avais pas vu mention de ces box et box-sizing.

Pour ce dernier: http://www.css3.info/preview/box-sizing/

Si on n'est pas un intégrateur web professionnel (et spécialisé dans ce domaine), on n'aura bien sûr pas le temps de suivre de très près les évolutions de CSS3, HTML5, etc. Ce n'est pas un tort de ne pas connaitre toutes les techniques possibles et émergentes.

Je réagis aux propos selon lesquels CSS serait déficient car il manquerait telle ou telle chose essentielle, ou parce que telle ou telle chose serait trop difficile. Le plus souvent:
- La chose essentielle qui manque est dans CSS 2.1, implémentée dans tous les navigateurs dont IE8... ou bien dans CSS3, implémentée dans N navigateur(s).
- La difficulté rencontrée est due soit à des bugs IE 6-7 (carences diverses, HasLayout...), soit à une incompréhension de certains concepts CSS.

Ce n'est pas le cas de la totalité des critiques formulées, mais ça en représente une bonne partie. Ainsi, sur les 3 critiques de Jeff Atwood: le problème du manque de grille verticale, tel que formulé, est un contresens; la nécessité des mix-ins est plus convaincante, mais je reste réservé sur l'intérêt de la solution; et enfin l'utilité des constantes CSS me semble très claire (et je suis en désaccord franc avec Bert Bos du W3C à ce sujet).
Sur la sémantique: il y a une sémantique des éléments et attributs HTML. C'est à dire que la spécification HTML décrit le «sens» de chaque élément ou attribut, et recommande d'utiliser l'élément ou attribut le plus adapté à un contenu donné. Certains éléments ou attributs sont par ailleurs sémantiquement neutres: DIV, SPAN, id, class, et sans doute quelques attributs que j'oublie.

Respecter la sémantique HTML est une bonne pratique qui sert plusieurs objectifs:
- Accessibilité des contenus.
- Optimisation pour le référencement (avec quelques bémols).
- Facilitation de la maintenance du code (avantage pas systématique).

Voilà pour la sémantique HTML. Ensuite, dans un registre très différent, il y a les problématiques et les technologies du Web Sémantique.

Les «classes sémantiques» n'ont rien à voir avec la sémantique HTML et le Web Sémantique. Elles n'ont aucun impact sur l'accessibilité des contenus et n'apportent pas d'information perceptible par l'utilisateur (humain ou robot).
(Le premier qui complique tout en parlant des microformats, je le bannis. Smiley smile )

Utiliser l'adjectif «sémantique» pour une classe est une double erreur:

1. On entretient une confusion entre une vague recommandation ou convention de nommage («pour les noms des classes, choisissez quelque chose en rapport avec le contenu décrit») d'une part, et deux concepts très clairement définis (la sémantique HTML + le Web Sémantique) d'autre part. Mieux vaudrait éviter ce type de confusion en choisissant un nom différent pour la convention de nommage des classes en question.

2. Comme respecter la sémantique HTML est une bonne pratique, on suggère avec «classes sémantiques» qu'utiliser cette convention de nommage est une bonne pratique d'intégration web. En réalité, c'est loin d'être évident.

Les concepts de sémantique HTML et du Web Sémantique n'ont rien à voir avec le choix d'une convention de nommage pour des classes ou identifiants. Ces concepts ne peuvent pas être utilisés pour justifier ou soutenir cette convention de nommage.

hibou57 a écrit :
cette convention, comme il faudrait apparemment l’appeler, sert la maintenabilité (c’est une banalité de le dire).

D'expérience, ça peut aussi la desservir. Par exemple quand tu dois refactoriser ton code CSS parce que des contenus différents sont ajoutés au site, et qu'ils doivent utiliser des styles existant. J'ai déjà vu des classes "module-news" appliquées à un contenu qui n'avait strictement rien à voir avec des actualités. Si à la base on avait choisi un nom de classe plus neutre vis à vis du contenu, par exemple "module-type1", on aurait pu réutiliser cette classe sans créer de contresens... et de problèmes potentiels de maintenance (je modifie les styles de "module-news" pour modifier l'apparence du bloc de news... et paf, ça s'applique à cinq autres contenus qui n'ont rien à voir... je me suis laissé berner par un nom de classe Smiley cligne ).

Pour ma part j'ai tendance à utiliser les id pour décrire le contenu, et les classes pour décrire la mise en forme (sans utiliser class="arial-12px-green", hein, faut pas caricaturer). C'est une convention parmi d'autres et elle peut être modifiée sur un projet donné. Les classes et identifiants qui décrivent le contenu sont intéressants pour les petits sites qui évoluent peu, mais très casse-gueule pour les sites moyens et plus gros.

hibou57 a écrit :
j’aimerais bien un exemple: sources HTML + CSS + surtout ces fameuses documentations comprises. Est-il possible d’en voir un exemple quelque part sans dévoiler des choses privées ou internes ? Un exemple qui peut être consulté publiquement ?

Je n'ai pas de projet de ce type en stock. J'ai bossé il y a deux ans sur 2-3 projets qui auraient nécessité cette approche; si je bossais aujourd'hui sur une projet semblable (plusieurs milliers de lignes de CSS), je proposerais ce type de fonctionnement.

hibou57 a écrit :
Si on reprend la bonne analogie de Jeff Atwood

Je ne vais pas te suivre sur ce terrain. L'analogie, c'est la mort de la pensée. Smiley smile
Franchement, essayer de calquer le modèle MVC sur HTML et CSS (et ce qu'on voudra), ça ne sert qu'à une chose: aboutir à des conclusions sans fondement.
Si on veut, on peut aussi comparer la couche des technologies web à une bicyclette, un braquage de banque, le système digestif humain, une bibliothèque publique, un marathon ou une ratatouille (au pif, disons que HTML = les roues, le coffre fort, l'estomac, les livres, le parcours de la course et les courgettes).

Appliquer MVC à HTML et CSS, ça sent le développeur back qui se raccroche à ce qu'il connait au lieu de chercher à comprendre les spécificités d'un domaine qu'il ne maitrise pas. Intérêt très faible.
Florent V. a écrit :
Je ne vais pas te suivre sur ce terrain. L'analogie, c'est la mort de la pensée. Smiley smile

Ça dépend, mais c’est pas la question (voir les sciences par exemple qui ne se prive pas d’essayer d’unifier Smiley cligne )

Florent V. a écrit :
Franchement, essayer de calquer le modèle MVC sur HTML et CSS (et ce qu'on voudra), ça ne sert qu'à une chose: aboutir à des conclusions sans fondement.
Si on veut, on peut aussi comparer la couche des technologies web à une bicyclette, un braquage de banque, le système digestif humain, une bibliothèque publique, un marathon ou une ratatouille (au pif, disons que HTML = les roues, le coffre fort, l'estomac, les livres, le parcours de la course et les courgettes).

C’était plutôt une manière de parler d’un fonctionnement, pas pour tout confondre.

D’ailleurs j’avais bien nuancé en indiquant quelques différences qui font que le HTML ne correspond pas toujours à un modèle, et il ne l’est pas exactement le plus souvent (mais peut l’être quand-même).

Le HTML peut doucement glisser d’un l’un à l’autre pôle, selon le domaine : pour une page qui présente des données ou un document, c’est un modèle intermédiaire (filtré ou transformé), tandis que pour une application web, le HTML, c’est plutôt une vue, et la vue a alors deux composantes (d’ailleurs j’ai une question technique à ce sujet, qu’il faut que je pose plus tard). En pratique, il est à peu-prêt tout ce qu’on a sous la main, la principale matière dont on dispose pour faire quelque chose dans un navigateur, alors pas étonnant qu’on le retrouve sur le tous les fronts.

Ce schéma existe toujours, même si on ne peut pas toujours calquer le modèle ou la vue sur le HTML, il y a toujours un modèle, une vue, et un contrôleur/médiateur (même s’il est discret ou que l’on y pense pas).

C’est abstrait, mais le voir peut aider à ne pas tout rendre inextricable, ou au moins aider à expliquer comment la chose fonctionne. Ce schéma à l’avantage d’être clair sans être démagogue, parce qu’il est aussi pratique. C’est presqu’aussi universel que l’idée de cause et conséquence (sans vouloir m’égarer trop loin).

Pas plus d’instance à essayer de coller HTML ici ou là dans ce schéma. Et le CSS, ben on le laisse à sa place qui ne fait aucun doute.

Sinon, merci pour la différence entre les petits sites et les sites plus conséquents concernant les classes CSS. C’est plus clair après ce petit témoignage.
Modifié par hibou57 (09 Aug 2010 - 00:40)
hibou57 a écrit :
Un autre dans la même catégorie.

Là, ils ont fait une compilation de tous les mots magiques : xcss.antpaw.org

Pas encore testé.

J'aime vraiment pas. Smiley smile

Enfin, disons que c'est peut-être un outil intéressant. Mais je pense que tout outil qui souhaite rajouter des fonctionnalités à CSS via une syntaxe non standard (ensuite compilée en CSS standard) devrait prendre une des deux orientations suivantes:
1. Proposer une syntaxe clairement différente de la syntaxe CSS. (Sass le fait dans une certaine mesure.)
2. Imaginer des règles grammaticales compatibles avec les règles de CSS (et pas seulement une petite partie...), tout en évitant les confusions.

Quand je vois ça:
vars {
  // définition de constantes, mais attention, "vars" est un
  // mot-clé syntaxique et pas un sélecteur!
}
.selector {
  self {
    // "self" n'est pas un élément HTML mais une référence au sélecteur
    // un niveau au dessus.
  }
}
// Ah tiens, une syntaxe de bloc de déclarations CSS pour quelque
// chose qui n'a strictement rien à voir.
.specialClass extends .basicClass {}

... bah j'ai un peu peur. Smiley ohwell

Quant aux opérations, ils auraient pu implémenter calc() plutôt que réinventer la roue.

Je préfère les choix syntaxiques faits pour Sass et LESS, même si pour chacun d'eux il y en a la moitié que je n'aime pas. Smiley smile
Florent V. a écrit :
J'aime vraiment pas. Smiley smile

Moi non-plus

hibou57 a écrit :
Là, ils ont fait une compilation de tous les mots magiques

C’était plutôt ironique, ça me semblait trop racoleur pour être honnête (même si c’est pas un bon fondement). Mais c’est toujours bien de connaitre.

Pour le reste des commentaires : oui, ça s’éloigne de l’esprit LESS, qui essaie de respecter CSS.
Modifié par hibou57 (09 Aug 2010 - 17:17)
Sujet clos
Aller à