5 réflexions au sujet de « Créer un site web en XHTML et en CSS »

  1. Bonjour,

    Je voulais revenir sur cette vidéo simplement pour dire qu’il fallait arrêter de dire aux ‘tits jeunes qui débutent que le xhtml, c’est beau, c’est à la mode, tout ça, alors qu’au final, vous le faites passer pour html (dans le ) pour qu’il soit lu par n’importe quel navigateur. Le W3C s’est plus ou moins gouré en faisant du xhtml, et il n’est pas « has been » ou quoique ce soit de continuer à faire du html 4.01 strict.

    Si encore, vous faisiez du xhtml en le déclarant xml, là, okay, mais vous connaissez tous les talents de internet explorer (étant le navigateur favori de la majorité des internautes… malheureusement), « le xml ? comprends pas. »

    Donc faites donc un pas en arrière (et c’est qu’une remise en cause, pas une regression), et utilisez du html pour vos sites web si vous voulez être vraiment compatible, ou sinon xhtml mais en tant que xml.

    Si vous avez un peu de temps devant vous ou/et que vous êtes curieux, lisez donc ceci : http://www.hixie.ch/advocacy/xhtml.fr/ , très bon dossier.

    Sinon, quant au reste de la vidéo, très sympa. Design appréciable, tuto plutôt clair, bien quoi. :)

  2. @Kud: Effectivement, le tuto en question montre le prologue XML en début de document, ce qui n’est pas nécessaire pour déclarer l’encodage, vu que plus loin, cette opération est répétée dans le « content-type ».

    Mais plus loin, on a bien le document servi en tant que text/html avec la balise Meta suivante :

    <meta http-equiv="content-type" content="text/html; charset=UTF-8" />

    Merci pour le lien concernant le le xhtml (que je connaissais déjà, mais il n’est jamais inutile de le relire).

    Une des choses que l’auteur juge néfaste c’est :

    Voici ce qui arrive généralement aux auteurs qui décident d’envoyer du XHTML en tant que text/html :

    Un auteur écrit du XHTML en se fondant sur des pratiques uniquement valides pour des agents utilisateurs HTML4 ou « soupe de balises », mais pas pour les agents utilisateurs XHTML, et l’envoie avec le type text/html. (Ces pratiquent sont répertoriées plus bas).
    Cet auteur constate que tout fonctionne bien.
    Le temps passe.
    L’auteur décide d’envoyer le même contenu en tant que application/xhtml+xml parce que, après tout, c’est du XHTML.
    L’auteur découvre que son site plante horriblement (voir la liste d’explications ci-dessous).
    L’auteur accuse le XHTML.

    Tout les personnes avec qui j’ai parlé ont vécu les étapes 1 à 5 lors de leur passage au type MIME de XHTML. Si l’étape 6 a pu être évitée dans ces cas précis, c’est uniquement parce qu’il s’agissait d’auteurs avancés, à même de comprendre comment réparer leur contenu.

    Pour ma part, je ne change pas le type Mime après avoir constaté que tout se passe bien pour ma page une fois servie en text/html 😉

  3. « Mais plus loin, on a bien le document servi en tant que text/html avec la balise Meta suivante :

    C’est tout là le problème, il fait du xhtml servi en html et non xml. :/

    Mais de toute façon, le xhtml était un peu trop précipité à mon goût, et j’ai hâte de voir le html 5 et css 3 supportés par les navigateurs dont IE.

  4. @Kud: Oui, mais rien n’interdit de servir du XHTML en text/html, d’ailleurs, comme tu le vois, il y a une balise meta pour ça.

    HTML5 vs XHTML = TABLE vs DIV+CSS ?

    Le problème, c’est que dès le départ le XHTML a eu mauvaise presse auprès des webmasters qui regrettaient la « souplesse » du HTML et le laxisme des navigateurs vis-à-vis des entorses faites à la bonne syntaxe.

    C’est un peu ce qui aurait pu se passer avec l’arrivée de la mise en page avec les CSS vs les tableaux à une époque où les CSS représentait une modernité contraignante par rapport à la souplesse des tableaux pour le design web.

    Les CSS ont gagné sur tous les tableaux (humour 2.0), ce qui n’est pas le cas du XHTML qui a vu ses opposants grandir au point qu’un retour aux « sources » du HTML est en marche avec HTML 5.

    Le projet XHTML n’est pas exempt de défauts, certes, mais au moins on a là un langage qui ne dit rien de ce qui doit être représenté : souplesse maximale.

    Je ne dis pas que HTML 5 n’apporte(ra) rien, mais bon, soyons raisonnable : y a t’il une chance pour que le rendu d’une balise :

    <header></header>

    ou même

    <header />

    soit mieux qu’un bon vieux

    <div id="header"></div>

    Il y a du bon dans HTML5

    Ceci dit, je ne jette pas le bébé avec l’eau du bain, et le jour où HTML5 sera disponible en production, je me jetterai à l’eau et y trouverai certainement des avantages.

    D’autant plus que si je prends la casquette formateur web et non plus seulement intégrateur web, l’apprentissage du langage sera dans doute plus facile à faire passer auprès des apprenants.

    J’ai d’ailleurs une « méthode » de formation qui part grosso modo du découpage visuel de la page web et qui se rapproche des nouvelles balises de structuration du contenu qui font leur apparition avec HTML 5.

    La balise en carton ?

    Dans ma pratique de l’intégration web, je reste toujours un peu en retrait des nouveautés car je leur laisse le temps de faire leurs preuves auprès des navigateurs : peu me chaut d’avoir une belle balise à disposition, si 80% des utilisateurs ne peuvent en profiter !

Les commentaires sont fermés.