Re: [css-regions][css-overflow] enhancing overflow:fragments use case 2

On 1/26/14, 7:10 PM, "L. David Baron" <dbaron@dbaron.org> wrote:

>On Sunday 2013-10-13 17:11 -0700, Alan Stearns wrote:
>> On 10/7/13 5:54 PM, "Alan Stearns" <stearns@adobe.com> wrote:
>> >The next case I'd like to describe is taking an instance of
>> >overflow:fragments and enhancing what's available to a JavaScript
>> >developer by adding a named flow. There are a lot of capabilities we've
>> >defined in Regions CSSOM [1] that are applicable and potentially
>>useful in
>> >an overflow:fragments layout.
>> 
>> 
>> I have a further point to make on the CSSOM we've defined for named
>>flows.
>> Making the results of fragmentation discernable via script allows all
>> sorts of extensions to the basic named flow functionality we define in
>>the
>> spec. The named flow CSSOM is 'explaining' fragmentation in the
>>Extensible
>> Web Manifesto sense [1].
>
>I agree that having an API to make the information about
>fragmentation accessible seems useful.  But exposing things is also
>dangerous in that it reduces our ability to change them in the
>future, and it also may well be more work than it seems to make
>truly interoperable.
>
>The flow-from/flow-into hack you propose in this thread doesn't feel
>to me like the right way to do that, though; it seems too hacky,
>especially if this is a use case we ought to care a lot about (which
>I'm not sure of).
>
>Nor, for that matter, is it clear to me whether the APIs we expose
>the box tree through should just expose things like fragments and
>flows, or whether they should also expose other cases where the box
>tree differs from the content tree (for example, anonymous table
>objects, anonymous blocks when a block contains both blocks and
>inlines, block-within-inline fixup).

Exposing fragmentation via the named flow APIs does not limit us from
exposing other parts of the box tree. I expect there are other places
where it would be useful to expose more details. I’ve only been
concentrating on fragmentation, which has produced some very nice results
in the applications developed in both IE’s and Safari’s versions of
regions [1]

>
>In all cases, exposing details gives authors more information about
>what's going on underneath.  It also requires us to do substantial
>amounts of work to align implementations and specifications where
>they currently differ.  There are many places in CSS where
>implementations don't actually construct the box tree that's
>specified in the spec, but they produce results indistinguishable
>from the spec's results.  If we were to expose the box tree via an
>API, in some of these cases we'd probably want to adjust some or all
>implementations to match the spec, but in others we may well want to
>adjust the spec to match implementations, because the spec specifies
>the boxes that it does only for the results they lead to, and not
>for whether the API exposed is sensible.  So exposing box tree
>details interoperably could be a lot of work.

I agree that exposing legacy box tree results could be problematic for the
reasons you describe. It’s fortunate then that what we’re exposing in CSS
Regions is new and separable from all of that. And use of the small part
that is exposed by the named flow APIs could give us an idea of whether it
would be worth the effort to expose more.

Thanks,

Alan

[1] http://lists.w3.org/Archives/Public/www-style/2013Dec/0258.html

Received on Monday, 27 January 2014 05:15:06 UTC