[css-spatial] Lots of review feedback from the spec

[tabatkins]

Apologies, while reviewing the spec I ended up with lots of small bits of feedback and questions. I'll post them all as one big issue here, but I'm happy to break things out into their own issues if they deserve it; just let me know.

Environment maps:

• why is the name a string? Should be a dashed-ident. Let's not repeat the @Keyframes mistake.
• environment rotate defaulting to a y-axis rotation is fine, but should allow an arbitrary axis using the same syntax as rotate. (this conflicts in the shorthand, tho)
• all "applies to" are wrong, it's spatial containers with a back spatial context, not elements participating in one (that's all the children)

---

• position-context - is this meant to apply to all elements? text implies 3d only.
• position-area:origin - this is independent of the existing 3x3 grid, right? you can't do any spans, just position yourself "in" the zero-sized box? how is this intended to work? this would mean you're automatically overflowing, and thus this can't be used with position-try at all? (i kinda suspect this might just be for centering on the origin? If so, should do it with an origin-center alignment keyword a la anchor-center, instead. The other alignments can be done via anchor() where referring to a singular line in an axis makes more sense.)
  • what even is the origin? The defining text isn't very clear; I feel like it's referring to some 3d model concepts that the writer assumed were obvious.
    • it says for other elements we use offset-anchor, but that presumably needs to be extended into 3d as well, probably by extending the <position> grammar.
• position:spatial-absolute - single-auto should instead be defined as "auto inset behaves as 0, normal alignment is toward the non-auto side"
• portal-action should expose the resultant transform - perhaps with another transform property, which is set on the element's style a la 'resize'? (Probably not altering 'portal-transform')
• 'inset-front' and 'inset-back' seem to be assuming that they're only used for shifting something. What's the 0 inset for each represent? (Remember that 'z-align-self' can make it not stretch to fill the z-axis; it can align to start/end.)
• z-align-items: is 'start' toward the front or back?
• anchor-size(depth) - I thought the z-axis size was still always 0 for now (elements don't have a thickness)? What size is this referring to? (Does it refer to front stage size?)

---

• general q: it seems there are two entirely unrelated 3d contexts here, the front (from spatial:page but also portal) and back (just from spatial:portal), and a descendant element chooses which one it's positioning itself into according to whether it uses position: spatial-absolute (back space) or not (front space).
  • front space is a pretty straightforward extension of normal CSS concepts into the z axis. You can relpos or abspos yourself in or out of the page, you can anchor in the z-axis, align in the z-axis, etc.
    • I think I heard Ada talking about 3d transforms, mentioning an element lifted off the page via inset-back and then 3d-rotated to partially go behind the page. How do those interact with the front space and its limits? If you don't have a front space, are 3d transforms still always composited back into your flat page plane? (I'm not familiar with how 3d-rendering environments currently treat 3d transforms on the page) If transforms do interact with the front space, how do you handle elements being transformed out of the volume (front-wise or side-wise)?
  • back space is a new space, more akin to scrolling, which is infinite in extent but is only viewable through the viewport of the establishing element. elements living in the back space can't fly around the page or anything, just like elements in a scroller can go all over the place but are still only visible via the scrollport. So if you positioned something living in the backspace forward, higher than the viewport, it just wouldn't be visible because it's behind the "camera" of the viewport.
    • Since we shorthand "scroll container's viewport" to "scrollport", clearly a spatial container's back-space viewport must be called the "spaceport".
  • front space can push back "into" the page, but it doesn't actually extend out the back "physically" like it does in the front - if you were interacting with the page in a 3d environment and looked at the window from the side, stuff pushed forward visibly hovers off the page, but stuff pushed backwards isn't visible (it extends into its own space a la the back-space). right?
  • front space's "back" overlaps with the back space but is its own coord system/etc (not affected by the various portal-* properties). Ideally stuff in the front and back spaces should z-interact.
  • are all back-space portals created by non-descendants independent spaces? or are they shared?
  • I see that if a parent container establishes a backspace, then children that also establish a backspace just live in that shared space (they just get their own coords overlaid for their purposes). This is akin to 3d transform containers sharing a context. Does this mean the grandchildren can effectively fly around and be visible frontwards of their their parent container (because they live in the grandparent's space alongside their parents, rather than being trapped in their parent's space)?
  • How are the normal, non-positioned contents of a backspace box rendered? I just see that the backspace box doesn't render its own background, but I'm not finding rendering details otherwise.