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


Most of what I said was really trying to make it look a bit more
professional. I don't have any great gripes with it. It would be nice if
recommendations had their correct names just to avoid confusion.

Adjectives like esoteric could cause some people to jump up and down and
it didn't seem really necessary. My dictionary has 'intelligible only to
those with special knowlege or intended only for the initiated'. It
obviously means something different this side of the Atlantic ;-)

Re not a sentence, the version I looked at had a 'when' or a 'where'
missing from the second sentence from what I remember. Don't have the
document with me at the moment.

I am happy with your responses. Document has a lot of useful information
and is worth issuing.


> On Mon, 2007-06-25 at 11:52 +0100, 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."
>  --
> (by the way, Anne, there's a space between HTML and 5 in the WG
> decision
>;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

Received on Monday, 25 June 2007 14:58:26 UTC