LaurentDenis

Moi qui suis tout sauf un intégriste des standards, je vais jouer justement la position radicale : un navigateur texte ne sert aucune présentation hormis celle par défaut de son implémentation. Pourquoi en serait-il autrement des navigateurs ne disposant pas de support CSS ? (Ne me dites pas que les navigateurs de génération 4.x supportent un peu CSS : ils supportaient tout autre-chose, dans une visée exclusivement propriétaire, datant de l'époque). Donc un contenu brut pour NS4. C'est très agréable à lire, au fait, quand on ne surfe pas pour le fun. Et on peut raisonnablement estimer que les utilisateurs actuels de NS4.x ne surfent pas pour le fun : ils n'ont pas le choix du navigateur pour le boulot. Quand on travaille, l'information compte, pas les fioritures. On peut même avancer que le salarié sera moins distrait par la jolie présentation et sera ainsi plus productif. J'avoue : il m'arrive très fréquemment de neutraliser les CSS (un clic dans Opera) quand je cherche une info.

Hum... à partir du Google PageRank Report, il me semble tout à fait possible d'écrire un favelet permettant un accès immédiat à ce service depuis Mozilla, FireMachin ou Opera. Le PageRank ne me fascine pas outre-mesure, mais je lance l'idée au cas où un bon développeur DOM passerait par là

Personellement, je n'utilise pas d'éditeur wysiwyg ni d'éditeurs spécifiques pour les CSS. Je gère l'ensemble avec HTML-Kit (et les navigateurs pour le rendu). http://www.chami.com/html-kit/ C'est un peu usine à gaz, mais facilement personnalisable (outil de génération de plugin...). De plus, il intègre un correcteur de code HTML (Tidy)...

En CSS, ne tiens pas compte de Netscape 4.7 (ni d'IE4) : son support CSS est trop partiel et défectueux pour tirer profit des feuilles de styles. Sur le fond du débat, voir le classique article de Zeldman http://pompage.net/pompe/paitre/ L'usage est de servir à Netscape 4.7 une page brute, au contenu parfaitement lisible, mais sans présentation CSS. Pour cela, il suffit d'utiliser la bonne syntaxe pour lier la feuille de style à la page, par exemple : <style type="text/css" media="screen" >@import url(...);</style> la règle _AT_import est inconnue de Netscape 4.7. La feuille de style sera en revanche correctement reconnue par les navigateurs plus récents et ayant un bon support de CSS2.

Ma "déclaration de principe" était un peu rapide et du coup, très imprécise : il ne s'agit pas d'ignorer les règles typo, mais de faire un tri selon le degré d'information véhiculé par la règle et le coût de son application hors impression papier de la page: - les caractères spécifiques comme les tirets cadratins et demi-cadratins, le point de suspension ajoutent du sens. Ils se justifient quelque-soit le média. Il en est de même des règles appliquées aux guillements nationaux dans les citations mêlant plusieurs langues. - D'autres règles n'ajoutent rien, mais sont naturellement et aisément applicables dans le contenu textuel : l'espace après les signes de ponctuation simple. - d'autres encore n'ajoutent rien au sens, mais ont un coût non négligeable car elles nécessitent une manipulation supplémentaire du contenu : l'espace insécable avant les signes de ponctuation doubles. - d'autres enfin portent une information, mais entrent en conflit avec des usages ou des mécanismes propres au Web : le soulignement des titres d'ouvrage ou certaines mises en italique. J'aimerais bien défendre le point-virgule moi aussi (et d'ailleurs, je respecte cette règle autant que possible), mais je ne suis pas sûr qu'il faille en faire un principe intangible.

Bon, une petite dernière avant de me remiser avec mes poules : Puisqu'on parle de caractères spéciaux, je vois bien la sémantique du tiret cadratin (anonce une réplique de dialogue) codé &#8212;. Je vois celle du tiret demi-cadratin (délimite une incise, &#8211;). Et même celle du vrai point de suspension (&#8230;), pas comme celui-là... Il y a là un ajout d'une sémantique explicite. Mais où est celle du tiret sécable ci-dessus ?

&shy; (&#173;) est ton ami à cette fin (pseudo-tiret sécable définissant où la césure doit être faite dans le mot, mais le navigateur ne doit pas rendre le tiret en l'absence de césure). Mais il montre bien les limites de la typographie classique transposée sur le Web : c'est à peu près inutilisable quotidiennement, en dehors de quelques cas spécifiques où l'on prendra la peine de s'en préoccuper. La typographie historique a été définie pour un media donné: l'imprimé. AMHA, le Web ne devrait s'en préoccuper que dans ses prolongements papiers (CSS print par exemple). Pour le reste, une autre "webographie", plus souple sans doute, est à inventer. Elle s'invente d'ailleurs de facto par la force des choses, hors normes.

Allez, pour une fois que je joue le jeu de "mon navigateur à moi que j'aime" : Opera 7.23 ? Opera 7.50, Denis... Opera 7.50 Enrichi de quelques menus/favelets de développement maison et de quelques CSS utilisateurs qui révèlent le code sous le code... C'est un outil merveilleux Mais bon, FireFox n'est pas trop mal, dans sa catégorie, faut reconnaître

L'outil est jeune : le Web a moins de quinze ans. C'est équivalent à zéro à l'échelle humaine. Et sa première crise d'adolescence, celle du développement sauvage hors-normes, de la guerre des navigateurs, etc... se termine à peine. Les outils dont nous parlons (XHTML, CSS) sont immatures, manquent de retour d'expérience, et sont encore en pleine élaboration (comparez CSS2 et ce que sera peut-être CSS3). Bref, nous parlons d'outils efficaces, concrets, rentables, ceux d'aujourd'hui déja, et plus encore de demain... mais dont il faut assumer l'aspect "pionnier". Nous sommes loin de pouvoir regarder en arrière et de pouvoir prétendre avoir une vue synthétique du sujet. C'était mon quart d'heure philosophique ;-)

Re Arf ! Et tout l'intérêt de ce genre d'apparent coupage de chevaux en quatre est de mettre en lumière les points qu'on ne lit pas assez dans les spécifications. En effet: - il est en fait impossible d'éliminer le facteur "calcul de spécificité", ni de mon premier exemple, ni de celui que tu viens de donner ! Calculez la spécificité des sélecteurs pour me dire si je me trompe... - il aurait fallu commencer par lire plus attentivement : http://www.yoyodesign.org/doc/w3c/css2/sel...simple-selector Et surtout relire ce à quoi renvoyait "sélecteur simple" : http://www.yoyodesign.org/doc/w3c/css2/sel...simple-selector Nous ne sommes pas dans un cas de figure "sélecteur simple", tout simplement.

Il semblerait donc que le bug soit plutôt du côté de Mozilla ? Le tiret par défaut devrait être sécable ? C'est ce qui me semble, mais ma typographie classique n'est pas très sûre. J'ai jeté un oeil rapide sur http://bugzilla.mozilla.org/ mais je n'y ai trouvé qu'un bug se rapportant au tiret de césure &shy;. Il faudrait creuser. A noter qu'Opera (7.5 beta et versions antérieurs) a le même comportement qu'IE. Enfin, je ne vois aucun contournement CSS propre. Désolé ne pouvoir être plus productif

L'exemple que tu donnes est faussé car tu y fais intervenir une donnée différente: la spécificité des sélecteurs. le sélecteur div * span { background-color: green; } étant plus spécifique que le sélecteur span { background-color: red; } il l'emporte évidemment. [edit] Pourquoi est-il plus spécifique ? Se rapporter à : http://www.yoyodesign.org/doc/w3c/css2/cas...tml#specificity Selon CSS2, la spécificité calculée des deux sélecteurs sont grossièrement : - 2 pour div * span { background-color: green; } qui a deux éléments HTML - 1 pour span { background-color: red; } qui n'en a qu'un. En effet, 4e point de calcul de la liste selon la spécification : [/edit] Ce qui est intéressant, d'ailleurs. C'est un usage du sélecteur universel auquel on ne pense pas souvent : renforcer la spécificité d'un sélecteur de descendant...

Techniquement : <b> est un élément présentatif qui ne définit que le rendu visuel (mise en gras) et n'apporte aucune information supplémentaire, aucun ajout de sens sur le contenu. De ce point de vue, un texte en rouge et un texte balisé avec <b> sont strictement équivalent. <strong> est un élément structurel qui donne une information sémantique supplémentaire sur le contenu : l'emphase forte. Une façon de dire aux machines qui vont traiter ce contenu : "Attention, ça, ça doit être mis en valeur, il y a une accentuation..." Par exemple : - un lecteur d'écran devrait exploiter <strong> pour modifier le ton, le débit, le volume... de la voix. Il doit ignorer <b>. - un outil de traduction ou de synthèse automatique devrait tenir compte de <strong> pour, si nécessaire et si possible, transcrire cette emphase au niveau grammatical. Il doit ignorer <b>. - etc. [edit] J'oubliais : un très bon texte de Matthew Thomas sur le bon usage de <strong> et de <b>. Il est en anglais, mais l'essentiel est présenté sous forme de bref tableaux très lisibles. http://mpt.net.nz/archive/2004/05/02/b-and-i

Les spécifications ne sont pas des documents si compliquées que ça. En fait, leurs rédacteurs les ont voulu les plus simples possible

Les spécifications sont assez claires sur le sujet, et laisse une grande liberté d'utilisation des id et des class. Ici, en HTML4.01 : http://www.la-grange.net/w3c/html4.01/stru...al.html#h-7.5.2 Outre l'attribution d'un id aux section <div> principales d'une page (menus, contenu, pied, tête...), on a intérêt à prévoir un id pour toute information qui forme un tout ou une unité logique, et qui est susceptible d'être l'objet d'un traitement quelconque (CSS, XSLT, ancre, formulaire...). Par exemple, pour: - chaque news d'une série - chaque post dans un weblog - chaque titre et sous-titre d'un texte long (hyperliens permettant de viser exactement la partie concernée, voir par exemple les id de titre dans la source de la spécification citée ci-dessus)

Si, les deux syntaxes sont strictement équivalentes. Pour le vérifier, exécutez le code suivant : <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> <meta http-equiv="Content-style-type" content="text/css" /> <title>Test</title> <style> body { color: green; } .test1 * span { color: red; } .test2 span { color: blue; } </style> </head> <body> <div class="test1"> <p> Ceci est un texte en vert <span>avec un span rouge</span> </p> </div> <div class="test2"> <p> Ceci est un texte en vert <span>avec un span bleu</span> </p> </div> </body> </html> Attention à ne pas confondre deux syntaxes de sélecteurs CSS, celle des "descendants" et celle des "enfants". Voir http://www.yoyodesign.org/doc/w3c/css2/conform.html#doctree - les sélecteurs descendant (syntaxe div p span) - les sélecteurs d'enfant (syntaxe div>p>span) Un exemple : <div> <p> <span>blabla</span> </p> </div> Le <span> est un descendant du <p>, mais aussi du <div>. Le <span> est un enfant du <p>, mais pas du <div>. On peut atteindre le <span> avec: - div p span - div * span - div span Ou avec : - div>p>span -div>*>span Mais pas avec : - div>span

D'après http://www.zengrafom.org/site/ind2.htm, ton site a clairement 3 séries de pages : - la page d'accueil - les pages enfants - les pages parents La structure de la page d'accueil devrait être du type : - Titre du site et texte/graphisme de présentation : <h1>ASBL jour après jour</h1> <h2>Association des Parents confrontés au Cancer de leur Enfant</h2> <p>bla bla bla</p> <p><img src="..." ></p> Il y a un titre principal (<h1>), un sous-titre (<h2>), un ou plusieurs paragraphes de texte (<p>) et une ou plusieurs images (<img>) qui font partie du contenu si elles donnent une information. Sinon, on ne s'en occupe pas maintenant et elles seront ajoutées par la CSS. Je te recommande de prévoir en page d'accueil un texte bref, mais assez explicite qui indique dès l'entrée dans le site la nature, le propos... de celui-ci. Le titre et le sous-titre ne donnent pas suffisamment d'informations à eux seuls. - Liens de navigation du site vers les deux sections Enfants / Parents : <ul> <li><a href="...">Le coin des enfants</a></li> <li><a href="...">Le coin des parents</a></li> </ul> C'est une liste (<ul>), puisqu'on énumère des liens. Les pages parents et enfants auront une structure quasiment identique : -section titre de page <h1>ASBL jour après jour</h1> <h2>Le coin des Parents</h2> -section menu enfant, une liste de liens. Par exemple : <ul> <li><a href="...">Coloriages</a></li> <li><a href="...">Jeux</a></li> </ul> -section menu parent, une autre liste de liens : <ul> <li><a href="...">bla bla bla</a></li> <li><a href="...">bla bla bla</a></li> </ul> -section contenu propre à chaque page. Tu peux prévoir certains éléments permanents, et des éléments-types qui reviendront régulièrement dans ce contenu. Une sorte de page-test, comme : <h3>Le titre spécifique de cette page</h3> <p>Un exemple de paragraphe de texte, avec <a href="">des liens</a></p> <ul> <li>Un exemple</li> <li>de liste</li> <li>avec <a href="">des liens</a> aussi</li> </ul> <p>Un exemple d'image avec une légende<img src="..."></p> A toi d'ajouter à cet exemple les éléments nécessaire d'après le contenu prévisible du site. Je me suis limité ici à l'essentiel. Peut-être prévois-tu de citer des textes (élément <blockquote>), d'indiquer des adresses (élément <address>). S'il y a des pages avec des formulaires pour une recherche ou autre (<form>), il vaudra mieux les traiter à part par la suite. Tu devrais pouvoir aboutir ainsi à 3 modèles de pages (accueil, parents, enfants).

Je retire ce que j'ai dit : il ne peut y avoir aucune bonne raison de faire ce genre de tripotage

Heu... Je ne vois pas où serait le problème. En tout cas, je n'en ai jamais rencontré de ce type ? Au fait, il s'agit du sélecteur universel ("universal selector") et non "wildcard selector" comme l'appelle http://www.htmlref.com/reference/appb/selectors.htm Je reprends la specification CSS2 : http://www.yoyodesign.org/doc/w3c/css2/sel...versal-selector De la même manière, pour reprendre l'exemple donné par la page que tu cites, les deux formulations suivantes sont équivalentes : div * span {background - color: yellow;} div span {background - color: yellow;}

Pour ta première page, http://membres.lycos.fr/cledencapsizun/ind...lle_de_langroas, tu es simplement victime : - d'une DTD incorrecte en début de page - du box model, c'est à dire du mode de calcul erroné des dimensions contenu/padding/margin par Internet Explorer - d'un problème de marge lié aux flottants Pour régler ça, il faut : - d'abord mettre la bonne DTD complète, qui est : <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> (Voir http://openweb.eu.org/articles/differentes_dtd/ pour faire des copié/collé des bonnes DTD bien écrites. ne vous fiez pas à celles générés par vos éditeurs wysiwyg). - ensuite, ménager une marge gauche pour ta div.contenu, en ajoutant une margin-left d'au moins 130px; (dimension de ton menu flottant de gauche) - enfin, supprimer le padding: 5px de la div.contenu, responsable du décrochement de celle-ci. Il suffit de le remplacer par une marge de 5px appliquée à tous les éléments contenu dans cette div. Pour les titres, c'est facile, mais il faut que tu balises le reste du contenu avec des <p> et des <ul> auquel appliquer cette marge latérale. Sur le box-model, voir : http://openweb.eu.org/articles/dimensions_boites_css/

Tu peux modifier sans risque de perturber le script. Au passage, comme la question avait été abordée dans un autre fil, cette modification est tout à fait ladmissible sur un de ces scripts qu'on s'engage à ne pas modifier pour pouvoir utiliser des services de statistiques ou autre : ce n'est pas le contenu du script qui est modifié, mais uniquement sa déclaration. Cela dit... "maquiller un script de statistique en feuille de style"... là, il y a sûrement une bonne raison, mais elle m'échappe Tu peux nous en dire plus ?

L'avertissement est effectivement dû à l'absence de famille générique pour les règles signalées par Denis. Le sélecteur * est correctement employé; Mais je ne vois pas bien son utilité puisque la même déclaration est faite pour le sélecteur body. Même si les familles étaient différentes pour * et pour body, celles du body l'emporteraient puisque c'est un sélecteur plus spécifique.

Bravo ! Allez, encore quelques détails, tout de même : Accessibilité Ton lien vers le contenu et ton lien home ne sont séparés par aucun caractère : <div id="header"> <a class="textheader" href="#contenu">. : Contenu</a><a class="textheader" href="http://s.billard.free.fr/">. : HOME</a></div> Ceci peut poser des problèmes dans certains lecteurs d'écrans qui énonceront les deux liens à la suite sans permettre à l'utilisateur de les distinguer. D'où le | proposé dans mon exemple ci-dessus. Il suffit que tu déplaces tes petits points pour arriver au même résultat : <div id="header"> . : <a class="textheader" href="#contenu">Contenu</a> . : <a class="textheader" href="http://s.billard.free.fr/">HOME</a> </div> Avec éventuellement une petite précision sur la police/couleur de header en CSS pour que les petits points soient présentés comme le texte des liens. D'autre part, ton menu comporte deux liens différents ayant le même intitulé "Liens utiles". Dans un lecteur d'écran par exemple, lorsqu'on utilise pour naviguer la fonction listant tous les liens de la page, on se retrouve avec deux liens apparemment identiques sans aucune idée de leur cible. Ils ne sont en effet différentiables que dans le contexte de la page. Donc, tu pourrais donner deux intitulés plus explicites, par exemple " Liens Musique" et "Liens Photo". (tes autres liens sont au contraire très explicites et bien libellés). langue du document Si celle-ci n'est pas déterminée par l'en-tête HTTP Content-Language, tu devrais signaler la langue de ton document avec : <html lang="fr"> Et les changements occasionnels de langue, par exemple : <h2 lang="en">Me, myself, and I</h2> validité Le script associé au style doit être balisé avec : <script type="text/javascript"> Tiens, une remarque amusante : une fois la correction faite pour le javascript, il suffit de quelques secondes pour transformer cette bonne page HTML transitional en... XHTML strict

Non. On est très loin de pouvoir poser la question en termes d'implémentation dans IE ou dans un autre navigateur. Un rappel salutaire à lire impérativement quand on s'intéresse à XHTML2 : XHTML 2.0, le vilain petit canard (Par ailleurs très clair sur le processus d'élaboration d'une recommandation/spécification/norme du W3C, et pour cause, vu l'auteur )

Aurais-tu le temps (et le courage) de détailler le problème posé par ce formulaire ? A partir de là, il serait utile et instructif d'élaborer sur ce fil une solution évidemment purement théorique (HTML uniquement), mais pédagogique...