XSLT et accessibilité au niveau du référencement...

Ahh wé bonne question en effet, d'autant que je commence à m'interesser au sujet

Le mieux (?) serait peut être de parser le XML/XSLT pour rendre un docment HTML et là plus de question, mais en fait je pense qu'il est mieux (pour le futur) de faire XML+XSLT et d'afficher directement le résultat, ce que tu fais actuellement.

Alors plusieurs problèmes :
Sous IE ça passera, sous Gecko aussi, mais sous Opera aucune transformation XSLT n'est prise en compte (avec mes tests perso, si tu as autre chose ca m'interesse ). Donc si les transformations XSLT ne sont pas prises en compte par Opera on peut se demander si un robot comme google le prendra en compte...

Mais perso, je pense que le rendu est pris en compte comme du HTML donc que les balises sont prises en compte. mais ce n'est que mon avis.

Un truc a prendre en compte, on peut faire les 2 .

Soit on laisse le client faire son boulot et parser lme XSLT/XML pour afficher du HTML(mozilla et IE)

Soit on fabrique le html sur le serveur avant d'envoyer le tout au navigateur.

On peut facilement avoir le choix si on à la main sur le serveur apache en installant mod-xslt et en utilisant des headers dans son fichiers XML qui selon le user-agent va effectuer la transformation XSLT via mod_xslt ou laisser le client faire son taf ..

En clair tout est enviseageable.

Faudrait demander à Laurent Denis, il connait bien Opera et les futures avancées.

En tout cas je voudrais vraiment utiliser XML coté client, mais je crois que je vais être obligé de me renseigner sur le mod_xslt pÔ cool

A propos d'XSLT côté client, voir tout simplement Yan Hixon, "Never send content in proprietary formats over the wire", http://ln.hixie.ch/?start=1064828134&count=1 :

Yan Hixon a écrit :

Les transformations ne devraient être faites que côté serveur, de sorte que le contenu envoyé sur le Web, quel qu'il soit, soit dans un format bien connu ((HTML, MathML, etc). L'agent utilisateur peut alors décider s'il rend ce contenu en utilisant les indications de style de l'auteur (CSS) ou s'il le rend en utilisant ses propres règles (comme le fait Lynx, ou typiquement Opera sur les périphériques handheld comme mon mobile, comme le font les navigateurs vocaux, etc.)

L'accessibilité n'est pas seulement une question de gens aveugles. Elle concerne un ensemble grandissant de périphériques aux caractéristiques exotiques. N'envoyez donc pas paître vos lecteurs !

Sinon, pour Opera, il y a peu de chances en effet que la position d'Hakon Lie ait changé depuis "Formatting Objects considered harmful", http://people.opera.com/howcome/1999/foch.html . Ni Opera 7.54 ( dernière version stable), ni opera 7.60 (dernière preview en cours) n'ont apparemment l'intention de supporter XSLT côté client.
Modifié le 25 Nov 2004 - 18:35

Donc XML coté client c'est vilain alors ???
Pourtant j'avais cru que c'etait ce vers quoi nous tendions à plus ou moins long terme, ça epargne les serveurs d'un traitement assez lourd tout de même

Donc, je vais m'en retourner trouver des solutions pour rendre du bon vieux HTML à partir de mes docs XML si j'en crois Yan Hixon.

Pour ce qui est de MathML ("dans un format bien connu ((HTML, MathML, etc)") Euh insérer du MathML dans un fichier, en utilisant xhmtl1.1 oui mais vu qu'IE fait des siennes avec le type mime xml c'est pas si bien connu de tous...

Parceque si j'ai bien compris, il faut grosso modo renvoyer du HTML, et s'il y a à utiliser un langage XML comme MathML, il faut l'insérer dans le doc HTML donc avec xhtml1.1.

Non pas taper, pas taper, j'essai de bien tout clarifier dans le néant qui me sert de tete

mplessis a écrit :
Que faudrait-il alors envisager : ne plus utiliser le xslt côté client ou attendre que presque tous les navigateurs évoluent vers ce systéme de traitement, qui comme le dit ElMoustiko, servirait bien à alléger le traitement des serveurs.

Si je peux me permettre, il n'y a pas de bonne réponse possible à une fausse question. Et je crois que celle-ci en est une.

En effet, il faut d'abord se méfier du mot "navigateur" qui vient trop souvent spontanéement pour désigner la cible des documents Web. Ceux-ci sont loin d'être exploités seulement par des navigateurs, même en donnant à ce terme un sens assez large pour inclure les agents utilisateurs des medias autres que l'écran traditionnel (lecteurs d'écran, mobiles, Web-TV, tablettes brailles, etc). Il faut songer aux robots d'indexation, aux traducteurs, etc. Il faudrait relire chaque matin http://www.w3.org/MarkUp/2004/xhtml-faq.html#ua pour s'en imprégner :

FAQ HTML XHTML W3C a écrit :

Pourquoi dites-vous "agent utilisateur" au lieu de "navigateur" ?

Bien que les navigateurs soient en effet des consommateurs importants de documents HTML et XHTML, d'autres programmes et systèmes lisent ces documents. Par exemple, les moteurs de recherche le font, sans être pour autant des navigateurs. En utilisant le terme "agent utilisateur", nous essayons de rappeler aux gens cette distinction.

Ceci posé, je crois que la question préalable est plutôt: y a-t-il une norme imposant à un agent utilisateur conforme d'implémenter XSLT ? Si je ne me trompe pas, la réponse est non, et rien ne contraindrait alors les "navigateurs" futurs à le faire. XSLT côté client resterait alors un pari très sélectif sur l'interopérabilité du document.

La FAQ citée ci-dessus se poursuit en effet avec un texte à propos des frames qui peut facilement être légèrement modifiée pour dire:

A la manière de FAQ HTML XHTML W3C a écrit :

Par exemple, si vous faites une recherche Google, vous verrez souvent dans plusieurs résultats de votre recherche quelque-chose comme "Cette page Web utilise XSLT mais votre navigateur ne le supporte pas". Ce qui dissuade à coup sûr une partie des gens de cliquer sur ce lien...

Modifié le 27 Nov 2004 - 08:01

Laurent Denis a écrit :


Si je peux me permettre, il n'y a pas de bonne réponse possible à une fausse question. Et je crois que celle-ci en est une.

Pas de probléme Laurent. Quelques fois je devrait un peu plus réfléchir avant de parler.....

Donc si l'on fait un petit résumé, xslt côté client serait comme tu le dis "un pari trés sélectif" sur l'accessibilité du contenu (l'exemple type de technologie pouvant engendrer de gros probléme d'accessibilité donc).

Essayons donc de réserver cette technologie à des projets trés ciblés (Intranet dont les données ne sont pas soumises à une visualisation "grand public", disons). Les normes imposant, aux agents utilisateurs , uniquement (je le pense aussi) de rendre un bon HTML, la génération de code se ferait donc plutôt côté serveur (un pari beaucoup moins risqué surement)....

Encore merci à tous de votre contribution, je vais revoir ma copie sur la génération de mon contenu XML.