Re: <l>: Inline or Block?

> [Original Message]
> From: Lachlan Hunt <lhunt07@postoffice.csu.edu.au>
>
> Ernest Cline wrote:
>
> >> [Original Message]
> >> From: Lachlan Hunt <lhunt07@postoffice.csu.edu.au>
> >>
> >>
> >> Maybe <blockcode> should be either:
> >> 1. <!ELEMENT blockcode (blockcode, l)*>
> >> 2. <!ELEMENT blockcode (PCDATA | blockcode | Inline)*>
> >>
> >> Remember, the content model for <l> is
> >> <!ELEMENT l (#PCDATA | Inline)*>
> >> so there is no restriction on using Inline elements for either of these
> >> two options.
> >> I prefer version 1, since it is more strict and forces more structure
> >> than version 2, though anything that's valid for version 1 MUST
> >> also be valid for version 2 (since <l> is an Inline element).
> >
> >
> > Of course, that raises the question of whether <l> should be an
> > Inline element. It is already noted as an issue that as an Inline
> > element, the following code is valid, if semantically ridiculous.
> > <l>When is a <l>line</l> a </l>line</l>?</l>
> >
> > IMO <l> needs to be moved out of the Inline Module and into
> > the Block Module with elements that have a content model of:
> > (PCDATA | Inline)*
> > changed so that their content model is:
> > (PCDATA | Inline | l)*
> >
> > (Alternatively, the content model of <l> needs to be changed
> > to exclude <l> which would be simpler from the viewpoint of
> > implementation, but I think that while <l> is not quite a block
> > nor an inline element, it is more blockish than inlinish.
>
>   I did consider this problem at one stage, and almost posted the issue 
> to the list, however I saw some problems with each possibility.
>
> There are 3 Options that I can see to potentially sort this problem out:
>
> -- 1. Move to Block --
> Pros:
> * Appears to be "more blockish than inlinish", so this module may be 
> more appropriate.
>
> Cons:
> * Requires the content models of all elements that contain Inline to be 
> modified to contain <l> as well. (maybe not all, see question 2, below)
> * Allows <l> to appear in any element that has a content model that 
> includes Block, but not necessarily Inline (eg. <body>)
> <body>
>     <l>A line outside of a paragraph (or other block element).  This 
> does not make sense here!</l>
>     <p>A paragraph with a <l>line inside does make sense!</l></p>
> </body>
>
>
> -- 2. Move to Separate Module --
> Pros:
> * Does not automatically allow elements like <body> to contain <l> 
> elements, like option 1.

Are there going to be sufficient number of elements that accept
Block but not <l> as part of the content model to make this worth
considering? Other than <body> I can't think of one. (And other
than metaphysical reasons I don't understand why XHTML
continues the HTML limitation that <body> not have Inline
or PCDATA as part of the content model of <body>.  That
restriction is because given the following:
<html>
 <title>Huh?</title>
 <script></script>
 <p></p>
</html>
Is script part of <head> or <body>?

> Cons:
> * Creates another Module with only one element.  This may be
> completely  unnecessary.

We have other one element modules at present.
Heck, we have a one attribute module at present.
So the size isn't a problem.

> * Requires the content models of (all?) elements that contain Inline
> to be modified to contain <l> as well.

Given that most, if not all, non-Inline elements that have Inline but
not Block content will be affected, it might be worth giving
the combination (Inline | l) a special name such as Subblock.
Perhaps <ruby> should also be treated as Subblock, so
as to avoid its own nesting difficulty?


>
> -- 3. Leave as Inline and Modify the Content Model --
> Pros:
> * <l> should ONLY be able appear where other Inline elements can, so 
> this may be more. appropriate.
> * Allows <l> to be within any element that currently allows Inline 
> without changing content models.
> * Easy to modify the content model to contain all Inline elements, 
> except <l>.
> <!ELEMENT l (PCDATA | abbr | cite | code | dfn | em | kbd | quote
> | samp | span | strong | sub | sup | var)*>
>
> Cons:
> * Maybe <l> should not appear *everywhere* that Inline elements do
>. (see question 2, below)

Unless the content model of all the other inline elements and of the
RUBY elements were changed to avoid including <l> you get indirect
nesting (see response to question 1).  Changing the content model
of the RUBY module is something that had best be avoided at
this point.  Also, do we really want to have lines inside ruby markup?

> If you can think of any more, please add them to the appropriate lists.
>
>
>   However, either way, the following will still be possible, though 
> still semantically ridiculous:
> <l>When is a <span><l>line</l> a </l>line</l></span>?</l>

Actually this example is a good reason to remove
<l> from the group of Inline elements altogether so as to make
indirect nesting invalid.

> So, we're left with the following questions:
> 1. Is there any reason to bother worrying about this issue since
> nesting can still be done indirectly? OR

If <l> is not an Inline element and its content model is
the same as Inline elements, namely :
	(PCDATA | Inline)*
Then the nesting cannot be done even indirectly

>
> 2. Should <l> only be allowed directly within block elements and NOT 
> Inline elements?

YES!

Received on Sunday, 9 November 2003 14:43:22 UTC