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



On 10/23/13 11:14 AM, "Håkon Wium Lie" <howcome@opera.com> wrote:

>David Baron 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
>
>Agree -- this attacks the foundations of both HTML and CSS. To quote
>myself:
>
>  We wanted HTML to remain a semantic language so the content could be
>  presented on all sorts of devices, not just visual ones. Therefore
>  we developed CSS. So, in a way, you could say that CSS was developed
>  to save an even more important language, namely HTML.
>
>  http://www.root.cz/texty/hakon-wium-lie-css-was-created-to-save-html/

>
>The way regions are currently designed and promoted, lots of
>presentational elements will enter the web.

I have heard you and a few others state this before; though you will
likely discount my comment due to my affiliations - "MSFT! ADBE! What is
wrong with this guy!?" - I still do not understand this reasoning, except
at a somewhat theoretical level. A very, very, *very* large number of web
sites serve pages generated by merging a template - an HTML layout built
out of mostly presentational container *elements* - with the actual
content; this is often done dynamically, from local news sites to product
pages on Amazon and almost everything in between. So the pattern of using
elements for purely presentational/layout purposes is not going to 'enter'
the web: it *is* the scaffold behind much of the web we consume every day
and it has been for many years already. While there may be valid
objections to enabling layout/content merging on the client using CSS and
elements, warning it may usher in some new era everyone has been
practicing on millions of servers for a decade sounds an awful lot like
worrying we'll quickly end up with oceans and rivers if people don't start
bottling all that rainwater. A bit late, in other words. (I am of course
being facetious for emphasis; I honestly do not grasp this argument)

It is true that Regions, on their own, do nothing to alter this pattern.
But I do not believe it is fair to say they create a new issue or add to
the existing burden (if one believes it to be a burden). Moreover, because
the ability to easily fragment content across an arbitrary chain of boxes
is an attractive capability that is too costly to handle on the back end,
the combination of named flows with box generation mechanisms like
overflow:fragments may not only enable new use-cases but have a positive
impact on how much presentational tag soup is actually needed to get the
job done in tomorrow's content.

Now, if we do want to fix the status quo then much more work is needed
above and beyond the ability to flow content in region chains or
generating fragments from overflow e.g. we may want a way to define those
templates everyone builds in HTML using CSS instead. But using elements in
the meantime seems unlikely to make things worse when this is how the web
already works.

Finally, since the flow-* properties allow authors to manipulate the box
tree independently from the DOM tree they would seem to increase the
separation of content from presentation. (And I suspect discomfort with
handing authors this much power may be part of what makes Regions as
exciting to many of them as it is worrisome to some implementers).


> 
>
>I suggest, again, that using elements is removed from the
>specification and that regions are declared & described in CSS.

overflow:fragments currently depends on an element to hold the content and
provide the default style for fragment boxes i.e. there might be no
semantic need for this container and its use can be purely presentational.
Do you object to this as well? Same deal with multicol: if I have a bunch
of sibling paragraphs I want to flow in three columns I need to wrap them
in a multicol element for which I have no other use than the production of
these column boxes. Same goes for grid or flexbox containers. Are those OK
because they require only one unnecessary element vs. several? If so
flowing content in an overflow:fragments element should certainly be
helpful. But that can't really happen without flowing content into at
least *one* element….


>
>-h&kon
>              Håkon Wium Lie                          CTO °þe®ª
>howcome@opera.com                  http://people.opera.com/howcome

>

Received on Wednesday, 23 October 2013 22:46:54 UTC