Au début 2000, après quatre versions du langage HTML, le W3C tente d'imposer plus de rigueur avec la mise au point du standard XHTML, fondé sur le langage XML. L'objectif est aussi de faciliter la délivrance d'un même contenu sur des plateforme variées (ordinateurs, téléphones portables, ...) et d'offrir la possibilité d'étendre le langage (par exemple avec MathML pour les formules mathématiques ou SVG pour le dessin vectoriel).
Mais le XHTML n'est pas adopté par la majorité des développeurs web. Pire : faute de support par le principal navigateur du marché (Internet Explorer), le XHTML déployé n'a souvent d'XHTML que le nom, étant en fait interprété par le navigateur comme une variante d'HTML, et non comme du XML. Les discussions sur XHTML 2 s'enlisent et une partie des acteurs du marché (dont la fondation Mozilla, Opera et Apple) fondent un groupe de travail séparé, le WHAT WG, pour réfléchir à une alternative, parfois appelée (X)HTML 5.
Le 27 octobre dernier, Tim Berners-Lee, toujours membre du W3C annonce un changement de cap radical : création de trois groupes de travail, dont deux qui travailleront en synergie sur (x)HTML et les améliorations à y apporter, le dernier continuant à développer séparément XHTML 2. Les réactions sont variées, mais toutes saluent une remise en question qu'il était plus que temps d'effectuer (voir la suite de l'article). Depuis plusieurs années, des voix s'élevaient pour regretter qu'XHTML ait été un échec et demander un nouveau virage. Le standard n'était que rarement respecté ce qui amenait certain à le déclarer mort de fait. D'autres recommandaient pragmatiquement de ne pas l'utiliser, sauf dans des cas très particuliers.
L'annonce de Tim Berners-Lee est donc logiquement accueillie plus que favorablement. Daniel Glazman le remercie pour ce changement majeur mais appelle à l'arrêt total du développement d'XHTML 2 pour éviter de diviser les énergies : le gros du travail va commencer maintenant. Karl Dubost de la-grange.net le rejoint sur ce dernier point (et aussi dans ce commentaire) en insistant sur l'aspect fondamental de la collaboration entre développeur et rédacteurs du standard. En effet, seul un standard enthousiasmant pour les développeurs aura une chance d'être adopté.
Il ne reste plus qu'à se retrousser les manches en espérant que cette fois soit la bonne.
Aller plus loin
- Reinventing HTML (1 clic)
- Tim Berners-Lee, thank you (2 clics)
- Le W3C sur wikipedia (3 clics)
- The WHAT WG (2 clics)
- Traduction partielle de l'article de Tim Berners-Lee (5 clics)
# Précision
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
[^] # Re: Précision
Posté par andeus . Évalué à 10.
Donc s'ils n'y mettent pas trop de mauvaise volonté on peut espérer qu'il soit correctement supporté.
[^] # Re: Précision
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Et puis il ne faut pas oublier le navigateur principal du marché, le plus utilisé IE : je doute trés franchement qu'ils implementent XHTML 2 en même temps que les autres, vu déjà l'énorme retard qu'il a (en XHTML1, CSS, HTML4 etc...).
Je suis de ton avis, mais ce n'est finalement pas trés réaliste..
[^] # Re: Précision
Posté par Sylvain Sauvage . Évalué à 4.
[^] # Re: Précision
Posté par andeus . Évalué à 4.
On va faire une bibliothèque de rendu xhtml2 sous licence BSD, ensuite on va la donner à tous les éditeurs de navigateurs, dont microsoft.
</dream>
[^] # Re: Précision
Posté par Mildred (site web personnel) . Évalué à 2.
Je ne sais pas si c'est vraiment une bibliothèque, mais c'est du code BSD, non ?
[^] # Re: Précision
Posté par Antoine . Évalué à 1.
# IE, HTML à la papa et XHTML
Posté par Nicolas Legrand (site web personnel) . Évalué à 5.
« faute de support par _la_ principal navigateur du marché »
Par ailleurs est-ce bien tuile de tirer à boulet rouge sur IE ? Sans aimer ce navigateur, je n'ai eu aucun problème avec lui et XHTML. Si XHTML était incompatible avec IE pensez-vous que la plateforme Skyblog soit entièrement XHTML 1.1 valide ? Ce code est très joli par ailleurs.
Le principe même d'HTML est d'être un langage où les erreurs sont très tolérées, pour que votre page puisse s'afficher de toute façon. Le principe du XML c'est que les erreurs ne soient pas du tout tolérées. Je ne suis pas choqué qu'un navigateur m'affiche une page plutôt que de me dire : « désolé, le XML est non valide, nous ne pouvons afficher la page ».
Ce qui fait que le XHTML ne perce pas plus que ça, c'est à mon avis parce que beaucoup de gens ne codent pas avec leurs éditeurs de texte préférés et que leur logiciel WYSIWYG leur balance des tags HTML à la papa (enfin c'était la reflection que je m'étais faite quand j'ai essayé NVU il y a longtemps) et enfin que HTML marche et que XHTML ne nous apporte pas grand chose par rapport à ça (attention, c'est super d'avoir un document XML pour le remouliner en autre chose, je dis juste qu'on a pas forcémment besoin des possibilités d'XML dans ce que l'on écrit en HTML).
Pour XHTML2, je suis preneur ! J'essairai quand il sera bien supporté par un navigateur.
[^] # Re: IE, HTML à la papa et XHTML
Posté par liberforce (site web personnel) . Évalué à 10.
Je pense que ton le problème du « désolé, le XML est non valide, nous ne pouvons afficher la page » n'en est pas un: le but est de forcer ceux qui écrivent des pages web à prendre conscience de leur responsabilité quand ils écrivent des pages, plutôt que sortir de la bouillie infâme, qui oblige tous les navigateurs à implémenter de mécanismes de rendu plus tordus les uns que les autres.
Donc oui, si un site est codé avec les pieds, et qu'un navigateur ne l'affiche pas, l'utilisateur pourra dire que ce sont les gars du site qui n'ont pas fait leur boulot plutôt que dire "le navigateur bidule il est tout pourri, il m'affiche pas ma page". Et ça me parait bien. Faire l'inverse c'est comme blamer linux de ne pas faire fonctionner out-of-the-box du matériel donc on a pas les spécifications: ça n'a pas de sens. Il est temps de responsabiliser les entreprises sur leurs produits.
Bref, que ceux qui font du désign pourri se tirent les doigts du cul pour pondre un site correct (et y soient contraints par les navigateurs), plutôt que de compliquer le boulot de ce qui font du bon travail.
Quant à XHTML 2, il semble d'après les liens de la dépêche qu'il ait peut de chances d'être un jour adopté...
[^] # Re: IE, HTML à la papa et XHTML
Posté par Nicolas Legrand (site web personnel) . Évalué à 3.
Si tu veux forcer l'arrêt sur les erreurs, cela n'est pas une solution, parce qu'effectivement les gens se diront que le navigateur bidule est mauvais puisqu'avec le navigateur machin ils sauront lire la page. Je trouve complétement illusoire de croire que l'on reponsabilisera qui que se soit, encore moins les décideurs pressés qui veulent que ça « just work » et surtout dans IE 5.5 qu'ils utilisent encore sur leur Mac à la maison.
Le grand intérêt d'avoir un code propre et éventuellement un code XML se trouve à mon avis dans le fait que le code peut être facilement modifié, retransformé. Et ce qui poussera les gens à faire ainsi c'est en temps que développeur Web, quand on se rend compte que c'est en effet plus simple et plus propre comme ça.
L'autre problème c'est finallement que cela n'a pas tellement de sens quand aujourd'hui on ne code plus une page Web en dure, mais qu'elle est issue de CMS, de PHP/MySQL maison, de fichiers XML. Il suffit de regarder en bas à droite de la page de DLFP :
Cette page est peut-être conforme xhtml 1.0...
Le XHTML n'est pas une silver bullet, s'il est difficile de faire respecter les standards, je trouve beaucoup plus convaincant de voir que ces standards te font mieux travailler que de forcer les gens à les suivre. Mais le truc... C'est qu'on ne peut pas forcer les gens... Si IE ne gère pas ce que je veux faire, je ne le fais pas, parce que mon travail ne servira à rien et que je ne peux pas forcer les gens à utiliser une version particulière d'un navigateur.
[^] # Re: IE, HTML à la papa et XHTML
Posté par François B. . Évalué à 10.
Peut-être qu'alors j'aurais moins de remarques du style Firefox c'est nul, regarde, la page est affichée n'importe comment ! (sous entendu, avec IE ça marche).
[^] # Re: IE, HTML à la papa et XHTML
Posté par Thomas Preud'homme . Évalué à 5.
Tout simplement parce que tous nos sites sont présentés avec un type mime "text/html" (ce que vous déclarez dans le "content" de votre )... ainsi qu'un type mime correspondant, envoyé par le serveur.
XHTML peut être présenté comme du HTML (type mime "text/html") ou du XML type mime "application/xhtml+xml"... problème : Internet Explorer ne reconnaît pas ce second type mime et personne (ou presque) ne l'utilise.
Donc je me dit que justement si un code est valide XHTML 1.1 et qu'on met la bonne présentation au début (Cf le type mime "application/xhtml+xml") alors peut-être les gens commenceront à s'énerver sur IE... Sinon y'a le traditionnel bandeau : votre navigateur n'est pas assez récent, merci de mettre à jour vers Firefox/Konqueror/Opéra/autre/ (rayer la mention inutile).
Ai-je dis une bêtise ?
[^] # Re: IE, HTML à la papa et XHTML
Posté par Barnabé . Évalué à 8.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Sun Wukong (site web personnel) . Évalué à 10.
Cautionner les sites dégueux en les laissant en liberté et en permettant aux navigateurs de les afficher, un peu, beaucoup, complètement ou pas du tout, je trouve ça assez ridicule. C'est exactement le même problème que de dire «Boah, j'ai acheté le dernier système de chez Minimou, il est complètement buggué mais ça doit venir de mon PC car il est trop récent, trop vieux, trop sec, trop mouillé, ...»
Un site buggué ne devrait pas exister, en tout cas ne pas être mis en exploitation en connaissance de cause (en dehors du fait que statistiquement parlant, un code source contient toujours des bugs etc ...). Sinon où s'arrête la caution ? À l'alignement des champs ou à l'impression inopportune de la liste des clients, leurs mots de passe ?
La fulgurante évolution du www n'avait guère permis d'imaginer l'accaparation et le détournement du html par des sociétés aux ambitions situées aux antipodes de celles de Berners-Lee. Il est temps d'arrêter les conneries (programmer un site en tenant compte des bugs des différents navigateurs, surtout quand les éditeurs de ces derniers n'ont cure de ces bugs du fait de leur position dominante) et fixer des règles techniques communes pour le net.
Imaginerait-on le leader des ampoules électriques définir une nouvelle tension d'entrée à 300V pour ses ampoules et obliger EDF à modifier la tension qu'il délivre à ses usagers ? :-D
MHA
SW
[^] # Re: IE, HTML à la papa et XHTML
Posté par Nicolas Legrand (site web personnel) . Évalué à 4.
Ensuite tu as les gens qui font un site interpouaite pour eux et leur copains qui vont bidouiller un truc pas très standards mais qui passe vaguement dans un navigateur avec des bouts de scotch. Bon ben c'est pas plus mal qu'ils puissent s'exprimer quand même, c'est le but du WWW aussi. Et rien qu'une page de wiki, de blog où tu peux rajouter des balises qui peuvent tout saloper, c'est quand même sympa de pouvoir enrichir un peu son texte... Dommage de se retrouver coincer parce que quelqu'un n'a pas refermé son <strong> et qu'on veut pas s'amuser à foutre des contrôles partout.
Toute cette histoire c'est un peu comme si les navigateurs s'arrêtaient à chaque fautes d'orthographe ou de grammaire que l'on faisait, parce que le texte n'est pas valid académie française... Bon je fais les efforts que je peux pour parler correctement, mais je ne suis malheureusement pas à l'abris des fautes (rien que dans cette page...).
[^] # Re: IE, HTML à la papa et XHTML
Posté par Joël SCHAAL . Évalué à 4.
Et combien de temps tu gagnerais si tu n'étais plus obligé de vérifier tes modifs sur chaque / la plupart des / quelques navigateur (rayer la mention inutile suivant le courage et la disponibilité du webmaster)?
[^] # Re: IE, HTML à la papa et XHTML
Posté par Nicolas Legrand (site web personnel) . Évalué à 3.
C'est con à dire, mais j'ai toujours trouvé mon code plus propre et plus beau (sans être sublime, je suis loin d'être une star) après avoir rencontré des problèmes dans différents navigateurs. La reflection autour du problème m'a souvent permis d'aboutir à un meilleur code.
Bon des fois ça génère des immondices de dernières minutes.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Antoine . Évalué à 3.
J'imagine que les zélateurs intolérants des standards qui traînent dans le coin n'aiment pas trop qu'on rappelle qu'écrire "selon le standard" ne dispense pas de faire des tests.
Quand on écrit une application portable, on compile sur les plateformes cible pour vérifier que ça marche bien (et on teste le logiciel après l'avoir compilé, hein...).
Quand on implémente un protocole réseau, on cherche à dialoguer avec différents équipements pour vérifier qu'il n'y a pas de malentendu.
etc.
Mais c'est tellement plus facile et démagogique de faire croire qu'en bouffant du standard, on peut faire du code portable sans même le tester sur plusieurs plateformes... Qu'on peut se contenter du validateur W3C au lieu de tester en conditions réelles.
[^] # Re: IE, HTML à la papa et XHTML
Posté par kowalsky . Évalué à 10.
et la vitesse d'affichage des pages en xhtml, html 4, ou même quirks, n'a rien à voir...!
Sur des pages en local, 90Ko de code xhtml s'ouvre immediatement, ou c'est tout du moins
l'impression donnée, par contre, en html, un petite page blanche de plus d'une seconde a
chaque fois, et en quirks, c'est looooong, mais looooong...! Bien sur, pendant que firefox ou
explorer boss, le processeur est full...
Bref, le xhtml, servit en utf-8, c'est pas juste "cool parce qu'il n'y a pas d'erreur'...!
ça accelere le rendue des pages et ça permet de faire de zoli chose en javascript et apres
on peut même dire qu'on fait du web2.0 alors qu'on fait du javascript... :)
Et en plus, c'est asser simple à générer, ya juste quelque truc à savoir...
[^] # Re: IE, HTML à la papa et XHTML
Posté par Mathieu Pillard (site web personnel) . Évalué à 7.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Xavier Poinsard . Évalué à 1.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Mathieu Pillard (site web personnel) . Évalué à 0.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Gabriel . Évalué à -3.
Je suis d'accord 1000 fois avec le grand Nicolas. On n'a pas à donner des contraintes excessives aux gens. Qu'une page soit mal foutue, qu'elle ne valide pas: et alors? On ne brise aucune loi, on ne gêne personne, on a juste son site qui s'affiche de manière pas standard. Et alors? ça gêne qui?
Pour préciser: je suis Aussi grand grand partisan du xhtml, de code valide et des possibilités offertes par le code valide: xhtml pour sortir un flux valide, qui peut aussi bien être vu par un navogateur que parsé par un batch; css nickel chrome etc. J'en suis partisan et je pratique. Je déteste pour moi même produire du code invalide. Vraiment, j'en suis même pénible.
Mais! Il y a un Mais Enorme. Ce n'est pas parce que je suis horloger que je vais demander à tout le monde d'avoir une montre, et qu'en plus leur montre soit à l'heure à 5 secondes près.
Après cela repose le problème de l'outillage, ok. Mais je pense qu'il est du devoir d'un navigateur être accueillant, envers totu code.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Gabriel . Évalué à 3.
- Vous avez déjà regardé le source du site du Pape de la css, Eric Meyer (http://www.meyerweb.com ). L'en-tête... oui oui. C'est bien du html. Tout simple. Et très souple.
- Deuxio, si vous voulez vraiemtn faire du xhtml, donc du xml, il faut un balise >xml...< au début de la page. Sauf qu'un navigateur très utilisé vous jettera. Oui, il a tord, mais est-ce que juger que ce navigateur a tord amène une solution au fait que la page ne s'affiche pas? Non... Bon, alors il faut mettre une première balise html et là, hop, c'est plus du xml.
Le choix n'est pas entre xhtml et html, ni entre valide/Bien et non valide/Mal, mais entre non valide=Normal et valide=Bien.
Il faut que cela apporte quelque chose d'avoir une page valide. Sinon, c'est juste respecter une règle sans que cela amène quoi ce soit fonctionnellement dans le cas le plus répandu.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Moonz . Évalué à 10.
- soit tu n'es pas un horloger, et tu t'en remets à un horloger pour trifouller dans le mécanisme de ta montre
- soit tu es un horloger et tu peux touhcher au mécanisme de ta montre toi même. Mais dans ce cas, tu le fais BIEN
Du côté des pages internet:
- soit tu n'es pas un codeur dans l'ame, et tu t'en remets à un logiciel qui fait tout bien à ta place (pour les photos de ton chien par exemple)
- soit tu en es un et tu comprends que être strict est important
Le problème du web actuel, c'est que lea plupart des horlogers (éditeurs wysiwyg) font leur boulot comme des porcs, et que des tas de personnes s'improvisent horloger et mettent les mains dans le cambouis sans savoir ce qu'ils font (le plus souvent, n'importe quoi).
>Mais je pense qu'il est du devoir d'un navigateur être accueillant, envers totu code.
Absolument pas. Soit tu t'y connais, et tu es capable de faire du bon code. Soit tu t'y connais pas, et tu laisses faire NVU... Pas de place pour le code crade AMHA...
[^] # Re: IE, HTML à la papa et XHTML
Posté par Gabriel . Évalué à -2.
Et oui, il y en a certaines que je n'ai jamais pu remonter. Eh... au moins j'ai essayé.
>Soit tu t'y connais, et tu es capable de faire du bon code. Soit tu t'y connais pas, et tu laisses faire NVU... Pas de place pour le code crade AMHA...
Je dirais plutôt: si tu as quelque chose à dire, internet te propose le maximum d'audience et le moins de contraintes humainement possibles.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Guillaume Knispel . Évalué à 9.
Non pas que le niveau mondial ait tout d'un coup radicalement augmenté, mais simplement soit:
* la personne utilisera un moteur tout fait pour faire un blog, un wiki ou autre (voir un site tout fait lui proposant de hoster son blog).
* la personne fera du php ou autre (parce que maintenir un site en full html, faut etre un peu maso s'il fait plus de quelques pages), et si elle est capable de faire ça elle sera capable de produire de l'(x)html correctement.
Enfin les outils de validation abondent et indiquent clairement (du moins la plupart du temps) ce qui ne va pas.
Les navigateurs capablent de corriger quelques erreurs avaient un sens il y a une dizaine d'année voir plus, lorsque les amateurs n'avaient que peut d'outils et que pour s'exprimer il était effectivement bon de laisser ceux qui avaient un minimum de connaissance faire rapidement quelquechose accessible à tous.
Aujourd'hui le contexte est radicalement différent et maintenir un base de code énorme et lente dans les navigateur rien que pour essayer de corriger les erreurs automatiquement (ce qui ne peut jamais marcher à 100%! imaginez un compilo C qui corrige votre code à votre place sans rien vous dire, ça y est vous avez peur ? ;)
n'a plus beaucoup de sens, la proportion de personne pouvant légitimenet produire de telles erreurs étant trop basse.
J'ai envi que mon navigateur soit moins lourd et moins buggué, pas que mon ordinateur passe son temps à faire de savants calculs pour essayer de desambiguifier du mieux possible un truc syntaxiquement incorrect.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Antoine . Évalué à 3.
Jusqu'au jour où tu veux personnaliser la mise en page, et là il faut sortir l'éditeur wysiwyg (si le système de templates le permet) ou faire du code à la main.
Aujourd'hui le contexte est radicalement différent et maintenir un base de code énorme et lente dans les navigateur rien que pour essayer de corriger les erreurs automatiquement
Il ne s'agit pas forcément de "corriger les erreurs" (ce qui effectivement n'a pas de sens) mais au moins d'être capable de les ignorer pour s'intéresser à ce qui reste extractible. Au lieu de s'arrêter en sortant une erreur fatale. Or en HTML le texte du document reste toujours extractible, donc autant en faire quelque chose.
Il faut se réveiller : HTML n'est pas le seul domaine où l'on cherche à ne pas s'arrêter aux erreurs. Dans beaucoup de normes IETF, il est demandé aux implémentations d'ignorer les constructions qu'elles ne comprennent pas (tel en-tête inconnu dans le protocole, par exemple). Si on impose la validité d'un document XML (pas seulement son caractère bien formé), on devient d'un coup beaucoup plus strict que l'IETF.
Il y a sans doute peu de standards non-triviaux qui sont respectés à 100% par les principaux acteurs, même ceux de bonne foi. Récemment gcc avait un bug d'ABI C++. On peut certainement multiplier les exemples.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Mildred (site web personnel) . Évalué à 6.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Antoine . Évalué à 2.
En théorie, sauf qu'en pratique, la façon dont tu structures ton document (X)HTML influe sur les combinaisons d'effets qui sont possibles.
Par exemple si tu fais une série de blocs en "float", l'ordre dans lequel sont déclarés les blocs influe sur le positionnement dans la page. Donc tu peux avoir à remanier le document X(HTML) pour changer la mise en page.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Mildred (site web personnel) . Évalué à 2.
Ou alors, un autre truc que je regarde en ce moment : DSSSL qui gère à la fois la mise en forme et les transformations ... mais l'implémentation Jade n'a pas l'air complète au niveau des transformations.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
Mais faire une page dynamique et être sûr qu'elle restera valide quoi qu'il arrive, c'est une autre paire de manche. C'est si facile de laisser passer une balise incorrecte ou un & dans un commentaire sur un forum, un blog ou linuxfr ...
Bien sûr que quand on code correctement, ça n'arrive pas, mais je ne trouve pas que ça soit une question « triviale ».
[^] # Re: IE, HTML à la papa et XHTML
Posté par pasBill pasGates . Évalué à 1.
- soit tu n'es pas un codeur dans l'ame, et tu t'en remets à un logiciel qui fait tout bien à ta place (pour les photos de ton chien par exemple)
- soit tu en es un et tu comprends que être strict est important
C'est genial, quand on te lit on dirait qu'il n'y a que 2 types de pages qui devraient etre dispo sur le net :
- Celles ecrites avec un editeur qui respecte les standards
- Celles ecrites par des apotres du HTML strict
Si on suivait ce que tu dis, Google serait ravi, ils n'auraient besoin que de 2 ou 3 ordinateurs pour indexer le web, car quasiment toutes les pages web ne repondent pas a ce critere.
Il y a un truc que bcp de gens ici ne comprennent pas : C'est bien beau d'etre un apotre du tout parfait, mais le tout parfait ca n'existe pas et se limiter a ca ca revient a se couper du monde.
Alors t'es libre d'utiliser un browser web qui ne montre que les pages web parfaitement standard si tu veux, mais moi je preferes pouvoir lire ce qu'il y a sur le web sans me priver des 95% qui ne sont pas valides.
[^] # Re: IE, HTML à la papa et XHTML
Posté par FReEDoM (site web personnel) . Évalué à 3.
=============> [] clac-clac... merde c'est fermé !!!
[^] # Re: IE, HTML à la papa et XHTML
Posté par Moonz . Évalué à 3.
J'ai juste dit que j'aimerais bien qu'il soit comme ça :p
[^] # Re: IE, HTML à la papa et XHTML
Posté par Éric (site web personnel) . Évalué à 10.
Moi, tous les jours.
En temps qu'utilisateur parce que mon navigateur "pèse" très lourd sur mon système coté ram et proc.
En temps que technicien parce que tout ce qui est fait sur le Web prend beaucoup plus de temps parce qu'il faut garder la compatibilité/communication avec tel ou tel autre qui lui n'a pas codé correctement et fait dérapper mon code.
> Franchement, blâmer les gens parce qu'ils n'ont pas fait du xhtml correct?
Franchement ? oui. Si je te répondais : blamêr les gens parce qu'ils ne font pas du ciment parfait ?
Tu me répond non ? j'espère que ta baraque ne va pas te tomber sur la gueule. Tu me répond oui ? tu risques de voir le voisin ne pas apprécier ta remarque sur son muret de 30cm dans son jardin.
La question ce n'est pas de blamer ou pas, c'est plutot qui, pour quoi et comment :
- Les techos/professionnels qui font du mauvais code, oui, ils sont à critiquer. C'est leur boulot de savoir, de la même façon que c'est le boulot de ton maçon de faire les murs de ta baraque.
- Les néophytes en informatique on a une chance : ils utilisent des outils. On peut donc se reporter au premier cas, c'est à dire sur les techos qui ont fait l'outil. Eventuellement par contre on peut guider le néophyte vers un meilleur outil.
- Reste le passionné qui fait du code direct, mais n'importe comment. Un peu comme le gars qui fait sa propre baraque avec du mauvais ciment. Le cas n'est heureusement pas le plus fréquent, mais je le classerai plutot avec les techos, justement parce qu'il a choisi de se ranger avec eux.
> Mais je pense qu'il est du devoir d'un navigateur être accueillant, envers tout code.
Strict en sortie, laxiste en entrée. Je pense qu'on est tous d'accord avec ça. Reste à ne justement pas oublier d'être strict en sortie ;)
En oubliant on fini par devoir utiliser des monstres pour interprêter les entrées, à faire perdurer et cascader des bugs de compatibilité à gogo, et à faire de l'empirique sans avoir de référence. Tout le problème (enfin une grosse partie) des navigateurs actuel est là.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Gabriel . Évalué à 1.
Un site par exemple que j'aime bien : www.iran-resist.org . Il est fait vraiment n'importe comment. J'en suis malade. Des titres de toutes les couleurs, de toutes les tailles. ça sent les amateurs qui rajoutent du bleu ou du rouge.
Mais le contenu est unique! Ils veulent mettre des "font" partout? Je le déplore mais ça ne m'empêche pas de les lire.
Au contraire, n'est-ce pas enthousiasmant de voir que des gens peuvent avec tant de facilité mettre du bleu ou du rouge? Et s'ils devaient se soucier plus de technnique et de validation, ou de séparation des responsablités (xhtml/css) s'ils devaient prendre le temps pour comprendre que ça ne se fait pas de rajouter des balises "font" n'importe où; et qu'en général un titre étant un titre il serait plus rationnel de garder une seule couleur: cela reviendrait à leur imposer une vue, une façon de faire.
Mais par malheur de telles remarques mal dites pourraient les freiner dans leur élan de publication - ils s'arrêteraient à se dire que publier sur internet n'est pas si facile. Alors que si: c'est simple. Le html se compose d'une série de balises invisibles lors de la publication, et d'un peu de texte dedans, point barre.
Et ... Et de quel droit ils ne pourraient pas penser qu'un titre peut être rouge, bleu, vert, de font 16, 12, etc... Est-ce qu'on se donne pas une facilité, en disant que tout titre est en gras 16 de tel couleur? Pourquoi pas des titres bariolés?
Vu que le prix à payer est la liberté, je pense que c'est à la technique de s'adapter, d'accueillir le html malformé.
Vu que le nombre de pages qui ne valident pas est bien supérieur au nombre de pages qui valident,cela veut dire qu'une page invalide c'est cela qui constitue le cas nominal.
Ta comparaison avec le maçon est intéressante, puisque justement des tas d'amateurs construisent leur maison ou refont des parties de leur baraque. Et, s'ils suivent tout de même le B-A-BA de la construction, leur manque d'a priori leur donne une latitude qu'on aurait vite tendance à oublier. Pense au Facteur Cheval.
Et oui j'espère que ma baraque ne va pas me tomber sur la gueule. Mais je préfère ma baraque mal foutue, à la baraque d'un autre, bien pensée, mais que je n'ai pas prise dans mes mains.
Je préfère les gens qui se plantent à ceux qui n'expériment pas. Comme au cinéma, je préfère un film pas parfait mais unique et qui montre qu'il y a un geste derrière, une volonté, un désir (le Roi et l'oiseau) à un film parfait et attendu (Le Seigneur des anneaux).
Mais, est-ce que notre discussion sur la validation est centrale?
La question ne me semble pas celle de la validation mais de la liberté que donnent - ou pas - les outils. Si Nvu ou Dreamweaver permettent de créer son site en xhtml strict, tant mieux. Pourtant la validation du résultat n'est pas si évidente, parce qu'ils laissent beaucoup de marge de manoeuvre à l'utilisateur. L'outil peut mettre des "li" vides, invisibles quand on regarde la page, puis après 2/3 copier/coller, la page se retrouve avec des "li" fantômes au mileur d'une suite d'images qui n'en demandait pas tant. Mais on peut quand même admettre que les outils de la sortes sont de plus en plus efficaces.
On a aussi de plus en plus de cms qui valident, de wiki qui valident, et flick, et les blogs et les galleries toutes faites etc... ça réduit beaucoup le nombre de sites persos faits n'importe comment. Donc le problème se circonscrit avec le temps et l'outillage.
Enfin, on a de plus en plus de web 2.0 qui transforme le html en une coquille vide à remplir. Alors, la question de la validation - et du code qui "fait" la page - devient plus perverse.
On a donc de plus en plus d'outils qui font du html valide.
A mon avis, le souci principal est de garder la souplesse du html, sa simplicité, tout en ajoutant les possiblitrés de génération et de manipulation, de contrôle, que l'on expérimente tous les jours sur les sites enclins à la web-deux-isation.
Si on veut amener les gens à faire du code plus "valide" il faut qu'ils y trouvent un intérêt et pas de frein. Que le tag machin avec son id soit ainsi aisément transformable grâce à de la validation xforms ou du script ajax ammoniaqué.
Tagger c'est ajouter, c'est présenter, enrichir son langage d'une certaine communication avec les autres. Mais que cela n'interdise pas l'accès au sens même de ce qui est taggé.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Éric (site web personnel) . Évalué à 8.
Si on parle de notre soupe de balise HTML alors le terme "liberté" est basé sur une méprise. Il n'a jamais été question d'interdire. Il s'agit d'inciter ou d'informer dans le cas de nos amateurs passionnés.
Par contre, l'information ça passe aussi par dire que le code est mauvais quand il est mauvais. Ca ne sert à rien de se voiler la face ou de dire "oh il est joli ..." comme si on s'adressait au brouillon d'un enfant de deux ans. Il n'y a pas de mal en tant qu'amateur a faire un code qui ne soit pas très joli, mais il faut l'assumer : il n'est effectivement pas bon. Dire "c'est normal et c'est très bien comme ça" non seulement ne fait pas avancer le shmilblick mais en plus le fait reculer.
Les seuls cas où la validité devrait être une règle (et loin d'être la seule) c'est pour le cas de services publics, ou d'entreprises de services de base. Parce que là ça peut se révéler une nécessité, et que ça devrait être fait par des gens du métier, qui eux n'ont pas de justification à faire n'importe quoi.
Si on parle de XHTML alors la question méritait d'être posée. Les dégat de la soupe de balise interprétée différement partout, faute de savoir quoi en faire, on a déjà les dégats sur le Web.
L'idée c'est de dire que le code xhtml est simple, même quand il est bien fait. Faire du code valide n'est pas complexe. Parti de là si ton amateur il voit que le code ne fonctionne pas dans le navigateur lors des tests, il va tout de suite corriger. Un peu comme si son ciment ne tient pas, il le refera.
Si on part du principe que le XHTML est simple, que faire attention à faire du code valide avec les bons outils n'impose pas une barrière à l'écriture, alors des navigateurs qui bloquent à la première erreur fatale sont une bonne chose. Il n'y a pas d'existant à maintenir, il n'y a pas de pages mal faite dont on risquerait d'empêcher la lecture.
Les erreurs fatales du XHTML permettent justement à notre auteur amateur d'avoir la barrière à l'entrée minimum. Au lieu de produire une page et de devoir la lancer partout pour vérifer que sa soupe n'a pas d'implication différente, il sait que le passage sur un navigateur lui garantira qu'au minimum la structure sera la même partout. Oui, théoriquement c'est ce qui devrait être fait avec un validateur plutot qu'un navigateur mais les gens utilisent le navigateur pour ça, alors évoluons aussi.
Pour le HTML c'est trop tard, justement à cause de l'existant. Pour le XHTML je pense que ce cas là est jouable, sérieusement. Si IE7 était sorti avec un support réel du XHTML tout en restant laxiste, ma position changerait. Ce n'est pas arrivé, et j'espère que ça n'arrivera pas (entendre: s'il supporte le xhtml ça sera en traitant les erreurs fatales comme fatales).
Mais globalement "être laxiste" ce n'est pas si simple que ça. Etre laxiste c'est accepter que la structure "lue" par les navigateurs soient différente sur chaque navigateur, justement parce que par définition un document mal formé ne peut pas toujours être compris sans ambiguité.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Gabriel . Évalué à -1.
Après réflexion - et après le passage des moinseurs (ne vous gênez pas, le bouton est en bas :-) (je dis cela parce que c'est assez énervant de voir une position simplement pragmatique se faire dezinguer juste parce qu'elle n'est pas dans les Canons. Mais bon... Vous jugez comme vous voulez, je juge comme je veux aussi.) - Bref, après réflexion, j'ai deux ou trois remarques:
D'abord, je continue à penser que le xhtml valide est un frein à la publication. Ce n'est pas comme de dire que l'orthographe est un frein à l'expression - bien que Rousseau par exemple, le plus immense styliste de la langue française, avait une orthographie lamentable, mais glissons - car l'orthographie est liée au mot, elle en porte une histoire et une épaisseur. La balise est un sens qui vient au dessus du sens, il est l'intrusion d'une langue étrangère dans la langue. Ce qui peut le rendre intéressant, d'ailleurs, par son étrangeté même.
J'ai souvent fait du xhtml et des fois, lorsque je générais un tableau (un tableau de résultat, calmez vous, pas un td/tr ça pue c'est pas bien) avec un sous tableau de résultat et uen structure bien compliquée, oui, je pouvais me planter en codant. Je pouvais générer du code invalide. Oui. J'avoue. ça m'est parfois arrivé... Et au non de Saint >li< saint patron de toutes les pages valide, j'en demande pardon...
La validité demande un surcroît de travail et d'attention. C'est tout simple. On peut quand même partir de cette évidence?
Maintenant, partant de ce constat, il faut se demander qui fait le travail. C'est souvent comme cela. Quand il y a quelque chose à faire, il faut juste se demander qui le fait.
En demandant au navigateur d'être un peu souple, un peu malin, pas trop casse bonbon parce qu'il manque une balise fermante, je sais pas ... Ok, on demande au navigateur un surcroit de travail, mais je me demande si ce n'est pas de demander au codeur un surcroit de travail, qui énerve. (le bouton de moinssage est en bas, allez y! Faites comme les chiens de Pavlov, montrez vos dents quand on vous donne un signal qui normalement doit vous énerver!)
En demandant de faire des pages valides le travail sera effectué par le publieur. Chose normale pour un professionnel - ou du moins ça devrait l'être.
Mais cela veut dire quand même un plus grand départ entre ceux qui ne savent pas le faire et ceux qui savent. Il y a une distinction entre les gens qui "savent" et ceux qui ne savent pas. ça me gène profondément. Pour moi c'est anti-web.
Pour aider les gens à faire du code valide, ils devront alors passer par un professionnel ou par un outil. CMS, blog, Nvu... C'est alors l'outil qui fera le travail à leur place.
Dans tous les cas, plus validation entraîne un surcroît de charge. Pour l'outil de publication, pour le publieur, ou pour le navigateur.
Il me semble que ça'aurait été une solution d'avoir deux langages: un xhtml détaché du web, avec ses propres lois, et ses propres bienfaits. Et un html pour un standard léger de publication. Mais.. on est sur la toile. Tout doit communiquer, par une interface privilégiée - le navigateur. Donc le navigateur doit prendre en charge ces deux langages et avec assez de souplesse ..
Je pense souvent un truc qu'a écrit ici je crois PBPG concernant Microsoft. Il a fait remarqué que m$ a donné la possibilité de faire un réseau à des gens qui n'en avaient par au départ la capacité. Et cela avait été un grand pas en avant pour beaucoup de pme.
Je pense pareil du web et des navigateurs et du html. Ils ont pemis à des milliers de gens de publier sans passer par des professionnels. C'est un gain Précieux.
Ce débat de toutes façons a déjà eu lieu. Et les tenants du "lachez nous les baskets" ont déjà une sale réputation. Mais je n'en démords pas, même si ce n'est pas très fashion.
Mais je continue à penser que le VRAI, le SEUL débat concerne le web2.0.27-001282 , l'ajax, les interfaces riches, le rdf, les XForms d'un côté; et le we sémantique, les tags, l'exploitation sémantique de l'autre etc. Et ce débat n'a pas encore eu lieu.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Antoine . Évalué à 3.
Surtout, la grosse différence, c'est que si ton message contient des fautes d'orthographe, il est quand même en général accepté par le récepteur (avec des niveaux de tolérance variés selon les individus).
Avec le XHTML validé en mode XML, bernique !
Ok, on demande au navigateur un surcroit de travail, mais je me demande si ce n'est pas de demander au codeur un surcroit de travail, qui énerve.
Bien vu. La majorité des gens ici sont des programmeurs (je le suis aussi) qui valorisent leur tranquillité. Mais c'est perdu d'avance : toute l'informatique va au contraire dans le sens d'une complexification de la tâche des programmes, précisément pour simplifier celle des utilisateurs.
(c'est même à ça que sert l'informatique, hein)
Le pire c'est qu'il n'y avait absolument pas besoin de XML pour rendre la grammaire un peu plus rigoureuse. Il suffisait de spécifier dans la norme HTML la machine à états qui construit l'arbre à partir des balises. Ce serait pas la première fois qu'une norme spécifie une machine à états.
Le pire c'est qu'il est à peu près admis que XML n'est pas fait pour être produit par un être humain (juste lu, et encore... vas-y pour lire du RDF encodé en XML). Mais sur ce forum on nous explique benoîtement que des webmestres devraient être capables de coder le XHTML dans le texte, et sans erreur.
(et les zigotos qui pensent qu'omettre des balises fermantes empêche un parsing rigoureux n'ont jamais dû utiliser Python, ou alors ils n'ont pas remarqué que le parser savait refermer une classe en même temps que la dernière méthode... et penser que ça bouffe beaucoup de cycles CPU est quand même d'une ânerie grave, les algos de positionnement CSS sont certainement mille fois plus compliqués)
Mais le W3C trouvait sûrement plus rigolo de lancer un autre standard parallèle à l'original, en plus on peut mettre du MathML dans les pages, chouette, ça va servir à au moins 0,01% des webmestres... Et à côté de ça, aucune fonctionnalité importante en plus, tout ce qui est bouge étant du côté de CSS, Javascript, Ajax & co (c'est-à-dire de façon orthogonale au schisme HTML/XHTML).
[^] # Re: IE, HTML à la papa et XHTML
Posté par sobek . Évalué à 2.
En même temps, que ce soit en C, en perl ou dans la majorité des langages, si tu codes aussi cradement que la moyenne des pages en html, tu peux toujours espérer un miracle pour que cela "tombe en marche".
Et même si je ne les trouve pas forcement adaptés à tous les usages, les langages à preuve comme OCaml, Eiffel, etc, relèvent un peu de la même logique.
Faut voir...
Je suis contre un élitisme dans le domaine, mais le pire piège de mon point de vu, c'est de faire croire que l'informatique c'est "magique".
On risque sinon de tomber dans les mêmes travers que MS, ou tout est fait pour faire croire que l'informatique est un jeu d'enfant, au prix d'une stabilité et d'une sécurité souvant discutable.
Mais XHTML est loin d'être le pide des formats XML que je connaisse. Avec un poil d'habitude, c'est assez rapidement lisible.
Et pour avoir l'occasion de donner quelques cours sur le sujet, la plupart des élèves que nous avons (et qui ne sont pas tous informaticiens, loin de là) sont capables de faire des pages simples et valides après seulement 3 ou 4 demi-journées. Peut-être pas du premier coup, certe, mais ils sont capable de comprendre les erreurs du validateur et de corriger. Le "valide du premier coup" viendra ensuite avec l'expérience.
Alors lorsque l'on me dit que des webmestres, dont c'est le métier de tous les jours, n'en sont pas capables, cela me fait doucement rigoler.
Bizarrement, j'ai un point de vue radicalement différent sur le sujet... Quand je vois que des collègues ont encore perdu 2 jours de taff à cause d'un espace mal placé dans du code python, alors qu'ils sont loin d'être des débutants dans ce langage, cela à tendance à me conforter dans l'importance des délimitations de bloc (et eux aussi manifestement ;)
[^] # Re: IE, HTML à la papa et XHTML
Posté par Antoine . Évalué à 1.
Vive le sophisme, là, coco.
Démontre-nous d'abord que cette "lourdeur" est liée au code supplémentaire dans le moteur de rendu, et pas au navigateur lui-même avec son interface graphique, ses plugins, son XUL, son système de composants et autres machins embarqués.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Juke (site web personnel) . Évalué à 7.
Les gens qui veulent developper des navigateurs (graphiques à la mozilla) ,
des terminaux brailles,
des navigateurs mobiles,
des moteurs de recherches, des moteur de traduction.
les gens avec une faible bande passante.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Mildred (site web personnel) . Évalué à 5.
- Essaie de faire un
- Et sûrement d'autres choses
Non, IE ne comprend pas XHTML, ou alors uniquement dans la mesure où cela ressemble à du HTML.
[^] # Re: IE, HTML à la papa et XHTML
Posté par left . Évalué à 5.
[^] # Re: IE, HTML à la papa et XHTML
Posté par MrLapinot (site web personnel) . Évalué à 1.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Éric (site web personnel) . Évalué à 4.
Moi ça me parait au contraire quelque chose de très bien pensé que de permettre de repérer la grammaire en plus du langage. A la limite j'aurai bien vu des xml/xhtml et xml/svg plutot que les application/xhtml+xml ou application/svg+xml.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Éric (site web personnel) . Évalué à 3.
Il faut :
- envoyer le code en application/xml (c'est accepté pour du XHTML)
- faire une balise de [?xml-stylesheet ..] qui mène vers un XSLT ... qui se contente de ne pas toucher le document (renvoyer chaque balise telle quelle).
MSIE sait gérer le XML+XSLT=>HTML et a l'impression qu'il se retrouve dans ce cas là. Du coup .. ça fonctionne. (bon, ça fait un peu bidouille aussi, c'est vrai)
[^] # Re: IE, HTML à la papa et XHTML
Posté par Moonz . Évalué à 3.
Elle est bien bonne celle là.
Chez moi, IE se vautre lamentablement sur une simple balise <script src="foo" /> (il ne comprend pas que le /> ferme la balise et interprète le reste de la page comme du JavaScript...)
[^] # Re: IE, HTML à la papa et XHTML
Posté par Nicolas Legrand (site web personnel) . Évalué à -2.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Nénuphare Rose . Évalué à 8.
IE comprend le XHTML en faisant comme si c'était du HTML, il le traite avec son parseur HTML tout ce qui n'est pas du HTML standart est considéré comme une erreur. Ca marche uniquement par chance, parce que les erreurs ne perturbent pas trop IE, et des fois ça plante. Faut aimer la loterie.
Mais c'est le même problème avec les autres navigateurs. Une fois qu'ils ont reçu le mime-type "text/html", ils traitent aussi le document XHTML comme du HTML avec des erreurs (d'ailleurs, Firefox n'a pas le même rendu pour une page servi en text/html et la même page servi en application/xhtml+xml), et le fait qu'ils arrivent à bien rendre un document avec le mauvais mime-type vient de leur capacité à négocier les erreurs... Encore de la loterie.
Finalement, tant qu'on a pas besoin des possibilités d'XHTML, il vaut mieux rester en HTML4.01 strict.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Mildred (site web personnel) . Évalué à 2.
C'est un peu ce que je fais chez moi (j'utilise tidy et des makefiles pour la conversion xhtml -> html), sauf que comme gecko n'a pas de préférence entre html et xhtml, apache, lui, semble préférer sortir la page html :(
Pour ceux que cela peut intéresser :
http://httpd.apache.org/docs/2.0/content-negotiation.html
[^] # Re: IE, HTML à la papa et XHTML
Posté par Nénuphare Rose . Évalué à 1.
Sinon c'est quand même dix fois plus simple de rester en HTML4.01 strict..
[^] # Re: IE, HTML à la papa et XHTML
Posté par liberforce (site web personnel) . Évalué à 5.
ça c'est la théorie. Après le pratique, malheureusement, si tu veux manger, c'est que tu fais ce que t'a demandé ton patron, quitte à coder comme un goret. Donc si ton patron veut pas bouger, il faut forcément lui forcer la main en changeant les standards du métier, que les gens apprendront dans les écoles, et qui sera vraiment mis en pratique sur le terrain. Avec un peu de bol c'est lui qui demandera ensuite à faire un truc XHTML58 parce que c'est bien, il en a entendu parler (feel the Web 2.0 effect).
[^] # Re: IE, HTML à la papa et XHTML
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
Le gros problème est que la plupart des écoles enseignent les sites en Flash, le mode d'emploi de FrontPage et de Dreamweaver. Quant aux normes du web, les étudiants n'en n'ont jamais entendu parler.
Je pense qu'il serait intéressant de lister les écoles de webmestres qui enseignent la conformité au W3C et celles qui l'ignorent. Ce serait un moyen de pression efficace.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Antoine . Évalué à -4.
J'adore cette vision candide où les webmestres seraient des amoureux de la technique susceptibles de se passionner pour la grammaire d'un langage à balise, plutôt que de se concentrer sur ce qu'ils ont envie de faire (avec un éditeur wysiwyg, donc, pour l'immense majorité d'entre eux). Le syndrôme habituel des nerds autistes qui pensent que tout le monde partage les mêmes centres d'intérêt qu'eux.
Bientôt Jarillon demandera aux graphistes faisant du dessin vectoriel de connaître la grammaire du format SVG, et menacera de "faire pression" sur les écoles n'imposant pas un tel enseignement. :-)
En passant, j'espère qu'il connaît la théorie de la conception des polices de caractères, car c'est un préalable indispensable avant de mener des conversations textuelles sur Internet. Je propose qu'on fasse pression sur les forums Web qui ne fournissent pas un tel enseignement à leurs lecteurs, et risquent ainsi de les laisser utiliser de mauvaises polices de caractères.
Ce serait un moyen de pression efficace.
Y a de l'idée : tu peux les menacer de les rendre improductifs en les faisant éclater de rire.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Mildred (site web personnel) . Évalué à 4.
C'est comme si inkscape ne produisait pas des documents svg valides
[^] # Re: IE, HTML à la papa et XHTML
Posté par lambada . Évalué à 8.
J'adore cette vision sordide où les webmestres seraient des scribouillards non scientifiques pas foutus d'apprendre à maîtriser un minimum leur boulot. Parce que oui, les webmestres sont des informaticiens et cela leur impose de connaître les bases de leur métier, c'est à dire le (X)HTML et ce qui va avec.
Ça n'empêche absolument pas de privilégier un éditeur WYSIWIG hein, surtout que certains commencent à privilégier la validité du code généré, comme Microsoft Expression (sic) paraît-il.
Comprendre les bases de son activité et avoir une vue d'ensemble de cette dernière c'est être un "nerd autiste" ? Ou alors webmaster = simple utilisateur de dreamweaver, mais dans ce cas là...
Sauf qu'un graphiste n'est pas un informaticien, à l'inverse d'un webmestre, et que ses outils sortent bien plus souvent un format standard (de fait ?) et/ou valide.
Et puis d'ailleurs, sans aller jusqu'à la connaissance parfaite du format SVG, tu penses pas que ce serait un minimum enrichissant pour un graphiste d'étudier ses choix techniques et diverses problématiques les ayant guidés ?
De l'ironie facile tu finis par verser dans le sophisme. C'est un boulot pour toi, "mener des conversations textuelles sur internet" ?
Et après ça traite les gens de "nerds autistes".
Je t'épargne la citation de Gandhi.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Antoine . Évalué à -1.
J'imagine que le terme "simple utilisateur" est censé être péjoratif, et c'est quand même là que c'est révélateur.
Un peintre, c'est un "simple utilisateur de pinceaux" ?
Un journaliste ou un écrivain, un "simple utilisateur de traitement de texte" ?
Sauf qu'un graphiste n'est pas un informaticien, à l'inverse d'un webmestre
Vis-à-vis de quelle définition précise de "l'informaticien" ? Celles que tu as choisie pour les besoins de la discussion ?
En quoi un gars qui fait des graphismes 2D ou 3D est-il moins aux prises avec l'informatique qu'un type qui fait des pages HTML ? Où traces-tu la ligne ? Là où ça t'arrange ?
Je t'épargne la citation de Gandhi.
Oui, il vaut mieux nous l'épargner, parce qu'à moins d'être très naïf, on remarque assez vite que beaucoup de mouvements à qui cette citation pouvait s'appliquer n'ont pas vraiment réussi...
Et que Gandhi, ce n'est pas avec quelques citations rêveuses qu'il a remporté son combat (même si ce fut de façon pacifique).
http://fr.wikipedia.org/wiki/Mohandas_Karamchand_Gandhi
[^] # Re: IE, HTML à la papa et XHTML
Posté par Pierre Jarillon (site web personnel) . Évalué à 9.
C'est pourtant ce qui se passe dans les écoles de webmestres ou de graphistes où l'on n'apprend pas les bases du métier. Il est nécessaire à un ingénieur de connaître les mathématiques, à un mécanicien de connaître un peu la physique, à un agriculteur d'avoir des notions de biologie et à un webmestre de comprendre que le web est un moyen de communication qui doit respecter un vocabulaire et une grammaire compris de tous.
Trop souvent, on apprend à répéter un mode opératoire (comme les certifications Microsoft) et non à comprendre les principes de ce que l'on fait. C'est le cas de ces écoles indigentes qui contribuent à pourrir le web.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Antoine . Évalué à 4.
Le Web étant un moyen de communication, le vocabulaire et la grammaire en question sont ceux des moyens graphiques, textuels, et hypertextes utilisés pour convoyer un message (sous-entendu : destiné aux humains qui le lisent).
Pas la grammaire du HTML qui est le format informatique sous-jacent !
Alors, je reprends ton analogie et je la corrige : c'est comme si tu demandais à un prof de français de connaître les règles typographiques d'impression du français, ou les mécanismes de fabrication du papier. Sûr que ça ne fait pas de mal, mais ça ne fait pas partie de son métier.
[^] # Re: IE, HTML à la papa et XHTML
Posté par imalip . Évalué à 7.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Antoine . Évalué à 2.
Justement, dans l'analogie, ils ne font pas du papier dans leur garage, puisqu'ils utilisent Word ou Writer (DreamWeaver).
[^] # Re: IE, HTML à la papa et XHTML
Posté par lambada . Évalué à 3.
T'imagines mal. Ici "simple utilisateur" est à distinguer de "professionnel", qui n'a pas à connaître le (X)HTML.
Par exemple, pour conduire une voiture, je n'ai pas à connaître les principes "bas-niveau" de la physique qui sous-tendent la discipline.
Par contre j'estime qu'un mécanicien automobile *doit* les connaître, même s'il n'en a pas l'usage tous les jours.
???
Ben non justement, dans la mesure ou c'est leur métier, on est bien d'accord que c'est pas le cas !
Je pense (ne connaissant pas du tout le domaine) qu'un peintre devrait connaître les diverses nuances de couleur, etc...
Un journaliste devrait savoir se servir de son traitement de texte mais il n'a pas à connaître le fonctionnement d'unicode et autres, parce que la finalité de son boulot c'est le *fond* de l'article, le message (peu importe le messager) à l'inverse du webmaster qui doit se préoccuper des deux.
D'ailleurs j'ignore si les comparaisons sont pertinentes. Un webmaster a ceci de particulier qu'il est à mi-chemin entre l'art et la technique. S'il est important de faire preuve de talent artistique, la connaissance des bases techniques ((X)HTML, structure du web, CSS, voire HTTP et autres) me semble primordiale.
Euh, un graphiste c'est une personne spécialiste en art et technique graphique, pas forcément sur ordinateur.
Si tu considères uniquement ceux qui font du graphisme sur ordinateur, alors est-ce que tu penses vraiment que des graphistes sérieux ignorent les caractéristiques techniques des standards et/ou normes qu'ils utilisent ? Qu'ils ne connaissent pas le fonctionnement du PNG/Jpeg/SVG/... ? La différence entre matriciel et vectoriel ?
Oui, et quand Pierre Jarillon propose de faire quelque chose qui n'est pas du tout une "citation rêveuse", c'est limite si on ne lui ri pas au nez.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Antoine . Évalué à 2.
Si, mais ce sont des notions conceptuelles, cela n'a rien à voir avec le fait d'être capable de dire si un document SVG est valide est pas, ou pire, d'écrire soi-même un document SVG valide à la main.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Nicolas Legrand (site web personnel) . Évalué à 1.
Pour IE le gros problème que je vois surtout, c'est que l'on risque de se coltiner IE6 pendant quelques années (Windows XP étant selon Microsoft le plus grand concurrent de Windows Vista, et je fais confiance aux utilisateurs pour ne pas mettre à jour leurs machines). Alors du coup les belles idées du W3C j'aimerai qu'elles aboutissent, mais c'est dur de les utiliser.
Une exemple un peu différent est E4X (http://www.ecma-international.org/publications/standards/Ecm(...)
Quand on lit comment ça marche on a franchement envie de n'utiliser plus que ça à la place de DOM dans ses javascripts. Mais bon...
D'autant plus dur que contrairement à ce que tu as l'air de croire, ce n'est pas temps les éditeurs à qui il faudra apprendre à faire des programmes qui suivent les standards que les utilisateurs. Forcer les gens à utiliser une technologie plutôt qu'une autre, parce que « c'est la bonne et je détiens la vérité », malheureusement, je trouve que ça ne marche pas.
Pour le Web 2.0, ce buzzword ne veut pas dire standard, un excellent exemple est google, qui est très Web 2.0 et ne passe aucun validateur. Mais... Ça marche dans un maximum de logiciels...
Cependant j'ai assez bonne espoir, parce que en effet, ça pousse vers les standards et que je pousse _aussi_ dans ce sens. Le truc c'est que le temps de mise en conformité est long, et c'est difficile de faire table rase du passé.
[^] # Re: IE, HTML à la papa et XHTML
Posté par gnujsa . Évalué à 2.
Euh... ?
Jette un coup d'oeil dans le code source des pages de google, ça serait plutôt du html 2.0 que du web 2.0 :)
[^] # Re: IE, HTML à la papa et XHTML
Posté par Mildred (site web personnel) . Évalué à 2.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Nicolas Legrand (site web personnel) . Évalué à 1.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Éric (site web personnel) . Évalué à 5.
En XHTML les seules balises autofermantes acceptées sont celles qui étaient déclarées comme EMPTY dans la DTD. La balise script n'en fait pas partie.
Bref, IE se vautre mais c'est quand même de ta faute ;)
[^] # Re: IE, HTML à la papa et XHTML
Posté par Mathieu Pillard (site web personnel) . Évalué à 7.
Le XHTML 1.1 de Skyblog n'est pas valide techniquement parlant, puisque pas envoyé avec le bon mimetype. Cela étant dit, je bosse la-bas et on est au courant, on peut simplement pas modifier toutes les pages existantes comme ça. Le choix de 1.1 et non 1.0 (compatible html, lui) a été fait historiquement parce-que les développeurs essayaient de bien faire sans forcement être au courant de toutes les implications.
Pour en revenir a IE, c'est plein de bidouilles continuelles pour le gérer, y compris avec du bete XHTML sans CSS. (*) L'envoi dans un mime type non XML, en fait partie, d'ailleurs...
(*) C'est le seul navigateur que je connaisse ou un <meta charset=...> peut provoquer une page completement blanche dans certains cas, quand même :-)
# IE ou l'avenir d'XHTML ?
Posté par krazykitty . Évalué à 3.
Sinon, toujours intéressant de voir que dès qu'on parle de navigateurs, ça lance une bonne vieille discussion des familles sur IE.
Je dis pas que ça soit pas lié, mais le sujet ici c'est quand même l'avenir d'XHTML : continuer à développer XHTML2 sert-il à autre chose qu'apaiser le W3C, et va-t-on enfin arriver à quelque chose avec xHTML (noter la minuscule) ?
Enfin, il me semble. (Mais bon, couper les cheveux en quatre est un passe-temps chez moi apparemment).
# présenter un code diffèrent suivant l'agent web
Posté par Madon Alex . Évalué à 1.
présenter un code diffèrent si l'agent est IE.
Si l'agent et IE alors le serveur web envoie une version HTML4
Si l'agent est autre chose, alors le serveur envoie une (vraie) version XHTML.
La duplication du code est assez limitée est et concentrée sur le header HTTP et le tag head du code HTML.
[^] # Re: présenter un code diffèrent suivant l'agent web
Posté par Pierre Jarillon (site web personnel) . Évalué à 5.
Si on est obligé de faire une page spéciale IE, une annonce : "votre navigateur n'est pas correct, utilisez-en un meilleur" est une mesure de salubrité publique.
Pour ma part, j'ai fait des pages explicatives sur http://pjarillon.free.fr/conforme.html et sur http://chateausaintjean.com/conforme.html
[^] # Re: présenter un code diffèrent suivant l'agent web
Posté par Mildred (site web personnel) . Évalué à 3.
Ou alors ce n'est pas du HTML que tu envoies à IE, c'est de la soupe de balises.
Note que pour convertir du xhtml en html, il y a un outil qui le fait très bien : tidy¹. J'utilise :
tidy -ashtml -utf8 -indent -quiet -xml xhtml_file > html_file
Au passage, je créer un fichier *.var² ³ qui permet à Apache de savoir que la version xhtml est préférable à la version html, et apache se charge tout seul de donner le bon fichier au bon browser.
Mais cela ne fonctionne que pour les pages statiques.
Et periodiquement, je lance un make⁴ sur /var/www ... ou j'utilise l'outil jam⁵ avec des scripts appropriés⁶ ⁷, plus adapté il me semble, et tout est fait automatiquement.
¹ http://www.w3.org/People/Raggett/tidy/
² http://httpd.apache.org/docs/2.0/content-negotiation.html
³ http://mildred632.free.fr/createvarfile.sh
⁴ http://mildred632.free.fr/Makefile et les Makefiles des sous-dossiers
⁵ http://www.freetype.org/jam/
⁶ http://mildred632.free.fr/Jamfile et les Jamfiles des sous dossiers
⁷ http://mildred632.free.fr/Jamrules
[^] # Re: présenter un code diffèrent suivant l'agent web
Posté par Madon Alex . Évalué à 2.
Je ne connais pas de tags existant dans XHTML et HTML4 et hors du "head" que tu ne puisses servir "a la" XML.
Les classiques br, hr, img, li peuvent tous être fermés dans HTML4. Peux-tu préciser les tags qui ne marcheraient pas?
C'est du moins ce que je fais sur http://atpic.com
Les deux versions passent sur Ok sur le w3c validator.
Tu peux forcer la version HTML sans passer par IE en mettant a zero la variable xhtml:
http://atpic.com/index.php?xhtml=0
donne du HTML4
http://atpic.com/index.php?xhtml=1
donne du XHTML
Si la variable n'a pas de valeur alors la valeur est définie par l'agent.
Cela me semble marcher pas mal.
[^] # Re: présenter un code diffèrent suivant l'agent web
Posté par Juke (site web personnel) . Évalué à 1.
(c'est une vraie question pas une critique)
[^] # Re: présenter un code diffèrent suivant l'agent web
Posté par Madon Alex . Évalué à 3.
C'est vrai que sur la page de garde j'aurais pu mettre des div mais pour le moment je considère les 4 photos au hasard comme une table de 1 ligne pour 4 colonnes.
Pour les pages des galeries, j'utilise aussi par défaut des tables ou les nombres de lignes et de colonnes sont des paramètres définis par l'utilisateur, mais des blocs de code (X)HTML sont disponibles par l'intermédiaire des gabarits (templates) te permettant de faire pratiquement ce que tu veux.
Ainsi l'utilisateur qui préfère présenter ses photos dans des div peut créer un template en utilisant la variable
[atpicvar_gallery_thumbnails_div]
au lieu de la variable par defaut:
[atpicvar_gallery_thumbnails_table]
et ensuite faire un style CSS a son goût. Le contrôle du HTML sur atpic est décrit dans
http://faq.atpic.com/
et
http://faq.atpic.com/skin_doc.php
[^] # Re: présenter un code diffèrent suivant l'agent web
Posté par Mildred (site web personnel) . Évalué à 2.
(j'ai rajouté quelques espaces ...)
[^] # Re: présenter un code diffèrent suivant l'agent web
Posté par Madon Alex . Évalué à 1.
Mon but est juste de présenter du XHTML1.1 et d'éviter que le pauvres surfeurs qui sont sous IE ne puissent pas du tout voir mon site. J'ai donc une approche plutôt pragmatique: il se trouve que comme indiqué dans http://www.cs.tut.fi/~jkorpela/html/empty.html, si tu présentes un document comme
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
(et non
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN" "http://www.w3.org/TR/html4/strict.dtd">
)
alors
1) les browsers communs vont présenter <br/> comme sous XHTML
2) la page va être validée OK par le w3c validator
Donc mon but est atteint. même si la version HTML est peut être de la "soupe"... après tout ceux utilisant IE pour surfer méritent bien une bonne mauvaise soupe ;)
[^] # Re: présenter un code diffèrent suivant l'agent web
Posté par XHTML/CSS inside (site web personnel) . Évalué à 3.
$mystring = $_SERVER["HTTP_ACCEPT"];
$findme = "application/xhtml+xml";
$pos = strpos($mystring, $findme);
if ($pos === false) {
header("Content-type: text/html; charset=iso-8859-15");
} else {
header("Content-type: application/xhtml+xml; charset=iso-8859-15");
}
// le même code XHTML peut faire les deux !
Reste que ce genre de truc est tout à fait possible sur un site perso dont on a la maîtrise complète, mais même si je serais le premier à vouloir la conformité absolue sur tous les sites, je me vois vraiment PAS utiliser une techno aussi stricte ça sur des sites en prod en l'état actuel des choses.
La raison en est simple : je me vois mal expliquer à mes clients ou aux visiteurs de mes sites qu'ils ne peuvent pas afficher une page :
- parce qu'un gusse non-initié (genre mon boss quand il veut modifier une ligne sur le site de la boite) a foutu du code non valide sur une page
- ou quand je récupère une database hyper lourdingue qui a été faite avec les pieds (on fait au mieux, mais je n'ai pas toujours la possibilité point de vue temps de rectifier à la pogne 3000 enregistrements parce que le bobet précédent qui a créé le site se prenait pour un développeur web mais n'avait aucune notion d'encodage)
- ou parce qu'il n'ont pas le bon navigateur
Pour cela, il y a un excellent article sur openweb : http://openweb.eu.org/articles/conformite_validation_surqual(...)
qui risque d'énerver les ayatollahs des standards.
Non, je pense déjà qu'on est dans une bonne voie : les sites sont déjà un peu moins fouillis (XHTML/CSS a quand même eu la réussite de taper sur l'épaule de bon nombre de développeurs en leur disant "fini le tag soup essayez de mettre un peu d'ordre là-dedans"), les gens commencent à comprendre que les standards "ç'ai bien", les navigateurs mieux que IE commencent à se faire connaître (ex le succès de Firefox) bref, ça évolue.
[^] # Re: présenter un code diffèrent suivant l'agent web
Posté par Madon Alex . Évalué à 0.
# Paternité ?
Posté par lolop (site web personnel) . Évalué à 3.
Cela dit, sans retirer l'apport de TBL, qui a su simplifier l'usine à gaz de SGML pour en faire quelque chose où le commun des mortels a pu apporter sa contribution à la toile et rendre le contenu accessible.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Paternité ?
Posté par Juke (site web personnel) . Évalué à 1.
[^] # Re: Paternité ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
[^] # Re: Paternité ?
Posté par Sylvain Sauvage . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.