Slashdot Mirror


IE8 Will Be Standards-Compliant By Default

A number of readers wrote in to make sure we know about Microsoft's change of heart regarding IE8. The new version of the dominant browser will render in full standards mode by default. Developers wishing to use quirks mode for IE6- and IE7-compatible rendering will have to opt in explicitly. We've previously discussed IE8's render mode a few times. Perhaps Opera's complaint to the EU or the EU's record antitrust fine had something to do with Redmond's about-face.

9 of 383 comments (clear)

  1. Re:Huge assumption in the title by Your.Master · · Score: 5, Insightful

    Compliance to standards is a relative term. No browser exists today that is completely compliant. What we can say is that this one appears to be more compliant than before -- it renders ACID2 at the very least (and probably does right everything IE7 did right).

  2. Re:I don't care about IE at all by 99BottlesOfBeerInMyF · · Score: 5, Informative

    What other browser does significantly better overall at standards compliance than Firefox?

    Well, since the link you provide is largely question marks for the Webkit based browsers, that's hard to say. Also, the comparison you link to is missing a lot of standards where Firefox is a bit behind. These include:

    • Javascript - Safari, Opera, and Konquerer all have at least some support for Javascript DOM 3, which Firefox lacks in the released versions so far.
    • image formats - Konquerer supports MNG, Tiff, and PDF. Safari supports JPEG 2000, Tiff, and PDF. I know of no standard image formats Firefox supports not supported by both of those (yet).
    • XHTML 1.1 lists Firefox at 63% and question marks for Safari and Konquerer, but wikipedia currently lists both of those as having "full support" and Firefox as "partial."
    • Web Forms 2.0 - Opera supports, Firefox doesn't
    • Voice XML - Opera supports, Firefox doesn't
    • WML - Opera supports, Firefox doesn't

    That is not to say Firefox is necessarily behind other browser for standards compliance in general. No one with a clue would cite the Acid tests as proof of anything in that regard, but it does indicate that the link you provide is not particularly strong evidence one way or another. The whole question is probably too vague to be answered. There are a lot of Web standards and what really matters is which ones are most universally supported and what functionality cannot be used because of lacking support in one browser or another.

    In summary, I reject your assertion, not because I'm convinced you're wrong, but because you haven't provided enough evidence to support it and there is significant contradictory evidence (cited above).

  3. Re:Huge assumption in the title by Anonymous Coward · · Score: 5, Insightful

    > Compliance to standards is a relative term.

    No, this statement is incorrect.

    > No browser exists today that is completely compliant.

    That is true. But it has no connection with the last statement.

    I understand your point, and it's well taken, but you are introducing a tautology. Standards compliance is absolute, by _definition_.
    Some attempts to comply with written standards may fail, and as such are not compliant. It may well be true that no browsers exist that are standards compliant, as the standards are written. However, please don't go waving around poisonous ideas like "standards compliance is a relative term".
    Americans seem to have adopted a very lax relativism of late, a kind of fuzzy belief that everything is subjective. Some things are not. Some things are just facts that must be heeded. The definition is not up for negotiation, that's what _makes_ it a standard.

  4. It's a trap! by tobiasly · · Score: 5, Funny

    It's a trap! First Microsoft lures us all into using interoperable web standards, and then... then.... shit, I can't figure out how they can use this for evil. Gimme a sec...

  5. Improved standards isn't the story here by trepan · · Score: 5, Informative

    The real story here is that "Developers wishing to use quirks mode for IE6- and IE7-compatible rendering will have to opt in explicitly."

    If you've been following any of the design / developer blogs and community response about this, you'll know that in a previous plan, all web pages would render in IE7 standards mode unless the developer inserted a specific meta tag

    <meta http-equiv="X-UA-Compatible" content="IE=8" />
    into each web page of a site. (For the truly avant garde, one could set the content to "edge", which would tell IE to render in the most current standards compliant version available). The outcry was that while it was clear that IE was making progress in standards, in order to take advantage of those improvements, developers were being asked to touch each page of their sites and tell IE to use its more standards compliant mode. That discussion is what was at play here.
  6. Re:Huge assumption in the title by cp.tar · · Score: 5, Insightful

    More standard than IE7 isn't really a high bar to aim for though.

    It is much higher than "more standard than IE6".

    --
    Ignore this signature. By order.
  7. Re:Huge assumption in the title by DanielJosphXhan · · Score: 5, Funny

    So what you're saying is that by IE15 we should see a fully standard-compliant browser?

    Microsoft has the be the only organisation on earth *slower* that the W3C. I mean, it's not exactly a moving target.

    --
    [ think ]
  8. Re:Huge assumption in the title by Random+BedHead+Ed · · Score: 5, Funny

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119

    For those too busy to consult RFC 2119 in detail, it basically states the following:

    • Should should mean "should."
    • Must must mean "must."
    • Must not must not mean anything other than "must not."
    • Required is required if you want to express the idea of a requirement.
    • Shall shall mean "shall."
    • Shall not shall not be construed as indicating that something "shall." (In fact it shall be the opposite.)
    • Should should usually mean "should," but not always.
    • Should not should not mean anything other than the opposite of "should," but also not always.
    • Recommend is recommended for use in RFCs as well, but may be optional.