Summary: InternetExplorerStandardsSupport for Cascading Style Sheets

The CSS (Cascading Style Sheets) standard: http://www.w3.org/Style/CSS/

CSS1 and CSS2.1 bugs in MSIE 6 with/without reduced demo case

'''Several hundreds of CSS testcases by Ian 'Hixie' Hickson. This testsuite has to be the most complete, thorough testsuite for modern browsers ''' Microsoft will for sure find well over 300 CSS bugs in that testsuite.

* Draft CSS 2 Test Suite at http://www.meyerweb.com/eric/css/tests/css2/index.html and the results for MSIE 6 at http://www.designdetector.com/articles/results.html

* Current CSS 2.1 Test suite at W3C (last updated on August 4th 2007) MSIE 7 fails 25.8% of the tests while others (Firefox 2, Opera 9, Safari 3) all fail under 10% of the tests.

* Peter-Paul Koch bug report56windows/index.html has over 122 bugs so far with many CSS bugs !

* G. Talbot MSIE 6 bugs has over 70 CSS bugs with testcases

* G. Talbot MSIE 7 bugs has well over 60 CSS bugs so far with testcases

* Position is everything bug list

* Hixie's CSS bugs with testcases has well over 100 bugs with links to these testcase at the bottom of the page http://ln.hixie.ch/?start=1051031464&count=1

* The box of a dimensioned element should not expand to accomodate content (i.e. the text should properly "spill" out of the box containing it). MSIE 6 does not support correctly overflow: visible. Reduced testcase showing the bug and another testcase here 1.Fixed Longitudinal Dimensions where the most inner inside thick green-bordered div with class=tall should be sticking out of the middle outer thick green-bordered div with class=short

* percentage width value on absolutely positioned elements should calculate the %tage of the containing block, not %tage of the immediate parent node of the abs. pos. elements. Safari 1.x and Mozilla-based browsers supports this correctly; MSIE 6 does not, even in standards compliant rendering mode. IE6 calculates the percentage with respect to the width of the .
This is an important bug to fix as it makes designing scalable (synonyms: fluid, liquid) multi-column webpage design a lot more difficult. Fixing this bug should be a top priority. Many web developers personally told me this bug is impossible to workaround without resorting to table-design.

Reference: "A positioned element should be positioned to the nearest containing positioned element, not the containing element." http://www.opera.com/docs/specs/opera6/#css
Reference: "The containing block for a positioned box is established by the nearest positioned ancestor (or, if none exists, the initial containing block)" CSS 2.1, Section 9 Visual formatting model section, 9.8.4 Absolute positioning#q28
Reference: "If there is no such ancestor, the containing block is the initial containing block. (...) If we position 'div1': its containing block is no longer 'body'; it becomes the initial containing block (since there are no other positioned ancestor boxes)." CSS 2.1, Section 10.1 Definition of 'containing block'#containing-block-details
Reference: "Note: For absolutely positioned elements whose containing block is based on a block-level element, the percentage is calculated with respect to the width of the padding box of that element. This is a change from CSS1, where the percentage width was always calculated with respect to the content box of the parent element." CSS 2.1, Section 10.2 Content width, the 'width' property#the-width-property

3 available testcases showing the problem:
http://www.gtalbot.org/BrowserBugsSection/MSIE6Bugs/WidthPercentageAbsPosElem.html
Mozilla-based browsers (NS 7.x, Mozilla 1.x, Firefox 1.x), Safari 1.2+ and Opera 9 render this testcase accordingly.
http://www.satzansatz.de/cssd/tmp/apboxpercentagewidth.html
http://www.gtalbot.org/BrowserBugsSection/MSIE6Bugs/WidthPercentageAbsPosElem2.html
Mozilla-based browsers render this testcase accordingly --DU/GT

* Support of comma as separator in clip: rect(valOffsetTop, valOffsetRight, valOffsetBottom, valOffsetLeft)

Reference: "Authors should separate offset values with commas. User agents *must support* separation with commas, (...)." http://www.w3.org/TR/CSS21/visufx.html#clipping

* Column Inheritance: Table cells set to "background:inherit" fail to inherit from column styles.

* Incorrect CSS parsing error handling: Parsing color: rgb(real, int, int) is wrong. Reduced testcase showing the bug and another reduced tescase showing the bug

Reference: "illegal values, or values with illegal parts, are treated as if the declaration weren't there at all" CSS1 Forward compatibility#forward-compatible-parsing

Reference: "The format of an RGB value in the functional notation is 'rgb(' followed by a comma-separated list of three numerical values (either three integer values or three percentage values) followed by ')'." CSS 2.1, Section 4.3.6 Colors#value-def-color

Reference: "An <integer> consists of one or more digits "0" to "9". A <number> can either be an <integer>, or it can be zero or more digits followed by a dot (.) followed by one or more digits." CSS 2.1, Section 4.3.1 Integers and real numbers#q15

* Incorrect CSS parsing error handling: Parsing cursor syntax errors; cursor: url(foo.cur) without keyword should not be rendered.
E.g. SelectorElement {cursor: url(foo.cur);} should not be rendered because a keyword cursor is missing, therefore the whole declaration should be ignored.
E.g. SelectorElement {cursor: url(foo.cur), pointer, url(bar.cur), auto;} should not be rendered because the proper W3C CSS2.1 syntax is not applied, therefore the whole declaration should be ignored.

Reduced testcase showing the bug

Reference: The correct syntax is [<uri> ,]* [ auto crosshair default pointer move e-resize ne-resize nw-resize n-resize se-resize sw-resize s-resize w-resize text wait help | inherit CSS 2.1, Section 18.1 the cursor property#propdef-cursor

Reference: "user agents must ignore part of an illegal style sheet. This specification defines ignore to mean that the user agent parses the illegal part (in order to find its beginning and end), but otherwise acts as if it had not been there." CSS 2.1, Section 4.2 Rules for handling parsing errors#parsing-errors

* CSS1 padding-top is ignored in nested box. Reduced testcase coming from webstandards.org archives! and another reduced testcase herenestedboxespaddingtopmargin_top.html This bug has been discovered and reported since 1997!

* Width of a table in border-collapse: collapse model must include half (and only half) of the table border

Reduced testcase showing the bug

Reference: CSS2.1, Section 17.6.2 The collapsing border model#collapsing-borders clearly states that "in this border-collapse: collapse model, the width of the table includes half the table border." and it should include only half of the table border.

* Lack of support for CSS 1 background-attachment: fixed on elements other than 'body'

WHY: it would enable effects like this: http://www.meyerweb.com/eric/css/edge/ (for starters)

* Incorrect support for CSS 1 pseudo-elements :first-line and :first-letter as shown in this 1998 demo page coming from archives of webstandards.org

* Percentage of padding is not correct Reduced testcase showing the bug
This is a CSS1 bug and Netscape 6.x, Netscape 7.x, Firefox 1.x, Safari 1.2, Opera 7, Amaya 9.2.1 all render that testcase correctly.

* CSS 1 Border-color inheritance is not correct Reduced testcase showing the bug

Reference: CSS 1, Section 5.5.16#border-color says: "If no color value for the border is specified, the value of the 'color' property of the element itself will take its place."

* CSS 2.1 Padding on @<col>@, @<colgroup>@, @<thead>@, @<tfoot>@, @<tr>@, @<tbody>@ must be ignored. Reduced testcase showing the bug
Reference: 'padding-top', 'padding-right', 'padding-bottom', 'padding-left', 'padding' "Applies to: all elements except elements with table display types other than table, inline-table, and table-cell" CSS 2.1, Section 8.4 Padding#padding-properties
Reference: "The five properties related to padding ('padding', 'padding-top', 'padding-right', 'padding-bottom', and 'padding-left') now say that they don't apply to table rows, row groups, header groups, footer groups, columns, and column groups." CSS 2.1, Section C.3.10#q36

* Wrong z-index implementations
Excellent article and demos showing clearly and convincingly the z-index bugs by Aleksandar Vacić

Reference: "Each box belongs to one stacking context. Each box in a given stacking context has an integer stack level, which is its position on the z-axis relative to other boxes in the same stacking context. Boxes with greater stack levels are always formatted in front of boxes with lower stack levels. Boxes may have negative stack levels. Boxes with the same stack level in a stacking context are stacked bottom-to-top according to document tree order." CSS 2.1, Section 9.9.1#x36 --DU/GT

---

CSS Compatibility

Just do a Google search for browser CSS compatibility chartCSSCompatibility+Chart -- Shining Arcanine

* mezzlobue.com has a list of IE CSS deficiencies
* westciv.commaster/academy/browsersupport/index.html has a chart showing IE's deficiencies (and those of other browsers)
* positioniseverything.net has a list of CSS bugs. In particular:
* bug list
* IE primer
* Guillotine bug working with a:hover style -- Xas
* quirkmodes.org has a good CSS page
* dean.edwards.name has a list of fixes, most of which have to be in IE. --julik
* Acid2 Test - pass this test and you should not get many complaints about CSS support. Safari is the most compliant browser at the moment. See Surfin' Safari (Dave Hyatt's web log) for progress --sbc

CSS Capabilities

Here is a small demonstration of what CSS can do -- DalanGalma
* check out this in Firefox
* and this in IE vs Firefox
* XRay demo (does not work in IE). No JavaScript is used for this. Found on this MozillaZine Forums Thread --sbc

Built-in CSS parsing error reporting in IE 7

There are now several browsers which report CSS parsing errors: Amaya 9.2.1, Firefox 1.5+, Seamonkey 1.x, Icab 3, Opera 9.x and possibly a few others. Considering that CSS parsing errors have definitely more impact on the layout of webpages, it certainly is becoming more suitable and desirable to have an UI in IE 7 to report such parsing errors. It could be turn off by default so that ordinary users would not be annoyed by this.
On the other hand, such feature should be definitely turn on and clearly visible, viewable, accessible and persistent in products like Front Page. --DU/GT

---

Specific Requests

* text-shadow
WHY: it's pretty. I've had designers come up with designs for email campaigns using drop-shadows on the headline. I've been able to get away with using text-shadow on an h1 tag, but only because the designers use Safari! Everyone that gets the email, of course, uses IE to render the HTML, so they don't see the drop shadow... (Maurits)

In order of importance (my opinion only)

* The various bugs detailed here: http://www.positioniseverything.net/explorer.html

WHY: most of the glitches detailed at that URL involve layout/positioning bugs which increase the time to develop CSS-based layouts and the complexity of the code required to do so; CSS-based layout is desirable for reducing bandwidth usage, better accessiblity, easeir machine readability, more flexible page behavior and faster redesigns

* Lack of support for position: fixed

WHY: It would enable authors both to position elements relative to the viewport rather than relative to the document edges (particularly useful in developing application UI-style pages) and to make elements (such as navigation menus) remain in a consistent position WRT the viewport regardless of how the page is scrolled without resorting to unweildy JavaScript hacks; relying on JavaScript for elements that remain in a consistent position is also undesirable because it mixes formatting with behavior, making maintenance more difficult and increasing development time

* Collapsing adjoining margins ( CSS 1, Section 4.1.1 Vertical formating#vertical-formatting and CSS 2.1, Section 8.3.1#collapsing-margins ) is entirely broken

WHY: this absence of support lead web authors to search, to create and to use all kinds of non-compliant workarounds, ugly fixes, invalid code, dirty hacks regarding MSIE 5.x, MSIE 6 and MSIE 7 ... and they did this during years with newbies copying their column templates (or via looking at their webpage source code) without even understanding their hacks on top of that.

Reduced testcase #1 showing failure to support collapsing adjoining margins
Reduced testcase #2 showing failure to support collapsing adjoining margins
Reduced testcase #3 showing failure to support collapsing adjoining margins
Another testcase #4 showing failure to support collapsing adjoining margins

The bugs related to MSIE 6 and MSIE 7 failures to support accordingly collapsing adjoining margins have been explained, detailed and demonstrated numerous times in many websites:

Margin collapsing bug demonstrated_margins/ by Micah Sittig

Margin collapsing bug: The hasLayout MS-property affects the collapsing of margins between a box and its descendants#uncollapse by Ingo Chao

Other convincing demos on margin collapsing bug for nested elements by Bruno Fassino

Reference: "The top margin of an in-flow block-level element is adjoining to its first in-flow block-level child's top margin if the element has no top border, no top padding, and the child has no clearance." CSS 2.1, Section 8.3.1#what-is-adjoining --DU/GT

* Text in absolutely positioned blocks should be easily and precisely selectable by users with mouse or with keyboard

WHY: Many multi-column design rely on (and must use/declare) abs. pos. @<div>@s. Other W3C web standards compliant browsers do not have this problem: an user can select text easily and precisely - with mouse or with keyboard - in abs. pos. elements. This problem has become an important usability burden on top of bugs related to absolutely positioned block-level elements. --DU/GT

Reduced testcase convincingly showing the bug

* Left: auto offset miscalculation bug

Left: auto offset are often miscalculated and this ruins, breaks many layouts.

Reduced testcase #1 showing left: auto offset miscalculation bug
Reduced testcase #2 showing left: auto offset miscalculation bug
Reduced testcase #3 showing left: auto offset miscalculation bug

WHY: This left: auto offset miscalculation bug happens very often in CSS columnar webpages and is encountered very often by web authors. Since by definition, the default, initial value of left is auto, then this makes it even harder for amateur web authors to figure out how to fix or work around this bug. So, they often resort to ugly hacks, poor workarounds, non-forward-compatible hacks.

* Spotty pseudo-class support (i.e., :hover on tags other than 'a')

WHY: pseudo-classes like :hover, :focus, etc. allow authors to define formatting based on element sates, which is necessary for providing feedback to users; again, doing so will eliminate the need for much scripting and help authors separate behavior from formatting resulting in easier maintenance and faster development

* Proper calculation of height for elements with height: auto (the default); currently, the height of elements with height: auto isn't always available to the renderer resulting in buggy rendering, for example when one has a parent element with height: auto and a child element with height: 100%

WHY: It would help in a number of moderately complex formatting tasks where veritcal alignment is required but content length/size is unknown, for example font sizes are notoriously unreliable meaning textual content is, almost by definition, of unknown - and unknowable - size

* Dodgy implementation of absolute positioning from the bottom of an element (i.e., when one uses top: 10px; bottom: 10px; to get an element that stretches from 10px from the top of the containing element - typically the viewport - to 10px from the bottom; IE6/Win doesn't do this right)

WHY: it would assist in the development of fluid layouts that expand/contract in response to the width of the viewport; current techniques for creating these layouts (percentage sizes, typically) often run into difficulty due to the fact that the width property doesn't include margins or (if using the W3C box model, as IE6/Win does in Standards mode) borders or padding; this means that if one wants to use a specified border, margin or padding width (say, 1px or 2em) and wants the element to resize according to the window/page height, very often a dummy 'container' element must be used - if indeed the problem can be solved at all (it can be unsolveable when dealing with height, for example, due to problems recognizing the height of elements with height: auto; see above); proper support of position:absolute would alleviate this difficulty in many areas, again resulting in less markup, smaller file sizes and shorter development times

* Lack of suppport for max-height

WHY: it would be useful in situations where one wants to achieve some sort of vertical alignment on a page with flexibly-sized elements but where there is some absolute upper limit on the desired height of some element (e.g., a height equal to the viewport)

* Form Controls Disregard or Completely Incorrectly render CSS

WHY: Form Controls are a joke, because some of them support CSS, some don't. Checkboxes draw borders and backgrounds not in the control itself, but as if there was a DIV container and the plain white checkbox was inside. Text fields just disregard styles in some cases. This page offers some great examples of IE7 incorrectly rendering the CSS.

* Lack of support for min-/max-width

WHY: these properties are extremely useful for developing flexible-width pages that are nonetheless limited to adjusting within certain ranges to keep the layout from completely falling apart; they can, for example, be used to force a parent element to retain at least a certain minimum width so that floated children remain side-by-side rather than having one drop down below the other on extremely narrow displays (in some cases, horizontal scrolling is preferable to breaking the horizontal flow due to the information being presented), or for ensuring that columns of text do not exceed a comfortable line length

* Lack of support for attribute selectors

WHY: it would eliminate the need to have separate classes for, say, input type='test' and input type='checkbox', resulting in cleaner, more maintainable code, shorter development time and smaller file sizes

* Lack of support for adjacent selectors

WHY: it would eliminate the need to use classes to apply different margins to, for example, the first paragraph after a header (a very common requirement), resulting in cleaner, more maintainable code, shorter development time and smaller file sizes. Another common example is putting a border only between the list items.

* Lack of support for border-spacing

WHY: it would eliminate the need to the presentational cellspacing attribute on tables - again yeilding the benefit of leaner code, easier maintenance/redesigns and shortened development time

* Broken support for table padding

WHAT: applying padding to a table should only apply to the entire table, like borders do. Instead IE applies it to every cell and it cannot be undone by setting the cell padding to zero. Both Mozilla and Opera handle this correctly.

* lack of support for empty-cells

WHY: it would allow more flexibility in the rendering of tables

* Lack of support for the content property (yes, other browsers are spotty here too, but I remember a day when MS was not content to sit at the back of the browser pack...)

WHY: it would enable a whole host of formatting effects: proper counters, proper automatic quotes, easier localisation of quotes (e.g., curly quotes for english, angle brackets for French, etc.) and so on, as well as compact formattin of documents using compact markup like the horizontal rule (hr) tag.

See also the list of bugs at: http://ln.hixie.ch/?start=1051031464&count=1

And the test suites developed by Ian Hickson: http://www.hixie.ch/tests/

Thank you for your attention. -- setmajer

(edited per Dave Massey's request for 'why' in relation to standards requests)

* page-break-inside (in particular, td { page-break-inside: avoid; })

WHY: http://channel9.msdn.com/ShowPost.aspx?PostID=36444 - in brief, because long tables have a nasty habit of breaking words in half across page breaks. Perhaps there's a better solution to this specific problem, but support for this element would go a long way.
-- Maurits

* CSS3 opacity: map, hook "filter: alpha (opacity = )" to CSS 3 Color Module opacity property. This should not be that difficult to implement.

Overall, map or convert already supported features (e.g. like filter: alpha (opacity); filter: drop-shadow, filter: Shadow, filter: MotionBlur) into CSS 2/CSS 3 properties like CSS3 opacity and CSS2/3 text-shadow. That way, MSIE will reduce the need to create or use cross-browser code all the time. -- DU/GT

---

* Lack of support for the child selector

WHY: The child selector helps prevent inheritance in contextual selectors, which is important when the markup may contain nested recurring structures (imagine navigation and content, but inside the content, there may be sub-navigation and content, and so on). -- dnl2ba

* The obscure "hasLayout" property has to be finally replaced with proper positioning model. I want my elements not to haveSomeStrangeLayout, I want them to be floated, positioned and expanded as per spec.

WHY: It should be transparent to the developer (and documented) that if he designs using the W3 specs the rendering engine in IE will use the same rules and will not play on it's own.

* The elements used as clearers should not have content (like non-brekable space) to be rendered properly (in ALL cases).

* Broken positioning of floated and positioned elements

WHY: Positioning and floating are major building blocks of any "liquid" layout. Currently many CSS designers resort to fixed-width layouts instead of 'liquid' only because of the float/box model shortcomings in IE, which creates an obvious screen real-estate waste. Any user feels more comfortable if the site he is viewing can fit his browser window in an optimum way.

* CSS 2.1 visibility: collapse; support (for table rows, table sections, table columns and table colgroups)

WHY: A web designer can dynamically toggle a table row or a column to meet some design requirement. Hidding and collapsing a table row and/or a table column can help presenting information, increase possibilities at the disposal of the user, gives the user more flexibility and this sort of feature is commonly used in database programming. -- DU/GT

* display: inline-table; support

WHY: In order to deliver their visitors a superior internet experience web designers will sometimes need to display inline elements. Supporting the proper declaration in Internet Explorer will save web designers time that would have been spent figuring out how to get IE to display a decent experience while maintaining a superior experience to users of web browsers that support the proper declaration. -- Shining Arcanine

* Properly dotted borders (by dotted I mean 'having dashes and gaps of the square shape'

WHY: Because every other browser displays it this way, and dotted borders are commonly used for decoration (it is very convenient because they don't use any bandwidth except for the CSS definition). Also dotted borders have become a commonplace in link formatting, current IE dotted rendering makes them look quite unpleasant.

* Special attention should be paid to "special cases" - by "special cases" I mean things like negative margins, positioning WITH floating, big border widths WITH floating. Current implementation of IE's CSS is certainly not taking these into account.

WHY: Flexible boxed layout gives the document a better linearisation (the content can be reorganized without depending on the presentation). A linearised document is by orders of magintude more accessible to PDA's, cell phones, screen readers and other "crippled" or even non-visual browsers and user agents.

* Support for table display model for arbitary elements

WHY: Table display model allows to construct columned (and very flexible layouts) withouth surrounding them in table tags. It makes such layouts much more compact because semantically meaningful elements can be used as content areas. This model also solves the "multicolumn stretching" problem of CSS in a couple of statements.

* Links displayed as "block" should have their COMPLETE area reacting to mouse events ( outlined here#clickable )

WHY: Beacuse the link set to display in a special way should offer the clickability on the whole area, making it much more accessible and suitable for creating buttons from links alone.

---

* Incorrect Margin Calculations. Let's say I have a block element with margin-top of 10px applied to it. If the preceding element in the HTML source code is positioned absolutely, no margin will be applied to my element. Rather than looking for the previous element in the normal document flow, IE applies a margin-top of 0. No matter how large the value becomes, IE doesn't even bother to calculate an offset, even from the top of the document. The function called to get the offset just returns 0.

Reference: "This top property specifies how far an absolutely positioned box's top margin edge is offset below the top edge of the box's containing block." CSS 2.1, Section 9.3.2 Top#position-props

Reference: The properties 'top', 'right', 'bottom', and 'left', incorrectly referred to offsets with respect to a box's content edge. The proper edge is the margin edge. Thus, for 'top', the description now reads: "This property specifies how far a box's top margin edge is offset below the top edge of the box's containing block." CSS 2.1, Section C.3.15#q41

---

* Background image options. I know this is a given but spcifically I'd like to say about using the background image fixed and scroll' options. They plainly do not work. We used to create all our pages with fixed backgrounds, thinking that was the best option. When one of our workers switched to linx and used Mozilla the backgrounds of the table cells were screwed and did not scroll wit hthe rest of the page. --SilentKeystroke

---

* Support for dotted borders at 1px. Currently this: "border: 1px dotted #000" produces that same result as this: "border: 1px dashed #000". Dashed borders also get corrupted into solid borders when you scroll the page.

---

* data: URLs. These allow powerful flexibility for all kinds of things, such as embedding bullet images in CSS files.

---

* CSS3 Media Queries. Changing layouts based on (declarative) screen size, color depth, etc. would drastically improve the user experience. See Virtuelvis and Media Queries Candidate Recommendation
* CSS 3 box-sizing, seletable box model
css1 box model is complete useless in real world. try <div style="width: 100%; border: 10px solid black"><div style="width: 100%; border: 10px solid red">a</div></div> in IE6 standard and quirk mode, u can see the quirk mode/border-box is complete win the simplification. i want IE6 standard mode but with border-box model as i can do in mozilla. do it in IE7 please.

* please fix the box model: Windows Explorer vs. the Standards
* selectors: child (tag > tag), adjacent (tag + tag), attribute existence (attribute), attribute value (attribute=value), language (:lang(language-code)), language prefix (lang), and attribute list containment (attribute~=value) are unsupported
* @import: adding the media type after the url confuses WinIE
* dynamic pseudo-classes: :active, :hover, :focus and :target
* support for all display types: list-item, run-in, table-*, marker
* :before, :after and content:
* min-width, max-width, max-height
* position: fixed
* :first-child pseudo-class
* counters
* quotes
* outlines, caption-side, white-space: pre-wrap and pre-line

---

* Proper Support for multiple CSS classes per element.

WHY: Right now, a definition of ".class1.plain" and ".class2.plain" seem to end up combining into a single, global ".plain" class. So both ".class1.plain" and ".class2.plain" will inherit each others settings. :\

-- DrewMarsh

---

General Discussion

I would like to see better CSS support (like many others do as well). At least at the same level as Mozilla. I've heard that it may break some sites - but I think the only way it will do that is by making it look a bit different (non-IE users have had to put up with IE only pages for many years - even then, they display most pages correctly).

---

I know breaking sites was not really a concern as when the Eolas patent was an issue, IE was going to be fixed so that embedded content would display a message box. That would have caused far more problems than fixing CSS - many more pages would likely have problems and more work would need to be done to fix embedded Flash. -- sbc

---

I believe some of the examples are heavily hacked to enable IE to view them properly (thus increasing development time) and if CSS can do that with IE's extremely broken standards support, imagine what it could do if Internet Explorer had full support for CSS Levels 1, 2 and 3. -- Shining Arcanine

---

CSS based layouts are the only proper way to position text, images, etc and make it easy to change the look of an entire website by modifying a single file. They speed up development by making webpages less complex and use uniform code while saving bandwidth that can be put to better use on video, audio and other downloads. They also compress extremely well giving even more bandwidth savings while allowing web developers to deliever superior websites. What does this mean? People on dial up will be able to view higher quality web pages faster. How fast? From my personal experience with dial up and viewers of my website, my website flies loading almost at the instant a link is clicked. Open connections increase server load, CSS based layouts load quickly so connections can be closed quickly, reducing server load allowing a server to serve more pages with the same hardware.

Unfortunately, the lack of standards support makes it impossible for me to innovate in my website's three column design so I am forced to use a simple interface. It also makes me want to pull my hair out. -- Shining Arcanine, http://channel9.msdn.com/ShowPost.aspx?PostID=839

---

Of course the problem of "old" pages comes to mind. There can be two solutions for this.
First, as addressed by Anne van Kesteren , the "standards" mode can triggered by sending the correct XHTML MIME type from the server. The second can be a "meta" tag used in the HTML, for example "useIEstandards" set to "true". The documents not containing this meta tag and/or documents without the correct XML MIME type can be handled in the "oldstyle" mode without breakage. --julik

---

Some doctype trickery is probably a better way to do this than to introduce new meta information for every page that wants to be standards-compliant. Maybe an extension of standards and quirks modes will work here? -- Iain.

---

IE6 already toggles standards vs. quirks box model implementations based on doctype. See here

---

Implementing the child selector would break a number of standards enthusiasts' sites. Many use hacks that rely on browsers mis-parsing or not supporting certain CSS features. It would be ironic if MS didn't implement the child selector in the next rev of MSHTML because it would break standards champions' standards evangelism sites. A more forward-compatible means I've been using is to detect the browser and write details about the rendering engine in the body's class (e.g. class="ua-iewin ua-boxmodel-ieold"). --dnl2ba

---

No, it would just cause IE to use the same set of rules as standards compliant browsers. Nothing should break assuming IE did things in a standards compliant way.

---

I beleive there is a relatively easy path to take, which balances the standards upgrades with the bug-fixes.

E.g. If the voice-family hack is fixed and child-selector implemented, make sure the box-model (and a few other things) work to the standards. With things like that, you can seemlessly upgrade without breaking sites, user expectations or standards. Fix the things that hacks are used to correct!

I'd recommend reading Dave Hyatt's blog, Surfin Safari . He moved from Mozilla to Safari, and kept updates on their progress. I think it's worth noting that it will be a very long process, and is best approached with a table of the standards to tick off (noting which ones others implement already), and it's probably also worth checking Mozilla's bugzilla for discussions on all the issues they came across. --alastairc

---

It is very important to fix CSS/HTML/DOM bugs as they appear, otherwise with time, developers find ugly hacks to work around them and then, much later, Microsoft can not fix these bugs because nobody asks to fix these because fixing these would break their webpages. A very miserable and stupid situation IMO where web design become prisonners of bugs and financially hostages of bugs and incorrect implementations. We eventually all waste/lose time, money, respect, etc. anyway.

Considering the extent of W3C specifications, the number of W3C specifications and the refinements (levels) of W3C specifications, there is no good reason really as to why the MSIE dev. team did not work continuously on improving the browser (spec compliance, spec support and spec implementation correctness) between September 2001 and June 2004. Considering the efforts it takes to develop webpages and considering the difficulties, time, efforts, budget/finances involved to develop and to later update and maintain a website, it is imperative for Microsoft to fix in a timely manner, to correct ASAP, the CSS/HTML/DOM bugs that are known and reproducible. --DU/GT

---

I hope the implementation of !important rules in CSS is fixed because the current implementation is broken. http://www.w3.org/TR/CSS21/cascade.html#important-rules This would mean we could use html/css corectly without breaking the page compatibility with older IE versions. It's what I am using - opera and firefox does interpret these rules - today when making my pages compatible for different browsers. It's allot less cumbersome then working with stylesheet switchers and thus supporting multiple css files -- Glenn De Backer