Re: CSS Regions considered harmful (was: [css-regions] issue 16858 redux)

On Thu, Jan 23, 2014 at 7:13 PM, L. David Baron <dbaron@dbaron.org> wrote:

> On Thursday 2014-01-23 12:58 +0100, Johannes Wilm wrote:
> > I contacted the Firefox list or IRC a while back and asked for advice on
> >  how to implement something like
> > http://sourcefabric.github.io/BookJS/using the fragment-overflow
> > specification. The answer was that this isn't
> > possible, because the fragment spec requires all the fragments to be
> > siblings of oneanother.
>
> What is it that isn't possible?
>


For the fragmented contents to be treated as child nodes of different
elements -- they all have to be siblings. At least that seemed to be the
view of the person who answered. We have one general page flow, and then
footnotes flowing out from their position on the pages.


>
> > This seems to significantly limit the use cases of
> > fragment-overflow. If you should decide to go for the fragment-overflow
> > specification instead, I would strongly recommend that you extend it to
> at
> > least cover all the current use cases of CSS Regions.
>
> Just because Regions can do it doesn't mean it's a feature that
> belongs in the fragmentation system.


Well, maybe your take on it is different than the Firefox person I spoke to
at the time, but the things I asked about were plain impossible according
to him -- no alternative available.

I understand that HÃ¥kon has another specification specifically aimed at
books, but as soon as one moves to more complex cases (for example SVGs of
a formula created by Javascript being part of the header, or headers being
shortened versions of titles), it doesn't work, and being this
functionality is kept away from the web developer, there is no way to
extend it to do it with Javascript either, at least not in a clean manner.

As I understand the current version of the fragment-overflow spec, it would
work for a very limited subset of usages of where CSS Reagions would apply.



>  I think regions is addressing
> use cases by reordering fragments that ought to be addressed by the
> layout model rather than by the fragmentation model.  Addressing
> layout features in the layout model allows the layout model to be
> designed for performant in-order layout to address its use cases.
> This, in turn, doesn't require that existing layout systems,
> designed for layout in content order, end up being used by regions
> out-of-order in a way that's either going to be slow or buggy
> (depending on which sacrifices the regions spec makes).
>

I am not a browser developer, but judging by the current state of CSS
Regions in Chrome and Safari and comparing some of the more complex book
layouts we have been able to create with it with the rendering time had we
tried to create something similar using LaTeX, I am quite impressed by the
speed.

Stability doesn't seem to be much of an issue either. From the perspective
of a web developer trying to create an editor interface in a browser, if
you guys want to fix something (starting by creating a proper spec for it),
it would be contenteditable, not CSS Regions.


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



-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.com