Slashdot Mirror

Define standard.

Some counter arguments:
http://www.osnews.com/thread?458060

"What you perhaps actually mean is that WebM is a standard that is not yet endorsed by any official independent standards body."

According to Wikipedia (http://en.wikipedia.org/wiki/Technical_standard):

"A technical standard may be developed privately or unilaterally, for example by a corporation, regulatory body, military, etc."

H.264 is not a standard acceptable by the W3c http://my.opera.com/haavard/blog/2011/01/13/openness

And finally:
http://annevankesteren.nl/2011/01/why-webm

"And lets face it, WebM has a specification, independent implementations, backing from hardware manufacturers, and is supported in all browsers that are not MPEG LA H.264 patent licensor — once Firefox 4 is released that makes about sixty percent of the desktop browser market."

And if you don't believe me, check out this wonderful document penned by none other than Bill Gates himself:

One thing we have got to change in our strategy -- allowing Office documents to be rendered very well by other peoples browsers is one of the most destructive things we could do to the company.

We have to stop putting any effort into this and make sure that Office documents very well depends on PROPRIETARY IE capabilities.

HA! Caught them red handed! Oh wait thats from 10 years ago....

I don't get it. Why is everyone so surprised by this? Microsoft has been the biggest consumer of their own non-standard web technologies in both an effort to tie services to Windows and to convince other web developers to use their 'neato' technologies.

Has no one ever noticed that Microsoft.com had various effects, direct system access, and other features not found anywhere else on the web? Or that Windows Update only worked through Internet Explorer? Microsoft WANTS to be as non-standard as possible. And if you don't believe me, check out this wonderful document penned by none other than Bill Gates himself:

One thing we have got to change in our strategy -- allowing Office documents to be rendered very well by other peoples browsers is one of the most destructive things we could do to the company.

We have to stop putting any effort into this and make sure that Office documents very well depends on PROPRIETARY IE capabilities.

In particular, I'm looking for something that goes like "IE8 implements x, y and z, but it implements y wrong, and still doesn't implement important standards a, b and c.".

I thought you asked for a rant? ;-)

Getting a comprehensive list of features support/not supported is hard given the scope of what a browser encompasses. You could use a tool like wttjs to test against the HTML5 WebIDL, but the output might be a bit more than you're looking for. From my perspective I'm worried about the big stuff that makes projects possible/not possible. So from my perspective, it's:

- No DOM2 Events support (Bug closed as "By Design")
- No CSS Opacity support (Bug closed as "By Design") and IE filter syntax is changed
- No SVG support
- HTML5 localStorage implementation is wrong
- Cross-Document messaging is wrong (lack of DOM2 Events here)
- A new Cross Domain XML Request object that incompatibly ignores the existing HTML5 work
- No Canvas support (not required, but pisses me off when they are supposedly adding HTML5 support)
- CSS is only slightly less borked. I defer to the earlier link for a description of this issue.

Here's a few articles covering these items and more:
http://annevankesteren.nl/2008/03/ie8-bad
http://annevankesteren.nl/2008/10/ie8-bad-update
http://annevankesteren.nl/2009/01/gettters-setters
http://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=333958
http://webbugtrack.blogspot.com/

As an aside, make sure you read this:
http://annevankesteren.nl/2008/03/office-sucks

I'd go digging for more, but I'm afraid I don't have the time right now. Hopefully those links will get you started! :-)

By the way, I see you're also using the ACID3 test to make a point. You shouldn't. While ACID2 was very relevant in how it tested standards everyone was asking for, ACID3 is content testing for little very specific rendering bugs in various rendering engines and CSS3 (which isn't even a standard yet!).

That's a fair argument. Mostly lack of ACID3 compliance is just more to be annoyed about. Other browsers have extremely high scores on these tests while IE manages a paltry 20/100. I wouldn't care so much if IE wasn't such a piece of crap in other areas, but it is. So if anyone brings up ACID3, I get to complain that it is also terrible there too. :-P

In particular, I'm looking for something that goes like "IE8 implements x, y and z, but it implements y wrong, and still doesn't implement important standards a, b and c.".

I thought you asked for a rant? ;-)

Getting a comprehensive list of features support/not supported is hard given the scope of what a browser encompasses. You could use a tool like wttjs to test against the HTML5 WebIDL, but the output might be a bit more than you're looking for. From my perspective I'm worried about the big stuff that makes projects possible/not possible. So from my perspective, it's:

- No DOM2 Events support (Bug closed as "By Design")
- No CSS Opacity support (Bug closed as "By Design") and IE filter syntax is changed
- No SVG support
- HTML5 localStorage implementation is wrong
- Cross-Document messaging is wrong (lack of DOM2 Events here)
- A new Cross Domain XML Request object that incompatibly ignores the existing HTML5 work
- No Canvas support (not required, but pisses me off when they are supposedly adding HTML5 support)
- CSS is only slightly less borked. I defer to the earlier link for a description of this issue.

Here's a few articles covering these items and more:
http://annevankesteren.nl/2008/03/ie8-bad
http://annevankesteren.nl/2008/10/ie8-bad-update
http://annevankesteren.nl/2009/01/gettters-setters
http://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=333958
http://webbugtrack.blogspot.com/

As an aside, make sure you read this:
http://annevankesteren.nl/2008/03/office-sucks

I'd go digging for more, but I'm afraid I don't have the time right now. Hopefully those links will get you started! :-)

By the way, I see you're also using the ACID3 test to make a point. You shouldn't. While ACID2 was very relevant in how it tested standards everyone was asking for, ACID3 is content testing for little very specific rendering bugs in various rendering engines and CSS3 (which isn't even a standard yet!).

That's a fair argument. Mostly lack of ACID3 compliance is just more to be annoyed about. Other browsers have extremely high scores on these tests while IE manages a paltry 20/100. I wouldn't care so much if IE wasn't such a piece of crap in other areas, but it is. So if anyone brings up ACID3, I get to complain that it is also terrible there too. :-P

In particular, I'm looking for something that goes like "IE8 implements x, y and z, but it implements y wrong, and still doesn't implement important standards a, b and c.".

I thought you asked for a rant? ;-)

Getting a comprehensive list of features support/not supported is hard given the scope of what a browser encompasses. You could use a tool like wttjs to test against the HTML5 WebIDL, but the output might be a bit more than you're looking for. From my perspective I'm worried about the big stuff that makes projects possible/not possible. So from my perspective, it's:

- No DOM2 Events support (Bug closed as "By Design")
- No CSS Opacity support (Bug closed as "By Design") and IE filter syntax is changed
- No SVG support
- HTML5 localStorage implementation is wrong
- Cross-Document messaging is wrong (lack of DOM2 Events here)
- A new Cross Domain XML Request object that incompatibly ignores the existing HTML5 work
- No Canvas support (not required, but pisses me off when they are supposedly adding HTML5 support)
- CSS is only slightly less borked. I defer to the earlier link for a description of this issue.

Here's a few articles covering these items and more:
http://annevankesteren.nl/2008/03/ie8-bad
http://annevankesteren.nl/2008/10/ie8-bad-update
http://annevankesteren.nl/2009/01/gettters-setters
http://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=333958
http://webbugtrack.blogspot.com/

As an aside, make sure you read this:
http://annevankesteren.nl/2008/03/office-sucks

I'd go digging for more, but I'm afraid I don't have the time right now. Hopefully those links will get you started! :-)

By the way, I see you're also using the ACID3 test to make a point. You shouldn't. While ACID2 was very relevant in how it tested standards everyone was asking for, ACID3 is content testing for little very specific rendering bugs in various rendering engines and CSS3 (which isn't even a standard yet!).

That's a fair argument. Mostly lack of ACID3 compliance is just more to be annoyed about. Other browsers have extremely high scores on these tests while IE manages a paltry 20/100. I wouldn't care so much if IE wasn't such a piece of crap in other areas, but it is. So if anyone brings up ACID3, I get to complain that it is also terrible there too. :-P

In particular, I'm looking for something that goes like "IE8 implements x, y and z, but it implements y wrong, and still doesn't implement important standards a, b and c.".

I thought you asked for a rant? ;-)

Getting a comprehensive list of features support/not supported is hard given the scope of what a browser encompasses. You could use a tool like wttjs to test against the HTML5 WebIDL, but the output might be a bit more than you're looking for. From my perspective I'm worried about the big stuff that makes projects possible/not possible. So from my perspective, it's:

- No DOM2 Events support (Bug closed as "By Design")
- No CSS Opacity support (Bug closed as "By Design") and IE filter syntax is changed
- No SVG support
- HTML5 localStorage implementation is wrong
- Cross-Document messaging is wrong (lack of DOM2 Events here)
- A new Cross Domain XML Request object that incompatibly ignores the existing HTML5 work
- No Canvas support (not required, but pisses me off when they are supposedly adding HTML5 support)
- CSS is only slightly less borked. I defer to the earlier link for a description of this issue.

Here's a few articles covering these items and more:
http://annevankesteren.nl/2008/03/ie8-bad
http://annevankesteren.nl/2008/10/ie8-bad-update
http://annevankesteren.nl/2009/01/gettters-setters
http://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=333958
http://webbugtrack.blogspot.com/

As an aside, make sure you read this:
http://annevankesteren.nl/2008/03/office-sucks

I'd go digging for more, but I'm afraid I don't have the time right now. Hopefully those links will get you started! :-)

By the way, I see you're also using the ACID3 test to make a point. You shouldn't. While ACID2 was very relevant in how it tested standards everyone was asking for, ACID3 is content testing for little very specific rendering bugs in various rendering engines and CSS3 (which isn't even a standard yet!).

That's a fair argument. Mostly lack of ACID3 compliance is just more to be annoyed about. Other browsers have extremely high scores on these tests while IE manages a paltry 20/100. I wouldn't care so much if IE wasn't such a piece of crap in other areas, but it is. So if anyone brings up ACID3, I get to complain that it is also terrible there too. :-P

The 2022 date is effectively meaningless. That is when every single minute edge case in the specification has been proven to be worked out, and implemented in an exactly identical manner by at least two browsers. (Hint: at present there isn't a single W3C specification which has reached this point.)

What matters to all of us is when we can start using features from HTML 5. This is roughly from Last Call, which is hoped to be reached next year.

See also these posts by Anne van Kesteren: Re: 2022 and Meaning of "recommendation".

The 2022 date is effectively meaningless. That is when every single minute edge case in the specification has been proven to be worked out, and implemented in an exactly identical manner by at least two browsers. (Hint: at present there isn't a single W3C specification which has reached this point.)

What matters to all of us is when we can start using features from HTML 5. This is roughly from Last Call, which is hoped to be reached next year.

See also these posts by Anne van Kesteren: Re: 2022 and Meaning of "recommendation".

"There are quite a few good things about the Microsoft release, such as showing that HTML5 is looked at, Acid2 is (almost) being passed, and CSS support is improving, but there are quite a few evil things as well"

http://annevankesteren.nl/2008/03/ie8-bad

And did you read the actual comments to that A List Apart article? Almost every single one of them rejected the proposal. In fact, both Opera, Mozilla, Apple and Google have rejected it. As well as most web developers who have spoken up.

If you would only educate yourself instead of spouting uneducated nonsense...

Yes. In fact, that is exactly what is happening at the moment. At least the vocal majority is in utter opposition. See the IE Blog.

Also:

• Eric Meyer's follow up post
• WaSP response
• Discussion which includes a disclaim of official endorsement by Andy Clarke, co-lead of WaSP

I am calling on the development community for solid alternative proposals:

Alternatives NOW!

Yes. In fact, that is exactly what is happening at the moment. At least the vocal majority is in utter opposition. See the IE Blog.

Also:

• Eric Meyer's follow up post
• WaSP response
• Discussion which includes a disclaim of official endorsement by Andy Clarke, co-lead of WaSP

I am calling on the development community for solid alternative proposals:

Alternatives NOW!

You could still do versioning by using as I explain above.

There's no versioning problem. We will never require UAs to do different things based on what version of HTML they find a page claiming to use. It's bad enough that UAs have been forced into quirks vs standards mode versioning. - Ian Hicks

the OpenGL API for the Canvas tag that the WHATWG has been working on

Only a minor point to clarify, but the WHATWG hasn't been working on the OpenGL API, and the 2D canvas (which it has worked on, and which has been implemented) isn't designed to be hardware-accelerated. Some Firefox and Opera developers have been experimenting with exposing OpenGL ES, and it seems likely that they will propose it in the WHATWG at some point to get standardisation, but that hasn't happened yet and it isn't much of a priority, and I expect it will take quite a while to get it sorted out.

(I've done some work with pseudo-3D in the 2D canvas, which is kind of slow, so I'm quite interested in how it's going to progress in the future.)

Yes, Microsoft is definitely the ball and chain that holds progress back - but at least they have joined the HTML Working Group.

Microsoft also invited Opera devs for the same reason that they've invited FF devs (to make sure the browser runs well in Vista, and possibly makes use of some new Vista apis (e.g. Vista's Common RSS api)). Opera accepted the invitation and Opera devs paid their visit to MS last week.
http://annevankesteren.nl/2006/08/opera-vista
http://my.opera.com/olli/blog/show.dml/417961

The Opera devs returned unharmed. ;-)

Other links: http://operawatch.com/news/2006/08/opera-visits-mi crosoft-in-preparation-for-windows-vista.html http://annevankesteren.nl/2006/08/opera-vista

One can discuss whether or not IEs supports this feature or that it is just a bug, as it allows you to assign width and height to any inline element . In my experience the rendering of inline-block hasn't been consistent between the different browsers, this might have changed since I last tested.

Technically CSS2.1 is still a working draft, it was pulled back to working draf on June 13, 2005 after it was had been Candidate Recommendation since February 25, 2004. You can read more about this in Anne van Kesteren's blog

HTML 5 is currently the spec. being worked on by WHATWG. You can read more about it courtesy of Anne van Kesteren.

This is the poorest excuse for an article I've seen on Slashdot in a while. Not only is it a rehash of an argument that's been going on for years, it doesn't even get its facts straight regarding the ACID2 test.

Opera9 isn't the only browser to pass the ACID2 test. Hell, it's not even the first.

Safari passed on April 27, 2005:
http://weblogs.mozillazine.org/hyatt/archives/2005 _04.html#008042

iCab passed in June, 2005, followed closely by Konqueror:
http://www.webstandards.org/2005/06/07/icab-konque ror-pass-acid2/

Beta builds of Opera were next on March 28, 2006:
http://www.webstandards.org/2006/03/28/acid2-suppo rted-in-opera-one-year-later/

A development branch of Firefox showed compliance on April 13, 2006:
http://www.thinklemon.com/weblog/2006/04/13/firefo x-acid2-compliance-on-its-way/

The funniest one is that someone cheated and got Firefox to pass last May:
http://annevankesteren.nl/2005/05/greasemonkey

The key phrases here are 'claim' and 'their platform'. What about cross platform web applications I ask you?!

"which they claim will greatly reduce the effort in developing AJAX style applications on their platform."

How about ACID2 complicance in IE7 or implementing the features developers are asking for:

http://annevankesteren.nl/2005/03/ie7-wishlist
http://news.com.com/Next+Explorer+to+fail+Acid+tes t/2100-1032_3-5813897.html
http://blogs.msdn.com/ie/archive/2005/03/09/391362 .aspx

No. is implied until you get to - see http://annevankesteren.nl for a valid HTML page with a <title> and no <head>.

http://www.w3.org/TR/CSS21/about.html#q1
http://annevankesteren.nl/2005/06/css-21

CSS 2.1 is in nearly-done stage I think. At least IE devs can start working on it already...

Yours is a good point, though I'm not too big of a fan of forcing every page I write to be parsed with an engine first. (and no, I don't have access to the apache server httpd.conf/.htaccess file :( )

However, I did come across this little beauty that gives me a little hope. It seems you can indeed serve xhtml as application/xml in IE and make it work (of course, with a small workaround).

Soon of course, lynx will have to be updated in order to keep up with the times :)

They could use MIME type switching though. If they actually cared. Which I'm quite certain they don't.

Are you trying to imply that the thousands of XHTML Strict websites out there produced by web/graphic designers, web developers, bloggers, and those who are supporting the standards are doing something wrong?

Yup. Check out Ian Hickson's "Sending XHTML as text/html Considered Harmful" for a quick primer on what most sites that do XHTML are doing wrong. Check out Evan Goer's list of "X-Philes" for a list of the very few sites which get it right, and his purge of sites from that list for an indication of how easy it is to go wrong even after you've initially gotten it right.

As for HTML generally not producing good markup and being "too loose", I hate to break it to you but XHTML 1.0 and HTML 4.01 are element-for-element identical; the only difference between the two is that one is an SGML application and one is an XML application. And when you serve XHTML 1.0 as "text/html" (e.g., when you do XHTML the way ESPN and others do) you don't gain any of the strictness benefits of XML. And the only thing XHTML 1.1 does on top of that is deprecate a couple more things and add modularization and ruby support, so I'm really not sure where all the "good markup" would come from in a transition to XHTML. Plus there's no reason to believe that serving XHTML 1.1 as "text/html" is conformant, so if you use 1.1 you either break the spec or you shut out IE. Likewise, switching to an XHTML DOCTYPE and using XML syntax doesn't magically confer accessibility on a page; it's just as easy to write a horrid, bloated, table-based images-for-everything page in XHTML as it is in HTML 4.01.

I suspect that you're making a common mistake among people who've just discovered web standards: you're confusing XHTML with good markup and best practices (check out Molly Holzschlag on what standards are and aren't). Anyway, it's quite possible to write beautiful, clean, accessible, semantically rich HTML 4.01 with separation of content from presentation; after all, it's got the same set of tags and attributes as XHTML 1.0, so if you can do it in one you can do it in the other just as easily. And when you consider that serving valid, well-formed XHTML according to the spec can be a nightmare at times, it's no surprise that even "gurus" of the standards world (e.g., Mark Pilgrim, Anne van Kesteren) have gone back to or recommended sticking with HTML 4.01 unless you really need one of the features gained by an XML-based HTML.

And lest you continue to think I'm some sort of skeptic or enemey of web standards, well, every site I've built in the past three years (basically, since I discovered there was such a thing as a "web standard") has been valid, accessible, and CSS-based. I just know from experience that valid markup and stylesheets are one part of the equation, and there are an awful lot of those "best practices" that aren't ever published in a spec from the W3C or anyone else.

Are you trying to imply that the thousands of XHTML Strict websites out there produced by web/graphic designers, web developers, bloggers, and those who are supporting the standards are doing something wrong?

Yup. Check out Ian Hickson's "Sending XHTML as text/html Considered Harmful" for a quick primer on what most sites that do XHTML are doing wrong. Check out Evan Goer's list of "X-Philes" for a list of the very few sites which get it right, and his purge of sites from that list for an indication of how easy it is to go wrong even after you've initially gotten it right.

As for HTML generally not producing good markup and being "too loose", I hate to break it to you but XHTML 1.0 and HTML 4.01 are element-for-element identical; the only difference between the two is that one is an SGML application and one is an XML application. And when you serve XHTML 1.0 as "text/html" (e.g., when you do XHTML the way ESPN and others do) you don't gain any of the strictness benefits of XML. And the only thing XHTML 1.1 does on top of that is deprecate a couple more things and add modularization and ruby support, so I'm really not sure where all the "good markup" would come from in a transition to XHTML. Plus there's no reason to believe that serving XHTML 1.1 as "text/html" is conformant, so if you use 1.1 you either break the spec or you shut out IE. Likewise, switching to an XHTML DOCTYPE and using XML syntax doesn't magically confer accessibility on a page; it's just as easy to write a horrid, bloated, table-based images-for-everything page in XHTML as it is in HTML 4.01.

I suspect that you're making a common mistake among people who've just discovered web standards: you're confusing XHTML with good markup and best practices (check out Molly Holzschlag on what standards are and aren't). Anyway, it's quite possible to write beautiful, clean, accessible, semantically rich HTML 4.01 with separation of content from presentation; after all, it's got the same set of tags and attributes as XHTML 1.0, so if you can do it in one you can do it in the other just as easily. And when you consider that serving valid, well-formed XHTML according to the spec can be a nightmare at times, it's no surprise that even "gurus" of the standards world (e.g., Mark Pilgrim, Anne van Kesteren) have gone back to or recommended sticking with HTML 4.01 unless you really need one of the features gained by an XML-based HTML.

And lest you continue to think I'm some sort of skeptic or enemey of web standards, well, every site I've built in the past three years (basically, since I discovered there was such a thing as a "web standard") has been valid, accessible, and CSS-based. I just know from experience that valid markup and stylesheets are one part of the equation, and there are an awful lot of those "best practices" that aren't ever published in a spec from the W3C or anyone else.

Are you trying to imply that the thousands of XHTML Strict websites out there produced by web/graphic designers, web developers, bloggers, and those who are supporting the standards are doing something wrong?

Yup. Check out Ian Hickson's "Sending XHTML as text/html Considered Harmful" for a quick primer on what most sites that do XHTML are doing wrong. Check out Evan Goer's list of "X-Philes" for a list of the very few sites which get it right, and his purge of sites from that list for an indication of how easy it is to go wrong even after you've initially gotten it right.

As for HTML generally not producing good markup and being "too loose", I hate to break it to you but XHTML 1.0 and HTML 4.01 are element-for-element identical; the only difference between the two is that one is an SGML application and one is an XML application. And when you serve XHTML 1.0 as "text/html" (e.g., when you do XHTML the way ESPN and others do) you don't gain any of the strictness benefits of XML. And the only thing XHTML 1.1 does on top of that is deprecate a couple more things and add modularization and ruby support, so I'm really not sure where all the "good markup" would come from in a transition to XHTML. Plus there's no reason to believe that serving XHTML 1.1 as "text/html" is conformant, so if you use 1.1 you either break the spec or you shut out IE. Likewise, switching to an XHTML DOCTYPE and using XML syntax doesn't magically confer accessibility on a page; it's just as easy to write a horrid, bloated, table-based images-for-everything page in XHTML as it is in HTML 4.01.

I suspect that you're making a common mistake among people who've just discovered web standards: you're confusing XHTML with good markup and best practices (check out Molly Holzschlag on what standards are and aren't). Anyway, it's quite possible to write beautiful, clean, accessible, semantically rich HTML 4.01 with separation of content from presentation; after all, it's got the same set of tags and attributes as XHTML 1.0, so if you can do it in one you can do it in the other just as easily. And when you consider that serving valid, well-formed XHTML according to the spec can be a nightmare at times, it's no surprise that even "gurus" of the standards world (e.g., Mark Pilgrim, Anne van Kesteren) have gone back to or recommended sticking with HTML 4.01 unless you really need one of the features gained by an XML-based HTML.

And lest you continue to think I'm some sort of skeptic or enemey of web standards, well, every site I've built in the past three years (basically, since I discovered there was such a thing as a "web standard") has been valid, accessible, and CSS-based. I just know from experience that valid markup and stylesheets are one part of the equation, and there are an awful lot of those "best practices" that aren't ever published in a spec from the W3C or anyone else.

Gee, why are the pages so small? The printer version is much easier to read. Anyway, for the latest word on mozilla's support of css3, don't miss Anne Van Kesteren's report available since Wednesday May 19th, 2004.