5546 sujets

Sémantique web et HTML

Pages :
(reprise du message précédent)

Merci Quentin de te passionner pour ce problème.... bien plus que je ne je fais moi même
J'ai simplement, en début de ce fil, demandé si quelqu'un pouvait me fournir de l'info sur ce qui se faisait dans le domaine des balises personnalisées. Je ne m'attendais pas à tant de passion pour... pour quoi en fait?

Que les balises aient perdu tout sens, pour autant qu'elles en aient jamais eu, c'est une constatation qu'on peut faire tous les jours, il suffit de faire Ctrl-U sur les pages que l'on trouve sur internet. La fait que l'on utilise de plus en plus le CSS (qui, je le rappelle, n'est arrivé que beaucoup plus tard) ne fait que vider de sens les balises courantes.
En inventer de nouvelles comme on a fait en HTML 5 ne me semble pas avoir apporté plus de clarté.

Il faut bien comprendre que j'ai démarré au tout début, on faisait ce qu'on pouvait avec ce qu'on avait sous la main. Dans les années 90 utiliser des balises <h1> donnait un rendu visuel horrible, ét on ne savait pas comment faire mieux, sauf à utiliser d'autres balises pour obtenir la présentation qu'on voulait. Après, on prend des habitudes...

En ce qui me concerne, 7 ans après avoir pris ma retraite et utilisé un peu de mon temps pour faire des sites pour des associations le des amis indépendants, j'ai voulu regarder comment ça avait évolué. Comme ce site me semblait assez bien fait et qu'on y trouvait des infos intéressantes, je m'y suis inscrit l'an denier et je ne regrette pas, car la solitude n'est pas un moyen de progresser, et je préfère les discussions qui ont lieu sur ce site â ce que j'ai pu trouver ailleurs., en particulier la dogma de Google.

Parmi les choses que j'ai prises en compte après avoir consulté ce site, je citerai, dans le désordre, le passage à HTML5 et CSS3, une meilleure prise en compte de l'UTF-8, et plus récemment l'utilisation de jQuery et des média queries. En quelques mois., je trouve que c'est déjà une moisson intéressante. Je suis donc toujours curieux de poursuivre l'exploration des terres nouvelles et de savoir ce qu'elles nous proposent comme flore et faune inconnue.

Je demande simplement qu'on ne tente pas de me convertir â quelque religion que ce soit. Les événements récents nous confirment que l'observation du réel, la rationalité et le doute philosophique sont les seules clartés qui peuvent nous guider dans la recherche jamais terminée d'une méthode de travail et de pensée constructive.
Pardon de débarquer comme un cheveu sur la garbure, mais je pense qu'au delà d'une tentative de "conversion à", il s'agit d'avantage d'un dialogue relatif à l'accessibilité, dialogue enrichi par l'intervention de quelqu'un ayant chaque jour un besoin crucial de cette accessibilité là.
Moi personnellement, et sans vouloir faire de distinguo péjoratif, je lis souvent les commentaires de QuentinC avec intérêt car je sais pertinemment que jamais je ne pourrai me mettre à sa place et profite donc de ses conseils avertis que je m'emplois ensuite à tenter de respecter dans mes réalisations.
Parce que moi aussi j'ai NVDA installé sur mon ordi, mais l'expérience est faussée par de nombreux paramètres dont deux importants se trouvant juste au dessus de mon nez.

Cordialement,

Smiley smile
Modifié par Manhattan (02 Mar 2015 - 08:16)
Hello,
PapyJP a écrit :
Il faut bien comprendre que j'ai démarré au tout début, on faisait ce qu'on pouvait avec ce qu'on avait sous la main. Dans les années 90 utiliser des balises <h1> donnait un rendu visuel horrible, ét on ne savait pas comment faire mieux, sauf à utiliser d'autres balises pour obtenir la présentation qu'on voulait. Après, on prend des habitudes...

Oui ben ces habitudes n'ont aucun sens, aucune utilité, sont même néfaste pour le visiteur de ton site. Moi aussi j'ai commencer à coder du HTML dans les années 90. C'est pour ça que ça justifierait d'en rester là ?
PapyJP a écrit :
Il faut bien comprendre que j'ai démarré au tout début […] Je demande simplement qu'on ne tente pas de me convertir â quelque religion que ce soit.

On a bien compris qu'une partie de tes connaissances en la matière datent du début du web, avant la mise en place de CSS, de standards dignes de ce nom et des démarches qualité et référentiels d'accessibilité actuels. Tu le répète à longueur de fil de discussion…

Maintenant faudrait aussi que t'arrête un peu aussi de répondre à tes interlocuteurs en avançant leurs dogmes et/ou religion comme un ado qui refuse de commencer par apprendre les bases avant de révolutionner le monde. Ça en devient insultant.
@Manhattan:
Merci pour cette remarque de bon sens.
Je suis moi aussi très intéressé par les remarques de Quentin. Le web pour malvoyants est un domaine tout â fait nouveau pour moi, et je n'avais jusque ces derniers jours qu'une idée très floue sur ce ce qu'est un lecteur d'écran. Si j'ai bien compris NVDA ne semble pas regarder de près le contenu des pages HTML, alors que c'est le contraire pour JAWS.

Pour les autres points, je continue à penser que ce que j'appelle les balises de présentation ont fait leur temps, puisqu'on peut â peu près styler n'importe quoi n'importe comment: il y a en permanence conflit entre les balises et le CSS.
Sans avoir passé le temps nécessaire à étudier les choses en détail, je dirais qu'à l'intérieur de <body></body> on pourrait s'en tirer avec une seule balise, appelons la <smurf>... ou <div> si vous préférez. En la stylant correctement et en utilisant l'attribut "onclick" on doit pouvoir répondre â tous les besoins. Sachant qu'il faut déjà avoir un œil sur le CSS et un autre sur le HTML (et un troisième œil sur le JS) pour comprendre comment fonctionne une page web, ça ne changerait pas grand chose. Si on y met les informations dites "micoformats" qui, elles, balisent réellement le contenu avec du sens (c'est â dire "sémantique") on arrive à une approche qui me semble intéressante â prendre en compte.

Si je parle de "religion" c'est que j'ai l'impression d'aborder le domaine des certitudes et des croyances plutôt que celui d'une techno quand je me demande simplement si ce n'est pas la terre qui tourne autour du soleil plutôt que le contraire. Cela m'effraie un peu, d'autant que j'ai eu l'honneur de contribuer dans une faible mesure à l'élaboration de ces technos et que j'ai vécu de l'intérieur la façon dont ces choses naissent, se développent et meurent.
Je ne compte plus le nombre de grands principes qui sont maintenant oubliés après avoir coûté des millions de dollars en R&D et colloques de tous genre. Qui s'intéresse aujourd'hui au "modèle ISO" des transmissions de données? Et pourtant je ne sais pas combien d'heures j'ai consacrées à batailler sur cette norme et quelques autres. Ce n'a pas été du temps perdu, ça a fait progresser les idées, mais ça relativise les choses.
a écrit :
Si j'ai bien compris NVDA ne semble pas regarder de près le contenu des pages HTML, alors que c'est le contraire pour JAWS.


Non. En fait NVDA respecte beaucoup plus les standards web que jaws.
En ce qui concerne le problème de display que j'expliquais dans un de mes posts précédents sur ce fil, c'est clairement ça.

Ce n'est pas nouveau, ça fait déjà quelqeus années que le requin a pris ses distances vis-à-vis des standards et que c'est, à certains égards, agaçant.
Malheureusement quelque part je suis comme toi, très conservateur. J'ai commencé avec jaws il y a une douzaine d'années, et du coup j'y reste... je n'arrive pas à me mettre à NVDA, et encore moins à VoiceOver ou Orca.

a écrit :
Pour les autres points, je continue à penser que ce que j'appelle les balises de présentation ont fait leur temps, puisqu'on peut â peu près styler n'importe quoi n'importe comment: il y a en permanence conflit entre les balises et le CSS.


Les balises qui existaient jadis telles que <font> et <center> n'ont pas à figurer dans une page HTML, car elles décrivent une présentation spécifique au média screen et non quelque chose qui fait sens en général.

IL n'y a pas de conflit. En HTML on décrit la structure logique du document, alors qu'en CSS on décrit comment cette structure logique sera présentée à l'utilisateur.

J'ai l'impression que tu confonds certaines choses: pour toi, <h1> est une balise de présentation ?
Et je répète les questions précédentes auxquelles tu n'as pas répondu :
a écrit :

Quelles balises juges-tu encombrantes ?
Et pour toi, qu'est-ce que la base ?


a écrit :
Sans avoir passé le temps nécessaire à étudier les choses en détail, je dirais qu'à l'intérieur de <body></body> on pourrait s'en tirer avec une seule balise, appelons la <smurf>... ou <div> si vous préférez. En la stylant correctement et en utilisant l'attribut "onclick" on doit pouvoir répondre â tous les besoins.


IL y a certains sites qui ne sont pas très loin de ce que tu décris.
Mais ceux qui font ça n'ont rien compris à ce que ça apporte, non seulement en accessibilité, mais aussi en lisibilité du code, maintenabilité et référencement.

a écrit :
Je ne compte plus le nombre de grands principes qui sont maintenant oubliés après avoir coûté des millions de dollars en R&D et colloques de tous genre. Qui s'intéresse aujourd'hui au "modèle ISO" des transmissions de données? Et pourtant je ne sais pas combien d'heures j'ai consacrées à batailler sur cette norme et quelques autres. Ce n'a pas été du temps perdu, ça a fait progresser les idées, mais ça relativise les choses.


Si tu parles des 7 couches réseau du modèle ISO, aux dernières nouvelles c'est toujours enseigné en classe, dans les cours théoriques sur le réseau. En tout cas en ce qui me concerne j'y ai eu droit.
Le truc c'est que c'est de la belle théorie, mais en pratique ça ne sert pas à grand chose: c'est pas tout le monde qui a le privilège ou le devoir d'inventer de nouveaux protocoles ou d'en adapter des existants aujourd'hui.
Bonsoir Quentin

Je suis désolé, je pense que tu prends comme vérités universelles des choses qui ne sont que la photo instantanée de l'état de réflexion de certaines personnes. Cela fait près de 50 ans, j'écrivais mon premier programme informatiques, et il y avait déjà à l'époque des grandes discussions de ce genre sur des domaines dont la plupart sont complètement disparu.

Il est curieux de voir comme le monde des ingénieurs, dont la vocation est de trouver des solutions faisables â l'instant T â tendance à dériver vers la recherche, dont la vocation est de remettre inlassablement en cause un modèle de l'univers, et finalement vers la métaphysique, cest â dire la croyance dans des vérités universelles, révélées par un etre suprême a un groupe d'élus.

J'ai posé une question bête à propos d'un point du standard du jour qui avait apparemment échappé à l'attention de la plupart des gens (dont moi même jusqu'à ces derniers jours). Je ne comprends même pas comment et vers quoi cette discussion a dérivé.

J'ai l'impression que nous tournons en rond, et je propose que nous en restions là sur ce sujet précis, ce qui ne nous interdit pas de continuer de discuter sur d'autres points, sur lesquels j'espère que nous parviendrons davantage â nourrir mutuellement nos réflexions.
Je marque donc ce sujet comme "résolu", ce qui est un peu exagéré car nous n'avons trouvé que 3 URL sur le sjet, en comptant le site du W3C, mais je ne vois pas dans quelle(s) direction(s) nous pourrions progresser.

Bonne nuit
a écrit :
Il est curieux de voir comme le monde des ingénieurs, dont la vocation est de trouver des solutions faisables â l'instant T â tendance à dériver vers la recherche, dont la vocation est de remettre inlassablement en cause un modèle de l'univers, et finalement vers la métaphysique, cest â dire la croyance dans des vérités universelles, révélées par un etre suprême a un groupe d'élus.


Le boulot d'un ingénieur, il me semble que c'est aussi en partie chercher comment améliorer une solution déjà existante. D'autres ajouteront pour rire qu'en plus en informatique, on cherche des solutions à des problèmes que les autres n'ont pas, ou qu'on passe 10 ans à économiser 10 millisecondes.
Toujours est-il que si personne n'avait jamais rien remis en cause, on serait sûrement encore en train de casser des cailloux autour d'un feu.

a écrit :
Je suis désolé, je pense que tu prends comme vérités universelles des choses qui ne sont que la photo instantanée de l'état de réflexion de certaines personnes. Cela fait près de 50 ans, j'écrivais mon premier programme informatiques, et il y avait déjà à l'époque des grandes discussions de ce genre sur des domaines dont la plupart sont complètement disparu.


En même temps c'est probablement normal. Je vis avec les technologies et les connaissances de mon temps.
Je discute et je spécule sur ce que je sais et ce que je pense savoir; je ne peux pas discuter de ce que je ne connais pas ni de ce qui n'a pas encore été inventé.

Quant à ceci: la croyance dans des vérités universelles, révélées par un etre suprême a un groupe d'élus, c'est plus ou moins la définition de la religion.

a écrit :
J'ai l'impression que nous tournons en rond, et je propose que nous en restions là sur ce sujet précis, ce qui ne nous interdit pas de continuer de discuter sur d'autres points, sur lesquels j'espère que nous parviendrons davantage â nourrir mutuellement nos réflexions.


Il est effectivement temps qu'on mette un terme à cette discussion, on se rapproche gentiment du point godwin.
Modérateur
Malgré tout j'aimerais quand même préciser quelques points.

La norme des custom-tags poursuit deux objectifs:
1) permettre l'implémentation de balises personnalisées avec une vraie présence dans le dom, son API, proriétés, méthodes etc.
2) Permettre de mettre en place une manière générique et normalisée de décrire un élément HTML, afin de redéfinir les éléments HTML du standard eux-mêmes par cette norme. (Et y inclure svg et MathMl mar la même occasion). Une norme de la norme en gros.

Si le point 2 est louable et intéressant, je ne suis pas sûr que ce soit possible sans en faire un monstre indomptable. À voir donc. Pour le point 1, qui est au cœur de cette discussion, je souhaite préciser certains points:

Le but n'est pas vraiment de remplacer les balises de la norme HTML par d'autres, mais plutôt de remplir des cases manquantes de la norme. Définir ainsi une nouvelle balise, définir ses attributs du DOM, ses méthodes, permet de faire de vrais éléments avec lesquels le navigateur ou tout autre système seront plus à même d’interagir. La norme n'en est qu'au stade de brouillon, mais, à terme et dans l'idéal, ces éléments et sous éléments pourront recevoir des rôles ARIA par défaut, des flags adaptés à leur utilité, etc.

Pour aller dans le concret, l'idée est plutôt d'implémenter une balise pour remplacer une soupe de div tels qu'utilisés actuellement dans certains cas. Par exemple Google travaille sur la balise <google-map>. Concernant l'accessibilité et la compréhension d'une carte Google sur une page par un système automatisé, dans le pire des cas ça équivaudra à une div, ce qui est le cas actuellement. Par contre en fournissant une norme et une API, il sera bien plus simple de créer des interactions avec le navigateur ou un système d'aide.

Par contre cela nécessite un vrai boulot d'analyse, de réflexion, de tests, pour une seule balise.

Si le but est juste de renommer des <div> en <building>, <cat>, <apple>, cette norme est inutile. Il suffit d'insérer ces balises dans le DOM et l'affaire est réglée (à l'instar de l'HTML5shim). L’intérêt est lui aussi très limité, en terme de sémantique <building> ne serait en rien différent de <div class="building">, à savoir sémantique, mais tiré d'un dictionnaire personnel non normé. De la sémantique destinée à la compréhension humaine lors de la lecture du code, sans plus. (Ce qui reste pratique pour la maintenance)

Si c'est pour remplacer <h1> par <main-title>, ou <a> par <external-link>, la perte est énorme. En matière de sémantique pour le premier, et de sémantique de d'interaction pour le second. Bien entendu, on peu implémenter l'évènement click, mais aucun navigateur/robot/assistant ne pourra savoir que c'est un lien, et ainsi agir intelligemment (fini enregistrer la cible du lien sous, ouvrir dans une nouvelle fenêtre, copier l'adresse, etc.). Les seules fonctionnalités disponibles seront celles que le développeur a bien voulu implémenter, et il n'y aura aucune homogénéité dans ces implémentations.

Avec les custom tags, l'idée est de pouvoir créer par contre un élément <external-link> qui hérite de <a>, il sera dès lors possible pour un parser de savoir que <external-link> peut être traité comme un lien, avec des fonctionnalités supplémentaires dont il ignore peut-être la fonction. Peu importe, il aura son attribut href et sera content avec. Mais tout cela est de la musique d'avenir, il faut rapeller que la norme en est au stade du brouillon, que seuls Chrome et Opéra sont compatibles, et que les autres parsers sont loin de l'être. On peut s'y intéresser et faire joujou avec, mais il faudra des années avant que cela puisse devenir une réalité pratique.
@kustolovic
Je suis assez d'accord avec ce point de vue.
Comme je l'ai dit plus haut, si je n'étais pas si vieux, je serais impatient de voir ce que la jeune génération d'ingénieurs va en faire...

Pour le reste, si on regarde un peu les balises actuelles et qu'on se demande à quoi elles servent, je reste sur l'idée qu'elles servent
- en premier lieu à accélérer l'écriture il est plus rapide d'écrire <h1> que <title level="1">, même s'il faut systématiquement le styler parce que le style par défaut est totalement ringard et fait pour des écrans qui n'avaient pas la même définition que ceux d'aujourd'hui quand on a défini ces balises (vers 1990)
- en second à se faire reconnaitre par son odeur (comme les toutous Smiley cligne ) par les renifleurs

Pour le reste, je crois que d'avoir utilisé le terme "document" pour décrire une page Web est une erreur de compréhension. C'est bien entendu cohérent avec l'inflation ("hype") des concepts dans les labos US. Je ne crois pas que dans mon passé de directeur de recherche j'aurais laissé dériver das cette direction.
Quand je fais un "document" sous Word ou OpenOffice, je pense chapitres, paragraphes, titres, sous titres, illustrations, etc.
Quand je fais une "présentation" sous PowerPoint ou assimilé, je pense en terme de lisibilité des informations à l'écran, l'ordre dans lequel je les fais apparaître, disparaitre, se modifier, etc. toutes choses qu'on n'a jamais vu faire sur un "document" au sens propre.
Quand je pense page Web, je suis plutôt en mode Powerpoint que Word. La description de cette page sous le nom de "document" n'est pas appropriée, et je suis convaincu que cette erreur de vocabulaire nous fait sortir de la route.

A quand un "Slide Object Model"?
Mais peut être y en a-t-il déjà un quelque part? Je vais chercher...
PapyJP a écrit :
Bonjour
Je recherche un tutoriel sur les balises personnalisées en HTML5.
.....


En fait, c'est du XML. HTML n'étant qu'une variante "figée" de XML.

XML exige plus de rigueur. Toute balise ouverte doit être fermée ou auto-fermante:

<livre>......</livre>


entre ces deux balises qu'on défini soi-même, on y met ce qu'on veut:

<livre>
  <resume>....résumé en dos de couverture....</resume>
  <index>
    <item>Chapitre 1 : ma vie....</item>
  </index>
</livre>


Il est évident que ces nouveaux éléments "maison" n'ayant aucun style pré-défini dans HTML5 ou HTML, ils n'auront aucune mise en forme. A vous de les décrire dans le CSS qui va bien.

Il existe un certain nombre de structures XML prédéfinies et standardisées:
- matML http://fr.wikipedia.org/wiki/MathML pour décrire les formules mathématiques
- MusicXML http://fr.wikipedia.org/wiki/MusicXML pour décrire les partitions musicales
- VoiceXML http://fr.wikipedia.org/wiki/VoiceXML si vous voulez monter un serveur vocal....
- DocBook http://fr.wikipedia.org/wiki/DocBook qui décrit la structure et le contenu de livres. Ce standard DocBook a été initié par "O'Reilly".
- WSDL: grammaire décrivant les données échangées en protocole SOAP....

Pour en revenir au HTML5, si on utilise des balises personnelles, on sort du standard HTML5 pour entrer dans le standard XML.

Ainsi, dans cette page: http://jeanpierre.moularde.free.fr/test/custom-tags-2.html

on trouve en première ligne:

<!DOCTYPE html>


Pour être "dans les clous", il faudrait remplacer par:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">


Pour en revenir à la question initiale, une fois qu'on a compris les exigences du XML, il suffit de trouver un tutoriel sur le langage XML.

A+
Modifié par mpmp93 (03 Mar 2015 - 19:39)
PapyJP a écrit :
Pour le reste, si on regarde un peu les balises actuelles et qu'on se demande à quoi elles servent, je reste sur l'idée qu'elles servent
- en premier lieu à accélérer l'écriture il est plus rapide d'écrire &lt;h1&gt; que &lt;title level="1"&gt;, même s'il faut systématiquement le styler parce que le style par défaut est totalement ringard et fait pour des écrans qui n'avaient pas la même définition que ceux d'aujourd'hui quand on a défini ces balises (vers 1990)
- en second à se faire reconnaitre par son odeur (comme les toutous Smiley cligne ) par les renifleurs

Tu te trompe.
La raison 1), c'est depuis le départ pour structurer un document en lui donnant un titre que l'on considère comme le premier de la hiérarchie de titres du document.

PapyJP a écrit :
Pour le reste, je crois que d'avoir utilisé le terme "document" pour décrire une page Web est une erreur de compréhension. C'est bien entendu cohérent avec l'inflation ("hype") des concepts dans les labos US. Je ne crois pas que dans mon passé de directeur de recherche j'aurais laissé dériver das cette direction.

Et voilà, le blabla revient… doucement avec les chevilles.
PapyJP a écrit :
Quand je fais un "document" sous Word ou OpenOffice, je pense chapitres, paragraphes, titres, sous titres, illustrations, etc.
Quand je fais une "présentation" sous PowerPoint ou assimilé, je pense en terme de lisibilité des informations à l'écran, l'ordre dans lequel je les fais apparaître, disparaitre, se modifier, etc. toutes choses qu'on n'a jamais vu faire sur un "document" au sens propre.
Quand je pense page Web, je suis plutôt en mode Powerpoint que Word. La description de cette page sous le nom de "document" n'est pas appropriée, et je suis convaincu que cette erreur de vocabulaire nous fait sortir de la route.

Ben justement, c'est tout le problème : tu ne pense que présentation là où tu devrais plutôt –si tu souhaite te placer dans un contexte de bonnes pratiques, d'intéropérabilité et de standards, ce qui constitue par ailleurs la thématique de fond du forum Alsacréations en général– normalement penser document. C'est pas la peine de nous rabattre encore et encore les oreilles avec ton passé professionnel Smiley ohwell
Modérateur
mpmp93 a écrit :

En fait, c'est du XML. HTML n'étant qu'une variante "figée" de XML.

Les custom elements, ( http://www.w3.org/TR/custom-elements/ ) ça n'a rien à voir avec le XML. Le HTML n'est pas du XML.
Le seul point commun, est d'être une tentative de standardisation et de norme descriptive, après l'échec du XML en ce sens justement.
l'XHTML quant à lui, est une norme qui a été abandonnée (aux nouveaux développements) par le w3c, en faveur du HTML5
a écrit :
2) Permettre de mettre en place une manière générique et normalisée de décrire un élément HTML, afin de redéfinir les éléments HTML du standard eux-mêmes par cette norme. (Et y inclure svg et MathMl mar la même occasion). Une norme de la norme en gros.


En fait, c'est surtout cet aspect qui risque d'être intéressant.
Dans le cadre des navigateurs, l'inclusion de SVG c'est déjà fait; MathML ça commence; il va rester CML pour la chimie, un autre pour les partitions de musique, encore un pour la 3D (VML?), et d'autres encore...

Le plus gros morceau que j'aiemrais bien voir apparaître dans les langages XML dédiés à des applications spécifiques de cet acabi, c'est un langage permettant de décrire des diagrammes, organigrammes, main mapping, etc.
Un truc qui permettrait aussi bien de faire de l'UML que des cartes euristiques ou de la description de processus (arbre de décision), en passant par la présentation de la hiérarchie d'une entreprise/organisation ou des arbres généalogiques.

a écrit :
Pour aller dans le concret, l'idée est plutôt d'implémenter une balise pour remplacer une soupe de div tels qu'utilisés actuellement dans certains cas. Par exemple Google travaille sur la balise <google-map>. Concernant l'accessibilité et la compréhension d'une carte Google sur une page par un système automatisé, dans le pire des cas ça équivaudra à une div, ce qui est le cas actuellement. Par contre en fournissant une norme et une API, il sera bien plus simple de créer des interactions avec le navigateur ou un système d'aide.


C'est ici que le point n°1 indiqué dans un post précédent commence d'être intéressant.
En espérant juste que ceux qui iront dans ce sens le feront correctement, en prenant en compte la'ccessibilité.

a écrit :
Quand je fais un "document" sous Word ou OpenOffice, je pense chapitres, paragraphes, titres, sous titres, illustrations, etc.
Quand je fais une "présentation" sous PowerPoint ou assimilé, je pense en terme de lisibilité des informations à l'écran, l'ordre dans lequel je les fais apparaître, disparaitre, se modifier, etc. toutes choses qu'on n'a jamais vu faire sur un "document" au sens propre.
Quand je pense page Web, je suis plutôt en mode Powerpoint que Word.


D'après moi, grosse erreur.

En ce qui concerne les présentations type PowerPoint, il y a tout autant de règles sémantiques à respecter si tu veux faire les choses correctement :
chaque diapositive doit avoir un titre, et de la même façon tu as des paragraphes, des sous-titres, des listes, des illustrations. Je ne vois pas où est la diffférence. Le document est seulement découpé différemment.

Ce que tu fais apparaître ou disparaître, c'est juste une question d'animation et de transition.
Par exemple, c'est un non sens de copier-coller 12 fois la même diapositive avec à chaque fois un point en plus simplement pour que chaque point apparaisse l'un après l'autre quand tu cliques.

a écrit :
La description de cette page sous le nom de "document" n'est pas appropriée, et je suis convaincu que cette erreur de vocabulaire nous fait sortir de la route.


Et pourtant, fondamentalement, 99.99% des pages web sont bien des documents, au même titre que des DOC(X), des ODT ou des PDF.
D'ailleurs, si on y regarde de plus près et si on fait abstraction des différentes façons de nommer les choses, les bases sémantiques sont plus ou moins les mêmes (avec plus ou moins de richesse et de limitations), et les stratégies à mettre en jeu pour rendre accessible des documents dans ces différents formats aussi.

Là où tu as le droit de douter, c'est les 0.01% restants, les one page application si je prends un gros raccourci.
Là, c'est les codes généraux des GUI natives qu'il s'agit de respecter et non plus ceux des documents, et c'est effectivement complètement différent.

La limite est parfois extrêmement mince, mais la plupart des pages web qui prétentent être des applications n'en sont pas réellement.
Ce qui est sûr, c'est que la simple présence d'un widget interactif, d'un formulaire, d'une iframe ou d'une vidéo n'est pas suffisante pour trancher définitivement.

Tu devrais peut-être jeter un oeuil à epub3, just que tu voies en quoi ça consiste. Je pense qu'avec epub3 tu ne devrais plus avoir de doute qu'en règle générale une page web est à penser en premier lieu comme un document, sauf exceptions très très particulières.
Et même au-delà de ça, c'est une lecture instructive qui n'est pas si éloignée du web, puisqu'on place toujours HTML5, CSS3 et javascript au centre.
SolidSnake a écrit :
Après j'ai une question de fond existentielle, peut-on encore vraiment appeler ça de l'HTML5 ?


Avant ça s'appelait xhtml, mais la mode à changé de numéro de version.
pour moi aucun doute que les balises personnalisées sont un plus indispensable pour la bonne lecture du code , peu importe les tag deja existant

j'aime utiliser

<menu>
<menu-item>accueil</menu-item>
</menu>


ou une balise specifique flex box

<flex data-direction="horizontal" data-wrap="no-wrap">
<flex-item  data-order="1">accueil</flex-item>
</flex>


tellement plus intéressant
Modifié par plumex (13 Mar 2015 - 10:20)
@plumex: si ton premier exemple paraît intéressant, ton deuxième est justement le genre de dérive à éviter: ça me paraît être un genre de <font> 2.0
QuentinC a écrit :
@plumex: si ton premier exemple paraît intéressant, ton deuxième est justement le genre de dérive à éviter: ça me paraît être un genre de &lt;font&gt; 2.0


pour quelle raison l'éviter et pourquoi ce serait une derive ?
il y a bien un table qui est un display table, un flex display

l'ideal serait un HTML5 qui permette a chacun sa propre syntaxe avec un minimum de regles etablies
a écrit :
pour quelle raison l'éviter et pourquoi ce serait une derive ?
il y a bien un table qui est un display table, un flex display


Sauf que <table> c'est pas pareil, si tu l'utilises correctement, ça a une valeur sémantique importante et indépendante de la représentation: ça permet de structurer des données tabulaires, et les données tabulaires se lisent d'une façon différente du reste ordinaire.

Ton flex là ça représente quoi pour moi qui suis non-voyant et qui lit avec une synthèse vocale et/ou une plage braille ? Rien. C'est juste une question de représentation graphique attachée au seul média screen.
Tu veux faire du groupage pour des besoins spécifiques de mise en forme pour un média bien particulier et seulement celui-là ? pas besoin d'inventer des nouvelles balises pour ça, il y a déjà <div>.

A ce rythme, on va bientôt voir arriver des sites en SVG uniquement !

Quant à display:table, c'est juste une directive CSS pour indiquer que tu veux que le contenu soit affiché un peu comme un tableau, sans que ce soit des données tabulaires pour autant.
Mais si tu utilises display:table avec un ramassis de <div> pour afficher des données qui devraient l'être avec <table>, c'est tout autant dommageable (plein de sites font cet erreur aujourd'hui).

a écrit :
l'ideal serait un HTML5 qui permette a chacun sa propre syntaxe avec un minimum de regles etablies


Ca existe, ça s'appelle XMl+XSL et éventuellement XSLT.
Modifié par QuentinC (15 Mar 2015 - 18:28)
Pages :