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

On Sun, Oct 27, 2013 at 6:47 AM, François REMY
<francois.remy.dev@outlook.com> wrote:
> ± I believe this is the correct next step towards the end point you're after,
> ± 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.
>
> Another way to state that:
>
> - CSS Regions is the angular stone of distributed content. If you take CSS Regions and JavaScript, you can obtain the same result as any other proposal because it remains generic enough to solve all use cases.
>
> - Experimentation will prove that some patterns are not /adequately/ solved by raw CSS Regions only. Those patterns will therefore get attention and new, specialized procedures will be put in place to cover them more adequately.
>
> We've seen this with "overflow: fragments" and we will continue to see this with page templates and another techniques in the future. I'm confident the "content" property will evolve dramatically in the process to make sure all layouts, even the most complex ones, can still be achieved in CSS without relying on dummy elements.
>
> I do not believe "overflow: fragments" or "gcpm" alone or even combined can solve all the use cases for which we need content flows. And they don't have to. Bear in mind, implementation interest comes as use surges, and use cannot surge in an environment that's not favorable to experiments. Implementing CSS Regions in browsers will open the door to this experimentation.
>
> ----
>
> I think implementing CSS Regions is the right move right now, at least if we follow the Extensible Web Manifesto principles:
>
> • 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.

~TJ

Received on Monday, 28 October 2013 17:15:52 UTC