- From: Lachlan Hunt <lhunt07@postoffice.csu.edu.au>
- Date: Mon, 10 Nov 2003 01:51:18 +1100
- 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