Publié par Simon Robic, le Lundi 23 Juillet 2012

HTML5 : deux versions pour diviser les développeurs

Le WHATWG, à l'origine du développement du HTML5, a décidé de se désolidariser du W3C. Ce dernier ne sera donc plus le seul à officialiser les avancées du langage et deux versions parallèles du HTML5 devront cohabiter. Une situation qui place les éditeurs de navigateurs dans un rôle de juge et partie puisqu'ils devront désormais choisir quelles fonctionnalités ils intègreront à leur logiciel, selon qu'ils suivent l'une ou l'autre des organisations. Des choix qui pourraient, avant tout, être basés sur des considérations économiques.

Le 19 juillet dernier, Ian Hickson a publié un message dans la liste de diffusion du W3C (World Wide Web Consortium) concernant le HTML5. L'homme y annonce qu'un fork du langage venait d'être effectué, créant ainsi deux versions parallèles du langage de référence de la création des sites et applications web.

HTML5 : un langage à deux têtes

Pour mieux saisir l'impact de cette annonce, il faut comprendre comment le HTML5 est géré. La cinquième version de l'HyperText Markup Language, utilisé pour développer les pages web, est l'évolution du HTML 4 et du XHTML 1.1. Il permet, notamment, d'apporter du multimédia et de l’interaction aux sites sans avoir besoin d'ajouter de module complémentaire à son navigateur.

Il est toujours en développement. Des corrections et des nouvelles fonctionnalités lui sont donc régulièrement apportées. Ce sont les 375 membres (entreprises, universités, ministères...) du W3C, répartis en groupes de travail, qui supervisent ces travaux après que son développement ait été initié par le WHATWG (Web Hypertext Application Technology Working Group - composé des principaux développeurs de navigateurs).

Cette supervision ne veut cependant pas dire que le WHATWG a arrêté de plancher sur le langage ; jusqu'ici, il fonctionnait comme la cellule de recherche et développement du W3C. Mais c'est ce dernier qui décidait, après son processus de brouillons et de validations, quelles spécifications seraient retenues pour la version finale prévue en 2014.

Un divorce lourd de conséquences

Le WHATWG a toujours critiqué la lenteur de ce processus qui, d'après ses représentants, freine l'innovation et l'évolution du web. Il a donc décidé de travailler, de son côté, sur sa propre version du HTML5. "C'est difficile d'ajouter de nouvelles fonctionnalités quand vous essayez de bloquer une liste de spécifications" explique Hickson à TechCrunch, en taclant le W3C.

Deux versions du HTML5 cohabiteront donc. Celle du WHATWG, baptisée "living standard" pour montrer que ce sera celle qui évoluera, et celle du W3C appelée "snapshot standard" pour montrer qu'elle ne bougera pas, ou peu.

Seulement, les développeurs devront donc vérifier si chacune des fonctionnalités qu'ils souhaitent utiliser est prise en compte par les navigateurs.  "Rien ne change pour [eux]" explique Ian Hickson. En effet, les spécifications du langage ne devant être finalisées que dans deux ans, et les navigateurs intégrant les fonctionnalités existantes à leur rythme, cette vérification était déjà devenue un réflexe.

Mais la promesse d'un standard unique laissait entrevoir le bout du tunnel et la fin de ce casse-tête qui leur fait perdre beaucoup de temps. Avec une version unique du langage, supportée par tous les navigateurs, les développeurs n'auraient pas eu de question à se poser.

Ils pourraient aujourd'hui être amenés à vérifier leurs sites sur chacun des navigateurs, voire à développer des versions spécifiques pour chacun d'entre eux comme dans les anciens temps, lorsqu'il fallait une version spécifique pour Internet Explorer. Adieu homogénéité du web, bonjour fragmentation.

Les navigateurs, juges et parties

Les navigateurs deviennent donc tout puissants. Ce n'est plus un organisme indépendant et impartial, le W3C, qui décidera des caractéristiques du langage mais des firmes comme Google, Mozilla ou Apple qui développent les navigateurs. Et si les éditeurs avaient déjà un pouvoir si important à la fin des années 1990, l'impact de leurs décisions était proportionnel à l'usage du web, qui était moins important qu'aujourd'hui.

Or, on peut douter de leur neutralité. Rien, aujourd'hui, ne peut plus garantir que les choix technologiques liés au web ne seront pas fait dans l'intérêt financier de ces entreprises. L'économie numérique s'est structurée ces 15 dernières années, passant d'un phénomène naissant à l'une des industries les plus puissantes du monde. Un tournant inquiétant pour l'avenir des internautes que l'on pourrait priver d'avancées technologiques au profit de considérations financières.

Publié par Simon Robic, le 23 Juillet 2012 à 11h53
 
46
Commentaires à propos de «HTML5 : deux versions pour diviser les développeurs»
Inscrit le 11/01/2011
16 messages publiés
Bordel de cul, qu'est ce qu'ils ont avec internet aujourd'hui...
Inscrit le 23/12/2011
378 messages publiés
Tout ça à cause de problèmes d'ego. Bande de cons.
Inscrit le 07/04/2012
55 messages publiés
Et merde ... on y avait cru à la Grande Unification ...

Je repars chercher le Boson de Internet ...
Inscrit le 17/03/2006
830 messages publiés
Un pas en avant, 3 pas en arrière !
Inscrit le 29/04/2010
393 messages publiés
Inscrit le 18/06/2011
871 messages publiés
Mais putain de fuck de merde -_-""

Les forks sont vraiment un des problèmes du libre ...
Inscrit le 21/03/2009
1787 messages publiés
On se croirait revenu dans les années 90 avec netscape et internet explorer volontairement non compatibles.
.
Maintenant que certains freinent l'avènement du standard je veux bien le croire.
J'ai déjà travaillé dans une boite qui faisait ca parce qu'elle était en retard dans ses développements.
Freiner l'arrivée du standard ca permet de rattraper les autres.
Résultat des courses : Un concurrent n'a pas attendu et a sortis son produit bien avant que le standard soit établis,
Et bien sur son produit n'était pas compatible.
Bien sur, ca n'a pas été fait exprès.
.
Je pense que quant on met en place des standards, on devrait éliminer du processus tous ceux qui ont un intérêt pécunier avec le standard en question.
Ou au moins les limiter au rôle de conseil et non de preneur de décision.
Évidemment, ca ne marcherait pas puisque ce sont les boites qui font les standards.
Mais il serait bon d'y réfléchir.
C'est l'intérêt général qui trinque si non.
Inscrit le 20/09/2011
5137 messages publiés
Cela fait plusieurs années que je trouve que HTML va dans le mauvais sens : au départ c'était un langage simple qui permettait à quelqu'un de développer un site sans avoir fait bac+15 en informatique. Il autorisait même un certain laxisme.

Et puis au fur et à mesure, on a commencé à mettre des bâtons dans les pattes des développeurs.
Il ne faut plus utiliser target=_blank pour ouvrir une page dans une nouvelle fenêtre : il faut laisser le choix à l'utilisateur. Du coup, on a fait exactement la même chose en mettant 10 lignes de javascript là où deux mots suffisaient.

Maintenant depuis HTML5, il faut utiliser les feuilles de style dans tous les coins, même les plus simples. Si je veux faire un tableau de chiffres qui tient tout la page, je ne peux plus utiliser table width='100%'... Non il faut que je fasse table id="tableau" et dans les css indiquer #tableau width:100% ou alors écrire table style={width:100%}
Pourquoi faire simple quand on peut faire compliqué ?

Quand un tag est composé d'un seul mot (img, hr, br, ...) il faut l'indiquer avec un / à la fin : br = pas bien ! br / = bien.
Pourquoi ? Pour satisfaire les besoins rigoristes d'une bande d'ayatollah ! Qu'est-ce que ça apporte au développeur de mette br / à la place de br : rien.
Est-ce que cela gêne les browsers de ne pas mettre le / : Non ! Est-ce qu'un analyseur syntaxique ou sémantique est gêné par l'absence de / : même pas ! Non, c'est juste des mecs qui se sont dit : mon dieu, mon dieu, on dit que les tags c'est machin /machin : mais comment on va faire pour img puisqu'il n'y a pas de /img ! Vite inventons une syntaxe qui va faire chier tout le monde, mais au moins il n'y aura pas d'exception à la règle.
Alors que toutes les études le montre : les systèmes trop rigoristes sont soit complètement bloqués, soit contournés.

Entre les versions HTML, les versions XHTML, les interprétations différentes par les browsers et par leurs versions, les problèmes de codage des caractères accentués, les bibiothèques javascript incompatibles et néanmoins indispensables pour implémenter des fonctions basiques, ça devient vraiment très très chiant.

Et vu qu'il y a des millions de sites développés par des amateurs qui continuent à tourner avec des syntaxes plus ou moins rigoureuses, les browsers sont obligés d'embarquer des interpréteurs qui prennent en compte toutes ses syntaxes !
Inscrit le 29/04/2010
393 messages publiés
@zig : Tu découvres que le code/développement a besoin d'une certaine rigueur ? Ptit bouchon.
Entre du HTML 2.0 et du XHTML 1.0 ca c'est complexifié pour un novice, mais c'est foutrement mieux maintenant.

Et le coup du _blank et du JS, ton exemple montre surtout un refus de s'adapter au comportement utilisateur en forçant coute que coute l'ouverture d'une nouvelle page. Et bordel en tant qu'utilisateur c'est chiant.
Inscrit le 18/06/2011
871 messages publiés
Mettre un / à la fin des balises uniques je trouve ça bien, ça permet de vérifier son code à la main sans stresser. Mais rien ne t'oblige à le mettre, ça ne fait pas de différence avec le vérificateur du W3C (et donc validité du code pour le référencement).

Ouvrir dans un nouvel onglet est toujours utile, par exemple si tu veux donner un lien vers la page officielle d'un téléchargement sans faire quitter ton site. Ca permet de donner de la visite et de t'assurer d'avoir un bon lien mis à jour.
[message édité par Nyn le 23/07/2012 à 13:07 ]
Inscrit le 28/03/2012
676 messages publiés
De toutes façons le W3C est compromis et foutu, choix de standards proprios, financement par des entreprises à la politique douteuse ...
Inscrit le 21/03/2009
1787 messages publiés
Ce que je n'aime pas dans le HTML c'est qu'il mélange l'information qu'il transporte (texte, image) et les informations propres au langage (le "code").
C'est quelque chose qui ne peut être bon dans aucun langage.

En ce sens, mettre des feuilles de style séparée me semble aller dans le bon sens.
Je ne vois pas en quoi ca représente une difficulté.
Surtout que ce sont des outils qui prennent en charge les subtilités du langage.

Le / a la fin : Bonjour la confusion si tu ne l'as pas.
Pense par exemple que les données constituant une page peuvent être reçus partiellement.
Est-ce qu'un analyseur syntaxique ou sémantique est gêné par l'absence de /


Oui il le peut.
Certes il peut aussi s'en affranchir mais ce "petit" effort peut bien être demandé aux codeurs (humain ou/et éditeur HTML)
Grosso modo, il y a une information à apporter (la fermeture d'une balise) et donc un peu de complication pour qui la traite.
Elle peut être traitée par le langage, ou par le codeur.
Je trouve que c'est un bon compromis que de la faire traiter par le codeur.
[message édité par identifiant le 23/07/2012 à 13:12 ]
Inscrit le 17/03/2006
830 messages publiés
@Zig : Au contraire je trouve que de ce point de vue cela s'est simplifié.
Les choses sont clairement séparée.
Le HTML est un langage de description de page. Il sert donc à indiquer qu'est-ce qui doit être afficher.
Ensuite c'est le rôle de feuilles CSS d'indiquer comment les informations doivent être affichées.

Oui c'est vrai du coup ça rend l'apprentissage plus difficile, mais le résultat est nettement plus propre et plus performant.

Après si tu as envie de programmer "à l'ancienne", rien ne t'en empêche.
Les fameuse balises et compagnie existent toujours, on recommande de ne plus les utiliser ce n'est pas la même chose.
Inscrit le 03/10/2011
6683 messages publiés
Fini le
, bonjour le 

									
Inscrit le 17/07/2008
254 messages publiés
neeko, le 23/07/2012 - 12:00
Tout ça à cause de problèmes d'ego. Bande de cons.


+ 100000000 tellement j'ai pas de mots pour les qualifier ces gens qui ont un ego tellement surdimensionné qu'ils peuvent même plus discuter pour se mettre d'accord!
Inscrit le 03/10/2011
6683 messages publiés
astragor, le 23/07/2012 - 13:10
Oui c'est vrai du coup ça rend l'apprentissage plus difficile, mais le résultat est nettement plus propre et plus performant.
Plus propre, oui, plus performant, non !
Entre, je dois afficher un carré de 8 sur 8, et je dois affiché un carré ... au fait, il fait 8 sur 8, pour la machine, c'est loin d'être équivalent. Surtout que plein de développeurs web bossent comme des gorets en définissant en fin de page un DIV qui va en haut, ... Logiquement, le CSS devait être dans le head, mais en HTML5, tu peux le coller n'importe où, bonjour le rendement.
Maintenant, c'est vrai que le CSS3 permet des trucs assez fun, en 10 lignes on fait une animation 3D, c'est assez cosmique. Néanmoins ce qui à la base était un HyperText Markup Language, ressemble plus à A Jumping Ajax Box, sans compter les Ext JS.
Inscrit le 17/04/2009
116 messages publiés
Faut arrêter un peu de fumer les enfants. Il n'y a absolument pas de fork du HTML ni de "plusieurs versions".
Il y a juste une évolution expérimentale en avance sur la version standard. Exactement comme avec la plupart des projets en fait (votre navigateur par exemple)

Après ça ne change rien du tout au fonctionnement HTML actuel, c'est juste que si vous développez avec la branche expérimentale vous n'aurez pas la garantie que tous les navigateurs soient compatibles (ce qui est parfaitement normal)
Inscrit le 28/11/2008
3161 messages publiés
Zig il rage
Le CSS sert à mettre en page, le HTML sert à apporter les informations. Par exemple un crawler de moteur de recherche comme les googlebots n'ont pas besoin des paramètres de style dans le HTML, en les cantonnant dans le CSS on allège sensiblement le HTML et on réduit ainsi le trafic et le temps de chargement.

Pour revenir au sujet, je suis très sceptique. AMHA essayer de "graver dans le marbre" des spécifications a l'avantage de servir de base pour les développeurs mais va avoir un problème majeur: le peu de flexibilité. Et à peine finalisé il risque d'être déjà obsolète. Une approche plus "langage qui évolue au fil du temps" me semble meilleure, le web progresse trop vite pour qu'on essaye de fixer des règles immuables.

Il y a un certain problème par contre: si le W3C a été assez peu strict au regard des formats avec royalties (H.264 et AAC) en les laissant entrer dans le HTML 5, est-ce que le WHATWG va les conforter au détriment des formats libres ? Il me semble urgent que les détenteurs de brevets sur le MPEG-4 se décident s'ils continuent ainsi ou s'ils renoncent à leurs royalties, avant que Mozilla fasse entrer le loup dans la bergerie avec Firefox OS (qui utilisera la puce de décodage H.264 des smartphones).

Je crains également qu'Apple abuse de son pouvoir (merci les iMachins) pour faire copain-copain avec Microsoft pour s'en prendre à Google, Mozilla et Opera. Et si ce dernier... se fait racheter par Facebook 0_o Putain la situation explosive...
Inscrit le 18/06/2011
871 messages publiés
Si les tous les gros navigateurs suivent le même. Si par exemple Firefox suit une branche et Chrome une autre on est bien ...
Inscrit le 05/10/2011
2885 messages publiés
@Zig : tu mélanges javascript, html5 et xhtml. Mais pour résumer : _blank, c'est de la merde (et s'il te faut 10 lignes de javascript pour le remplacer, tu codes de la merde), j'ai jamais vu un utilisateur content de ce truc. La norme, tu n'es pas plus obligé de la suivre maintenant qu'hier : si t'as pas envie de la suivre, tu fais comme tu veux, on te donne juste des bonnes pratiques pour que ton site web soit affiché correctement par les navigateurs qui respectent les normes.
Et séparer le contenu de la mise en page est une très bonne pratique, que tout le monde devrait respecter quand il fait son site web (même le développeur de numerama devrait essayer ), et pour ceux qui ne veulent pas le faire, venir nous dire que "style="width:100%"" et vraiment beaucoup plus compliqué que "width="100%"", c'est vraiment du foutage de gueule.

Ben oui, pour réaliser un truc un peu technique, il faut se document un peu. Quelle aventure.
Inscrit le 03/10/2011
6683 messages publiés
Ronfladonf, le 23/07/2012 - 13:22
neeko, le 23/07/2012 - 12:00
Tout ça à cause de problèmes d'ego. Bande de cons.


+ 100000000 tellement j'ai pas de mots pour les qualifier ces gens qui ont un ego tellement surdimensionné qu'ils peuvent même plus discuter pour se mettre d'accord!
Surtout quand on met 5 ans pour créer 30 balises, dont certaines laissent à désirer : aside, canvas, mark, ...
Inscrit le 18/10/2008
1878 messages publiés
zig, le 23/07/2012 - 12:44

Il ne faut plus utiliser target=_blank pour ouvrir une page dans une nouvelle fenêtre : il faut laisser le choix à l'utilisateur.

Quoi de plus normal ? C'est amusant d'ailleurs, tu dis toi-même que les systèmes trop rigoristes sont contournés, et là c'est pire : impose un comportement que l'utilisateur ne veut pas et regarde comment il va contourner la chose.

Alors que toutes les études le montre : les systèmes trop rigoristes sont soit complètement bloqués, soit contournés.

Je ne sais pas ce que montrent toutes les études, mais mon interpréteur me montre très vite que si je déconne avec la syntaxe, ça, ça ne se contourne pas. C'était comme ça avec le BASIC dans les années 80, rien de nouveau de ce côté là et c'est une excellente chose puisqu'on parle de langages de programmation. Il y a certes des choses critiquables, mais si ce qui t'embête le plus c'est le _blank et le slash à la fin des tags, 'tain, j'aimerais vivre dans le même monde.

Reste à voir si la version du W3C sera un sous-ensemble de celle de WHATWG, un peu à la ASCII-Unicode. Ian Hickson est loin d'être un guignol, il est évident qu'il va tout tout faire pour rester compatible au maximum. Quelque part, un sous ensemble de base statique avec une version qui évolue en permanence, ça peut être jouable si c'est bien géré. Dans un autre domaine, OpenGL fonctionne de cette façon avec ses extensions et explose tout sur son passage.
Inscrit le 15/03/2006
1921 messages publiés
Bravo les gars !
Vous non plus vous n'avez pas su résister au fric !
ET C'EST, UNE FOIS DE PLUS, NOUS, CONSOMMATEURS QUI ALLONS àTRE PÉNALISÉS.
Bande d'imbéciles !
db
Inscrit le 28/06/2006
2723 messages publiés
bronto, le 23/07/2012 - 13:55
mon interpréteur me montre très vite que si je déconne avec la syntaxe, ça, ça ne se contourne pas.


Mon navigateur Firefox ne me signale aucune erreur avec du code non valide comme celui-ci :

Une phrase < b >pour montrer < i >un des multiples < / b >problemes < / i >!

(il faut bien entendu retirer les espaces dans les balises...)

et il me l'affiche pourtant comme on peut l'attendre :

Une phrase pour montrer un des multiples problemes !
[message édité par Croux le 23/07/2012 à 14:41 ]
Inscrit le 17/03/2006
830 messages publiés
Centaurien, le 23/07/2012 - 13:28
astragor, le 23/07/2012 - 13:10
Oui c'est vrai du coup ça rend l'apprentissage plus difficile, mais le résultat est nettement plus propre et plus performant.
Plus propre, oui, plus performant, non !
Entre, je dois afficher un carré de 8 sur 8, et je dois affiché un carré ... au fait, il fait 8 sur 8, pour la machine, c'est loin d'être équivalent. Surtout que plein de développeurs web bossent comme des gorets en définissant en fin de page un DIV qui va en haut, ... Logiquement, le CSS devait être dans le head, mais en HTML5, tu peux le coller n'importe où, bonjour le rendement.

Après dès gens qui codent avec les pieds y en a partout.
Inscrit le 23/09/2008
1860 messages publiés
zig, le 23/07/2012 - 12:44
Cela fait plusieurs années que je trouve que HTML va dans le mauvais sens : au départ c'était un langage simple qui permettait à quelqu'un de développer un site sans avoir fait bac+15 en informatique. Il autorisait même un certain laxisme.


Mais le résultat ne s'affichait correctement que sur un navigateur cible.


zig, le 23/07/2012 - 12:44

Et puis au fur et à mesure, on a commencé à mettre des bâtons dans les pattes des développeurs.


Au contraire, on nous a grandement simplifié la vie moyennant quelques apprentissages supplémentaires.


zig, le 23/07/2012 - 12:44


Il ne faut plus utiliser target=_blank pour ouvrir une page dans une nouvelle fenêtre : il faut laisser le choix à l'utilisateur. Du coup, on a fait exactement la même chose en mettant 10 lignes de javascript là où deux mots suffisaient.


Seulement en STRICT, et pour les raisons suivantes:

http://www.ultra-flu...html/target.htm

Il faut reconnaître que d'une façon générale, ouvrir plusieurs fenêtres est une pratique peu ergonomique car l'utilisateur peut faire passer un popup en arrière-plan par inadvertance et se retrouver perdu.
Tout faire dans la même fenêtre est bien mieux.

zig, le 23/07/2012 - 12:44

Maintenant depuis HTML5, il faut utiliser les feuilles de style dans tous les coins, même les plus simples. Si je veux faire un tableau de chiffres qui tient tout la page, je ne peux plus utiliser table width='100%'... Non il faut que je fasse table id="tableau" et dans les css indiquer #tableau width:100% ou alors écrire table style={width:100%}
Pourquoi faire simple quand on peut faire compliqué ?


Vous n'êtes pas obligé d'abandonner vos vieilles (et mauvaises) habitudes. Rien ne vous oblige à écrire des pages en HTML5. La version 4.01 est une norme et le restera encore longtemps.

Utiliser des feuilles de style sert à séparer l'apparence du contenu. Cela augmente grandement la flexibilité et la maintenabilité des pages web et facilite le travail en équipe. Cela permet également de mettre assez facilement les mains dans le code des différents CMS du marché (Joomla, WordPres...) pour les adapter à nos besoins, car à part pour des besoins spécifiques on ne code plus de pages web en partant de zéro.

Personnellement j'ai appris à faire des pages comme vous les faites actuellement, et comme la plupart des développeurs je me suis mis au XHTML et aux feuilles de styles ensuite. Cela permet de faire bien plus de choses, plus jolies, tout en gagnant en efficacité et en nous libérant en grande partie des spécificités de chaque navigateur. Bien sûr il a fallu y investir du temps mais je suis bien content de l'avoir fait.

zig, le 23/07/2012 - 12:44

Quand un tag est composé d'un seul mot (img, hr, br, ...) il faut l'indiquer avec un / à la fin : br = pas bien ! br / = bien.
Pourquoi ? Pour satisfaire les besoins rigoristes d'une bande d'ayatollah ! Qu'est-ce que ça apporte au développeur de mette br / à la place de br : rien.
Est-ce que cela gêne les browsers de ne pas mettre le / : Non ! Est-ce qu'un analyseur syntaxique ou sémantique est gêné par l'absence de / : même pas ! Non, c'est juste des mecs qui se sont dit : mon dieu, mon dieu, on dit que les tags c'est machin /machin : mais comment on va faire pour img puisqu'il n'y a pas de /img ! Vite inventons une syntaxe qui va faire chier tout le monde, mais au moins il n'y aura pas d'exception à la règle.
Alors que toutes les études le montre : les systèmes trop rigoristes sont soit complètement bloqués, soit contournés.


Tout cela est pourtant bien plus cohérent qu'avant. Essayez d'en avoir une vue d'ensemble.

zig, le 23/07/2012 - 12:44

Entre les versions HTML, les versions XHTML, les interprétations différentes par les browsers et par leurs versions, les problèmes de codage des caractères accentués, les bibiothèques javascript incompatibles et néanmoins indispensables pour implémenter des fonctions basiques, ça devient vraiment très très chiant.


Justement, la normalisation permet d'échapper en grande partie à ces différences d'interprétation. Suivez les recommandations du w3c et vos pages s'afficheront correctement les navigateurs qui les suivent aussi, c'est à dire à peu près tous.

zig, le 23/07/2012 - 12:44

Et vu qu'il y a des millions de sites développés par des amateurs qui continuent à tourner avec des syntaxes plus ou moins rigoureuses, les browsers sont obligés d'embarquer des interpréteurs qui prennent en compte toutes ses syntaxes !


Etre un amateur n'oblige pas à faire du boulot de cochon. Il y a des outils très simples qui vous prennent par la main et vous permettent de respecter les normes sans trop d'efforts, comme le module complémentaire HTML validator de Firefox qui vous dit exactement ce qui ne va pas dans votre code et vous fais des suggestions de remplacement.

Le w3c nous a permis d'échapper aux effets de bords de la guéguerre Netscape-Microsoft qui a fait rage dans les années 90. Maintenant on respire.
[message édité par anomail2 le 23/07/2012 à 16:12 ]
Inscrit le 24/12/2011
2307 messages publiés
+1 bronto pour le commentaire le plus intelligent à mon sens.
Et a priori oui le HTML W3C sera un sous-ensemble du HTML "live", enfin c'est ce que je comprends.
Le choix de faire un standard figé et un standard mouvant (qu'on pourrait tout simplement appeler "draft") me semble très bien
Inscrit le 22/02/2009
3904 messages publiés
2 versions pour les diviser... Et 1 anneau pour les contrôler tous ?
Inscrit le 23/09/2008
1860 messages publiés
2 versions pour les diviser... Et 1 anneau pour les contrôler tous ?


Excellent !!!
Inscrit le 29/07/2010
1024 messages publiés
Kheltdire, le 23/07/2012 - 12:53

Et le coup du _blank et du JS, ton exemple montre surtout un refus de s'adapter au comportement utilisateur en forçant coute que coute l'ouverture d'une nouvelle page. Et bordel en tant qu'utilisateur c'est chiant.


+ 1000
C'est simple, les développeurs qui font ça, je les hais !
Surtout que le clic milieu c'est pas fait pour les chiens !
Inscrit le 23/09/2008
1860 messages publiés
june, le 23/07/2012 - 18:06
Kheltdire, le 23/07/2012 - 12:53

Et le coup du _blank et du JS, ton exemple montre surtout un refus de s'adapter au comportement utilisateur en forçant coute que coute l'ouverture d'une nouvelle page. Et bordel en tant qu'utilisateur c'est chiant.


+ 1000
C'est simple, les développeurs qui font ça, je les hais !
Surtout que le clic milieu c'est pas fait pour les chiens !


Y'a plus que les spammeurs qui font ça maintenant.

Quand au clic milieu, curieusement peu de gens le connaissent. Pourtant quel confort.
Inscrit le 20/09/2011
5137 messages publiés
@zig : Tu découvres que le code/développement a besoin d'une certaine rigueur ? Ptit bouchon.
Entre du HTML 2.0 et du XHTML 1.0 ca c'est complexifié pour un novice, mais c'est foutrement mieux maintenant.

A bon, c'est foutrement mieux d'avoir 35 versions de HTML qui se croisent et se décroisent. Et c'est mieux pour qui ? Pour le novice ou pour l'informaticien qui se la pète en montrant qu'il maîtrise un langage alors que le novice ne le peut pas.

Est-ce que déjà tu peux m'expliquer pourquoi il y a du HTML et du XHTML ? Quelle est vraiment l'utilité ? Pourquoi est-ce qu'il y a des gens qui se sont dit : HTML ce n'est pas terrible, il faut du XHTML ?

Et le coup du _blank et du JS, ton exemple montre surtout un refus de s'adapter au comportement utilisateur en forçant coute que coute l'ouverture d'une nouvelle page. Et bordel en tant qu'utilisateur c'est chiant.

Sauf que quand tu as un site et que le lien amène à ouvrir un pdf, l'utilisateur est plutôt content de rester sur la même page. Et que quand il s'agit d'un lien vers un site externe, l'utilisateur est aussi content d'avoir une nouvelle page.

Le HTML est un langage de description de page. Il sert donc à indiquer qu'est-ce qui doit être afficher.
Ensuite c'est le rôle de feuilles CSS d'indiquer comment les informations doivent être affichées.

Ah ouais ?
Si j'écris en gras, je peux utiliser le tag b, ce n'est pas deprecated
Par contre si j'écris en rouge, je dois utiliser une feuille de style parce que l'utilisation de l'attribut color est deprecated.

j'ai jamais vu un utilisateur content de ce truc.

Ben moi, je suis très content quand je suis sur le site de ma banque et que j'ouvre un relevé de compte en PDF que cela s'ouvre automatiquement dans une nouvelle fenêtre. Ou que lorsque je viens de passer une commande, que la facture en PDF s'ouvre automatiquement dans une nouvelle fenêtre.

D'ailleurs, on remarquera qu'après avoir été banni, l'attribut target=_blank est à nouveau autorisé dans html5.

pour ceux qui ne veulent pas le faire, venir nous dire que "style="width:100%"" et vraiment beaucoup plus compliqué que "width="100%"", c'est vraiment du foutage de gueule.

Ben oui, c'est plus compliqué : écrire 3 mots au lieu de 2, c'est plus compliqué.
Ecrire span style='color:red' au lieu de font color='red' c'est plus compliqué.

Attention : je ne conteste pas les feuilles de style ; j'en use et j'en abuse. Mais je conteste la suppression (annoncée) des fonctions simples pour les remplacer par des fonctions compliquées.

Par exemple un crawler de moteur de recherche comme les googlebots n'ont pas besoin des paramètres de style dans le HTML, en les cantonnant dans le CSS on allège sensiblement le HTML et on réduit ainsi le trafic et le temps de chargement.

Sauf que
1) ton css peut être embarqué dans ton HTML et donc c'est encore plus lourd.
2) un moteur de recherche comme Google te présente une hardcopy des pages, donc a besoin de l'ensemble des fichiers.

Ben oui, pour réaliser un truc un peu technique, il faut se document un peu. Quelle aventure

Quand la technique consiste à rendre compliqué ce qui est simple, on se demande à quoi cela sert.
Que ce soit compliqué pour faire des choses compliquées, déjà c'est limite, mais pourquoi pas. Mais que ce soit compliqué pour faire des choses simples, alors là c'est le syndrôme des techniciens qui se branlotent entre eux et qui oublient le but du langage.
Le but du langage étant de faire des sites et pas de rendre facile la tâche des analyseurs syntaxiques.


Après si tu as envie de programmer "à l'ancienne", rien ne t'en empêche.

Prenons un exemple : la mise en page avec des div. Il faut faire comme ça sinon tu es un goret et les puristes du HTML te crucifient.
Du coup, si tu veux faire une mise en page de ton site en 3 colonnes avec une zone d'entête et une zone de bas de page qui tiennent toute la largeur, tu en as pour 3 heures pour trouver les bons paramètres, les float:left, les float:right et autres clear:both ou je ne sais quoi encore.

Alors que c'est tellement simple avec une table : c'est compréhensible par le premier amateur venu. Tu lui dis : c'est comme dans Excel ! Tu met tes cellules, tu règles la largeur, tu règles les alignements, tu règles les fusions et puis c'est tout.

Va t'en lui expliquer avec des div !!!

Et puis même moi : je suis en train de faire une mise en page avec une bonne vingtaine de modules d'informations plus ou moins carrés que je dois disposer sur ma page, parfois en 3 colonnes, parfois en 6, parfois en 2 et parfois en 1.
Va t'en faire ça from scratch avec des div ! Y a de quoi y passer la journée. Alors que de bonnes vieilles tables imbriquées, même si elles sont démodées, en 1/4 d'heure c'est réglé. Et en plus, ça tourne pareil sur tous les browsers.

Si les tous les gros navigateurs suivent le même. Si par exemple Firefox suit une branche et Chrome une autre on est bien ...

Exemple : une page conforme au HTML5 ; pas un seul warning. Elle fonctionne bien sur Firefox, Chrome, Opera et IE (même les versions antérieures grâce à des bibliothèques adjointes). Et mise en page complètement à la ramasse sur Safari.
Inscrit le 01/01/2004
132 messages publiés
zig et puce > Je ne vois pas en quoi c'est génant. Pratiquement personne ne tape le code HTML à la main pour ce genre de choses. C'est généré automatiquement par l'éditeur du coup la syntaxe est sans grande importance.
Inscrit le 14/09/2007
651 messages publiés
boarf, voilà qui va donner du boulot à une armée de web-designers pour dix ans, il faut plutot etre content ! =)
Inscrit le 26/11/2003
1840 messages publiés
lol , déjà si ils pouvaient mettre les même valeur par défaut pour les attributs css et neutre aussi, sans etre obliger de passer un reset hein

c'est bien beau ça , le WHATWG, il vont réussir a ce mettre d'accord sur un standard ? sérieusement ils sont assez adulte pour faire des compromis ?

mouais j'y crois moyen a leur fork.
Inscrit le 17/03/2006
830 messages publiés

Le HTML est un langage de description de page. Il sert donc à indiquer qu'est-ce qui doit être afficher.
Ensuite c'est le rôle de feuilles CSS d'indiquer comment les informations doivent être affichées.

Ah ouais ?
Si j'écris en gras, je peux utiliser le tag b, ce n'est pas deprecated
Par contre si j'écris en rouge, je dois utiliser une feuille de style parce que l'utilisation de l'attribut color est deprecated.


Tu va avoir un choc, les balises < b > et < i > et sont également deprecated, comme tu dis, elles doivent être remplacées par < strong > et
< em >que tu peux ensuite définir comme tu veux dans ta feuille CSS.


Après si tu as envie de programmer "à l'ancienne", rien ne t'en empêche.


Prenons un exemple : la mise en page avec des div. Il faut faire comme ça sinon tu es un goret et les puristes du HTML te crucifient.
Du coup, si tu veux faire une mise en page de ton site en 3 colonnes avec une zone d'entête et une zone de bas de page qui tiennent toute la largeur, tu en as pour 3 heures pour trouver les bons paramètres, les float:left, les float:right et autres clear:both ou je ne sais quoi encore.

Alors que c'est tellement simple avec une table : c'est compréhensible par le premier amateur venu. Tu lui dis : c'est comme dans Excel ! Tu met tes cellules, tu règles la largeur, tu règles les alignements, tu règles les fusions et puis c'est tout.

Va t'en lui expliquer avec des div !!!

Et puis même moi : je suis en train de faire une mise en page avec une bonne vingtaine de modules d'informations plus ou moins carrés que je dois disposer sur ma page, parfois en 3 colonnes, parfois en 6, parfois en 2 et parfois en 1.
Va t'en faire ça from scratch avec des div ! Y a de quoi y passer la journée. Alors que de bonnes vieilles tables imbriquées, même si elles sont démodées, en 1/4 d'heure c'est réglé. Et en plus, ça tourne pareil sur tous les browsers.





La dessus j'étais comme toi, j'avais du mal avec les div jusqu'à ce que je trouve le site qui explique bien les choses.
Et finalement on se rends compte que c'est plus simple avec le DIV.
Déjà tu te trimbale avec une seule balise au lieu de 4 et ensuite le jour ou tu veux modifier ta mise en page tu sera bien content de pas avoir tout a reconstruire.
Attention : je ne conteste pas les feuilles de style ; j'en use et j'en abuse. Mais je conteste la suppression (annoncée) des fonctions simples pour les remplacer par des fonctions compliquées.




La sur le coup j'ai du mal a te suivre, tu dis user et abuser des feuilles de style et pourtant tu continue a vouloir t'accrocher aux anciennes balises.
C'est assez paradoxal quand même. C'est surtout fort dommage de t'entêter à ne pas les utiliser complètement.
[message édité par astragor le 23/07/2012 à 22:34 ]
Inscrit le 05/10/2011
2885 messages publiés
zig, le 23/07/2012 - 20:19

Ben moi, je suis très content quand je suis sur le site de ma banque et que j'ouvre un relevé de compte en PDF que cela s'ouvre automatiquement dans une nouvelle fenêtre. Ou que lorsque je viens de passer une commande, que la facture en PDF s'ouvre automatiquement dans une nouvelle fenêtre.

Et t'es pas assez intelligent pour décider quand un truc doit s'ouvrir dans un nouvel onglet ? T'es tout le temps en train de dire que les techniques ne se mettent pas à la place de l'utilisateur, et là tu nous dis que c'est cool de forcer le choix de l'utilisateur ! T'es en train de nous dire que les utilisateurs sont trop crétins pour comprendre quand ils doivent ouvrir un nouvel onglet, et donc qu'il faut les forcer à le faire quand on pense que c'est nécessaire ?
zig, le 23/07/2012 - 20:19

Ben oui, c'est plus compliqué : écrire 3 mots au lieu de 2, c'est plus compliqué.
Ecrire span style='color:red' au lieu de font color='red' c'est plus compliqué.


Ben non, c'est pas plus compliqué : dans un cas, tu dois apprendre tous les attributs spécifiques d'une balise, dans l'autre cas, t'as juste à apprendre le css, que tu devrais apprendre même si tu apprenais tous les attributs spécifiques de toutes les balises. Tu mesures la complexité au nombre de mots ? T'es bidon.

zig, le 23/07/2012 - 20:19

Prenons un exemple : la mise en page avec des div. Il faut faire comme ça sinon tu es un goret et les puristes du HTML te crucifient.
Du coup, si tu veux faire une mise en page de ton site en 3 colonnes avec une zone d'entête et une zone de bas de page qui tiennent toute la largeur, tu en as pour 3 heures pour trouver les bons paramètres, les float:left, les float:right et autres clear:both ou je ne sais quoi encore.

Alors que c'est tellement simple avec une table : c'est compréhensible par le premier amateur venu. Tu lui dis : c'est comme dans Excel ! Tu met tes cellules, tu règles la largeur, tu règles les alignements, tu règles les fusions et puis c'est tout.

Va t'en lui expliquer avec des div !!!

Et puis même moi : je suis en train de faire une mise en page avec une bonne vingtaine de modules d'informations plus ou moins carrés que je dois disposer sur ma page, parfois en 3 colonnes, parfois en 6, parfois en 2 et parfois en 1.
Va t'en faire ça from scratch avec des div ! Y a de quoi y passer la journée. Alors que de bonnes vieilles tables imbriquées, même si elles sont démodées, en 1/4 d'heure c'est réglé. Et en plus, ça tourne pareil sur tous les browsers.


Hey, mais si tu trouves que des tables sont mieux adaptées que des div dans certains cas, fais des tables ! T'as peur de quoi ? Qui te force à faire des div ?
En fait, ce que tu supportes pas, c'est qu'on t'explique les bonnes pratiques, alors qu'avant "on pouvait faire n'importe quoi, et ça marchait quand même". Continue à faire n'importe quoi, t'es libre ! C'est beau le web.
Du standard html5, t'as réussi à dériver sur un truc qui n'a rien à voir : "vous m'emmerdez avec vos bonnes pratiques, je fais ce que je veux".
Inscrit le 16/03/2011
2 messages publiés
zig > et si on recommande de ne plus utiliser les tables, c'est pas parce qu'elles sont démodées. C'est parce qu'on ne mange pas la soupe avec une fourchette. C'est parce que les tables ont un sens, ont un rôle, et qu'au niveau de l'accessibilité, mettre une mise en page en table, c'est la cata.
Inscrit le 24/07/2012
1 messages publiés
Y'a que moi que ça choc que l'article qui traite Mozilla de "firme", placé entre Google et Apple ?
Inscrit le 24/07/2012
1 messages publiés
Ce que je n'aime pas dans le HTML c'est qu'il mélange l'information qu'il transporte (texte, image) et les informations propres au langage (le "code").
C'est quelque chose qui ne peut être bon dans aucun langage.


Essaye MVC, il n'y a pas de code dans le html mis à part les tags des variables.

Sinon ils font #!*$@", je vais attendre HTML 6
Inscrit le 27/07/2012
1 messages publiés
Sensationnalisme à la Numerama... Ce qui se passe c'est qu'un état de fait qui dure *déjà* depuis plusieurs années a été admis et les conséquences tirées... Le HTML5 étant en développement, la version "snapshot" (figée) du W3C a donc maintenant un bugtracker différent de la version "living standard" (expérimentale).

Ce sont les bugtrackers qui ont été forkés. Les specs, répétons-le... ça fait longtemps qu'elles l'étaient d'une certaine manière (en tout cas ce qui vient de se passer ne change rien aux specs, mais en effet les specs living standard risquent d'avancer maintenant plus vite). Du coup il serait plus juste de parler de branche expérimentale que de fork (mais bon, ne faisons pas de mal aux mouches) : concrètement, le snapshot ne va pas évoluer tout seul de son côté en ignorant ce qu'apporte le living standard, il ne s'agit pas du tout de ça.

Le message du gars c'est pour expliquer pourquoi les gens qui suivent ce qui se passe ont reçu plein de mails du bugtracker : les bugs ont été clonés, et à partir de maintenant seuls les bugs du living standard sont gérés par le WHATWG.

Edit : https://plus.google....sts/QdGfrgtP6Eg explique la situation bien mieux que l'article de TechCrunch (qui commence, lui, par une formidable introduction montrant que l'auteur ne comprend rien à HTML5).
[message édité par PasEnvieDeMInscrire le 27/07/2012 à 16:02 ]
Inscrit le 12/08/2011
1165 messages publiés
Stepmen, le 24/07/2012 - 11:58
Ce que je n'aime pas dans le HTML c'est qu'il mélange l'information qu'il transporte (texte, image) et les informations propres au langage (le "code").
C'est quelque chose qui ne peut être bon dans aucun langage.


Essaye MVC, il n'y a pas de code dans le html mis à part les tags des variables.

Sinon ils font #!*$@", je vais attendre HTML 6


J'ai ris, merci beaucoup pour cette tranche d'humour.
Inscrit le 02/08/2012
1 messages publiés
Et merde ... on y avait cru à la Grande Unification ...

Je repars chercher le Boson de Internet ...


Juste pour info, on parle ici du Web, pas d'Internet.
Inscrit le 05/05/2010
579 messages publiés
@zig
Prend un de tes sites et regarde comment ils vont réagir ici responsive
C'est surtout là qu'on comprend tt l'intérêt des feuilles de style, et qu'on le veuille ou non, on est en plein dedans avec l'apparition des tablettes et smartphone.
Inscrit le 29/08/2012
2 messages publiés
"Seulement, les développeurs devront donc vérifier si chacune des fonctionnalités qu'ils souhaitent utiliser est prise en compte par les navigateurs."

Oui, on a l'habitude, mais ça nous casse le cul. Et en plus, quand certains navigateurs sont à la bourre (je cite: IE9 avec ses mises à jours tous les 3 ans, et IE8 qui existe encore sur beaucoup de machines avec XP), il y a 3 solutions:
- on change notre doctype, et on fait un vieux truc avec des fonctionnalités de 2007;
- on colmate avec du javascript, ce qui nous fait passer du temps sur google, alourdit bien le tout, et encore parfois on doit proposer autre chose;
- fuck IE8! Si vous êtes pas contents, vous prenez firefox ou chrome!

Et avec cette séparation entre le W3C et le WHATWG, ça va pas s'améliorer.

La 1ère solution représente juste une anti-innovation. La 3ème pose des problèmes évidents, surtout si on se met à boycotter la moitié des navigateurs. Et la 2ème est lourde, parfois très lourde, voire impossible (essayez de recréer la balise vidéo en HTML5...)


Donc, messieurs les organismes de standardisation, pensez s'il vous plait un peu à l'intérêt public, sous peine de voir un grand retour des sites en HTML4.
Inscrit le 12/08/2011
1165 messages publiés
brliron, le 29/08/2012 - 19:09

- fuck IE8! Si vous êtes pas contents, vous prenez firefox ou chrome!


Tu m'expliques comment font les entreprises ?
Répondre

Tous les champs doivent être remplis.

OU

Tous les champs doivent être remplis.

FORUMS DE NUMERAMA
Poser une question / Créer un sujet
vous pouvez aussi répondre ;-)
Numerama sur les réseaux sociaux
Juillet 2012
 
Lu Ma Me Je Ve Sa Di
25 26 27 28 29 30 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5