XHTML

[Mirada2000]

Bonjour,

je souhaiterais savoir comment lire des ficheirs xhtml avec Maxthon,

ex :

http://cui.unige.ch/~robin0/configuration.xhtml#web

[Jimi]

Zarbi ce truc ...

Maxthon lit tres bien les fichiers xml normalement : Son precebdaent fichier de config en etait un !!!

et danc ce fichier je vois au debut :

<?xml version="1.0" encoding="UTF-8"?>

 

Par contre pour ton lien il m'enregistre un fichier qui commence par :

<?xml version="1.0" encoding="iso-8859-15"?>

 

UTH-8 ...... iso-8859-15 .. ????

[hpsam]

Je connais html, htm, xml mais c'est quoi du xhtml ?

Chez moi, ni IE ni Maxthon ne l'ouvre, les 2 lancent l'utilitaire de téléchargement.

Ne s'agit-il pas d'une erreur de lien ou de nomination de la part du webmaster ?

[Jimi]

telecharges le fichier te droppes le dans maxthon ...

[Ldfa]

Pour l'explication sur XHTML, ça se trouve ici : http://medias.obs-mip.fr/www/Activite/Form...d/cours005.html

 

Pour une astuce (non testée personnellement) pour pouvoir afficher un fichier XHTML avec IE (et donc Maxthon), ça se trouve là : http://blog-and-blues.org/weblog/2005/01/0...k-denue-de-sens

 

En attendant une vrai mise à jour de IE (la v7 bêta est annoncée par Microsoft pour les grandes vacances ) ou de passer sur quelque chose de plus à jour au niveau des standards du W3C, j'ai nommé les navigateurs de la famille Mozilla (pour les impatients).

[ManuDevil]

En fait, on arrive là aux limites du moteur obsolète de IE. Nan, je suis sérieux. En gros, le XHTML, c'est un codage bien strict et bien régulier des pages web, avec un usage intensif et intelligent des balises et des feuilles de styles.

Feuilles de style = CSS

IE les interprète assez mal, et peut faire un affichage assez... primitif, parfois. Inversement, IE a des codes CSS qui ne respectent pas les standards du XHTML, mais qui permettent des trucs... La guerre des boutons, quoi.

[Jimi]

T'e dans le vrai manu !

J'ai voulu en savoir plus et fait un google et trouvé ca :

 

http://www.siteduzero.com/xhtml-css/annexes/w3c.php

 

Tout est daté et detaillée nickel ! super boulot, tres instructif !

A Bookmarquer et faire passer ...

[NH]

Nan mais vraiment vous ne saviez pas ce que c'était le xhtml ? snif :'/

http://openweb.eu.org/xhtml/

[ErnestR4]

Zarbi ce truc ...

Maxthon lit tres bien les fichiers xml normalement : Son precebdaent fichier de config en etait un !!!

et danc ce fichier je vois au debut :

<?xml version="1.0" encoding="UTF-8"?>

 

Par contre pour ton lien il m'enregistre un fichier qui commence par :

<?xml version="1.0" encoding="iso-8859-15"?>

 

UTH-8 ...... iso-8859-15 .. ????

Bonsoir,

 

Juste pour préciser que :

 

UTF-8 correspond au codage unicode (regarder dans la barre d'outil ou Menu "affichage --> codage)

et

iso-8859-15 au codage "Europe occidental (ISO)"

 

Suivant les sites la coche du codage change et indique donc dans quel codage le site a été écrit ...

 

Exemple : le forum de Maxthon en anglais et en codage UTF-8

et ce forun ainsi que le site de Ldfa sont en codage "Europe occidental (Iso)

mais c'est transparent pour nous, sauf si on a la curiosité d'aller voir...

 

Je complète par le lien direct sur le site cité par NH :

 

http://openweb.eu.org/articles/jeux_caracteres/

 

qui expliquera encore mieux

 

 

 

[Jimi]

Wouarf merci pour ca ernest !

C'est vrai pour moi, je met mon nez partout ...

 

D'un coup je vais me faire pleins d'enemis mais je dirais que je

suis plutot chien moi !!!

 

Chouette, une nouvelle version ! Ce que je préfère !

Chouette, une page qui marche pas ! Ce que je préfère !

wouarf wouarf

[hpsam]

Merci pour toutes ces infos, c'est juré, un de ces jours je vais passer mon site au xhtml, mais je viens de supprimer les frames et de passer au php en autodidacte alors pas tous de suite la relecture et la modification de centaines de lignes.

D'ailleurs si quelqu'un connait un logiciel de transformation html => xhtml.

[ManuDevil]

Hpsam, ne t'affole pas, les deux langages sont extrêmement proches. Si ton site est vraiment très simple, si ça se trouve, tu n'auras presque rien à faire.

En fait, le XHTML, c'est en gros la séparation du contenu et de la mise en forme. Le contenu est mis dans des balises HTML. Les bonnes balises, je vous prie : les paragraphes dans des <p>, les blocs dans des <div>, les listes dans des <ul> ou <ol>. Et on arrête impérativement de mettre des tableaux partout, pour la mise en forme. Les tableaux ne servent pas à ça !

La syntaxe est épurée au possible, car il devient interdit de faire passer des paramètres de mise en forme dans les balises. On met tout en miniscules obligatoirement, et on ferme chaque balise ouverte. Du coup, une balise HTML <BR> devient <br /> en XHTML.

La mise en forme est assurée par les feuilles de styles en cascade, ou CSS. On peut même, si on le désire, mettre plusieurs fichiers CSS, afin de donner le choix à l'internaute. On peut aussi créer un fichier CSS pour l'affichage dans votre navigateur, et un autre pour l'impressin de la page, ou la visualisation du site sur une interface braille. C'est pas mal fichu.

Bon, je te conseille en effet de lire les sites dont les liens sont au-dessus, c'est bien plus instructif que mon petit post.

[Calimo]

Maxthon lit tres bien les fichiers xml normalement : Son precebdaent fichier de config en etait un !!!

<{POST_SNAPBACK}>

Sauf que ce n'est pas un bête fichier XML, c'est un fichier XHTML.

 

Je connais html, htm, xml mais c'est quoi du xhtml ?

Et pourtant...

http://www.la-grange.net/w3c/xhtml1/

Maintenant tu connais le XHTML ;-)

 

Par contre, IE, lui...

Chez moi, ni IE ni Maxthon ne l'ouvre, les 2 lancent l'utilitaire de téléchargement.

Eh non, IE ne connait pas le XHTML.

Pas de bol, Maxthon utilise par défaut le moteur d'IE

Ne s'agit-il pas d'une erreur de lien ou de nomination de la part du webmaster ?

<{POST_SNAPBACK}>

Non non, pas du tout

Simplement le fichier est envoyé avec le type MIME application/xhtml+xml comme expliqué ici et recommandé là.

 

Mais me direz-vous... vous pouvez bien lire la majorité des sites qui sont codés en XHTML... oui, mais en fait les webmestres font une "erreur" (je mets entre guillemets car elle est prévue par le W3C, dans ce tableau, ligne "text/html" colonne "XHTML 1.0 (HTML compatible)" il y a un "MAY", indiquant une possibilité comme expliqué dans la RFC 2119, à condition que les auteurs respectent les Règles de Compatilité HTML. La plupart des auteurs ne les respectent pas et envoient malgré tout le document en text/html malgré le "SHOULD NOT" pour le "XHTML 1.0 (other)"

Et comme le XHTML envoyé comme text/html n'est rien d'autre que du HTML invalide, je ne peux pas me résoudre à le faire. Tant pis pour les navigosaures comme IE qui ne connaissent même pas des recommandations "basiques" vieilles de plus de 5 ans

 

Pour une astuce (non testée personnellement) pour pouvoir afficher un fichier XHTML avec IE (et donc Maxthon), ça se trouve là : http://blog-and-blues.org/weblog/2005/01/0...k-denue-de-sens

Sauf que comme le dit l'auteur ce hack est totalement insensé !

 

Je ne peux que vous déconseiller de le faire. Pourquoi ? Parce qu'il s'agit de faire traiter le xhtml comme du html. Or LE XHTML N'EST PAS DU HTML ! C'est du XML ! Ce qui veut dire, entre autre, que le parseur doit s'arrêter sur les erreurs. Avec ça IE ne s'arrêtera pas sur les erreurs, chose gravissime ! (parce que ça veut dire que les autres navigateurs, eux, s'arrêteront et ne pourront pas lire la page )

 

En attendant une vrai mise à jour de IE (la v7 bêta est annoncée par Microsoft pour les grandes vacances ) ou de passer sur quelque chose de plus à jour au niveau des standards du W3C, j'ai nommé les navigateurs de la famille Mozilla (pour les impatients).

<{POST_SNAPBACK}>

Il n'est absolument pas certain qu'à ce moment IE supportera le XHTML

 

Par contre il est possible d'utiliser le moteur de Mozilla, qui supporte effectivement le XHTML, dans Maxthon ! Il faut commencer par installer le contrôle ActiveX Mozilla puis demander à Maxthon de l'utiliser plutôt qu'IE (je ne me souviens plus exactement de la procédure )

Ainsi vous avez enfin un bon moteur dans Maxthon

 

Rien que pour vous j'ai fait un fichier XML : http://cui.unige.ch/~robin0/configuration.xml

Il est envoyé avec le MIME type text/xml, IE le connait mais en fait on voit bien que ce n'est pas vraiment le cas

 

Au passage, ne vous faites pas d'illusions, IE va être incapable d'afficher un nombre croissant de sites. Un exemple : http://soirees.ehol.org/news/main.php Nul doute que ce n'est qu'un début et que dans quelques années ce sera une vraie galère de naviguer avec

[Calimo]

Ah au passage, j'ai oublié de préciser que le but, à terme, est d'inclure du SVG et du MathML directement dans cette page (ainsi que dans mon blog), chose qui est évidemment totalement inimaginable en HTML. Seul le XML et ses espaces de nom le permet. Avec un doctype XHTML + SVG ça ne devrait pas poser de problèmes, mais ce n'est pas possible en HTML.

 

Je veux juste revenir sur un truc :

En fait, le XHTML, c'est en gros la séparation du contenu et de la mise en forme. Le contenu est mis dans des balises HTML.

<{POST_SNAPBACK}>

C'est à moitié vrai ! En fait la séparation forme/contenu est tout à fait possible déjà en HTML 4.0. De même il est tout à fait possible de faire une soupe de balise (tag-soup) en XHTML (surtout si celui-ci est traité en text/html).

 

En fait la séparation du contenu et de la forme est introduite avec les variantes "Strict" et "Transitionnal" de ces deux langages. Ainsi on sépare la mise en forme et le contenu en HTML 4.0/1 Strict et en XHTML 1.0 Strict. On ne peut pas utiliser de balises de mise en forme en HTML 4.01 Strict. On peut aussi ne pas le faire en (X)HTML Transitionnal, mais ce n'est pas obligatoire.

 

Cela dit c'est vrai que le passage au XHTML est souvent une bonne occasion de faire cette séparation.

 

En fait le XHTML est une simple reformulation du HTML en XML, est il est donc plus strict au niveau de la syntaxe :

• Guillemets obligatoire autour des valeurs d'attributs
  
• Les caractères "<" et ">" doivent être sous forme d'entités (< et >) s'il ne s'agit pas des balises (c'est-à-dire si on veut les afficher à l'écran)
  
• Les entités doivent être terminées par un point-virgule (
  
• Imbrication correcte des éléments
  
• Mais surtout, surtout, le parseur XML s'arrête sur les erreurs de syntaxe, et ça c'est vraiment le plus important Bien sûr pour profiter du parseur XML il faut travailler en XML, donc pas en text/html comme MIME type mais en application/xhtml+xml (ou à la limite application/xml)
  

Ça ce sont les vrais avantages du XHTML, avec le fait qu'il peut tirer parti de toutes les technologies XML (les XPath, MathML, SVG etc.)

 

Voilà, si après ça vous êtes toujours pas convaincus je ne peux rien faire

[Ldfa]

Un grand pour toutes ces explications fondamentales et très intéressantes.

[NH]

Oui je t'adresses moi aussi un grand merci Calimo ... ça fait longtemps qu'ailleurs comme ici je n'ai souvent pas le courage de partir dans les explications techniques quand on en vient à parler des lacunes d'IE et de l'interêt du w3c.

Je donnes souvent par dépis des liens pas évidents à comprendre par tous, desormais j'aurais sous la main ton argumentaire, claire et complet, à offrir comme explication.

 

J'ai depuis en outre longtemps l'occasion de te lire sur GeckOzone et à d'autres endroits, et je tiens pour cela là encore à te remercier pour ton implication ( et tes qualités rédactionnelles, mais aussi humaines, et pour ton temps consacré sur les forums/blogs/traductions/site des extensions, ...) dans la défense des standards pour améliorer le web et ouvrir les prises de conscience de ses utilisateurs.

[ManuDevil]

Merci à Calimo, qu'il me semble bien avoir croisé sur le forum Geckozone

[mr_ianou]

sinon tu peux lire le xhtml avec firefox j'adore maxthon mais si un jour j 'ai une vérole j'ai toujours un navigateur de secoure pour pouvoir me télécharger les solutions de secoure (cela m'est déja arriver et j 'ai bien satisfait de l'avoir le renard)

[babyssou]

Bonjour à tous,

 

(c'était impossible pour moi de ne pas mettre mon grain de sel )

 

Pour le XHTML, tout a été dit, et bien dit (merci à Calimo). Le bug de IE sur ces pages est très génant, il faut vraiment en vouloir (du XHTML à la sauce IE) pour accepter d'en pondre.

 

En dehors de cette "évidence", il reste que le HTML, même en transitional, doit être "propre" ! Ce n'est pas parce que le W3C a cherché à rendre le code "béton" en sortant la norme "strict" que l'on peut faire n'importe quoi (en trans), même si IE l'accepte.

 

Mais je vais me faire plein de copains Je me fous que le webmestre a mélangé le fond et la présentation ! Je veux des pages "légères", sans erreur et au contenu intéressant. Tout le reste ne me concerne pas. Si quelqu'un qui habite les hauts plateaux désertiques de la Mongolie septentrionale a envi de faire connaître son pays par quelques photos et légendes, je préfère qu'il fasse son site, même avec des tableaux imbriqués, plutôt qu'il attende d'être un expert du code (il le corrigera plus tard).

 

Et de toute façon, le WEB n'a jamais été fait pour être "strict" (je suis bien placé pour en parler puisque je faisais parti de l'équipe de chercheurs qui a développé EARN, le réseau "ancêtre" de Internet en Europe), mais pour être "ouvert" le plus largement possible, afin que le maximum d'informations - quelque soit le média - puisse y être diffusé.

 

Il faut donc arrêter de... (attention, je vais me lâcher)... "se masturber" avec le XHTML, car pour pratiquement tous les créateurs de sites, il n'apporte strictement rien de plus que le transitional bien codé (quel est le % de matheux qui a besoin de MathML ? et le SVG ?). Je vois une utilié non citée, c'est pour les producteurs multi-média (dont je fais parti actuellement) de pouvoir mettre en ligne leurs bébés... mais qui s'amusera un jour à faire un produit, avec les coûts de production que cela implique, et à mettre en ligne son contenu !?! Avec l'évident risque que tout le monde va le charger et personne l'acheter !

 

Le XML ! Ce n'est pas du code, c'est un standard pondu par le W3C !!! Il est le "fils" du GML d'IBM, dont le langage balisé s'appelait SGML (c'est à dire Script GML). J'ai encore toute la doc GML et SGML dans mes cartons, je la garde comme "archives très précieuses" (et lui avoir fait faire 20 000 km montre à quel point j'y tiens). Ce XML est donc un standard pour des langages balisés servant à présenter (mettre en forme) des données suivant le média utilisé... et donc pas forcément destinées (les données) au WEB... je dirai même plus : lorsqu'elles ne sont pas destinées au web !

 

Je suis bien d'accord avec Calimo lorsqu'il dit que l'interpréteur (de IE) doit s'arrêter sur les erreurs (en XHTML) ! Raison de plus pour ne pas faire de XHTML pour ses pages. De mes nombreuses lectures, je cherche encore l'apport pour le WEB du XHTML sur le HTML... et je crois que je chercherai longtemps.

 

En conclusion, en dehors de besoins très particuliers, vous n'avez pas à basculer vos pages en XHTML, contentez-vous de faire du code propre et de nous transmettre vos informations.

 

Et bien fait si des pages en ligne sont illisibles car en XHTML merdeux !

 

(je n'ai parlé que du WEB, d'Internet, hein ! Pas d'applis qui utilisent les navigateurs comme interface, et elles sont de plus en plus nombreuses ! Pour elles, XML et XHTML sont obligatoires !)

[ManuDevil]

Là je te rejoins tout à fait. Pondre des standards, c'est une bonne idée pour obliger les programmeurs de navigateurs, mais il ne faut pas que ça empoisonne les webmestres.

A l'inverse, il est bon pour un webmestre de tenter de coder au plus strict possible, c'est un bon exercice. Mais si un bout de code n'est pas valide, et qu'on ne puisse pas s'en passer, pourquoi s'en passer ? Le code ne sera pas strict, mais sera interprété correctement. Le reste, c'est de la littérature. Je pense aux animations Flash, qu'il est absolument impossible de bien coder en XHTML strict.

En fait, le plus gros bonheur du XHTML, c'est qu'on est quasi assuré de faire des pages avec du code minimaliste, donc rapides à charger et à calculer. Mais il y a d'autres façon de coder pour un affichage rapide.

En clair : le XHTML, je suis pour sur le principe. Sauf si ça limite notre créativité pour des raisons oiseuses. Les navigateurs ignorent les balises qu'ils ne savent pas interpréter, c'est bien là le point principal à ne jamais oublier.

[hpsam]

Perso, ayant fait mon premier site en 96 en autodidacte, j'ai vite compris l'utilité des CSS pour alléger le code sur des styles complexes et modifier toute l'apparence de mon site via un seul fichier.

Mais les pages sont plus légère avec un <b>...</b> qu'avec <span class="bold">....</span> + un style définit dans la CSS alors je suis plus pour du HTML transitionel que pour le XML/XHTML.

Le HTML est relativement simple et un débutant peux rapidement faire une page web avec du bon contenu. Avec le XHTML, les erreurs ne sont plus pardonnées et le temps pour faire du contenu se reporte sur la technique.

Si quelqu'un qui habite les hauts plateaux désertiques de la Mongolie septentrionale a envi de faire connaître son pays par quelques photos et légendes, je préfère qu'il fasse son site, même avec des tableaux imbriqués, plutôt qu'il attende d'être un expert du code (il le corrigera plus tard).

La dessus, je suis totalement d'accord je préfère un site simple avec un bon contenu, qu'un truc technique plein d'animations et de vide.

Pour finir, je ne suis pas informaticien malgrès la gestion de 3 sites. J'ai appris en autodidacte le HTML, les CSS, récemment PHP et SQL car j'y trouvais un intéré pour faciliter la gestion des sites et gagner du temps pour travailler le contenu. Actuellement je n'ai encore trouvé aucun intéré réel à me tourner vers le XML/XHML

[ManuDevil]

Heureusement, avec le XHTML, tu peux mettre en gras avec la balise <strong> et en italique avec <em>. Ca ne change pas trop. Mais c'est vrai, le strict nous pompe grave, tout de même.

[babyssou]

Heureusement, avec le XHTML, tu peux mettre en gras avec la balise <strong> et en italique avec <em>. Ca ne change pas trop. Mais c'est vrai, le strict nous pompe grave, tout de même.

<{POST_SNAPBACK}>

 

ce qui, au niveau de la sémantique, est un détournement de la mise en forme, donc ce n'est plus du strict, c'est du n'importe quoi

 

Ceux qui sont intéressés par le sujet peuvent consulter les archives du forum fr.comp.infosystemes.www.auteurs, il en a été longuement (et trop souvent) débattu...

[Calimo]

Pour le XHTML, tout a été dit, et bien dit (merci à Calimo). Le bug de IE sur ces pages est très génant, il faut vraiment en vouloir (du XHTML à la sauce IE) pour accepter d'en pondre.

 

Ce n'est pas un bug, son comportement est tout à fait correct, il ne connait pas donc il ne traite pas... c'est étonnant car normalement il a tendance à ignorer les types MIMEs et interpréter coûte que coûte le HTML, même s'il est en text/plain ou application/octet-stream. Enfin tant mieux, sinon ce serait une vraie galère.

 

Mais je vais me faire plein de copains  Je me fous que le webmestre a  mélangé le fond et la présentation ! Je veux des pages "légères", sans erreur et au contenu intéressant. Tout le reste ne me concerne pas. Si quelqu'un qui habite les hauts plateaux désertiques de la Mongolie septentrionale a envi de faire connaître son pays par quelques photos et légendes, je préfère qu'il fasse son site, même avec des tableaux imbriqués, plutôt qu'il attende d'être un expert du code (il le corrigera plus tard).

 

En tant qu'utilisateur, effectivement, rien à faire. Encore que... il ne faut pas non plus que les pages en deviennent inacessibles. Cela dit on peut très bien faire du transitionnal 100% accessible et du strict 100% inacessible. Mais il y a quand-même une démarche, en strict, on est poussé à ne pas faire un titre juste avec un <font size="+2" bold color="red">. Donc pour l'utilisateur (celui qui est handicapé, et je rappelle qu'on est tous handicapé un jour), il peut quand-même y avoir un avantage, bien que ça ne soit pas automatique.

 

Par contre en tant que webmaster, je veux pouvoir faire confiance en mon outil pour ne pas laisser passer d'erreurs. Pour ça le XHTML est un gros avantage, une erreur --> hop, on s'arrête ! Et en tant que webmaster j'attend que les navigateurs soient à la hauteur, avec un support CSS raisonnable etc.

Bien sur le SVG et le MathML sur cette page c'est "pour le fun" ! Mais il y a des applications et ce serait dommage de s'en priver à cause d'un outil obsolète.

 

Il faut donc arrêter de... (attention, je vais me lâcher)... "se masturber" avec le XHTML, car pour pratiquement tous les créateurs de sites, il n'apporte strictement rien de plus que le transitional bien codé

 

Là tu fait la confusion classique XHTML/strict/transitionnel ;-)

Le XHTML apporte quand-même un plus : l'obligation de coder proprement, fermer les balises, guillemeter les attributs, échapper correctement (avec ; à la fin) les entités, etc. Ce n'est pas rien pour un webmestre, en HTML il est vite fait de se laisser aller et même le validateur ne dira rien.

 

(quel est le % de matheux qui a besoin de MathML ? et le SVG ?). Je vois une utilié non citée, c'est pour les producteurs multi-média (dont je fais parti actuellement) de pouvoir mettre en ligne leurs bébés... mais qui s'amusera un jour à faire un produit, avec les coûts de production que cela implique, et à mettre en ligne son contenu !?! Avec l'évident risque que tout le monde va le charger et personne l'acheter !

 

Le XHTML peut aussi s'avérer utile dans certains cas si le site est construit sur une base XML avec une transformation XSL (pour ceux qui ne sauraient pas, le XSL permet de transformer du XML en un autre XML différent), il est nettement plus facile de sortir du XHTML.

 

Le XML ! Ce n'est pas du code, c'est un standard pondu par le W3C !!!

 

On pourrait même dire une simple syntaxe il me semble !

 

Il est le "fils" du GML d'IBM, dont le langage balisé s'appelait SGML (c'est à dire Script GML). J'ai encore toute la doc GML et SGML dans mes cartons, je la garde comme "archives très précieuses" (et lui avoir fait faire 20 000 km montre à quel point j'y tiens). Ce XML est donc un standard pour des langages balisés servant à présenter (mettre en forme) des données suivant le média utilisé... et donc pas forcément destinées (les données) au WEB... je dirai même plus : lorsqu'elles ne sont pas destinées au web !

 

De nombreux programmes l'utilisent effectivement pour stocker des données en particulier dans des formats ouverts (ou pas). C'est vrai que le web est presque marginal.

 

Je suis bien d'accord avec Calimo lorsqu'il dit que l'interpréteur (de IE) doit s'arrêter sur les erreurs (en XHTML) !

 

L'analyseur XML le fait très bien ! La seule chose qu'il manque à mon avis c'est une feuille de style appropriée pour le XHTML. Rien de plus !

 

En conclusion, en dehors de besoins très particuliers, vous n'avez pas à basculer vos pages en XHTML, contentez-vous de faire du code propre et de nous transmettre vos informations.

Tout à fait !

 

Et bien fait si des pages en ligne sont illisibles car en XHTML merdeux !

C'est-à-dire envoyées comme du HTML ! Erreur trop fréquente, il n'y a pas à dire

 

 

Perso, ayant fait mon premier site en 96 en autodidacte, j'ai vite compris l'utilité des CSS pour alléger le code sur des styles complexes et modifier toute l'apparence de mon site via un seul fichier.

Mais les pages sont plus légère avec un <b>...</b> qu'avec <span class="bold">....</span> + un style définit dans la CSS alors je suis plus pour du HTML transitionel que pour le XML/XHTML.

 

Il faut dire que ce n'est pas du tout prévu pour ! Et à voir comme ça ton <span class="bold"> est encore plus déplacé que ton <b> original !

Le but est d'utiliser les bonnes balises pour donner du sens au contenu. <b> ce n'est pas du sens, c'est du graphisme. "Gras" ça ne veut rien dire si ce n'est visuellement. <span class="bold"> est une abération, car tu enlève tout sens au code. Un <span> n'a aucune signification. Et si ta page est découplée de sa CSS tout est perdu.

[Jimi]

( suite du post de Calimo )

 

Voyons la suite qui est fortement liée :

Heureusement, avec le XHTML, tu peux mettre en gras avec la balise <strong> et en italique avec <em>. Ca ne change pas trop. Mais c'est vrai, le strict nous pompe grave, tout de même.

<{POST_SNAPBACK}>

 

Ah ! Je l'attendais celle-là. C'est l'erreur classique.

 

<stong> ne signifie en aucun cas "gras". Strong signifie "forte emphase". Il se trouve, et c'est bien malheureux, que cela est rendu en gras dans les navigateurs graphiques. Mais la mise en gras n'est qu'un moyen (commode) qu'utilisent (par défaut) les navigateurs graphiques pour montrer à l'utilisateur que "ce morceau de texte est important". Dans un lecteur d'écran, <stong> sera rendu par une fort intonnation. Dans les plages brailles je ne sais pas, peut-être par un relief plus marqué ou que sais-je...

Pour <em> c'est simplement "emphase". Pareil, c'est rendu en italiques dans les navigateurs graphiques, différemment ailleurs... mais ce n'est pas ce qui compte, ce qui compte c'est l'accentuation. L'italique n'en est que l'effet secondaire.

 

Donc le strict ce n'est pas simplement là pour "pomper l'air", c'est pour pousser à réfléchir à quel est le sens de ceci et peut-être à pousser les gens à arrêter de penser uniquement "navigateur graphique". Il y a beaucoup d'alternatives. Le but est de se concentrer sur le contenu, et d'arrêter de penser uniquement "graphiquement". Code plus propre, mais surtout plus accessible. Comment rendre du gras, qui est typiquement un effet graphique, dans un navigateur non graphique ? Il n'a de sens que graphiquement. Pas de bol pour les autres.

 

Alors webmasters, libérez-vous de votre carcan de "pensée graphique" et pensez au sens de ce que vous faites !

 

PS : <b> et <i> sont tout à fait autorisés en "strict"

 

Edition : désolé pour les citations, je n'arrive pas à savoir ce qui se passe

 

edit : le fourm pete un plomb si on depasse les 10 citations , apres essai je me suis permi de couper le mess pour que ton travail soit plus comprehensible. Jimi.