W3C home > Mailing lists > Public > public-html-xml@w3.org > January 2011

Serializer unavailability (was: Re: What problem is this task force trying to solve and why?)

From: Henri Sivonen <hsivonen@iki.fi>
Date: Thu, 6 Jan 2011 15:30:33 +0200
Message-Id: <294E9D3D-26E4-42C1-8D51-DF525FC926CD@iki.fi>
To: public-html-xml@w3.org
On Jan 5, 2011, at 13:36, David Carlisle wrote:
> The proposal to avoid these problems of always putting an html5 serialiser at the end of the chain isn't always available, James C just gave some use cases so I won't list any more here.

The unavailability of a serializer problem basically boils down to asking the developers of consuming software make changes to their software because the developers of the producer software can't be bothered to change their software.

Changing the consuming software is tricky because the legacy content accumulates and doesn't completely fade away. Thus, changing the consuming software either means breaking compatibility with existing content or introducing new modes. Modes require more code and increase quality assurance costs and cause confusion to authors. I've done community service over the past decade (http://hsivonen.iki.fi/doctype/) to try to reduce the confusion around modes, and I think modes definitely do lead to author confusion.

OTOH, changing the producing software would *increase* compatibility with existing consuming software without having to wait for a hypothetical change to the consuming software. (For example, if you do e.g. <h1><a name="foo"/>Bar</h1><p>Baz</p>, you get a non-tree DOM in IE8, and every reasonable content producer should want to avoid having to troubleshoot the effects of getting a non-tree DOM in IE.)

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Thursday, 6 January 2011 13:31:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 6 January 2011 13:31:40 GMT