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

Re: Properties of Custom Layout

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 4 Jun 2015 11:57:08 -0700
Message-ID: <CAAWBYDDTS_rpGwxA5yV0Lon6dn5kU_pKmSxFE2brfwcU5c_YnA@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 8:02 AM, Ojan Vafai <ojan@google.com> wrote:
> On Wed, Jun 3, 2015 at 1:14 PM Fran├žois REMY <francois.remy.dev@outlook.com>
> wrote:
>> >> - What if we want to emulate something like scrollbars or carousels?
>> >> Should custom layout be allowed to layout out boxes that are not in
>> >> the DOM for their own purposes, and get some basic events on them
>> >> and on the layouted element itself if it's focusable (I was thinking
>> >> about: pointer-over, pointer-click, focus, enter-key, space-key,
>> >> left-key, right-key, up-key, down-key)?
>> >
>> > Custom Layout will need to know about boxes not in the DOM for layout
>> > purposes (I.e. the fragment tree). I'm not sure what form this will take
>> > yet.
>> >
>> > As an example, a text node which is a child of a flexbox, can be wrapped
>> > in an anonymous box which isn't in the DOM.
>> Okay, so a custom layout can create anonymous boxes. It may be able to
>> display a scrollbar, for instance.
> Custom layout might need to know about boxes not in the DOM. I don't think
> we should allow it to *create* them during the layout though. It's very hard
> to reason about the tree you're iterating over being modified.
> Maybe we want to say that the style computation phase can create them, e.g.
> for the case Ian pointed out. Or, maybe we want to say you need to modify
> the actual DOM to get what you want. That'll be something we figure out as
> we work out the details of how something like the flexbox example Ian gave
> should work.

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.

Received on Thursday, 4 June 2015 18:57:56 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 4 June 2015 18:57:56 UTC