W3C home > Mailing lists > Public > public-html@w3.org > August 2009

Re: HTML 4.02

From: Toby Inkster <tai@g5n.co.uk>
Date: Sun, 23 Aug 2009 23:42:56 +0100
Message-Id: <33FD699C-D951-47F0-AFD6-2A916B4445E4@g5n.co.uk>
To: "public-html@w3.org WG" <public-html@w3.org>
I'm not answering all questions, but here are some answers:

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.

> What problems are being solved by these nice bits?  What criteria did
> you have for what to include and exclude?

Criteria: I included stuff I liked and did not include stuff I did  
not like.

I did originally plan to run a survey on what should go in and what  
should stay out, and although I finished writing the survey, never  
got around to writing it.

Yes, this is a somewhat autocratic method for writing a  
specification, but I'm not proposing that the W3C publish HTML 4.02  
as a Recommendation tomorrow. Personally, I like it, and am already  
using it in some places. It already "just works", so I'm perfectly  
happy for it to be ignored if there is no interest in developing it  
further - it more or less fulfils my need as it is.

> So can it be DTD validated or not?  If not, is there any real benefit
> from having it be DTD-validatable only sometimes?  If not, is there
> any benefit in having the DTD at all?

A subset of HTML 4.02 documents can be validated against the DTD. If  
the validator is tweaked to ignore xmlns:* attributes, then all HTML  
4.02 documents can. This tweak is already present in the W3C  
validator, but only enabled for XHTML documents.

Line 3132 is where the magic happens:
http://dev.w3.org/cvsweb/validator/httpd/cgi-bin/check?rev=1.680

That said, the xmlns:* issue is, I consider, the biggest open issue  
with it. The @prefix attribute is a hint at a possible solution - it  
has been proposed that RDFa (which is the main use case for xmlns:*  
attributes) could use this attribute as an alternative for CURIE  
prefix definitions. At least two implementations already support this.

Laura Carlson wrote:
 > Karl Dubost previously mentioned doing an html 4.2 or 4.5:

Kornel Lesinski wrote:
 > Douglas Crockfor has called for HTML 4.2 that's "stable and reliable"

Indeed. For a long time I've thought HTML5 needs to scale back its  
efforts. A lot of the stuff that's going on as part of the HTML5  
effort is great stuff, and no doubt very useful, but it's not  
necessarily stuff that should end up in the specification for a  
markup language.

> That however depends on definition of "works". Should it be  
> "doesn't break badly" or "browser implements it [partially |  
> fully]"? e.g. does <section> "work" in IE6? Does Ruby "work" in Opera?

Varying definitions of "work". Nothing breaks too much. <section> is  
not included in HTML 4.02. Ruby is included, and using <rp> elements  
can be made to degrade very gracefully in browsers that don't support  
it.

> 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).

<meta charset> doesn't seem to solve an actual problem.

DOM APIs I do not consider to be part of the markup language.

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.

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.

-Toby
Received on Sunday, 23 August 2009 22:43:48 UTC

This archive was generated by hypermail 2.3.1 : Friday, 10 October 2014 16:24:51 UTC