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



On 10/28/13 2:46 PM, "Håkon Wium Lie" <howcome@opera.com> wrote:

>Tab and others wrote:
>
> > > ± Håkon. First, explain fragmentation via named flows and region
>chains.
> > > ± Provide scripting access so that people like Johannes do not have
>to wait for
> > > ± browsers to implement more 'first class citizens' of CSS. Then see
>what
> > > ± cowpaths we should pave from actual use on-screen in browsers.
>
> > > • Focus on adding new low-level capabilities to the web platform
>that are secure and efficient.
> > > • Expose low-level capabilities that explain existing features, such
>as HTML and CSS, allowing authors to understand and replicate them.
> > > • Develop, describe and test new high-level features in JavaScript,
>and allow web developers to iterate on them before they become
>standardized. This creates a virtuous cycle between standards and
>developers.
>
> > This, precisely.  Current Regions is the low-level primitive.
> > Attempting to design just a high-level primitive (or set of them) will
> > *guarantee* that useful use-cases will fall through the cracks, and be
> > unable to be addressed.  For the health of the platform, we *must*
> > design by starting from low-level primitives to make lots of things
> > possible, and then adding higher-level sugar on top to make common
> > things easy.
>
>I see two independent questions here:
>
>  a) should we design low- or high-level features?
>  b) should we base new CSS designs on presentational elements?
>
>For a), I think we should do both. If you design a new car, do you
>start by thinking about the nuts and bolts, or do you start by drawing
>the chassis? Good car designers probably do both. I can see use cases
>for basic regions (I even co-authored a proposal in 1996 [1]), but I
>don't have to wade through many javascripted cowpaths to know that
>pages, columns, and spreads are fundamental features of documents.

Some basic engine features will exist regardless of the final chassis,
body or driver dashboard. The point of the manifesto quoted by Tab and
others is that such core features are best exposed to the author (whereas
we use to keep them buried as 'magic'). In other words, hiding the ability
to flow content through containers should be exposed to authors without
being arbitrarily constrained to some high-level constructs designed for
specific use-cases that may well not fit their needs. If authors want to
skip the syntactic sugar and build a different feature based on elements,
they should be able do so. Because pages, columns and spreads is not all
there will be. 


> 
>
>For b), I think the answer is no. And if you disagree, maybe you
>should consult the HTML WG before proceeding.

The HTML section you link to refers to legacy elements like <font>.
Regions neither requires nor introduces this type of presentational
elements. This section of HTML does not in any way preclude the need for a
wrapper element in order to flow content into columns, of another wrapper
element for overflow:fragments, or of three of them to contain a
fragmented named flow.

>
>[1] http://www.w3.org/TR/WD-layout

>[2] 
>http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.h

>tml#presentational-markup
>[3] 
>http://www.w3.org/html/wg/drafts/html/master/introduction.html#presentatio

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

>

Received on Monday, 28 October 2013 22:34:57 UTC