W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2012

Re: [whatwg] Character-encoding-related threads

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 29 Jun 2012 20:42:06 +0000 (UTC)
To: Simon Pieters <simonp@opera.com>
Message-ID: <Pine.LNX.4.64.1206292028360.30734@ps20323.dreamhostps.com>
Cc: whatwg@whatwg.org
On Tue, 14 Feb 2012, Simon Pieters wrote:
> On Mon, 13 Feb 2012 18:22:13 +0100, Ian Hickson <ian@hixie.ch> wrote:
> > > I think this is like saying that requiring <!DOCTYPE HTML> is an 
> > > undue burden on authors...
> > 
> > It is. You may recall we tried really hard to make it shorter. At the 
> > end of the day, however, "<!DOCTYPE HTML>" is the best we could do.
> 
> It is a burden, but it's not significantly difficult or anything.

I consider all "boilerplate" to be a significant burden. I think there's a 
huge win to making it trivial to create a Web page. Anything we require 
makes it less trivial.

Currently you need a DOCTYPE, a character encoding declaration, a title, 
and some content. I'd love to be in a position where the empty string 
would be a valid document, personally.


> > Hm, that's an interesting point. Can we make a list of features that 
> > rely on the character encoding and have the spec require an encoding 
> > if any of those are used?
> > 
> > If the list is long or includes anything that it's unreasonable to 
> > expect will not be used in most Web pages, then we should remove this 
> > particular "hole" in the conformance criteria.
> 
> The list may well be longer, I haven't checked, but I don't think that 
> matters. The resolving URL problem is a bad problem because it means 
> links will stop working for users that have a different default 
> encoding, so those users leave and go to a competitor site. The form 
> problem is a bad problem because it means that the database will be 
> filled with content using various different encodings with no knowledge 
> of what is what, so when the author realizes this and "fixes" it by 
> declaring the encoding, it's already too late, the data is broken and is 
> very hard to repair.
>
> Letting authors get themselves in a situation where they have broken 
> data even though it could have been easily prevented seems more like an 
> undue burden to me.
> 
> Note that both of these features can be hidden in scripts where 
> validators currently don't even look, so I think it's not a good idea to 
> make the requirement conditional on these features.

Fair enough.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 29 June 2012 20:42:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:14 UTC