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

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

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.

-David

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