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



On 10/26/13 4:47 PM, "Håkon Wium Lie" <howcome@opera.com> wrote:
>
> > One of the most basic things to
> > position elements is to have an outer element with the
>position:absolute
> > inside an position:relative element. I don't see how adding an extra
> > element for CSS Region-flowing is much different.
>
>The fact that 'position: relative' establishes a containing block has
>led to much abuse. We're trying to not make the same mistakes.

I think you mean the fact that position:static did *not* establish a
containing block is what led to position:relative 'abuse'? I'm not sure
how this relates to using named flows with overflow:fragments together
though.  

For the main use-case - a primarily textual flow of content - and assuming
an element chain, the number of such elements is likely to be quite small
in practice as text needs a minimum amount of horizontal and vertical
space; the maximum number of such elements in most apps will likely be far
smaller than the number of position:relative elements used by a typical
site. To take one extreme example, let's imagine Pinterest uses a region
element for each pin column; these columns are too narrow for text and the
site will produce as many as necessary to cover the space you give it. In
a full-screen browser window on a 27" screen, Pinterest will produce 10
columns. On most computers it'll be 2-4. On tablets, you may get 2 in
landscape mode. For a site like nytimes.com these numbers would be likely
be halved. Keep in mind this would be a temporary requirement; once
overflow:fragments and other box generation mechanisms are available the
same can be done with one extra element, just as with multicol, flexbox,
grids etc.

There are of course pragmatic concerns as well i.e. pseudo-elements are
and will remain functionally crippled for some time. You still can't
attach events to them or update their style from script, they're not
accessible etc. So if I wanted to build a web version of the widely used
Tweetdeck app, one named flow per feed would be a great way to separate
the content - individual feeds of tweets - from the visual feed columns in
the app. But as soon as I want to let the user reorder these columns using
touch or the mouse pseudo-elements make it extremely difficult since I
cannot attach the event handlers I need. As long as that is the case the
*option* to use elements is something authors will demand.

Received on Monday, 28 October 2013 14:41:06 UTC