It’s just data

Co-Chair HTML WG

Michael(tm) Smith: effective January 5, there will be a change in the leadership for the HTML Working Group. Sam Ruby has been appointed as a new co-chair by the W3C Director, Tim Berners-Lee, and will be joining Chris Wilson in that role next month; at that time, I’ll be returning to my previous role as the W3C staff contact for the group.

While my primary focus will be inward, let me first get something out of the way: I’ve talked to Steve Holbrook (IBM’s AC representative) and Roland Merrick (XHTML2 co-chair) and each of us personally would like to see the XHTML2 and HTML groups brought together or at least the overlaps removed.

I’m not overly concerned about events, access keys, or even an additional forms model.  If these efforts seek to address different requirements, they can attract their own constituencies.  Or not.  In any case, the web is a big place.

No, my concern is the active development of two incompatible vocabularies being served with the same media type and being defined in the same XML namespace.  A difference in DOCTYPE does not address my concern.


submitted by gthank [link] [0 comments]...

Excerpt from programming: what's new online at

I agree that having the XHTML2 WG continue with development of a replacement XHTML vocabulary while using the same namespace isn’t optimal, but until now, we’ve successfully dealt with the issue by ignoring them.  Besides, their current WD uses “http://www.w3.org/2002/06/xhtml2/” as their namespace anyway.  Although I suspect that’s a temporary namespace for use just while it’s a draft, they can just mint a new ns like “http://www.w3.org/ns/xhtml2”

The MIME type isn’t such a big deal.  In practice, it’s just another XML MIME type and it doesn’t matter that much whether they use application/xml, application/xhtml+xml or create a new one for XHTML2.

Posted by Lachlan Hunt at

Ah, I hadn’t noticed the different namespace.  Thanks!

Posted by Sam Ruby at

“I’ve talked to Steve Holbrook (IBM’s AC representative) and Roland Merrick (XHTML2 co-chair) and each of personally would like to see the XHTML2 and HTML groups brought together or at least the overlaps removed.”

Damn straight. This XHTML2 as compared to XHTML5 nonsense serves no one.

Posted by Shelley at

PS Congratulations. Should be interesting times in the HTML working group.

Posted by Shelley at

Movement at the Station

Sam Ruby has been appointed as Co-Chair of the W3C HTML working group Sam will take over from Mike Smith early 2009, Mike will move back to his old position of staff contact. Rumblings from the intellectual bowels of a number of WHAT WG teamsters...

Excerpt from Last Week in HTML5 at

At some point in 2007, the XHTML2 WG decided that they’d going to use the original XHTML namespace (this must be in one of their meeting minutes). I haven’t heard yet that they reversed that one.

What concerns me more right now is XHTML2+RDFa imposing a new syntax (Curie) on @rel attributes. This is another area where coordination with HTML5 is needed; hopefully we can make some progress on RDFa-in-HTML soonish...

Posted by Julian Reschke at

From XHTML2 3 Oct 2007 minutes:

RESOLUTION: as earlier resolved XHTML family languages should be served as application/+xml

and

SP: ok to use 1999 namespace in XHTML2, but there are others who don’t want us to use it

Frankly, that combination concerns me.

Posted by Sam Ruby at

I can’t think of a better person to help guide the future…

I can’t think of a better person to help guide the future of HTML: Sam Ruby has been appointed as a new co-chair [of the HTML Working Group] by the W3C Director, Tim Berners-Lee...

Excerpt from Justinsomnia at

old skool teamster style

You’ve got IRC Hixie: rubys: if you’re around, someone was asking a question about your blog entry in #whatwg earlier read it Mr Subtlety Fucker jacobolus: what would this mean, practically? "each of us personally would like to see the XHTML2 and...

Excerpt from Last Week in HTML5 at

FWIW, the Editor’s Draft of XHTML 2.0 has used the standard XHTML namespace for over a year.  See [link]

Posted by Dave H at

Drafts => XHTML2 => 20071024 => XHTML Document Module =>

the value of the xmlns declaration is defined to be “http://www.w3.org/1999/xhtml”

Posted by Sam Ruby at

Congratulations, Sam! Congratulations, HTML WG! This is just the vitamin injection the HTML WG needs. The timing is perfect. I just hope you find time to consume the vast amount of information flowing through the mailing list and staying on top of it all. Chris Wilson has not been on top ever since he started, it seems. Understandably, but unfortunate nonetheless.

Posted by Asbjørn Ulsberg at

Interesting enough, the 20071024 draft of XHTML2 defines @rel to be a QName, which is both incompatible with HTML (making the interpretation depend on namespace declarations) and RDFa-in-XHTML (where it is defined to be a Curie).

Posted by Julian Reschke at

I want to steer clear of discussions as to whether XHTML2 is a good idea or not.  Questions as to whether XHTML2 is backwards compatible or not clearly are of that nature.

The question I want to focus on is whether or not there is overlap.  I actually heard an unchallenged statement that there was no overlap.  My recommendation is that there not be overlap, but even if that recommendation is not adopted, I want that to be an explicit decision made with full appreciation of the fact that there is overlap.

I continue to assert that two editors drafts from separate W3C working groups defining incompatible vocabularies with the same namespace and mime type constitutes overlap.

Posted by Sam Ruby at

Right and if, instead of overloading the existing xhtml namespace we have separate namespaces for HTML5 and XHTML2, some of us can continue using XHTML 1.0 and just namespace any new elements.

Posted by yup at

Links for 2008-12-15 [del.icio.us]

Co-Chair HTML WG "Michael(tm) Smith: effective January 5, there will be a change in the leadership for the HTML Working Group. Sam Ruby has been appointed as a new co-chair by the W3C Director, Tim Berners-Lee, and will be joining Chris Wilson...

Excerpt from techno.blog("Dion") at

Sam RubyがHTML WGのCo-chairに

びっくりなニュースですねー “Sam Ruby appointed co-chair for HTML Working Group, effective January 5” “Co-Chair HTML WG” やー、どうなるんでしょう。 While my primary focus will be inward, let me first get something out of the way: I’ve talked to Steve Holbrook...

Excerpt from vantguarde at

I want to steer clear of discussions as to whether XHTML2 is a good idea or not.  Questions as to whether XHTML2 is backwards compatible or not clearly are of that nature.

I don’t really follow. Whether XHTML2 (or indeed HTML5) is backwards compatible is only a “good idea” type question if you necessarily ascribe some absolute virtue to backwards compatibility (rather than allowing, for example, that the merits might be context-dependent). On the other hand, determining the level of compatibility seems essential in making logical decisions about potential areas of overlap such as reuse of an existing namespace URI (something that is essential in a language that aims for backwards compatibility but not in one that does not).

Posted by jgraham at

My focus is on HTML5.  Another way of saying this is that I don’t consider comparisons between any other pair of vocabularies particularly relevant.

Neither HTML5 and XHTML2 permit acronym in conformant documents.  One could say that neither are completely backwards compatible with HTML4.  That’s OK.

The definition of the rel attribute is different in the XHTML2 and HTML5 drafts that exist today.  As two actively developed vocabularies which make use of the same mime type and DOM namespace, this is something that I considered cause for concern.

Posted by Sam Ruby at

Ruby in a chair

Congratulations Sam ! Its an exciting time to be there :-)...

Excerpt from Leftover thoughts at

Sam Ruby to Chair HTML WG

I saw an announcement the other day that Sam Ruby will become co-chair of the W3C HTML working group at the beginning of next year. The HTML working group impacts web application development more than most other standards even though there’s rarely...

Excerpt from Nicholas Allen's Indigo Blog at

The HTML 5 vocabulary uses section and other “sectioning content” elements, in conjunction with header and h1-h6; meanwhile XHTML 2 uses a section element in conjunction with h.  (XHTML 2 also retains h1-h6, but they’re generally not used with section.)  Is there any room for convergence here?

XHTML 2 has the concept of “navigation lists” through the nl element, whilst HTML 5 has the menu element.  Can they happily coexist, or should they be merged into one element?

(The Forms Working Group has released the First Public Working Draft of XForms for HTML, the vocabulary of which also has overlap with HTML 5.)

Posted by Dave H at

Hi Sam, I’m a long time reader, though I’ve never bothered to leave a comment before. I have a suggestion regarding the HTML 5 recommendation. I know it’s probably poor form to approach the co-chair of the HTML5 WG directly, but I’m just a regular Joe who works for a bank in the middle of nowhere. You’re the closest thing I have to a friend who has access to the HTML5 WG.

I also know it’s very poor form to post off topic. I’m really sorry, but I don’t know how else to contact you.

Anyway, my idea has to do with getting around the problems we (web developers) have been experiencing due to certain browsers COUGH Internet Explorer COUGH flouting the recommendations of the W3C. Oddly enough, my idea was inspired by a decision Microsoft made that didn’t sit well with me.

As I’m sure you’re aware, MS has bundled the IE 7 version of Trident into IE 8. A meta tag on a web page can trigger IE 7 or IE 8 mode. The idea was very poorly received, and I count myself among the disappointed. No one wants more IE specific meta tags that go against the very purpose of web standards. Web developers have been forced to write IE specific code for too long, and we need less of it, not more!

As I thought about it, I realized that maybe they were onto something. Maybe everyone hated their implementation of the idea because MS hadn’t taken it far enough. If IE 8 can flip over to the IE 7 version of Trident, then why can’t it do the same with Gecko, Webkit, Presto, etc? In fact, why can’t all browsers support plug-and-play layout engines?

According to Wikipedia, there are at least 5 browsers that can flip between Trident and Gecko. There are also browsers that can flip between Gecko and Webkit. It’s already been proven that layout engines can peacefully co-exist in one browser, so why not make this a standard feature?

I propose a new attribute for the HTML tag itself, called layout-engine. It might look something like this:

<html layout-engine = "webkit 1.7" >

When the browser encounters it, it will automatically flip the rendering of that tab over to Webkit 1.7. It would also be relatively easy to add more advanced version selection:

gecko 1.5
Equal to 1.5

gecko > 1.5
Greater than 1.5

gecko < 1.5
Less than 1.5

gecko >= 1.5
Greater than or equal to 1.5

gecko <= 1.5
Less than or equal to 1.5

gecko 1.5 : 2.3
From 1.5 through 2.3

gecko 1.5 ; 2.3
Equal to 1.5 or 2.3

Also, if a browser has more than one acceptable engine, then go by the order specified in the attribute text. By combining these version selectors we can get very specific and robust control of the rendering engine used.

gecko 1.5 : 2.3, webkit 1.5 ; 1.8, trident >= 6.3

Would tell the browser that it can use:

In that order. Here are a few situational examples that explain how this might play out in the real world.

Situation 1
Available layout engines: Gecko 1.5
Supports layout-engine tag: Yes
Layout tag text: gecko 1.5
Result: Tab loads in Gecko 1.5 and all is well.

Situation 2
Available layout engines: Gecko 1.3
Supports layout-engine tag: No
Layout tag text: gecko 1.5
Result: Obviously, browser ignores tag and defaults to the only engine it supports. This is the worst case scenario, but it’s how the web works today.

Situation 3
Available layout engines: Gecko 1.5, Trident 2.3
Supports layout-engine tag: Yes
Layout tag text: gecko 1.5, trident 2.3
Result: Tab loads in Gecko 1.5, since it’s the first available engine specified.

Situation 4
Available layout engines: Gecko 1.5, Trident 2.3
Supports layout-engine tag: Yes
Layout tag text: gecko 1.4, trident 2.3
Result: Tab loads in Trident 2.3, since the exact version of Gecko requested isn’t available.

Situation 5
Available layout engines: Gecko 1.5
Supports layout-engine tag: Yes
Layout tag text: Trident 2.3
Result: Since no acceptable engines are available, the browser will ask the user for permission to install Trident 2.3. If the user denies permission then the browser will fall back to its default engine.</td>

As I see it, we can wait for Microsoft to get Trident up to speed on CSS2 and CSS3, which at the rate they’ve been going could take 5-8 years, or we can let web pages choose their own layout engine. I don’t see why such a simple feature couldn’t be available in time for IE 8.

If it works then web developers would finally have what they’ve wanted from web standards all along; the ability to write web pages that render the same way in any browser, without quirks created by stubborn and antiquated web browsers.

Posted by Michael Tomer at

It’s already been proven that layout engines can peacefully co-exist in one browser, so why not make this a standard feature?

There is a big gap between proof of concept and the problem you face.

Since you identify yourself as being at a bank, I presume that your issue is that you want to produce webpages that you can trust will render acceptably on a range of browsers.

Life was simpler a few short years ago when you could reliably assume that your customers had IE5.  Unfortunately, life is going to get a bit more complicated before it gets better.

Some of your customers will be running iPhones or Windows Mobile or Android or (soon) Palm Pre devices.  I apparently have a browser on my wii, though I’ve never used it.  In any case, none of these users will have the ability or interest in switching rendering engines.  Furthermore, none of these platforms currently have plans to run Gecko.

Even if it could be solved for IE8 (something I fear it is too late for, but it is not for me to say), it will be many, many, many years before IE7, IE6, and yes, even IE5 users step up.

Even if you could solve THAT problem, you will face issues when you wish to present pages which contain content from multiple sources.

The solution the HTML working group is driving towards is one where there is a common language which is implemented equally by all browser vendors.  It will take a number of years, but that solution will be more robust and durable.

Posted by Sam Ruby at

There is a big gap between proof of concept and the problem you face.

Fair enough.

Since you identify yourself as being at a bank, I presume that your issue is that you want to produce webpages that you can trust will render acceptably on a range of browsers.

You are correct.

Some of your customers will be running iPhones or Windows Mobile or Android or (soon) Palm Pre devices.

I believe the iPhone runs a modified version of Webkit and Windows Mobile uses a modified Trident. I’m not sure about the Palm. Still, I suppose the word modified could certainly denote a weak point in my theory.

I apparently have a browser on my wii, though I’ve never used it.

The Nintendo DS also has one, which was made by Opera. I’m guessing it may be (you guessed it) a modified version of Presto!

In any case, none of these users will have the ability or interest in switching rendering engines.

Well, I was hoping that the tag would make it automatic so the end-users' interest wouldn’t be a factor.

Furthermore, none of these platforms currently have plans to run Gecko.

A very good point. In that case, the browser could fall back to the next engine specified, or failing that, fall back to its default engine. That’s the worst case scenario, and it’s how the web works today.

Even if you could solve THAT problem, you will face issues when you wish to present pages which contain content from multiple sources.

A extremely good point. I’m ashamed to say that hadn’t occurred to me until you mentioned it.

The solution the HTML working group is driving towards is one where there is a common language which is implemented equally by all browser vendors.  It will take a number of years, but that solution will be more robust and durable.

Well spoken (Written?). Maybe my suggestion is just an attempt to cut corners on the path to standards compliance for all browsers. Perhaps I’m just impatient to arrive at the day when I don’t have to worry about the browser my users have. However, you are correct that it would be ideal if all rendering engines had complete standards compliance.

Also, I think I understand your primary problem with my suggestion. It would be impossible for this tag to support all options on all browsers across all platforms. Gecko is probably never going to be released for the iPhone, and it’s certainly never going to be released on the X-Box 360. That’s a valid point.

As I said, it seems that the idea here is to allow the web developer to specify a series of acceptable engines and gracefully fall back through them based on availability. If the browser only supports one rendering engine (Like the Wii) then so be it, render the page using that. As I said, that’s the worst case scenario, and it’s how the web works today. If the worst case scenario isn’t any worse than the way things are today, how much are we really risking?

No matter our differences on this matter, I respect your opinion and your standpoint. I suspect you may see my standpoint as a little shortsighted, and I see yours as being a little optimistic. Still, there’s a reason you’re the co-chair of the HTML5 WG and I’m just some guy at a bank!  : )

Posted by Michael Tomer at

I suspect you may see my standpoint as a little shortsighted

I didn’t say that. :-)

No solution is without problems.  IE’s solution, even if you ignore other rendering engines, poses problems down the road for Microsoft.  Five, ten years down the road, how many different rendering engines will the current IE have to support?  Multiply that by the number of vendors already in this space and you have a real mess.

That’s not saying that the alternative is not also a real mess.  Indeed, it is.

Posted by Sam Ruby at

This is a grait artical. Tank you !!!

Posted by blog at

Both Dare Obansanjo and Nick Bradbury have checked in fixes to the Atom <title> issue. Could it be? Is the syndication community moving in a common direction?

Posted by Aremila at

Add your comment