Re: ready to publish "HTML5 differences from HTML4"?

On Mon, 2007-06-25 at 11:52 +0100, bhopgood@brookes.ac.uk wrote:
> Dan,
> 
> I read the first few pages and have the following commemnts:
> 
> 
> (1) 1. Introduction,  Para 2: W3C has never had a Recommendation called
> HTML4.

I suppose we could use a space between HTML and 4.

"This specification defines HTML 4.01, which is a subversion of HTML 4.
...
The first version of HTML 4 was HTML 4.0 [HTML40], published on 18
December 1997 and revised 24 April 1998."
 -- http://www.w3.org/TR/1999/REC-html401-19991224

(by the way, Anne, there's a space between HTML and 5 in the WG
decision
http://www.w3.org/2002/02/mid/46423D1F.5060500@w3.org;list=public-html )

>  HTML 4.0 became a Recommendation in 1997.
> This paragraph is argumentative and adds nothing to the document.

I suppose someone could argue the other side of
"it does not provide enough information to build
implementations that interoperate with each other and, more
importantly, with a critical mass of deployed content"
but I have not seen any such argument in this WG.

As to what it adds: it adds "some of the rationale for the changes."

> (2) 1.1 First para: I do not believe previous versions of HTML are
> backwards compatible. HTML 4.01 does not support hp1, hp2, plaintext, xmp,
> listing for example.

True; "backwards compatible" is a subtle thing to discuss/define;
I could live without it for this document.

>  These appeared in earlier versions of HTML.  I don't
> understand what 'dropped' means given this and the next paragraph. It does
> not sound like the conventional definition of the word 'dropped'. Perhaps
> a different word should be used similar to but different from
> 'deprecated'.

As the WG hasn't made any decisions to take this markup out of the
language, I'd rather stick to reporting the differences factually;
i.e. say they appear in one specification and not in the other.

I don't have any specific suggestions for section
"1.1. Backwards compatible" except to delete it. (though
that probably crosses the "large change" boundary...)

> (3) 1.1 Third para: there is no guarantee that having things clearly
> defined will make any difference whatsoever to what gets implemented in
> the future. Previous standards efforts can vouch for that. This is wishful
> thinking. In any case, why is this para in a section called Backwards
> compatible? I don't think this para really adds anything to the document.

I could live without it.

> (4) 1.2 Having two implementations of the specification does not mean that
> it is usable. Somewhere in this para it should state  that the
> implementations must be valid or conforming.

I suppose that might help, though it seems clear enough to me as is.


> (5) 2. Syntax para 1. 'esoteric' is argumentative and should be removed.

Again, you suggest that presenting argument is bad.
I don't see why. 

I suppose it might help to elaborate
with examples, such as <em/text/ .

The first definition for "esoteric" that I find is:
"Hidden or deeper knowledge or teachings that are possessed or
understood only by a few."

Yes, I think it's accurate and useful to say that only a few knew
that HTML 4.0 included markup such as <em/text/ .

> (6) 2. Syntax Para 2. The parsing rules clearly cannot be largely
> compatible with popular implementations when IE, Firefox and Opera manage
> to parse the same  HTML fragment quite differently. For example: <em>abc
> <strong>def</em>ghi</strong> is parsed differently by all three and
> produces different DOMs in each case.

"largely compatible" is close enough for me.


> (7) 2. Syntax para 4. W3C does not have an XHTML1 recommendation.

The references section makes it clear enough what XHTLM1 refers to.

>  Second
> sentence is not a sentence.

I don't see a non-sentence around there. Maybe it's been fixed already?

> (8) 3.1 Para 1. HTML 4.01 states that the presentation of <em> and <li> 
> depends on the user agent. The implication is  that they are neither 
> block or inline  elements. There are constraints on where such elements
> can appear in a document. They can be rendered as either block or inline
> elements. Thus the change in HTML5 may be much more drastic than is
> implied here as it is forcing classification on such elements as well.
> Perhaps that is not what was intended.

That seems like a comment on the HTML 5 spec more than a comment
on the differences document.


> (9) 3.2 Although 'section' may introduce structure to a document, as h1 to
> h6 enclose very little, not even the <p> elements following, they cannot
> be used to indicate document structure.

I don't see any claim that h1 indicates document structure:

"section represents a generic document or application section. It can be
used together with h1-h6 to indicate the document structure."

> (10) 3.2/3.3 The rest of this section uses the phrase 'can be used'. To me
> that implies the element has a certain meaning (unstated)  but can also be
> used for this function. Why not say what <embed> is for rather than saying
> what it 'can be used for'. The two statements are different. Why not
> remove the word 'can' and 'can be' from the document completely.

Fine by me.

> Bob
> 
> 
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Monday, 25 June 2007 14:07:12 UTC