[rfc-i] <list> brainstorming
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
>> 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).
Best regards, Julian
More information about the rfc-interest