Re: Structure vs Semantics

Jewett, Jim J wrote:

>Structure is important to the extent that it helps 
>with semantics.  Nesting is important.  Order is
>sometimes important.
>
  Absolutely Correct!!!

>But why is block vs inline important?  
>...
>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.
>
><snip>about limiting href to small, basically inline elements</snip>
>
  I think this possibility is the more accurate than the second one you 
provided.  I'll leave the discussion of href for now, and I'll focus 
more on the structure and semantics issues.

  In light of this discussion of removing the presentational distinction 
between block and inline, I have looked at the elements, and reorganised 
them into new structural modules, which are not linked to to their 
presentation in any way.  This is far from perfect, but I believe it is 
a *good start* to removing the distinction.  The content models are 
probably the biggest problem, but I've done my best, without spending a 
very long time analysing every single element.

  The main concept of this is to give an idea about the possible types 
of modules to use instead of the existing block and inline. Not every 
module or element is included here.

Divisional Module
section          (Divisional | Heading | List)*
div              (PCDATA | Divisional | Heading | Line | Inline | List)*
p                (PCDATA | Divisional | Line | Inline | List)
pre              (PCDATA | Inline-Sem)*

Heading Module
h                (PCDATA | Inline-Sem)*

Line Module
l                (PCDATA | Inline)*

Divisional/Inline Semantic Module
[Included with 'Divisional', 'Inline' and NOT 'Inline-Sem']
code             (PCDATA | Line | Inline-Sem)*
quote            (PCDATA | Divisional | Heading | Inline-Sem)*
contact  (PCDATA | Divisional | Heading | Inline-Sem)*

Inline Semantic Module
[Included with 'Inline' and 'Inline-Sem']
abbr             (PCDATA | Inline-Sem)*
cite             (PCDATA | Inline-Sem)*
dfn              (PCDATA | Inline-Sem)*
em               (PCDATA | Inline-Sem)*
kbd              (PCDATA | Inline-Sem)*
samp             (PCDATA | Inline-Sem)*
strong           (PCDATA | Inline-Sem)*
sub              (PCDATA | Inline-Sem)*
sup              (PCDATA | Inline-Sem)*
var              (PCDATA | Inline-Sem)*
span?            (PCDATA | Inline-Sem)*

List Module
dl               (dt | dd)+
dt               (PCDATA | Inilne)*
dd               (PCDATA | Divisional | Heading | Line | Inline | List)*
label         (PCDATA | Inline)*
nl               (label | li+)
ol               (li+)
ul               (li+)
li               (PCDATA | Divisional | Heading | Line | Inline | List)*


Removed Elements
h1-h6
blockcode, blockquote (Replaced with code and quote)
address (Replaced with contact)
hr (Divisional Module should have enough semantics to replace this)


  The distinction between div and span still present a problem.  If it 
were replaced with just div, and it were allowed within Inline aswell, 
then one could write:
<abbr><div><section></section></div></abbr>
So, I have included both for now.  However, there is still the question 
of the usefulness of <span> for anything other than just presentation?  
ie. It is useful to group some inline elements, but this can be done 
using div.  The question is more about grouping inline elements within 
another inline element.
eg. (where <inline> represents any element from the above inline-sem module.
<inline>text 
<span><inline>text</inline><inline>text</inline></span>text</inline>

  Presentation of the Divisional/Inline semantic module as either block 
or inline will need to depend on their use.  For example, when used 
within a paragraph, the default style should be inline, but when used 
within section or div, it should be block.

  There would be very little need to include the Divisional/Inline 
Semantic elements within the Inline semantic module when it can be 
written as, for example,
<code><strong>...</strong></code>
  instead of
<strong><code>...</code></strong>

CYA
...Lachy!

Received on Tuesday, 9 December 2003 08:22:08 UTC