|
|
|
HTML5 : deux versions pour diviser les développeurs
Sujet ouvert par
Guillaume Champeau
- Dernière réponse le 29 août 2012 à 19h52
 
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. 
zig et puce
(Banni) 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.
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 ! 
@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. 
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
]
De toutes façons le W3C est compromis et foutu, choix de standards proprios, financement par des entreprises à la politique douteuse ...
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.
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
]
@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. 
neeko, le 23/07/2012 - 12:00 + 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! 
astragor, le 23/07/2012 - 13:10Plus 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. 
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) 
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...
Si les tous les gros navigateurs suivent le même. Si par exemple Firefox suit une branche et Chrome une autre on est bien ...
@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. 
Ronfladonf, le 23/07/2012 - 13:22Surtout quand on met 5 ans pour créer 30 balises, dont certaines laissent à désirer : aside, canvas, mark, ... 
zig, le 23/07/2012 - 12:44 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.
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.
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 
bronto, le 23/07/2012 - 13:55 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
]
Centaurien, le 23/07/2012 - 13:28 Après dès gens qui codent avec les pieds y en a partout. 
zig, le 23/07/2012 - 12:44 Mais le résultat ne s'affichait correctement que sur un navigateur cible. zig, le 23/07/2012 - 12:44 Au contraire, on nous a grandement simplifié la vie moyennant quelques apprentissages supplémentaires. zig, le 23/07/2012 - 12:44 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 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 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 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 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
]
+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 
Kheltdire, le 23/07/2012 - 12:53 + 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 !
june, le 23/07/2012 - 18:06 Y'a plus que les spammeurs qui font ça maintenant. Quand au clic milieu, curieusement peu de gens le connaissent. Pourtant quel confort.
zig et puce
(Banni) le 23/07/2012 à 20:19
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 ?
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.
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.
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.
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.
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.
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.
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.
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.
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.
boarf, voilà qui va donner du boulot à une armée de web-designers pour dix ans, il faut plutot etre content ! =)
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.
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.
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.
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
]
zig, le 23/07/2012 - 20:19 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 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 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". 
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.
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
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
]
Stepmen, le 24/07/2012 - 11:58 J'ai ris, merci beaucoup pour cette tranche d'humour.
Juste pour info, on parle ici du Web, pas d'Internet.
@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.
"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.
brliron, le 29/08/2012 - 19:09 Tu m'expliques comment font les entreprises ? Tous les champs doivent être remplis. Tous les champs doivent être remplis. Tous les champs doivent être remplis. |
Sujets liés :
LES + RECHERCHÉS
A VOIR AUSSI
Télécharger
online tv adult,
pro evolution soccer,
vdownloader mac,
voissa anonymo,
windows 7 gratuit,
logiciel alcatel,
index php,
cpu z,
Accès rapide :
Diagnostic |
eMule (et mods eMule) |
Photo numérique |
Outils Réseau |
Codecs et plugins |
Nettoyeurs |
Optimisation |
|
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 WHATGW 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 WHATGW, 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.
Lire la suite