W3C home > Mailing lists > Public > www-style@w3.org > July 2013

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

From: Alan Stearns <stearns@adobe.com>
Date: Fri, 19 Jul 2013 11:46:20 -0700
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <CE0ED74A.2DB6D%stearns@adobe.com>
On 7/10/13 3:12 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

>On Wed, Jul 10, 2013 at 2:26 PM, Alan Stearns <stearns@adobe.com> wrote:
>> On 7/10/13 2:08 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>>>On Wed, Jul 10, 2013 at 1:59 PM, Alan Stearns <stearns@adobe.com> wrote:
>>>> Do you have a use case for creating a region chain out of list items?
>>>>Do
>>>> people use lists to create layouts?
>>>>
>>>> Or are you asking me to add an additional caveat that flow-from does
>>>>not
>>>> 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
>>current
>> 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.

Given this feedback and an off-list conversation with Rossen, I've
reverted the change.

Thanks,

Alan
Received on Friday, 19 July 2013 18:46:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:32 UTC