[rfc-i] Supporting both ease-of-entry and un-labeled list items in v3

Julian Reschke julian.reschke at gmx.de
Thu Feb 13 09:12:30 PST 2014


On 2014-02-13 17:55, Paul Hoffman wrote:
>
> On Feb 12, 2014, at 12:45 PM, Julian Reschke <julian.reschke at gmx.de> wrote:
>
>> On 2014-02-12 20:57, Paul Hoffman wrote:
>>> On Feb 12, 2014, at 11:47 AM, Julian Reschke <julian.reschke at gmx.de> wrote:
>>>
>>>> We can support both inline elements (text, <xref>) and block elements (<t>), but why would we want to allow to combine them?
>>>
>>> Because it makes it easier to create an Internet Draft, which is a design goal. Compare the current proposal:
>>>
>>>     <list style="symbols">
>>>        <li>This is the first element with a bullet.</li>
>>>        <li>This is the second element with a bullet.
>>>           <t>This is part of the second element,
>>>           but it does not have a bullet</t></li>
>>>        <li>This is the third element with a bullet.</li>
>>>     </list>

Once we start mixing text with block level elements, we'll probably see

         <li>This is the second element with a bullet.
            <t/>This is part of the second element,
            but it does not have a bullet</li>

as well :-)

>>> With the one you seem to be proposing:
>>>
>>>     <list style="symbols">
>>>        <li><t>This is the first element with a bullet.</t></li>
>>>        <li><t>This is the second element with a bullet.</t>
>>>           <t>This is part of the second element,
>>>           but it does not have a bullet</t></li>
>>>        <li><t>This is the third element with a bullet.</t></li>
>>>     </list>
>>>
>>> I suspect that someone who just wants to write an Internet draft would prefer the first.
>>
>> Not convinced.

BTW, my proposal was to have <li> (*) be either inline content *or* 
block content. That is,

      <list style="symbols">
         <li><t>This is the first element with a bullet.</t></li>
         <li><t>This is the second element with a bullet.</t>
            <t>This is part of the second element,
            but it does not have a bullet</t></li>
         <li><t>This is the third element with a bullet.</t></li>
      </list>

would work but so would

      <list style="symbols">
         <li>This is the first element with a bullet.</li>
         <li><t>This is the second element with a bullet.</t>
            <t>This is part of the second element,
            but it does not have a bullet</t></li>
         <li>This is the third element with a bullet.</li>
      </list>

(*) I'd prefer not to use <li> unless it's really the same thing as in 
HTML. That's why the proposed element name has been <lt> for a very long 
time.


> You're not convinced that someone (maybe almost everyone) would prefer the first? Other than for some XML design reason, why would someone prefer the second?
>
>> Let's not mix block-level elements with text content.
>
> That design goal has little or nothing to do with making it easier to create an Internet Draft, which is a design goal.

It seems that you equate "has less to type" with "easier". I disagree 
with that. A logical structure with fewer edge cases makes things 
"easier", too. (And no, not only for implementers)

> A possible third alternative, which makes me cringe a bit but I can see some logic to it, would be:
>
>     <list style="symbols">
>        <li>This is the first element with a bullet.</li>
>        <li>This is the second element with a bullet.
>        <linolabel>This is part of the second element,
>           but it does not have a bullet.</linolabel>
>        <li>This is the third element with a bullet.</li>
>     </list>
>
> That solves your "not mixing block-level elements with text content" problem and still would not force people to have to use two elements everywhere. Thoughts?

It  doesn't help if a list item needs to contain, for instance, a text 
paragraph and a preformatted example (for which we don't have an element 
yet).

Also, in this case, the logical structure is not reflected by the XML 
structure. I believe that's not helpful. Right now the only place where 
we have this in xml2rfc is in <texttable>, and my understanding was that 
everybody hates it for that. (Right?).

Best regards, Julian



More information about the rfc-interest mailing list