Re: Publication of specifications as HTML5

Hi, Liam-

On 8/22/11 6:00 PM, Liam R E Quin wrote:
> On Mon, 2011-08-22 at 16:33 -0400, Aryeh Gregor wrote:
>> On Sun, Aug 21, 2011 at 11:15 PM, Liam R E Quin<liam@w3.org>  wrote:
>>> Seems to me a requirement should be that the format issuitable for
>>> archiving.
>> [...]

I strongly agree with the goal of archivability.

To be clear, however, that is a goal for readability by future software, 
and is not the same as backwards compatibility; this may seem obvious, 
but there seemed to be some conflation.


>>    Archivability of the format is how reliably we
>> expect it to be readable into the distant future.  Just because
>> something ostensibly conforms to a Recommendation doesn't mean it's
>> readable at all.
>
> That's true, I agree. T some extent for W3C that's what (1) pubrules and
> (2) human review attempt to accomplish.
>
>> Moreover, just because something is not yet a Recommendation doesn't
>> mean it's not stable.
>
> I'm sorry if I wasn't clear - W3C has a definition of the word "stable"
> involving Recommendation... it's true that a given specification might
> not have technical changes between Last Call and Recommendation, but
> it's not unusual for there to be at least small changes.

We can usefully make a distinction between different types of features 
of HTML5 for these purposes.

It is true that there may be implementation changes around what I will 
call "active elements"... those elements with intrinsic behavior, like 
form elements, audio and video elements, and indeed any element with a 
dedicated API.  For all that they may be relatively stable, I appreciate 
concern for minor changes as we draw toward Recommendation.

However, there are semantic elements, most of which were present in 
previous versions of HTML, and others, like <aside>, <header>, <footer>, 
<section>, and so on; because these are not the kind of thing a browser 
needs to do anything special with (other than allowing them to be 
styled), and because they have remained stable for a long time, it seems 
reasonable to allow these in TR documents (with consideration for 
archivability).  These are the features that are most likely to be used 
in specifications anyway, not the "active elements" and APIs.

Should we need to establish formally that these sections are stable, we 
could do so with adequate tests for those features.

Does anyone disagree that such elements should be allowed in TR 
documents?  If so, what's the rationale?



>> In fact, the HTMLWG explicitly considered the question of whether to
>> add version identifiers to HTML5:
>> <http://lists.w3.org/Archives/Public/public-html/2010Dec/0135.html>.
>> It concluded that a version indicator is not necessary, because
>> (roughly) all future versions of HTML are expected to be
>> backward-compatible, and in the unlikely event that they're not, a
>> version indicator can be added at that point.
>
> I'm glad there are no bugs :-) Since version indication was removed, I
> don't (speaking as an individual) have confidence it will come back.
> But, once HTML 5 is a W3C Recommendation I also see no reason not to use
> it. Before that point, with no standard way to say one's using a
> particular draft, I do not think it should be used.

I would personally prefer a way to differentiate between the "text 
document" semantic features of HTML5, and the APIs and "active 
elements", but I'm not going to argue that point.  I disagree that there 
seems a real risk, in practice, for W3C specs being somehow unstable for 
the set of common features that are likely to be used.



>>   Do you foresee
>> any concrete, short- to medium-term harm from permitting the use of
>> HTML5 for W3C specifications?  Or are the issues you have with
>> publication as HTML5 solely a matter of principle?
>
> A matter of principle becomes a matter that is practical when your
> entire organisation is in fact about promoting a principle.
>
> Yes, I see harm in using things that are not standards.

I see just as much harm in not using and promoting those specifications 
that we are producing.  By not allowing HTML5, we are not eating our own 
dogfood.

So, it seems that there are different opinions within the W3C staff as 
well as with the larger community.  I've heard very sound reasoning on 
both sides of the discussion, but to me, I don't see the harm in 
allowing at least a practical subset of HTML5 in TR documents 
(especially given that the lion's share of it is compatible with HTML 
4.01), nor do I see compelling reason to delay using, if we have 
assurances of stability, like tests for the features to be used.

Regards-
-Doug

Received on Tuesday, 23 August 2011 02:17:31 UTC