Re: Structure vs Semantics

Hi,
   The distinction, or lack of distinction between block and inline
elements appears to be more complex than at first glance.  There have 
been many valid arguments for and against the removal of this 
distinction which, as Ernest pointed out, has been fundamental to HTML 
since it was first standardized as HTML 2.0.

   The only way to make this kind of decision, is to determine what kind
of distinctions currently exists between block and inline, and whether 
or not these distinctions between the elements can be retained without a 
specific distinction between block and inline.

   Several arguments suggest that it is purely presentational and as 
such suggest that it should be removed, while other arguments suggest 
that it is more of a structural distinction and some suggest that there 
is also a fundamental semantic difference between them.

   The presentational differences are obvious, and, because XHTML is not 
a presentational language, it seems unlikely that they can have any 
effect on a decision such as this.

This leaves us with two seperate questions to address:
* What are the semantic distinctions?
* What are the structural distinctions?
   For both questions we need to look at the arguments for and against,
and what effect these distinctions, if any, have upon a final decision.

   The concept of this post is to present the facts, and indicate some 
of the questions raised clearly and in a neutral way.  ie. I will try to 
present both sides of the debate equally.


-- Semantics --

The XHTML 2 draft states [1], in the Block Text module:
   "Note that while the concept of "block level" can be construed
    as a presentation aspect, in this case it is intended to only
    have a semantic meaning.
    ...
    Note that the use of the words Block and Inline here are meant
    to be suggestive of the role the content sets play. They are
    not normative with regards to presentation since a style sheet
    might give any element within the Block content a display
    property of inline."

   So, there can be no argument against the intention to have a
semantic, rather than a presentational meaning, but what are the
semantic meanings of a block level element that differ from inline?

Jim Jewett 2003-12-09:
> The conceptual "size" of the contained information is truly
>  important.
>
> Some element types (such as <strong>) are large enough to contain
>  subelements, but not large enough to stand on their own.  Since they
> can't stand on their own, they shouldn't contain anything that does -
>  or even could.

   A block element generally indicates a logical division or section 
large enough to stand on its own, whereas the inline equivalents 
generally contain smaller fragments that don't necessarily make sense 
out of the context of their containing element.
   For example:
     blockquote: "This element designates a block of quoted text." [2]
     quote:      "This element designates an inline text fragment
                  of quoted text." [3]

   This indicates that there may be a fundamental content size semantic 
difference between the two.  However, two questions still remain
   1. Is this difference in size relevant to the overall semantic
      meaning of the elements.  ie. Does it really matter that a block
      is larger than it's inline equivalent, since boths element are
      marking up the same kind of semantic structure?
   2. If so, can this same semantic difference be indicated through
      structure, rather than having two seperate elements?


-- Structure --

Karl Dubost 2003-12-06:
> Structure and Presentation are very difficult to distinguish and it 
> seems sometimes overkilling to have two tags for the same semantics 
> when only the structure has changed.

 From the HTML 4.01 Specification [4]:
   Content model
    "Generally, block-level elements may contain inline elements and
     other block-level elements. Generally, inline elements may contain
     only data and other inline elements. Inherent in this structural
     distinction is the idea that block elements create "larger"
     structures than inline elements."

   This indicates that there is a structural distinction between block 
and inline elements, and this distinction is clearly defined, however, 
Karl raises a good point.  If any semantic distinction between 
equivalent block and inline elements can be indicated through the 
document structure, can this same structure be indicated through the 
context of the element, rather than having two seperate elements, such 
as <blockquote> and <quote>?

Chris Mannall 2003-12-11:
> A "block" quote can be defined not only by what it contains (which,
> as you say, can't be represented by a CSS selector), but also by what
> it is contained by.  An "inline" q element would tend to be a
> descendent of a p element; a "block" q element would not. This would
> seem to be handled by the following CSS rules:
> 
> q { display:block; }
> p q { display:inline; }

   Although this idea would need quite a lot of refinement, this 
indicates that it may, infact, be possible to determine the nature of an 
element as being block or inline from the context of the element's use. 
  However, as Ernest points out in his reply, that this may not be so 
simple.

Ernest Cline 2003-12-11:
> Yes and no.  While the tendency is for quotes in a paragraph to be
> inline, they can be block which is one reason the current draft makes
> the needed improvement of adding blockquote to the content model
> of p.  And for div we have  in my opinion a roughly equal expectation
> of encountering either block or inline quotes. 
> 
> OTOH,  as far as a blockquote inside a paragraph is concerned,
> the block nature there is largely a matter of presentation save for
> one critical distinction: the punctuation characters used differ in the
> two contexts. (at least in English they do)  If we leave the block/inline
> distinction to styling, we'll have to revert to having UA's adding
> appropriate quotation marks as per the <q> element instead of
> adopting the simpler handling of the proposed <quote>.

   As Ernest correctly points out, the block or inline nature of a quote 
may be presentational, however he also states that the quotes used also 
differ and that these may not simply be a presentational issue.

   While the quotes do differ, do they provide any additional semantic 
value to the reader.  Both forms indicate a quotation, and as such, the 
different quotes may just be a presentational convention, which can be 
handled through CSS.

   As for the point about <div> as the parent element of a quote, 
perhaps the decision could be made to make the *default* presentation of 
elements such as quote, block in such situations where either block or 
inline is equally likely, and inline for where there is a tendency of 
usually being inline, such as within <p>.  However, since this would be 
a presentational issue, if the default style is incorrect, the author is 
able to apply CSS to correct it.


Ernest Cline 2003-12-10:
> The problem is that with the structure of XML, it is impossible to
> allow <a><b/></a> and <b><c/></b> while banning <a><b><c/></b></a>.
> (At least via an XML DTD there is no way to do this. Does XML
> Schema or Relax NG provide a mechanism to do this?)
> 
> Thus, with the proposed model we would have to accept
> <em><quote><div/></quote></em> even tho we
> don't want <em><div/></em>.
(The proposed model is referring to that which I proposed earlier, on 
the same day)

   Ernest has raised quite a good point about the content models, but 
the question is, that even though structures like <em><div/><em> are 
semantically incorrect, is there no case where 
<em><quote><div/></quote></em> would be semantically correct?
eg. If the <quote> was infact large enough to be block quote, and was 
presented as such through CSS, then it could well be semantically correct.

   This could be an argument for keeping the distinction between block 
and inline elements like <blockquote>/<quote>, yet not if the difference 
between the two is just presentational.

CYA
...Lachy!

[1] http://www.w3.org/TR/2003/WD-xhtml2-20030506/mod-block-text.html
[2]
http://www.w3.org/TR/2003/WD-xhtml2-20030506/mod-block-text.html#sec_8.3.
[3]
http://www.w3.org/TR/2003/WD-xhtml2-20030506/mod-inline-text.html#sec_9.8.
[4] http://www.w3.org/TR/html401/struct/global.html#h-7.5.3

Received on Thursday, 11 December 2003 10:41:49 UTC