Re: [csswg-drafts] [css-transforms-2] proposal new transform-style: detached (#4242)

> I guess I need the explainer because I'm not sure how this is supposed to work, or whether it is useful, or why anyone would want to do it.

Yes, sorry. The hurricane caused our office to close and most of my team fled to higher ground :-)

> I assume the idea is that you're looking at a Web page in some AR/VR space, and you want the elements in that page to project out (or back) from the flat surface into the hosting space?

Correct. Elements will be able to "break out" of the web page.
There is a Google [slide deck](https://docs.google.com/presentation/d/1ORdKs1wNe7QysRYSBtmW8LnMTFRu69gEwyOSrjIaZyA/edit#slide=id.g186a1bfda4_0_148) on declarative 3D. `transform-style: detached` would allow you to design such a page and have it still look good on a traditional 2D browser.

> Do you expect the hosting space to apply effects to the projected elements? 

Standard CSS effects such as blur? Yes (see earlier in this thread)

>For example, will they respond to lighting, cast shadows, etc? 

That would depend on the window manager of the UA. For Magic Leap, we only have a global light and no shadows but as the technology advances, this would certainly be possible.

> If so, that means the hosting space needs pixel access, which we can't allow. If not, the effect will look so weird it isn't worth doing.

I don't know why you need lighting and shadows. The google example doesn't have them either. Don't forget that our browser is a [3D prism](https://creator.magicleap.com/learn/guides/design-prisms) in the [Landscape](https://creator.magicleap.com/learn/guides/design-landscape). The user can place it anywhere and walk around it. Each eye will get the correct projection of the browser plane and each detached element so it shouldn't look weird.

Of course the window manager needs pixel access but it already has pixel access to the browser plane so there's no privilege change. The important part is that the process that does layout and javascript won't have more access than before.

> And what happens as 3d elements are scrolled into view (they were clipped by the viewport)? Do they all of a sudden appear in 3d space? Does half of them appear if they are partially clipped?

Yes. Objects are clipped by what we call a "prism" which is basically a clipping cube in space. The [google slides](https://docs.google.com/presentation/d/1ORdKs1wNe7QysRYSBtmW8LnMTFRu69gEwyOSrjIaZyA/edit#slide=id.g186a1bfda4_0_153) have an example of that as well. (BTW our prismatic library already does this when models scroll out of view)

An open question is what should happen with `overflow: hidden`.

> And why is this just applying to CSS transforms? Wouldn't a better case be having WebGL objects from the page exist in the hosting space?

There is a [proposal](https://github.com/immersive-web/proposals/issues/31) from @NellWaliczek which is basically that. It's definitely something we want to consider later but right now, we want to do something that can be done easily and with regular CSS semantics (instead of difficult WebGL, lots of javascript and tricky compositing).

> My gut feeling is that we should continue to assume that CSS always projects onto a flat 2d surface. Within that surface you can emulate 3d sub-spaces, but the end result is always 2d. Just like the `canvas` element.

3D transforms already establish a 3D scene. Why not actually make them part of our environment?

Also, we're no longer constrained by 2D surfaces :-)
AR/VR is the next frontier and we want to give the browser access to enable cool new experiences.


-- 
GitHub Notification of comment by rcabanier
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4242#issuecomment-528189807 using your GitHub account

Received on Thursday, 5 September 2019 04:17:55 UTC