Discuter:Feuilles de style en cascade

Un article de Wikipédia, l'encyclopédie libre.

	Feuilles de style en cascade fait partie du projet Informatique, qui a pour but d'enrichir le contenu de Wikipédia sur les sujets liés à l'informatique. Si vous voulez participer, vous pouvez modifier cet article ou visiter la page du projet où vous pourrez vous joindre au projet et consulter la liste des tâches et des objectifs. Le portail informatique pourrait aussi vous intéresser.
B	Cet article a été classé comme d'Avancement B selon le Tableau d'évaluation du projet. (Voir les statistiques)
Moyenne	Cet article a été classé comme d'Importance moyenne selon le Tableau d'évaluation du projet. (Contester?)

Wikipédia n'est pas uniquement un repositoire de liens externes...

---

ah, je n avais pas vu que c'était un résidu d'effacemenent de copyright...bonbonbon...quelqu un pour rendre a cette page un aspect decent ?

Si tu parles de la police courrier c'est corrigé.

---

Je pense qu'il faudrait traduire 'class' par 'classe' sauf dans le code bien sur ZeroJanvier 26 fév 2004 à 21:08 (CET)

---

Normalement, pour être bien rigoureux il faudrait mettre, non pas HTML, mais (X)HTML. Pour ceux qui ne savent pas, le XHTML est une version neuve (enfin elle a déja plusieurs années), complétement remanié du HTML, en effet la dernière version du HTML c'était vraiment le gros bazar ... .18 janvier 2008 à 14h51

---

Sommaire 1 Différentes feuilles de style 2 La fausse solution des CSS persos 3 Phonétique ? 4 Acid2 ? 5 Difficultés d'intégration 6 Ou puis-je trouver le CSS des Wiki en Francais? 7 Implémentations de CSS2.1 8 Historique CSS, work in progress 9 nettoyage bibliographique 10 Modifications de Marc Mongenet

[modifier] Différentes feuilles de style

Fraudait pas faire deux rubriques distinctes ?

Une "feuille de style" peut très bien n'avoir aucun rapport avec les CSS :
C'est la partie "présentation" d'un document : Document traitement de texte par exemple : La notion de "feuille de style" dans Word existe depuis bien avant le W3C !

Donc je propose :

• "Feuille de style" : Définition généraliste d'une feuille de style, centrée sur la distinction contenu et présentation d'un document (Traitement de texte, PAO ou page HTML).
• "Feuille de style en cascade" (discuter éventuellement sur cette traduction...) : cas particulier des CSS pour un document HTML.

--Serged 15 mar 2004 à 14:11 (CET)

[modifier] La fausse solution des CSS persos

Note : le texte ci-dessous a été déplacé depuis le Bistro de Wikipédia.

Souvent lorsque quelqu'un essaie de dire qu'un choix de présentation nuit à Wikipédia (bandeaux envahissants, caractères trop petits) le débat est détourné vers un "yaka utiliser monobook.css". Or si monobook.css est très bien pour les préférences personnelles, elle ne sert qu'à l'infime minorité des utilisateurs enregistrés. Bref, monobook.css ne peut pas faire partie de la solution d'un problème graphique général. Marc Mongenet 30 aoû 2004 à 19:05 (CEST)

Un site web n'a pas à imposer une charte grapjhique à l'utilisateur : voilà l'idéal vers lequel tout concepteur de site devrait tendre et ce vers quoi Wikipédia se dirige immanquablement. Chaque élément présent dans une page devrait être configurable selon le désir de l'utilisateur final. Lequel peut apprendre, s'il le veut bien, et pour peu qu'on lui donne quelques clés pour ouvrir les portes. 213.36.162.28 30 aoû 2004 à 19:13 (CEST)

C'est une solution temporaire, à défaut de mieux. Mais il faut avouer que l'on a tous des goûts, envies, besoin différents et le fait que l'on puisse déjà modifier son monobook.css permet de résoudre un problème ponctuel d'un individu. Il ne clôt pas le débat: rien n'empêche de continuer à parler du problème général qui est Qu'est-ce que l'on veut par défaut? et le débat est plus serein quand on sait que la valeur par défaut peut être configurée localement; plus facile à faire des concessions :-) Jyp 30 aoû 2004 à 19:31 (CEST)

Qu'on le veuille ou non, un site web impose une charte graphique par défaut à tout nouveau visiteur. Si dans la journée je visite 10 sites différents, je dois me taper 10 css pour que ça soit navigable? La personnalisation des style touche 1% des participants (et je suis gentil, il doit y avoir des vrais chiffres).

De plus, certains aspects relèvent plus du bug que de la personnalisation, par exemple les tableaux collés au texte (voir Pays-Bas). Il ne faut quand même pas pousser le bouchon trop loin ; à mes yeux, donner accès au CSS revient à donner accès au code source d'un logiciel : si l'utilisateur veut quelque chose de spécial, il peut l'ajouter, voire le faire partager aux autres, mais ce n'est en aucune manière un moyen de justifier des erreurs : "si tu trouves ça moche, t'as qu'à changer le css" n'est en aucun cas une réponse acceptable. Les bugs, il faut les corriger dans le CSS par défaut, et les fonctions souvent demandées (masquer des cadres, des tableaux, des images...), les implémenter dans le logiciel avec des boutons à cocher, par exemple. OK, on a le droit de répondre "On n'a pas le temps d'implémenter ça pour l'instant, le mieux, c'est de proposer un patch, ou, au pire, de modifier ton css pour le moment". C'est quand même un peu plus poli, non? Arnaudus 30 aoû 2004 à 19:41 (CEST)

de modifier ton css pour le moment; c'est ma réponse non? C'est pour cela que j'ai modifié 20 modèles, pour permettre déjà à ceux qui le veulent (par exemple pour l'impression) de pouvoir supprimer dans leur css, pour le moment. Ce travail est un préalable pour réaliser une interface simple.Jyp 30 aoû 2004 à 19:54 (CEST)

Personne ne dit : « taka ». Jyp et d'autres ont constaté certains manques, et ont cherché le moyen d'y remédier. Faudrait peut-être ne pas pousser... 213.36.162.28 30 aoû 2004 à 19:57 (CEST)

Accessoirement j'ai modifié la page Pays-Bas je ne sais pas si elle convient mieux ainsi? Jyp 30 aoû 2004 à 20:07 (CEST)

Un site est bien obligé de proposer une disposition graphique de ses éléments, soit une charte graphique. Mais HTML autorise une importante souplesse dans les propositions, par exemple le design élastique dont Wikipédia tire fortement parti. HTML autorise aussi l'utilisation des polices les plus lisibles pour chaque visiteur. Mais sur ce point capital pour une encyclopédie à contenu principalement textuel, Wikipédia s'est dramatiquement éloignée de l'idéal. Les polices de Wikipédia apparaissent comme des petites lettres de contrat d'assurance chez moi depuis le dernier changement de style. Marc Mongenet 30 aoû 2004 à 20:24 (CEST)

Ça pourrait être pire (cf. les liens externes verts par défaut sur en:)... Il y a quand même un progrès énorme si l'on regarde quelques mois en arrière : on ne pouvait rien configurer en dehors des quelques cases dans les Préférences. Maintenant avec plein de class et d'id un peu partout, enfin je ne t'apprends rien. 213.36.162.28 30 aoû 2004 à 20:36 (CEST)

Un progrès pour 1% (estimation grossière et optimiste) des visiteurs ne peut être que minime. Marc Mongenet 31 aoû 2004 à 09:30 (CEST)

Chez moi, la taille des caractères n'a pas varié de façon sensible. Une fois un problème découvert c'est le début de la réflexion... Voici donc quelques questions pour essayer de comprendre ce qui arrive chez toi:

• Sais-tu à quoi cela est dû chez toi?
• Est-ce spécifique à ton navigateur? (Si tu utilises un autre navigateur, y a-t-il le même problème?)
• Que faudrait-il changer pour corriger le problème? (Peut-être que tu as une idée)
• Quel navigateur utilises-tu et quelle taille de caractères as-tu par défaut?
• As-tu des particularités (par exemple la configuration d'un mal-voyant ou d'un aveugle est très différente de celle des autres personnes) ?
• Peux-tu nous fournir une copie d'écran pour que l'on se rende mieux compte de ton problème?
• Est-ce que d'autres wikipédiens ont le même problème?

Jyp 31 aoû 2004 à 10:06 (CEST)

[modifier] Phonétique ?

Mais à quoi sert la phonétique introduite dans l'article ? — Nucleos 10 mai 2005 à 23:29 (CEST)

Je ne sais pas qui en a pris l'initiative (j'ai souvent vu ça sur en: avec en plus un fichier audio), mais je trouve cela sympa d'indiquer comment un terme étranger est prononcé. Bon, ça fait un peu dictionnaire, c'est vrai, mais ça peut être utile, surtout qu'à terme, vu la taille du monde, une majorité d'articles portera un titre étranger, probablement transcrit (comme Tōkyō). Marc Mongenet 10 mai 2005 à 23:52 (CEST)

Il faut aussi le faire pour la version française du mot alors :p pour que nos lecteurs étrangers sachent le prononcer. Et puis mettre la prononciation audio serait aussi un plus. --ƒœΝύξ 11 mai 2005 à 12:12 (CEST)

Je me suis posé la question, mais je pense que c'est moins justifié. En particulier, si les étrangers veulent savoir comment prononcer Académie française, qu'ils le mettent dans l'article de leur langue, comme on le fait par exemple tous avec Karol Józef Wojtyła. Ça permet aussi à chaque Wikipedia d'utiliser le système phonétique qui lui convient. Marc Mongenet 11 mai 2005 à 14:20 (CEST)

[modifier] Acid2 ?

Quelqu'un connait-il le fonctionnement du test Acid2 cité dans les liens externes.

En regardant ce test, il me semble que Firefox ne passe pas l'épreuve ce qui me parait assez étrange. Ou alors je n'ai pas compris.

chaker

T'as pas vu avec Internet Explorer ! --Serged 17 août 2005 à 10:23 (CEST)

Il me semple qu'il n'y a qu'un seul (ou deux à la limite) navigateur(s) qui à passé le test avec succé (opéra je crois).--Spy-Seth 20 décembre 2005 à 18:20 (CET)

Il y a maintenant un article sur le test Acid2 (depuis le 31 octobre).

Personellement, la première fois que j'en ais entendu parler, j'ai été surpris des résultats obtenus :

Coté internet explorer 6, ça ne ressemble à rien (un grand rectangle rouge avec un oeil noir et l'autre jaune) mais ce n'est pas vraiment une surprise...

J'ai par contre été très surpris des résultats très moyens obtenus sur les navigateurs basés sur gecko (mozilla, nescape, firefox, epiphany, etc.) qui d'expérience semblent avoir une meilleur implémentation css que ceux qui réussissent le mieu ce test à savoir Safari, Konqueror et Opera. Je ne me rappel pas avoir rencontré de problème avec gecko, j'écris une feuille de style et j'obtiens exactement le résultat que j'imaginais. Je n'ais pas analysé le test en profondeur mais j'ai lu qu'il contenait des erreurs volontaires que les navigateurs sont sensés ignorer. C'est peut-être là la faiblesse de gecko.

Il semble que les dévelopeurs de Webkit (Safarie) et d'Opera aient attaché plus d'importance à ce que leurs navigateurs passent ce test avec succès que ceux de gecko.

C'est un peu dommage parcequ'ils ont par ailleur négligé la prise en charge de propriétés css de bases sur certains élément notaement dans les formulaires (le test acid2 n'en contient pas) . En effet dans Safarie et Konqueror les bouttons de formulaires et les champs de texte ne sont pas personalisables (les propriétés css background-image sont ignorés entre autre selon le type d'<input> ). Opera n'applique pas les propriétés "padding" sur les <input type="text">, on m'a parfois répondu que ça ne servait à rien, et bien si je veux faire un beau champs de texte avec les bouts arrondis et un peu de relief sur la bordure, je crée une image de fond, je supprime les bordures, et j'ajuste le "padding" pour que le texte n'apparaisse pas sur la bordure... si je ne peux pas ajuster cette propriété, ça ne me sert plus à rien de pouvoir changer l'image de fond.

"the CSS used in the test is invalid. This is deliberate, as a means of exposing the ability of user agents to handle invalid CSS properly."

Il faudrait arrêter de considérer ce test comme un "validateur" de navigateurs. Dans la mesure où le W3C ne donne aucune règle sur la façon de gérer les erreurs, les navigateurs sont libres de faire comme ils l'entendent, et pas comme les auteurs de Acid2 l'entendent... --Daxorp

A la différence de la gestion d'erreur en HTML, la gestion d'erreur CSS est normalisée. Le test Acid2 vérifie la conformité à CSS2.1 de différents traitements d'erreurs. Il teste par ailleurs de très nombreuses autres implémentations CSS et quelques implémentations non CSS (transparence PNG, élément object, data URLs). Merci, donc, de ne pas restaurer la version erronée de ce passage de l'article. Cordialement, --Lgd 26 juin 2007 à 06:55 (CEST)

"la gestion d'erreur CSS est normalisée." Où ça? Ce test Acid2 est une pure m###de, je vote pour supprimer carrément sa citation. De plus il ne sert à rien pour l'utilisateur lambda. Il sert à tester la réaction d'un navigateur aux erreurs pour aider les développeurs (de navigateurs).

De plus la description donné d'Acid2 actuellement est incorrecte. La bonne serait la traduction de la citation anglaise ci-dessus. — Le message qui précède, non signé^?, a été déposé par 86.197.214.69 (d · c).

Puis-je vous demander de lire ceci, s'il vous plaît, ainsi que la documentation du test Acid2 ? Puis nous pourrons en reparler en connaissance de cause ;) Le test Acid2, comme j'ai tenté de vous l'expliquer, comporte en effet un aspect "validation de la gestion d'erreurs de parsing CSS", mais il est très loin de s'y réduire.

Merci par ailleurs de signer vos message, avec --~~~~, voir de créer un compte. Cela facilite le suivi des discussions. Cordialement, --Lgd 28 juin 2007 à 11:07 (CEST)

Le problème de Wikipédia finalement c'est que c'est le + tétu qui l'emporte. ;-)

Déjà les url(data:...) qu'on trouve sur Acid2 ne sont pas dans les CSS2, il faudrait utiliser http://hixie.ch/tests/evil/acid/002-no-data/ Ensuite je suis plutôt d'accord pour l'enlever , pour la raison suivante: Firefox ne passe pas le test et pourtant il a raison sur plusieurs points de CSS sur lesquels Opera 8 a tord, et pourtant Opera 8 réussit le test (ou presque si je me rappelle bien). Donc le test ne représente pas la qualité d'un navigateur. CQFD. :-p (J'ai bien dit Opera 8, la version 9 a corrigé ces erreurs, notament la largeur width d'un élément en position absolue.)

Je suis le 1er gars, j'ai signé mon 1er msg, je savais pas, mais j'ai une IP fixe alors on peut me retrouver! D'ailleurs en rééditant là, je viens de voir que quelqu'un a déjà fait à peu près la même remarque que moi au sujet de Gecko contre Opera et Safari. --Daxorp

Le fait que tel ou tel navigateur ne passe pas ce test ne justifie en rien qu'il soit passé sous silence, s'il s'agit d'une étape importante dans les implémentations (et c'est le cas d'Acid2, tout cela avait été le cas d'Acid1 en son temps. l'article en cours de refonte sera d'ailleurs complété sur ce point).

Pour la petite histoire, les versions « nightly » du futur FF3.0 passent le test Acid2, ou en sont proches. La version FF2.0 (version "actuelle") était une « version de consolidation », dans laquelle aucune avancée d'implémentation, notamment CSS, n'évait été prévue : Firefox suit tout simplement son programme de développement.

Evitons d'autre part les comparaisons grossières et approximatives entre navigateurs: outre qu'elles ne servent qu'à alimenter d'inutiles trolls, elles sont dénuées de sens: c'est à un niveau de détail beaucoup plus fin que peuvent s'apprécier les choix différents qui sont effectués par des navigateurs différents. Certains de ces choix correspondent simplement à des "niches stratégiques" distinctes (l'avancée d'Opera dans les media queries, par exemple, répond à son rôle dans le Web mobile, que n'a pas Firefox, lequel ne les implémente donc pas). D'autres divergences correspondent à des points problématiques de CSS2.1 (les pseudos-contenus générés par :before et :after appliqués à des éléments remplacés, implémentés d'une certaine manière par Opera, dans un premier temps implémentés d'une autre manière par Gecko puis finalement « désimplémentés » au profit d'une proposition de suppression en CSS3 de cette fonctionnalité jugée impraticable). Dans certains cas, il s'agit également de niveau de priorité accordé à tel ou tel développement (le display:inline-block implémenté par tous les navigateurs, sauf FF2.0, car repoussé à FF3.0, etc.)

Enfin, au risque de me répéter dans le vide: Acid2 n'est en effet pas un test uniquement consacré à CSS. Et il ne « représente pas la qualité d'un navigateur » : juste la conformité de ses implémentation sur certains points spécifiques, notamment CSS, choisis pour leur importance dans le développement à venir des contenus Web... --Lgd 2 juillet 2007 à 06:18 (CEST)

Je note bien le "sur certains points spécifiques". Ce sont les auteurs qui les choisissent, mais on donne trop d'importance à ce test, donc à leurs choix...

Concernant Opera, il n'y avait pas de troll. Les quelques erreurs que j'avais noté était les mêmes qu'IE6. Je pense qu'Opera faisait ça volontairement pour une meilleure compatibilité avec les sites "optimisé" pour IE. Mais c'est de toutes façons corrigé.

Bref, pourquoi parler de ce test finalement qui ne sert pas au grand public comme ça a été dit + haut? --Daxorp

[modifier] Difficultés d'intégration

Cette section me semble à fois inutilement technique (sur un point de détail en partie hors-sujet, le doctype switching) et peu pertinente sur le fond. Le passage de CSS2.0 à CSS2.1 n'est pas lié en effet au phénomène des bugs d'implémentation, mais notamment:

• au constat qu'un errata ne suffisait pas aux nombreuses corrections nécessaires dans CSS2.0
• aux avancées très ambitieuses de CSS2.0, sans rapport avec les besoins et les intentions de l'industrie (les media print et aural, les descripteurs de police, les valeurs avancées de display, ou dans le sens inverse les valeurs avancées de white-space)
• à la mise à jour par les retours d'implémentation de mécanismes insuffisamment pris en compte par CSS2.0 (rôle de l'overflow, par exemple)

Bref, une reformulation plus poussée qu'un errata était nécessaire pour tirer parti des retours après implémentation.

D'autre part, si une mention doit être faite concernant les "bugs" et les divergences d'implémentation, il s'agirait plutôt, pour refléter la situation actuelle, de souligner :

• la convergence (récente) volontaire entre fabricants de navigateurs dans le détail des implémentations (alignement des comportements entre Opera, Safari, Gecko)
• les progrès en cours avec IE7, l'amélioration de l'implémentation CSS2.1 et une nouvelle étape du recul du système de formatage visuel propre à ce navigateur ("haslayout")

Le constat actuel étant que CSS2.1 en l'état des implémentations permet enfin d'aborder cet aspect de la conception Web de manière nettement plus rationnelle et industrialisée (même si CSS2.1 reste actuellement partiellement implémenté par chaque navigateur, et même si son utilisation repose toujours sur le détournement de propriétés pour réaliser malgré tout les effets recherchés, cas typique de l'utilisation actuelle des flottants).

Enfin (mais ce serait une autre section de l'article) , il serait également important de définir le rapport entre CSS et accessibilité, qui est loin d'avoir le caractère "magique" qu'on lui prête parfois. En particulier:

• CSS fait partie d'un ensemble cohérent de normes ayant notamment pour objectif de favoriser l'accessibilité (HTML4.x, XHTML1.x, CSS, WCAG, ATAG...) et n'a de sens que si chacune de ces normes est prise en compte
• Pour dire les choses simplement, ce n'est pas parce qu'un document est présenté uniquement à l'aide de CSS qu'il est accessible, loin de là.
• en fait, de nombreuses utilisations actuelles de CSS, peu au fait des problématiques d'accessibilité et du rôle dévolu aux feuilles de styles... produisent au moins autant d'inaccessibilité que les anciennes méthodes de présentation, et parfois même davantage ;) (utilisation erronée des contenus générés, incohérence entre contenu linéaire réel et contenu visuel apparent, etc)

Il y aurait beaucoup d'autres choses à faire pour enrichir et améliorer cet article, mais ce point me semble déjà assez facile à traiter. Vos avis (en reformulant tout cela plus simplement et moins rapidement) ? --Lgd 27 août 2006 à 16:11 (CEST)

[modifier] Ou puis-je trouver le CSS des Wiki en Francais?

Bonjour,

Dans Wiki, les CSS en français(fr) sont different de ceux en anglais (en). Spcécialement les coins aroundis des onglets ainsi que les onglets gris derrière les sections: Naviagion, Conctribuer, Recherche, Boite à outils.

J'aimerais bien avoir le meme look dans mon site wiki... Est-ce que quelqu'un peut me dire ou je peux trouver le main.css ou le monobook.css ustilisé dans les site fraçnais de wiki?

J'ai déjà trouvé celui pour anglais mais c'est celui de francais que je cherche.

Merci, Alain

En fait, les arrondis sont basé sur le "-moz", ce qui fait un peu de leur utilisation un manque de représentation des navigateurs qui n'utilisent pas le rendu Gecko : -moz-border-radius: 6px;

Voie par exemple http://fr.wikipedia.org/skins-1.5/monobook/main.css?32

[modifier] Implémentations de CSS2.1

Afin d'éviter si possible le retour récurrent de trolls sur le niveau de support de CSS2.1 dans tel ou tel navigateur, j'ai ajouté ce qui me semble encore le moindre mal, c'est à dire les chiffres obtenus par la seule étude détaillée et suivie existante (voir source dans l'aticle). --Lgd 20 mai 2007 à 08:42 (CEST)

[modifier] Historique CSS, work in progress

Les deux premières parties (origines, premiers développements) ont été enrichies, de manière à mettre en évidence autant que possible les enjeux majeurs autour de CSS, qui étaient en fait présents dès le départ. Naturellement, c'est à améliorer ;)

La troisième partie est à poursuivre (mais là, je dois m'arrêter pour aujourd'hui), avec la question de « l'implémentabilité » de CSS2.0, du statut de CSS2.1, de la modularité CSS3, etc. --Lgd 1 juillet 2007 à 09:11 (CEST)

Ça fait plsisir de voir cet article avancer ! Quelques questions et remarques :

• « L'un des objectifs de CSS est de bien séparer la structure (écrite en HTML ou similaire) et la présentation » L'objectif n'était-il pas de proposer une stylisation indépendante de la structure ? OK, ça veut dire un peu la même chose, mais de manière plus positive et plus ambitieuse que le mot séparer. :-) Et puis il y avait à l'origine de CSS l'objectif très ambitieux de pouvoir réaliser des feuilles de style indépendantes de la structure qu'on pourrait même imaginer être servies par des serveurs spécialisés dans les styles (et amhpdv c'est un des lamentables échecs de CSS).
• L'héritage et la spécificité sont fondamentaux en CSS, et font partie de la cascade [1]. Je pense qu'il ne faut pas hésiter à leur consacrer une grande place.
• Je suis un peu étonné par l'expression « flux des boîtes » : ça donne l'idée d'une simple séquence de boîtes, alors qu'elles sont avant tout imbriquées, avec une racine au sommet.
• Pour la présentation technique, il me semble que l'ordre le plus logique est
  1. Présenter la structure en arbre
  2. Indiquer que chaque nœud de l'arbre a un ensemble de propriétés qui ont chacune une valeur
  3. La valeur est obtenue en cascadant les styles :
     1. si une déclaration s'applique, l'appliquer, sinon chercher à hériter, sinon valeur par défaut
     2. !important
     3. origine
     4. spécificité
     5. ordre

En fait, la spécification CSS 1.0 m'inspire par sa brièveté. :-) Marc Mongenet 10 août 2007 à 09:49 (CEST)

Merci de tes remarques, toujours utiles (d'autant plus que je rédige « quik and dirty » en vue de passes ultérieures).

• « proposer une stylisation indépendante de la structure » adopté
• « l'objectif très ambitieux de pouvoir réaliser des feuilles de style indépendantes de la structure » : il y aurait une section supplémentaire à faire, après l'historique, sur les limites atteintes par CSS, telles que cet objectif de la séparation, ainsi que ceux d'accessibilité et de simplicité
• « L'héritage et la spécificité » : ma foi, je pensais éviter le plus possible les considérations ou les exemples techniques, mais on peut certainement trouver un juste milieu, en effet
• « flux des boîtes » : oui, il faut compléter en précisant... qu'elles sont également emboîtées ;) Mais le traitement linéaire du flux est crucial. Par exemple : positionnement relatif, flottants et positionnement absolu se différencient avant tout par le degré de rupture qu'ils introduisent dans le flux. Il faut trouver une formulation idoine...

--Lgd 10 août 2007 à 10:13 (CEST)

• Pour l'héritage et la spécificité, en fait je ne pense pas forcément faire beaucoup plus technique que maintenant. Je pense aussi qu'il faut éviter le howto et la spécification light. En y repensant, je pense qu'il faudrait articuler la partie technique de l'article sur deux axes : la syntaxe (sélecteurs, déclaration, propriété, valeur, déclaration en ligne) ; la cascade (étant donné une propriété d'un élément, comment détermine-t-on sa valeur ? origine, média, héritage, spécificité, défaut, etc.). Marc Mongenet 10 août 2007 à 14:12 (CEST)

Hum... je te passe la main, alors, au moins pour fournir une rédaction à poursuivre si tu veux/peux pas y consacrer du temps en profondeur. Je suis un peu trop plongé actuellement IRL dans la rédaction de formations techniques CSS en e-learning: du coup, j'avoue franchement avoir du mal à situer ce qui serait souhaitable ici, sorry. --Lgd 10 août 2007 à 14:23 (CEST)

[modifier] nettoyage bibliographique

Aucun des ouvrages de type "tutoriel CSS" n'apportant d'informations constitutives de la matière de l'article, j'ai ramenée la bibliographie aux ouvrages majeurs sur le sujet réel. Des avis ? --Lgd 12 août 2007 à 09:52 (CEST)

Est-ce que CSS 2, des feuilles de styles pour le Web, de Daniel Glazman, 1^er livre en français sur CSS (plutôt ancien du coup), devrait faire partie d'une bibliographie en français ? Je n'ai pas lu le livre et n'ai pas d'avis, mais je me disais qu'un article encyclopédique en français sur le sujet devait peut-être mentionner ce livre. Marc Mongenet 12 août 2007 à 13:31 (CEST)

C'est à voir. Il est en partie « historique », mais il n'a pas eu (dans le monde francophone) un écho comparable à celui du Zeldman, par exemple (pour le monde anglophone et au-delà). Dans tous les cas, il est/sera par ailleurs cité dans les notes. /me est neutre, sur ce coup-là. --Lgd 12 août 2007 à 17:31 (CEST)

[modifier] Modifications de Marc Mongenet

Dans l'intro, on trouvait « décrire la présentation d'un document ». Lequel ? :-) J'ai remplacé par « des », d'autant plus qu'une feuille de style sert en général à décrire la présentation de plusieurs documents. J'ai remplacé « est utilisé » par « sert » pour éviter de faire croire que CSS est le langage forcément utilisé pour la présentation (modif un peu trop subtile, je le concède). J'ai supprimé « structuré écrit », un document étant forcément écrit, et étant forcément structuré s'il est en HTML ou XML. J'ai voulu ajouté une information sur la notoriété de CSS. Marc Mongenet (d) 12 mars 2008 à 15:33 (CET)

Sur la séparation de « la structure d'un document de ses styles de présentation », je reste un peu dubitatif. En effet, il me semble qu'une feuille de style CSS non triviale (avec par exemple des sélecteurs de classe, d'id, d'éléments imbriqués) ne peut s'appliquer qu'à des documents ayant une certaine structure et pas une autre. CSS sert à définir les styles hors du document HTML, et à pouvoir appliquer la même feuille à tous les documents de même structure. Mais peut-être je comprends mal le sens du mot « structure » ? Marc Mongenet (d) 12 mars 2008 à 15:55 (CET)

Même si la feuille CSS est très précise, elle peut s'appliquer à n'importe quelle document (et si ca fait n'importe quoi, c'est que le CSS est mal fait :). Il y a vraiment une volonté de séparer structure (paragraphe, titre ...) et présentation (la représentation graphique donc): voir cette note sur w3c et b:Programmation CSS/Introduction. Romainhk (QTx10) 12 mars 2008 à 16:43 (CET)

Il existe des feuilles qui peuvent s'appliquer à n'importe quel document sans faire n'importe quoi ? Je veux dire des feuilles qui font des choses intéressantes, pas juste changer le fond, la police et le padding du body. Marc Mongenet (d) 12 mars 2008 à 16:59 (CET)

Si un css utilise des classes, et que le document html ne les implémente pas, le css est compatible (même si il ne modifie en rien pas l'affichage).

Pareil pour les sélecteurs (genre "ol > il > p"): si le document html ne tombe jamais dans ce cas, ça ne change rien graphiquement.

Tu pourrais préciser intéressantes? Romainhk (QTx10) 12 mars 2008 à 17:27 (CET)

Et bien par « intéressant », je pense justement à plus intéressant que « ça ne change rien graphiquement ». :-) Enfin, le mot qui me manque, c'est Lgd qui l'a trouvé ci-dessous. Marc Mongenet (d) 12 mars 2008 à 18:50 (CET)

La séparation ne réside pas dans le fait qu'une CSS peut avoir ou non un caractère générique (CSS n'a jamais vraiment eu cette ambition, d'ailleurs). Elle réside dans le fait que les données de présentation ne sont pas dans la structure (pas de balisage de présentation en particulier). --Lgd (d) 12 mars 2008 à 17:36 (CET)

Voilà, tu as trouvé le mot : « générique ». Le pire, c'est que c'est une modification que j'avais proposée moi-même il y a quelques mois qui me laisse dubitatif :-) :
« L'un des objectifs majeurs de CSS est de proposer une stylisation indépendante de la structure du document.»
En fait, une feuille de style est indépendante du document seulement dans le sens où l'on a une ressource Web pour la feuille CSS et une autre pour le document HTML, mais la stylisation est généralement dépendante de la structure du document HTML (sinon la stylisation serait générique). Marc Mongenet (d) 12 mars 2008 à 18:50 (CET)

Pour l'ambition de CSS, j'ai un très vieux souvenir d'une interview, de Håkon Wium Lie je crois, où était évoquée l'ambition de voir apparaître des serveurs de styles dans lesquels des sites Web totalement indépendants pourraient piocher le style qui leur plait. Mais ce n'est jamais arrivé à ma connaissance et CSS ne me semble pas assez générique pour permettre d'atteindre de résultats intéressants ainsi. Marc Mongenet (d) 12 mars 2008 à 18:50 (CET)

Bref, tout ça pour dire que je trouve simplement la formulation actuelle de l'article un peu ambiguë. Rien de bien grave. Marc Mongenet (d) 12 mars 2008 à 18:50 (CET)

J'ai essayé de lever l'ambiguïté que je voyais. J'ai aussi ajouter un refnec quant au fait que CSS simplifie les changements de structure. Il me semble que ce n'est qu'un PdV. Marc Mongenet (d) 12 mars 2008 à 22:48 (CET)