W3C home > Mailing lists > Public > www-international@w3.org > October to December 2014

Encoding Standard (was: API exceptions)

From: Anne van Kesteren <annevk@annevk.nl>
Date: Mon, 10 Nov 2014 10:21:35 +0100
Message-ID: <CADnb78jYxvrqOXT3CSS0_jwaR_mf5HD-TE8wJDxYGFGGX9KUOw@mail.gmail.com>
To: Shawn Steele <Shawn.Steele@microsoft.com>
Cc: "www-international@w3.org" <www-international@w3.org>
On Sun, Nov 9, 2014 at 8:56 PM, Shawn Steele <Shawn.Steele@microsoft.com> wrote:
> Hmm, I haven't looked at this before, however I'm not too keen on this paragraph of the API spec:

That paragraph is part of the overall Encoding Standard...


> I  would prefer much stronger language discouraging the use of legacy encodings.

That is done elsewhere. utf-8 is required for all new things.


> If "existing user agents can converge" means changing behavior of the mappings, then applications will break.

Some might break, but more will work, given network dynamics. Also,
some of the breakage will be better for end user security.


> I'd much prefer pointers to the existing standards.

As explained, existing standards don't give sufficient detail.


> I don't mind having those tables in a normalized format to work with a specific API, but it should probably be clear that it's a normalized copy.

Could you clarify what you mean? Note that these tables are not for
this API. They are for CSS, HTML, XML, and all other things browsers
implement.


> Currently the text could be read as being "the" standard definition of the encodings,

That is certainly the intent.


> however a better description might be that it's a normalized collection of encodings, and the files really should point to the standard source definitions.

I don't think those provide adequate detail for the level of
interoperability we need. I'd be happy to provide some historical
context somewhere though, if you think that's appropriate and if you
could help out with what you think that should say.



-- 
https://annevankesteren.nl/
Received on Monday, 10 November 2014 09:22:01 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:38 UTC