Re: [css-regions] issue 16858 redux

Hey,

am I correct in assuming that this would basically mean that CSS Regions
would only work as as internal mechanism to do CSS column layout, pages
media output, etc.? It seems that would severely limit the use cases for
CSS Regions. If there is no such thing as CSS Regions, then instead (much
slower) javascript solutions will have to be found. Instead of separating
content from presentation, it means that one has to add an element around
every word or maybe even every letter of the text that makes out the
presentation, so that the javascript code can know exactly where it is and
make the cut-off at the right place. This is pretty much what Google Docs
and similar programs do today.

With CSS Regions in place (and the mentioned bug resolved), the relation
between content and presentation could for example look like this:

presentation: website (a bunch of javascript, css and html) asks server for
article content via websocket and once it arrives in the client flows it in
a named region through various element-boxes.

content: the content is sent separately from the server to the client upon
request. If the client changes any of the content (for example through an
editor interface), it can send the html of the content back to the server
for saving.


Without CSS Regions:

presentation: website (a bunch of javascript, css and html) asks server for
article content via websocket and once it arrives in the client, starts
hacking it up in sizes that fit the individual boxes individual parts of it
will fit into. In order to find out how much content goes into each box, it
likely has to put elements around lots of small parts of the content.

content: arrives from the server upon request. will then be hacked up. If
it is being changed while in the client, it has to be put together to be
one long html-string, before being sent back to the server.

Unless I have misunderstood something, the CSS Region way of doing things
allows for the content to be much more separate from the presentation than
the current way of doing things.
CSS Regions does not seem to be about extremely extravagant layout
functions. Since the days of Quark Express the option to define containers
and to have the content flow from one to the other, while not covering
graphic elements, is seen as a fairly standard tool of any DTP program --
take Scribus or the Adobe products.

The question is: Why should the web, which is all about design these days,
not have this option?


On Mon, Jan 13, 2014 at 8:08 PM, Brian Kardell <bkardell@gmail.com> wrote:

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



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