1. We decided to start simple for the first release but it’s definitely possible to add something like asChild if the need arises. There are some tradeoffs to this though, eg it’s easier to mess up the DOM structure required for accessibility. There are some other approaches we’ll be documenting for this as well.
2. TS should be easier now. All the docs examples are now written in TS so you can see where the interfaces are imported from.
3. Yeah prop naming is a trade off. When we started, we decided to make all of the components follow a consistent naming convention. The DOM is quite limited in its functionality (eg you can only submit strings and not more complex objects) and we knew we’d need quite a bit more capability so we decided not to follow it in some areas. But we know integrating with form libraries is a pain point and we might have some documentation or helpers for that in the future.
1. Understood! Yes, I agree about messing up the DOM, and I'm sure you've seen some egregious cases haha. asChild definitely enables some less deliberate choices when composing bits and pieces together and assumes some good habits around event handlers - probably not an approach that scales well for growing teams, but definitely convenient for hacking on things. Can I bum you for a link or some search terms for the "other approaches"? I'm curious about them.
2. You're spoiling us. Thank you. Re-visiting the hooks docs, I think I was just meant to use the `Aria...Props` interfaces the whole time haha. I have a feeling I overcomplicated some things in that codebase.
3. "you can only submit strings and not more complex objects" - I think this is the crux of the tradeoff. Frankly, the only thing I use Formik for when I bring it in is binding Zod schemas to form state to get validation messages in a pinch. If React Aria had a first-class schema-driven Form component or similar, I'd be a satisfied "customer".
Had another random question overnight -
4. Have y'all considered implementing anything in the realm of the "CSS Spatial Navigation" proposal? The conversation around it looks like it has gone quiet in the past few years, but I think there's definitely an opportunity for non-grid-y 2D navigation in web UIs.
This was an intentional choice. Repositioning when an outer element scrolls is pretty janky in some cases because scroll events don’t fire at 60fps. Also it’s not possible at all in other cases, like if the trigger goes completely out of view. We used to close the popover in this case but this caused usability problems. The new behavior of preventing scroll actually matches native platforms like macOS and helps with these issues. I get that it’s a little opinionated but it was thoroughly considered, not just done out of laziness. More details in this answer: https://github.com/adobe/react-spectrum/discussions/3802#dis...
I reckon it’s a mistake. Hiding scrollbars dynamically is unpleasant, and the degenerate cases like `position: fixed` seen on this particular page make it very unpleasant.
Embrace what the web exposes. Allowing document scrolling underneath is distinctly the lesser of two evils. With a bit of effort, you can block scrolling underneath in almost all cases, and I reckon that’s good enough and much better than what there is currently. (Also try asking browser makers, “y’know this ‘top layer’ thing you made for <dialog> modal presentation and fullscreen? Wouldn’t it be nice if we could prevent scrolling underneath a ::backdrop?”)
Facts. You have to forgo native scrolling and basically re-implement all desired scroll behavior in JS in order to get rid of fixed position scroll jank.
I've been interested in re-implementing smooth scrolling in JS to mimic native but.. Even if you hit solid native refresh at all time, I feel you'd have to switch your entire site to JS controlled scrolling for consistency and even then the scroll feel might not match native scroll on other pages per system settings.
Never override scrolling in this way. Scrolljacking is always bad, because the web doesn’t expose the primitives required to make it anything else. You might be able to get it to match the platform you’re on exactly, but it will still be a trainwreck for many other users.
Are you saying that you can only anchor an element to one of its ancestors? Can CSS really not define positional relationships between siblings (I'm used to Apple's Auto Layout)? If so, couldn't you add an additional outer container that doesn't crop its contents to its bounds and anchor the dropdown to that?
If you have a trigger inside a nested scrollable region, and the popover pops out of this region, then if the trigger is scrolled out of view the popover cannot be anchored to it anymore.
I have been thinking about implementing the CSS OM spec as the JS API. This is the same API that browsers expose for manipulating stylesheets. The advantage of this is that we don't need to invent something custom. Still thinking through options. https://github.com/parcel-bundler/parcel-css/issues/5
That said, I think I'd want to keep the use cases for JS plugins limited, because it will affect performance significantly. So, if it's something that exists in an official CSS spec somewhere (even if draft), or a really common transformation, it should be implemented in Rust. An example of this is the support for the CSS nesting spec. Ideally, we'd try to keep the amount of custom syntax being invented around CSS to a minimum and stick to standard CSS syntax wherever possible though.
Separate question, that may be seemingly unrelated however I'm curious.
How did you kinda "learn" how to read these specs effectively? I can read them, and I think I can reasonably understand them, however I feel like I have little confidence in saying yes I get this.
Is there anything you point to that helps? Tips or recommendations?
I'm trying to learn how to parse these standards docs better myself.
For a spec about a browser feature, "getting it" can mean a few different things.
1. Understanding the purpose of the feature ("why/when would I use this?")
2. Understanding how to implement the feature
3. Understanding how to use the feature
4. Understanding the feature's "corner cases" (surprising implications, cases where it doesn't do what you'd expect, etc.)
5. Understanding why the feature works the way it does (instead of some other way)
Most of the web specs really only explain how to implement a feature, and even then, they're not great at that, because they do such a poor job at explaining the purpose of the feature.
Assuming that you, like most of us, aren't working on implementing a browser, that means that web specs are mostly unhelpful to you. It's almost completely beyond the purpose of a spec to teach you how to use a feature, what its corner cases would be (which are often unknown at the time a spec was written), and why the specification says what it says.
This is an area where the web spec community has made some improvements in recent years. Nowadays, it's understood that new proposed specifications shouldn't just provide a specification, but also a separate "explainer" document to explain the purpose of the feature, and also persuade the other browser vendors to implement the feature. ("This will be really cool, and here's why…")
At a minimum, specs nowadays often include a non-normative "Motivation" section, as the CSS Nesting spec does. https://www.w3.org/TR/css-nesting-1/ I you'll find that you can "get" that spec much better than you can the CSS OM spec https://www.w3.org/TR/cssom-1/ which is old enough to buy alcohol and doesn't include a "Motivation" section.
In addition to dfabulich's excellent comment, I'd also suggest: read specs of tech you're most familiar with first, rather than specs of new cutting edge stuff you're curious about. Doing that will give you huge amounts of extra context because you're just reading something you already know expressed in a different format.
I work on React Aria. Adobe is a big company and there are many teams using different technologies. In general, some very new parts of creative cloud chose to use web components, but the majority of teams are using React, and I don't foresee that changing anytime soon. It's definitely not a company wide shift if you got that impression from the Photoshop article. Ideally we'd collaborate more, but... big company silos.
I can see the appeal of web components when your interop issues are as large Adobe’s must be. On the other hand if huge portions of your apps are canvas / wasm then web components’ DOM-centric component model might feel awkward or constraining
1. We decided to start simple for the first release but it’s definitely possible to add something like asChild if the need arises. There are some tradeoffs to this though, eg it’s easier to mess up the DOM structure required for accessibility. There are some other approaches we’ll be documenting for this as well.
2. TS should be easier now. All the docs examples are now written in TS so you can see where the interfaces are imported from.
3. Yeah prop naming is a trade off. When we started, we decided to make all of the components follow a consistent naming convention. The DOM is quite limited in its functionality (eg you can only submit strings and not more complex objects) and we knew we’d need quite a bit more capability so we decided not to follow it in some areas. But we know integrating with form libraries is a pain point and we might have some documentation or helpers for that in the future.