Re: HTML 4.02

On the earlier mentioned HTML4all specification, I've recovered some  
of the more relevant portions from the backend database here:

<http://html4all.org/HTMLDraft.html>

Again, this specification looks to get to where authors have indicated  
they would like HTML to be. Combining that approach with the  
incremental HTML 4.02 approach it would be a good idea to identify  
those parts of the end product that either work in current browsers or  
degrade gracefully in those browsers. That way authors can target a  
current crop of browsers and get useful conformance checking feedback  
on that target set of browsers. The remainder of the specification  
could be moved to 4.03 or 4.1 or what have you. Then it is a matter of  
organizing upgrades and feature requests to the open source and  
proprietary browser makers respectively.

On the points you replied to:


> On 23 Aug 2009, at 20:04, Tab Atkins Jr. wrote:
> > To be fair, that's only because you've left out some things that  
> would
> > be necessary to actually have an unambiguous, coherent spec.
>
> Certainly it could do with beefing up a bit, but I have neither the
> time nor the inclination. However, if you consider the links to be
> normative references, it's actually quite usable as a spec.

I agree. I think the HTML4All effort nicely complements the work  
you've done by providing further prose on using the features for  
authors (and for implementing features for UAs when those features are  
not already sufficiently designated elsewhere)
>
> > I'm not sure whether subset you've chosen is the best (and probably
> > exact subset is going to be hard to agree on...)
> > Why add target, but not <ol start>?
>
> <ol start> should probably be in there actually. I'll maybe add that
> tomorrow.
>
> > There are other features that work today and could be included,
> > e.g. <input autocomplete>, <meta charset> and APIs like innerHTML.
>
>
> <input autocomplete="off"> works today, so could theoretically be
> included. But I don't like it, so it doesn't meet my primary
> inclusion criteria (which is that stuff I don't like isn't included).

To avoid the same autocratic problems the WG already suffers under, it  
would be nice to say a bit why you don't like autocomplete. If it is  
your own personal spec, the autocratic method is fine, but if you want  
a community of authors to adopt it, you should at least meet that  
community half way.
> <meta charset> doesn't seem to solve an actual problem.

I think it solves a problem that it is much easier for authors to  
understand and recall the syntax of a simple charset attribute than  
the more complex syntax of the meta http-equiv content-type attribute.  
Ideally this attribute would be moved to the 'html' element to further  
simplify the authoring process, but that would require a shift of UAs  
to support 'charset' on the 'html' element in addition to the already  
existing support on the 'meta' element.
> DOM APIs I do not consider to be part of the markup language.

I think that is perfectly acceptable to separate DOM to a separate  
spec. It prevents issue creep and forms a clear boundary between the  
hierarchical infoset vocabulary and the other parts of HTML.
> Robert J Burns wrote:
>
> > Ian Hickson and the WhatWG have shown they have no interest in the
> > needs of authors and users but only the needs of the anointed
> > browser vendors
>
> I somewhat agree with this sentiment. For every browser vendor
> reading the HTML5 spec, there's going to be a thousand page authors.
> I've been saying for a couple of years or more that HTML5 is far too
> skewed towards what implementers need. An HTML specification should
> define what the elements and attributes are called, what they mean,
> where they are allowed to be used, and precious little else. If
> necessary, an implementation guide could be produced separately and
> informatively referenced.

I agree. Authors are asking for new features for HTML to expand its  
expressibility whereas HTML5 is a browser specification that puts up a  
false front of an HTML specification.
> A final thought before I go to bed. Why should people use HTML 4.02?
> Because it's more or less the same as good old HTML 4.01 Strict that
> you're used to, but with better accessibility (ARIA), better metadata
> facilities (RDFa, plus the <time> element which solves a big
> Microformat accessibility problem), better internationalisation
> (Ruby) and a doctype tag you can probably remember without having to
> look up.

I agree here too that you have accomplished this with this moderate  
proposal. One question about the doctype declaration. Is it a  
standards mode invoking declaration? If not it might make sense to  
recommend the HTML5 doctype declaration for tHTML parsing and simply  
associate the DTD through conformance checker settings.

Take care,
Rob