LaurentDenis

Autre contrainte du XHTML1.1 justement : la page n'étant pas en UTF-8 ou en UTF-16, mais en iso-8859-1, le prologue xml est nécessaire pour spécifier l'encodage.

Ah... Me voilà encore à jouer les rabat-joie : Très joli, le passage au XHTML1.1. Mais maintenant, il n'y a plus qu'à... remettre ça avec le bon vieux DocType XHTML1.0 (Autrement dit, juste changer le doctype en gardant l'excellent code de Denis) En effet, à la différence du XHTML1.0, le XHTML1.1: - ne doit pas être servi comme étant du HTML (avec le type Mime text/html) - doit être servi comme étant du XML ( avec le type mime application/xml + xhtml). Voir http://www.w3.org/TR/xhtml-media-types/ (attention à la différence entre "may" et "should" qui ont chacun un sens bien précis dans les spécifications du W3C) Pour ceux qui se posent la question, disons que le type mime est une information envoyée par le serveur qui indique au navigateur ce qu'il va recevoir : - du HTML, - du XML, - une image GIF, PNG... - de la soupe, - des brocolis - ou une claque. Actuellement, la page est servie incorrectement en text/html, autrement dit, c'est de la soupe. Coup de bol, les navigateurs s'en accommodent et font comme si c'était du HTML. Passer en application/xml + xhtml ne serait pas une bonne solution, car : - ce type mime n'est pas supporté (entre autres) par Internet Explorer (Win et Mac). Le document se transforme alors en brocolis à télécharger. - le document étant interprété par les navigateurs Gecko et par Opera comme étant du xml, il ne doit comporter aucune erreur de syntaxe sinon... c'est la claque ! Le moteur de rendu du navigateur s'arrête sur l'erreur, affiche un message d'alerte et la suite du code XHTML. On peut être un peu masochiste et apprécier ce mode de validation radical (c'est mon cas et celui de Denis aussi, il me semble), mais il faut être sûr de bien maîtriser sa syntaxe ! ce serait encore jouable ici, mais ce serait très dangereux par exemple dans un weblog où les commentaires et trackbacks risquent d'amener du code invalide : Denis témoignera (avec accablement) que j'ai souvent (et involontairement) dézingué son CyberCodeur juste avec la petite esperluette du Blog & Blues de ma signature dans un trackback... Déclarer correctement du XHTML1.1 est donc plutôt contraignant: - Il faut faire de la négociation de contenu au niveau serveur pour n'envoyer du XHTML1.1 en application/xml+xhtml qu'aux navigateurs qui déclarent le supporter, et du XHTML1.0 en text/html aux autres. - pas de droit à l'erreur Et ces contraintes n'apportent... aucun avantage concret ici. En effet, XHTML1.1 sert principalement à intégrer un élément supplémentaire (le module ruby) qui n'est pas utilisé dans cette page (où il ne servirait à rien d'ailleurs). voilà, voilà... Bon, j'avoue : on l'a tous fait, de s'offrir brièvement le frisson d'une page en XHTML1.1 Sinon, pour l'accessibilité : il y a deux liens adjacents dans la page à cause des stikers de validation qui ne sont séparés par aucun caractère affichable. [edit]: du danger des forums pour les blogueurs : on finit par faire des posts en guise de message au lieu de bloguer ça chez soi

Si peu en effet. Juste Tainted Words par exemple Très heureux de te retrouver sur le hub, Steve !

C'est tout bon, on ne revient pas dessus, dans un but productif. Mais Denis, juste pour toi (et les curieux), pour creuser un peu : que penses-tu de Accessibilité et handicaps de compréhension (Notes de lecture) ?

heu... Préviens-moi avant de citer, que je m'auto-censure : j'ai la fâcheuse habitude de laisser traîner un peu n'importe quoi sur le Web Cette histoire de style switcher, ça me fait penser au téléphone portable. Il faut vous dire qu'en dehors de deux trois trucs sur le Web, je suis résolument hostile au supposé progrès, et tout spécialement au téléphone. C'est pourquoi j'ai été très étonné il y a quelques temps chez des amis de voir que leurs filles avaient encore un nouveau portable tout coloré, au moins le 3e depuis le début de l'année. Meuh non ! M'a-t-on expliqué gentillement : c'est juste la "coque" (ça s'écrit comme ça?) qu'on change. C'est fun ! Le rapport ? La coque du bidulophone est "fun" parce que c'est juste un accessoire très simple qui donne à bon compte l'illusion volontaire d'avoir vraiment changé quelque-chose. Les CSS alternatives... prendront dans le mythique "grand public" quand il en sera de même pour elles : une technique aussi transparente que l'aperçu avant impression, un clic sur un bouton avec un petit logo sympa, et c'est tout. D'ici là, rien que le mot "style" (ou "présentation", etc...) est mauvais. Bref, c'est un truc de geek (très rigolo, je le répète). Bon, j'arrête d'intervenir dans ce sujet : au fil de mes messages, je deviens de plus en plus sceptique

Dino : je viens de faire un petit test avec un invité qui "consomme" du Web depuis quelques temps mais que la technique indiffère. Réactions aux explications de http://www.canaldumidi.com/pages/styles.htm : - Il en faut, des trucs, pour que ça marche ! - Tu as bien le Mozilla-là, le java-machin et le macaroni (cookie pour lui) ? - Faut que je change quoi pour la dimension du texte ? Bref, je n'ai lâchement pas osé lui montrer ma propre page d'explication qui ne vaut sans doute pas mieux J'en retiens (pour donner un avis plus personnel que ci-dessus) : - que les explications qui commencent par une avalanche de mises en garde et de conditions techniques pour que ça marche... sont dissuasives plus qu'utiles; - qu'il est inutile de mêler la question des navigateurs et celles des styles; - que c'est tout de même plus transparent sans obligation de javascript - que la béquille "style switcher"... est tout de même plutôt boiteuse Tiens, si je refais des styles alternatifs, je me contenterai des <link rel="... qui conviennent pour les futurs navigateurs qui feront ça proprement

Les degrés de priorités 1,2,3 de la WAI définissent... 3 degrés d'accessibilité Il n'y a aucun degré suprême et ultime garantissant l'accessibilité universelle d'un contenu Web : il y a aura toujours une combinaison de handicaps pour poser de nouveaux problèmes. L'accessibilité est donc une démarche (exigeante) et non un état stable. Cela dit, les résultats des 3 degrés de priorités sont clairement définis dans la WAI. Voir : http://www.la-grange.net/w3c/wcag1/wai-pageauth.html Les Directives pour l'accessibilité aux contenus Web (version 1.0) datent de 1999, et commencent franchement à dater, pour tout dire. Quelques-uns de ses défauts notoires sont étudiés dans http://www.w3.org/TR/wcag2-req/ Une nouvelle spécification est à l'état de travaux: voir http://www.w3.org/TR/2004/WD-WCAG20-20040311/

J'oubliais un grand cri primal : non ! pas persistant le cookie, pas persistant ! Si la CSS par défaut est mauvaise au point que ça en devient pénible de switcher vers son style favori à chaque visite... c'est qu'il y a un loupé quelque-part. En d'autres termes, le style par défaut doit être le plus "neutre" et le moins risqué du lot.

Je rebondis sur ce qui précède : - la seule solution valable serait de s'en remettre au seul navigateur, car c'est tout simplement son boulot, et non celui du serveur. Le "style switcher" n'a en fait strictement rien à faire dans la page Web, car la gestion des styles alternatifs est du ressort du media. Mais on se heurte à la réalité : ---IE ignore les styles alternatifs ---Opera et les navigateurs Gecko les supportent, mais avec le même défaut rédhibitoire : le style choisi n'est pas persistant de page en page au fil de la navigation. Autrement dit, l'utilisateur revient au style par défaut dès qu'il change de page... C'est idiot, d'accord, mais rien ne semble vouloir changer de ce côté depuis longtemps, quelques-soient les rapports de bugs et les réclamations reçues par les auteurs de ces navigateurs. - sur le principe, priver les utilisateurs d'IE des styles alternatifs en s'en remettant au navigateur n'a rien de bien grave : ce n'est qu'une fonctionnalité tout à fait accessoire (rigolote cependant) liée uniquement à la présentation. On a donc le confort et le "fun" de navigation qu'on mérite, ou plutôt qui est à la portée du navigateur qu'on utilise... - mais quand on fait de belles feuilles de styles variées en montrant ainsi son habileté, on a naturellement envie que tout le monde en profite, et sans avoir à rechanger le style à chaque page : d'où le style switcher, béquille plus qu'autre-chose. - ça peut se faire en javascript... avec une qualité immense : ça reste du côté du navigateur. Aucune sollicitation supplémentaire côté serveur. Evidemment, ceux qui n'ont pas javascript en sont privés... mais ne pas avoir activé javascript et vouloir s'amuser en surfant, c'est un peu beaucoup demander. - ça peut se faire uniquement côté serveur, au prix modique d'un cookie de session (faire propre !). Dans ce cas, AMHA: --- éviter les scripts qui vous perdent dans la nature dès que votre navigateur cache le referent, ou qu'il n'accepte pas votre cookie... Veiller à ce que la page de switch redirige toujours quelque-part sur le site (accueil ou carte ou page spécifique, au pire). Pour ma part, je transmettais l'URL de la page appelant le script en query string, pour être sûr de ne pas la perdre. En cas d'absence d'url, on arrivait sur l'accueil après le switch. (Je parle au passé parce que je n'ai pas eu le temps de remettre tout ça en place sur mon nouveau site personnel). --- éviter les formulaires express dans le menu du site, qui vous switchent le style sans vous expliquer ce dont il s'agit, voir sans que vous ayez même cliqué sur autre chose que la liste déroulante des styles disponibles : 99.99% de la population du Web ne sait absolument pas de quoi il s'agit. Une page de switch avec un formulaire bien propre et surtout une petite explication sur la nature la chose... ça aide. --- comme dit Ganf, déclarer vos styles proprement avec une bonne gestion des medias et surtout des title, pour que ça marche proprement quand on s'en remet au navigateur.

Moi, moi, m'sieur ! Je veux bien être prévenu pour mettre à jour mon billet Au passage : re-bravo pour l'article.

ça n'était pas du tout mon intention, rassures-toi. Sujet clos pour moi

Bon, je conviens volontier que ce petit bouton rendra sûrement service à pleins de gens. Mais juste pour le principe et l'amour de la discussion : met-on dans les pages web le code nécessaire à l'affichage de l'ascenseur vertical ? Vous me direz si je me trompe, mais il me semble bien que non : ce sont évidemment les navigateurs qui s'en charge, de cet ascenseur. Alors... pourquoi y mettre un bouton "haut de page" qui est typiquement du ressort du navigateur, lui aussi ? D'accord, c'est parce que les navigateurs sont mal fichus et ne l'ont pas par défaut, le bouton bidule. Moi, il y a longtemps que je l'ai ajouté dans mon Opera, tiens

Presque : http://www.la-grange.net/2002/10/23.html

Une question sans doute sans réponse possible : as-tu remarqué une différence selon le charset choisi ? la manière de le spécifier (HTTP, meta...) ?

Suggestion impulsive et peut-être stupide : pour élaborer collectivement un tel lexique, pourquoi ne pas mettre en place... un petit wiki ? Sur le principe "une entrée du lexique = un mot ou une expression = un MotWiki = une page wiki générée automatiquement", c'est l'outil le plus adapté que je connaisse à ce type de travail collectif.

Les tableaux d'entités ne manquent pas sur le Web. Personnellement, j'ai un faible pour A Simple Character Entity Chart particulièrement complet et bien présenté. Au passage, un premier article d'une série prometteuse sur la question chez Tainted Words (en français) : Jeux de caractères : c'est quoi ?

Daniel Glazman publie un premier billet sur la question, en anglais, mais particulièrement instructif (j'ai vraiment l'impression de commencer à mieux comprendre les enjeux, là ) Voir : Future of HTML and the Web, part 1 Je me suis risqué à résumer (en français) les points qui m'ont paru saillants dans Une de mes notes de lectures Eric : je n'ai pas encore fait de retour sur ton projet d'article... faute d'avoir encore tout compris Mais en tous cas, tu auras au moins une relecture typo et une critique de "consommateur moyen qui a du mal à comprendre", si ça peut servir...

Quelques exemples de l'utilité des classes dans le XHTML pour "faire du DOM dessus" (pierredureau, ça va te rester, ça... ) Un excellent exemple dans un tutoriel complet de Karl Dubost, montrant pas à pas comment générer un RSS à partir d'une source XHTML via XSLT : - le tutoriel commence avec Jour 1 : De XHTML à RSS - Structure de ce site - l'utilisation des classes pour viser les informations à extraire de la source XHTML apparaît dans Jour 6 - De XHTML à RSS - Explication du jardin Autre exemple : imaginons un CMS pour un site publiant les contributions de différents auteurs. Le CMS archive les sources de ses articles en docbook, autrement dit, dans un dialecte XML pas forcément connu des auteurs et délicat à manier. Plutôt que d'imposer aux auteurs l'utilisation de docbook pour fournir leurs articles, on leur demande simplement de faire un XHTML valide respectant les règles d'un template simple. Celui-ci leur fait utiliser entre-autres des classes pré-définies qui seront utilisées par la transformation XSLT vers le docbook final, après un simple upload de l'article... (toute ressemblance avec le CMS d'OpenWeb serait purement fortuite D'ailleurs, ça ne marche plus tout à fait comme ça) Dernier exemple : dans mon weblog, je suis en train de préparer un système de récupération de mes liens, pour constituer une BD de sources. Je voudrais que les liens présent dans un billet soient récupérés automatiquement lors de la publication, pour être indexés selon leur sujet. Je vais simplement utiliser des classes appliquées à ces liens pour les étiquetter selon leur thématique, à l'aide de quelques mots-clés combinables (XHTML, CSS, accessibilité, egronomie...), faciles à utiliser lorsque j'écris mon billet. Après ajout d'un billet au blogue, une simple XSLT pourra extraire les liens et les indexer en se basant sur ces classes. (Tu me diras peut-être que je pourrais obtenir le même résultat en utilisant le title des liens... sauf que ça casserait l'accessibilité, avec des titles n'apportant plus la bonne information).

Un "titre" avec pour seul intitulé "Accueil" n'a en effet pas en grand intérêt. Mais dans Lynx non plus, en fait L'information est cependant utile, et peut être donnée d'autres façons. Par exemple, la barre de localisation dans le site sous la forme : Vous êtes dans > Monsite > rubrique truc > document bidule Codée avec un simple <p> ou des <ul> imbriquées, et avec les liens qu'il faut sur Monsite (accueil) et rubrique truc (sommaire de section). Ou encore, un simple ajout au titre du site : Monsite (Accueil) On peut en imaginer d'autres. Sur mon blog, je me suis amusé à utiliser le titre h1 de mes pages pour en faire un barre de localisation, par exemple. Avec CSS, le même h1 produit à la fois le nom du site en titre bien classique et la barre de localisation en dessous... Ah... Vieux problème. Voir chez Denis cette discussion récente sur le sujet, avec diverses démarches. Le contenu principal de la page en premier, et les menus ensuite (qu'ils soient ensuite répartis entre des colonnes gauche et droites, un pied... n'y change rien) : du point de vue accessibilité, l'accès au contenu significatif de chaque page est immédiat et plus aisé dans les lecteurs d'écran, dans les navigateurs textes, dans les navigateurs graphiques pour les personnes ne pouvant utiliser une souris... On pourrait peut-être y ajouter (mais d'autres ici te renseigneront mieux que moi) que google (et/ou d'autres moteurs, je suppose) serait plus sensible au contenu présent en début de page... Attention : quand on parle de linéarité, ça concerne uniquement le HTML. Le rendu graphique en CSS n'a plus rien de linéaire le plus souvent, avec des présentations où les blocs se répartissent non seulement de "haut" en "bas", mais aussi de gauche à droite (dans le plan et non sur une droite). Pour ma part, je place systématiquement les menus après le contenu, sans me préoccuper de leur emplacement dans le rendu graphique (qui n'est déterminé qu'après, de toute façon). Autant que possible, on déconseille de mettre une page "cul par dessus tête" avec le positionnement CSS. Si on l'interprète strictement, un menu apparaissant comme une barre horizontale avant le contenu principal devrait être écrit dans le code HTML avant le contenu, et non pas après. Mais je ne crois pas cependant qu'il faut en faire une règle absolue. La CSS principale d'OpenWeb (réalisée par Emmanuel Clément) te montrera qu'un menu peut se retrouver via CSS réparti "un peu partout" dans la page graphique... Ton menu horizontal peut très bien se placer en HTML après le contenu, et se positionner avant via CSS. Après tout, tu feras peut-être un jour une CSS alternative pour ton site, où ce menu ne serait plus horizontal, et serait dans une colonne à gauche ou à droite... Tu n'es pas tenu par le rendu graphique pour structurer ton document HTML, quand même !

Tout est dit, ou presque : class est tout aussi "sémantique" que id : "si on veut faire du DOM dessus", par exemple... C'est un identificateur irremplaçable, sachant qu'il peut être répété dans le document pour étiquetter une série de données

Rassure-toi : c'est un syndrome très répandu, heureusement non durable. - Produire d'abord la source XHTML brute en utilisant des div "logiques" par section principale de la page, sans aucune idée d'une éventuelle utilisation CSS ; - Vérifier la structure et le rendu dans un navigateur texte et un lecteur d'écran. Corriger en conséquence. - Développer la CSS sans ajout de div ou de span, sur la base des éléments existants. Mais c'est juste un petit peu radical, comme démarche Et pas forcément transposable. Il faudrait en fait une url vers ton code pour te donner une analyse plus efficace de ton code et de la démarche à suivre. Réponse résolue d'un vieil intégriste CSS... oui. Pour l'instant, tu as autre-chose à faire que te lancer dans des positionnements subtils. Et si tu as une solution bien en main avec un tableau (un seul, pas d'imbrication svp), ne perds pas de temps : utilise-la. S'il pose des problèmes d'accessibilité, là encore, il faudra le code précis : il y a des astuces permettant de résoudre le problème majeur des tableaux, c'est à dire leur linéarisation (quand ils sont raisonnablement simples et non imbriqués). Tu reverras la question plus tard, quand tu ne rêveras plus de CSS toute la nuit, justement ! Rome ne s'est pas construite en un jour. Un site full-CSS hight-tech non plus

Excellente nouvelle ! Ce que j'avais vu de ChuWiki m'avait semblé très intéressant

Je n'ai pas dépassé la page d'accueil, mais celle-ci fonctionne correctement sous Opera 7.51 (toutes plates-formes). Idem pour IE6Win Seul bug : - le style-switcher m'a amené à une erreur 403 (url visée http://thorgal.tektonika2.com/sitemoi/siteperso/) avec IE6 - avec Opera 7.51, il s'arrête à la page du switcher (http://thorgal.tektonika2.com/sitemoi/siteperso/switcher.php) sans redirection sur la page d'origine. Probablement un problème de gestion du referer (prévoir un test et une redirection par défaut, par exemple, ou transmettre l'url en query string) Je tâcherai d'y revenir pour d'autres tests. En tout cas, c'est une belle réalisation, intéressante... même pour un vieil anti-javascript primaire comme moi

Hum... tant que tu es à faire du javascript à haute dose, pourquoi ne pas prévoir deux CSS : - l'une disponible sans javascript, donnant une présentation agréable de ta page, moins "brute" que le HTML tout nu, - l'autre appliquée via javascript, neutralisant la première et reprenant tes effets actuels. Mais bien-sûr, la meilleure solution serait de reproduire tes effets dynamiques en pur CSS. Tu auras à jongler avec le mauvais support CSS de certains navigateurs (je ne vise personne ), mais ce devrait être jouable.

La structure de ta page (je prends l'accueil) est en effet très compliquée. Il doit y avoir moyen de faire plus simple. Sur ta page d'accueil, ton h1... est en display:none, non ? A quoi sert un titre qui n'apparaît pas ? Il serait plus logique de le faire porter par le logo du site, en tête de page. A partir de là, la réorganisation des titres devrait déjà être plus facile. Une question simple : pour qui écris-tu prioritairement des pages Web ? Pour les moteurs de recherche ou pour les gens qui les lisent ? Les moteurs de recherche exploitent les titres pour l'indexation des pages, et c'est une bonne chose (c'est fait pour, entre-autres raison d'être). Mais un titre ne se détermine pas d'abord pour le référencement...