Re: [css-regions] restricting flow-from further

On 7/10/13 3:12 PM, "Tab Atkins Jr." <> wrote:

>On Wed, Jul 10, 2013 at 2:26 PM, Alan Stearns <> wrote:
>> On 7/10/13 2:08 PM, "Tab Atkins Jr." <> wrote:
>>>On Wed, Jul 10, 2013 at 1:59 PM, Alan Stearns <> wrote:
>>>> Do you have a use case for creating a region chain out of list items?
>>>> people use lists to create layouts?
>>>> Or are you asking me to add an additional caveat that flow-from does
>>>> apply to elements whose display-extras property resolves to list-item?
>>>Neither.  I'm saying that if you can put a region into a display:block
>>>element, excluding display:list-item elements (which desugar into
>>>"display-outside:block-level; display-inside: block; display-extras:
>>>list-item;", identical to what "display: block" desugars into save the
>>>last property) is just perverse.  It's a restriction for no reason.
>> Given that display-extras is merely a proposal, I'm skeptical that
>> implementations have refactored list items sufficiently that extending
>> region support from blocks to list items would be a simple task. The
>> reason for the restriction would be to avoid implementation cost for
>> little to no gain.
>I protest a decision being made based on implementation concerns that
>have nothing to do with any theoretical inefficiency, nor on any
>merely-practical-but-still-large issue, but merely on the fact that
>some impls use separate classes for list items and blocks.  There's no
>reason to break the conceptual model here.

I agree in principle, though I think the call is quite pragmatic in
practice; realistically, the following is quite likely:
1. Because there are no clear use-cases and...
2. …most current list-item implementations may well fail this particular
set of Regions testcases and...
3. …no one will be in a hurry to fix #2 because of #1, never mind the lack
of any obvious urgency in messing with list-items to conform to a spec
that is not even written yet….

…the WG would end up punt list-item regions to the next level.

One may argue this is premature spec optimization. I see it more as
watching out for the perfect getting in the way of the good. Spinning
level 1 spec/testing cycles on something with no good use-case that
depends on some to-be-written spec with an unknown timeline is something I
would 'protest', also.

But if you came up with a decent use-case it'd be a different matter.

Received on Thursday, 11 July 2013 02:49:29 UTC