W3C home > Mailing lists > Public > www-html@w3.org > November 2003

Re: <l>: Inline or Block?

From: Lachlan Hunt <lhunt07@postoffice.csu.edu.au>
Date: Mon, 10 Nov 2003 01:51:18 +1100
Message-ID: <3FAE5466.80802@postoffice.csu.edu.au>
To: ernestcline@mindspring.com
Cc: W3C HTML List <www-html@w3.org>

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 Seperate Module --
Pros:
* Does not automatically allow elements like <body> to contain <l> 
elements, like option 1.

Cons:
* Creates another Module with only one element.  This may be completely 
unnecessary.
* Requires the content models of (all?) elements that contain Inline to 
be modified to contain <l> as well.

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

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>

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

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

CYA
...Lachy.
Received on Sunday, 9 November 2003 09:53:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:40:09 UTC