W3C home > Mailing lists > Public > www-tag@w3.org > January 2013

Re: TAG Decision on Rescinding the request to the HTML WG to develop a polyglot guide

From: Daniel Glazman <daniel@glazman.org>
Date: Tue, 22 Jan 2013 10:24:04 +0100
Message-ID: <50FE5AB4.9060900@glazman.org>
To: Henri Sivonen <hsivonen@iki.fi>
CC: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@intertwingly.net>, Noah Mendelsohn <nrm@arcanedomain.com>, "www-tag@w3.org List" <www-tag@w3.org>, "public-html@w3.org" <public-html@w3.org>, Paul Cotton <Paul.Cotton@microsoft.com>, Anne van Kesteren <annevk@annevk.nl>, Aryeh Gregor <ayg@aryeh.name>, Lachlan Hunt <lachlan.hunt@lachy.id.au>, Ms2ger <ms2ger@gmail.com>
On 22/01/13 09:55, Henri Sivonen wrote:

> Don't support polyglot. Problem solved.

I will support what I think is best for the Web, like I have
always done during the last 22 years, thanks.

> That polyglot is eating your development time like this is evidence
> that publishing the polyglot guide is not harmless.

You know what is _really_ eating my development time? Some people
seem to have a undisclosed plan to just kill XML wherever it lives,
ignoring the reality of the industries out here in the name of
some sort of logical purity. Some of these people have worked for
software implementors but never for software users. They say they
know but they don't. When I see the xml declaration is still used
by zillions and Gecko has no more OM way of reaching it, _that_
does eat my development time. When I see editing in contenteditable
elements and designMode documents is specified ONLY trying to
harmonize what browsers currently do w/o looking at what users need
and by people who are NOT Masters of html editing rules, _that_ eats my
development time. When a Working Group prefers keeping <ins> and <del>
that CANNOT work instead of switching to a modern, robust AND
IMPLEMENTED-BY-EVERYONE solution, that does eat my development time.

Received on Tuesday, 22 January 2013 09:24:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:51 UTC