Il y a un énorme engouement pour HTML5, sa sémantique, ses nouveautés,... et beaucoup de personnes aimeraient en faire usage dès maintenant.
Le problème (comme toujours) est IE (toute version), qui ne reconnaît tout simplement pas les éléments HTML5 et ne les intègre pas à son DOM.
Néanmoins il existe des solutions : La *"mauvaise"* solution en JS, qui consiste à déclarer chaque élément utilisé en début du fichier HTML, ce qui n'est pas recommandable en terme de maintenabilité (il faut écrire chaque élément utilisé) et d'accessibilité (ceux qui n'auront pas JS auront tout simplement un site explosé). <!--[if IE]> <script> document.createElement("header"); document.createElement("footer"); document.createElement("nav"); document.createElement("article"); document.createElement("section"); </script> <![endif]-->
La *"bonne"*, qui consiste à utiliser le préfixe html pour déclarer l'élément dans son namespace, ce qui a pour avantage de garder le site accessible à tout le monde, mais de rendre le code moins lisible... <html:header>Ceci est un header</html:header>
Et finalement *l'idée*, qui consisterai à servir les éléments HTML avec ce préfixe uniquement pour IE, le code serait réécrit par un moteur en back-end.
Vous en pensez quoi ? On pourrait se baser sur quelque chose d'existant pour développer cela ? Ou peut-être quelqu'un l'a déjà codé?
> Néanmoins il existe des solutions : > La *"mauvaise"* solution en JS, qui consiste à déclarer chaque élément > utilisé en début du fichier HTML, ce qui n'est pas recommandable en terme de > maintenabilité (il faut écrire chaque élément utilisé) et d'accessibilité > (ceux qui n'auront pas JS auront tout simplement un site explosé). > <!--[if IE]> > <script> > document.createElement("header"); > document.createElement("footer"); > document.createElement("nav"); > document.createElement("article"); > document.createElement("section"); > </script> > <![endif]-->
> La *"bonne"*, qui consiste à utiliser le préfixe html pour déclarer > l'élément dans son namespace, ce qui a pour avantage de garder le site > accessible à tout le monde, mais de rendre le code moins lisible... > <html:header>Ceci est un header</html:header>
> Et finalement *l'idée*, qui consisterai à servir les éléments HTML avec ce > préfixe uniquement pour IE, le code serait réécrit par un moteur en > back-end.
> Vous en pensez quoi ?
Ca me rappelle un post de John Resig qui suggérait cette technique pour créer la balise ABBR pour IE6. Franchement, je trouve que la "mauvaise" solutin est une bonne idée ;)
Quant à la "bonne" solution, je ne suis pas très chaud, car une des raisons d'adopter html5 est l'amélioration de la lisibilité du code à produire ^^
Mais bon, à la fin, faut voir comment on gère les navigateurs avec JS désactivé.
Bon, comme on me tanne sur un chan IRC que je ne nommerais pas pour
que je réponde, je vais le faire.
Si vous voulez faire du HTML5, c'est normalement pour aller de l'avant
et utiliser des nouveautés du langage. Donc vous êtes prêt à faire des
compromis puisque vous utilisez une spec en cours de rédaction, pas
finalisée avant un an au moins. Je trouve du coup complètement contre
productif d'essayer de filer une expérience identique à des
navigateurs à la bourre.
Mon avis, soit vous acceptez de vous appuyez sur la solution
Javascript, qui fonctionnera pour un bon nombre des utilisateurs IE,
soit vous utiliser des commentaires conditionnels pour déclarer vos
appels CSS. Les pauvres avec leur IE verront le site brut mais il
restera "accessible". On peut même combiner les deux solutions :
déclarer les CSS en commentaires conditionnels et les insérer en
javascript pour les utilisateurs de IE. Comme ça tout le monde à la
meilleure expérience sans que le développeur ne se casse trop la tête.
Car c'est un peu le but en utilisant HTML5.
Le 15 juil. 09 à 14:23, Yves Van Goethem a écrit :
> Il y a un énorme engouement pour HTML5, sa sémantique, ses
> nouveautés,... et beaucoup de personnes aimeraient en faire usage
> dès maintenant.
> Le problème (comme toujours) est IE (toute version), qui ne
> reconnaît tout simplement pas les éléments HTML5 et ne les intègre
> pas à son DOM.
> Néanmoins il existe des solutions :
> La "mauvaise" solution en JS, qui consiste à déclarer chaque élément
> utilisé en début du fichier HTML, ce qui n'est pas recommandable en
> terme de maintenabilité (il faut écrire chaque élément utilisé) et
> d'accessibilité (ceux qui n'auront pas JS auront tout simplement un
> site explosé).
> <!--[if IE]>
> <script>
> document.createElement("header");
> document.createElement("footer");
> document.createElement("nav");
> document.createElement("article");
> document.createElement("section");
> </script>
> <![endif]-->
> La "bonne", qui consiste à utiliser le préfixe html pour déclarer
> l'élément dans son namespace, ce qui a pour avantage de garder le
> site accessible à tout le monde, mais de rendre le code moins
> lisible...
> <html:header>Ceci est un header</html:header>
> Et finalement l'idée, qui consisterai à servir les éléments HTML
> avec ce préfixe uniquement pour IE, le code serait réécrit par un
> moteur en back-end.
> Vous en pensez quoi ?
> On pourrait se baser sur quelque chose d'existant pour développer
> cela ?
> Ou peut-être quelqu'un l'a déjà codé?
Personnellement, j'aurai tendance à ne pas utiliser HTML5 avant un
bout, sauf si je souhaitai utiliser une de ses fonctionnalités comme
canvas, video, audio ou autre dans un service web innovant quitte à ne
m'adresser qu'à une partie des internautes.
On en sait assez peu finalement sur la façon dont le doctype html5 et
les éléments nouveaux seront interprétés par les anciens navigateurs
et même les récents (par exemple, les balises footer, section etc..
sont-elles déjà exploitées par les navigateurs ?). Vous connaissez un
endroit ou on pourrait trouver des tests etc ... ?
Car utiliser HTML5 pour utiliser HTML5, c'est un peu du temps perdu.
C'est marrant, j'ai jamais été très chaud pour adopter ce type de pratiques.
pour moi il est paradoxale d'utiliser des des specs du W3C qui ne sont pas
prises en compte par l'ensemble les principaux navigateurs (en terme
d'audience, ie se pose là, malheureusement).
C'est là que le paradoxe du monteur rentre en compte, faut il utiliser les
toutes dernières technologies quitte à faire des pieds et des mains pour les
adapter aux navigateurs obsolètes ou faut-il mieux se raisonner et utiliser
des technos transverses qui nécessitent déjà de faire des pieds et des mains
pour qu'ils soient pris en compte de la même manière sur touts les
navigateurs ?
pour ma part, j'utilise le html5 pour faire des expériences le dimanche dans
mon garage.
> Personnellement, j'aurai tendance à ne pas utiliser HTML5 avant un
> bout, sauf si je souhaitai utiliser une de ses fonctionnalités comme
> canvas, video, audio ou autre dans un service web innovant quitte à ne
> m'adresser qu'à une partie des internautes.
> On en sait assez peu finalement sur la façon dont le doctype html5 et
> les éléments nouveaux seront interprétés par les anciens navigateurs
> et même les récents (par exemple, les balises footer, section etc..
> sont-elles déjà exploitées par les navigateurs ?). Vous connaissez un
> endroit ou on pourrait trouver des tests etc ... ?
> Car utiliser HTML5 pour utiliser HTML5, c'est un peu du temps perdu.
Au contraire, on en sait beaucoup sur ce que font les navigateurs.
Puisque lors de l'écriture de la spec, tous ces aspects ont été pris
en compte.
<!doctype html> passe tous les navigateurs en mode standard sauf IE
qui est en almost standards (et NS6 en quirks mais bon, hein) . (cf http://hsivonen.iki.fi/doctype/) .
Les nouveaux éléments sont très bien reconnus par tout le monde sauf
IE (d'où ce thread) et Firefox2 (cf http://html5doctor.com/how-to-get-html5-working-in-ie-and-firefox-2/) . La seule chose qu'il ne faut pas oublier, c'est de rajouter un
display: block; puisqu'ils ne sont pas déclarés ainsi dans la feuille
de style par défaut des navigateurs.
Le 15 juil. 09 à 15:04, nicolas_froidure a écrit :
> Personnellement, j'aurai tendance à ne pas utiliser HTML5 avant un
> bout, sauf si je souhaitai utiliser une de ses fonctionnalités comme
> canvas, video, audio ou autre dans un service web innovant quitte à ne
> m'adresser qu'à une partie des internautes.
> On en sait assez peu finalement sur la façon dont le doctype html5 et
> les éléments nouveaux seront interprétés par les anciens navigateurs
> et même les récents (par exemple, les balises footer, section etc..
> sont-elles déjà exploitées par les navigateurs ?). Vous connaissez un
> endroit ou on pourrait trouver des tests etc ... ?
> Car utiliser HTML5 pour utiliser HTML5, c'est un peu du temps perdu.
Je me permets de partager ce commentaire de Victor Brito (http://
blog.britoweb.net/) laissé sur ce billet (http://www.css4design.com/ blog/dom-vs-namespace-pour-implementer-html5-sur-ie6-ie7-firefox2-
camino-etc) :
> Pour avoir l’équivalent en PHP de ce que préconise John Resig en JavaScript,
> on peut utiliser l’extension DOM de PHP,
> qui permet même de manipuler des espaces de noms :
> http://www.php.net/manual/fr/book.dom.php
Ce qui permettrait de ne pas dépendre de la présence de javascript
pour créer les éléments HTML5 dans le navigateur tout en simplifiant
peut-être le dévelopement du script côté serveur.
Je suis désolé du ton que je vais employer mais ça m'a fait
tellement susrauter. J'ai rarement vu plus grosse connerie que ce que
je viens de lire. Sérieusement, changez de travail ou renseignez vous
un peu sur votre métier. Ça vaut pour Bruno et Victor.
Le 18 juil. 2009 à 14:55, "bruno bichet (br1o)"
<infographi...@gmail.com> a écrit :
> Je me permets de partager ce commentaire de Victor Brito (http://
> blog.britoweb.net/) laissé sur ce billet (http://www.css4design.com/ > blog/dom-vs-namespace-pour-implementer-html5-sur-ie6-ie7-firefox2-
> camino-etc) :
>> Pour avoir l’équivalent en PHP de ce que préconise John Resig en
>> JavaScript,
>> on peut utiliser l’extension DOM de PHP,
>> qui permet même de manipuler des espaces de noms :
>> http://www.php.net/manual/fr/book.dom.php
> Ce qui permettrait de ne pas dépendre de la présence de javascript
> pour créer les éléments HTML5 dans le navigateur tout en simplifia > nt
> peut-être le dévelopement du script côté serveur.
Peut-être, en ce qui me concerne je ne sais pas.
Il faudrait donc argumenter un peu pour l'édification des masses laborieuses, et pour ne pas donner l'impression d'une attaque gratuite et sans fondement...
> Je suis désolé du ton que je vais employer mais ça m'a fait
> tellement susrauter. J'ai rarement vu plus grosse connerie que ce que
> je viens de lire. Sérieusement, changez de travail ou renseignez vous
> un peu sur votre métier. Ça vaut pour Bruno et Victor.
> Le 18 juil. 2009 à 14:55, "bruno bichet (br1o)"
> <infographi...@gmail.com> a écrit :
>> Je me permets de partager ce commentaire de Victor Brito (http://
>> blog.britoweb.net/) laissé sur ce billet (http://www.css4design.com/ >> blog/dom-vs-namespace-pour-implementer-html5-sur-ie6-ie7-firefox2-
>> camino-etc) :
>>> Pour avoir l’équivalent en PHP de ce que préconise John Resig en
>>> JavaScript,
>>> on peut utiliser l’extension DOM de PHP,
>>> qui permet même de manipuler des espaces de noms :
>>> http://www.php.net/manual/fr/book.dom.php
>> Ce qui permettrait de ne pas dépendre de la présence de javascript
>> pour créer les éléments HTML5 dans le navigateur tout en simplifia >> nt
>> peut-être le dévelopement du script côté serveur.
Il y a un principe un peu essentiel dans nos métiers : client-serveur.
Ce qui se passe sur le serveur est inconnu du client. Que la page soit
statique, générée par PHP, ASP, brainfuck ou LOLCODE le navigateur
n'en sait rien (hormis peut-être quelques headers).
Du coup, faudra m'expliquer comment une extension DOM PHP va pouvoir
changer le comportement de IE.
> Peut-être, en ce qui me concerne je ne sais pas.
> Il faudrait donc argumenter un peu pour l'édification des masses
> laborieuses, et pour ne pas donner l'impression d'une attaque
> gratuite et sans fondement...
>> Je suis désolé du ton que je vais employer mais ça m'a fait
>> tellement susrauter. J'ai rarement vu plus grosse connerie que ce que
>> je viens de lire. Sérieusement, changez de travail ou renseignez vous
>> un peu sur votre métier. Ça vaut pour Bruno et Victor.
>> Le 18 juil. 2009 à 14:55, "bruno bichet (br1o)"
>> <infographi...@gmail.com> a écrit :
>>> Je me permets de partager ce commentaire de Victor Brito (http://
>>> blog.britoweb.net/) laissé sur ce billet (http://www.css4design.com/ >>> blog/dom-vs-namespace-pour-implementer-html5-sur-ie6-ie7-firefox2-
>>> camino-etc) :
>>>> Pour avoir l’équivalent en PHP de ce que préconise John Resig en
>>>> JavaScript,
>>>> on peut utiliser l’extension DOM de PHP,
>>>> qui permet même de manipuler des espaces de noms :
>>>> http://www.php.net/manual/fr/book.dom.php
>>> Ce qui permettrait de ne pas dépendre de la présence de javascript
>>> pour créer les éléments HTML5 dans le navigateur tout en simplifia
>>> nt
>>> peut-être le dévelopement du script côté serveur.
Anthony, ne sois pas si catégorique, il est tout à fait possible de
détecter le user-agent côté serveur. Le seul problème, c'est que c'est
peut-être un peu moins fiable que côté client et que ça complique le
cache HTML s'il il y en a un.
Pour préciser, ce que suggère Victor Brito, ce n'est pas de changer le
comportement du navigateur, mais de produire le code HTML qui va être
adapté au comportement du navigateur.
HTML 4.01 est adapté au comportement du navigateur. Faites votre site
perso avec la techno qui vous chante, le site de votre projet aussi on
s'en tape le cocotier. Certains n'ont pas attendu l'accord de
quiconque… http://intertwingly.net/blog/, http://diveintomark.org/, …
(ajouter votre nom ici si vous être un bloggeur influent)
Cette réalité est déjà une jungle sans nom où chaque hack (la
détection du navigateur ça n'est pas beau, car j'ai l'air fin avec mon
: “Midori/0.1.5 (X11; Linux; U; de-ch) WebKit/532+” bref, vous avez dû
entendre parlé de : jQuery.support, c'est bon mangez-en
http://docs.jquery.com/Utilities/jQuery.support
Donc en sommes, on s'en moque. Mais utiliser une spéc en cours de
rédaction c'est un peu comme manger du pain sorti du four, si c'est
excellent et croustillant, c'est tout de même indigeste (le pain juste
cuit) et on peut le regretter. Et, oui, j'ai utilisé ce type de hacks
là : http://www.workingwith.me.uk/articles/scripting/mimetypes (pour
servir du XHTML 1.1)
Rien à dire, c'était vraiment bien d'être en avance sur son époque, mouarf ;-)
Il est possible de se servir des "nouveaux" éléments via les landmarks
ARIA dans de l'HTML actuel, c'est supporté par Firefox 3.x, MSIE 8 et
Opera (mais personne ne s'en sert[1]) :
http://www.paciellogroup.com/blog/?p=106
> Pour préciser, ce que suggère Victor Brito, ce n'est pas de changer le
> comportement du navigateur, mais de produire le code HTML qui va être
> adapté au comportement du navigateur.
|
