5568 sujets

Sémantique web et HTML

[Appel à commentaires] Quelques pages de sémantique

Bonjour!

Je n'ai pas posté ce message dans le forum "Ergonomie et esthétique générale", car... il n'y a aucun design Smiley cligne . Et je ne prévois pas de beaucoup apporter de style à l'ensemble; vous comprendrez pourquoi.

En revanche, j'aimerais avoir vos avis sur le contenu. Y-a-t-il quelque chose qui vous choque? qui cloche? une contre-vérité ou une faute grave/vénielle?
Je ne compte pas apporter beaucoup de stylage à l'ensemble -le but est de faire une démonstration de tous ces éléments plus ou moins inconnus, tels qu'ils sont rendus dans un navigateur. Au mieux, il y aura peut-être un peu de CSS/JavaScript pour faire une démo de ce qu'il est possible de faire pour tirer parti au maximum des éléments et attributs dont les fonctionnalités ne sont pas encore pleinement exploitées par défaut par les navigateurs.

Tout commentaire sur l'accessibilité est aussi le bienvenu!

Après tous ces discours, l'adresse (temporaire):
http://dam.cicrp.jussieu.fr/dam/accessibilite/html/introduction.html
Le titre même ne me convient pas totalement. Je suis ouvert aux suggestions Smiley smile

Et si un modérateur trouve que ce sujet est plus à sa place dans le salon ergo ou accessibilité, qu'il se lache et déplace Smiley ravi

Merci!
Modifié par Gilles (29 Jul 2005 - 09:24)
Bonjour Gilles,

J'espère avoir le temps cette après-midi de revenir sur ce document passionnant pour jouer la mouche du coche Smiley cligne .

En attendant, une première réflexion sur :

4-b Transitionnelle, stricte ou avec prise en charge des cadres ?

Chacune de ces trois catégories recouvre un domaine d'usage bien distinct. Pour un usage plus raisonné, il est recommandé d'opter pour la déclaration la plus adaptée au contexte.

La déclaration transitionnelle, permet aux anciens sites codés lors de la vague de « propriétarisation » des balises, dans les années 90), d'amorcer la transition vers un codage plus propre, sans devoir forcément casser tout leur code. Elle donne droit à l'utilisation de certaines balises de présentation.


En fait, les trois déclarations transitionnelles (HTML4.0, 4.01 et XHTML1.0) me semblent avoir un but qui n'est pas bien décrit, mais qui n'est pas facile à résumer dans un document tel que celui-ci Smiley ohwell :

- elles n'autorisent pas plus que les autres DTD les éléments propriétaires. Personnellement, je mettrais la frontière entre code "propre" et "pas propre" sur l'utilisation de <marquee> plutôt que de <center>.

- elles autorisent en revanche, comme tu le dis, certains éléments de présentation dont la série de DTD HTML4.0 à XHTML1.0 vise à se débarasser, dans l'optique de la séparation du contenu et de la structure, et de l'adoption des feuilles de styles.
Le seuil intéressant est celui d'XHTML modulaire, qui les relègue dans un module bien spécifique, uniquement pour préserver la compatibilité ascendante, module qui n'est pas retenu dans XHTML1.1 par exemple : on va vers un format beaucoup plus abstrait, pour être beaucoup plus déclinable selon les medias.

- Le "transitional" de ces DTD ne vise pas vraiment la transition faite par les auteurs dans leur choix de codage. Elle vise plutôt à définir une base permettant à des outils de traitement automatisés (Tidy, XSLT...) de prendre un code "à l'ancienne, mais pas soupe de tag" et de le convertir en XHTML strict, voir au-delà, en générant des feuilles de styles (ce que fait typiquement Tidy).
Autrement-dit, il ne s'agit pas vraiment d'autoriser l'usage de ces éléments de présentation "dépréciés", mais plutôt de favoriser leur élimination au bout du compte.

- La différence plus essentielle, mais moins visible, entre strict et transitional me semble se situer à un autre niveau, qui est celui des contenus anonymes :
* en transitional, <body>, <form>, <blockquote> (par exemple), ont un type de contenu %flow => tu peux mettre dedans du texte non structuré à l'aide de <p>, <ul>, <hn>, etc. Tu peux donc te passer des éléments HTML très signifiants et délivrer une "structure molle", dont seule la présentation va donner le sens de détail, au prix d'un résultat nettement moins exploitable en dehors du navigateur graphique.
* en strict, ces éléments <body>, <form>... ont un type de contenu %block => tu es obligé de structurer leur contenu de manière beaucoup plus signifiante : c'est la "structure stricte", par opposition à la "molle", qui se prête à de nombreux traitements par la suite en dehors du navigateur graphique Smiley cligne

Qu'en penses-tu ?

<edit>10:19 : j'arrête d'éditer ce message pour expliciter mon idée, sinon, tu ne parviendras jamais à le lire Smiley lol </>
Modifié par Laurent Denis (29 Jul 2005 - 10:06)
Je profite de ma réponse pour remonter un peu le sujet Smiley cligne

Tes remarques (surtout la dernière!) sont très intéressantes. Il y a des phrases, parfois, qui d'un seul coup éclairent beaucoup de questions... et c'est le cas de ta dernière remarque pour moi Smiley smile Je m'étais déjà interrogé sur la "souplesse" par exemple de blockquote en transitionnelle, sans penser à regarder exactement la définition des entités dans la DTD. Une autre preuve du fait que multiplier les points de vue est une expérience enrichissante.

Je vais tâcher d'amender mon discours pour essayer de faire passer cette notion... je dis bien "essayer", car le public est a priori assez divers; je ne peux pas entrer dans beaucoup de détails techniques.

Appel à la communauté: d'autres remarques sur le contenu?

PS: inutile, si vous y avez pensé, de mettre ces pages dans vos signets/favoris/marque-pages. Ces URLs ne seront plus à jour en automne (des restrictions d'usage seront alors appliquées aux serveurs de l'université où elles sont hébergées).
Bonjour Gilles,

Tu fais bien de remonter le sujet, car je n'avais pas pu, finalement, revenir t'embêter un peu sur un autre point :

a écrit :
On spécifie la langue à l'aide de l'attribut lang. Indiquer la langue dans laquelle est rédigé un document permet d'une part aux navigateurs à synthèse vocale d'adopter un accent correct à la lecture, d'autre part aux moteurs et annuaires de recherche de présenter les résultats d'une requête en fonction de sa langue de rédaction, ce qui améliore la pertinence des résultats.


Voilà qui n'est pas évident à éclairer dans le cadre d'un tel document : la différence entre langue primaire et langue de traitement d'un document est loin d'être facile à saisir :

- C'est la langue primaire qui correspond à l'info destinée aux moteurs de recherche, pour leur permettre de connaître le ou les publics cibles du document, et donc de classer celui-ci dans tels ou tels séries de résultat en fonction des préférences linguisitiques de leurs utilisateurs. Un même document peut très avoir plusieurs langues primaire, s'il s'agit par exemple d'une page bilingue où le même contenu est présenté dans les deux langue, ou encore par le biais de la négociation de contenu...

- C'est la langue de traitement qui va servir aux lecteurs d'écran pour basculer d'un moteur linguistique dans un autre. Et cette fois, la langue de traitement est unique pour chaque élément HTML concerné, même si la page peut, au total, avoir plusieurs langues de traitement successives... Smiley eek

Concrètement, quelle importance ?

- C'est effectivement l'attribut lang qui signale la langue de traitement unique de chaque élément HTML, avec effet d'héritage depuis l'élément racine <html>
- Mais ce n'est pas cet attribut qui renseigne sur la ou les langues primaires : c'est le rôle, par ordre de poids décroissant, de l'en-tête HTTP Content-Language et de la balise <meta> correspondante...
( http://openweb.eu.org/articles/specifier_langue/ )

Maintenant, est-ce :
- une distinction utile dans le cadre de ce cours ?
- ou une confusion admissible, sachant que le comportement réel des moteurs de recherche est tout de même assez incertain, et demanderait d'être étudié de prêt pour savoir dans quelle mesure est exploitée la langue primaire théorique ?
Bonjour,

Pour éclairer la différence entre langue primaire et de traitement, selon la terminologie brocolinienne qui est très bien, le plus simple est sans doute d'utiliser l'exemple d'une citation.

Ainsi dans un document en langue primaire française (html lang="fr") une citation anglaise devrait être signalée par l'attribut lang="en" afin de signaler la langue de traitement du contenu concerné.


JP
Modifié par jpv (03 Aug 2005 - 04:09)
Pour le page "élements usuels" :

a écrit :
Un tableau se déclare à l'aide de la balise <table>. On distingue deux grandes catégories de tableaux :

1. les tableaux de mise en forme, permettant la mise en page d'une page Web. Peu conseillés, ils doivent respecter quand ils sont utilisés quelques précautions ;
2. les tableaux de données, les plus complexes.


Je crois vraiment que cette présentation n'est pas une bonne idée car elle tends à valider la pratique des tables de layout.
En la lisant on à l'impression qu'il existerait une "catégorie" de tableaux spécifiques à la mise en page ce qui est évidemment faux.
Il serait préférable de définir un tableaux pour ce qu'il est : la présentation de données, point barre.
Puis de signaler les tables de layout comme un usage, hérité des faiblesses des premières versions de HTML, qui ne sont à utiliser que quand il est impossible de faire autrement et avec des adaptations spécifiques.

C'est important pour ceux qui seraient issus de la conception par tables de layout qui perçoivent généralement cet élément comme "naturellement" destiné à la mise en page et ont du mal à comprendre de ne plus l'utiliser.

a écrit :
L'attribut summary de l'élément <table> donne une description du tableau ; cette description doit être vide dans le cas d'un tableau de mise en forme.

Le problème est pris à l'envers, il faut renseigner le summary d'une table de layout si c'est pertinent, l'attribution d'un summary="" n'à aucun effet en dehors de faire croire à l'auteur qu'il à "bien fait".
Tout au contraire, une table de layout dont on ne parviens pas à définir le summary est un signe fort de son inutilité, ce qui est par exemple le cas des tables utilisé pour centrer le contenu dans la zone de display.
Cette recommandation est issue du guide accessiweb et franchement je la trouve dangereuse car elle tends à rapprocher summary="" du rôle de alt="" des images ce qui est absolument faux.

a écrit :
Liens

Les moteurs de recherche usuels tiennent compte de l'intitulé des liens qui pointent vers une page donnée, dans le calcul du rang de cette dernière en réponse à une requête. Il y a donc lieu de donner aux liens des intitulés les plus explicites possibles sur leur destination.


Peut-être préciser que pour les liens en image, le title du lien est indispensable pour la compréhension du lien par les aides techniques même si l'image ell-même possède un attribut alt.

Ce qui replacerais le rôle de title pour les liens à sa destination première son rôle pour les moteurs de recherches n'étant somme toute qu'assez accessoire.

a écrit :
Cadres

Les mises en page à base de cadres peuvent maintenant être délaissées avec profit pour des mises en page à base d'éléments <div>, dont le contenu peut être généré dynamiquement par script.


Je chipote sans doute, mais je supprimerais la référence au div comme substitut des frames, ce qui aura l'immense avantage de ne pas entretenir la confusion très pernicieuse entre frame et div dans l'esprit du néophyte.
Et puis de toute manière il n'y à rien de commun, ni même d'approchant entre un div et une frame.

a écrit :
Mise en valeur

On met en valeur du texte grâce à deux éléments : <em> et <strong>. On rencontre encore ces éléments utilisés pour mettre du texte respectivement en italique ou en gras, alors qu'il ne s'agit là que de la manière dont elles sont traduites par un navigateur graphique, et donc d'un détournement de leur signification. Une mise en valeur est réalisée grâce à l'élément <em> ; si on a besoin d'un niveau d'emphase supplémentaire, on utilise <strong>.


J'aurais juste inversé la définition (une mise en valeur...) et la remarque sur la confusion gras/italique.
D'autre part il existe une sorte de consensus, issue de la spécification HTML 4.01 pour parler "d'emphase" pour em et "d'emphase forte" pour strong.
Ce qui me aprait plus "parlant" que "emphase supplémentaire".
(Dans la spec c'est "mise en exergue" mais bon c'est "emphase" qui semble l'usage).

JP
Modifié par jpv (01 Aug 2005 - 18:09)
En revenant sur la question de la langue, et en relisant du coup ce qui est dit pour l'encodage, je me demande dans quelle mesure ce document sur "les bases du document (X)HTML (finalement), ne devrait-il pas aborder, de manière succinte, le rôle des informations communiquées au navigateur par les en-têtes HTTP.
Accompagnant l'envoi du "HTML" proprement dit, celles-ci sont en effet le premier vecteur (prioritaire), pour :
- la langue primaire
- l'encodage
- le type de contenu (pour mémoire, car il dépasse le cadre de ce document)
- la cachabilité de la page
- les erreurs
- les redirections

Sans faire entrer en compte toutes ces données, celle de l'encodage me semble être la plus importante à ce niveau. Et c'est préparer le terrain du "vrai" XHTML pour lequel l'élément meta... doit être omis Smiley cligne
Miam miam... merci pour tous ces commentaires.

Je ne suis pas, lion s'en faut, fin connaisseur des entêtes HTTP, et je crois que ces considérations débordent du cadre que je m'étais fixé. Néanmoins, je suis d'accord que dans l'absolu, cela serait un complément utile.

En fait, je dois respecter un cadre assez strict, puisque l'ensemble de ces considérations doit être exposable en 3h et demie, à des gens, comme je l'ai dit, à profils très variés. Parler des entêtes HTTP risque de leur passer assez largement au-dessus de la tête Smiley ohwell

Bon, je prends tout ça en note, j'assimile, je corrige... et je resoumets (probablement pas avant mercredi, peut-être demain si j'ai le temps).
Pour la page "Séparation du fond et de la forme"

Peut-être serait-il utile de faire une courte introduction sur le concept de séparation forme/contenu pour expliquer le fondement de cette démarche qui est de rendre le contenu indépendant des périphériques d'affichage.

Dans la formulation que tu emplois on à l'impression que le langage CSS n'est qu'une "autre" manière de faire de la présentation alors qu'il s'agit, pour HTML, de la seule manière de rendre le contenu indépendant de l'affichage.

La séparation forme/contenu est la pierre angulaire des langages standards et du travail du W3C, je trouve dommage de le passer sous silence et de le fondre dans le seul aspect "CSS".

JP
Modifié par jpv (01 Aug 2005 - 18:33)
jpv a écrit :
La séparation forme/contenu est la pierre angulaire des langages standards et du travail du W3C, je trouve dommage de le passer sous silence et de le fondre dans le seul aspect "CSS".


Je ne le passe pas sous silence (en tous cas, d'après mes notes préparatoires, je devais en parler au début Smiley rolleyes ). Je vais y faire attention, merci. Smiley smile
a écrit :
le JavaScript ne doit être utilisé que pour coder des fonctionnalités additionnelles de la page. On doit limiter l'utilisation du JavaScript à des « gadgets », qui améliorent l'ergonomie ou l'apparence pour les utilisateurs disposant de JavaScript, mais dont la désactivation ne gêne pas l'accès à l'information de la page


Allez une petite dernière :
Parler de limiter l'usage de javascript à des "gadgets" de la part de l'auteur de ce monument de pédagogie : Cours de manipulation du DOM et DHTML, qui m'à fait gagner des années lumières sur la conception javascripté non obstrusive me semble bien cruel... Smiley cligne
Il est vrai qu'il est d'usage de dire ça, en même temps tu sais tout comme moi qu'un dipositif javascript non obstrusif et bien conçus peut rendre de grand service.
La pré-validation d'un formulaire par un dispositif javascript en économisant le rechargement de la page simplement parce que des champs obligatoires ne sont pas remplis est tout sauf un "gadget"...

JP
salut gilles,

J'ai parcouru le document et je n'ai pas remarqué que tu parlais de l'importance du flux dans une page html ou de la linéarisation d'une page.

Outre l'importance du balisage "sémantique" et de la séparation contenu mise en forme penser également à l'organisation de sa page et de son flux est une bonne chose.Même sans entrer dans les détails des float et autre absolute cela peut être interessant dans une optique plus lointaine d'accessibilité.
Modifié par knarf (01 Aug 2005 - 19:53)
Sujet clos
Aller à