Journal #spaghettis xhtml standard, sauce javascript

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
-16
26
mai
2017

Sommaire

Afin d'illustrer les articles précédant cette chronique sur l'accessibilité du web,
.#REM on saura peut-être faire le café et pas vous ficher dehors
http://linuxfr.org/users/patrick32/journaux/rem-on-saura-peut-etre-faire-le-cafe-et-pas-vous-ficher-dehors
.# et pour ceux qui l'auraient loupé… CSS and JavaScript are accessible?
http://linuxfr.org/users/patrick32/journaux/et-pour-ceux-qui-l-auraient-loupe-css-and-javascript-are-accessible

à l'occasion du "Codefest Toulouse 2017"
https://www.facebook.com/events/883207281810970/

je vous propose de vous attarder sur l'analyse d'une page officielle prise au hasard,
et de constater :
- l'affichage des standards
- le non respect des standards
- la quantité d'information brute (entité)
- la qualité d'informations additionnelles (dynamiques)
- le coût matériel et en accessibilité de l'addition d'informations applicatives
(par applicatives, je compare au téléchargement d'une application)
- l'intérêt de technologies permettant de faciliter la différenciation de ces contenus, afin de permettre le développement d'applicatifs "sur-mesure" (custom), tourné vers l'utilisateur, et pouvant partir de l'utilisateur,
étant donné la capacité aujourd'hui à influer sur l'applicatif, et la facilité de par exemple appliquer un XSL (modèle) sur un XML (donnée), les modèles pouvant se diffuser et s'appliquer à differents cas de figure, tel ceux facilitant l'accessibilité au contenu et la mise en production d'individus aujourd'hui encore tenus à l'écart de l'économie.

DOCTYPE

<!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" lang="en">

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
http://www.w3.org/1999/xhtml

On y retrouve la référence au langage utilisé sur la page, permettant éventuellement de valider la page avec un outil de validation, qui fonctionne un peu comme un outil de correction orthographique.
http://validator.w3.org
On remarque que la spécification xhtml choisie date de 1999…

entête

<head>

L'entête contient essentiellement du javascript greffé à la page, pourtant qui ne devrait apporter aucune information brute.
74 lignes

wc 20170525_headscripts.txt 
  74  178 4566 20170525_headscripts.txt

sur un total de 

wc 20170525_head.txt 
  98  269 5721 20170525_head.txt

soit près de 70%, de surcroît incompatible avec la norme XHTML choisie, les codes javascript ne devant apparaître que sous forme de références externes.

On y retrouve les meta, métadonnées indiquant l'encodage du texte avec lequel est écrit le code html de la page, un commentaire indiquant déjà une contrainte (enforce) limitant l'accès des données, puis enfin des métadonnées concernant une application commerciale précise, dont aucune autre ne devrait avoir d'utilité (usefull).

(lignes 8 à 12)

  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <!-- force latest IE rendering engine  & Chrome Frame -->
  <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />
  <meta name="viewport" content="initial-scale=1.0" />
  <meta name="apple-itunes-app" content="app-id=593468235"/>

Le titre (indispensable, et encodé avec des entités), un lien vers l’icône relatif à la page, un lien relatif à un icône d'un autre standard, puis la référence externe à la feuille de style CSS, tel qu'aurait du l'être le javascript.
(ligne 14 et 17)

  <title> Pope Francis: &quot;Mercy Friday&quot; visit to Ostia housing project </title>
  <link rel="shortcut icon" href="/static/portal/img/favicon.ico" />
  <link rel="apple-touch-icon" href="/apple-touch-icon.png" />
  <link rel="stylesheet" href="/static/CACHE/css/b25c40b2d4fd.css" type="text/css" media="all" /><link rel="stylesheet" href="/static/CACHE/css/99cc12c4c890.css" type="text/css" media="print" />

Arrive une floppée de scripts indigestes pour un validateur, et plus encore pour un outils de transformation, tel un Google Translate qui lit plusieurs langues à la fois, parfois mal orthographiées.
http://translate.google.com
Le premier d'entre-eux, s'applique à une exception de la feuille de style, spécifique à une navigateur, ainsi le développeur a du code un code spécifique pour une fraction non standard, n'étant par définition pas pérenne. Généralement ce type de production qui s'apparente à faire le tour du bâtiment en courant, et remonter par l'escalier, est justifié par l'indispensable taille ou police de caractère, ou par la couleur du texte qui serait sans ça légèrement différente. Une oeuvre d'art.
(lignes 18 à 98)

A nouveau deux balises meta, dont la première est redondante à la balise titre ligne 14.
(lignes 100 et 101)

<meta property="og:title" content="Pope Francis: &quot;Mercy Friday&quot; visit to Ostia housing project"/>
<meta property="og:image" content="http://media02.radiovaticana.va/photo/2016/05/14/ANSA1006671_LancioGrande.jpg"/>

Il est remarquable qu'une telle référence ait été spécifiée pour le CSS, car il est rare que le CSS ne vienne polluer l'ensemble des données, pour apporter une couche de présentation indispensable aux données présentées, l'argument étant le plus souvent, que l'information a besoin d'être vue pour exister, ainsi que cela a été indiqué par le courrier des lecteurs lors des précédentes chroniques.

body

Le corps de page, contenant l'information proprement dite, se trouve libérée des codes de style CSS comme la référrence externe contenue dans les entêtes le promettaient, mais on y retrouve à nouveau du code javascript. Généralement issue probable à des contraintes techniques inhérentes à ce langage, ne permettant pas son exécution autrement qu'imbriqué dans les données, cette fois le javascript remplace purement et simplement la données. La donnée est dynamique, exécutée sur le poste du client.
Un code typiquement php, mais qui peut s'écrire en tout langages, même en C ou assembleur, exécuté sur le serveur, aurait permis l'envoi de données lisibles et transformables.
Il est parfois volontaire de rendre le code illisible, tel qu'on peut imaginer à lire celui des pages distribuées par Facebook, dont le but est de restreindre la réutilisation des données affichées, et de canaliser ces flux par une API fournie, comme twitter et d'autres en mettent à disposition. Ce ne semble pas être le cas de cette page.
Un code dynamique peut être écrit et exécuté sur le serveur, servi par un cache qui évite de refaire les opérations, dans la mesure où ce code n'est pas une application autonome, mais bien une page de données, dont le fond (la donnée) peut être séparé de la forme (tout ce qui s'ajoute à la donnée).
Nous avons ainsi affaire à une réelle application, avec un code qui s'exécute sur le poste du client, une application hybride dont une partie est contenue en ligne, une autre transportée sur le poste du client. Les pages de Twitter et Facebook exploitent ces modèles afin de mettre à jour en permanence la page du client sans la recharger, et donc avec un flux continu de données.
Ce qui ne semble pas être le cas de cette page.

L'information se situe lignes 291 à 308.

    <p style="margin:0">2017-05-19 Vatican Radio</p>

    <img align="left" alt="" hspace="5" src="http://media02.radiovaticana.va/photo/2016/05/14/ANSA1006671_LancioGrande.jpg" title=""/> <p>(Vatican Radio) Pope Francis is continuing his “Mercy Friday” activities. Begun during the 2015-1016 Extraordinary Jubilee Year of Mercy, the Mercy Fridays see the Holy Father engaged in specific corporal and spiritual works of mercy.</p>
<p>A communiqué from the Press Office of the Holy See explains that the Pope on this Friday made a visit to public housing projects in the parish of <em>Stella Maris</em> – Star of the Sea parish – in the coastal town of Ostia on the outskirts of Rome.</p>
<p>The communiqué goes on to explain that the Holy Father was to bless the abodes of the parishioners in the complex located at Piazza Francesco Conteduca, 11, just as the parish priest does traditionally each year during Eastertide.</p>
<a href="http://en.radiovaticana.va/news/2017/05/19/pope_francis_mercy_friday_visit_to_ostia_housing_project/1313488">(from Vatican Radio)</a>
  </div>

commentaires

On remarque des commentaires html permettant au développeur de s'y retrouver dans ses spaghettis…

 <!-- bloque general -->

Peut-être la séparation de ces "blocs" donne une idée des fonctionnalités de la page en tant qu'application, où l'externalisation de la majorité des textes et codes auraient pu être possibles, par références externes.
N'étant pas spécialiste en développement Web, je ne saurais me prononcer sur la capacité des standards à supporter de tels applicatifs, et la séparation des contenus.
Il est possible que des raisons évidentes de sécurité qui m'ont échappées, expliquent la quantité de sauce pour entourer l'information spécifique de cette url qui se résume en une image, un titre et une description, le reste n'étant que données contextuelles et applicatifs spécifiques à un contexte prédéfini, parfois limité à quelques navigateurs particuliers ou même versions de ces navigateurs.

A moins que ces commentaires divisant la page entre information complémentaires et information générales, ne soit destinés aux futurs navigateurs capables de distinguer les contenus et de les rendre accessibles,
il reste possible que ces limitations volontaires à l'accès du contenu soient volontaires.

Article saisi avec kwrite, options : retour à la ligne dynamique, correction orthographique en français, coloration syntaxique "marquage" XML.
https://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0ahUKEwj__cnssYvUAhXKXRoKHVS8AZIQFgg4MAM&url=https%3A%2F%2Ffr.wikipedia.org%2Fwiki%2FKWrite&usg=AFQjCNEm3FJcagnlOiWJ-rROBuO--ODQhA&sig2=s6eLk3yzYAS63T49cEH1iQ

  • # typo

    Posté par  . Évalué à -5.

    Spaghetti (pluriel) ne prend pas d'"s" à la fin.

    • [^] # Re: typo

      Posté par  . Évalué à 7.

      Ce n'est pas l'avis de l'académie française.

  • # site fait avec quoi ?

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    Ca n'est pas une excuse pour faire du non accessible, mais as-tu regardé avec quel outil ces pages sont générées ? Génère-t'il des pages accessibles et bien faites ? (encore une fois, ce n'est pas une excuse, mais ça peut expliquer des choses)

    Soit je suis bigleux, soit tu n'as pas précisé la page analysée, tu as juste employé le terme "officiel", ce qui laisse à penser qu'il s'agit d'une page xxx.gouv.fr Après, les liens que tu donnes contiennent du vatican.va, du coup j'ai comme un doute que ce soit du gouv.fr

  • # .

    Posté par  (site web personnel) . Évalué à 10.

    On comprend rien à ton combat, mais apparemment t'es fâché avec les meta HTML. Elles t'ont fait quoi ?

    de surcroît incompatible avec la norme XHTML choisie, les codes javascript ne devant apparaître que sous forme de références externes

    Non.

    un commentaire indiquant déjà une contrainte (enforce) limitant l'accès des données

    Déjà t'as l'air d'avoir tes petits poings tellement serrés de colère que t'es pas capable de copier-coller un verbe (ou alors c'est la faute des meta ?). Ensuite t'as visiblement rien compris à ce que ça fait.

    puis enfin des métadonnées concernant une application commerciale précise, dont aucune autre ne devrait avoir d'utilité (usefull)

    Oui et un terminal en noir et blanc n'a aucune utilité (usefull) (c'est quoi le délire de mal traduire en anglais ?) des instructions color: en CSS, et ?

    Le titre (indispensable, et encodé avec des entités)

    Et alors ça fait quoi ? " est une entité définie par défaut dans XML, et il est tellement évident qu'elle l'est aussi dans la DTD XHTML que je vais même pas vérifier.

    Arrive une floppée de scripts indigestes pour un validateur, et plus encore pour un outils de transformation, tel un Google Translate qui lit plusieurs langues à la fois, parfois mal orthographiées.

    Pour un validateur HTML c'est sûr mais ça tombe bien c'en est pas. Essaie un validateur Javascript. Et puis comme si google translate était assez con pour essayer de traduire les balises script…

    ainsi le développeur a du code un code spécifique pour une fraction non standard, n'étant par définition pas pérenne

    Je crois que pour ta sérénité il ne faut surtout pas que tu t'intéresses au développement.

    N'étant pas spécialiste en développement Web

    On s'en était douté.

    je ne saurais me prononcer sur la capacité des standards à supporter de tels applicatifs, et la séparation des contenus.

    Eh bah essaie par toi-même en te bandant les yeux et en utilisant un navigateur pour mal-voyants, au lieu de nous broyer les raisins avec tes journaux incompréhensibles.

    les modèles pouvant se diffuser et s'appliquer à differents cas de figure, tel ceux facilitant l'accessibilité au contenu et la mise en production d'individus aujourd'hui encore tenus à l'écart de l'économie.

    Ah ouais carrément, parce que le Vatican utilise un CMS qui insère un peu de Javascript inline, c'est la lutte des classes et la fracture numérique et les masses prolétariennes sont spoliées.

    Alors, c'est quoi ton problème ? Tu veux quoi ? L'adresse de l'HP le plus proche ?

  • # mais surtout pas Google !

    Posté par  (site web personnel) . Évalué à 9.

    Arghh, mais pourquoi une redirection par Google pour arriver à la page https://fr.wikipedia.org/wiki/KWrite (voir le dernier lien de l’article) ?

    Désolé, mais la défense de la vie privée est une lutte de tous les instants…

    Ce message ne contient aucun degré. (sérieusement…! non, mais en vrai !! ok, peut-être un peu parfois mais pas là ☻ )

  • # L'adresse de la page analysée est présente dans l'article

    Posté par  . Évalué à -1.

    Merci pour vos analyses.

    L'adresse analysée, peu visible, se situe juste au-dessus de commentaires.
    http://en.radiovaticana.va/news/2017/05/19/pope_francis_mercy_friday_visit_to_ostia_housing_project/1313488

    <a href="http://en.radiovaticana.va/news/2017/05/19/pope_francis_mercy_friday_visit_to_ostia_housing_project/1313488">(from Vatican Radio)</a>

    Il s'agissait d'un des rares passages compatibles avec XHTML,
    bien que contenant du CSS :

    style="margin:0"
align="left"
hspace="5"

  • # uxam

    Posté par  . Évalué à 2. 

    <!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" lang="en">

    On trouve encore beaucoup de XHTML de nos jours ? Je viens de vérifier deux trois sites mainstream, c’est du HTML5, j’ai l’impression que ça fait un petit moment que HTML est devenue la norme la plus usitée, pourquoi parler de XHTML ?

    <head>

L'entête contient essentiellement du javascript greffé à la page, pourtant qui ne devrait apporter aucune information brute.
74 lignes

    Aucune information brute ?! L’entête contient par exemple le titre du document ou les mots-clés associés. C’est bien de la donnée. Ou alors je n’ai pas compris ce que tu voulais dire par « information brute » ?

    Généralement issue probable à des contraintes techniques inhérentes à ce langage, ne permettant pas son exécution autrement qu'imbriqué dans les données

    C’était le cas il y a quelques années, ce n’est plus vrai. On peut très bien mettre tout le code JS dans le script JS et pas directement imbriqué au HTML : https://www.w3.org/wiki/Handling_events_with_JavaScript#The_evolution_of_events

    C’est pas fait tout le temps parce que c’est assez lourd (ça fait plus de code à écrire) et sur de petits projets on a pas forcément le temps pour ça. Surtout que je ne vois pas en quoi cela gêne quoi que ce soit à l’accessibilité, d’avoir des attributs type 'onmouseover' sur certaines balises…

    Nous avons ainsi affaire à une réelle application, avec un code qui s'exécute sur le poste du client, une application hybride dont une partie est contenue en ligne, une autre transportée sur le poste du client.

    Je trouve ta formulation… bizarre… Il s’agit simplement d’une application basée sur le modèle client/serveur, ni plus ni moins.

    On remarque des commentaires html permettant au développeur de s'y retrouver dans ses spaghettis…

    Les commentaires dans le code HTML sont de l’information. On pourrait là parler d’information secondaire, puisse qu’elle est destinée à ne pas être affichée… mais ça reste de l’information. On peut par exemple indiquer le nom de la machine qui a générer la page, ou la version de l’application, etc…

    l'information spécifique de cette url qui se résume en une image, un titre et une description, le reste n'étant que données contextuelles et applicatifs spécifiques à un contexte prédéfini, parfois limité à quelques navigateurs particuliers ou même versions de ces navigateurs.

    Quelle URL ? https://www.facebook.com/events/883207281810970/ ?

    le reste n'étant que données contextuelles et applicatifs spécifiques à un contexte prédéfini

    Oui donc cette URL ne se limite pas à « une image, un titre et une description », ton propos est paradoxal…

    C’est vrai que ce n’est pas toujours facile d’accéder au contenu directement mais en l’occurrence, sur la page sus-citée, on y accède très facilement, en deux clics : https://scontent-cdg2-1.xx.fbcdn.net/v/t31.0-8/18489457_415403502176540_7560607531319358570_o.jpg?oh=86ab05006b087ed401db2988cd2cae9f&oe=59A76EFB

    Bref. Je ne comprends pas où tu veux en venir, ce que tu essayes de faire passer comme message… Si c’est juste que certains usent d’astuce technique pour décourager qu’on partage leur contenu par d’autres biais que leur application c’est pas vraiment nouveau…

    Firefox (et Chrome) incluent un « inspecteur » (Ctrl+Alt+C) qui permet d’afficher le DOM, comme si c’était une page statique. Des fois ça aide à trouver « la bonne URL » ;)

    • [^] # fr.wikipedia.org/wiki/Header

      Posté par  . Évalué à 0.

      Nous avons donc constaté le DOCTYPE se rapportant à une norme qu'il ne suivait pas.

      Effectivement tout est donnée ou information, à des degrés divers, et ce que j'appelais l'information brute de la page analysée, concerne l'essence de la page, sa raison d'être, ce qui la distingue de toute autre sur le site web.
      Le mot "acer" écrit sur mon écran est une information, le on-mouse-over est une information, le mozilla Firefox ou konqueror ou lynx qui s'affiche en haut de la fenêtre est une information. On les distinguera plus facilement du nom de la page (ou titre) rattaché à cette page, mais qui n'est pas l'information contenue dans cette page. Il s'agit de son nom permettant de le retrouver, et le nom ne devrait pas se substituer à ce qu'il nomme, sans quoi ce qu'il nomme serait inutile.
      Il semble qu'à l'origine du head, on trouvait comme pour un fichier C, les données externes (prérequis) permettant d'évaluer le contenu (main ou body). Si aucune distinction entre les spécifications précisées dans l'entête et le contenu ne peuvent se différencier autrement que par le "c'est comme ça", c'est une tradition, c'est une convention… alors l'entête n'a pas de raison d'être.
      Dans le contenu lui-même, il y a plusieurs degrés d'informations. Celles liées à l'affichage (css), celles liées à l'interaction (javascript), et celles liées à la structure du document (DOM écrit en Xhtml, le X étant je crois là pour sa validité avec le XML, à la différence du HTML, dont le HTML5 est une évolution me semble-t-il).
      Pour l'accessibilité, seul le DOM devrait avoir de l'importance, car CSS et JavaScript restent rattachés au contexte, qu'il soit navigateur (sa marque, sa version, son utilisation poste de travail ou mobile, tablette, etc), ou son utilisateur (pas doué du mulot, malvoyant, etc), ou même base de données, archivage, transformation (XSL) d'un contexte à l'autre.
      Un document non standard, très joli, avec plein de codes dans tous les sens qui ont beaucoup d'intérêt et de justifications, est juste soit difficile à transformer, soit perdra toute information non conforme.
      Enfin le titre contenu dans la balise de l'entête, peut ne pas être le titre du document qui s'affiche, il peut être une simple référence, tel un code barre, ou contenir diverses informations codifiées concernant la place du document ou son thème…
      Comme dans une bibliothèque, les métadonnées, telles que le titre, l'auteur, le nombre de pages, la taille de l'ouvrage, etc, ne sont pas l'oeuvre, mais viennent la décrire. Ces données ne sont pas utiles à qui veut l'adapter (transformation) vers un autre média ou en faire une oeuvre dérivée (film, bd, etc).

      https://fr.wikipedia.org/wiki/Header

      • [^] # Re: fr.wikipedia.org/wiki/Header

        Posté par  . Évalué à 2. Dernière modification le 26 mai 2017 à 23:25.

        Il s'agit de son nom permettant de le retrouver, et le nom ne devrait pas se substituer à ce qu'il nomme, sans quoi ce qu'il nomme serait inutile.

        Est-ce que le titre d’un roman fait partie du roman ? Est-ce qu’une éventuelle dédicace fait partie du roman ?

        Je pense que oui pour ma part.

        Il semble qu'à l'origine du head, on trouvait comme pour un fichier C, les données externes (prérequis) permettant d'évaluer le contenu (main ou body).

        Le corps contient les données, l’entête contient les méta-données, c’est pas plus compliqué que ça.

        Le contenu de la balise 'title' est bien une méta-donnée comme tu le fais remarquer. L’équivalent au titre d’un roman serait le contenu de la balise 'h1'

        Je réitère, le titre d’un roman est partie intégrante de ce roman, ce n’est pas une simple méta-donnée comme le nombre de page, c’est un morceau de la substance littéraire de l’œuvre.

        • [^] # KISS : faire simple, faire accessible

          Posté par  . Évalué à 0.

          C'est bien parce que certains titres sont là pour l'accroche qu'il y a parfois des second titres. A une époque révolue, on utilisait des titres à rallonge.

          Aussi, ayant séparé la forme du contenu, les contenus contextuels, les métadonnées, il reste la structure du document qui porte la donnée.

          Cette structure standardisée peut désormais être facilement manipulée et reconstruite à l'infini.

          L'argument revenant souvent dans ces colonnes, qui veut que le CSS et le JavaScript se justifient par l'accessibilité, est valable, mais pas dans le cas d'un contenu distribué à un ensemble hétérogène d'individus et de lecteurs (n'oublions pas les robots et autres spiders qui viennent apporter une plus-value démesurée à la distribution du contenu).

          Le maître d'oeuvre du site web ne peut savoir à qui il s'adresse précisément, à moins de faire le choix de restreindre son audience. Aussi, il a tout à perdre à chercher à développer pour une audience spécifique, et tout à gagner à coder pour le plus grand nombre. Ce qui peut se faire en suivant les standards du W3C, et tenant compte des exceptions de sociétés commerciales (je pense à Apple ou Microsoft), en rendant ces exception lisses. C'est à dire qu'elles n'interfèrent pas avec les standards, qu'elles ne rendent ni le code inutilisable pour le standard, ni plus complexe à développer pour s'accrocher à des détails qui devraient rester secondaires.

          Le maître d'oeuvre n'a pas à s'occuper de l'accès par son audience de façon technique, ou plus exactement, la meilleure façon d'en tenir compte, est de suivre les normes qui prennent déjà en charge ces contraintes techniques, et évitent de les réinventer. Il n'a pas non plus à se soucier de pallier à des contraintes de navigateurs, c'est le travail de l'architecte du navigateur.

          Dès lors, ce que l'on appelle la lourdeur du respect des normes, devient un moyen de glisser sur les difficultés et de s'en détacher, pour se concentrer sur l'essentiel, par exemple d'autres modèles de contraintes permettant de transporter et distribuer plus de données, de façon plus efficace, comme par l'audio, la video, la transcription, la traduction et la description des contenus.
          Peut-être aussi transformer de coûteuses heures de travail qualifié de développement applicatifs non pérennes, et de surcroît limitants, en la contribution ou le financement d'API modèles, ou la prise en charge sérieuse des contraintes liées à l'accessibilité des données.

          Un exemple simple est d'opérer un suivi des accès en erreur (fallback), et d'y remédier par l'action plutôt que par le déni.
          Comme par exemple rechercher la raison d'un lien cassé, plutôt que d'attendre de l'utilisateur qu'il effectue lui-même ces recherches.
          Ces recherches alourdissent la charge de travail de l'utilisateur, celle des services qu'il utilisera pour ce faire, gonflant la bande passante inutilement, etc… Dès lors que l'on sait l'utilisateur (l'audience), de par des demandes récurrentes, mesuré généralement avec plusieurs zéros, a tendance à se augmenter et se à multiplier.
          Cette l'audience est elle-même créatrice de diffusion, et la toile (web) en marche se constitue naturellement. Pour se convaincre de la redondance des requêtes et des contenus, il suffit de lancer une recherche sur Google, qui vous proposera plusieurs requêtes déjà effectuées, et bon nombre de résultats.

          Aussi la correction de ces erreurs, la recherche et la résolution des problèmes, ne peut qu'avoir l'effet d'un cercle vertueux. Bien plus efficace que le développement de codes censés apporter de l'accessibilité (sur des détails) tout en nuisant à celle-ci (en général). Ne serait-ce que pour le respect de liens partenaires venant gratuitement augmenter votre visibilité.

          Le développement JavaScript pour l'accessibilité, doit ainsi se comprendre dans le respect des standards, par l'agglomération de codes réutilisables, API ou briques de développement, mais de façon systématiquement détachée du contenu auquel il s'applique, pour qu'il ne devienne pas un carcan dont on serait fier.
          Il vaut mieux construire des développements sains sur une base saine, et obtenir de la valeur ajoutée avec un code propre, servi par une gestion efficace des ressources.

          • [^] # Re: KISS : faire simple, faire accessible

            Posté par  . Évalué à 2.

            n'oublions pas les robots et autres spiders qui viennent apporter une plus-value démesurée à la distribution du contenu

            Quelle plus-value ? Le référencement ? Le HTML est fait pour présenter le contenu pour des humains (handicapés ou pas). C’est au concepteur du robot de s’adapter au format, pas au concepteur du site de s’en faire une contrainte.

            l'essentiel, par exemple d'autres modèles de contraintes permettant de transporter et distribuer plus de données, de façon plus efficace, comme par l'audio, la video, la transcription, la traduction et la description des contenus.

            Pour l’audio et la vidéo ça a justement été normalisé par HTML5, suite à une longue période où effectivement ce n’était pas standard et pas du tout « accessible », typiquement, en Flash.

            Pour ce qui est de la description du contenu et bien c’est à ça que servent mot-clés, description, et autres balises du header HTML, non ?

            Il n'a pas non plus à se soucier de pallier à des contraintes de navigateurs

            On dit : « pallier des contraintes » https://fr.wiktionary.org/wiki/pallier

            c'est le travail de l'architecte du navigateur.

            Le problème c’est qu’il n’y a pas un architecte du navigateur mais des architectes des navigateurs : Mozilla, MS, Google, pour citer les principaux. Il y a aussi des gens pour considérer que le contenu Web n’a pas forcément vocation à être exploité par un navigateur mais autrement, je pense à Weboob.

            Comme par exemple rechercher la raison d'un lien cassé, plutôt que d'attendre de l'utilisateur qu'il effectue lui-même ces recherches.

            Si on se retrouve avec un lien interne qui est cassé c’est clairement qu’on a fait de la merde en concevant son site. Par contre, pour les liens externes ça ne dépend évidemment pas du site. C’est le site pointé qui fait de la merde.

            Dans ce cas, évidemment, le site peut détecter que le lien ne répond plus et agir en conséquence (ne pas présenter le lien au visiteur par exemple) mais ça c’est pallier les mauvais comportements des autres. Ce n’est pas forcément une bonne idée.

            Pour se convaincre de la redondance des requêtes et des contenus, il suffit de lancer une recherche sur Google, qui vous proposera plusieurs requêtes déjà effectuées, et bon nombre de résultats.

            Je dirais même que lorsque ta recherche est une question proprement formulée, on trouve quasiment toujours dans les résultats un site de Q&A où quelqu’un a déjà posé exactement la question que l’on se pose soi-même… et bien sûr quelqu’un y a répondu… :)

            Le développement JavaScript pour l'accessibilité, doit ainsi se comprendre dans le respect des standards, par l'agglomération de codes réutilisables, API ou briques de développement, mais de façon systématiquement détachée du contenu auquel il s'applique, pour qu'il ne devienne pas un carcan dont on serait fier.

            À la lecture de tous tes commentaires et en particulier celui-là, j’ai l’impression que tu confonds contenu « documentaire », c’est à dire statique (ou à peine dynamique, jore un peu de JS pour trier les tableaux ou autre truc simple dans le genre) et contenu « applicatif », c’est à dire fortement dynamique, où le contenu envoyé par le serveur dépend fortement du contenu (formulaires typiquement) envoyé par le client.

            Le code JS est exécuté par le client (on peut faire du code serveur en JS aussi mais je mettons ça de côté pour l’instant), donc visible de celui-ci, donc modifiable par celui-ci !

            Le code serveur, lui, est au contraire connu seulement du « maître d’œuvre » comme tu dis… Même si ce code est libre et donc disponible pour tout un chacun, du point de vu du client on peut s’attendre à ce que n’importe quoi tourne…

            détachée du contenu auquel il s'applique

            Si le contenu de mon document est défini par : « un nombre au hasard entre 1 et 6 », le code JS qui tire un numéro au hasard ne fait-il pas partie du contenu ?

            • [^] # Re: KISS : faire simple, faire accessible

              Posté par  . Évalué à -1.

              Effectivement, la plus-value réalisée par les robots et spider tient du référencement, mais aussi de l'exploitation des contenus qu'ils permettent. Le contenu leur est aussi destiné.

              Le concepteur de l'outil ne devrait selon moi pas avoir à pallier à (il paraît que pallier à existe d'après https://fr.wiktionary.org/wiki/pallier ) des codes déficients dont il ne peut connaître par avance quels défauts ont pu être imaginés par le développeur (c'est que ça a de l'imagination, un développeur).

              Aussi les concepteurs de tels outils devraient s'attacher à tenir compte d'un standard afin d'analyser les contenus et les exploiter, standards développés précisément dans ce but, et rien que le standard. Ce qu'ils ne font heureusement pas, à lire les titres et descriptions de Google par exemple, lorsqu'ils ont peu de sens… mais sont exploités quand même, puisque même un contenu mal fichu peut être utile.

              Aussi l'architecte (au sens général) de l'outil qui sert d'interface à l'utilisateur, quel qu'il soit (du GET à IExplorer, ou Weeboob…), ne devrait pas non plus se soucier des erreurs rencontrées sur les pages, et se concentrer sur les fonctionnalités de l'outil. Ce que là non plus il ne fait heureusement pas, et les navigateurs insérant des fonctions permettant de lire les contenus mal fichus ou non standards.

              La description des contenus, peut être simplement de fixer ces liens internes cassés, ou pages déplacées sans redirection. Plutôt que d'imposer à l'utilisateur de chercher et l'outil de recherche de pallier. Ces concepteurs de sites ayant autant peu d'intérêt pour les références des sites externes, qu'ils ont la volonté de capter l'utilisateur, lui imposant un parcours précis pour accéder à l'information. Peut-être mal formés au concept de Toile (Web) et de réseau (network), ou le faisant volontairement pour limiter l'accès à leurs informations, ce qui devient hors-propos.

              Reste la question du contenu, de l'information.
              Si tout est information, tout peut être considéré comme contenu, et le contenant pouvant être lui aussi information ou simple enveloppe dépourvue d'intérêt. L'un et l'autre sont valable.
              Pour cette article j'avais fixé, traitant du fond et de la forme, la limite à ce qui est effectivement statique, l'information brute.
              Dès lors qu'elle est dynamique, elle n'est plus brute, et devient évanescente (contenu quantique ?). Elle n'est plus la même selon le contexte, et n'est plus une #entité.
              On a alors affaire à un contenant qui vient modifier l'information brute, ou une application qui attend un paramètre pour fournir un résultat, comme « un nombre au hasard entre 1 et 6 ». Dans ce cas, l'information serait la formule, et ne fournirait pas de résultat. Le résultat deviendrait le contenu brut, dès lors qu'il serait soit fournissant le résultat statique, soit fournissant la formule, le paramètre, et son résultat.
              Que le code soit effectué sur le serveur, ou sur le client n'a pas d'impact sur ce point.

              On pourrait soulever le problème de la Licence libre qui impose de fournir le code, sur demande, à l'utilisateur.
              Pour un logiciel libre, condition nécessaire pour que le logiciel puisse être modifié et redistribué (soit de façon libre avec ls GPL, soit de façon fermée avec BSD).
              Pourtant, si ce code n'est pas exécuté sur le client, il semble que cette obligation n'est valable que pour le déploiement de l'applicatif sur un serveur, aussi il ne devrait concerner que les codes compilés, puisque les codes interprétés sont en clair sur le serveur, c'est à dire la diffusion du code source au bénéficiaire de la redistribution.

              Les termes employés peuvent être inexacts ou approximatifs, tout comme les raisonnements et conclusions, n'étant, je le rappelle, pas un spécialiste.
              Le maître d'oeuvre, concepteur du site ou développeur au sens large : https://fr.wikipedia.org/wiki/Ma%C3%AEtrise_d'%C5%93uvre
              Le client au sens commercial, appelé ici bénéficiaire : https://fr.wikipedia.org/wiki/Ma%C3%AEtrise_d'ouvrage

            • [^] # Re: KISS : faire simple, faire accessible

              Posté par  . Évalué à 3.

              n'oublions pas les robots et autres spiders qui viennent apporter une plus-value démesurée à la distribution du contenu

              Quelle plus-value ? Le référencement ? Le HTML est fait pour présenter le contenu pour des humains (handicapés ou pas). C’est au concepteur du robot de s’adapter au format, pas au concepteur du site de s’en faire une contrainte.

              C'est pourtant ce que portent les microfotmats.

              Le développement JavaScript pour l'accessibilité, doit ainsi se comprendre dans le respect des standards, par l'agglomération de codes réutilisables, API ou briques de développement, mais de façon systématiquement détachée du contenu auquel il s'applique, pour qu'il ne devienne pas un carcan dont on serait fier.

              À la lecture de tous tes commentaires et en particulier celui-là, j’ai l’impression que tu confonds contenu « documentaire », c’est à dire statique (ou à peine dynamique, jore un peu de JS pour trier les tableaux ou autre truc simple dans le genre) et contenu « applicatif », c’est à dire fortement dynamique, où le contenu envoyé par le serveur dépend fortement du contenu (formulaires typiquement) envoyé par le client.

              Le code JS est exécuté par le client (on peut faire du code serveur en JS aussi mais je mettons ça de côté pour l’instant), donc visible de celui-ci, donc modifiable par celui-ci !

              Le code serveur, lui, est au contraire connu seulement du « maître d’œuvre » comme tu dis… Même si ce code est libre et donc disponible pour tout un chacun, du point de vu du client on peut s’attendre à ce que n’importe quoi tourne…

              Je suis pas certain de ce que vous voulais dire, mais vous êtes entrain de discuter de choses sans les formaliser : vous avez un paquet d'architectures qui sont là pour décrire des façon d'organiser tout cela (MVC, MVVM, MVP, PAC, Flux,…). Penser qu'il y a une bonne façon de faire et que c'est quelque chose de dépendant du langage me surprend. Ils ont tous des avantages et des inconvénients et (mise à par PAC) sont tous activement utilisé aujourd'hui.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: KISS : faire simple, faire accessible

                Posté par  (site web personnel) . Évalué à 2.

                C'est pourtant ce que portent les microfotmats.

                Oui et de manière générale ça a fortement agi pour le partage de l'information, puisque permettant son traitement automatique. Mais fais gaffe, dans le contexte du journal on va te répondre que ça bride sa diffusion, car pas compris par Altavista, seulement par des technos post-2010.

  • # moinssage

    Posté par  . Évalué à 3.

    J'ai moinssé pour plusieurs raisons :

    • pas d'intro, pas de conclusion, pour un journal très long.
      Je n'ai pas compris l'objet de cet article.
      Si c'est pour dire que la plupart des pages HTML sont bloatées; Bah oui merci, on sait.

    • tu décortiques une "page officielle prise au hasard".
      Mais sans en donner le lien.
      Et puis une "page officielle", ça me rappelle la blague de la bite avec un attaché case.

    • comble du comble pour qqun qui dénonce les mauvaises pratiques du web : foutre un lien vers wikipedia avec une redirection gggle.
      Non mais là, à ta place je me fais hara-kiri.

    Au temps pour toi.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.