Re: Comments on XHTML 2.0 Working Draft

Philip TAYLOR [PC87S/O-XP] wrote:

[snip]

> Chris Mannall wrote:
>>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.


To some degree I almost do agree with you, were it not for the fact that 
the semantic nest these elements are allowed in is the /only difference/ 
between the two.

I just don't see how any value is added to the language when two such 
similar elements are included. Just what is the semantic difference 
between a "division" of text and a "span" of text, anyway? The only 
difference alluded to in the spec is that one is block, one is inline - 
which as I've already stated, is a presentational issue. And it's here 
that your argument about the semantic nests falls flat to me - why 
bother distinguishing between these two elements in the allowable 
document structure when there's no benefit in doing so? In the pre-CSS 
days, when presentation was built in to the document itself, there was a 
benefit/reason for the distinction in that they were displayed 
differently... once this stops being the case, and there's no other 
distinction left, why keep them separate?


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

I'm not sure from your wording whether you intended this as an argument 
for or against... either way, I wasn't actually suggesting that p 
elements could be nested, more pointing out that the definition given 
("[representing] a sub-paragraph") would seem to be met just as well by 
allowing nesting of p elements. I'd actually oppose such a change 
however - unless someone can prove the existence and usefulness of a 
"sub-paragraph"!


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

Hmm. I can see your point here... I'll have to mull this one over a bit. 
   Your reasoning about not indenting paragraphs after a contained 
element is my reasoning behind saying I was fine with the idea of lists 
inside paragraphs, but I'm still not sure about tables inside 
paragraphs. I suppose it comes down to your established ideas of what 
"paragraphs" can contain - and I would never be happy with the idea of a 
table inside a paragraph.

My opposition to blockquotes inside paragraphs could also largely be 
rendered moot due to my suggestion that blockquote be deleted in favour 
of a single quote tag.


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

Correct... this is the same argument. The only real difference I can see 
between the two is that one is meant to be block, one is meant to be 
inline. The distinction of "blockquotes contain longer expanses of text 
than quotes" doesn't seem worthwhile to me.

[snip to end]


Chris Mannall

Received on Tuesday, 6 August 2002 12:10:53 UTC