'width' d'après les spécifications, définit le contenu de la boîte, hors bordure et marge interne (padding) - ce tracé conditionnant les dimensions de tous ses enfants, rendre un truc aussi aléatoire que la largeur d'une barre de défilement partie de la définition du contenu est franchement idiot (c'est le cas de IE).
Pourquoi? Parce que dans un cas où le contenu de la boîte fait effectivement toute la largeur de la boîte (mettons, une image de 750px de large), l'apparition de la scrollbar latérale à l'intérieur de la boîte fait apparaître aussi la scrollbar horizontale! C'est moche, c'est difficile à naviguer, c'est pourrave, ça prend de la place pour rien, et ça demande de compter les pixels d'un élément d'interface utilisateur inaccessible pour un calcul automatique - donc de réserver manuellement de la place pour le cas le plus courant.
Là, le standard prend tout son sens: la taille du contenu de la boîte une fois décidé, y'a plus qu'à s'inquiéter de la place libre dans son conteneur.
Alors, puisque c'est si idiot, pourquoi faire des boîtes de taille fixe?
Simplement parce que IE 6 et inférieurs sont incapables de tracer des boîtes dont on définit les dimensions par rapport à leur conteneur (essayez de tracer une boîte avec top:10px, bottom:10px, left:10px,right:10px, et pleurez), ce qui empêche le tracé de pages à contenu fluide - il faut donc définir des pages à contenu fixe, avec des dimensions définies au pixel près, juste pour que IE les affiche sans faire appel à Javascript dans son CSS.
Et là, IE 7 (qui pourtant comprend enfin correctement le tracé 'fluide' d'éléments de pages) montre vraiment la perversité du mode de calcul d'IE: chaque fois que les barres de défilement doivent apparaître parce que le contenu de la page change (mettons, un élément s'agrandit lorsque survolé par la souris, ou la page est redimensionnée), l'apparition des barres de défilement entraîne une confusion totale de l'affichage.
Prenons le cas de figure d'un conteneur avec overflow:auto, qui contient du contenu varié mais essentiellement fluide (texte et blocs redimensionnables). Si l'un des blocs change de dimension, le texte devrait 'couler' et se repositionner, et si le contenu déborde du conteneur, overflow:auto devrait faire apparaître une barre de défilement latérale (rien ne pousse à l'horizontale puisque le texte s'écoule).
IE 7 aura les réactions suivantes:
- les barres de défilement n'apparaissent pas alors qu'elles le devraient (contenu qui déborde de son conteneur, agit comme overflow:none)
- la barre latérale apparaît, mais calcule mal le contenu (faire défiler la barre la fait sauter et se redimensionner; charge processeur grimpe à toute vitesse, risque de plantage du PC)
- les deux barres apparaissent, alors que l'horizontale n'est pas nécessaire
- le contenu s'affiche normalement avec une seule barre de défilement latérale parce qu'il n'y a plus de contenu redimensionnable hors zone affichée.
Sous Firefox 2, une barre de défilement apparaît sur le côté. Elle peut rester même si elle n'est pas nécessaire par la suite (un élément agrandit rétrécit à nouveau), mais elle disparaît si un autre élément entraîne un 'reflow' de la page.
Opéra 9, Safari et Firefox 3 recalculent le contenu de la page avec fluidité.
Traduction, ici IE est réellement pourrave.
Solution pour le cas de figure présent: utiliser le doctype html 4 Strict ou Xhtml 1.0 strict fait que IE6/7 et firefox calculent la largeur du bloc de la même manière. Pour éviter de s'enquiquiner avec les scrolls, une solution est de définir un conteneur assez large (mettons, 780px), de lui donner à lui l'attribut overflow:auto, et de coller à l'intérieur le div de largeur 750px, sans overflow. A ce moment-là, c'est le div conteneur qui s'occupe de 'scroller' son contenu, lequel fait 750px - point barre.
Auto click