[rfc-i] <list> brainstorming

Julian Reschke julian.reschke at gmx.de
Tue Jan 28 23:30:36 PST 2014


On 2014-01-28 23:13, Jim Schaad wrote:
> I am not clear what you mean by block and flow elements.  These are not
> necessarily terms that I am familiar with and therefore I probably think of
> them in different terms than you do.

See <http://www.w3.org/TR/html4/struct/global.html#h-7.5.3>, where the 
W3C says "inline" when I said "flow".

<section>, <texttable>, <t>, <figure>... are block-level elements.

<eref>, <cref>, <spanx> ... are inline elements.

> I tend to think in very different terms than what you do.  To me a block
> element is one that is more or less fixed in size and layout, while a flow
> element is one that can be re-shaped on the flow during layout to change how
> things look.  Thus to me a figure is a block but a paragraph (and thus a
> list) is a flow element.  This means that I am not sure what this means.

Sorry for the confusion.

> There may be some real benefits to making list elements belong inside of t
> elements.  The first thing it does is simplify the ability to reference an
> object (i.e. list item #3 in paragraph 4) as all of the things that are
> going to be at the top level are going to be either paragraphs or something
> that is very definitely not a paragraph (i.e. a figure).

Understood, but that's simply a problem for the processors to fix (they 
need to count both <t> and <list> elements).

A harder problem BTW is how to count the paragraphs inside a list.

>> 3) Abusing lists to generate indented paragraphs is awful. If we want
>> indented paragraphs, then those should have their own element.
>
> I don't agree with this.  To me  hanging list is in fact a list and, as
> such, is an atomic thing that I can think about.

Even when there's nothing list-like about it; such as a single "Note:..."?

>> 4) Limited control over labels. For "letters" and "numbers" for nested
> lists we
>> rely on heuristics that are not well documented and implemented. We also
>> do not support different numbering styles (HTML lists for instance support
>> roman numerals...). For "symbols" there's an undocumented PI that some
>> processors support. We should clean this up, stealing the good parts from
>> HTML/CSS.
>>
>> 5) Text content in attributes (hangText attribute) is bad.
>
> This is as good of a heuristic as using something like <b/> following to
> identify that this is hanging text.  I don't have a purity argument here
> that I am willing to agree to.
>
>>
>> 6) Mixing label style with content (format attribute) is bad.
>
> I don't understand what you are saying here

The "format" style provides both styling information and text content.


>> 7) Missing list style "dictionary" (similar to "hanging", but with the
> actual text
>> always starting on a new line).
>
> +1
>
> Jim

Best regards, Julian



More information about the rfc-interest mailing list