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

On Mon, Oct 28, 2013 at 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.

I recommend reading the Extensible Web Manifesto
<http://extensiblewebmanifesto.org/>, which I and a lot of other spec
authors and major library developers signed.  It says precisely what I
just did - the correct way to design the web platform, established
through years of experience, is to figure out the low-level primitives
and expose those, then additionally offer high-level sugar that
composes those primitives automatically for you to solve common
problems.

That way, authors aren't stuck with precisely the solution that we
dreamed up, and have to reinvent everything from the ground up if they
stray just a bit too far, but neither are they forced to write
everything themselves in basic JS.  Best of all worlds - easy use of
common things, easy customizability for slightly less common things,
and *possible* creation of brand new things that use the same
underlying semantics.

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

As Alan keeps saying over and over again, Regions is totally
compatible with, and frankly *begs* for, better ways to generate boxes
in CSS.  However, the underlying functionality, the primitive that
we're exposing, doesn't intrinsically care about whether it's filling
a box that originally came from CSS or HTML.  They're equivalent at
the level of the primitive, and we shouldn't try to complicate things
further than that *at the level of the primitive*.  Doing so will just
mean that authors have to jump through more hoops when they try to do
something outside of what we've imagined.

Let primitives be primitives.  Offer sugar on top of the primitive to
make common things easy, and encourage good practices.

~TJ

Received on Monday, 28 October 2013 21:58:33 UTC