internetexplorerstandardssupport

Cancel
Save
Edit

Internet Explorer Standards Support


Summary: ProductFeedback support for standards in InternetExplorer

* Worried about InternetExplorerSecurity?
* Reporting other InternetExplorerBugs?
* Want to make InternetExplorerFeatureRequests?

Note: Each reference page in the SDK for Internet Explorerreferenceentry.asp has an explicit section for standards. This makes it clear if the attribute, method or element falls within a W3C recommendation or not. So before adding something to this page, check there first...


Acid 2 Test


Please make IE render the Acid 2 Test properly:

http://www.webstandards.org/act/acid2/

--Shining Arcanine


Accessibility Support


The User Agent Accessibility Guidelines , a W3C Recommendation, lists browser requirements for users with a range of disabilities, and users of assistive technology. Members of the User Agent Working Group have done an evaluation of IE 6_id=1 listing in detail what IE has done and needs to do to conform to UAAG.

UAAG conformance is hugely beneficial to Web developers who, instead of having to hack around browser limitations, would be able to do much less work on their end to conform to the W3C Web Content Accessibility Guidelines , and screen readers, magnifiers and other assistive technologies would be able to programmatically access content and user interface to be rendered logically to the user.


CSS Support


See InternetExplorerSupportforCSS


Dean Edwards IE7 behaviors


Many of these issues have been tackled by Dean Edwards in his IE7 collection of behaviours. -- mvuijlst


HTML 4 Support and spec violations


HTML 4 Conformance tests results at http://www.robinlionheart.com/stds/html4/results

W3C DRAFT HTML 4 Test Suite at http://www.w3.org/MarkUp/Test/HTML401/current/tests/index.html

* <iframe> border width implementation bug: There is a bug in the implementation of <iframe border="0" frameborder="0" ..> attributes (without the desired borderless effects). Many wrapper applications using IE5/6 as their underlying browser object do not make such a mistake (e.g., Tencent Traveller).
* proportional/relative column widths#h-11.2.4.4 to specify weighted column width using the <col width="3">, <col width="0"> (minimum), <col width="1*"> syntax.
* buttons: return the value attribute, not the content. At the moment, when the form is submitted by clicking a <button> its content is returned insted of its value. This makes difficult to implement localized versions of web applications, when a button always has a value in english, but its textual content is in the relevant language. W3C spec#initial-value
* options: use the label attribute over the content
* disabled attribute for option
* optgroups: produce submenus, as in MacIE (this makes long lists much more navigable)
* link bar for pages that provide their navigation via link relations, or offer alternate formats or languages (see LinkBars ). Several browsers now support a Site Navigation toolbar and @<link>@. Using @<link>@ for that purpose is a recommended and recommendable web design tip at W3C: Use <link>s in your document
* alternate style selector: Trident can do this already via script, there's just no UI for it! Alternate Stylesheet UI regarding Internet Explorer has been a request from webstandards.org since 1998#AlternatestylesheetUI
* accesskey: it might be worth considering stepping outside of the letter of the spec - the key should probably activate the link rather than simply give it the focus
* <label> associated with contained control (also known as implicit version of label)
* cite attribute for blockquote, q, ins and del elements; for cite attribute of blockquote, add a menuitem in the right-click contextmenu which would make it clickable
* summary attribute for table: it should be accessible via a right-click and properties of the table element. According to WCAG 2, title should not be used For table#title-att and An optional method is to use the title attribute on the table element, but because of the semantics of the attribute.#datatables_summary
* rel, rev, hreflang, charset @<a>@ attributes: useful for internationalization of a webpage
* Support for scrollable tbody (scrollable colgroup would be nice, too)
* object tag: works very differently from the spec, it shouldn't do that in standards mode; particularly nested objects working correctly would be a great help. Right now, the MSIE 6 support for <object> is frustratingly miserable.
* abbr tag: doesn't work. Just make it do exactly what <acronym> does - allow it to be styled with CSS. Currently IE doesn't recognise the tag at all, it's ignored.
* -a cursor based indicator of secure/insecure links and form submissions…- The browser cannot know whether a link points to a secure or insecure resourece before the resource is retrieved. Also, this would be a styling issue, but there is no CSS selector available that can determine whether a page is secure or not (and nor should there be, site security is out of the scope of both the document and stylesheet). (The browser cannot determine that a link or form points to an SSL (HTTPS) resource before retrieving it? How, then, does it know how to retrieve it? -brianiac)
* alt and title attributes: The alt attribute's text is displayed when a mouse over is done to its object/image/<insert name here>. The alt attribute's text should only be displayed when the image is broken (which to my knowldge it isn't) while the title attribute's text should only be displayed when a mouse over is done. The alt attribute should be understood only and exclusively as textual alternate content, textual replacing content, textual rendering equivalent. When one thinks of the alt attribute, one should understand, think of what he would say of an image if he was to describe it on the phone. The title attribute should be understood only and exclusively as advisory information, additional information, complementary information. E.g.<img src="path/url" width="..." height="..." title="My dog's name is Rex" alt="My dog catching a frisbee in the park">
* longdesc attribute: a link should be offered in the contextmenu of an @<img>@ (also @<frame>@ or @<iframe>@); Longdesc Linker for Internet Explorer 6 which adds a 'Long Description' item to the context menu that IE uses for images and Firefox Longdesc extension adds 'View Image Longdesc' to the image context menu . The Longdesc 0.21 extension works perfectly too for Seamonkey 1.x. Icab also supports longdesc attribute and offers a link in the contextmenu. http://trace.wisc.edu/bugzillawcag/showbug.cgi?id=229#c1
* target="blank" : When a hyperlink points to a file download and has target="blank", clicking the link should open a new window and then open the download prompt. Currently IE ignores the existance of target="_blank" (Is this strictly true {or important}? I thought that the download dialog implied _blank. -brianiac)
* target should NOT start with an "_" unless for reserved names, otherwise they should be ignored: http://www.w3.org/TR/html4/types.html#type-frame-target
* Remove support for proprietary elements and attributes such as @<marquee>@, and whatever else you added during the browser wars.
* The default type value of @<button>@ should be submit in IE 6, not "button". Submit is the default value for @<button>@ in HTML 4.01 spec. 'submit: Creates a submit button. This is the default value.'#adef-type-BUTTON
* Support for fixed height on <td> when rowspan attribute is used.rowspanTD+height
* Proper z-level behaviour/hiding for <select> listboxes (currently when a dynamic menu appears over form elements, all form elements apart from <select> listboxes appear behind the menu, but this is broken for <select> listboxes). (Also known as the "form elements over DHTML objects problem"; see also http://www.faqts.com/knowledge_base/view.phtml/aid/2150/fid/178 )
* Pressing the Enter key in a form should submit the form as if by clicking the first button, if one is present (e.g. assume HTML that has: start form, then one text field, then one button, then end form. Pressing enter in the text field will currently submit the form in IE, but it will not 'click the button' - however it will in other browsers such as Firefox); See also http://www.mail-archive.com/jsp-interest@java.sun.com/msg41981.html
* Allow users to override some specific HTML attributes which are known to limit accessibility of content, to restrict accessibility and usability: noresize, target, frameborder, scrolling. UAAG 1.0 on Making Frames accessible is crystal clear on this when it says: In order to ensure that content is accessible, allow the user to override some attributes of the FRAME element of HTML 4 noresize, scrolling, and frameborder.#frame-techniques HTML 4.01, Section 16.3.2 Target semantics says 'User agents may provide users with a mechanism to override the target attribute.'#h-16.3.2 Already Netscape 7+, Mozilla 1.x and Firefox 1.x all allow users to override these specific attributes.



HTML 4.01 Bugs


* In the border-collapse: separate model, a @<col>@'s width is equal to a table's cellspacing + 2 * cellborder width + 2 * cellpadding width + cell content's width in the border-collapse: separate model.

Reduced testcase showing the bug

* A border around an iframe creates unexpectedly, out of nowhere a padding-right and padding-bottom which are twice as large as the border. This is clearly a bug.

Reduced testcase showing the bug

* rules="cols,rows,rowgroups" should only apply when in border-collapse: collapse model. Section 17.6.1 of CSS 2.1#separated-borders says "In this model border-collapse: separate model, (...) Rows, columns, row groups, and column groups cannot have borders (i.e., user agents must ignore the border properties for those elements). Section 17.6.2 of CSS 2.1#collapsing-borders says "(...) In the collapsing border model, it is possible to specify borders that surround all or part of a cell, row, row group, column, and column group. Borders for HTML's 'rules' attribute can be specified this way."

Reduced testcase showing the bug

* Non-defined value of option is not set to the contents of the OPTION element. HTML 4.01, Section 17.6.1 Pre-selected options#adef-value-OPTION spec says that if no value attribute is provided, then the value of an option is its content: "If this (value) attribute is not set, (then) the initial value is set to the contents of the OPTION element."

Reduced testcase showing the bug

* @<hr>@ are block-level elements and not inline elements: that's by definition and given by the HTML 4 specification. But MSIE 6 and MSIE 7 define @<hr>@ as inline elements. This leads to bugs and to major incompatibilities for all web authors.

A testcase querying HR-Element-Reference.currentStyle.display for @<hr>@csscolor_bug.html



HTTP Support


* 205 Reset Content should just clear the form, and not navigate away from the page, for data-entry apps
* 301 Moved Permanently should offer to update the bookmark (or just do it)
* 410 Gone should offer to delete the bookmark
* Link: headers should work just like link tags (for CSS, navigation, alternates, etc.)
* Incomplete support for "Vary" response header (causes content not to be made available to external applications such as Acrobat Reader, see (KB824847
* No standard support for encoding non-ASCII characters in HTTP headers, such as defined in (RFC2231 this makes it impossible to send a Content-Disposition response header for any filename containing non-ASCII characters in a portable way
* RFC2396 (URL) compliance. IE Patch MS03-015 broke compliant treatment of HTTP URLs that contain single quotes (content can not be opened in external applications)
* IE MUST respect the Content-Type header sent in the HTTP Headers, and not incorrectly snifff the file to determine that it is actually something else. eg. When an HTML file is sent as text/plain, IE MUST NOT interpret and render the file as HTML. There are a few websites that this may affect, but the author should fix thos problems anyway. It MAY be an option (check with the relevant standards) to provide the option to the user to override the MIME type, but the SHOULD be accompanied with an appropriate warning.
* RFC2965 (cookie management) compliance. IE6 seems to treat cookies with default domain (cookie domain not explicitly set in the set cookie header) the same way as cookies with a default domain (user agent defaults the cookie domain when it was not set). But it shouldn't. When requesting www.example.com, IE should not select cookies with cookie domain example.com. It is allowed to select cookies with domain .www.example.com, .example.com, www.example.com, but not example.com (notice: no leading dot).


Quirks Mode


If you decide to make the changes which break compatibility (proper XHTML/CSS support) you can use three-level quirks mode.
Of course IE7 should identify in conditional comments and IE7, not IE6 because most hacks are based on conditional comments.
You can also fix CSS parser so it doesn't match on CSS hacks, but these hacks are rarely used.

Level 1. Standards Mode. W3C standards compliant. Triggered when:
*Server sends "application/xhtml+xml" content type
*Server sends "application/xml" or "text/xml" content type
*Server sends "text/html" content type and the page has XML declaration such as <?xml version="1.0" encoding="utf-8"?>

Level 2. IE6 Quirks Mode. IE6 compatibility with all its quirks. Triggered when server sends "text/html" content-type and
*The page is XHTML 1.0 but doesn't have XML declaration
*The page is HTML 4.x Transitional/Frameset with full !DOCTYPE including DTD URL
*The page is HTML 4.x Strict

Level 3. Quirks Mode. Compatibility with older browsers. Triggered when server sends "text/html" content-type and
*The page is HTML 4.x Transitional/Frameset and !DOCTYPE doesn't have DTD URL
*The page is HTML 3.2, 3.0 or 2.0
*The page is HTML 1.x or version not present
*The page doesn't have !DOCTYPE

It offers about 99% compatibility because some webmasters are adding XML declarations for quirky pages.
If you really want 100% compatibility you can enable Standards Mode only for "application/xhtmlxml" content type and IE6 Quirks Mode or Quirks Mode for other HTML/XML content types. It allows 100% compatibility because quirky browsers including IE6 don't support "application/xhtmlxml" content type. --mkol


RFC 2397 data: URLs ( HTML )


The data: URL scheme allows powerful flexibility for all kinds of things, such as embedding bullet images in HTML/CSS files, or for any other small embedded media. Mozilla, Opera, even Netscape 4 and QuickTime recognize the data: scheme!
* about
* tests
* The data: URI kitchen


Namespace support


Currently a document can contain an object linked to a namespace:
		 <object id="behav" classid="bla"></object>
		 <?import namespace="prefix" implementation="#behav" ?>
Two things would make this unbeatable: mapping to the namespace URL rather than the prefix, and allowing this linkage between namespace and classid to be made outside the document (i.e. as a preference or similar). Then you wouldn't need to implement SVG, MathML, XForms natively: it would all work transparently out of the box with plugins.


MathML Support


Currently, math-heavy websites need to rely on inline bitmaps to display their equations. This is unacceptable, especially given that a W3C recommendation already exists! MathML is a W3C recommendation, dating back to February 2001.

Yes, there are free plugins that will display MathML for you, but until MathML support reaches critical mass, webmasters will be reluctant to use it. MathML support in IE would provide the required critical mass.

I also agree that MathML support is important. Many people even resort to using PDFs to display pages containing equations. MathML is very important to the development of the web for scientists and engineers. -- Calvin


OpenType Support


Better support for OpenType allows better typography (fi and fl ligatures, for example) as well as better support for non-latin scripts.


P3P (Platform for Privacy Policy) Support


IE6 already has P3P support. -- Simon


PNG Support


See InternetExplorerSupportforPNG


Server-Push Support


A pretty basic feature that has been supported in other browsers from the word go. Should be able to handle headers from both CGI scripts and the multipart MIME type2Multipart.html.


SVG (Scalable Vector Graphics) Support


There's an Adobe SVG Viewer 3.0 Add-in for InternetExplorer. With that free, redistributable add-in, help me understand need to natively support SVG in IE. I don't get it. -- StuartCelarier

GavinGreig: SVG would be fantastic for doing dynamically generated business graphics in a web page. It's obviously the ideal technology for what we want to do (personalised online reports), but currently it would be a "brave" decision to use it, as a large proportion of our customers are employed at corporates where installing an add-in is a difficult requirement - not technically, but in terms of processes. It is hugely frustrating that the right solution has been developed, and is even standardised, but we can't sensibly use it because it's not supported natively in the dominant browser.

BenAnderton: The desire for native (built-in) SVG support stems from the limitations of Internet Explorer's plug-in architecture. Specifically, plugins can (usually) only trigger from OBJECT elements. This precludes the use of SVG images specified inline within XHTML documents, for one thing. However, it is also desirable to support read-only (non-interactive) SVG referenced by IMG elements and other image loading techniques. This would allow the use of SVG images as backgrounds, for example. An alternative to built-in SVG support would be a more rich plug-in architecture which allows plug-ins to latch into various different places in Internet Explorer, from acting as renderers for XML namespaces to pluggable image loaders. I suspect, however, that making a plugin architecture general enough that it could be used to support future specifications would be a very difficult task. IE already has support for the VML vector graphics language (basically "Office Graphics in XML") so it can't be much of a stretch to go from here to some basic non-interactive SVG support and from there support for the interactive elements of SVG.

Pantagruel: As for the need for svg support this I think actually relates to a need for IE to have some way of handling xml namespaces and associating them with rendering/action behaviors, there is of course already some support for this in binary behaviors, and one can use svg inline in html markup using Adobe's svg implementation, but the damn thing will fail over anything sufficiently complex (i.e not a couple circles or similar simple objects). To be brutal I suppose this, the document element on an xml document's namespace is used to get a namespace handler for the document, if that namespace handler fails if defaults to the default xml handler, which is the defaultss.xsl inside of msxml 3. I suppose that unknown namespaced markup inside of a html document can still be handled via the binary behaviors methods, however given that binary behaviors use a syntax akin to processing instructions maybe an overal internet explorer processing instruction should be used for associating namespaced markup with rendering/actions. Then any xml instance would require a default behavior be declared in its processing instruction if said behavior is not declared then fallback is once again to the defaultss.xsl in msxml2.dll. Okay that was spur of the moment stuff, and probably not very clearly thought out, but this is what my gut tells me is the right level to attack the problem at, not implementing svg support, but implementing a methodology to make various xml technologies more naturally part of the browser. After that is done we can talk about actually implementing those technologies.

MikeGale: SVG is a really good idea. I can't use it to write public web pages because the browser needs a plugin which I can't guarantee is there. If it was standard I'd be able to use it eventually. Instead I've written .NET assemblies that consume SVG and emit images. It works but the extra work is annoying. I personally find images cut into pieces, flash etc. a most unsatisfactory approach.
* MS gave us VML in the browser. (Well done, Why no publicity or development!!)
* SVG seems like a logical next step.
* (I'm sure this can tie in with XAML.)

leonbrooks: Further to MikeGale - relying on the Adobe plugin means relying on Adobe to port it or fix bugs, too. You do want to see IE7 run on Linux, don't you? (-:

Iain: The door to SVG, MathML and many other *ML technologies could be provided by the suggestion brought up in the SVG considerations above. Allow other rendering engines to take on parts of the XML tree that are separated by namespaces. Then a MathML renderer would take over for that part of the document and so on. Presumably, this would still be stylable with CSS and would allow positioning and formatting to be specified for the namespaced part as a whole. With some work it might even be possible to get the other renderer to obey the CSS so that, for example, the MathML is rendered in sans-serif rather than serif.


Unicode (font) Support


The symbols starting at 0x2000 are exactly what I need all too often (zero download cost, vector-based), but unavailable to a huge part of my audience, since there is inadequate font support. Arial Unicode MS, expanded for Unicode 4, should come with the browser.


XForms Support


XForms would provide a declarative syntax that is ideal for GUI-based development (once the tools mature) and extremely powerful validation.


XML Binding Language Support


This is a really nice feature that would make the separation of presentation and code even easier for webmasters. -- DalanGalma


XHTML Support


Support for XHTML: "1. In order to be consistent with the XML 1.0 Recommendation XML, the user agent must parse and evaluate an XHTML document for well-formedness. If the user agent claims to be a validating user agent, it must also validate documents against their referenced DTDs according to XML."
* Support for application/xhtml+xml (and here
* Inclusion of application/xhtml+xml in the Accept: header#sec14.1
* Don't put IE in quirks mode when the @<?xml version="1.0" charset="1.0"?>@ processing instruction is used, infact get rid of quirks and more quirks (aka. standards compliant — it's not really, but that's what it's called) modes all together, and just attempt to render everything according to the standards. If a website breaks because it relies on quirks, it's the sites problem, not yours so let the author fix it. They might get their ass into gear when they realise their site will break with a future version of IE, so it would benefit everyone. Leniency with the code is one major reason there are so many invalid websites, so it's all yours and netscapes fault the web is so inaccessable. Also, set a good example and make this Wiki use valid HTML.


XHTML2 Support


There are some things that look stable so far:
* <section> and <h>
* <nl> navlists

XHTML 2.0 (Extensible Hyper Text Markup Language 2.0) should should not be implemented until at least after it reaches a Candidate Recommendation, and the call for implementations has been made, no matter how stable elements may seem to be, there's still a chance they could change. The only thing worse than not supporting a standard is having an non-conformant implementation, which is highly likely to occur while XHTML 2.0 is still a draft specification. (This did not stop MS from pre-implementing XSLT. -brianiac) However, since the next version of IE must support application/xhtml+xml so that a 4 year old standard (XHTML 1.0) can, and will finally be used on corporate websites, XHTML 2.0 should be supported as XML, which can at least be styled.

One issue with this is that attributes like @href@, @src@ and other's which are now in the Common Collection and can thus be used on almost every element, may not work. HLink (Link recognition for the XHTML Family) may address this issue, but it's still a working draft.


XSLT (Extensible Stylesheet Language) Support


Again, IE6 fully supports_browsers.asp XSLT. -- Simon

Assuming XSLT 2.0 is available by the time the new IE is out, that would be a powerful infrastructure for a variety of applications. -brianiac


XUL Support


Maybe XAML will takeover and this won't be needed.
* http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul
* http://en.wikipedia.org/wiki/XUL
* http://www.mozilla.org/projects/xul/


Everything above here talks about specific standards. Everything below here is more of a general discussion -- JonathanHardwick


Discussion


Regarding XHTML 2.0 and its implementation... Considering the standard is more or less stable these days, there should be advance work on it, so that if it goes into Call for Implementation, the IE team can implement the last minute changes and flip a switch.

That requires that the team will issue regular engine updates often, though, instead of major releases every 6-9 months. And that it doesn't just idle, waiting for Mozilla do the next move. Which is another issue, considering that the Mozilla team thinks it should only implement new web standards if the market share leader does, too. -- Tom Servo


I don't think that modern web design can progress until Internet Explorer improves in standards support, IE hasn't changed much since 4.x and most web design enhancements (like CSS2, Alpha-transparent PNGs) have been blocked from being common until IE can support it. -- Simon


Standards have had no priority for years, they should have a priority higher than features and almost equal priority to security for many reasons. A few of which are:
*So that years do not become decades.
*Microsoft is a member of the W3C and chances are Microsoft made the specification or a good part of it.
*Many web developers, of which a significantly large portion are Microsoft customers, will want to use them.
*Corporations that are huge customers of Microsoft might be able to save money (could save bandwidth or compress very well, which would mean the server will close connections faster lowering the CPU load thus allowing the server to do more with less) by utilizing the specification.
*Microsoft has control of 95% of the browser market so it has an obligation to do so or risk having another antitrust lawsuit.
*Lack of standards support contributes to peoples' hatred of Microsoft.
-- Shining Arcanine


An increasing number of webmasters have given up on Internet Explorer and are designing their websites so Internet Explorer cannot display them to accomplish two things:
  1. Be able to use standards.
  2. Force people to use browsers that support standards.
They are using bugs in IE's standards support to prevent IE from displaying them. A friend who did this then decided to make an extremely hacked and simple stylesheet specifically for IE which provides users of Internet Explorer a significantly degraded user experience. The Windows IE team can provide users with a superior user experience (which I believe is one of Microsoft's goals) by implementing full CSS support ASAP. -- Shining Arcanine


Arcanine, I don't know of any 'paid' designers who design sites that are incompatible with IE6. Even wacky, out-of-the-way proof of concept sites at least display reasonably in IE6. If you don't at least throw IE6 a bone (like when everyone was groaning about having to support NS4, but you still had to) the web designer is being irresponsible. That said, I long for the day that this particular problem will be behind us, and that starts with the IE team bringing IE up to code. -- DalanGalma


I never said that paid designers make sites that are incompatible with Internet Explorer. I said that an increasing number of webmasters are designing their websites so Internet Explorer cannot display them. Webmasters is a very broad category which includes both people being paid (as you intrepreted my comment for) and people who own hobby sites (the people that my comment primarily referred to). -- Shining Arcanine


Right, as nice as it would be to implement full CSS 2.0 support ASAP, users aren't going to upgrade IE unless there are some other tangible benefits to upgrading. And of course, Microsoft don't look likely to release a new version of IE with "new features" from Joe User's point of view before Longhorn. BTW, the IE team supporting CSS 2.0 won't magically provide users with a richer experience and prevent crappy website design. It's web designers that ultimately provide a rich user experience. -- Simon


But full CSS2 support, (coupled with good PNG alpha support) 'enables' web designers to make nicer looking sites. And Microsoft can market the upgrade as something that makes "the web" look better and run faster. It's bull until people start using the new features, but it certainly does allow it. Also, a lot of people will upgrade to the newest thing no matter what. And even if it dosen't matter at all to average users, Microsoft owes its customers to at least fix the support for the things they claim to support. -- DalanGalma


Kirk Biglione has a fine rant about Microsoft's support (or otherwise) of web standards on the alt tags blog -- JonathanHardwick


Wasn't standards support one of the 'selling' points of IE6? See IE6 What's New and Internet Explorer Features. What may make some happy is if better support was available as part of XP SP2 - Windows 2000 users will not benefit, but it would prove that Microsoft has not forsaken standards.


Even PNG alpha support would be appreciated - how can adding it break existing sites? IE6 came out in 2001, even SP1 didn't improve standards. The blog above summarises a good point - Opera and Mozilla can create a compliant browser, why can't Microsoft (too busy fixing security holes probably)? Longhorn will have to be an exceptional OS with better CSS/PNG support. -- sbc


I understand that a lot of people on these forums (and elsewhere) have been begging for better W3C standards support. However, I also understand that if the IE team forced stric adherence to the W3C standards down everyone's throat, A LOT of existing web pages would break. I'm sure a lot of people in this forum will say "good, let them break", but that represents millions of dollars in developer time that will have to be thrown out. It will also make the web browsing exeperience WORSE for the average user (Joe Blow doen't care about W3C standards, and never will). The grim reality is that there are a lot of sites that will probably NEVER be fixed to use proper HTML.

Here's my proposal:
  1. Don't screw with existing web sites. Leave them exactly as they are.
  2. For any new standards that come out, follow the W3C guidelines as closely as possible.
  3. Add a support for a special META tag in new versions of IE. Call it something like "obey-dtd-rules", or something similar. When a the new IE encounters a page with this tag defined (and a proper DTD at the top of the page), IE should then closely follow the DTD rules, rendering the page like Mozilla does, instead of the way IE currently does. This shouldn't interfere with other browsers, as they should ignore the tag.

The idea behind this is that old sites that won't be fixed won't add this new META tag, and will render just as they always did. For web developers that actually followed the HTML or XHTML spec, they can add this tag to tell IE to render it properly.

I'm seeing it look something like this:
		 <meta name="obey-dtd-rules" content="yes" />
This idea would require developers to add the tag, but it's not that much work compared to trying to get a page rendering perfectly in both IE and Mozilla. And this tag would only be a requirement for existing standards. As new ones come along, they can be implemented exactly as the W3C reccomends.

If this is too complicated, you could scale it back to that "obey-dtd-rules" only works for XHTML pages. You could probably have two rendering engines, say MSHTML (the exisitng one) and MSHTML2 (the new standards-friendly one). The code could check for the presence of that tag AND a proper DTD, and if so pass the HTML to the new engine, otherwise use the existing engine.

At least, this is my idea for a compromise. It give developers what they want with a minimum of effort, and won't break most of the web. -- msemack


I don't think the creation of a unique 'meta' tag is the best route for this. Most, if not all, non-IE browsers simply use 'doctype' sniffing to send the browser into either quirks or standards mode, and about 99% of websites behave fine in browsers that support modern web standards. If IE tightens up its CSS/XHTML support in standards mode, it will not affect the display of old websites in quirks mode. And once IE supports these standards fully, more webmasters will be encouraged to write pages that render in standards mode. Eventually, quirks mode may only need to be used for old, archived webpages that haven't been modified since the pre-standards days. --taestell


Except that even with a properly defined DOCTYPE, IE still has some quirks. There are many web pages that have a proper DOCTYPE, but still depend on IE's quirks. That's the point, you can't change how exisitng web pages are rendered. You will break the web for a lot of people. Furthermore, there are a lot of old pages that will probably never get updated. Saying "It's ok if IE renders pages badly that it used to render properly" is like saying "It's ok for Windows to drop DOS support". People depend on it. People have millions of dollars invested in the old technology. Telling them "tough, you've gotta move forward" will just tick them off.

It's very easy to preach standards, but one lesson I've learned is that companies hate to change their existing applications. Maybe it was written by a 3rd party contractor and no one understands it. Maybe the people who wrote it are all retired/layed off/fired. Maybe they lost the source code (I've seen it happen). If the pages are borken, they're going to stay broken.

If a customer tries to browse the web with the new IE, and current pages don't render like they did in the old IE, he's going to say "this new IE sucks", and go back to the old one. Remember, Joe Schmoe isn't going to say "Well, this page must not have standards-compliant HTML, let me write an e-mail th the web master".

Also, think about all the people that are using WYSIWYG web page editors that produce invalid HTML. The web masters who know nothing about how HTML really works. Try explaining to them how to make their pages standards compliant. Sad but true. -- msemack


In response to earlier comments about leaving things hopelessly broken and supporting new standards to the fullest. There is one slight problem. New standards do not replace old standards, they build on them. CSS Levels 1, 2 and 3 are not CSS 1.0, CSS 2.0 and CSS 3.0. They all parts of the CSS specification. Leaving a previous one broken impairs the ability of web developers to utilize newer ones.

All standards must be fully supported in Internet Explorer. Firefox has what seems to be flawless standards support and can display 99.999% (educated guess) of the internet flawlessly. If Internet Explorer was the same, the only sites that would be would be sites that were broken to begin with by utilizing doctypes (which give the browser a guarentee that the page follows the specification) when they used quirks mode code. For the people who complain because their sites were broken and were shown as broken in a newer version of Internet Explorer, simply state "you can either fix your site or pull the doctype (that should have never been there) and everything will render like it used to."

Additionally, it is very likely that any site that would support standards that are broken in IE such as CSS Level 2 is standards compliant. Therefore you should not bother maintaining support for broken markup and go ahead and fix it. -- Shining Arcanine


New standards build on the old one. So when IE encounters a doctype for a brand new HTML standard (let's say XHTML 2.0), it should render XHTML perfectly. However, a lot of existing sites use the DOCTYPE tag incorrectly to deal with IE quirks. I agree that they should not do this, but they do. And they render fine in IE now. Breaking them is a step backwards. You claim 99.999% of sites are fine. I have seen about 1 site in 4 that doesn't render perfectly in Mozilla. Let's just agree that there are broken sites.

By making those sites render incorrectly, no matter the number, you are DECREASING THE USER EXPERIENCE. Remember, it's all about the users. I don't care how important you think standards are. 99% of the world doesn't care. All they know is "this site used to work with IE6, now it doesn't work with IE7, stoopid M$ can't use their $50B to make the intarweb look good".

Just because you are willing to live with some site that don't render properly doe not mean the general browsing populace will. Also, you have to consider the thousands of applications that use the MSHTML rendering engine for internal stuff. Now you're talking about application changes, just just web pages.

Furthermore, there are more than enough web sites out there made with WYSIWYG tools that generated invalid HTML. Good luck getting people to change them. In those cases, you're probably dealing with a staff that wouldn't know how to fix their HTML. Not to mention that it would probably be re-broken by their WYSIWYG editor soon after.

Breaking exisitng web sites and applications will require (literally) millions of dollars in developer time and QA. The costs would be even higher for companies that don't have the web developer expertise in house. It will take years for web sites to get their HTML bugs worked out. Some will probably never be fixed.

Heck, think of the lawsuits from companies with bad HTML in their online storefront that lose business because customers can't use IE7 to view their sites.

Do you really think it's a good idea to tell the user "sorry you can't view this page because the author didn't use valid HTML. I know you don't care, but I do so tough luck."?????????

All this because some guys on the channel 9 forums whined about how they feel standards are important. Let's put it this way, come up with a compelling BUSINESS CASE for breaking existing web sites. If you can't, then breaking them is a bad idea.


I would consider that argument to be very short sighted. Users do matter, but I'd argue that code quality matters more. If Google cannot reliably index the Bob's House of Vacuums web site, too few people will even get there to use it. Well-written sites can also be used by future technologies, beyond their current expectations. Designing HTML-soup means you need to rewrite each time the site is used in a different way: Pocket PCs, a tip in the browser ecology, reusing content in RSS, etc. A bad experience using Pocket IE, for example, just looks unprofessional.

One in four sounds like an inflated claim. I've used Firefox as my main browser for a year, and Mozilla before that, and I've found maybe one or two sites that do not look and work just fine. The ones that do break are usually user-agent filtering, and work fine once the UA is spoofed. Do you have examples of sites that are incompatible with Gecko-based browsers or Opera? Your claim of years and millions of dollars is predicated on the assumption that a large number of sites will "break". Please quantify the number of sites we are talking about (anyone--we really need to get some stats here because both sides seem to be assuming a scenario to reinforce our preconceptions), and what level of "breakage" we are talking about (minor cosmetic, cosmetic, minor functional, functional, hosed). Keep in mind that most sites are already quite ugly, and the browser cannot be blamed for this. ;)

Bad code tends to be accompanied by a missing, incomplete, or invalid !DOCTYPE, which should trigger Quirks Mode.

I do not understand the concern about WYSIWYG editing: this would be an opportunity for FrontPage (clean code edition) to dominate the market overnight, while MS gets to wear a white hat for "cleaning up the Internet"!

Do you really intend to tell the user "sorry you can't view this page"? Shouldn't quirks mode prevent that kind of message?

Here's the business case: it is faster and easier to build a website without the IE workarounds, and the resulting sites are faster, more flexible, and more feature-rich.

If our opinion is trivial, then isn't this site just a colossal waste of time?

A final thought: what if Visual C++ included a "Quirks Mode" that assumed it knew what you meant to do? -brianiac


Question : How many sites would get broken if MS simultaneously fixed the box model and the voice-family hack? Think about it. --evanbro


Most webmasters that correctly understand the CSS box object model use a "CSS hack" (such as the "voice-family hack") for the IE-specific values, but include the correct values for all other browsers. In other words, there would be no problem if MS fixed the "voice-family hack" and the box object model at the same time. There would only be a problem if MS fixed the "voice family hack" and did not fix the box object model; If they did this, IE would get same values as other browsers, but would display the site differently due to the broken box object model. But isn't the box object model already fixed in standards compliant mode? --taestell


Something that you might want to think about that hasn't been mentioned yet is XFORMS. While they sort of compete with Infopath, they are extremely useful and could shrink the size of form pages significantly and also limit the amount of server requests a site would get for validation. I know its not high on your list probably, it is something that could be quite useful.
Baby Gifts - All for your babies and kids


Breaking support for existing (i.e. non-standards compliant) is something MicroSoft will never do, but what I would propose is adding an icon in the status bar that shows if the page is considered compliant or not. This could e.g. be a 'W3C' logo that has been striped through or not. This will give web developer that only test with IE at least an indication and incentive to make their pages standards compliant.

Double clicking on the icon could then maybe reveal what exactly is wrong with the page...

What about it?


The P3P support in IE 6 broke our site. Never may be overstating things a bit. -brianiac


Before there is a great deal of effort thinking about a new standards-compliance mode (three modes?!), keep in mind that MSDN says "In standards-compliant mode, compatibility with other versions of Internet Explorer is not guaranteed. When standards-compliant mode is switched on, the rendering behavior of documents might differ in future versions of Internet Explorer. You should not use this mode for content that is fixed in nature, such as content that is stored on a CD." (thanks Rosyna). Also, the extent of damage needs to be assessed before investing a huge amount of work and complexity here: how many pages on the web will it hurt, and how badly?


It has been said before, I will say it again to emphasize some details:

Implement W3C compliancy wherever you go. CSS2, MIME types (including correctly rendering XHTML content types, and not offering XHTML for download as IE6 does at times). SVG built-in as an option. Full PNG support.

Additionally, it would be nice if a small frowning icon would show up whenever the page does not validate according to a strict doctype -- hey, just make it an option until IE8.

Anyway, CSS compliancy is the biggest problem with IE6, so fix that before all other things. Especially the lack of working selector syntax needs a heavy update. -- Philipp


* proper implementation of CSS 1, CSS 2
* css: working selector syntax
* full PNG support without plugins
* XML: XHTML, XLink, XPointer, XForms, XPath, XSL , X3D, SVG, MathML
* support for all w3c standards
* lack of standard compliance encourages pages that work -only- in Internet Explorer and not other, more secure and more functional, browsers.
* display "invalid site" icon in status bar when web site is non standard
* don't render non standard compliant things
* JPEG2000 support
* MIME types. including correctly rendering XHTML content types
* Sun JavaVM shipped with IE (disabled by default for security reasons)


I have many issues ;o) Some already mentioned here by others. I'll go with my top 2 issues at this very moment.

* HTML: DIV and FIELDSET don't wrap around content like TABLE does. Instead they take all the horizontal space they are given. I did not find any justification for this in the spec.
* CSS: TABLEs do not inherit style from their parents.


Hey - How how come SELECT (dropdownlist) doesn't support a tooltip. Shouldn't IE add that to the standard?

SELECT#edef-SELECT does support a tooltip#adef-title (it's already in the standard)


Nutscrape! Lest We Forget. Hold a memorial service each year on 16 July (The day of the MS/AOL deal), to remember Netscape's death, since Microsoft nearly killed during the browser wars, and finished it off with that money making deal with AOL. Then worship those that reincarnated it with the Mozilla Project.


To the IE7 team:

* Please support CSS 2.1 entirely for the next release of IE. Opera in its own website claims#css that its Opera 8.5 support entirely CSS 2.1 while konqueror.org claims that Konqueror 3.4 supports almost entirely CSS 2.1 : so this is a reachable goal.
* Fix known, demonstrated, documented and "testcased" bugs in MSIE 6: this is particularly important to do before such bugs become part of normal programming manners or some sort of support legacy thanks to repeated bug-workaround coding habits.
* Implement DOM 2 Events: this is one area where DHTML programming can be a nightmare for web designers. MSIE's DOM event interface is not as good, advanced and performant as the W3C DOM 2 Events interface.
* CSS selectors support: MSIE 7 beta 2 fails 86 tests out of 181 tests which is the 2nd worse result out of 6 browsers tested: KHTML only fails 12 tests out of 181.
* Give absolute veto power to the users when it comes to windowFeatures (like chrome toolbars presence and browser window functionalities like resizability and scrollability) of secondary window generated via window.open() calls. There is nothing more frustrating than a poorly coded link that creates a crippled window (non-resizable and without scrollbars). The window is frustratingly unusable and inaccessible in such cases and such crippled window can not serve the authors' goals nor give the user access to the content. All other browser manufacturers (Opera, Mozilla, Konqueror, Safari) out there have given the user entire veto power over web developers on window.open() windowFeatures. All non-chrome windows should always be resizable. 'Earlier versions of Internet Explorer ignored the resizable=no feature and allowed you to resize the new window.' http://support.microsoft.com/default.aspx?scid=kb;en-us;211068 One reason as to why tab-browsing is more appreciated than non-tab-browsing is precisely because web authors can no longer modify the UI of the window application. New windows can have menubar missing, scrollbars missing, window resizability disabled, etc.; new tabs can not be missing those functionalities or toolbars (or at least, the toolbars which are present by default). Therefore, tab-browsing is preferred by a lot of users because the normal user-interface of the browser window they prefer is kept intact, remains stable.
http://developer.mozilla.org/en/docs/DOM:window.open#Avoidresortingto_window.open.28.29
* Drop support completely for "javascript:" pseudo-protocol links. "javascript:" pseudo-links are a bad way to create DHTML because
* a) they break accessibility and they fail when javascript support is disabled for various reasons (like: security, corporation policies, public access, text browsers, etc.),
* b) they interfere with the process of indexing webpages by search engines,
* c) they break in assistive technologies and/or other web-aware applications (PDA),
* d) they confuse and interfere with advanced tab-browser features (middle-click, Ctrlclick, CtrlShit+click to open the link in a new tab in background or in foreground), etc.
Top Ten Web-Design Mistakes of 2002 (http://www.useit.com/alertbox/20021223.html), 6. JavaScript in Links, Jakob Nielsen, December 2002
* Implement a feature which will report back to the user if a page uses valid code, has markup and/or parsing CSS errors: some sort of a Webpage Quality indicator icon (smiley or green check for valid page, frown or red 'X' when invalid) on the statusbar (or somewhere else) which when clicked would report more info to the user and give him more options among which one would be to validate the page with the W3C validator. Implement something like HTML Tidy as an extension or an option into IE 7 and for IE 7 users.
A few browsers today already report common mistakes and errors in webpages: Icab 2+, Amaya 9.x, Dillo browser, Firefox 1.x error console, BBedit, Opera 9.x error console, etc. http://scholar.lib.vt.edu/staff/handbook/tasks/syntax_checking/#toperrors The trend today among modern browsers is to make possible, available such report of these errors (js errors, CSS errors, markup errors) to the user because
* a) the user can become a web author too; web authors were and are users to begin with
* b) the user can report back to the web author about his problems at using a visited site: absence of feedback/interactivity in that area hurt the web community at both ends.
* c) the user has a chance to take an active part into fixing problems and improving the quality of website

* W3C HTML 4.01 specs recommend browsers to notify users about markup/syntax errors in pages: 'We also recommend that user agents provide support for notifying the user of such errors.'#h-B.1 http://www.w3.org/TR/html401/appendix/notes.html#h-B.1 Silent recovery from error is harmful, in particular for improper nesting of elements (malformed markup code), missing closing quotes, incorrect attribute values, etc... "*Agents that recover from error by making a choice without the user's consent are not acting on the user's behalf.* (...) Experience with the cost of building a user agent to handle the diverse forms of ill-formed HTML content convinced the designers of the XML specification to require that agents fail upon encountering ill-formed content. Because users are unlikely to tolerate such failures, this design choice has pressured all parties into respecting XML's constraints, to the benefit of all." coming from: Architecture of the World Wide Web: http://www.w3.org/TR/webarch/#no-silent-recovery "The whole reason nearly all Web pages on the Internet are malformed is because browsers let Web page authors get away with it. As long as browsers are permissive in their error handling and recovery, Web authors will continue to produce invalid Web pages, because they won't even have any idea the pages they are authoring are invalid! (...) people who don't work on Web browsers for a living have no concept of just how malformed the Web really is" coming from http://weblogs.mozillazine.org/hyatt/archives/2004_01.html#004702
* Support for scrollable tbody and wise printing of table sections. "(...) This division THEAD, TFOOT and TBODY elements enables user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data.". HTML 4.01, section 11.2.3 Row groups: the THEAD, TFOOT, and TBODY elements Scrollable tbody at WAI

--DU/GT

Please Comply with W3C Standards!

I know a million people are saying this in every forum, but make that attempt. The W3C is there for a good reason and its important to support the standards now fully as Netscape/Mozilla/Opera are doing, for the most part. The second issue is IE does a very good job patching together logic for displaying width:100% and height:100%. Instead, please do what Netscape and Mozilla do and define 100% as actual viewport values and support min-width and min-height (and the "max" versions of those tags). I think that is a major problem for designers in IE this year, as we move to the CSS driven design model in pages. IE should match the standard, and that will allow us to use complete web page structuring in CSS that works the same in all browsers and allows us to build great expanding and contracting divs and complex page structures that will finally allow us to abandon tables and spacers. Its a w3c recommendation and like to see that implemented in IE. Another is use of "border-spacing:" support for defining cellspacing in tables using CSS. Thats critical if we want to abondon table attributes and table use for structure and move to the xhtml stricter doctype. Also, what is the cause (or solution) to why placing the xml prologue before an xhtml doctype, forces the browser to ignore the doctype and/or convert to quirks mode. Maybe Im not understanding whats happening there when both are implemented, but please look into that. I think you should be able to repurpose your page optionally by adding the xml prologue at the top and if you are using xhtml, it NOT affect that page's display in desktop browsers, as long as content-type is defined in that page. But, using the xml prologue, that should then be able to allow that page to be used as xml, or as an xml application strictly, for those troublesome agents that require it and dont recognize the doctype, as xhtml is nothing but xml anyway, right?
Lastly, remove the feature where assigning a tag to a pixel based font size locks the browser and user from changing text size....or, at least check the agent recommendation from the w3c on that. Mozilla supports this feature....I think its a valid standard. Or at least, add an alternative browser feature called "zoom", that allows text to remain pizel-set, but on zoom, truly magnifies the browser window and thus resizes text that way. - MS


Having an IE supporting all standards the right way is breaking the web si

As a developer I do fill really frustated about ie.
Millions of pages about the problem, but not so many about solutions.
MS now more than ever wont follow any standars.
I will ask to all of you a big favor and it is...
Why, there can't be a plugin like Adobe Acrobat Reader, or Flash, or else ... so the client gets a browser in a browser? so the plugin is Javascript standar, dom standard, etc. If the Acrobat Reader appears inside the web-browser as it does word and excel, why not a mozilla 100% compatible browser? or does it already exist?
Every body users Acrobat Reader, Flash, etc. They do download the plugins, I think the same they will download a mozilla browser plugin. Is it possible?
Let me participate in a proyect like that ... my mail is dlogica (at) gmail.com