- 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>
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