Re: [css-regions] issue 16858 redux

On Jan 9, 2014 7:02 PM, "Alan Stearns" <stearns@adobe.com> wrote:
>
> Hey all,
>
> The main remaining issue in the CSS Regions specification is 16858 [1]. It
> proposes to make flow-from not apply to elements, in favor of making it
> apply to CSS-generated containers only. I will be asking the working group
> to resolve to close this issue when we meet in Seattle, but I would like
> to prime that discussion with some debate on the list, as I think there's
> only a handful of people who are passionately interested in this issue.
>
> The main argument for the issue is the position that content should be
> separated from presentation, which is a good theoretical stance. But this
> theory does not match practice. HTML elements are used as presentational
> boxes and containers *nearly everywhere*. Server and client code routinely
> take content markup and mash it into a presentational HTML template. In
> some cases, using named flows and elements as regions can provide more
> content/presentation separation than current practice allows [2].
>
> The most basic argument I have against this issue is that it doesn't make
> sense to have a CSS property that does not work on elements. The only
> other instance of this is 'content', and we plan on extending its use to
> elements. I think it's preferable to design properties that are as widely
> applicable as possible.
>
> One thread of argument has been that flow-from should only apply to the
> proposed ::slot pseudo-element in a grid container. Restricting regions to
> ::slots introduces a dependency - named flows could only be used with grid
> positioning. This is much too restrictive - there are good uses for named
> flows that either do not need to require grid (static positioning of
> regions), or do not work well with grid (see the navigation overflow menu
> [3]). Cross-feature dependencies should be avoided when possible.
>
> Most importantly, disallowing elements as regions reduces or eliminates
> the value of using named flows to explain fragmentation [4]. The web is
> built on elements, and extending functionality works when there are
> elements to start from. We might someday define CSS-generated containers
> with extension points, but they currently are a dead-end. The CSSOM that
> is defined for named flows only works with actual HTML elements, so in
> order to use CSS Regions as a building block for the extensible web,
> flow-from needs to apply to elements.
>
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16858
> [2] http://lists.w3.org/Archives/Public/www-style/2013Dec/0408.html
> [3] http://lists.w3.org/Archives/Public/www-style/2013Nov/0401.html
> [4] http://lists.w3.org/Archives/Public/www-style/2013Oct/0675.html
>

I understand the hesitation here and I sympathize with the conceptual
desire to fully separate presentation from structure - in fact, I want
myself that quite badly.  Perhaps there is something considerably missing
in a larger scheme, like an explanation of what is painted on the screen
which has a default implied mapping to DOM, but which is somehow clearly
itself decoupled - maybe some kind of render tree of boxes and shapes that
is a projection created from, but not actually the DOM  is hidden under
there just waiting for an elegant definition to unearth it and provide some
sanity we could build upon - I honestly don't know.  What does seem to be
the case, however, is that:

1. markup via template for providing presentational concerns is common and
actually grokable and expanding quickly to the client side.  In this
scenario, the proposal improves the situation by helping to decouple
further.

2. The only counter proposal i have seen is overflow: fragments which seems
(to me: to not be very actively moving forward and, given where it is
currently, I have difficulty seeing it solving the same problems.  Very
possibly it could and it is just under defined - this is just my simple,
honest assessment.  Either way it seems hard to call it a real alternative.

3.  It's very easy to let perfect be the enemy of good here and think that
we could define one or more very good high level interfaces which let this
be pure CSS.  I think that this is unlikely - I've yet to see an answer
that fully separates without adding what seems to me dubious amounts of
complexity - again, just my take on it - but i feel like the regions
proposal has a lot of decent answers and bits that would allow us to
harness the creative powers of the larger community for ideas in higher
level abstractions toward the perfection we are searching for and provide
some semblance of order for lots of developing specs.

I think it would be a shame to let this bug be the main reason for
disagreement unless someone has a really great alternative pretty soon.