W3C home > Mailing lists > Public > public-houdini@w3.org > June 2015

Re: Properties of Custom Layout

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 5 Jun 2015 12:14:23 -0700
Message-ID: <CAAWBYDAsRrFweEFVjyF-iZ2oMjpmdZkt0TNU7HX5rMztjqAe4A@mail.gmail.com>
To: Ojan Vafai <ojan@google.com>
Cc: Fran├žois REMY <francois.remy.dev@outlook.com>, Ian Kilpatrick <ikilpatrick@chromium.org>, "public-houdini@w3.org" <public-houdini@w3.org>
On Thu, Jun 4, 2015 at 11:57 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> I think we can get away with ignoring anonymous box creation for now,
> and adding it into a future version.
> Or, at minimum, allowing only simplistic "correct wrapper" box
> creation, which the engine can do automatically for you.  That is, you
> register somewhere that your custom layout X must be within a Y
> wrapper, and if we don't find one of those, we generate one for you.
> (This assumes that custom layouts are explicitly named, which I
> assumed they would be, so we could, for example, use them in
> 'display'.)  This doesn't give you the full box-tree-rationalization
> that table layout specifies, but it would at least let you say that
> custom-table-cell needs a custom-table wrapper, and the layout code
> can handle arranging it into rows and whatnot on its own.
> Additionally, we'll need to handle raw text inside of custom layouts,
> probably generating an anonymous box automatically for you as well.

Let me rephrase this a bit.  There's a few points, and they're in a
weird order in the above quote.

1. Regardless of what else we do, v1 of custom layout needs a way to
say "my layout only deals with blocks, not text", and have this wrap
naked text children into anonymous blocks.  This is necessary to
reproduce Flexbox and Grid, which are the simplest of our built-in
layout models (in terms of box relationships, at least!).

2. It *might* be a good idea to let a multiple connected custom
layouts declare that one of them is the "container" for the others, so
that when we see one of the "inner" layout types whose parent box is
not the "container", we can gather it up with its similar siblings and
generate an anonymous wrapper box of the right type.  This is a weaker
version of Table's box-creation rules, but probably okay for most
cases.  It's sufficient for Ruby, for example.  A multi-level layout
like Table just needs to do its own bookkeeping in this scenario, so
if it ends up with a bunch of bare --custom-table-cell layout
children, it has to do the row/body arranging on its own.

3. Or we can defer that to v2, as requiring the containers in the
markup really isn't a burden.

Received on Friday, 5 June 2015 19:15:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:53:23 UTC