- From: Dan Connolly <connolly@w3.org>
- Date: Mon, 25 Jun 2007 09:07:05 -0500
- To: bhopgood@brookes.ac.uk
- Cc: public-html@w3.org
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