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

Re: [css-regions] Named Flows, Elements and Box Generation

From: Alan Stearns <stearns@adobe.com>
Date: Wed, 23 Oct 2013 10:24:25 -0700
To: "L. David Baron" <dbaron@dbaron.org>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <CE8D512F.14539%stearns@adobe.com>
On 10/23/13 8:51 AM, "L. David Baron" <dbaron@dbaron.org> wrote:

>On Monday 2013-10-21 17:39 -0700, Alan Stearns wrote:
>> The way that named flows and overflow:fragments interact is through
>> applying flow-from to the overflow:fragments element itself. It
>>*requires*
>> that flow-from applies to elements. So I think this shows that the
>> elements issue [5] should be closed as well. If anything, we need to
>> restrict flow-from from applying to ::nth-fragment() pseudo-elements in
>> the Overflow draft, in exactly the same way that the content property
>>does
>> not apply to these particular pseudo-elements. The flow-from property
>> needs to apply to elements to interact properly with the rest of CSS.
>
>I think the underlying motivation for [5] includes (at least) that:
>
> (a) the use of regions encourages creation of extra markup for
> stylistic purposes only, which is inconsistent with separation of
> content and presentation

As I mentioned in the paragraph above the one you quoted, each of the
interactions between overflow:fragments and named flows that I described
can be used without adding any extra markup. Our contention all along is
that as we add ways to create boxes in CSS, you should be able to use
those new mechanisms to create region chains. It's the fact that you *can*
assign flow-from to an element that allows this interaction, and allows
the use of named flows with overflow:fragments without adding any extra
markup.

>
> (b) the model of creating elements to be regions is inconsistent
> with the typical model of writing CSS where new property
> declarations cause observable changes, without requiring a
> complicated set of declarations and content changes to achieve an
> Effect

I'm not clear on how this fits into [5], or if this is a separate issue. I
think that using two declarations to describe "display *this* over *here*"
is a fairly good match for what's being expressed. And I'm not sure what
you mean about requiring a set of declarations to get an observable change
- declaring flow-into by itself definitely gets you an observable change,
as does declaring flow-from by itself.

>
>I don't see how the above addresses these problems.
>
>-David
>
>> [1] http://lists.w3.org/Archives/Public/www-style/2013Oct/0239.html

>> [2] http://lists.w3.org/Archives/Public/www-style/2013Oct/0250.html

>> [3] http://lists.w3.org/Archives/Public/www-style/2013Oct/0266.html

>> [4] https://www.w3.org/Bugs/Public/show_bug.cgi?id=15733

>> [5] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16858

>
>-- 
>𝄞   L. David Baron                         http://dbaron.org/   𝄂
>𝄢   Mozilla                          https://www.mozilla.org/   𝄂
>             Before I built a wall I'd ask to know
>             What I was walling in or walling out,
>             And to whom I was like to give offense.
>               - Robert Frost, Mending Wall (1914)
>


Received on Wednesday, 23 October 2013 17:24:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 23 October 2013 17:24:58 UTC