Re: Publication of specifications as HTML5

Hi, Liam-

Tl;dr version:

Let's use a pragmatic rule of thumb, not a policy, to decide what 
features of a language are commonly supported enough to allow on /TR. 
That's really what we've done in the past, and it seems to have worked. 
  Let's just allow HTML5 to be used by those groups that want to.


Time to kill version:

It seems you are trying to solve the general policy question: when 
should a format be allowed on /TR, given the principle that W3C wants to 
be an exemplar.

One criterion you seem to be applying to settle this policy question is 
the maturity of the targeted format along the Rec track.  On the face of 
it, this seems to have been the loose rule of thumb in the past for 
previous HTML specs, for example.

However, that is not the sole, or even the best, criterion to use.

For example, SVG was a Recommendation for a decade before it was 
appropriate to use as the primary image source for a specification, 
despite the fact that it was meant to be a user-facing browser-rendered 
document format; it wasn't usable because SVG wasn't yet widely 
supported in the most common browsers; now that it is, we can 
legitimately use it.

Another example is XHTML.  Despite its status as a Recommendation, there 
had to be a loophole in the spec to allow it to be served, parsed, and 
displayed as 'text/html', not according to XML rules at all.  That's 
because if we served it on /TR as XHTML, most users couldn't have viewed 
it (since IE, the dominant browser of the time, didn't support XHTML).

Both of these are pragmatic rules... Can the average reader be expected 
to view the document in a way that captures the authorial intent, 
without significant loss of information?  If not, then regardless of its 
Rec-track status, it is not suitable.

I suggest that the unwritten rule of thumb (I'm going to stop short of 
calling it a policy, because it's not documented anywhere) has not been 
the Rec-track maturity, but a combination of stability and deployment. 
That's the existing precedent.

W3C continually improves how it measures both of those, through more 
comprehensive and exact test suites.  But it's still not exact... it 
needs human judgment.  Let's put our energy on continuing to improve 
those measures, so we can make better and better judgments.


There is one more subtlety to this: not all features that could be used 
in a spec affect the way it is rendered to the average user, but rather 
are targeted at other UAs or processing tools.  Metadata, like Microdata 
or RDFa, or functional attributes, like ARIA, could be used in a spec, 
and ideally should be stable.  But I think that is of less importance 
than the primary presentation of the document (though still important); 
this is largely because our specs are fairly simple... mostly variations 
on text, tables, and images.


So, if you want a general rule of thumb, I would offer the following: 
Specifications should only be published in /TR using those features or 
formats that seem to be widely supported, given our best information.

To me, most static document features of HTML5 meet that criteria.  If 
there seems to be a problem with some specific feature that isn't widely 
enough supported, we can address that as needed.

I *wouldn't* want this rule of thumb to be interpreted or enforced as a 
"policy" per se, because I personally think W3C should seek to avoid 
bureaucracy as much as possible, where it isn't shown to produce 
tangible benefits.

As an aside, another of your stated criteria was archivability, which is 
also useful, but does not seem to be a decisive factor... others have 
pointed out that HTML5 has good future-proofing.

And finally, if a group wants to stick with XHTML, HTML4.01, or 
whatever, that's clearly fine, too... HTML5 should simply be an option 
that groups can choose.

Regards-
-Doug

On 8/25/11 1:48 PM, Liam R E Quin wrote:
>
> You're quoting Leif, not me.  However, I'll reply :-)
>
> I see no objection if HTML 4 was published using HTML 4, nor if HTML 5
> is published using HTML 5, as I have said.
>
> On the other hand... what if we want to publish the XSL-FO 2.0 draft as
> an XSL-FO 2.0 document, not in HTML? Web browsers won't easily be able
> to display it, but it would encourage adoption and we should eat our own
> dog food, right?  No, because the goal is to have specs that the
> implementors can read and understand.  So, HTML is (rightly) treated as
> a special case at the World Wide Web Consortium, and the drafts are
> written so that existing browsers can understand them. Plus it's the
> browser-makers working on the spec, a luxury we don't have in (say) the
> XML world, where there might easily be over 100,000 XML-system
> implementations in the world.
>
> None the less, we should be careful about what precedents we set.
>
> Best,
>
> Liam
>

Received on Friday, 26 August 2011 20:15:07 UTC