IE7 : En vrac
Lu dans Hello from LA !
sur l’IEBlog :
- Fonction
Quick Tabs
permettant à l’utilisateur de gérer dans une fenêtre les onglets ouverts sous forme de miniatures (j’espère que j’ai à peu près bien traduit) - Nouvelle fonctionnalité de zoom permettant de zoomer aussi bien les textes que les images
- Améliorations sur
Open Search
- Améliorations sur la sécurité, et notamment, désactivation par défaut de la plupart des ActiveX
- Intégration du navigateur avec le système de contrôle parental de Windows Vista
- Modifications sur la gestion de certains éléments de formulaire (les
<select>
ne seront plus récalcitrants à passer derrière un bloc en position absolue) - Du fait de la désactivation des ActiveX, l’objet
XMLHTTPRequest
sera disponible nativement - Support des IDN
- Développement d’une barre de développement web (à l’instar de l’extension
Web Developer
de Firefox) sous forme d’add-on (elle sera apparamment disponible aussi pour IE6)
Nouveau billet publié sur l’IEBlog : Developer Toolbar for IE announced at PDC
Chris Wilson, directeur de l’équipe de développement d’Internet Explorer a publié un
billet complémentaire à propos du bug
concernant le doctype switching
et le passage d’IE6
en mode de compatibilité si le doctype est précédé d’un prologue XML. Ce bug sera corrigé dans la version 7.
Il a également annoncé qu’IE7 ne supporterait pas le type de média
application/xhtml+xml
(traduction approximative) :
Pourquoi n’ajoutons nous pas le support de XHTML servi avec le type de média
application/xhtml+xml
dans IE7 ? J’ai pris la décision de ne pas essayer de supporter (Ndt : Je sais, c’est un anglicisme) ce type de média dans IE7 parce que personnellement, je veux que XHTML soit un succés à long terme. J’aime XHTML (regardez, mon nom est dans la liste des contributeurs à XML 1.0); cela permet une vraie interopérabilité si c’est bien fait.Avec la plupart de nos plateformes de ressources dans IE7, en dehors de la sécurité, utilisées pour améliorer notre support de CSS, si nous essayions de supporter réellement XHTML dans IE7, nous devrions le finir en utilisant notre parseur HTML existant (qui se concentre sur la compatibilité) et hacker les structures XML.
Il est très peu probable que nous puissions supporter XHTML correctement dans ce cas ; En particulier, nous ne devrions certainement pas détecter quelques cas d’erreurs ici et là, et nous devrions supporter silencieusement ces cas invalides. Ceci, bien sùr, causerait des problèmes de compatibilités basés sur le gestionnaire d’erreurs du parseur dans le futur, ce que XML essaye précisément d’éviter ; Nous ne voulons pas causer d’autres problèmes comme avec la gestion actuelle des erreurs HTML (initiée pour la compatibilité avec les précédents navigateurs – vous pouvez me blâmer personnellement pour cela, mais pas IE).
J’aimerais beaucoup plus prendre le temps d’implémenter proprement XHTML après IE7, et avoir quelque chose de vraiment interopérable – mais j’ai voulu débloquer le déploiement de XHTML du mieux que nous puissions, c’est pourquoi nous nous sommes assurés de corriger le bug du prologue XML/DOCTYPE.
Le texte original :
Why aren’t we supporting XHTML when it’s served as the
application/xml+xhtml
media type in IE7? I made the decision to not try to support the MIME type in IE7 simply because I personally want XHTML to be successful in the long run. I love XHTML (go look, my name is in the credits for XML 1.0); it’s capable of being truly interoperable if done right.With most of our platform resources in IE7 outside of security work being spent on improving our CSS support, if we tried to support real XHTML in IE7 we would have ended up using our existing HTML parser (which is focused on compatibility) and hacking in XML constructs.
It is highly unlikely we could support XHTML well in this way; in particular, we would certainly not detect a few error cases here or there, and we would silently support invalid cases. This would, of course, cause compatibility problems based on parser error handling in the future, which XML is explicitly trying to avoid; we don’t want to cause another mess like the one with current HTML error handling (rooted in compatibility with earlier browsers – you can blame me for that personally somewhat, but not IE).
I would much rather take the time to implement XHTML properly after IE7, and have it be truly interoperable – but I did want to unblock deployment of XHTML as best we could, which is why we made sure to address the XML prolog/DOCTYPE issue.