- From: Philip TAYLOR [PC87S/O-XP] <P.Taylor@Rhul.Ac.Uk>
- Date: Tue, 06 Aug 2002 15:46:40 +0100
- To: Chris Mannall <chris.mannall@hecubagames.com>
- CC: www-html@w3.org
Chris Mannall wrote: > > XHTML 2.0 Working Draft Comments [snip, with implicit support for all Chris' "consistency" and aesthetic suggestions] > 8.11 The heading elements > ------------------------- > > Is it necessary to have two forms of heading? Bearing in mind that the > combination of h and section is recommended over the traditional hX > elements, I don't see why both are required. Can the hX elements not be > deprecated? > > If it's really necessary to retain the functionality of the hX elements, > could we not instead have something like this?: > > <h level="1">Equivalent of h1</h> > <h level="2">Equivalent of h2</h> > <h level="3">Equivalent of h3</h> > etc. This one I /very/ strongly support. > 8.9 The div element and 8.19 The span element > ------------------- --------------------- > > Reading the descriptions of these elements, I have to wonder why both > are necessary. Since the descriptions of both state that "this element > imposes no presentational idioms on the content", the only difference > between the two is that one is defined as "inline" content and one is > defined as "flow" content. One could argue that this distinction is > mostly presentational anyway... there's no reason why a single element > could not be used for both purposes, for example: > > <div> > <p>The enclosing div is a "block" element.</p> > <p>Whereas <div>this one</div> is a flow element.</p> > </div> > > The intended difference in presentation here is easily handled using CSS > mechanisms: > > div { display:block; } > p > div { display:inline; } I suspect that having two elements, each of which is permitted only in a particular semantic nest, is beneficial, so I don't offer unqualified support for this idea, but I'm willing to be convinced. > > 8.13 The line element > --------------------- > > "The line element represents a sub-paragraph." > > I really dislike this description. The line element clearly represents a > line! If there were such a notion as a "sub-paragraph" (which I must say > I've never come across before), what is wrong with nested p elements? Well, allowing <p> to nest within <p> would reduce the implicit error checking which disallowing it permits. [short snip] > 8.14 The p element > ------------------ > > "In comparison with earlier versions of HTML, where a paragraph > could only contain inline text, XHTML2's paragraphs represent the > conceptual idea of a paragraph, and so may contain lists, > blockquotes, pre's and tables as well as inline text." > > Could I ask what the working group's reasons are for this change? > Although I have not yet sat down to come up with a concrete argument > against, my gut > instinct is to strongly dislike this change. I can understand the idea > of a paragraph containing a list (and in fact I used to do this in my > pre-valid > markup days), but a table inside a paragraph? A blockquote inside a > paragraph? Neither of these last two "feel" correct to me. They both feel correct to me. If you think of an interrupted paragraph, where the current paragraphing convention is "indent", then resuming the paragraph requires the first line of the resumption to be /not/ indented, whilst if the para. is /terminated/ at what might otherwise be an interruption, then the first line of the new para. will be indented. So allowing <x> (for all sensible <x>) to occur /within/ a para. allows the author to ensure that an interrupted paragraph is visually differentiable from a pararaph which has ended just prior to the <x>. > > 8.16 The quote element and 8.4 The blockquote element > ---------------------- -------------------------- > > Based on the fact that blockquotes are now allowable inside a p element, > is it really necessary to have two elements? It seems to me that once > again the only difference between these two is that one is "inline", one > is "flow"... which strikes me as a presentational difference that should > be left to stylesheets: > > quote { display: block; } > p quote { display: inline; } This is analogous to the <span>/<div> argument, so whichever position is "correct" should be applied consistently. [longer snip] > 18.2 The script element > ----------------------- > > Is there any chance that we can start the process of renaming "src" > attributes to "href" attributes (or vice versa)? This one I /strongly/ support, particularly in view of the following argument adduced by Chris. > The distinction is both > unnecessary and unclear - someone once made the argument to me that src > is used when the resource is to be included directly included into the > document, and href when the resource is something being pointed to as > some form of relation, but examination of HTML and XHTML specs doesn't > agree with this argument. If this were the case, then I suppose I could > tolerate the difference between the two... without this semantic > difference, I can see no reason whatsoever to have two different attributes. [snip to end] > Chris Mannall. Philip Taylor, RHBNC
Received on Tuesday, 6 August 2002 10:49:37 UTC