Meeting minutes
Spatial CSS (josh-inch)
josh-inch: GH post, asking about pursuing spatial CSS. Ideas kicked around for past few years.
… We wanted to zero in on what is the smallest primitive to give websites depth
… big outcome of last discussion was, how is that going to work with the compositor? etc.
… Did some work in that area, made some prototypes
… [loads slides]
… In principle, we believe in this approach, a simple way to do this.
… We want an intuitive way for developers, who otherwise might not write spatial content, to be able to apply some
… Consider developer building a website, if they knew they could add a few extra lines to a CSS sheet
… maybe lift off the Checkout button
… We think that has the most leverage just to begin
… and we see this as the way to expand into more advanced spatial features
… Layers metaphor is already common. Compositor works with this. Want to pull layers out and adopt them into the system
… FYI I'm a front-end designer, not a browser engineer
… We're not proposing a new app model, just considering the Web today and give it a little more capability.
josh-inch: We're proposing spatial-detach -- tells compositor to give this as a separate layer to system
… System then owns placement etc. of these layers
… Stylesheet might look like this
.product-card {
spatial-detach: plane;
spatial-anchor: element;
spatial-depth: 72px;
spatial-interaction-zone: volumen;
}
josh-inch: This CSS tells the compositor what to do.
… Each detached subtree gets a stable slot that the system can see
… Browser sends geomtry to the compositor.
… Want the system to handle as much as possible.
josh-inch: Thinking about how to build this ability into existing Web. Drop-down components, etc.
… We built a simple prototype [shows demo of some buttons floating above the page]
bajones: What's the fade-out effect when you get close to it?
josh-inch: from the system
josh-inch: This works, performant on our system, but safety -- how to bound the volume
… Input is not something we solved yet
… Also where does this land in our charter? Seems like we need to get this over to CSS and start collaborating with them.
… If we start to move towards the world of handling more spatial stuff in CSS, how do we handle that.
Siyaman: THanks for presentation, really cool and exciting.
… Is the syntax you're using here something your team developed?
… What kind of challenges have you run into? How did you implement this?
josh-inch: I spent a lot of tokens. :)
josh-inch: Syntax is something we discussed previously. Internally discussed what's the absolute minimum, intuitive way to declare this.
… Initially we wanted transform-detached. But now we have 3 lines spatial-detached, transform depth, and [?]
emeyer: Curious about a few things. One is, do you see any way to link spatial depth to z-index?
cabanier: z-index is not spatial depth
ada: Yeah, it's a 2D layering effect. Within the same plane, what's on top of what.
… Once you start bringing things outside the page, it no longer helps
emeyer: The other was spatial-anchor: element. I assume there are other values?
… Is there a way to take something in 3D space and move it aside?
josh-inch: I think so
emeyer: Is there a way to visually associate the thing you moved with the thing you moved from, or ...
josh-inch: Scenario where you're manipulating spatial contents pulled out of page?
… I don't think we should allow that, unless we create a new spatial-manipulation feature.
… I don't thing developers generally expect the user to pull things out of the page.
… but if they want to give the ability for the user to e.g. pull out a 3D shoe, that's a specific feature.
ada: Agreed, that shouldn't come as part of breaking out into a layer
… want to say down the line if you break off a chunk of content, but not by default.
… Doesn't make sense to e.g. pull out the checkout button and put it in the corner of the room
josh-inch: Agreed. Though you could have sub-layers that you might want to be able to move around. E.g. Figma might want to allow that for individual toolbars
cabanier: Assume transforms work?
josh-inch: Yeah
cabanier: Originally we had 3D transforms in CSS. What about that? Rotate?
josh-inch: Could pivot in that direction maybe
… In implementation for this prototype (note we are not shipping this! It's just a demo!) we should investigate transform thing a bit deeper
<Zakim> fantasai, you wanted to talk about that
<yonet> fantasai: on the z-index point, zindex is probably something that should work with layering but depth is a separate property so zindex should only apply if 2 elements exist at the same depth
bajones: Have you had a chance to look through the document Ada put together about that?
… Obviously some similarities, also differences.
… Where are the divergences and what motivates them?
josh-inch: Skimmed through ... for us, coming from product perspective.
… Their proposal seems like it's better system long-term
… But our goal is to capture the developers simple needs
… But we want to make it so simple, that a developer writing HTML/CSS for the first time can easily use it.
… That opens door to new developers.
Ada: The syntax for ours is equally terse for the same functionality.
<Brandel> https://
Ada: There's more for browsers to do, because want to be more forward-thinking about risky things to do
… But for something as simple as raising a button, you set 'spatial' property on an ancestor, and use 'inset-front' or 'inset-back' to move it in z axis.
josh-inch: Originally, I thought developers would be writing this code. But now it seems AI will be writing the code.
… so how much does simplicity matter? Does it change how we think about complexity?
ada: They're so bad at it though.
Brandel: The code they write is awful. Testament to browser developers that it works at all. It was trained on awful developers like me.
<bajones> Ada and Elika's Spatial CSS explainer, for reference: https://
ada: LLMs are good at parsing natural-language, so building for people should make it better for LLMs.
… But also computers are built for people. We should build for people.
<emeyer> Strong +1 to ada’s point.
Brandel: [missed]
Brandel: It looked like there was screen space ambient occlusion(?)
josh-inch: One of the issues I faced was the output by default was no occlusion, and it was a big problem.
… so I added it, at the system level
… I think that kind of thing should be done at the system level
… For example when these panels turn semitransparent, I think that's something the system should handle.
Brandel: In my experience with short depth, dark shadow, would be important to make ppl aware of the necessity
… less ambient light between them
… nice to see that it's a critical issue that needs to accompany anything that does that
josh-inch: Other primitives, radio buttons, etc. do we need to have a shadow default for these components?
Siyaman: When you define that an element, e.g. a button, comes out. Do you have to define a volume for that element?
… and then that volume define how things overflow?
josh-inch: It's put on a plane, so not a 3D volume
… Plane is still defined geometry. So clipping needs to align with the component.
Siyaman: What's the 'depth' property?
josh-inch: Where to place the plane
Siyaman: Oh, it's the offset
josh-inch: Yeah
ada: Let's talk about shadows!
… Not something I described in our proposal ... even though it's 53 pages long ...
… The 'box-shadow' property, while very useful for the last 2 decades, it's just a "3D illusion for 2D pages"
… You're right that cast shadows are a key indicator of depth
… You need it to sell the illusion of 3D. Stereoscophy is powerful but not enough.
… I think it'll be important to have shadows for this
… But until we have more materials for the Web, we should treat Web surfaces as purely emissive.
… When we do have the ability to define alternative materials for them
… it would be useful to be able to define lighting for the page, provides shadows, but is configurable by the developer
… So you could set the ambient color and light color
… I think very quickly ppl will really want to do interesting lighting effects.
josh-inch: Would get out of hand
ada: I don't think so. Syntax today is pretty terse.
… If we want to take this seriously, I think this is the future of the Web
… I think developers will want all the knobs they have for 2D web for 3D web
… This topic is worth its own discussion, not included in our proposal yet, but it's the next thing.
… But need to define what the default material of the Web is
… Right now all content is on LCD OLED screens, they are purely emissive. Might want to tweak that. And then we'll need to deal with shadows.
bajones: Wrt AI, i've seen the arguemnt from various corners that boilerplate doesn't matter anymore because AI
… what matters more in that ocntext is that humans still have to review the output of the AI
… If the AI is creating large volumes of code, and it's dense and hard to read, then that review is going to be much more difficult.
… If you're making AI create stuff without review, then idk what your'e doing.
… Terseness of the code, readability of code, ability comprehend what's happening whether you're writing or reading, still matters even in world of LLMs.
… Because someone has to read it at some point.
… And if it's easy, benefits hand-coders also.
bajones: I find it encouraging that while there are syntax differences and capabities highlighted differently, there are a lot of similarities.
… We need a strong signal, yes this should be spatial
… We need to position once broken out spatially
… Recognize need for new syntax for these abilities
… A lot of the differences are very syntactic style stuff, rather than fundamental model
… So good to see independent approaches converging on same general concept.
<yonet> fantasai: we've been through many phases where people are like you will never need to write code again so it doesn't matter if the end result is not readable to humans, and we don't find that something valuable, human readable code is still programmable.
cabanier: Previous proposal just used CSS transform had nice side effect that if your browser didn't support it, then page still worked.
ada: Back up Josh here. CSS ignores properties it doesn't understand. Because Josh's proposal is all new properties, it'll just be laid out like normal.
… It'll fall back pretty robustly.
… And if you're doing a jiggle, you'll be using a transform for that anyway. I assume the transform will work on top of the spatial layout.
… Same as ours.
cabanier: Why not just use transforms?
ada: They're not enough to do 3D layout. We use positioning syntax for positioning things, and then 3D transforms for transforms on top of that.
… That allows you to do smart things. For example we have a bounding volume, which you are bound to, you can't place context outside it.
… If you position yourself outside that box, we clamp your position into that space.
cabanier: You could just yous 3D transforms, and it would work in both worlds
ada: In our proposal you *could* just use transforms.
… Our proposals are very similars. It makes sense to have distinct transforms vs layout.
josh-inch: Intention was still to use detach transform as the baseline. In implementation, I ran into a lot of bugs. Couldn't create the demo.
… Built on this idea that this would not interfere with what authors would be doing with the site.
… That being said, not fan of having code irrelevant to 85% of ppl using the site. So I hope we can have it be simple.
… Goal is not to have to read a whole spec to use it.
parth: Amazing to see this.
parth: At last F2F, some concern about turning browser into 3D engine framework. You've implemented that. How hard was it?
josh-inch: Initially I asked it to build the spatial-detach feature. But took a few months of going back and forth.
parth: Internals of browser, how hard was it to get this simple thing working?
josh-inch: In the end, I coudl easily iterate on this in a short amount of time.
… Once you have the functionality in, and understand how to get a frame through, getting that built into 3 separate layers: browser, compositor, and shell
… 2 APKs, browser and shell
Brandel: Wrt transforms for positioning. In an end-user superficial sense, any way you get stuff to a place on a page looks more or a less the same (until you use a screenreader)
… But CSS position have hierarchical outcomes.
… problem with transform is similar to HTML-in-Canvas needing flat hierarchy
… You can create something that *looks* like it has a proper hierarchy
… but having a proper hierarchy is different
… "The page must flow." to quote frank herbert
… It's exceptionally important. Also something we can solve. But it must be part of our final resolution of how we reason about this
bajones: You're dealing with planes, right?
… There's no limit within OS compositor that you couldn't apply transforms to it, right?
josh-inch: Right
Brandel: In our proposal we're exclusively using transforms for e.g. rotation.
… But depth is a more "semantic" value. In addition to left/top/bottom/right, we have front/back, to allow reasoning about the spatial structure.
josh-inch: Over past 10 years, we've seen developers want to see "the future", 3D UI like Minority Report. But it's a challenge.
… For this spec, we limited the functionality.
ada: You said repeatedly that our spec is complicated. It's well-thought-out.
… It's long because there's a lot of detail in it, and we've thought about it end to end.
… A lot of decisions in there, and alot of reasoning.
… Users aren't expected to read the spec -- it's for browser authors.
… But I fully expect MDN pages for this stuff to be normal and friendly.
… Regardless of what we ship, someone will build a full 3D model out of DOM elements and I will cry. :)
<yonet> fantasai what we've drafted up is not a subset of the feature but the full feature that is fully integrated into CSS that feels natural to CSS authors and is integrated into CSS that makes sense when you put all the pieces together, this is where we are going we won't implement the whole thing all in one go, we will want to break it up and when we
<yonet> look at what we can build together with both our features we can pick pieces that can move forward together. And we can look at this is the subset that we will refine fully then ship that.
Siyaman: If you had more time/resources, what would be the next feature you'd add?
josh-inch: Definitely allowing transforms to change orientation
… I personally, as a visual effects person, would love to do all kinds of 3D effects
… I'd love to see shaders, ...
… That's where I'd like to go with this. I want people to be dazzled by the pages, without needing to enter an exclusive mode to access 3D content
parth: We've been working on web spatial, approaching from similar angel
… We're suprised how even in simple thing, you have to think of all these corner cases.
… We've aligned a lot with what the spec is, approach they're (who?) going with
… Thinking about coordinate spaces
… E.g. build Bootstrap for 3D, how would that work
… Once you start building more than just DIV that's popping out, you see the necessity for all the things that are laid out
bajones: Everyone who's used CSS knows about the grandfathered edge cases nobody likes to work around
… It's worth seeing the whole roadmap ahead.
… Does the system we're setting up work all a long the way?
… 99.98% of the usage of all of this is going to be "make the add to cart button float 2cm above the page"
… As long as that can be done simply, maybe 2-3 lines of CSS at most
… That'll give most developers everything they will ever want from this system.
bajones: Also, I'm of an age that I remember every page had a 3D carousel on it.
<Brandel> https://
bajones: You are definitely going to go through a phase when these abilities are available, and we'll get the equivalent in WebXR. (It'll probably just be a spatial carousel.).
… It behooves us to support that.
… So let's make sure we can see the road ahead.
… And also make sure the simple thing seems simple.
josh-inch: Should we have a limit on how many components can be detached?
Siyaman: Our experience with customers is that they push the limit.
… People hit the limit really fast.
… If it's easy, it's really hard to put a limit.
bajones: You're using ??? layers for this. Are there system limits?
josh-inch: Almost certainly.
… Probably shouldn't be infinite.
ada: Difficult to have infinite layers, but probably shouldn't put caps on it. Hardware of 5 years from now not same as today.
bajones: Does feel like it will be necessary for browser implementers to create some sort of layer merging.
… Like if you have all 50 buttons floating at same distance, naturally CSS author will float the individually. Naive implementation is to create a new system layer for each, so browsers probably need to be smart about it.
… Create one layer, paste them all. Break them out only when there's some hover animation or whatever.
… Sorry for whoever implements it!
Brandel: Something we should do here is "sharpen the contradictions". What are merely subset, and what are intrinsically different.
… I think that what we're suggesting is that while we don't need to implement everything, we need to have an answer for a lot of stuff.
… one of the major differences between the proposals
… if you answer questions, you end up in a similar place
… but what's different?
[time check]
cabanier: Why not implement input?
josh-inch: idk
[generally in favor of input]
<yonet> item: background-material (building on spatial CSS proposal) #247
<yonet> immersive-web/
<Siyaman> https://
<yonet> topic background-material (building on spatial CSS proposal) #247
background-material (building on spatial CSS proposal) #247
github: immersive-web/
https://
<yonet> parth: at the last face-to-face we talked about several proposals from Web Spatial, and today I want to go into detail on one of those proposals: background materials
<yonet> Siyaman background materials are a little bit adjacent
<yonet> [presentation]
ada: This is very cool.
… as I went on my rant on shadows, will be important to have physical materials for shadow to be rendered on
… The concern I have is that people will not use these materials for their intended usage
… For example, I would probably use text-clipping ability to have glass text
… But on a different OS it'll look different
… As much as I like "this is a panel", developers will just use whatever looks nice on their system, and it won't be cross-platform
… Instead of tying capabilities to the property value, I think it would be better to do something more like PBR so that you have a consistent experience across platforms
… Developers will not test on all platforms. They can't own all the devices anyway.
… But I do like what you're trying to go for here.
Siyaman: So we did talk about custom materials. I didn't put that here.
… But hopefully this is set up in a way that we could go that route and have custom materials
… Use that on elements similar to this.
… I think we're too early for that.
… Do you think if we didn't have PBR ability, this would not be useful at all?
ada: I think this is useful if people use it for the intended purpose. I'm saying they won't do that, and will run into problems on other platforms or if platforms change over time.
… Browsers will end up baking in the design at the time the spec came out into the browser, and would be unable to change with the platform.
parth: Even with PBR, different rendering frameworks can render differently
… So probably still have issues
ada: Similar issues, but different from "this is glass" vs "this is ceramic" and "this is red with a particularly nice highlight" and "this is a slightly different [missed] with a different environment map"
… I support the idea, just my concern with current proposa
Siyaman i was trying to base it on the system colours
fantasai unfortunatenely those ossified exactly ada said, and just became those colours defined in win95
fantasai: System colors had the same problem, they got ossified on Windows 95 defaults. They couldn't evolve with the platforms.
… That's why pretty much all the colors, with a few exceptions, are just default colors across all systems now. They don't reflect the platform, because that platform model no longer applies.
ada: ..Start with round of introductions [Joint Meeting with CSS x Immersive Web]
CSSWG Immersive WG Joint Meeting - Spatial Layout
ada: Proposal for bringing spatial to web...revolve around CSS. Purpose of joint meeting to discuss CSS proposal
fantasai: Conceptual introduction first, then ada will talk about how to hook into CSS
<model> - rectangle, sized based on standard CSS. Punch through to create 3D world.
Iteration from this is, separate idea of portal. Brings more questions about putting multiple models in portal
What if we put in the same coordinate space - we need to position them in space, we are adding front and back to size them, and position them in space.
Absolute positioning - extend that into 3D. Position area can get Z-axis, then anchor things to other things in 3D space. Create positioning system for anchor positinoing.
We can also position things that are DOM elements in space.
Going to the glass, 3d world creating in there, positioning things relative, reuse front / back insets for that world.
Overall, this is the vision of how we can fit 3d content / 2d content, and interleaving these things into a system
flackr: 2 questions. What are we imagining people on plain old 2D screens. No perspective? Or give perspective?
fantasai: If you don't support 3d layout, then don't support properties, but UA could synthesize
ada: The layout we're doing is just for layout - forward/back, no perspective, in theory. But it is interesting property - this can give you a unified world, make it easier to do 3D CSS stuff.
flackr: Question about sizing / anything that's far away, you can see more content, how should authors create background to be large enough so that can see more of it.
fantasai: It's infinite backdrop inside portal
ada: 2 modes: spatial page - content above page, and spatial portal - gives you portal - if you use portal, ends up being opaque color - do get smaller, as you push them away.
in that case, authors would put image and push it back if they want some kidn of image backdrop
Brandel: <model> has thought of this as well
<ada> (explainer: https://
@roman: many authors who try to achieve with 2d projections. Would be great if we can use this to enhacen 2d designs. Ask authors who deal today with 3D in today's 2D
@roman: Question about shadows
ada: Box shadows are 2d illusions on 2d surfaces. When you start having things spatial, good to have consistent lighting system, set lighting for soaptial context or page as a whole.
@roman: Question on anchor positioning - if we position something in regards to model, way to name / expose surface on model or target.
ada: Spec has details
cabanier: Can you apply filters, transforms, iframes
ada: box shadows don't make sense, backdrop-blur gives you illustion of glass, platform could do work, but for spatial elements it would be quite expensive. Unanswered question - if we want to mandate
Brandel: difference b/w spatial portal interacts with rest of page / what happens within spatial portal. A model should have ability to be composited onto page as regular DOM element.
cabanier: You can then define opacity to the portal
ada: Looks weird, but yes. Stereoscopic depth works with opacity. We don't support background-image, they're explicitly placed on top of glass, rather than behnd.
@roderick - question about approach to temporality and statefulness
ada: No additional state management. No support of things like physics. State should be managed by JS
ydaniv: Does z-axis have interactions with CSS stuff like overflow?
ada: behavior is slightly diff for z-axis. will come back to this in the explainer - if not enough vertical space, clamp elements back, get squished against glass
bajones: Can you shape of the portal?
ada: Yes. clip-mask, border-radius
ada: way to spatially position elements - both into/out of page.
Bringing things off page, certain restriction - how far elements come towards users for safety / how much OS are willing to let surfaces leave.
Developers will want to be able to lay out stuff with regards to that limit.
inset-back will move things forward, inset-front will move things away from front plane (move them backwards)
<lea> Apologies if I missed this, does this also create *thickness*? E.g. I see `inset-front` and `inset-back`. If I set them both to e.g. `1em`, is my element now drawn with a thickness of `2em`?
fantasai: Not yet, they're infinitely thin
lea: What happens if you set inset-back, inset-front
fantasai: same thing happens in absolute positining
flackr: Can you have something that happens both some what front/and somewhat behind?
<lea> Being able to create actual thickness would be awesome, authors fake it today with all sorts of hacks (poorly), e.g. stacked shadows with no blur
ada: spatial page, and spatial portal. For rendering, positioning properties will determine whether you're being laid out by detached element in front page. And if you're positioning puts you into spaitial portal.
Spatial portal - gives you space in front of page - open up hole in page, position relative, inset-back 1cm to bring you forward, use transform to rotate so back, clips into black pane. Difficult to implement....
<lea> Again sorry if this was already mentioned, would this also extend SVG coords to support a 3rd coordinate? 3D `<path>`s would be pretty awesome
ada: Examples of <h2> back into portal with, to move header, position: relative, set it to front, pushes into the page.
<bajones> lea: To get on the speaker queue the syntax is "q+"
For complex layout - ex. cards - using flexbox positioning to lay them out in line - on active card, set property called front-limit - determines how far children can move from surface of parent.
lea: Is it on scope for effort for svg coordinate syntax to have 3rd coordinate?
Brandel: it would be pertinent to this, but efforts can go in parallel
ada: 3d transforms apply additional transformations to surface. as developer you'd want to use positioning for z-positioning
you can use transforms like rotate to do transforms on top of that
bajones: What's behavior at sides of the panel, related to clipping. Illustration that shows fade-out. For a portal when something scrolls off side/top - would they clip at the boundary, or see them underneath
fantasai: Portal has a diff coordinate space / diff world, own infinite space. You can see things under the page.
For the front, there is a front-limit property - default value of that is going to be set by the user-agent, ex. if not active window - front-limit might collapse to 0. Or 2 inch/cm. If active 5 inch or something
Front-limit is used to clamp the positioning
We can't do that with transforms, transforms position things in a lot of weird ways, if you transform out of allowed space, it's going to get clipped
Clip whatever user doesn't have to be, stabbing them in the eyes - distinction b/w having position vs transform.
<lea> re: `position: absolute-spatial`, I wonder if baking it into `absolute` is the right primitive? It seems like a different, orthogonal mode that should work with existing positioning modes (even if it only works with `absolute` in L1, the syntax should be able to accommodate expansion), rather than a whole new one. E.g. I can see `relative`, `fixed`, `sticky` etc ultimately being useful here too. Or even `static`, I guess. I suppose we can
<lea> always add `xxx-spatial` keywords, but it seems like a fundamentally orthogonal switch. But I'm totally new to this, so I'm probably missing a ton of context!
ada: Portal-stage interesting if you want to do layout in space in back area
Portal-action, if you have portal, we can give orbit, pan controls, to move object, pan in 1-3d, or rotate with orbit controls. So we can do things without needing additional JS for interactions. Scrolling should just work. Touch does get a bit complicated - but things should mostly work together
Envrionment maps - mostly useful for <model> - all the contents with materials should share some kind of lighting.
fantasai: Extended not just inset, but also position, the anchor, alignment props to add z-index. Allows you to transform things with anchor, and anchor origin alignment value - take elemtn origin and center it on anchor's origin.
Mike_Wyrzykowski: Does spec have anything regarding precision of z-buffer, or impl detail?
ada: implementation detail, if z-fighting, browser should be treating same as z-depth.
bajones: developers *will* find a way to provoke z-fighting
<emeyer> bajones is 100% correct
florian: Front-limit, if limiting multiple objects - if they all get squished onto same plane, you lose the sense of depth
<kizu> Portal-stage units?
ada: If setting diff positions, even when flattened, front-limit being reduced, you're still using what z-position should be in order to preserve stacking.
florian: Need more examples - squish things and keep stacking order
josh-inch: push back on portal as center of gravity - portal feels like - something for someone that is going to make a spatial website.
Brandel: Spatial page is for this (the simple thing)
<astearns> time check: at some point soon I’ll need to get the CSS folks move over to our regular meeting
ada: Implementor could just support spatial page
<TabAtkins> (my comment is just to ask for where feedback is wanted, i've been compiling comments on the spec draft)
only spatial portal gives you portal
josh-inch: Is there a way to simplify even more directly, just thought exercise?
ada: It's 3 props - position relative, one of inset props, and spatial porta or spatial page on container. you could set it on root element.
<Siyaman> q_
<Zakim> fantasai, you wanted to talk about coordinate systems
fantasai: front spatial context uses css units relative to size of path. when you create portal, creating coordinate system within portal. by default it'll be some kind of automatic sizing - but you can also explicitly what coordinate system is using portal stage property - which sets origin and what sizes, etc.
flackr: portal-action, should think how this relates to scrolling. touch action restriction on what you can do with touch. is there limit to portal action panning?
<fantasai> fantasai: The two coordinate systems co-exist in the same space, for example if you position: spatial-absolute some object and also position: relative some object into the portal
TabAtkins: Where would you like feedback?
ada: Issues on webkit explainer repo should be best place for now, until we figure out.
<Siyaman> https://
<TabAtkins> the keyword controls whether you're in the front or back spatial context, afaict
lea: What's rational behind new keyword for position spatial absolute - instead of a separate toggle, could be useful in conjunction with existing positioning modes. Syntax should support future expansion.
fantasai: We started with separate keyword combined with abs/relative. For relative to positioning there's no spatial relative - because why not have it always be spatial - but need distinction b/w position absolute and position spatial absolute.
Position absolute already is trapped by position relative parent, or position parent, or nearest ancestor in 2d space.
Spatial sbolute takes something out of flow - but it puts item by default, unless you give it position, origin of spatial context - different from if you set position absolute.
<lea> +1
ada: Thank you for everyone who came, and for questions, would love to talk more about this with CSS working group. Would be good to have another joint meeting
<lea> exciting stuff!
<emeyer> Thank you, Ada!
lunch break
<TabAtkins> okay, rereading, I think you're wrong Emilio. The dict member is optional, but the default value declares what it gets set to *instead of* undefined when it's not passed
<TabAtkins> required members always need to be passed or else they throw an error, so there's no concept of default
<TabAtkins> (but that doesn't change the resolution in any way)
background-material (building on spatial CSS proposal) #247
<yonet> background-material (building on spatial CSS proposal) #247
<Siyaman> https://
<joshi> ... going back to background material, how are you thinking about security implicaitons to reproduce native backgrounds, esp page trying to impersonate sys ui with spatial css and lift it as a detached layer. Thoughts on how you get trust?
<joshi> ... does this allow spoofing? maybe more than traditional background colors... windows case has different mode that you go into. thsi does not allow that. Maybe I should call that out specifically... similar to pico os... not everything exposed. final set of materials will likely be small subset of system. Liquid glass might not be one of things
<joshi> for example
<joshi> fantasai it would be the the same
<joshi> Siyaman wondering if you had thought about margin padding... partners mentioned this in web spatial
<joshi> fantasai margin and padding apply just as always... in Z space, yeah... we thought about it but we got it inset in both directions. we wanted to start there and see if we really needed margin as well. And then we coudl have z axis margin. until we get more 3D to pages, margin might not be helpful
<joshi> Siyaman we have this back property , people use it... devs might want to do flex box in 3d... instead of just row and column
<joshi> fantasai was does that actually look like because flex box aligns things in one axis? what would it be in 3d? have to align in a grid? what are you trying to do? until we have concrete use cases cant extrapolate what the model is.
<joshi> Siyaman we have all these how do we want to extent to 3d?
<joshi> fantasai give me examples
<fantasai> Like what do you want to build with a 3D grid?
<joshi> Brandel we started with things like this because its better now to start with we have to think about the question on what do we do with Z, it might be case that we rotate something inside the context, unless to fantasai point finding out about specifics finding simplist map to semantics on intent of the scene. Until we need, keep minimum
<joshi> ada put everything in same grid cell
<joshi> fantasai as some point elements can have same thickness
<joshi> Siyaman thsi proposal does not tackle? fantasai no ada does not right now, left right top bottom same as usuall z order works in the same dimension but also to ensure back compat
<joshi> ada not included in this not prevented
<joshi> fantasai for layout models like flex grid - have to design those around scenarios. We need use cases. All of that is based around what are realistic things people actually want to do. we want to create a new layout model of some kind. what are the user goals we cant accomplish with basic tools we already have. From that, we can decide how things
<joshi> like sizing are going to work. things in layout are decided in the layout spec. like Brandel was saying, you can do a lot of these things by rotating the plane. maybe you want to do layout along a plane, then just rotate the plane and do it there.
<joshi> Brandel we wait until we understand how and why to understand the dynamics
<joshi> ada we keep as simple as possible, already huge
<joshi> ada even with what we have devs will do weird hacks to do things . we have seen devs doing weird hacks with flex boxes for example
<joshi> fantasai we might not even standardize that, we might learn from that and build something better
<joshi> bajones huge api, complex, going to take years... I will forward on advice from my api mentor - ian kilpatrick. "build the api until where you think it needs to be, then cut out half of it" in terms of the intial launch target. you dont want to start with everything. Just the idea of really trying to decide what the MVP is.
<joshi> fantasai the subset of this that overlaps with what joshi is building would be the MVP
<joshi> fantasai we wanted to sketch it all out to understand first
<joshi> ada if you cant go above page and that is too difficult spatial portal then you can use portal etc
<joshi> bajones you generally want the same half to be chosen for users
<joshi> ada enough of the syntax should be shared that it should be intuitive. You should end up witha neat switch for supporting both - if you support spatial page - you hope for 6cm depth, you expect to be in portal, back elements and front get back to plane - good situation
<joshi> alcooper will devs see that or just wait?
<joshi> fantasai front limit could be 0, based on user pref, state of window and operating system devs going to have to think about what happens when you have a limited front window
<joshi> ada unless you have a limited portal front window goes to zero
<joshi> bajones the other thing that I wanted to bring up little silly... talking about simple thing that people want to do.. raise button off page.. lets assume we are in a page situation. as a dev I want to pull something off a page, I want to bring something forward - it just feels weird ot use "inset" rather than something more intuitive
<joshi> fantasai used forward and backward originally , ended up matching parralels
<joshi> bajones portals have ability to come in and out page?
<joshi> ada yes
<joshi> fantasai we had spatial page, portal, and full. page context to full canvas plane
<joshi> bajones with things as they sit now I could create a portal that spans both in front and behind glass right?
<joshi> fantasai youd have to look through portal to see contents yes
<joshi> bajones do I have the ability to reason about spatial positioning in terms of its offset from the glass in that case instead of just saying ok we ahve things divided in half
<joshi> fantasai yes
<joshi> ada inset relative stick to front, inset back calc 100% -1cm
<joshi> bajones thats what the front spatial context page?
<joshi> ada the front spatial context does the relative style positioning, the front volume you have and the rear volume... position spatial absolute puts you in the back spatial context which has the coordinate system.
<joshi> fantasai you cant go through the portal its another world ada you can from front though
<joshi> bajones ok other way around, page spatial context can inset into portal, portal doesnt come out
<joshi> ada portal gets space in front, cant put elements in front
<joshi> ada you behave kinda like model does today, behind z plane gets clipped
<joshi> ... you can move forward relative
<joshi> fantasai portal magical window to other world... shift forward back within magic glass space
<joshi> bajones my ability to see into the portal is constrained by the rect of the portal itself
<joshi> .... spatial context of the page by default comes off the page, not infinite space
<joshi> fantasai when you push things belonging to the page context it still belongs to the coordinate system. can push iinfiintely back if you want to. once inside you are constrained so we dont worry about it
<joshi> bajones in that page spatial context I have the ability to postiion relative to the back of it
<joshi> fantasai you can go behind, glass is origin point
<joshi> bajones everything on glass by default
<joshi> bajones inset back is from glass?
<joshi> fantasai yes ref is containing block
<joshi> ada only two refs between you and page
<joshi> fantasai if we just use absolute units - i have my portal... I have a warning box, the warning box I want to be inset by 1ft. inside warning box there is an ! symbol, Iwant raised 1m. I ft minus 1cm into page. because the warning box is containing box, just like top bottom left right
<joshi> bajones that makes sense... question: the pushing of that block into the page.. is that like a negative back inset
<joshi> fantasai yes it could be either
<joshi> ada inset front is direction
<joshi> fantasai your containing cube is zero thickness tall wide as portal, you position ref to that. front limit is additional limit.. front limit is like 5 in. If i try ot move 18 in
<joshi> bajones brandel pointed that the portion of that box that is furthest is front, ada said something different
<joshi> brandel they are talking about what is the front and is the back, i am talking about directions that are front and back
<joshi> fantasai position relative is going to be working reference to glass, position spatial absolute is going to put you inside usually 3d space that has depth.
<joshi> bajones what I was missing until now is the distinction between absolute and relative
<joshi> ada relative posiitioning most people will use most times for most things position is relative to where it would be if you were doing nothing.
<joshi> brandel only relative to whats there, once you talk about doc and flow, you need more metaphors. containers with depth we dont have no is something we would need to expand. we have front limit, not dimensions.
<joshi> fantasai relative to position is always in relation to where it is. once you set to absolute it starts from left
<joshi> fantasai we started with forward, once you start putting it altogether things fit together better. the syntax we need has to have consistent language. it ended up being more consistent this way. We are not going to do just this one thing, we want this whole thing to still align together. They all match, so we dont hae one property where things dont
<joshi> align
<yonet> joshi: once all line here what is the first step forward.
<yonet> fantasai
<yonet> fantasai: we will push it and ask people to implemented a smaller portion
<yonet> ada: the portion we can implement and others can are not the same, hopefully we can have discussions to align or at least overlap a little
<yonet> joshi: it would be great for us here we think this is the best thing to drive addoption
<yonet> fantasai: it might be a little early to have implementation plan before we figure out the details. Once we know the whole, we can figure out the subset
<yonet> ada: we can ask the engineers what seems feasable once we have the bigger picture
<yonet> cabanier: it will take time to spec and then implement.
<yonet> ada: webxr took 8 years
<yonet> cabanier: you have to figure out css in advance and not change over time
<joshi> fantasai you have the simple things can stay simple, how does that integrate with the other things we want to do?
<joshi> rik why describe model, why is that necessary
<joshi> cabanier ^
<joshi> ... people would like to have more javascript if they wanted more
<joshi> ada there are plenty of model only things, theere are chunks of things that have complex logic decisions in it. that mass should be described in css.. stuff like that gets taken out of the model api. thats not hte purview
<joshi> Siyaman two questions - as you were talking thinking of weird example where you have something that gets pushed out - you have another element inside of it thats a portal, what happens
<joshi> fantasai inside it you have a picture thats a portal with a teapot inside of its in reference to the cards position. lets say we have a card lifted.
<joshi> Brandel if you put a spatial portal in a spatial page - thats weird
<joshi> fantasai lets say I had a teapot catalogue, I dont want to be ablet to see through the walls of my teapots individual portal walls
<joshi> ada you could build that if you wanted to... you could make the siblings stack in that way
<joshi> fantasai its going to look really weird if all you do is raise the portal
<joshi> Siyaman interesting, second question: not many mentions of the depth concept not many references to model, model could have depth right?
<joshi> ada we dont have innate stacking like that since its not useful to the rest of the web
<joshi> fantasai for dom elements before we have thickness we need to figure out materials.
<joshi> ada border radius are really complicated
<joshi> fantasai not going down there right now
<joshi> Siyaman to clarify model is not part of this?
<joshi> ada correct
<joshi> Siyaman if you have model and you have depth I wont be able to lay it out?
<joshi> fantasai you can still change the backdrop color, you can still control through css
<joshi> ada anchor position is for that in the spec
<joshi> Brandel anchor positioning in css
<joshi> Siyaman for simple things it seems complex
<joshi> ada yes we will some kind of z stacking, in a world where lots of people are using model and stacking in the z plane
<joshi> ada if you wanted to do it you could lay out with flex box and turn them
<joshi> Siyaman lets say you have a front limit and a model, you have depth and you know how to push forward and back
<joshi> ada in the case of spatial page, if you put a model on there you will get a portal
<joshi> ... if your model is 10cm deep and you only have 3cm of front limit, you do horrible thing where you punch through page
<joshi> ... yes in theory could beworld where you end up with a portal and it gets clipped
<joshi> Siyaman or you give me depth and I control myself right?
<joshi> ... in css I use width and height
<joshi> joshi portal above page, walls there?
<joshi> ada it would get clipped there is no way in the way model is specced \
<joshi> ada make your whole page spatial portal, it would enable that for you you could put all page content in there and it woudl give you that effect
<joshi> ada you dont have infinite space behind you where models could potentially fit if we do go speccing this in the model spec it would be a valid thing to do, through a css effect
<joshi> ada right now with way model is specced its kinda incompat
<joshi> mkeblx good discussion what if page is curved and you are in a panel... have you thought about that? something in the future ? how do you decide what we need to think about even if we dont specify early on ?
<joshi> ada this is something we did think about.. our current suggestion is to have spatial portal alwayas cartesian(?)
<joshi> ... for spatial relative sutff... elements maintain curvature. if raising off, always remain parallel to page if they remain same shape they were on the page do they get concentric or parralel
<joshi> ... interesting difference we will need to nail down
<joshi> Brandel i think its also because models should remain planar, maintain high level disparaities between surfaces. Existing in relation to space vs a page
<joshi> mkeblx how can we progress this in some way.. we have spec... theres a gap.. brandel brought up shared a screen to discuss this - faster than the debates we are having... how can we do more of that?
<joshi> ada for everyone here if you go back to some of the people who are responsible see which parts are easy / impossible. how can we all get somewhere quick. it would be good to get aligned on the primitives so we can land something
Add attribute/setter for opacity #93
<yonet> immersive-web/
joshi Having a toggle to dim the display when using Android XR AR display
bajones You would have to find a way of distilling the contents
cabanier Would you emulate it with a video feed
joshi Not all additive displays would support this. You need some way to feature detect, basically if the device supports it
bajones Technically go in and always render like a partially transparent quad behind the entire scene and do things that way that env. But the ability actually trigger this API
joshi You didn't actually get the opacity you wanted in case that changes how you want to render things. You are actually rendering a different opacity
cabanier I know for battery savings purposes maybe how other headsets do it
bajones If you don't want to use a boolean, you could have a minimum opacity like that. You could have 80% you can let 0.2
… you could set to whatever you want and then we can nudge you back into range
bajones With XR session you can get a number of fingerprint properties
Brandel The fingerprint not withstanding, it's a big question. If somebody is making a request to a value that it sort of has more or less the same peceptual effect would be really good. In the event that we end up blocking more light in the future, we're not meaning different things by the same kin of numbers would be really. If not objective,
then future-proof the numerical ranges. So that 0.8 is roughly 0.8 across all devices
joshi So fully 1.0 reset 1.0. I hear no objections to the idea of attribute get or setter with null.
cabanier Session has a render state object, so then you just have to update it via updateRenderState
joshi I'll need to prototype a little bit, I want to see there are any strong objections
bajones They may not want to snap to one opacity or level or another.
joshi I guess we could just update the value out on a frame by frame basis on the render state from the system
cabanier I mean I think you could. I don't know if that's the best ideas
joshi Probably not on the text but like UAS are allowed to ignore this if you set it too frequentyl.
Default environment map #152
<yonet> immersive-web/
mkeblx Environment map for lighting. If we want consistency across platforms want some specifics on how the environment maps work. Whether it's an exact file or a more general way. Also maybe multiple light maps for light/dark mode.
ada I have answers, questions and proposals.
ada When putting together the model polyfill took a screenshot of a Chrome ball and reversed matcap into an environment map. This was terrible and nobody should do that. Should describe the math so that everyone can render the same.
[A Chrome ball appears]
ada Feels like it's currently woefully underspecified.
ada Define the environment map in a similar way to how font face is specified. "studio", etc.
[Brings up link for proposal]
ada Had people creating 10 maps to tween between them. Huge fillrate sync. proposal supports multiple formats such as cubes and equirectangular as well as HDR. More comprehensive approach.
mkeblex Designers are likely to use non-default maps.
ada Proposal for light/dark/real makes a lot of sense.
ada If we could have an easy way to do dark and light mode without building or finding multiple environment maps that's a good idea. Pro having multiple built-in maps.
Brandel We initially suggested putting the env-map in CSS. Were encouraged not to do that. Was seen as less onorous to create a new HTML attrib. Worth revisiting that now.
Brandel To the question of what is a default, what's listed in the issue is still directly on the attribute. Should look at CSS use before comitting.
mkeblx Less thoughts on that.
Brandel Cool, we'll throw that to people with stronger preferences.
… One of the challenges is that we don't have line of sight to ???. Would be happy to address in the right order.
mkeblx Question about Vision Pro defaults
Brandel In the portal we had anticipated that people would want to light things with the hallucinated (from the real world lighting) IBL.
ada Might get pushback on the fact that there's not many media assets in the browsers. Env-maps can be big. Lots of defaults would add ~6MB to each browser. Polyfill generated algorithmically. Might be more palatable. 1Kb of floats rather than 2Mb of textures.
mkeblx Three.js does that
ada [Questions life choices]
mkeblx In addition to light/dark could have warm/cold/indoor/outdoor etc.
ada Made a tool that converted any matcap into an env-map. It was a lot of fun. Made me think a lot of presets would be nice.
ada Maybe auto is fine? Try to popularize a library approach for other smaller env-maps
Mike_Wyrzykowski Seconded. Shouldn't be that complicated.
mkeblx Could be easier jsut to spec out reference files
ada Maybe should take that to our graphics folks and say "would you be happy with this default?"
Moving specs to Rec #246
immersive-web/
ada: we have a few specs that we haven't touch for a while, do we to spec track or think about living spec
ada: it is a good opportunity to move to level 2 or living spec
cabanier: we just talked about extending the AR spec
ada: only the webxr spec is a living spec
bajones: the AR spec is already pretty small, we seperated it out because we didn't want to wait webxr spec for AR to be a blocker. It is not a problem anymore
… ar spec is relatively minumal.
… my reference is webxr and vulkan spec, having everything in one place makes the spec long but easier to search in one place.
atsushi, most of our specs are in CR, is there any changes
bajones: our specs are independent implementations under same engine
atsushi: we don't have any other implementations as far as I know, I want to suggest to start with that
ada: one of the things cabanier and bajones are talking about is some of the specs like gamepad can be merged into the webxr issue, would that work?
atsushi: would rather they stayes seperate until other implementations ourside of blink to occur
ada: is not having everything impelemented in safari would count as incomplete implementation?
bajones: if the ar module is in there, there are still a lot of devices, that doesn't support ar but we are not going to say they don;t support webxr
bajones: I think lighting estimations and dom overlay does not quit fit with the others. Dom overlay is on androud ar but the rest has more widespread support
alcooper: my personal opinon is it is somewhat nice to have individual modules but also it is nice to reference is in the one place. I wonder if it is possible to take the spec to cr and than to merge it
atsushi: there is the restriction of two implementation for recommendation.
ada: does css have living spec?
ada: I am not sure if the levels approach would be approachable for us, atsushi mentioned some of css specs are level 6 but we would reach to a higher level within months
atsushi: we need to get proper horizantal review
ada: apart from lighting estimation and dom overlay we should follow the rec track. We can let people know once that is done, we can merge it together.
atsushi: for IP protection, it is desired to recommendation to crs in timely manner
ada: I will put out the cfcs after I get back to CA
Develop 2026/Sep draft charter #237
immersive-web/
<Brandel> ada: It's time to update the charter, as it is every two years - one thing we need to look at is to explicitly include collaboration with WebApps on controller.
<Brandel> ... The vote will be in a couple of months, but we are probably better-served by looking at this offline with people in your respective companies to make sure things can be reviewed
<Brandel> fantasai: Probably also collaboration with CSS?
<Brandel> ada: Model is happening with the CG rather than the WG, but we may want to add some language around a liaison agreement
<Brandel> ... It's likely that we will have a number of further joint meetings, rather than for folks in here to join
<Brandel> fantasai: Yes, there are a _lot_ of fine details that CSSWG goes into - because they are necessary, but the necessity to be involved there will vary
https://
<Brandel> ada: Suggest that this discussion happen between you and your lawyers, as this is a significant new unit of work to embark on