Re: Consistence with other specifications, was: Design Principles

On Tue, 26 May 2009, Julian Reschke wrote:
> 
> I think that consistency with other specifications is a very important 
> goal, and that it needs extremely good reasons to give up on that.

I completely agree. Making sure the HTML5 spec matches deployed 
implementations and content is one such reason.


> In general, if another specification clearly has a bug, it should be 
> reported to the standards body maintaining that spec. In the worst case, 
> this is where the process ends (such as for IETF specs with an Erratum 
> on the RFC Editor page), on the other hand that Standards Body may be 
> revising that spec anyway.
> 
> But then, there's apparently disagreement about what constitutes a bug. 
> Many WhatWG contributors operate under the assumption that a spec that 
> doesn't define error handling somehow is "broken" or "incomplete". 
> That's not a reason to ignore it. If HTML5 *needs* to mandate specific 
> error handling (if!), then it can describe it, but that doesn't mean 
> that spec can be ignored otherwise.
> 
> As far as I can tell, ignoring/overriding other specs often is a symptom 
> of an assumption that one can do something better than those who were 
> involved writing the "other" spec (a certain kind of "NIH"). This may be 
> true sometimes, in which case the right thing to do is to help making 
> that other spec better.

I completely agree.

It should be noted that in every case (but one, see below) I'm aware of 
where it makes sense to fix the underlying specification, the working 
group in question is either working on fixing the underlying specification 
or indicated that they would rather their specification continue to not 
match deployed implementations.

One exception is the RFC2045/2046 violation; HTML5 introduces a few text/* 
types that only support UTF-8 and that support either CR, LF, or CRLF 
linebreaks, at odds with 2045/2046 requirements of always supporting an 
open-ended set of character encodings with charset="" and only supporting 
CRLF as line breaks for text/* types. The former is an outdated an 
unnecessarily heavy requirement now that UTF-8 support is widespread; the 
latter is a nonsensical requirement that is widely ignored already on the 
Web (and always has been for some types, e.g. text/html). I am unsure how 
to address this since as far as I am aware nobody is maintaining these 
RFCs anymore. Is this something we can or should report as errata? How?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 26 May 2009 10:09:38 UTC