Discussion:Feuilles de style en cascade

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)

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)

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)

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 l'IP 86.197.214.69 (discuter)

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

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)

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

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)

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)

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)

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)

Ajout d'une partie pour l'intégration du CSS dans une page HTML

Je trouvais qu'il manquait cela, sans faire "cours" sur le CSS au moins ca permettra à chacun de pouvoir mettre du CSS dans sa page HTML (j'ai mis HTML mais si vous préférais dire XHTML, vous pouvez modifier). J'ai mis les 3 methodes en essayant de respecter les recommandations du W3C même si les feuilles internes et dans l'attribut "style" ne sont pas trop appréciées. N'hésitez pas à modifier car je l'ai fait sur le moment comme j'ai un trou de mémoire pour la balise de feuille externe. --Nairod.brain (d) 16 mars 2009 à 22:14 (CET)

Ce serait pertinent dans ce wikibook ou dans la wikiversity, le but de ces deux projets étant, contrairement à Wikipédia, de permettre en effet une application pratique immédiate (je t'invite d'ailleurs à les compléter). Ou encore très, très éventuellement dans l'article Élément HTML, mais pas ici: link, style (élément) et style (attribut), leurs syntaxes respectives, le fait que les styles puissent être internes, en ligne ou externes, mais aussi permanents, alternatifs ou préférés (car alors, pourquoi ne pas en parler également ?), tout cela relève du (X)HTML, non de CSS. Dans le même ordre d'idée, l'article n'aborde pas l'application des styles dans le cas de XML (<?xml-stylesheet>) ni ne donne d'exemple de code des media queries. Désolé. Tu avais d'ailleurs toi-même senti le problème, puisque tu parles du risque de « faire "cours" sur le CSS » : Wikipédia n'a pas de visée pratique --Lgd (d) 17 mars 2009 à 03:40 (CET)

Titre de l'article

Selon moi il faudrait changer le titre de l'article qui doit être "CSS" et non "feuille de style en cascade". Les règles sont posées ici http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Conventions_sur_les_titres - Le titre idéal est le titre le plus court qui définit précisément le sujet. - Si plusieurs titres sont possibles, le plus commun devrait être utilisé, par application du principe de moindre surprise. Le « titre le plus commun » est le titre le plus courant ou le mieux attesté dans le contexte francophone.

Paul Guignard (d) 7 juin 2011 à 10:31 (CEST)

Je rajoute ceci :
Pour les sigles, créer l’article sous le nom complet. Exception : si le nom complet est inconnu alors que le sigle est courant (par exemple « Common Business Oriented Language » pour COBOL, ou « VHSIC Hardware Description Language » pour VHDL)
(Il me semble que CSS est courant et "feuilles de style en cascade" complètement inutilisé, en tout cas j'ai jamais entendu personne le dire !

Paul Guignard (d) 7 juin 2011 à 10:35 (CEST)

CSS est une page d'homonymie : le terme peut correspondre à pas mal de choses... Donc "CSS" ne définit pas précisément le sujet des feuilles de style en cascade, à la différence de COBOL ou VHDL. Romainhk (QTx10) 7 juin 2011 à 10:38 (CEST)

Style utiilsateur

C'est un beau concept , mais combien de gens savent configurer leurs navigateurs pour définir la feuille de style par défaut ( l article n aborde pas la feuille de style "reset" ...?) ? De plus aucun utilisateur ne va s'amuser a redéfinir le style pour les balises html/xhtml et encore moins pour les valeurs des attributs id et class qui eux sont spécifiques aux choix du développeurs. Il est vrai que les CMS imposent des valeurs mais sont elles identiques entre les différents CMS python/php/asp ..? 194.5.134.180 (d) 3 septembre 2012 à 12:24 (CEST)

Implémentation

Le terme "Implémentation" n'est pas français. Il faut privilégier l'expression "mise en place".

Effectivement c'est un barbarisme. Implémenter n'a pas du tout le même sens en français.

http://www.academie-francaise.fr/implementer

Liens externes modifiés

Bonjour aux contributeurs,

Je viens de modifier 2 lien(s) externe(s) sur Feuilles de style en cascade. Prenez le temps de vérifier ma modification. Si vous avez des questions, ou que vous voulez que le bot ignore le lien ou la page complète, lisez cette FaQ pour de plus amples informations. J'ai fait les changements suivants :

• L'archive https://web.archive.org/web/20070911125220/http://www.blog-and-blues.org/articles/Float,_clear_et_contextes_de_formatage a été ajoutée à http://www.blog-and-blues.org/articles/Float%2C_clear_et_contextes_de_formatage
• L'archive https://web.archive.org/web/20141004215348/http://people.opera.com/howcome/2006/phd/ a été ajoutée à http://people.opera.com/howcome/2006/phd/

SVP, lisez la FaQ pour connaître les erreurs corrigées par le bot.

Cordialement.—InternetArchiveBot (Rapportez une erreur) 23 juillet 2018 à 16:08 (CEST)

Exemple incomplet sans image

La page donne un exemple avec le code HTML et le code CSS associé, mais pas d'images du rendu! Comme on est dans une encyclopédie, on pourrait s'attendre à pouvoir voir quel rendu ça donne, sans avoir à créer un fichier HTML pour tester. Et ceux qui ont ceci imprimé, comment font-ils?