No (Content) Negotiation

December 28th, 2007

Virginia DeBolt provides a really nice grouping of links to writings related to the WHATWG. Among the writings are those related to accessibility, and there's nothing I can add to this discussion that isn't isn't handled succinctly and completely by others.

I did want to jump into the discussion related to XHTML, though. Dean Edridge wrote a general note of dissatisfaction with the WHATWG effort, including perhaps too much influence by Apple, Opera, and Google. I could add to this list by saying that Microsoft's non-involvement contributes an undue influence by Microsoft.

Edridge also started another thread, about XHTML5. He wrote:

I don't think that support for XHTML5 should be optional. Specifying
that user-agents may support only one format, but supporting both is
"encouraged" is insufficient and will only lead to a lack of support for
XHTML5 like we had with XHTML1 [1]

We've been down this road before where support for application/xhtml+xml
was only an "opt in" for user-agents. That's the main reason we have
less than 100 valid XHTML websites today. [2]
People wont be able to use XHTML5 if there's no support for it.

Can this please be changed to:
[[
…..Implementations MUST support these two formats.
]]

I found it fascinating that so few sites are 'pure' XHTML. This site is now one. Last week I turned off site negotiation and serve up pages with the proper MIME type of "application/xhtml+xml". This means, of course, this page isn't viewable by IE, which wants to process the page as XML, rather than interpret it as XHTML.

What's more interesting, though, is how much push back Edridge is getting on, what to me, is a very valid request. The responses have ranged from the 'undue burden' this places on devices like desktop widgets, to how Edridge should try to contain his passion–after all, some people are just raising issues.

What astonishes me, though, is how much this group is willing to bend over for companies that have the resources to make these changes, but it is is not convenient from a business perspective to do so. In other words, they can't turn it into profit, so why spend time on the tech?

I integrate the use of SVG into my sites. I plan on more heavily integrating it into this site. I can do so because I made one fundamental design decision: this site supports released specifications, not specific browsers. SVG is the one and only graphics system capable of giving something like Flash–a proprietary technology–a run for its money. SVG with XHTML, ECMAScript, and CSS3, combined, could do amazing things regardless of whether you're using a widget, cell phone, or browser on a computer. Why on earth would we deliberately sabotage this as a goal, just because it's not convenient from a business perspective for some companies who are making enormous amounts of money, and who could easily encompass such effort without breaking a sweat?

Then the argument comes around to, the fact that there are few sites implementing XHTML tells us that people don't want it. No, it tells us that tools aren't doing a good job of ensuring XHTML compliant pages. That people don't understand about content negotiation. That IE has effectively undermined XHTML while supposedly pretending to be a friend of the specification. This is a true chicken and egg story: which comes first? The demand for the technology which then generates support for the technology? Or support for the technology, which will generate demand?

Regardless of whether it's XHTML, or accessibility, or support for SVG, a standards group has the responsibility to move a technology forward–not provide excuses for keeping it rigidly locked in place, while browser makers happily skip ahead using proprietary technologies.

Perhaps I'm being overly harsh, but I've never seen a web specification group that is so happy to make a race for the bottom as the WHATWG group is.

Boggles.

update

I did like what the Opera Spec Wrangler had to say. And it is important to keep in mind that much of the work on these specs is done by volunteers. Having said this, though, I am seeing far too much willingness to say, "Oh, well we don't want to burden the user agents so we'll make this optional".

Why even bother with a specification if it doesn't move us forward? Just to make the web easier to process by a search engine? To give companies a "get out of standards" free card?

What is moving forward? Let's build some real accessibility into the new markups. Let's ensure that user agents can handle the specifications that have been released, including XHTML and SVG. Let's do things right, rather than expediently.

Comments
1
Ian Hickson - 8:54 pm December 28, 2007

The problem is that if we don't bend over backwards (as you put it) they'll ignore us. We only have any power over the browser vendors so long as we're telling them to do things that they agree with. The moment we start telling them to do things they don't want to do, they ignore us and we're back to the proprietary nonsense of yore.

In this particular case, it wouldn't make any difference if we required support for XHTML and HTML instead of making them both optional as they are now. Just because the spec requires it doesn't make it happen. That's why the spec just makes them both optional, and lets implementors decide which is more important to their users.

Now if you do want XHTML support, your best bet is to take that up with the browser vendors. Making your site XHTML-only, like this one, is a good way of doing that.

2
Shelley - 9:56 pm December 28, 2007

I can be sympathetic to your position, Ian, and the difficulties inherent keeping all of these self-serving egos in check. However, I do disagree with your premise: that if we don't 'compromise' the vendors will ignore the specifications.

If you provide options, it gives the vendors a way to say, "Hey, we're compliant with HTML5" when what they've done is a minimal implementation of HTML. Another vendor looks at this and says, "Why should we implement both HTML and XHTML, when that so-and-so can say they're compliant, but they're only supporting HTML? Let's go create something proprietary, instead."

What the HTML5 working group has done, by providing these options, is remove the ground out from under those of us on the outside who are pushing the browser companies to stop dragging their feet and implement the specs we need in order to create terrific pages.

We'll still be stuck with a broken web, except now the browser vendors who persist in breaking it can boast of their spec compliance, as they continue their own proprietary efforts.

This is somewhat the same situation that the ECMAScript group faced, and are facing with moving to ECMAScript4. The group wants to move forward, Microsoft wants them to rename the language, or hold, or some such thing. I disagreed with the ECMAScript group at the time. I was wrong.

Frankly, I'd rather have the vendors ignore the WHATWG effort, because then we'll all be in this battle together. You say that implementing this site as XHTML is a start, but if it's just me doing my own thing. I have no power. I'm just one node on a big web. Regardless of what you say, your group does have some power. Don't shove these issues out to the edges.

3
Michael R. Bernstein - 4:28 pm December 29, 2007

Hmm. We obviously need a 'To Hell with Broken Browsers Day' campaign.

4
Shelley - 10:21 pm December 29, 2007

That's not a bad idea, Michael.

Or perhaps we all need to remember a time when all of our efforts weren't spent 'compromising' with the vendors, so they won't have a snit and pick up their marbles and go home.

5
Bud Gibson - 8:48 pm January 12, 2008

Boy, Shelley, into the new year with piss and vinegar. I was wondering when we'd see your return.

I've always liked your tech experimentation and writing.

6
Bud Gibson - 10:38 pm January 12, 2008

BTW, the full feeds work poorly in Google Reader. That probably has something to do with how you are packaging the xhtml in the atom elements. My guess is that you're using an xhtml namespace for the content, and reader is barfing on that.

7
Bud Gibson - 10:40 pm January 12, 2008

Finally, is there a comments feed?

8
Michael R. Bernstein - 2:00 am January 13, 2008

Bud, there is, it's at http://realtech.burningbird.net/comments/feed/

9
Shelley - 8:24 am January 13, 2008

Thanks Bud, and I had another email on this, too. I've manually converted the field entries to HTML for now, and will convert–fully and compliantly–over to XHTML a little later today. Wordpress is hard coded to serving up HTML, only.

Right now, it should be fine. I have to check the comments feed, make sure it's good, too.

10
Shelley - 8:42 am January 13, 2008

Unfortunately, Google caches the feed and probably won't update until I create another post. It will remain muck until then.

11
Michael R. Bernstein - 6:21 pm January 13, 2008

Shelley, I use Google Reader and haven't noticed any problems for quite a while (at least in the past few months).

Meanwhile, I'm a little disconcerted that you didn't just turn off commenting on your main weblog, you also removed (or hid) all pre-existing comments, many of which (I thought) had a great deal of value.

12
Shelley - 6:26 pm January 13, 2008

The older comments have been returned.

13
Michael R. Bernstein - 8:14 pm January 13, 2008

Thanks Shelley!

14
Bud Gibson - 9:02 pm January 14, 2008

Shelley, your feed refreshed with all your delicious links, and now this post presents much better in Google reader.

BTW, I did not realize at first that delicious had become part of your feed, and I almost commented on humorless bitch as if she were you.

Michael, thanks for the comments feed.

15
Shelley - 9:54 pm January 14, 2008

I've removed the delicious links. I added them to test out the feed aggregator. Now, both posts here and at Burningbird show up under the general burningbird.net/feed.

The tech's in place. Too bad I don't have anything to say.

Thanks to all those who have contributed to the discussion. Comments are now closed, but you can contact the author of the post directly.

Prev: Lists of Good Stuff
Next: del.icio.us for January 14th