Laurent Denis a écrit :
Ce qui revient à dire qu'il ne faut pas:
- afficher la langue de destination d'un lien à partir d'hreflang
- imprimer les url des liens à partir d'href
- imprimer la signification d'un acronyme à partir de title
- afficher la date de modification d'un contenu wiki à partir de datetime
- afficher le title d'une image en guise de légende
- afficher l'url source d'une citation à partir de cite
- etc.
Le HTML a été conçu pour la diffusion de contenu textuel dans des documents autonomes.
On a donc ce contenu textuel structuré par des balises ayant un sens sémantique.
C'est ce contenu qui nous interesse, pas le contenu des attributs de balises.
Tu parles des hyperliens (href, hreflang, ...), mais cela ne fait pas parti du contenu (au sens de parti du texte), ce n'est pas une information textuelle, c'est un mécanisme présent dans le document et permettant d'accéder à un autre document. Seul le texte présent entre <a...> et </a> est du contenu.
Concernant l'attribut title, la recommandation propose elle-même de représenter son contenu sous forme d'info-bulle. C'est donc probablement une sorte d'"entorse" volontaire de la part du W3C.
a écrit :
Ou qu'il faudrait supprimer le lien vers la page d'accueil puisque <link rel="home"...> est là pour ça...
Dans l'absolu, oui.
C'est le problème du web actuellement. Il n'y a pas encore vraiment de langage de description d'interface (XUL, XAML, ...) reconnu et massivement utilisé. Or c'est ce dont ont besoin beaucoup de sites (la plupart des sites commerciaux pour commencer). Donc on se rabat sur le HTML, par habitude et parce qu'il n'y a pas vraiment d'alternative.
a écrit :
Je suis tout à fait d'accord pour considérer que CSS est une béquille problématique pour combler les défauts fonctionnels des navigateurs. Mais d'une autre côté, l'information étant présente, je ne vois pas de raison de ne pas la rendre disponible pour enrichir l'expérience de l'utilisateur (dans la mesure où l'expérience fonctionnelle minimale n'est pas compromise lorsque les CSS ne sont pas activées). Voir le point 1.9 dans http://www.la-grange.net/w3c/cuap/
Oui, ce n'est probablement pas par hasard que les concepteurs des CSS ont ajouté la fonction attr(). Ils ont peut-être estimé que, dans le cas de certains attributs, cette information incluse dans le document sous la forme de contenu d'un attribut pouvait interesser la personne qui visualise le document.
Le cas de l'attribut href est révélateur.
Le but premier de l'attribut href sur la balise A est d'indiquer à l'agent utilisateur l'URL à appeller si le lien est activé. Je rappelle qu'à la base, le HTML a été conçu pour des documents autonomes. C'est son contenu qui est important, pas que tel ou tel morceau de texte pointe vers tel ou tel autre document. Et pourtant, il serait difficilement concevable aujourd'hui de ne pas avoir accés à cette "information secondaire" (barre de statut, lecture vocale, ...).
Certains navigateurs ont pris le parti de rendre plus accessible le contenu de certains attributs (source d'une citation, langue d'un document ciblé par un lien, dans Mozilla en faisant click droit -> properties; Il y a sùrement des exemples similaires pour Opera).
Mais dans l'absolu, cette information n'est pas nécessaire à la compréhension du document.
a écrit :
Une justification, parmi d'autres: les compteurs "évolués'" du type lower-roman ((i, ii, iii...), upper-roman ou les combinaisons de compteurs rendent l'audition d'une page Web passablement atroce dans un media vocal: le fait que ces compteurs soient générés en CSS permet de différencier le type de numérotation ou de combinaison selon les medias.
Donc ces média vocaux ne lisent pas non plus les compteurs numériques ?
a écrit :
Heu... J'ai du mal à suivre, là ? Cette CSS auditive ajoute des "marqueurs de sens" avant / après le contenu, ce qui respecte parfaitement le principe de CSS (voir la spécification qui comporte plusieurs exemples tout à fait similaires).
Peux-tu préciser ou fournir un lien vers les exemples en question ? Je ne vois rien ressemblant de près ou de loin à ton exemple dans la recommandation (CSS 2.0 ou 2.1). On parle bien de
ça ?
a écrit :
Il n'y a aucune différence entre la bordure ajoutée via CSS à un tableau dans un navigateur graphique et le fait qu'une CSS auditive ajoute la mention "Ceci est une ligne de tableau").
Mais non, là, les styles sont utilisées pour décrire la structure du document auquel la feuille de style est rattachée, ce qui n'a rien à voir avec le rôle des CSS.
* Soit j'ai manqué une étape de tes explications et ne comprend donc pas le sens de cet exemple
* Soit je me trompe lourdement sur le rôle des CSS et j'ai hâte dans ce cas que tu me donnes plus d'explications afin que je rectifie mes connaissances sur ce sujet (ceci dit sans ironie)
a écrit :
Pour illustrer très concrètement cette dérive fréquente:
- http://webnaute.net/Tests/CSS/HTTP-Link/ ... omet de signaler que l'en-tête HTTP link n'existe plus en HTTP1.1, et qu'aucun navigateur n'est actuellement tenu de le supporter (même si les navigateurs gecko le font)
Si, c'est indiqué vers la fin du document.
a écrit :
- http://webnaute.net/Tests/CSS/XML-Stylesheet/ omet le fait qu'xml-stylesheet n'a de sens et ne peut être appliqué que si le navigateur supporte application/xml+xhtml et si le document lui est adressé comme tel. Il est donc parfaitement normal et heureux qu'IE n'applique pas les styles dans ce cas, et opera aura du mal à l'appliquer puisque la page lui est adressée (pourquoi ???) en text/html 
Sur ce cas, j'admet mon erreur. Mais ce n'est pas celle que tu penses
, je n'ai tout simplement (et bètement, je le reconnais) pas mis en place la vérification de l'en-tête accept qui aurait permis d'envoyer le document avec l'en-tête application/xml à défaut de application/xhtml+xml.
Tu noteras d'ailleurs que ni Opera ni IE win ne sont présents dans le tableau des résultats, tout simplement parce que je n'avais pas fait cette vérification d'en-tête, et ultérieurement, j'étais passé à autre chose et n'avais pas pensé à terminer la mise en place de ce test.
Pour les résultats concernant IE mac et Safari, ils m'ont été donné par email par des visiteurs et je les ai intégré au tableau.
Aucune frustration donc ni l'envie d'humilier tel ou tel navigateur, juste envie de tester un mécanisme nouvellement découvert.
a écrit :
- http://webnaute.net/Tests/CSS/MIME-Negociation/
Ah, là, je reconnais mon tort. Il y a en effet un brin de mépris déplacé. Le document a été édité.
a écrit :
... omet de signaler qu'aucun navigateur n'est tenu de signaler par défaut dans ses HTTP_ACCEPT la totalité des types supportés (même si les navigateurs gecko signalent ce type).
Mais je ne dis aucunement que c'est obligatoire.
Modifié le 24 Dec 2004 - 03:48
? 