Pour toute norme, il y a des implémentations plus ou moins heureuses. J'ai de plus en plus l'impression que Microsoft est un champion toutes catégories des implémentations foireuses, qui obligent les développeurs à introduire des cas spécifiques pour contourner les erreurs de cet éditeur.
J'ai recensé quelques-unes de ces bourdes :
- Internet Explorer 6, et son interprétation toute particulière des CSS ;
- l'incapacité d'Internet Explorer (toutes versions), incapable de lire le XHTML (déclaré comme tel, application/xhtml+xml) ;
- Internet Explorer et sa prise en charge anormale du HTTPS (on peut voire un kludge dans les configurations habituelles d'Apache HTTPD) ;
- le codage Windows 1252 souvent utilisé en lieu et place de Latin 1 ;
- la vérification de serveur d'expédition de courrier Sender-ID, qui reprend les informations de la norme SPF de façon incompatible et ambigüe ;
- tout récemment, l'implémentation du format OpenDocument par la suite Microsoft Office.
Il y en a sans doute d'autres : si tu en connais, n'hésite pas à les indiquer en commentaire, pour que nous nous réconfortions en nous plaignant ensemble.
# Vive l'ACPI! \o/
Posté par Melkor73 . Évalué à 9.
On peut aussi rappeler une machine virtuelle Java un peu bancale sur ses 3 pattes...
[^] # Re: Vive l'ACPI! \o/
Posté par Melkor73 . Évalué à 6.
[^] # Re: Vive l'ACPI! \o/
Posté par Bobyl . Évalué à 10.
[^] # Re: Vive l'ACPI! \o/
Posté par Melkor73 . Évalué à 1.
[^] # Re: Vive l'ACPI! \o/
Posté par Elfir3 . Évalué à 10.
=>[]
[^] # Re: Vive l'ACPI! \o/
Posté par zebra3 . Évalué à 3.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Vive l'ACPI! \o/
Posté par ナイコ (site web personnel) . Évalué à 1.
Il les collectionne. Vivants.
# Commentaire à caractère informatif
Posté par littlebreizhman . Évalué à 10.
[^] # Re: Commentaire à caractère informatif
Posté par Marc Quinton . Évalué à 3.
[^] # Re: Commentaire à caractère informatif
Posté par Gniarf . Évalué à 5.
kludge c'est vraiment du bricolage, une solution de porcasse, un truc horrible, c'est pire que faire tenir un assemblage avec des bouts de ficelle dans l'idée (car ca, ca marche assez bien), c'est chewing-gum scotch papier maché et compagnie. ça tiendra 5 minutes, pas plus.
# O_o
Posté par Axel . Évalué à 10.
En gros tu nous dis que certains logiciels de Microsoft sont buggués ? C'est une grande nouvelle, c'est bien la première fois que j'entends parler de logiciels qui ne sont pas parfaits !
Merci d'avoir partagé ton scoop avec les dlfpiens.
[^] # Re: O_o
Posté par B16F4RV4RD1N . Évalué à 7.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: O_o
Posté par claudex . Évalué à 9.
... pour que nous nous réconfortions en nous plaignant ensemble.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: O_o
Posté par Axel . Évalué à -4.
[^] # Re: O_o
Posté par claudex . Évalué à 3.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: O_o
Posté par Axel . Évalué à -2.
[^] # Re: O_o
Posté par Octabrain . Évalué à 6.
[^] # Re: O_o
Posté par claudex . Évalué à 5.
Mais alors ce commentaire ne serait-il pas là pour m'occuper aussi?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: O_o
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
[^] # Re: O_o
Posté par Axel . Évalué à -10.
[^] # Re: O_o
Posté par LeJulien . Évalué à 4.
Tu t'es exprimé en disant pourquoi ce journal ne changera pas ta vie, c'est très bien. Mais à force de répétitions ça devient vite lourd.
Merci pour ce journal Ortolo. Il n'est pas inutile de synthétiser ce que l'on a observer à droite et à gauche au fil des années. Et puis... ça donnera des billes à la jeune moule fraichement Linuxienne qui passe dans le coins.
[^] # Re: O_o
Posté par BAud (site web personnel) . Évalué à 6.
c'est Juste Tanguy son prénom, c'est juste ?
# Un peu naïf ...
Posté par Francois G. (site web personnel) . Évalué à 10.
Embrace,_extend_and_extinguish
Cette entreprise met en avant l'outil (le logiciel) avant les standards.
Sa force de frappe commerciale fait le reste.
Cela ne se voyait pas trop lorsque chaque ordinateur était dans son coin.
On a commencé à bien le voir au début des réseaux.
Maintenant que tous les ordinateurs sont connectés entre eux, ça pique vraiment les yeux.
Rien de neuf sous le soleil.
Si tu veux respecter les standards, tu sais ce qu'il ne faut pas prendre (non pas que tous les autres soient parfaits).
# pf... les amateurs de l'informatique libre!
Posté par LeJulien . Évalué à 8.
Que ça plaise aux hippies de l'informatique ou pas, nous et nos clients appelons ça "standards". Si nous sommes premier c'est pas pour rien. Et puisque vous êtes inférieur, vous n'avez qu'a vous adapter.
[^] # Re: pf... les amateurs de l'informatique libre!
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -4.
[^] # Re: pf... les amateurs de l'informatique libre!
Posté par LeJulien . Évalué à 4.
À cette heure des enfants sont devant le web. Merci d'arrêter de faire de la pub pour tes groupes de rock et ta nouvelle marque de drogue.
Mais que fait le CSA?
# Un joli amas de conneries
Posté par pasBill pasGates . Évalué à -5.
On le sait tous, Mozilla a l'epoque de la sortie d'IE6 (2001) respectait CSS parfaitement lui n'est ce pas ? Ah tiens, meme pas.
l'incapacité d'Internet Explorer (toutes versions), incapable de lire le XHTML (déclaré comme tel, application/xhtml+xml) ;
Super, c'est une obligation maintenant de supporter tous les standards existants ?
le codage Windows 1252 souvent utilisé en lieu et place de Latin 1
Windows 1252 est standardise : http://www.iana.org/assignments/charset-reg/windows-1252
Tu te plains des standards aussi maintenant ?
Internet Explorer et sa prise en charge anormale du HTTPS (on peut voire un kludge dans les configurations habituelles d'Apache HTTPD) ;
Bug qui a ete corrige il y a un bon moment deja, mais c'est tellement plus simple de ne pas reflechir et copier aveuglement ce qu'on voit sur le web...
la vérification de serveur d'expédition de courrier Sender-ID, qui reprend les informations de la norme SPF de façon incompatible et ambigüe ;
Sender ID est un standard experimental au meme titre que SPF, partant de la, qui te dit que c'est pas SPF qui est incompatible avec Sender ID ?
tout récemment, l'implémentation du format OpenDocument par la suite Microsoft Office.
L'implementation est totalement conforme, que votre standard cheri ODF soit rempli de problemes n'est pas la faute de MS.
Bref, un bel amas d'idioties que dont n'as visiblement jamais cherche a comprendre les fondements.
[^] # Re: Un joli amas de conneries
Posté par Bigon . Évalué à 1.
[^] # Re: Un joli amas de conneries
Posté par pasBill pasGates . Évalué à 5.
Le compilo n'est pas bugge, il n'est juste pas aussi bon a noter les erreurs que celui d'Intel. La cause des bugs c'est les OEMs qui ont des DSDT bugges comme la page le dit clairement :
As a result, many OEMs write buggy DSDTs, and it turns out that Windows is very forgiving of bugs in the DSDT that get by Microsoft's compiler (not surprisingly).
[^] # Re: Un joli amas de conneries
Posté par claudex . Évalué à 4.
Non, mais les standards utilisés pour écrire des pages web, ça peut être utile pour un navigateur Internet. On ne parle pas non plus des standards du réseau électrique Luxembourgeois.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Un joli amas de conneries
Posté par Jerome Herman . Évalué à 3.
Quitte à me faire moinsser violamment, il y a beaucoup plus de gens qui utilisent les standards electriques luxembourgeois que de page XHTML+XML déclarée comme telle et valides de surcroit.
XHTML est une belle plantade en matière de norme, 70% du web est encore en HTML 4 quand au xhtml déclaré proprement avec version xml et encoding il fait figure d'ovni.
Un exemple au hasard le site lin***r.org, qu'on ne peut pas vraiment taxer d'être pro-microsoft est encore en XHTM 1.0 transitional, avance dans ses meta qu'elle est text/html. (Plus le fait qu'une déclaration de la version xml en en tete aurait pu être mise en place)
XHTML 1.0 strict, conforme et avec la version et l'encoding des caractères c'est plus rare que le routage IPV6 en interlan... A partir de là je comprend totalement que MS se focalise sur autre chose en attendant que HTML5 ne sorte (Là les gens qui surveillent un peu le truc et qui ne sont pas Glazman devraient éclater de rire)
(N.B : comme je suis un gentil garcon je ne parle pas de XHTML 1.1)
[^] # Re: Un joli amas de conneries
Posté par claudex . Évalué à 3.
Et si le navigateur majoritaire ne supporte par XHTML, c'est normale que les site web ne soit pas écrit avec. Sinon une majorité des gens ne pourrais pas l'utiliser
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Un joli amas de conneries
Posté par pasBill pasGates . Évalué à -3.
[^] # Re: Un joli amas de conneries
Posté par briaeros007 . Évalué à 3.
[^] # Re: Un joli amas de conneries
Posté par Yvan Joffre . Évalué à 6.
[^] # Re: Un joli amas de conneries
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Un joli amas de conneries
Posté par windu.2b . Évalué à 10.
1 http://fr.wikipedia.org/wiki/Internet_Explorer#Versions
[^] # Re: Un joli amas de conneries
Posté par Gniarf . Évalué à 5.
[^] # Re: Un joli amas de conneries
Posté par grid . Évalué à 3.
[^] # Re: Un joli amas de conneries
Posté par Adrien . Évalué à 5.
Bah justement regarde le nombre de site qui utilisent le XHTML mais le présente comme du text/html à cause de IE…
[^] # Re: Un joli amas de conneries
Posté par pasBill pasGates . Évalué à -2.
[^] # Re: Un joli amas de conneries
Posté par Jerome Herman . Évalué à 1.
Et qui oublient la déclaration XML à cause de IE.
Et qui ne passent pas la validation W3C à cause de IE
Et qui utilise le naming space HTML 4 à cause de IE
et qui sont moches, lent et mal codés à cause de IE
Bon sans rire, même Nitot et Glazman n'utilisent pas les fonctionnalités XML du XHTML, et je ne pense pas que ce soit par peur de perdre des visiteurs.
XHTML+XML 1.0 strict
a) ne sert à rien en l'état
b) n'est pas complètement compatible IE.
Je pense que le a) est la raison principale pour laquelle le standard ne prend pas (opinion personelle bien sur)
[^] # Re: Un joli amas de conneries
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
pardon? à l'heure ou SVG, SMIL, MATHML et cie commencent à être utilisé, le XHTML ne sert à rien ?
Ce serait bien de pouvoir faire ce genre de chose http://people.mozilla.com/~prouget/demos/round/index.xhtml dans tout les navigateurs...
>même Nitot et Glazman n'utilisent pas les fonctionnalités XML du XHTML
Tristan c'est normal : il ne développe pas. M'enfin, c'est quand même lui qui a poussé XHTML et les standards avec l'aide de 10 autres gus (dont moi), via le site openweb.eu.org, il y a 6 ans.
Quant à Daniel Glazman, si il pouvait utiliser XHTML plus souvent (pour intégrer du SVG et cie), il le ferait hein. surtout dans son editeur BlueGriffon (note: j'ai bossé 4 ans et demi avec lui)
Mais voilà, il y a cette grosse MERDASSE de IE, qui ne connait pas XHTML, (et encore moins SVG...), et qui empeche donc toute innovation sur les sites web (sauf à se couper de 60/70% des internautes)
[^] # Re: Un joli amas de conneries
Posté par Jerome Herman . Évalué à 4.
SVG : ne nécessite pas XHTML, marche bien (voire mieux) en utilisant des plugins.
SMIL : On va rester poli : la norme ne bouge pas depuis 2008, on ne sait toujours rien de ce qu'on peut ou ne peut pas mettre dedans et les espaces de nommages sont (une fois encore) en vrac.
MathML : La norme actuelle date de 2001, le plugin mathplayer fait souvent un bon boulot et dans 99% des cas il faut se coltiner d'installer des polices spéciales (plus le fait que l'interêt est quand même réduit au niveau de la population).
<i>Mais voilà, il y a cette grosse MERDASSE de IE, qui ne connait pas XHTML </i>
IE connait parfaitement le XHTML/XML, le connait depuis 1999 (depuis les premiers drafts), le connaissait avant Netscape. IE ne support pas deux choses :
a) que la feuille soit déclarée autrement qu'en text/html ou en text/xml avec un déclaration complète de la DTD dans le corps du message. Certes c'est hors norme pour XHTML1.1 (mais autorisé pour 1.0), mais très honnêtement vu les montagnes de javascript qui ont été écrites pour la compatibilité CSS je ne pense pas que le fait de devoir déclarer une page en text/html au lieu de test/xml ait été le frein majeur de cette techno.
b) IE passe en mode debug (donc est plus lent/moins optimisé et affiche certains artefacts) si on surdéclare l'encoding dans la déclaration XML. Compte tenu du fait que cette surdéclaration n'est ni obligatoire, ni prépondérante (quoi qu'il arrive le body prend la main) il suffit de ne pas déclarer pour avoir un comportement standard. Une fois de plus je ne vois vraiment pas de frein majeur.
>>et qui empeche donc toute innovation sur les sites web (sauf à se couper de 60/70% des internautes)
Outre le fait que si tu ne veux pas te couper de 60 à 70% des utilisateurs ET faire du XHTML il te suffit de faire un réglage enfantin dans ton serveur web - je ne vosi pas trop ce que tu peux faire "d'innovant" avec XHTML et que IE bloque. CSS3 n'est pas encore supporté par quoique ce soit de mainstream. Ajax+middleware fait très facilement toute les transformations dynamiques de pages.
Alors oui IE a fait chier la terre entière avec son interpretation très particulière (et souvent fausse) des CSS, mais en ce qui concerne XHTML je ne vois vraiment pas de quoi il est coupable. Ou sont les milliers de webmaster (professionnels s'entend) qui auraient aimé faire du XHTML 1.0 mais qui se sont restreints car ils ne supportaient pas de devoir déclarer leur mime-type en text/html ? Ou sont les feuilles XSLT qui justifient l'emploi du mime type application* ? Et surtout ou est la norme de gestion des formulaires qu'on nous promet depuis 10 ans ?
Honnêtement pour les webmasters qui en ont rien à battre de MathML (et ils sont nombreux) ca apporte quoi au juste de tangible comme avantage d'écrire <br /> au lieu de <br> ?
[^] # Re: Un joli amas de conneries
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Oui mais non. Il l'accepte quand on le déclare comme du HTML, ce qui :
- est anormal (c'est du XHTML, pas du HTML !) ;
- empêche d'utiliser certaines possibilités du XHTML (des <script /> plutôt que <script></script>) ;
- empêche d'avoir un vrai DOM XML sur les pages ainsi servies.
[^] # Re: Un joli amas de conneries
Posté par Jerome Herman . Évalué à 2.
Une fois de plus la norme permet tout à fait de déclarer XHTML 1.0 comme text/html, ce qui est parfaitement normal vu que XTHML 1.0 n'est pas une nouvelle norme mais juste la formalisation en XML de la norme HTML.
empêche d'utiliser certaines possibilités du XHTML (des <script /> plutôt que <script> </script>)
Jamais vu de </script> dans la norme... Et je vois pas trop l'intérêt non plus.
empêche d'avoir un vrai DOM XML sur les pages ainsi servies.
GNI ? C'est pas parce que le mime type est fixé sur text/html que ca gène en quoi que ce soit le parcours ou l'édition du DOM. Si on était en XHTML1.1 modulaire, ou si on disposait dans la norme de méthodes pour ajouter/supprimer, réordonner, éclater des tags ca serait un peut gruik d'utiliser un mime text* pour un document qui serait effectivement une application.
Sauf que
- C'est toujours le bazar dans les espaces de nommage
- Les hiérarchies sont inaccessibles depuis le document lui même (tout à été reporté dans les CSS)
- On a toujours pas de normes XForms (donc bon chance pour faire de la mise en page interactive directement depuis les document, une fois de plus c'est CSS qui s'y colle)
Dans les faits je ne vois toujours pas ce que l'on perd en XHTML 1.0 sous IE par rapport au XHTML 1.0 sous mozilla. Y a-t-il une chose intéressante pour un webmaster qui soit possible sous mozilla et pas sous IE ? Quelqu'un a-t-il un exemple concret ?
[^] # Re: Un joli amas de conneries
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Je parle de <script/>, pas de </script>. :-)
Intérêt ? Éviter une absurdité du genre : <script src="pouet.js"></script>, qu'on remplace alors par une auto-fermante : <script src="pouet.js"/>.
GNI ? C'est pas parce que le mime type est fixé sur text/html que ca gène en quoi que ce soit le parcours ou l'édition du DOM.
Tu as essayé ? Moi, oui. J'avais un site servi en application/xhtml+xml pour tout le monde, sauf bien sûr pour Explorer, pour lequel je déclarais du text/html. Je voulais, depuis une page, en télécharger une autre (avec XmlHttpRequest) pour l'anayser. Et bien, l'analyse marchait partout, sauf dans Explorer, tout simplement parce que du text/html, ben ce n'est pas du XML.
[^] # Re: Un joli amas de conneries
Posté par Jerome Herman . Évalué à 2.
Tu mets donc une balise à contenu (fut-il distant) en auto-fermant... Bien bien bien...
Tu m'aurais dit une balise link vers un script pourquoi pas (même si la norme ne le permet pas à l'heure actuelle). Mais du container, donc rentrant dans le DOM, en auto-fermant ca me fait un peu peur. Pourquoi pas <p /> quand on veut créer un paragraphe vide tant qu'on y est ?
Tu as essayé ? Moi, oui. J'avais un site servi en application/xhtml+xml pour tout le monde, sauf bien sûr pour Explorer, pour lequel je déclarais du text/html. Je voulais, depuis une page, en télécharger une autre (avec XmlHttpRequest) pour l'anayser. Et bien, l'analyse marchait partout, sauf dans Explorer, tout simplement parce que du text/html, ben ce n'est pas du XML.
Je te rassure tout de suite, on est beaucoup à avoir essayé et à y être arrivé. D'ailleurs l'imense majorité des framework AJAX utilise ces techniques.
- Soit en désérialisant à la mano avec les API propriétaires Mozilla qui se vautre lamentablement sur le parsage DOM natif : https://developer.mozilla.org/en/Parsing_and_serializing_XML
- Soit en utilisant les activeX ou les fonctions body.appendchild et body.removechild sous IE http://dean.edwards.name/weblog/2006/04/easy-xml/
Sous IE on peut aussi servir la page en tant que text/xml et définir correctement et complètement la DTD. Ca marche aussi très bien depuis IE6...
[^] # Re: Un joli amas de conneries
Posté par e-t172 (site web personnel) . Évalué à 4.
Tu m'aurais dit une balise link vers un script pourquoi pas (même si la norme ne le permet pas à l'heure actuelle). Mais du container, donc rentrant dans le DOM, en auto-fermant ca me fait un peu peur. Pourquoi pas <p /> quand on veut créer un paragraphe vide tant qu'on y est ?"
Où est le problème ? En XML <blabla></blabla> veut dire EXACTEMENT la même chose que <blabla />. C'est IDENTIQUE. <br /> c'est pareil que <br></br>. <p /> c'est pareil que <p></p>.
http://www.w3.org/TR/2008/REC-xml-20081126/#d0e2433
"[Definition: An element with no content is said to be empty.] The representation of an empty element is either a start-tag immediately followed by an end-tag, or an empty-element tag."
"Empty-element tags may be used for any element which has no content, whether or not it is declared using the keyword EMPTY."
(la phrase qui suit "for interoperability" concerne la compatibilité avec SGML, autant dire qu'on s'en fout complètement aujourd'hui)
[^] # Re: Un joli amas de conneries
Posté par Jerome Herman . Évalué à 2.
Relis mieux la norme XHTML (pas seulement la version W3C de la norme XML 1.0) tu verras qu'un élément déclaré en balise auto-fermante est un élément vide terminal, ce qui veut dire qu'il ne peut pas avoir de fils.
Une fois de plus je ne vois pas l'interet d'un script vide de contenu...
[^] # Re: Un joli amas de conneries
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: Un joli amas de conneries
Posté par Jerome Herman . Évalué à 2.
Je me rends compte que je ne dois pas parler francais, ou alors que je suis devenu complètement névrosé. Il n'y a donc que moi que ca choque de déclarer en même temps qu'un élement est vide ET qu'il a des fils (même si c'est dans une source distante).
Si ton script a une source, laquelle source dans le DOM va venir enrichir le document de fils pour ton tag script. Comment peux-tu le déclarer comme élément vide ?
Maintenant c'est peut être juste moi...
[^] # Re: Un joli amas de conneries
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
Un element script qui indique un fichier js par un attribut src, ne va pas du tout enrichir ton DOM.
<script src="truc.js"></script>
<script></script>
et
<script src="truc.js" />
sont strictement équivalent d'un point de vue DOM. Le fait d'avoir un attribut src ne rajoute nullement un quelconque noeud DOM en tant que fils de l'element DOM script (ça n'aurait aucun sens tant d'un point de vue SGML que XML). Un attribut n'est pas un noeud DOM fils sur un noeud element.
Et le problème donc, c'est que pour IE, avoir la balise script auto fermante est invalide. Alors qu'en XML (donc XHTML), c'est tout à fait valide. Et c'est invalide pour IE parce qu'il utilise un espèce de parser tout pourri qui est à moitié SGML, à moitié XML....
[^] # Re: Un joli amas de conneries
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Ça fait franchement extra-terrestre… :-)
[^] # Re: Un joli amas de conneries
Posté par e-t172 (site web personnel) . Évalué à 2.
Je viens de relire la norme XHTML et la seule chose qui ressemble à ce que tu dis c'est ça :
"Given an empty instance of an element whose content model is not EMPTY (for example, an empty title or paragraph) do not use the minimized form (e.g. use <p> </p> and not <p />)."
Là où le bât blesse, c'est que ce paragraphe est dans la section "HTML compatibility guidelines", qui est informative et non-normative. Raté, essaie encore.
[^] # Re: Un joli amas de conneries
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Tu utilises souvent des <img></img> ?
[^] # Re: Un joli amas de conneries
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
c'est du vent toutes ces specs ? http://www.w3.org/MarkUp/Forms/#documents
>Dans les faits je ne vois toujours pas ce que l'on perd en XHTML 1.0 sous IE par rapport au XHTML 1.0 sous mozilla.
Bah c'est simple, avec Mozilla :
- on peut intégrer dans un même document XHTML du SVG, MATHML, XFORMS, et bientôt du SMIL.
- ne necessite pas 4 plugins pour afficher tout ces types de langages
- les bouts de SVG, MATHML, XForms et cie peuvent être manipulés directement par du javascript, ce qui autorise une très grande souplesse (alors que via les plugins, c'est quasiement impossible, sauf peut être avec celui de XForms pour IE je crois), des pages bien plus dynamiques et fonctionnelles..
Note: l'implémentation de XForms dans Mozilla est disponible via une extension, mais pas par un plugin. La difference est de taille. Cette extension etend le DOM et le parser de Gecko (via la technologie XTF de Gecko), ce qui fait que l'on a pas à faire appel à une balise object (donc à un plugin). On a donc une interpretation "native" de xforms, ave un vrai DOM derrière.
[^] # Re: Un joli amas de conneries
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Non, il ne le connait pas du tout. Il utilise un parser SGML plutot que XML pour parser une page XHTML.
La preuve est cette abération qu'il ne sait pas ce qu'est une balise autofermante.
[^] # Re: Un joli amas de conneries
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
Nous y voilà, faut un plugin. N'importe quoi. Alors que dans tout les autres navigateurs, ça fonctionne direct dans du XHTML.
Et le problème des plugins :
- tu n'as pas accés à un vrai DOM pour manipuler le SVG
- tu ne peux pas mettre autre chose que du SVG dans le SVG. impossible d'utiliser foreignObject par exemple. Du coup, on ne peut pas par exemple inclure une belle formule en MATHML dans un dessin SVG.
- et je ne parle pas de l'accessibilité totalement néante via le plugin SVG
> SMIL : On va rester poli : la norme ne bouge pas depuis 2008, on ne sait toujours rien de ce qu'on peut ou ne peut pas mettre dedans et les espaces de nommages sont (une fois encore) en vrac.
Euh.. relis la spec ?
> MathML : La norme actuelle date de 2001
Ta phrase laisse supposé que ça ne bouge pas, alors que la spec MATHML a évolué, avec une version 3 en préparation.
> le plugin mathplayer fait souvent un bon boulot et dans 99% des cas il faut se coltiner d'installer des polices spéciales (plus le fait que l'interêt est quand même réduit au niveau de la population).
Le problème des polices, c'est la faute droits de propriétés sur ces polices, très restrictives (et souvent payante).
M'enfin, je dirais là encore: encore un plugin ! Super... Et là encore, ça apporte tout les inconvenients
- pas d'accés au DOM
- c'est lourd puisqu'il faut un plugin
- autant de fichier que de formule mathématique
Bref, c'est totalement nul, alors que Mozilla permet d'utiliser le MathML depuis des lustres au sein même du XHTML, ce qui fait des documents plus legers et plus flexibles.
[^] # Re: Un joli amas de conneries
Posté par Jerome Herman . Évalué à 2.
Le navigateur IE 6 ne supporte pas une surdéclaration de l'encoding dans le XML et nécessite un hack dans le serveur pour le mime type quand le xml est mal déclaré. On est très loin des problèmes rencontrés avec les CSS qui ont pourtant fini par devenir la norme.
De plus le problème du mime type est résolu dans IE 7 et 8.
Bref XHTML+XML ne marche pas principalement parceque très peu de gens y voit un intéret. De plus la norme w3c est banquale, notamment sur le espaces de nommage (et c'est pas XHTML 2.0 qui va sauver la donne : http://lists.w3.org/Archives/Public/www-archive/2009May/0029 )
[^] # Re: Un joli amas de conneries
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Le future, c'est XHTML 5, le pendant XML de HTML 5 (XHTML5 et HTML5, c'est la même spécification, y a juste la différence syntaxique XML entre les deux)
[^] # Re: Un joli amas de conneries
Posté par suJeSelS . Évalué à 4.
[^] # Re: Un joli amas de conneries
Posté par TImaniac (site web personnel) . Évalué à -1.
[^] # Re: Un joli amas de conneries
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
[^] # Re: Un joli amas de conneries
Posté par Jerome Herman . Évalué à 0.
Petite correction : toute les version d'internet explorer depuis le 6 (le 5.5 si on compte les version drafts de XHTML) accèptent très bien le XHTML 1.0.
Il suffit de palcer le mime type à text/html ce qui est parfaitement admis par la norme.
[^] # Re: Un joli amas de conneries
Posté par thedude . Évalué à 1.
Question subsidiaire: ca apporterais quoi a l'application, ce XHTML strict?
A part un logo a la con et des linuxfriens au kiki tout dur a la vue d'une page declaree en text/xml ou je sais pas quoi?
Parce que pour autant que je sache, html 4.01 est toujours pas deprecie.
Donc le standard est toujours respecte.
En fait a part de grosses emmerdes de validite de document xml qui commence a etre assez couillu a maintenir vu comment les pages sont generees, je vois vraiment pas ce que ca apporte pour la grande majorite des sites de faire du xhtml 1.1 strict.
Ca veut pas dire que c'est malin de la part d'IE de montrer le document en plain text, mais faut pas pousser meme dans les orties et imputer a IE la secheresse de 2003 non plus (ou la non adoption d'une techno inutile)
[^] # Re: Un joli amas de conneries
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
[^] # Re: Un joli amas de conneries
Posté par thedude . Évalué à -3.
Plus rapide a parser dis tu. Super, tu vas gagner un pouillieme de milliseconde au parsing et continuer a passer un temps fou au rendu.
Et encore dans le meilleur des cas, parce que mon petit doigt me dit que tu vas toujours tomber sur une page mal formee par ci par la qui va te forcer a repasser en mode pas propre.
Et donc le cote strict, c'est plus des emmerdes qu'autre chose.
'fin bon, l'avis sur les technos web d'un mec qui conseillait des bonne vieilles frames html bien pourries ya pas 2 mois, excuses moi...
[^] # Re: Un joli amas de conneries
Posté par windu.2b . Évalué à 4.
Parce que le côté "code dégueu", c'est quoi, selon toi ?
Quand le code HTML est dégueu, le navigateur doit deviner ce que le développeur a cherché à faire. Le résultat est donc hasardeux (parce qu'on ne peut pas coder en dur toutes les gruikeries possibles).
Alors qu'un code XHTML est forcément syntaxiquement propre, sinon le parseur XML t'enverra bouler...
Après, il reste toujours le problème de la mauvaise utilisation des balises : mettre un "span" + du CSS au lieu d'un "h[1-6]" est syntaxiquementcorrect mais sémantiquement dégueu !
[^] # Re: Un joli amas de conneries
Posté par e-t172 (site web personnel) . Évalué à 5.
"un code XHTML est forcément syntaxiquement propre, sinon le parseur XML t'enverra bouler..."
->
"un code HTML est forcément syntaxiquement propre, sinon le parseur SGML t'enverra bouler..."
(ce qui en pratique ne se produit jamais, mais c'est un choix des navigateurs d'être tolérant, ça n'a rien à voir avec la norme elle-même)
Tu peux très bien avoir du XHTML syntaxiquement dégueu comme du HTML syntaxiquement dégueu. Dans le premier cas il ne passera pas un parser XML strict, dans le second cas il ne passera pas un parser SGML strict.
[^] # Re: Un joli amas de conneries
Posté par windu.2b . Évalué à 4.
Alors que, pour des raisons de compatibilités, les parseurs HTML doivent l'être !
Donc passer à du XHTML aurait le mérite de remettre tout ça à plat, c'est pas forcément négligeable
[^] # Re: Un joli amas de conneries
Posté par suJeSelS . Évalué à 3.
[^] # Re: Un joli amas de conneries
Posté par e-t172 (site web personnel) . Évalué à 2.
[^] # Re: Un joli amas de conneries
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
Faire donc des pages bien plus fun, en limitant l'utilisation de techno comme flash &co...
Et si SVG et SMIL n'ont pas le succés que l'on aimerais, c'est bien parce que c'est impossible de les utiliser dans le navigateur le plus utilisé. Parce que c'est pas implémenté, mais aussi parce que même XHTML n'est pas reconnu.
XHTML serait tellement plus pratique et plus puissant à utiliser si IE le supportait...
[^] # Re: Un joli amas de conneries
Posté par thedude . Évalué à 1.
Si SVG n'a aucun succes, c'est parce qu'il n'a aucun tool d'edition, principalement.
C'est une techno ultra aride (comprendre par la que meme pour un developpeur, ca pique les yeux) dediee a des non geeks (designers/artistes).
Et t'espere que ca va prendre?
Il a bon dos IE serieux...
Meme firefox a mit des annees a implemanter svg, venez pas faire porter le chapeau a MS s'il vous plait!!!
Quand a SMIL, c'est pareil la bonne blague. Ca fait 10 ans que c'est la, et pourtant flash arrive a etre plus populaire.
Meme le w3c l'admet plus ou moins en introduisant la balise video...
Mais bon, c'est si pratique de faire porter le chapeau a IE, ca rassure son ego, on est pas oblige d'admettre que personne n'est interesse par ces technos du w3c, et donc on est pas oblige de remettre en cause ses convictions.
[^] # Re: Un joli amas de conneries
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Hein ? Inkscape, non ?
[^] # Re: Un joli amas de conneries
Posté par thedude . Évalué à 1.
Sous macos, plateforme de choix pour les designers, il tourne sous x11 qui est un enfer pour l'integration au systeme et rebute meme les plus agueris.
Et par dessus le marche, il supporte que les images fixes, pas les animations.
wouhou.
Flash et flex peuvent aller se rhabiller, apres tout ils ont quoi eux?
Juste un des ide les plus populaires du moment pour le dev, un outil d'authoring plus que bien gaule (avec l'integration avec la suite d'un des leaders de la creation graphique) qui pond des binaires qui tourne sur 95% des navigateurs du marche.
[^] # Re: Un joli amas de conneries
Posté par Gniarf . Évalué à 4.
t'étais en taule ces 10 dernières années ?
http://en.wikipedia.org/wiki/Svg#Software_.26_support_in_app(...)
> Sous macos, plateforme de choix pour les designers, il tourne sous x11 qui est un enfer pour l'integration au systeme et rebute meme les plus agueris.
il parait qu'un certain Adobe Illustrator se démerde pas trop mal sous Mac comme sous Windows et est raisonnablement bien intégré à ces systèmes...
> Et par dessus le marche, il supporte que les images fixes, pas les animations.
et il en manque un paquet (au pif, WebDraw de (feu) Jasc (Paint Shop Pro...) qui justement gérait les animations. j'ai la flemme de chercher vraiment, mais les fichiers datent de janvier 2002. pour une version francisée, donc 2001.
> wouhou.
lol. j'ai l'impression que tu ne maitrises pas bien ton sujet.
> Flash et flex peuvent aller se rhabiller, apres tout ils ont quoi eux?
> Juste un des ide les plus populaires du moment pour le dev, un outil d'authoring plus que bien gaule (avec l'integration avec la suite d'un des leaders de la creation graphique) qui pond des binaires qui tourne sur 95% des navigateurs du marche.
bah alors, tu ne savais même pas que Illustrator lisait et pondait du SVG ?
car après tout, ils avaient même écrit un plug-in pour IE pour lire les SVG, justement... ils étaient les champions du SVG jusqu'à ce qu'ils rachètent Macromedia donc Flash...
[^] # Re: Un joli amas de conneries
Posté par thedude . Évalué à 0.
SVG n'a donc jamais decolle a cause d'IE. Itou pour XHTML.
Dont acte.
Tout va bien, madame la marquise.
[^] # Re: Un joli amas de conneries
Posté par Jerome Herman . Évalué à 2.
Sur IE (comme sur à peu près tous les navigateurs en fait) si tu veux un support correct du SVG (ie avec gradient éventuellement multipoint, différents niveaux de transparences, synthèse additive, ICC et autre z axis respecté) tu déclare ton SVG comme un objet que tu ouvres avec le plugin adobe. Toute autre approche donne des résultats "suprenants".
Quand à SMIL il n'a pas de succès parceque la norme se garde bien de prendre partie pour quoi que ce soit, ni des containers, ni des codecs, ni des déclarations DOM (d'ailleurs la page de la norme est un chef d'oeuvre à ce niveau http://www.w3.org/TR/smil-boston-dom/domcore.html ), ni des comportements par défaut (simultanéité, séquentialité, parallelisme). C'est juste une envellope creuse qui donne une façon de lier des médias à d'autres médias et/ou à des séquencement du temps. On a trois évènements : un qui capture les clicks de souris, un qui lance une animation en même temps qu'une autre et un qui lance une animation après une autre. Pour les autres éléments (onpause, on resume, onrepeat) c'est la guerre. On ne sait pas quoi faire avec les descendants; on ne sait pas qui ? quoi ? ou ? doit être affecté ou pas par les évènements etc.
Bref on tiens un flash-killer les gars...
Pour la petite histoire IE 5.5 a été le premier navigateur a avoir un squelette de fonctionnement SMIL. Vu le peu de retour, MS a laissé le moteur dans l'état.
[^] # Re: Un joli amas de conneries
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
http://fr.wikipedia.org/, http://www.ibm.com/, http://www.ubuntu.com/ …
Je continue ?
http://www.lemonde.fr/, http://www.france-info.com, http://www.lefigaro.fr/
D'autres ?
http://www.microsoft.com/
XHTML, OVNI ? J'ai des doutes, là. Bien sûr, tout ça est servi en tant que HTML (text/html), parce que sinon, ce serait inaccessible sous le navigateur à la masse. Mais XHTML est certainement utilisé. Si demain, je veux faire un site Web, j'ai le choix entre HTML 4 et XHTML : franchement, qui hésiterait une seconde ?
[^] # Re: Un joli amas de conneries
Posté par Littleboy . Évalué à 2.
Deja lemonde.fr me sert du HTML 4.01 chez moi (Firefox), ca commence mal...
A part Ubuntu, tous tes exemples sont XHTML 1.0 Transitional.
Donc XHTML 1.0 Transitional ovni, certainement pas, mais Strict et 1.1 oui.
[^] # Re: Un joli amas de conneries
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Ben évidemment, vu que Strict 1.1, ça doit être servi en application/xhtml+xml, et ça, c'est refusé par le sous-navigateur, malheureusement encore très utilisé.
[^] # Re: Un joli amas de conneries
Posté par e-t172 (site web personnel) . Évalué à 3.
Preuves :
- A :
"quand au xhtml déclaré proprement avec version xml et encoding il fait figure d'ovni"
Tu as cité plusieurs sites. Aucun ne déclare proprement "avec version xml et encoding". En effet je ne vois aucun prologue "<?xml version="1.0" charset="utf-8" ?>".
- A :
"Donc XHTML 1.0 Transitional ovni, certainement pas, mais Strict et 1.1 oui."
Tu as répondu :
"Ben évidemment, vu que Strict 1.1, ça doit être servi en application/xhtml+xml".
Il ne parlait pas de "Strict 1.1" mais de XHTML 1.0 Strict et de XHTML 1.1. Tu as sans doute sauté le "et" dans sa phrase. Tu as donc répondu pour XHTML 1.1, maintenant on attend l'argument pour XHTML 1.0 Strict.
Attention, tu as perdu à la troisième petite croix !
[^] # Re: Un joli amas de conneries
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Les standards du Web depuis 8 ans, ouais. Sinon, ça s'appelle être à la rue, tout simplement.
Windows 1252 est standardise : http://www.iana.org/assignments/charset-reg/windows-1252
Oui, il est standardisé. Mais si tu me relis, c'est ça dont je me plains :
Content-Type: text/plain; charset=latin-1
[des trucs en Windows-1252]
Sender ID est un standard experimental au meme titre que SPF, partant de la, qui te dit que c'est pas SPF qui est incompatible avec Sender ID ?
Oui, mais la différence, c'est que Sender ID a plein de problèmes, notamment de propriété intellectuelle, et par conséquence ne pourra jamais passer à l'état de standard. En plus, Sender ID utilise les enregistrements DNS définis pour SPF, de façon incompatible avec ce dernier. Et enfin, il est ambigu sur le domaine à vérifier (MAIL FROM: ou PRA ?), là où SPF est univoque.
[^] # Re: Un joli amas de conneries
Posté par pasBill pasGates . Évalué à 0.
Non ca s'appelle implementer ce qui est vraiment utile simplement, Jerome l'explique tres bien dans son post.
Oui, il est standardisé. Mais si tu me relis, c'est ça dont je me plains :
Content-Type: text/plain; charset=latin-1
[des trucs en Windows-1252]
Super, et qu'est ce que MS a a voir la dedans ? Ils sont responsables de la mauvaise configuration de ton Apache ?
Oui, mais la différence, c'est que Sender ID a plein de problèmes, notamment de propriété intellectuelle, et par conséquence ne pourra jamais passer à l'état de standard. En plus, Sender ID utilise les enregistrements DNS définis pour SPF, de façon incompatible avec ce dernier. Et enfin, il est ambigu sur le domaine à vérifier (MAIL FROM: ou PRA ?), là où SPF est univoque.
Super, marrant que je ne t'ai pas vu dire un mot sur les deficiences enormes d'ODF pourtant, tu nous fais deux poids deux mesures ?
# ODF et wifi
Posté par Renaud Guezennec (site web personnel) . Évalué à 5.
(ça dit, en gros, que ODF Alliance a rédigé un document qui prouver que le support à été écrit avec des pieds.)
D'après les normes Wi-fi 802.11..., le scan actif que fait Windows est considéré comme le niveau 0 d'une attaque. Cette liberté avec la norme explique aussi pourquoi windows trouve plus de réseau Wi-Fi qu'un GNU/Linux (enfin c'était vrai, il y a quelques années, il est probable que les grosses distributions fassent de même maintenant)
Puis, il y a POSIX aussi hihi, (OK je sors.... )
[^] # Re: ODF et wifi
Posté par pasBill pasGates . Évalué à -2.
b) Windows ne fait rien qui ressemble a une attaque avec 802.11
c) POSIX on s'en fout pas mal, Windows n'est pas Unix
[^] # Re: ODF et wifi
Posté par Sébastien B. . Évalué à 7.
[^] # Re: ODF et wifi
Posté par fearan . Évalué à 5.
POSIX : Portable Operating System Interface
C'est sur qu'un standard de portabilité n'est pas la priorité de microsoft, hein, rien à battre de pouvoir compiler son code sur plusieurs plateformes, après tout y'en a qu'une seule de valable. ;)
Alors oui le X connote un héritage UNIX, mais cela ne veux pas dire que tous les systèmes POSIX doivent en découler.
ps: windows nt est compatible POSIX.1 au delà il faut installer 2 trois trucs "Microsoft Windows Services for UNIX" par exemple, ce qui connote quand même autre chose que on s'en fout pas mal, Windows n'est pas Unix, ou plus connu : cygwin
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: ODF et wifi
Posté par pasBill pasGates . Évalué à 0.
Alors oui le X connote un héritage UNIX, mais cela ne veux pas dire que tous les systèmes POSIX doivent en découler.
Non, et ca ne veut pas dire non plus que tous les OS doivent l'implementer, ca va dans les 2 sens.
Quand a la portabilite ca me fait bien rire, vas me faire un soft decent avec une UI qui soit portable en te limitant a POSIX...
[^] # Re: ODF et wifi
Posté par fearan . Évalué à 4.
* POSIX.1, Core Services (incorporates Standard ANSI C) (IEEE Std 1003.1-1988)
o Process Creation and Control
o Signals[6]
o Floating Point Exceptions
o Segmentation Violations
o Illegal Instructions
o Bus Errors
o Timers
o File and Directory Operations
o Pipes
o C Library (Standard C)
o I/O Port Interface and Control
* POSIX.1b, Real-time extensions (IEEE Std 1003.1b-1993)
o Priority Scheduling
o Real-Time Signals
o Clocks and Timers
o Semaphores
o Message Passing
o Shared Memory
o Asynch and Synch I/O
o Memory Locking Interface
* POSIX.1c, Threads extensions (IEEE Std 1003.1c-1995)
o Thread Creation, Control, and Cleanup
o Thread Scheduling
o Thread Synchronization
o Signal Handling
Par contre en UI simple, je donnerai grep couteau suisse indispensable :P
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: ODF et wifi
Posté par pasBill pasGates . Évalué à 1.
Sans parler du fait qu'il n'y a aucune raison de limiter l'architecture d'un OS par les contraintes de POSIX, si l'OS n'est pas un Unix, POSIX est tout simplement facultatif.
[^] # Re: ODF et wifi
Posté par briaeros007 . Évalué à 7.
Posix peut etre facultatif si tu t'en tape de l'interopérabilité et des standards et décide de faire tes trucs dans ton coin.
[^] # Re: ODF et wifi
Posté par beagf (site web personnel) . Évalué à 10.
Tout dépend de ce que tu code et de ce que tu appelle portabilité.
Personnellement je code des programmes de calculs intensifs, des gros truc de bourrins qui travaillent sur de gros volumes de données en parrallèle. Le coeur de mes programmes est parfaitement portable car écrit en C/ANSI. La couche juste au dessus qui gère le parallèlisme est aussi très portable puisqu'elle est en POSIX.
Tu peut prendre à peu près n'importe quel OS POSIX et mes programmes compilent et ce lancent sans modifications. Par contre jamais je n'irais utiliser des serveur de calculs sous windows car impossible de compiler un truc POSIX de base dessus et je serais donc obligé de recoder toute la partie multithread qui est en générale une plaie à débugger.
La couche graphique que l'on peu éventuellement mettre au dessus, je dois avouer que personnellement je m'en bas les roustons. Elle sert juste à créer des fichiers "jobs" et à afficher des fichiers de résultats pour ceux qui n'aiment pas éditer des fichiers textes. Ça peut très bien ce coder en java ou n'importe quel autre truc un peu indépendant de la platforme.
C'est peut-être un cas particulier mais il est quand même répandu et ce n'est pas pour rien que microsoft est à a traine pour tout ce qui est calcul... Personnellement, en général je m'en fous de l'OS sur lequel tourne mes prog de calcul, tout ce que je lui demande c'est d'être compatible POSIX. Le jour ou MS le fera ça ne me genera pas que l'admin installe des serveurs sous windows, en attendant...
[^] # Re: ODF et wifi
Posté par ham . Évalué à 2.
1) Le document de l'ODF alliance dit lui meme que les formule me sont pas specifié, mais que MS n'a fait aucun effort par rapport au suite qui elles ont convergé vers openformula
2) excel detruis des infos.
3) certain point ne sont pas parfaitement correct (change tracking)
4) les plugins pour ODF fais par des societe tierce pour ODF marche mieux que le support natif (qui est seulement pour office 2007)
De ce point de vue la , le support ODF de word 2007 ca resemble plus de la beta pour dire qu'on pourrais le faire que un support d'interoperabilité avec les maximum de produit du marché.
Appeller ce type de support un truc mature et une super feature (surtout comparé a ce que font d'autres) ca sent un peu trop le marketing qui a depassé l'implementation
[^] # Re: ODF et wifi
Posté par pasBill pasGates . Évalué à 8.
2) Il ne detruit rien
3) Super, grande nouvelle : aucune suite n'implemente parfaitement 100% de ODF, pourtant OOo ca fait plus de 5 ans qu'ils bossent dessus hein, et bizarre, personne ne les critique
4) Haha, ils marchent mieux pour quoi ? Pour lire des documents de OOo ? Mais on s'en fout, c'est une implementation de ODF ici, pas de la version OOo d'ODF
De ce point de vue la , le support ODF de word 2007 ca resemble plus de la beta pour dire qu'on pourrais le faire que un support d'interoperabilité avec les maximum de produit du marché.
Vous me faites bien rire, vous vous plaignez de l'existence de standards de fait par rapport a une norme (.doc par rapport a ODF), et ensuite vous insistez pour que MS implemente un standard de fait (la version d'ODF a la sauce OOo).
C'est de l'hypocrisie pure et simple.
[^] # Re: ODF et wifi
Posté par Adrien . Évalué à 5.
C'est de l'hypocrisie pure et simple.
C'est bine le problème, et des deux côtés…
# DOMParser
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 7.
Alors que pour un même document XML, tout les autres navigateurs fournissent quasiement le même arbre DOM
On a trouvé tellement de bug dans leur parser (que ce soit avec IE6/7 ou 8, sur XP ou vista), qu'on a fini par refaire en JS notre propre parser. Quelques centaines de lignes de codes en plus à cause des monstruosités Microsoft. Que de perte de temps, pour un truc qui ne date pas d'hier quand même... Pas merci Microsoft.
[^] # Re: DOMParser
Posté par Jerome Herman . Évalué à 2.
br est le plus casse gueule des éléments (depuis des lustres). One ne sait toujours pas si on doit le considérer comme un contenu brut ou si on doit le considérer comme un bloc. Le W3C n'a pas tranché donc on devrait théoriquement pouvoir lui appliquer des styles et le manipuler via DOM. Tout ceux qui s'y sont essayés se sont pétés la gueule et les transformations/styles sur BR ne sont pris en charge par aucun des navigateurs. De plus BR ne peut pas avoir d'enfants rattachés, pas de contenu et pas d'évennement....
Partant de là IE décide de le considérer non comme un bloc dans un arbre DOM mais comme du contenu pur.
A ce niveau aucune des deux approches ne me parait fausse (br comme noeud ou non), mais personellement je trouve l'approche d'IE plus cohérente. (pourquoi se faire chier à rajouter des noeuds dans l'arbre DOM alors qu'on ne pourra de toute façon rien en faire).
[^] # Re: DOMParser
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
si tu as
<foo>
<bar />
</foo>
Avec IE, le DOMElement foo n'a qu'un fils, un DOMElement bar, alors qu'il devrait en avoir trois: deux DOMText (contenant les sauts de lignes en question) et le DOMElement bar. Et c'est grave, parce que ces caractères blanc peuvent être significatifs selon le langage XML, aussi un parser XML ne devrait pas zapper ces types de noeud textes.
[^] # Re: DOMParser
Posté par Jerome Herman . Évalué à 2.
Mais une fois de plus on est sur un cas problématique : a savoir faut-il considérer les espaces comme du contenu qui doit rentrer dans le DOM ou comme de la mise en page qui n'est là que pour faciliter la lecture.
A noter que Firefox tout seul ne sait pas répondre à la question, le DOM Inspector renverra bar comme premier fils de foo... alors que nextsibling en javascript firefox me renvoit bien le DOMText....
Quand à la norme HTML elle est assez floue sur le sujet sauf dans le cas du PRE. J'ai pas d'ie sous la main là tout de suite pour voir si
<pre>
<img src="pipo.jpg"/>
<pre>
parse correctement. (La norme force la création du DOMText vu qu'elle spécifie que tous les espaces sont significatifs...)
[^] # Re: DOMParser
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Pas du tout ! Ou alors c'est juste une configuration de l'affichage du DOM inspector. Si tu lui demandes de tout afficher, il affichera tout.
> Quand à la norme HTML elle est assez floue sur le sujet sauf dans le cas du PRE.
Certes, mais là on parle de XHTML, donc de la notation XML. La spécification de DOM et XML sont claires là dessus : il DOIT y avoir des noeuds texte, pour TOUT contenu textuel d'un élément, même si il ne s'agit que d'espace et/ou de sauts de ligne.
Le fait de savoir si les espaces sont significatifs, ce n'est pas le problème du parser et du DOM. C'est le moteur de rendu ou le programme qui travaille sur le DOM qui estime si les espaces sont significatifs ou pas. Ce n'est pas au parser de l'estimer. Le parser doit donner un DOM qui représente fidèlement le contenu du fichier texte. Un fichier XML ou SGML n'étant finalement qu'une version "serialisée" d'un DOM.
Bref chacun son rôle.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.