Given how much difficulty all the browser vendors (who are working on this full time) have had getting their CSS implementations right, I don't see how we could expect the W3C to make a perfect implementation... Some things are just hard to get right. Dynamic typographic layout of the kind CSS allows is one of them.
If you're watching a movie in 16:9, then you're still experiencing pan-and-scan. Movies are mostly shot in 2.39:1 or 1.85:1, which are both far wider than the so-called "widescreen" 16:9 ratio.
No, that wasn't my point. But I'm tired of making my point over and over again so I'm just going to let the market make my point for me and go back to working on the real solution instead (HTML5).
I'm in the CSS working group, and have been for 6 years (I'm one of the editors of two of the three "High Priority" items on the list you cited). Microsoft are very active. They might not be editors of many drafts today, but that doesn't mean they're not active. (Sadly, the CSS group is one of the many W3C groups that still operate behind closed doors. Hopefully this will change in due course, but anything that involves interacting with the W3C bureaucracy is time consuming, so don't hold your breath.)
If you read the original post in this thread that I responded to, you'll see that I wasn't arguing that Microsoft have never (or will never) abuse their dominant market position. We know they do that, they've been convicted of doing that. What I said was simply that Microsoft was not to blame for the things that are wrong at the W3C, most notably, those that Bjoern mentioned in TFA.
Life isn't like the movies or video games. Companies can be in the wrong in some areas without being the root cause of badness everywhere. Multiple groups of people can be in the wrong in multiple places and at multiple times.
It would have been hard to use XML for CSS, since XML came out in 1998, and CSS came out in 1996.
The grandparent didn't suggest using XML for CSS, but HTML. That's what I was arguing with. Using HTML syntax for CSS makes as much sense as using it for JavaScript. HTML is a tree structure language. CSS isn't a tree -- using a tree structure language for it would be a bad language design decision.
The.NET stuff is the first thing. That's irrelevant, IMHO, to the W3C..NET is like Win32, MacOSX Core APIs, Gtk+, or any number of other OS-specific APIs. It makes no sense for an OS vendor to use the W3C's standards as a base, it has nothing to do with the Web.
The second and third things are the two approaches that were discussed at that landmark workshop: do we throw the baby out with the bathwater and start afresh, or do we build on existing standards. Neither of these approaches implies shutting out new products and innovation, nor do tehy involve preserving the status quo at the expense of new features. The second approach *does* require that we carefully consider extensions so as not to break existing content, but that is just the mature way of doing things -- building standards for the entire planet's emerging electronic communication media is a task that requires us to be responsible.
I still don't know of any browser vendors that wish to stop the specs from evolving. I certainly don't remember that being the message we put forward in our joint presentation at that meeting, and I think the WHATWG work we've done since then is evidence enough that plenty of "innovation" can happen without sacrificing the billions of pages already on the Web.
I can think of very few elements that have been deprecated from HTML and have actually stopped being used. Off-hand I can think of maybe four, and even those, people still use them often enough that browsers have to implement them, and still have to fix bugs with them. Introducing an element that does the same as another element but is not supported in existing browsers would just make life for browser vendors expensive without making the Web a particularly better place.
<blockquote> is a separate element because it has to contain blocks. <blockcode> does not, <blockcode> is only allowed to contain code. Thus <blockcode> is just like a <pre> block that contains code -- <pre><code> -- whereas a <blockquote> is like a quote that contains multiple blocks -- something which you can't do with an inline element like <q>.
The HTML5 spec will (or already does, I forget) say that <pre><code> is how you do a block of code. So it will no longer be a hack, it'll be the rule.
If you have concrete examples of how HTML5 fails to fix HTML's "brokenness", I urge you to send them to the WHATWG list, where they will be taken into consideration. http://www.whatwg.org/mailing-list
Which members want to shut out new products and innovation and simply preserve the status quo? I can't think of a single vendor who has that position, and I've been involved with pretty much all the browser vendors...
CSS is a tree decoration language. HTML is a document tree language. Why would they use the same syntax? That's like saying C++ should use the same syntax as XML. Or that PNG images should use the same syntax as e-mails. You use the right syntax for the job.
We (WHATWG) can't really replace with anything, because is in such heavy use (see http://code.google.com/webstats/2005-12/elements.h tml -- it's the 8th most often-used element, per page). <blockcode> doesn't seem hugely useful either, you can already do it in HTML4 using <pre><code>...</code></pre>.
But if you have any suggestions, please do send them to the WHATWG list -- see http://whatwg.org/mailing-list -- the group is open to all feedback, even if we don't necessarily agree with all of it!:-)
I would just call it a standard and be done with it.;-) It's far more mature than any other W3C document ever released (maybe except the XML 1.1 spec, which isn't bad, all things considered). It's definitely being read by Web browser vendors (including MS) and being treated as the normative reference. The fact that it has the label "Working Draft" is just an artefact of the W3C Process, which, IMHO, is yet another example of a W3C problem.
Everything you've described is completely unrelated to the grievances that Bjoern listed in his mail which was the impetus for the Slashdot posting. I'm not saying that Microsoft is competent at writing browsers that are compliant (heck, just look at the Acid2 test in IE vs any other browser), but I *am* saying that the problems *at the W3C* have nothing to do with Microsoft, and could be solved, regardless of what Microsoft do.
(BTW, in case you think I might be some sort of Microsoft apologist: I think it's pretty clear from my life over the past few years that I'm not on Microsoft's "side" here.)
CSS2.1 went back to working draft because we got some 100 or so comments on it when we last went to CR. If you read Bjoern's original mail, he pointed out that some W3C groups weren't dealing with comments -- well, the CSS group is one of the few groups that _is_, and that's why it's taking a long time for CSS2.1 to be completed. You can't have it both ways: either we listen to your feedback and fix the spec, or we ignore everyone's feedback and make an irrelevant spec.
Microsoft have no part in the running of the W3C Team. If the W3C Team wanted to fix the problems that Bjoern listed, they would not find Microsoft stopping them. Blaming Microsoft for the W3C's problems is ridiculous Slashdot-flamebaiting.
I'm a W3C member, have been for years. Microsoft is not the source of the problems there. The closed-door membership is a problem, but that's not Microsoft's fault. Nor have Microsoft attempted to abuse their position in the W3C in the past decade or so (there was an instance a long time ago, but that was quickly resolved and hasn't happened since). There are plenty of issues at the W3C, but they're not due to MS.
Actually Microsoft take part in several working groups, most notably the CSS working group, and seem to do so in good faith. They play by our extension rules, they are making attempts at fixing their standards compliance bugs, etc. I'm not saying they're perfect, but ever since Firefox showed them their market share wasn't guaranteed, they've become active again and have been acting as reasonably as the other major browser vendors.
"A non-profit organization with a focus on development and maintenance of web standards" is exactly what W3C staff think the W3C is. What would prevent the staff of a new organisation from ending up in the same state?
Slashdot Mirror
Given how much difficulty all the browser vendors (who are working on this full time) have had getting their CSS implementations right, I don't see how we could expect the W3C to make a perfect implementation... Some things are just hard to get right. Dynamic typographic layout of the kind CSS allows is one of them.
If you're watching a movie in 16:9, then you're still experiencing pan-and-scan. Movies are mostly shot in 2.39:1 or 1.85:1, which are both far wider than the so-called "widescreen" 16:9 ratio.
Also as I understand it Apple didn't "steal" the ideas from Xerox, they licensed them from Xerox.
No, that wasn't my point. But I'm tired of making my point over and over again so I'm just going to let the market make my point for me and go back to working on the real solution instead (HTML5).
Now try adding conformant XForms to http://www.microsoft.com/ and load the page in IE.
I'm in the CSS working group, and have been for 6 years (I'm one of the editors of two of the three "High Priority" items on the list you cited). Microsoft are very active. They might not be editors of many drafts today, but that doesn't mean they're not active. (Sadly, the CSS group is one of the many W3C groups that still operate behind closed doors. Hopefully this will change in due course, but anything that involves interacting with the W3C bureaucracy is time consuming, so don't hold your breath.)
If you read the original post in this thread that I responded to, you'll see that I wasn't arguing that Microsoft have never (or will never) abuse their dominant market position. We know they do that, they've been convicted of doing that. What I said was simply that Microsoft was not to blame for the things that are wrong at the W3C, most notably, those that Bjoern mentioned in TFA.
Life isn't like the movies or video games. Companies can be in the wrong in some areas without being the root cause of badness everywhere. Multiple groups of people can be in the wrong in multiple places and at multiple times.
It would have been hard to use XML for CSS, since XML came out in 1998, and CSS came out in 1996.
The grandparent didn't suggest using XML for CSS, but HTML. That's what I was arguing with. Using HTML syntax for CSS makes as much sense as using it for JavaScript. HTML is a tree structure language. CSS isn't a tree -- using a tree structure language for it would be a bad language design decision.
You're confusing three things here.
.NET stuff is the first thing. That's irrelevant, IMHO, to the W3C. .NET is like Win32, MacOSX Core APIs, Gtk+, or any number of other OS-specific APIs. It makes no sense for an OS vendor to use the W3C's standards as a base, it has nothing to do with the Web.
The
The second and third things are the two approaches that were discussed at that landmark workshop: do we throw the baby out with the bathwater and start afresh, or do we build on existing standards. Neither of these approaches implies shutting out new products and innovation, nor do tehy involve preserving the status quo at the expense of new features. The second approach *does* require that we carefully consider extensions so as not to break existing content, but that is just the mature way of doing things -- building standards for the entire planet's emerging electronic communication media is a task that requires us to be responsible.
I still don't know of any browser vendors that wish to stop the specs from evolving. I certainly don't remember that being the message we put forward in our joint presentation at that meeting, and I think the WHATWG work we've done since then is evidence enough that plenty of "innovation" can happen without sacrificing the billions of pages already on the Web.
I can think of very few elements that have been deprecated from HTML and have actually stopped being used. Off-hand I can think of maybe four, and even those, people still use them often enough that browsers have to implement them, and still have to fix bugs with them. Introducing an element that does the same as another element but is not supported in existing browsers would just make life for browser vendors expensive without making the Web a particularly better place.
<blockquote> is a separate element because it has to contain blocks. <blockcode> does not, <blockcode> is only allowed to contain code. Thus <blockcode> is just like a <pre> block that contains code -- <pre><code> -- whereas a <blockquote> is like a quote that contains multiple blocks -- something which you can't do with an inline element like <q>.
The HTML5 spec will (or already does, I forget) say that <pre><code> is how you do a block of code. So it will no longer be a hack, it'll be the rule.
If you have concrete examples of how HTML5 fails to fix HTML's "brokenness", I urge you to send them to the WHATWG list, where they will be taken into consideration. http://www.whatwg.org/mailing-list
Yeah, Zeldman is exaggerating. Bjoern isn't. And what Bjoern wrote is far more damning than what Zeldman wrote.
Which members want to shut out new products and innovation and simply preserve the status quo? I can't think of a single vendor who has that position, and I've been involved with pretty much all the browser vendors...
CSS is a tree decoration language. HTML is a document tree language. Why would they use the same syntax? That's like saying C++ should use the same syntax as XML. Or that PNG images should use the same syntax as e-mails. You use the right syntax for the job.
Ruby is in XHTML 1.1 as well (and IE supports it in HTML4, even). HTML5 will probably have ruby support in the spec.
HTML5 already has <section>.
(where "HTML5" is the name of the WHATWG language)
We (WHATWG) can't really replaceh tml -- it's the 8th most often-used element, per page). <blockcode> doesn't seem hugely useful either, you can already do it in HTML4 using <pre><code>...</code></pre>.
:-)
with anything, because
is in such heavy use (see http://code.google.com/webstats/2005-12/elements.
But if you have any suggestions, please do send them to the WHATWG list -- see http://whatwg.org/mailing-list -- the group is open to all feedback, even if we don't necessarily agree with all of it!
I would just call it a standard and be done with it. ;-) It's far more mature than any other W3C document ever released (maybe except the XML 1.1 spec, which isn't bad, all things considered). It's definitely being read by Web browser vendors (including MS) and being treated as the normative reference. The fact that it has the label "Working Draft" is just an artefact of the W3C Process, which, IMHO, is yet another example of a W3C problem.
Everything you've described is completely unrelated to the grievances that Bjoern listed in his mail which was the impetus for the Slashdot posting. I'm not saying that Microsoft is competent at writing browsers that are compliant (heck, just look at the Acid2 test in IE vs any other browser), but I *am* saying that the problems *at the W3C* have nothing to do with Microsoft, and could be solved, regardless of what Microsoft do.
(BTW, in case you think I might be some sort of Microsoft apologist: I think it's pretty clear from my life over the past few years that I'm not on Microsoft's "side" here.)
CSS2.1 went back to working draft because we got some 100 or so comments on it when we last went to CR. If you read Bjoern's original mail, he pointed out that some W3C groups weren't dealing with comments -- well, the CSS group is one of the few groups that _is_, and that's why it's taking a long time for CSS2.1 to be completed. You can't have it both ways: either we listen to your feedback and fix the spec, or we ignore everyone's feedback and make an irrelevant spec.
Microsoft have no part in the running of the W3C Team. If the W3C Team wanted to fix the problems that Bjoern listed, they would not find Microsoft stopping them. Blaming Microsoft for the W3C's problems is ridiculous Slashdot-flamebaiting.
I'm a W3C member, have been for years. Microsoft is not the source of the problems there. The closed-door membership is a problem, but that's not Microsoft's fault. Nor have Microsoft attempted to abuse their position in the W3C in the past decade or so (there was an instance a long time ago, but that was quickly resolved and hasn't happened since). There are plenty of issues at the W3C, but they're not due to MS.
Actually Microsoft take part in several working groups, most notably the CSS working group, and seem to do so in good faith. They play by our extension rules, they are making attempts at fixing their standards compliance bugs, etc. I'm not saying they're perfect, but ever since Firefox showed them their market share wasn't guaranteed, they've become active again and have been acting as reasonably as the other major browser vendors.
Note that the WHATWG doesn't have membership in the W3C, which is what the grandparent was suggesting.
"A non-profit organization with a focus on development and maintenance of web standards" is exactly what W3C staff think the W3C is. What would prevent the staff of a new organisation from ending up in the same state?
Microsoft have absolutely nothing to do with any of the problems that are listed in the article.
People actually see lilo's spam? Wow, I figured everyone had him on /ignore by now. Isn't that the first thing one does when connecting to freenode?