A Forum Request.

[deletethisaccountpls]

I dont know if its possible but im asking anyway, cant the links open in a new window? It's so annoying.

PunBB should handle that?

[ScubaSteve]

no your browser should handle that not the forum. try getting a browser like Opera. or even perhaps other browsers like Firefox + Maxthon

[hofshi]

In Firefox just middle-click a link to make it open in a new tab.

[deletethisaccountpls]

So much probs just for a linking in a new window? and ScubaSteve: what are the IE ppl gonna do, they aint FF & Opera ppl like us.

[DreadWingKnight]

if you were to look at the HTML being generated, you would not be seeing the target="_blank" code in the links associated with the [ url= ] tags. That is a bug in the template, not in the browser.

[dAbReAkA]

IE ppl will have to change to another alternative

[1c3d0g]

Agreed. Enough with pleasing the IE crowd. Your browser is hopelessly broken, just get a better one. There are plenty of 'em out there, for free. :/

[bleh]

Yes, sadly it is so, IE is hopelessfly flawed.. hopefully they'll fix these errors and many more in future releases. But, I certainly won't hold my breath, I made the switch around two years ago and I've never looked back since.

Hopefully I'll make an OS switch aswell soon. (provided I get can my arse into gear)

[Animorc]

The forum is valid XHTML Strict, so target="_blank" is not allowed to be used. Hold [shift] while clicking a link and your problem is solved.

[Dark Shroud]

no your browser should handle that not the forum.

Incorrect, a forum should implement scripts to help their users.

In Firefox just middle-click a link to make it open in a new tab.

I'm assuming you're talking about a three button mouse, those aren't common, even though they should be.

IE ppl will have to change to another alternative

Or they could get IE 7.

Agreed. Enough with pleasing the IE crowd. Your browser is hopelessly broken, just get a better one. There are plenty of 'em out there, for free. :/

Who are you say that IE is hopeless? What if people hosting forums decided not to support Fire Fox because it's unstable? IE 7 is better than ever, it has the few old problems removed. The first paragraph in the documents on IE 7 beta-1 features state that they removed some of the outdated ten year old legacy code for security reasons. In essence IE 7 is stripped down and more secure with new options to boot.

I've never had the problems with IE that I hear other people talking about. My only problem with it was no pop-up blocker, but SP-2 fixed that just fine for me. With two programs by the names of Spybot-SD & Spyware Blaster I have not had any problems with IE. And if you're going to piss and moan about "tabs" well guess what IE 7 has them. And before that you could get the "Advent Browser" add-on for IE that also has a pop-up blocker that even blocks flash (Just like Spyware Blaster) for those non SP-2 people.

Side note: Fire Fox will not be a good alternative until it works on systems without locking them up or crashing them or its self. Plus you have to down load 20 plug-ins to get features that are built in on other browsers, like IE 7, Mozilla (Better than Fire Fox will ever be.), & Opera (now ad free ).

Animorc seems to be the only person to explain the problem and give an actual fix.

[Firon]

He said there is NO fix. There is no target attribute in XHTML strict.

ctrl click on FF/Opera, shift click on IE. That's all you can do.

[1c3d0g]

Who are you say that IE is hopeless? What if people hosting forums decided not to support Fire Fox because it's unstable? IE 7 is better than ever, it has the few old problems removed. The first paragraph in the documents on IE 7 beta-1 features state that they removed some of the outdated ten year old legacy code for security reasons. In essence IE 7 is stripped down and more secure with new options to boot.

Nobody. Just like you. However, unlike you, I'm very aware of Trident's completely broken XHTML engine and CSS "support". It's people like you who keep clinging to old crap that have kept the Web stagnant for the past 5 years. By just moving to another browser - ANY browser not based on IE - you'll be actively contributing towards more awareness of other browsers' market share. Standards are there for a damn good reason, and when a browser willfully ignores those established standards and creates its own, everybody has a problem. :/

[hofshi]

agreed.

[DParrott]

no your browser should handle that not the forum.

Incorrect' date=' a forum should implement scripts to help their users.[/quote']

How do you decide what it is that helps everyone else that uses the forum?

I personally hate it when my browser is doing things that I've not told it to, if I want something in a new window or tab I'll open it in a new window or tab, my choice, not something I want forced on me by a site.

[Dark Shroud]

Nobody. Just like you. However, unlike you, I'm very aware of Trident's completely broken XHTML engine and CSS "support". It's people like you who keep clinging to old crap that have kept the Web stagnant for the past 5 years. By just moving to another browser - ANY browser not based on IE - you'll be actively contributing towards more awareness of other browsers' market share. Standards are there for a damn good reason, and when a browser willfully ignores those established standards and creates its own, everybody has a problem. :/

Once again, neither I nor my friends who use IE have had any problems with xhtml or css with IE 6 and previous versions. Many people who had problems with IE never properly updated on a regular basis or understood how to use the settings. Now, if you actually knew what you were talking about when it comes to IE you would know that it has support for xhtml, css, and even rss. IE 7 is very different from IE 6; you should try reading some of the documents from Microsoft on it. You might save yourself some future embarrassment. Because weather you like it or not IE 7 is going to make a big impact in its final release.

The only thing keeping the web stagnant are people using poor html codeing utilities put out by ISPs.

As to your comments on standards, why don't you actually go look up internet history before making commets like that. Because html code standards were developed by Netscape & <gasp> Microsoft. W3C had to step up because both Microsoft and Netscape wanted certain things done their way.

Now if all you're going to do is continue with the usual n00b/troll "M$ is teh devil" speech then I'm going to ignore this thread from now on.

How do you decide what it is that helps everyone else that uses the forum?

The best way I've seen is like this. A person makes a request for a feature, if a few more people post supporting the new feature the mod then makes a decision on his own or puts up a poll for everyone to vote on adding the new feature.

[JigPu]

Careful with your accusations Dark Shroud. I'd hardly put 1c3d0g's posts as trolling.

IE does support XHTML, CSS, and RSS. However, what 1c3d0g was pointing out is that the support is broken. And not just by the browser, but by the rendering engine (Trident). IE7 ships with some updates to the engine, sure, but it still isn't perfect. Then again, I don't know of any browser that reachest perfection in rendering, so saying it's broken dosen't really mean much.

What does mean a lot is that because of IE's broken rendering, web developers are forced to implement (at least) two versions -- one for IE, and one that is actually correct. This is a lot of wasted time, let me assure you. IE having rendering issues is not enough of a reason to not use it, since every browser has its own. However, it does have more issues than others, and is the cause of all that wasted time. For me, that's enough reason to not use it. I don't design websites for a living, but the two or three sites I've done have left a bad taste for Trident in my mouth with all the special exceptions I've had to make for it. I don't see why I should use and support a rendering engine with more bugs (Trident) than one with fewer bugs (Gecko, whatever Opera uses, etc).

Side note: Fire Fox will not be a good alternative until it works on systems without locking them up or crashing them or its self.

...and yet IE6 crashes just about as often as Firefox does for me... Admittedly that means "almost never" (once or twice a month), but I really don't see how Firefox isn't a good alternative based on that. I'll grant you the plugins thing though (lets face it, there are tons of plugins and functionality that Joe Sixpack isn't going to find). Of course, you could just use one of the other feature filled (and less rendering-buggy) browsers like Opera (my personal browser of choice).

JigPu

[Firon]

the front page has a ton of IE-specific fixes because IE is broken in rendering

[1c3d0g]

...

Once again, neither I nor my friends who use IE have had any problems with xhtml or css with IE 6 and previous versions. Many people who had problems with IE never properly updated on a regular basis or understood how to use the settings. Now, if you actually knew what you were talking about when it comes to IE you would know that it has support for xhtml, css, and even rss. IE 7 is very different from IE 6; you should try reading some of the documents from Microsoft on it. You might save yourself some future embarrassment. Because weather you like it or not IE 7 is going to make a big impact in its final release.

The only thing keeping the web stagnant are people using poor html codeing utilities put out by ISPs.

As to your comments on standards, why don't you actually go look up internet history before making commets like that. Because html code standards were developed by Netscape & <gasp> Microsoft. W3C had to step up because both Microsoft and Netscape wanted certain things done their way.

Now if all you're going to do is continue with the usual n00b/troll "M$ is teh devil" speech then I'm going to ignore this thread from now on.

...

Here's a free lesson: never start a debate in which you don't know SHIT what you're talking about, mkay? :/

First of all, IE's (X)HTML and CSS support is horrible. But don't take my word for it, just look here:

...

Standards support

Internet Explorer offers support for HTML 4.01, CSS Level 1, XML and DOM Level 1, with some implementation gaps. It also offers limited or broken support for CSS Level 2, XHTML, DOM Level 2, and XSL. Internet Explorer provides its own dialect of ECMAScript called JScript.

...

Proprietary extensions

Internet Explorer has introduced an array of proprietary extensions to many of the standards, including HTML, CSS and the DOM. This has resulted in a number of web pages that can only be viewed properly using Internet Explorer. Some view this as an example of what is called "embrace, extend and extinguish" (EEE), a way to drive competitors out of business by forcing them to use proprietary technology that Microsoft controls, resulting in vendor lock-in.

...

And so on and so on. :| But wait! Let's grab the long list of details that their (X)HTML "support" currently lacks:

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 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. World Wide Web Consortium

12/6/2004 10:45:25 PM - dmarsh

W3C spec

* 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 World Wide Web Consortium

12/6/2004 10:45:25 PM - dmarsh

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

* 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 and An optional method is to use the title attribute on the table element, but the summary attribute is preferred because of the semantics of the attribute.

* 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/bugzilla_wcag/show_bug.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.'

* Support for fixed height on <td> when rowspan attribute is used.

* 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. HTML 4.01, Section 16.3.2 Target semantics says 'User agents may provide users with a mechanism to override the target attribute.' 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 CSS2.1 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 CSS2.1 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."

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 add a one or paragraph summary or description of what's discussed here; put yours after 'Summary:'

7/13/2005 10:16:05 PM - Loadsgood

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? What about IE7?

8/30/2004 11:01:44 PM - leonbrooks

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 What's known about InternetExplorer Version 7

2/1/2006 5:37:45 AM - sbc

IE7 should identify in conditional comments and What's known about InternetExplorer Version 7

2/1/2006 5:37:45 AM - sbc

IE7, not IE6? What about IE7?

8/30/2004 11:01:44 PM - leonbrooks

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. World Wide Web Consortium

12/6/2004 10:45:25 PM - dmarsh

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? What about IE7?

8/30/2004 11:01:44 PM - leonbrooks

IE6 Quirks Mode. IE6? What about IE7?

8/30/2004 11:01:44 PM - leonbrooks

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/xhtml+xml" content type and IE6? What about IE7?

8/30/2004 11:01:44 PM - leonbrooks

IE6 Quirks Mode or Quirks Mode for other HTML/XML content types. It allows 100% compatibility because quirky browsers including IE6? What about IE7?

8/30/2004 11:01:44 PM - leonbrooks

IE6 don't support "application/xhtml+xml" 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, Click to read this topic

7/23/2004 7:06:05 PM - jonathanh

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 World Wide Web Consortium

12/6/2004 10:45:25 PM - dmarsh

W3C recommendation already exists! MathML is a World Wide Web Consortium

12/6/2004 10:45:25 PM - dmarsh

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? What about IE7?

8/30/2004 11:01:44 PM - leonbrooks

IE6 already has P3P support. -- Simon

PNG Support

See ProductFeedback about InternetExplorerStandardsSupport for Portable Network Graphics

2/19/2005 10:02:38 PM - jonathanh

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 type

SVG (Scalable Vector Graphics) Support

There's an Adobe SVG Viewer 3.0 Add-in for More information about Internet Explorer

2/23/2005 4:41:09 PM - jonathanh

InternetExplorer. With that free, redistributable add-in, help me understand need to natively support SVG in IE. I don't get it. -- Click to read this topic

11/21/2004 8:09:27 PM - loadsgood

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.

Click to read this topic

6/23/2004 10:51:08 PM - MikeGale

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.)

Your favourite Devil's Advocate

8/30/2004 11:10:11 PM - leonbrooks

leonbrooks: Further to Click to read this topic

6/23/2004 10:51:08 PM - MikeGale

MikeGale - relying on the Adobe plugin means relying on Adobe to port it or fix bugs, too. You do want to see What's known about InternetExplorer Version 7

2/1/2006 5:37:45 AM - sbc

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.

Click to read this topic

7/23/2004 7:06:05 PM - jonathanh

XForms Support

Click to read this topic

7/23/2004 7:06:05 PM - jonathanh

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. -- Click to read this topic

1/10/2006 1:16:52 PM - dalangalma

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

* 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.

Oops...was that too long to read? Well, we're not done yet, here's some more for you to drown in.

Ah, I forgot, the previous list was (X)HTML only, here's the CSS bug list. :| Note that this article has links for FURTHER IE-ONLY BUGS:

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

* 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

* Peter-Paul Koch bug report over 102 bugs so far!

* G. Talbot MSIE 6 bugs over 23 bugs so far

* Position is everything bug list

* Hixie's CSS bugs with testcases has well over 50 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 content box of the nearest dimensioned ancestor.

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

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'

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

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

* 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

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

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

* 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 World Wide Web Consortium

12/6/2004 10:45:25 PM - dmarsh

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 | progress ] ] | inherit CSS 2.1, Section 18.1 the cursor property

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

* CSS1 padding-top is ignored in nested box. Reduced testcase coming from webstandards.org archives! and another reduced testcase here 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 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 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

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

* 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 --DU/GT

CSS Compatibility

Just do a Google search for browser CSS compatibility chart -- Shining Arcanine

* mezzlobue.com has a list of IE CSS deficiencies

* westciv.com has a chart showing IE's deficiencies (and those of other browsers)

* positioniseverything.net has a list of CSS bugs. In particular:

o bug list

o IE primer

o 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 -- Click to read this topic

1/10/2006 1:16:52 PM - dalangalma

DalanGalma

* check out this in Firefox

* and this in IE vs Firefox

* XRay demo (does not work in IE). No The most common client side scripting language implemented in many user agents

7/17/2004 12:42:09 PM - lachlan.hunt

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.0a, Icab 3 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 The most common client side scripting language implemented in many user agents

7/17/2004 12:42:09 PM - lachlan.hunt

JavaScript hacks; relying on The most common client side scripting language implemented in many user agents

7/17/2004 12:42:09 PM - lachlan.hunt

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

* 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 World Wide Web Consortium

12/6/2004 10:45:25 PM - dmarsh

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

* 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 World Wide Web Consortium

12/6/2004 10:45:25 PM - dmarsh

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 What's known about InternetExplorer Version 7

2/1/2006 5:37:45 AM - sbc

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 )

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

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

* 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: add a one or paragraph summary or description of what's discussed here; put yours after 'Summary:'

7/13/2005 10:16:05 PM - Loadsgood

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? What about IE7?

8/30/2004 11:01:44 PM - leonbrooks

IE6 standard and quirk mode, u can see the quirk mode/border-box is complete win the simplification. i want IE6? What about IE7?

8/30/2004 11:01:44 PM - leonbrooks

IE6 standard mode but with border-box model as i can do in mozilla. do it in What's known about InternetExplorer Version 7

2/1/2006 5:37:45 AM - sbc

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|=prefix]), 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. :\

Feeling humiliated yet? Additionally (I know this has nothing to do with Web standards, but still), IE even lacks the basic capacity to display PNG-32 properly, and it can't even display SVG at all! Even M$'s own blog says so.

And I am the troll? Ha! You better think twice before writing down this type of crap again, for you own reputation - or what's left of it.

You've been 0wned, so STFU. :/

[Ultima]

@Dark Shroud: Mmm... yeah... I'm not even sure what an ISP's "html codeing utilities" have to do with "codeing" errors. Notepad, used by a LOT of people for text editing, wasn't made by your ISP, was it? Why do people have to write workaround codes for Internet Explorer if it's working properly? I'm not bashing IE, but just pointing out the fact that your post was extremely uninformed, with the example for which I provided a counterpoint for being the weirdest part of the post. 1c3d0g has some interesting information for you to read up above... And yeah, while this isn't the place for "M$ is teh devil" chit chat, defending Microsoft with baseless, asinine arguments makes you sound like you're praising Microsoft to no end, ignoring its bad sides that are obviously there... unless you're telling us that millions of webmasters are wrong? "M$ is teh god?"

[DonGato]

You might save yourself some future embarrassment. Because weather you like it or not IE 7 is going to make a big impact in its final release.

From that high it will fall?

Anyway, too little too late... or so they say.

We will see what they achieve but I will never return to IE, and less to the crap IE7 is (yes, I tried to use it).

Of course most people will love IE7, and there's nothing wrong with that.

[Firon]

tl;dr

if IE was perfect we wouldn't need this CSS hack on every single page:

<!-- Some IE Fixes, hasLayout declarations, etc -->

    <!--[if IE]><style>

    /* Global styles */
    div#innercontent, div#top, div#hype, div#navi ul, div#navi { height: 1%; }
    div#footer { position: relative; top: -1px; }

    /* Page specific styles */
    div#screenshots { height: 1%; }
    div#rightbox li a { border-bottom: 0; text-decoration: underline; }
    div#centerbox li#changelog a { margin-right: 1.4em; }
    div#rightbox li#archives a { margin-right: 2em; }
    div#innercontent div#rightcontent { float: right; margin: 0 0 0 2em; }

    </style><![endif]-->

</head>

<body>

<!-- IE5.x only fixes -->
<!--[if IE 5]><script type="text/javascript">
    if (document.body.clientWidth >= 990)
    { document.write('<style>div#wrapper { width: 67em; } div#content { margin: 0 1em; }</style>'); }
    else { document.write('<style>div#wrapper { width: 100%; } div#content { margin: 0; }</style>'); }
    document.write('<style>body, p, h3 { margin: 0; } div#innercontent div#screenshots { width: 710px; }</style>');
</script><![endif]-->

[Switeck]

To the original poster:

Almost everwhere I get a chance, I right-click and choose Open in a New Window.

To 1c3d0g:

Thanks for going into such great detail about Microsoft IE's slightly-less-than-perfect support for open standards.

To Firon:

I applaud the effort you go to in making this one of the highest tech-level talk websites on the internet.

[Firon]

What'd I do?

[Switeck]

You're helping save the world

...from ignorance at least

...and possibly even stupidity.

1 post at a time, and by maintaining this message forum.

[Firon]

lol I'm flattered.