Panelset/Spicy-Sections issue(s) review/rfc
Nobody has claimed this yet.
- Dominant language
- MDX
- Stars
- 4.5k
- Forks
- 226
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 4
Description
We have been doing work in a branch of the tabvengers/spicy-sections repo preparing to get something closer to being able to be pulled over to open ui and "closer" to reality.
On the surface, it changes to and the IDL class is now similarly named. Beneath that though are also a number of reworks/changes we would like to discuss/consider.... We'd like to present and discuss roughly the following...
Pros:
- The CSS is as we'd like it to be in CSS (or some CSS-like) - just a property, familliar, integratable with everything, even container queries
- No attributes are spouted in the light dom. It is much closer to how a native element would appear from the outside and how we'd probably handle most things on the suface.
- Things remain as stylable through parts and circularities avoided
Things we could use help evaluating:
Our previous approach tried to punt on the details of the CSS property and how it would work, etc and lean into something simple that avoided circuarity. This solution is better for devs, more understandable, but observes a CSS Custom Property. Our data and our testing suggest this is not a perf problem, doesn't cause recalcs and stuff wildly - but we'd like to be sure.
Previously there was very little Shadow DOM, things were simple pair based and in relation to the actual content in the light DOM. That is, if there was a heading, it's content was simply ~"the next sibling" as in any document naturally. With this approach we have to create (and keep in sync) slots for an unknown number of light DOM children. It's some more bookkeeping and we'd like to know if this creates spec/implementation hurdles.
Previously headings were treated as tabs sometimes, that is, they would change their role. Because ARIA doesn't allow dual roles and we're saying that it is simply a different presentation, that was one way to do it. In this prototype, headings are slotted into shadow dom - so you get a role tab that contains a role heading. Is that better/worse from an a11y point of view? Or about the same?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the tabvengers/spicy-sections branch described in the issue and compare its to changes. Examine the CSS custom property approach, shadow-DOM slots, and ARIA roles for the three evaluation questions. Done means the design questions have been resolved and the proposed direction is agreed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- css
- Domain
- accessibility, frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 18/100