Internet : Le W3C met en route le premier brouillon de HTML 5
Posté par zchark (page perso, ). Modéré le 23 janvier 2008.
Les nouvelles fonctionnalités les plus intéressantes : API pour dessiner des graphiques en deux dimensions, embarquement et contrôle des contenus audio et vidéo, maintient de stockage de données côté client pour permettre aux utilisateurs d'éditer des documents ou des parties de document de manière interactive.
Rappelons que le HTML 4 a fêté ses 10 ans en décembre 2007, une éternité en informatique, particulièrement le domaine du web. Quant au XHTML 2.0, il est jugé trop compliqué et trop peu accessible pour la plupart des personnes amenées à publier sur le Web. Le XHTML 2.0 semble donc être abandonné.
![[en]](../images/en.png)
Annonce du HTML 5 (386 hits)-
Différences ente HTML 4 et HTML 5 (743 hits)
-
Nouveaux éléments du HTML 5 (420 hits)
-
Nouveaux attributs du HTML 5 (259 hits)
![[fr]](../images/fr.png)
Blog de Laurent Jouanneau : « Premier brouillon de HTML5 » (875 hits)
> Lire la dépêche (119 commentaires, moyenne: 2,9).
Vous avez demandé le commentaire #898997.
Run by 
Cette page a été générée par Templeet en 0.1341s (dont 0.0114 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Plus que sceptique
J'étais très enthousiaste la première fois où j'ai vu XHTML2, je me disais qu'enfin, on avait pris la bonne direction, en abandonnant plein de boulets de HTML : obligation de la syntaxe XML, uniquement des balises sémantiques, etc. Bref, ce qu'aurait du être HTML dès le départ. Et XHTML1 représentait une très bonne transition entre les deux, à mon sens, en conservant encore pour quelques temps des balises qui n'avait plus lieu d'exister.
Et là, patatras, HTML5 arrive et remet tout ça en cause. Alors oui, on "peut" faire du XML avec HTML5, mais il ne faut pas rêver, les concepteurs ne vont pas s'amuser à aller vérifier la validité XML de leurs pages s'ils n'y sont pas obligés. Les trucs que je trouvais sympa dans XHTML2 et qui ont disparu dans HTML5 :
- la balise h qui permettait de ne pas spécifier de nombre après et qui, en combinaison avec la balise section donnait des trucs vraiment bien structuré [1]
- la balise l qui permettait de spécifier une ligne sémantique [2]
Mais surtout, parmi les horreurs de HTML5, j'ai vu :
- le détournement du sens de dt et dl où le d pourra signifier definition (comme en (X)HTML) mais aussi maintenant dialog, des éléments schizophrène donc. Ça va être simple d'apprendre le HTML5 : ça veut dire quoi dt ? ben le d veut dire : ça Dépend...
- la redéfinition de balises anciennes qui aurait dû disparaître, ce qui ne va pas améliorer ni leur abandon, ni leur compréhension : b, i, small
- la floppée de nouvelles balises inutile dans 99% des cas (aussi appelé Docbookisation de HTML) : progress, meter, etc.
- la disparition de la balise acronym : c'est peut-être anecdotique mais bon, moi je l'aimais bien et je l'utilisais. DokuWiki aussi génère automatiquement des balises acronym aussi pour un certain nombre d'acronymes qu'il connaît (genre SQL, IRC, etc). C'est une balise sémantique que je regretterai.
- la disparition de l'attribut style qui était fort pratique pour un style ponctuel mais souvent mal utilisé, je le reconnais.
- la disparition de l'attribut align dans la balise table : faudra m'expliquer comment, en CSS, je centre un tableau sans mettre de balise div autour et sans centrer tout mon texte. Idem pour l'attribut valign.
- le meilleur pour la fin : le retour de la balise font où on nous dit qu'on n'a pas le droit de l'utiliser, sauf si on est un éditeur WYSIWYG (un peu dans le genre du CPE, c'est publié mais vous ne devez pas l'utiliser). vu le nombre de personne qui utilise des Frontpage ou même des Word pour générer du HTML, on n'est pas près de voir disparaître ce truc infâme. On nous dit que les outils ne savent pas faire autrement ; et bien qu'ils apprennent à faire autrement mais qu'on ne nous ressortent pas ce cadavre qui était en voie d'extinction !
Bref, je suis vraiment très très très très sceptique et les avancées de HTML5 (je les ai pas commentées, d'autres l'ont fait avant) comme canvas ou nav ou header/footer ou audio/video ou même les nouveaux type d'input ne feront pas oublier toutes les horreurs/erreurs présentes et qui ne favoriseront pas les bonnes pratiques du web, à mon avis.
[1] http://www.w3.org/TR/xhtml2/mod-structural.html#edef_structu(...)
[2] http://www.w3.org/TR/xhtml2/mod-text.html#sec_9.7.
[^]Re: Plus que sceptique
J'avais juste oublié une petite chose que j'aurais aimé voir aussi en HTML5 : c'est l'inclusion de document externe.
Parce que, quand on fait un petit site statique et qu'on veut mettre un menu, il faut recopier ce menu partout, au risque de devoir tout recommencer si on changer le menu. Une simple balise include permettrait de résoudre ce problème et d'éviter de devoir utiliser un PHP pour pouvoir faire des choses proprement et simplement.
En XHTML, je pense qu'on pourrait utiliser XInclude [1] qui est justement fait pour ça (ça marche pour tous les documents XML). Mais je n'ai jamais vérifié si c'était implémenté par les navigateurs, je vérifierai à l'occasion mais j'ai vraiment des doutes.
Donc pas d'inclusion encore pour cette fois.
[1] http://www.w3.org/TR/xinclude/
[^]Re: Plus que sceptique
C'est un vrai manque.
Les frames proposaient une solution (je ne dis pas la meilleure solution) mais je doute qu'elles fassent partie de la norme.
Mais malhereusement comme beaucoup de site utilise des outils comme PHP, ça ne dérange pas grand monde. Mais perso, je préfère un site statique (sauf si il y a vraiment un besoin) et j'aimerais que la norme prévoie plus de choses pour ces sites.
- Les includes
- Pourquoi pas un format de menu standard (HTML ?) qui pourrait être lié par une balise <link> et affiché dans la sidebar du navigateur
- Pourquoi pas un moyen standard de proposer des commentaires sur une page (une balise <link> qui donne l'adresse d'une page qui recevra le commentaire, et affichera les commentaires présents, avec affichage dans une zone séparée du navigateur par exemple)
- et on peut imaginer plein d'autres choses.
A mon avis beaucoup des pages dynamiques actuelles pourraient être remplacées par une norme qui va bien implémentée dans le navigateur. Par exemple a quoi servent les wiki actuels alors que la commande HTTP PUT existe depuis le début ? (et que les premiers navigateurs proposaient aussi un éditeur HTML en même temps).
A mon avis, ce serait moins confus pour l'utilisateur qui aurait toujours la même interface devant lui pour ajouter une commentaire sur la page, modifier la page d'un wiki, ...
La Roue du Temps
[^]Re: Plus que sceptique
heu vi mais les wiki tentent aussi de rendre l'édition un peu plus facile qu'en html...
Pour ce qui est des includes et menu, pourquoi pas.
Mais je vois pas trop pour les commentaires.
A partir de là on est justement plus dans un site au contenu statique.
Et dans tous les cas il faut bien que le serveur recoive qq chose.
Dans un site statique, le serveur ne fait justement qur fournir.
Du moment qu'on rajoute des commentaires ou autre, il faut aussi réceptionner, enregistrer, ... les données
[^]Re: Plus que sceptique
On est dans le même cas qu'une page statique avec un formulaire renvoyant sur un script CGI.
Avec ce genre de système, on peut avoir un site complètement statique avec quelques petits scripts CGI dans un coin ... On peut même utiliser un prestataire extérieur pour le CGI et garder un site entièrement statique.
Et un site statique, ça consomme moins de ressources.
La Roue du Temps
[^]Re: Plus que sceptique
Sinon à la place de XInclude, peut-être qu'un truc du genre :
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html [
<!ENTITY header SYSTEM "file:../build-common.inc">
]>
<html>
&header;
</html>
Si tu as le temps, tu peux essayer et nous donner tes conclusions ? :)
Merci.
[^]Re: Plus que sceptique
J'utilisais une astuce similaire pour encoder le @ des emails ... et ça ne semble marcher qu'avec gecko, et que lorsque c'est du xhtml (Content-Type application/xhtml+xml).
Vous pouvez tester:
http://mildred632.free.fr/test/test.html
http://mildred632.free.fr/test/test.xhtml
http://mildred632.free.fr/test/test2.html
http://mildred632.free.fr/test/test2.xhtml
http://mildred632.free.fr/test/test3.html
http://mildred632.free.fr/test/test3.xhtml
La Roue du Temps
[^]Re: Plus que sceptique
La balise object dois pouvoir faire ça il me semble.
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.
[^]Re: Plus que sceptique
Et ça fait un joli cadre de taille fixe avec des assenceurs pour présenter le contenu... ça ne rentre pas dans le flot de la page.
(pub: Livres à prix réduit sur http://www.sollire.com/ - la boutique de mes petites soeurs)
[^]Re: Plus que sceptique
http://psychoslave.free.fr/test/
Ça m'a l'air de fonctionner, et en définissant la taille de l'object (attribut width) plutôt que celle du body du fichier que j'inclus, je n'ai pas eu d'assenceur. Bon je dis pas qu'il n'y pas de possibilité de problème sur d'autres navigateurs, où avec des styles un peu plus poussés, où peut être que je n'ai même pas compris le problème que tu voulais signaler avec cette solution, mais ça m'a l'air de fonctionner.
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.
[^]Re: Plus que sceptique
Et est-ce que les liens du menu vont juste ouvrir une nouvelle page dans le cadre du menu ou dans la fenêtre entière ? De toute façon, comme je ne pense pas que ce soit standardisé (la manière de suivre les liens avec la balist object) ce n'est pas vraiment utilisable.
La Roue du Temps
[^]Re: Plus que sceptique
Par défaut le lien s'ouvre dans le cadre courant, donc à l'intérieur de la balise object. Cependant il suffit d'ajouter un target="_top" à ton ancre et le tour est joué, ce qui est normalisé. Je t'ai mis à jour mon exemple pour montrer les différents comportements possibles pour un lien en fonction de la cible (target) définie.
En tout cas, preuve est faite qu'inclure des documents externes, c'est tout ça fait faisable. Attention, je ne dis pas que ça s'intégrera toujours bien toujours comme on s'y attend. Je ne dis pas le contraire non plus. Je n'ai jamais vraiment utilisé la balise object en production, parceque je n'en jamais eu besoin.
Mais je sais qu'elle existe si un jour j'en ai besoin. Le but ici était simplement de signaler à rewind que contrairement à ce qu'il pensais, inclure un document externe en HTML, c'est tout à fait possible. Cette solution à peut être des défauts (rien n'est parfait, donc on trouvera toujours à redire), mais elle à le mérite d'exister.
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.
[^]Re: Plus que sceptique
Merci pour cette démonstration.
Je trouve la solution un peu bancale quand même, c'est du détournement de balises. Et à vrai dire, je préfèrerais nettement que les navigateurs implémentent la toute petite norme XInclude, ce serait nettement plus clair et plus simple.
[^]Re: Plus que sceptique
* En quoi trouves-tu que je détournes une balise?
* Qu'est ce que tu trouves obscur et difficile dans cette solution?
* En quoi un XInclude serait plus adéquate, clair et simple?
Je ne l'avais jamais fait avant et ça n'a pas du me prendre plus d'une vingtaine de minutes en tout, je ne pense pas qu'on puisse dire que cela relève d'une extrême diffulté.
J'ai demandé à un pote de tester sous IE et ça à l'air de passer d'après ce qu'il me dit.
Un vrai problème c'est si le navigateur ne gère pas l'inclusion de document par la balise object. Par exemple links/lynx. Une solution peut être alors de simplement placer un lien vers la page menu entre les balises object, de manière à afficher ce lien si le navigateur ne gère pas l'inclusion. Bref, y a un mode dégradé très facile à mettre en place.
Je vois pas ce qu'on pourrait demander de plus à une balise d'inclusion en fait.
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.
[^]Re: Plus que sceptique
Enfin, ce n'est pas un vrai include ...
C'est comme une iframe (pas de différence a ce que je peux voir) ... Donc c'est un objet et cela ne s'intègre pas bien au flot de la page.
Pour mon site statique, j'utilise une astuce très intéressante pour les styles. Dans chaque répertoire, j'ai un fichier 'style.css'. Presque partout, mon fichier contient @import url(../style.css).
J'ai un style général (dans le répertoire racine) qui me définit mon style par défaut, et chaque répertoire peut alors dans son propre fichier de style, redéfinir des choses (comme les images pour la présentation).
Mes styles (c'est plus parlant):
http://mildred632.free.fr/who/style.css
http://mildred632.free.fr/wot/style.css
http://mildred632.free.fr/style.css
Et les différences de présentation:
http://mildred632.free.fr/wot/
http://mildred632.free.fr/
J'aimerais bien pouvoir faire pareil avec les menus, mais avec la balise <object>, j'ai deux problèmes:
- il faut spécifier dans chaque page la dimension du cadre (ou alors garder la valeur par défaut, mais qui n'est pas adaptée pour un menu)
- si je m'amuse a faire des inclusions comme ça en cascade, ça me rajoute une marge de environ 1em pour chaque niveau. Je suppose que je pourrais l'enlever complètement, mais cela implique ajouter encore des styles.
Et donc finalement l'opération d'inclusion devient très compliquée ... et tout l'interêt disparaît (car si on veut modifier quelques petites choses, il faudrait modifier tout les fichiers).
Ce serait bien une balise <include>, non ?
La Roue du Temps
[^]Re: Plus que sceptique
Bah une première différence avec les iframes, c'est qu'elles ne font pas de mode dégradé comme je l'explique ci-dessus. Du moins tout les sites avec des frames que j'ai pu voir affiche "votre navigateur ne gère pas les frames, allez vous faire poutrer par un ours", quand on a pas de gestion des frames. Avec la balise object utilisé comme dis ci-dessus, le contenu principale de la page est affiché, et les contenus qui ne peuvent être inclus par manque de fonctionnalité du navigateur sont toujours accessibles en suivant un lien.
Je ne comprends pas bien ce que tu essais de me dire par le "intégration au flot de la page" :\
- Bah la dimension du cadre est spécifie en css (dans mes pages d'exemple c'est du css incrusté avec l'attribut style, mais le mettre dans un css à part reviendrais au même), donc je ne comprends pas où est ton problème à ce niveau là.
- dans ton css racine tu mets "object .menu {padding:0px;margin0px;}", en imagineant que tu utilises , ça te paraît si lourd que ça comme style à ajouter? Éventuellement tu peux utiliser un id="menu" si tu comptes n'avoir qu'un menu par page.
Bah ça prend moins de temps à faire que de te poster cette réponse, par exemple. :)
Je crois que je n'ai pas saisie ce que tu entendais pas ton "flot de la page", et donc je ne comprends pas l'intérêt supplémentaire que peu représenter une balise . Si tu pouvais me donner un exemple d'une application tel que tu la voudrais, ça m'aiderais sans doute à mieux saisir cet intérêt. :)
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.
[^]Re: Plus que sceptique
> Je crois que je n'ai pas saisie ce que tu entendais pas ton "flot de la page",
Comment peux tu manipuler l'arbre DOM du menu depuis la page ?
Comment fais tu si tu veux que les règles de style de ta page s'appliquent à ton menu ? (hors d'inclure le même fichier CSS à la fois dans le menu et dans la page)
Comment fais tu pour un menu dont la taille change dynamiquement (cas des menus "déroulants") ?
La balise object, ce n'est qu'une grosse boite. Ça peut suffire pour des choses basiques, mais c'est franchement limité par rapport au modèle d'une forêt de boites qui prévaut en XHTML/CSS.
[^]Re: Plus que sceptique
Parfaitement ...
Tu ne peux pas t'amuser par exemple a inclure un fichier (pense aux #include du C) qui afficherait par exemple un titre en haut, un menu à droite et un bas de page (positionnés avec CSS position: absolute) dans un même fichier. Si tu veux le faire, tu dois include un fichier pour le titre, un autre pour le menu et un dernier pour le bas de page. Et encore, cela ne peux marcher que si ces 3 éléments ont la forme rectangulaire de la boîte <object>
De plus j'ai a rajouter que les iframes gèrent le mode dégradé aussi bien que la balise <object> ... De la même manière. Le texte est à mettre entre <iframe> et </iframe>
La Roue du Temps
[^]Re: Plus que sceptique
Et pourquoi pas utiliser ce qu'Apache met à disposition ?
C'est pas vraiment ce qu'on peut appeler une balise HTML, au contraire, mais ca a l'air plutot sympa.
Je n'ai pas testé, c'est un collègue qui vient de me faire suivre ca ...
[^]Re: Plus que sceptique
Alors oui, on "peut" faire du XML avec HTML5, mais il ne faut pas rêver, les concepteurs ne vont pas s'amuser à aller vérifier la validité XML de leurs pages s'ils n'y sont pas obligés.
Sauf que les seuls gens qui vont faire du XML avec du HTML 5 sont ceux qui seront intéressés par la création de pages XML valides. Les autres vont se contenter de faire du HTML 5, plus digeste (et mieux validé qu'avant).
faudra m'expliquer comment, en CSS, je centre un tableau sans mettre de balise div autour et sans centrer tout mon texte. Idem pour l'attribut valign
Euh sans tester comme ça là, par réflexe : si tu mets des marges auto à droite et à gauche (resp. en haut et en bas), ça ne centre pas ta table au sein de son élément père ?
[^]Re: Plus que sceptique
> Les autres vont se contenter de faire du HTML 5, plus digeste (et mieux validé qu'avant).
C'est ça que je ne comprends pas. Avoir voulu oublier la syntaxe SGML est probablement une très bonne décision. Et si j'ai bien compris, maintenant, il y a des règles de parsing défini dans la norme. Mais pourquoi ne pas avoir dit alors : le parsing se fera selon la norme XML ?
Non, là on a un truc bâtard entre la soupe de balise et le XML, genre "vous pouvez faire de la soupe de balise mais il faut quand même certaines règles", et pourquoi pas les règles XML ? elles sont si contraignantes que ça ? moi je ne crois pas, elles sont surtout très logique ! Allez dire à des gens : "bon des fois vous pouvez fermer vos balises mais c'est pas obligé et des fois vous devez le faire absolument sinon, ça foire", ils vont vous prendre pour un fou. Alors que dans le cas de XML : fermez vos balise, point, pas de discussion.
Enfin voilà, il faut m'expliquer l'intérêt d'une soupe de balise "mieux validée" mais pas XML.
[^]Re: Plus que sceptique
Le XML est très strict, probablement trop strict pour la plupart des sites.
Rien qu'avec l'intégration de code en provenance de régies publicitaires, on casse tout en général... Alors qu'un petit peu de souplesse du coté du parser peut résoudre beaucoup de situations « humainement » évidentes.
Et puis la plupart des gens ne sont pas des logiciens perfectionnistes. ;-)
Pour moi, il y a une place valable pour les deux.
[^]Re: Plus que sceptique
Oui, le XML est très contraignant.
Si on regarde comment les pages sont faites en PHP, le XML est trop contraignant. A une époque (et c'est peut être encore le cas) PHP ajoutait automatiquement des identifiants de sessions à tous les liens, en ajoutant un caractère '&' dans les liens. Sauf que ce caractère est interdit en XML et gecko affichait une jolie erreur d'un vert fluo très joli.
Et en plus comme moi j'avais un cookie de session, php ne modifiait pas les liens pour moi, et je n'avais pas l'erreur (mais les autres l'avaient toujours :( ).
Cela demande une rigeur de programmation qui est bien souvent absente. (Utilisez-vous htmlspecialchars() a chaque fois que vous voulez afficher un texte sur une page avec php ?)
Je pense que XML a très bien sa place, mais ne doit pas être généré comme le HTML l'(est actuellement. je considère que la meilleure façon de le générer est soit en passant par XSLT, soit par d'autres outils spécialisés dans le XML. mais pas en collant des bouts de droite et de gauche. Sinon, fatalement, on aura des erreurs quelque part.
le problème c'est que les solutions comme XSLT sont très lourdes a mettre en place, donc peu utilisées.
La Roue du Temps
[^]Re: Plus que sceptique
>Sauf que ce caractère est interdit en XML
Idem en HTML. Le & est un caractère réservé qui introduit une entité. Donc que ce soit en HTML ou XML, il faut utiliser & si on veut utiliser le caractère &.
Le fait que les navigateurs tolèrent l'utilisation du & tout seul n'est que pour être tolérant face aux développeurs indélicats...
[^]Re: Plus que sceptique
arf, il m'a bouffé mes &. Il faut lire "il faut utiliser &".
[^]Re: Plus que sceptique
Ouai, mais seulement ce genre de truc est un cauchemar à styler. Comment styler les titres de deuxième niveau par exemple, et uniquement de deuxième niveau ?
Et ce n'est pas un cauchemar seulement pour les développeurs web, mais aussi pour les implémenteurs des moteurs de rendu, d'après ce que j'avais lu. Cela apporte des problèmes mais je ne me rappel plus quoi.
http://www.w3.org/TR/2008/WD-html5-20080122/#dl
Le d veut dire description. Pour les dialogs, tu as maintenant une balise dialog. Pour les définitions, une balise dfn. Bref, je vois pas ce qu'il y a de schizophrène là dedans. C'est dans HTML4 que dl était schizo.
Je ne te comprend pas. Tu te plains que soit-disant on perd les avançées sémantiques de XHTML2, alors que ces balises justement, avec dialog et dfn par exemple que j'évoquais juste au dessus, apporte de la sémantique.
Bon sinon pour ton information, progress et meter peuvent être utilisé dans une interface d'application web. Et ça pourra être utile pour les applis qui prennent en charge le mode offline. Genre le mode online est de nouveau actif, l'appli va alors sauvegarder les infos modifiées pendant le offline, et donc pourra afficher simplement un progress pour indiquer à l'utilisateur qu'il est en cours de sauvegarde... (par exemple)
bah margin:auto sur la table...
Enfin bref. Il ne faut pas oublier que ce n'est qu'un brouillon. Des choses vont certainement disparaitre, ou réapparaitre, ou être modifié.
[^]Re: Plus que sceptique
1) je ne dis pas que la balise h est la panacée mais pour des gens qui ne veulent pas mettre des styles différents, c'est quand même utile et ça n'empêche pas d'utiliser h* pour des cas plus complexes.
2) ce n'était pas dt et dl mais dt et dd. dl garde son sens (= Definition List). Mais dt et dd prennent des sens différents : respectivement Definition Term et Definition Description pour dl et Speaker et Quote pour dialog [1]. D'où la schizophrénie.
3) je ne critique pas les balises sémantiques, loin de là, je critique le trop de balises sémantiques. ma question est : va-t-on créer une balise sémantique pour chaque truc que l'on veut ajouter ? si oui, ça va donner DocBook, si non on peut très bien essayer de trouver des balises suffisamment généraliste pour faire plusieurs choses mais suffisamment précises pour ne pas couvrir la moitié du monde.
Et puis juste comme ça en passant, les "applications web", si ça ressemble à ce qu'on a en ce moment en pire, je préfère encore ma vraie application.
4) merci du tuyau, je vais essayer dès ce soir
[1] http://www.w3.org/TR/html5/#the-dialog
[^]Re: Plus que sceptique
> Ouai, mais seulement ce genre de truc est un cauchemar à styler. Comment styler les titres de deuxième niveau par exemple, et uniquement de deuxième niveau ?
body > section > h {
...
}
Non ? (en tout cas, je trouve ça joli ;))
[^]Re: Plus que sceptique
Tu enlèves les ">", et c'est ça.
body section h,
body section h section h
{
...
}
Les virgules elles séparent les éléments auquels doit s'appliquer le style.
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.
[^]Re: Plus que sceptique
Non, les ">" dont là pour dire "fils direct". En les enlevant, le style s'appliquera au h de niveau deux ou supérieur:
[h]Premier niveau, ne s'applique pas[/h]
[section]
[h]Second niveau, s'applique[/h]
[section]
[h]Troisième niveau, s'applique[/h]
[section]
[h]Quatrième niveau, s'applique[/h]
...
Soit dit en passant, ton "body" est inutile (tout section est un descendant de body). Le mien sert justement à déterminer le "section" de premier niveau.
(en xpath, mon expression serait //body/section/h, tandis que la tienne est //body//section//h,//body//section//h//section//h, qui ne répond absolument pas au problème...)
[^]Re: Plus que sceptique
Noooooon pas la balise font! Tout mais pas ca! b, i tu dis? Rhaa comme au bon vieux temps! Je sens le retour en force du code bien gruik...
Apparement la tendance est à revenir à ce qui a fait le succès de html: ca marche même si c'est écrit hyper porc.
[^]Re: Plus que sceptique
Oulah, vous vous emballez un peu vite :)
http://blog.whatwg.org/2007/08
"- Est-il vrai que HTML 5 permettra l’utilisation de <font> ?
- Non, les développeurs ne pourront pas utiliser <font>. Cependant, les éditeurs WYSIWYG seront autorisés à émettre des balises <font>. Ils devront s’identifier avec une balise <meta>. Cette problématique a reçu beaucoup de feedback et pourrait être modifiée."
Hôdo
Livingstone
[^]Re: Plus que sceptique
Donc il suffit de se faire passer pour un éditeur WYSIWYG en ajoutant une balise <meta> ;)
[^]Re: Plus que sceptique
Même pas ... comme le mode HTML est tolérant aux erreurs, je suppose que la balise <font> sera comprise dans tous les cas :(
De toute façon si tu développes à la main, c'est beaucoup plus simple d'utiliser CSS. Je ne vois pas pourquoi quelqu'un chercherait a utiliser <font> (sauf si il n'a pas encore réussi a se débarasser de ses mauvaises habitudes)
La Roue du Temps
[^]Re: Plus que sceptique
...
<!--Generation avec un éditeur WYCIWYG (What You Code Is What You Get) -->
...
<font ... >
Hahaha, parceque je suis méchant!
<!-- Finalement je ne mettrais pas de , parceque je suis super méchant -->
...
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.
[^]Re: Plus que sceptique
Ca existe pourtant toujours, la raison est: "Parce qu'IE est le navigateur majoritaire, donc je code POUR IE et je fais quelques modifs pour que ça passe avec Firefox"
entendu cette semaine justement quand je lui ai parlé du futur (éventuel) IE8.
Il code avec la suite A daube pour profiter des fonctionnalités (intégration des autres cochonneries, vidéo et compagnie) mais utilise surtout le code source à la mano .. sans CSS ..
Pas réussi à lui faire entendre raison, ils étaient deux à considérer qu'il fallait toujours coder POUR IE puisqu'il était majoritaire et qu'il le resterai toujours .. >_<
[^]Re: Plus que sceptique
ouai enfin, tu peux aussi leur dire que leur IE majoritaire baisse en europe, et que négliger les presque 30% de part de marché de Firefox en europe, c'est à dire ignorer presque un tiers des internautes, c'est complètement con. (source des chiffres : xitimonitor)
[^]Re: Plus que sceptique
J'ai essayé, mais je crois que le coté "mouton de panurge" était plus fort que ces arguments.
"La masse saute de la falaise (forcée pour la plupart), alors JE saute de la falaise de mon plein gré (et j'aide les autres)"
[^]Re: Plus que sceptique
Oui enfin on est pas tous obligé non plus d'avoir l'instinct de survie d'un lemmings :)
Plus sérieusement, oui IE a encore la part belle sur le marché des navigateurs web, pour la simple et bonne raison que les gens ne connaissent pas autre chose.
Mais d'une part les particuliers s'éduquent petit à petit - merci les enfants qui ramènent les bonnes idées aux parents - et d'autre part, je suis peut-être utopiste - non, pour être franc, je suis utopiste. Utopessimiste même - mais j'attend beaucoup du procès lancé par Opera contre Microsoft pour abus de position dominante concernant l'intégration par défaut d'IE dans la fenêtre. Bien que le verdict ne sera surement pas rendu avant plusieurs années, comme d'habitude, et que son application prendra elle aussi du temps.
Toujours est-il que les mentalités évoluent et les logiciels aussi. Imaginez donc, il paraitrait qu'IE8 passe le test Acid2 ! Qui aurait cru que ca arriverait avant 2025 ? ...
Donc "coder pour IE", c'était "bien" il y a quelques années, aujourd'hui je pense que c'est une con****e.
Personnellement, je préfère de loin faire des sites valides, qui seront lus conformément aux spécifications par les navigateurs qui en sont capables, et jouer ensuite des coudes pour faire en sorte d'obtenir une dégradation élégante sous les navigateurs pourraves.
Et ca tombe bien, pour une fois M$ a à peu près pensé la chose puisqu'il existe les commentaires conditionnels, qui permettent d'éviter les hacks CSS douteux et d'adapter les styles mais aussi les scripts aux différentes versions d'IE. Histoire de leur faire comprendre ce qui leur passerait au dessus de la tête.
A première vu, on peut se dire que ça fait beaucoup de travail en plus, mais je suis régulièrement étonné du faible nombre de ligne de mes feuilles de styles spéciales IE à partir du moment où le design de base a été un minimum réfléchi et où les styles ont été fait à peu près intelligemment.
Au final, on assure une partie de l'avenir en utilisant des standards d'ores et déjà pérennisés et on s'économise du travail... M'enfin s'il y en a qui aime se faire mal ...