[rfc-i] Structure of <li> in v3
paul.hoffman at vpnc.org
Sun Feb 16 14:58:53 PST 2014
On Feb 16, 2014, at 2:36 PM, Paul Kyzivat <pkyzivat at alum.mit.edu> wrote:
> On 2/16/14 5:17 PM, Paul Hoffman wrote:
>> On Feb 16, 2014, at 1:36 PM, Paul Kyzivat <pkyzivat at alum.mit.edu> wrote:
>>> Why are 'hangtext' and 'term' attributes of <li> rather than contained elements?
>> That was a design decision that is being discussed. In that proposal, it made it easy to create the list items. In a different proposal, the list item takes two elements (and is thus more remembering and typing for the author) but a possibly-clearer content model.
> I realize there is a backward compatibility problem for 'hangtext'.
> But (as is often commented on here) it is easily solved with a conversion tool.
> Re ease of use I think it is just number of characters typed:
> <li hangtext='foo'>
Those are incomplete. The proposals are:
For the second, Julian and others expressed a dislike for elements whose content model is both free text and required elements. Thus, the following would not be likely accepted:
> The advantage, in addition to a clearer content model, is that one can embed other formatting elements.
> Also, while the formatting differs between "hanging" and "dictionary" lists, there isn't a lot of conceptual difference between the 'hangtext' and 'term' element/attributes. I wonder if a common element could be used for both. (E.g., 'subject'.)
> Another advantage to that would be that you could switch a list between "hanging" and "dictionary" styles with a single change.
More information about the rfc-interest