Re: Blocker for PR: links to HTML5 spec

On Mon, 4 Apr 2011, Philippe Le Hegaret wrote:
> On Mon, 2011-04-04 at 21:48 +0000, Ian Hickson wrote:
> > > Because the HTML5 spec won't be a REC before that.
> > 
> > Why does that matter?
> > 
> > HTML5 as published by the W3C is more stable and mature than the HTML4 
> > REC, and you can reference that, right? So why not reference HTML5?
> 
> More stable by whose criteria? As far as I know, the HTML4 spec doesn't
> change anymore, unlike the HTML5 spec.

HTML4 changes all the time, it's just that nobody is maintaining the spec 
to make it reflect the changes. For example, the HTML4 spec claims the 
default value of 'media' is 'screen' when it's in fact 'all', but the spec 
hasn't been updated to reflect that.

HTML5 is more stable than HTML4 because it more accurately reflects 
reality. For example, it correctly says that the default for 'media' is 
'all', not 'screen'.


> > Is there a process rule that says you cannot? If so, where is it? Can you 
> > provide a URL to that rule?
> 
> [[
> Does this specification have any normative references to W3C
> specifications that are not yet Proposed Recommendations? Note: In
> general, documents do not advance to Recommendation with normative
> references to W3C specifications that are not yet Recommendations.
> ]]
> http://services.w3.org/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=pr-tr

That doesn't seem to say you can't do it, it just describes, in a side 
note, the status quo. There's no "must" in that quote, and the "status of 
this document" of the process document claims that the process document 
uses RFC2119, so that implies there's no actual requirement in the quote 
above. Therefore, this seems like a very weak reason to not reference the 
specification that actually contains the definitions the Timing spec 
relies on.


> > Also, if there is such a rule, why not change it? We should obviously 
> > not be making decisions like copying spec text, along with the risks 
> > that entails, purely to work around a process we control.
> 
> We're trying to go around the instability factor.

No you're not: You said yourself that even after copying the definitions 
from HTML5, if HTML5 changed, you'd have to revisit this spec. So you 
don't gain anything in terms of stability.


> > If there really is such a rule and you can't change it, why not reference 
> > the WHATWG HTML spec instead? It's already a Standard, the most mature 
> > state a spec can get in the WHATWG, so presumably there's no problem with 
> > maturity, right? The process clearly doesn't require that you reference 
> > only W3C specs, since it references both an IETF spec and an ECMA spec 
> > already.
> 
> The WHATWG spec is even more unstable than the W3C one, so I don't see
> the point of referencing it.

The point is that it describes what this Timing spec relies on.


> > > > So what difference does it make if you depend on the HTML spec or 
> > > > not?
> > > 
> > > The difference is that we will be allowed to move REC if we don't 
> > > rely on a WD normatively. If we keep the current dependency, we 
> > > cannot move.
> > 
> > Working around a process you control is a clear indicator that the 
> > process is broken. Fix the process.
> 
> What you see as broken is there for a reason. It's difficult to pretend 
> that a spec is stable if it relies on unstable ones.

So don't try to pretend that it's stable.


> If HTML5 changes the navigation algorithm, the Navigation Timing spec 
> won't make sense anymore. By copying it, we're at least ensuring that it 
> still makes sense.

No, you're not. By copying it you are ensuring that it will be wrong as 
soon as the underlying spec changes.

This is *actively harming interoperability*.

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

Received on Monday, 4 April 2011 22:35:44 UTC