Proposal to create/transfer "spicy-sections" repo

[bkardell]

We have been (esp big props to @jonathantneal) at work the last several weeks trying to put things into good order to have a pretty solid take in the oui branch of our spicy-sections repository. As we demonstrated a few weeks ago, this involves a lot of changes

• Changes the name from <spicy-sections> to <oui-panelset>
• Moves nearly all of the attribute relationships into the shadow dom
• Provides well specified parts for the shadow dom
• Changes the CSS property/value to be simple and intuitive/close to what we would probably propose
• Fixes a problem we had with testing setup
• Rewrites all of the tests to this model
• Creates some nice gh-pages hosted documentation

Along the way, however, we struck upon a fairly significant new open question/debate. We have noted this directly in the readme itself with appropriate recommendations relating to use. Despite that, we believe the best thing to do is to move this work at this stage into the openui repo and work together to address them.

We're asking for : a) Consensus to do that - and b) specifics about how (we could transfer the repo, but then I suppose we have to merge into main first - or we can fresh commit that branch into a new repo here and put a note on the old repo - or ...?)

[gregwhitworth]

A) +1, very supportive of this B) With regards to moving the spec/explainer and component over here are my initial thoughts and honestly these should probably be broken out into separate issues but it's generally the tenants on web component creation/transfer.

• Separate Repo within OpenUI Organization or under OpenUI Repo: One of the key reasons I'd prefer a single repo is for issue discovery. Granted this has its own downsides but labelling enables filtering so I'm less concerned about this personally.
  • The Explainer should land on the site in the same way others have. With regards to documentation this may require some additions to the site (@captainbrosset was thinking about this too) but I'd prefer to not have numerous different areas where folks don't know where/how to discover the work.
  • The component: Currently we have a sub-branch called components that under the components folder actually has web components authored on top of Fast (@chrisdholt and others did work to enable transpilation down to native web components but simplify DX).
• Framework/No Framework/Hybrid?: Given what we discussed very early on, this group will define and build on top of standards. As such, if the group desires to leverage a framework for uniform authoring/improved DX, etc it needs to lean heavily into web components so that ultimately what we're providing to the community is effectively web components. If there is a desire to leverage a framework (I think there should be) we should have an issue solely on that and discuss the requirements and make a decision.
• Testing: What testing framework do we want to use? As I noted to folks years ago I'd really like if the tests can be easily ported into WPT since so much of this work has an expectation of graduating to WHATWG/CSS/ARIAWG, etc.
• Issues: The issues should get moved over to the repo and labeled with panelset (did we resolve on this name in Open UI??).
• Archival/historical purposes: The spicey sections repo should move to the Open UI org and will be put into an archived state. This will keep it in association with Open UI for later reference. This is important as well for informing future discussions around resolutions.

I'm sure there are more things to discuss but I'd really love for the spicey section team to inform aspects of the above as they begin moving through it.

Thanks for all of the effort on this folks!

[chrisdholt]

On the component side, happy to help here if needed with any conversion to fast-element.

[jonathantneal]

We built without a framework, so there would only be an issue if we’re forcing a library (with much respect to Fast).

[chrisdholt]

We built without a framework, so there would only be an issue if we’re forcing a library (with much respect to Fast).

No expectation here - just mentioning as I know the conversion could be a pain if starting from scratch. Zero expectation :)

[gregwhitworth]

No expectation here - just mentioning as I know the conversion could be a pain if starting from scratch. Zero expectation :)

This is why I recommend a new issue because we effectively should get down in an issue the discussion we had 3ish years ago and figure out how Open UI wants to handle it

[jonathantneal]

About testing:

I’d love to help further bridge the gap with proposals and WPT. I am enthusiastic about WPT, and I was even recently playing around with WPT to prototype a popup polyfill. However, I do also have three concerns about using WPT as it is today.

1. The WPT local environment setup is bespoke to get going, which I think will limit contributions compared to other project environments.
2. The WPT testing types don’t appear to include the same kinds or levels of visual testing or interaction testing that we are accomplishing in TestCafe. Switching to manual testing would feel like a real downgrade.
3. The WPT tests don’t factor in library code, understandably. I have been working on code coverage tests, which means those tests would need to exist parallel to the WPT (harness?) tests.

Those things are important to me. Do they seem reasonable to others? Are those issues already mitigated in WPT and I’m missing information?

Even with those issues, I have been thinking of ways we could bridge the gap. For instance, I am looking into running WPT tests from within TestCafe, to reduce the duplication of tests, and I’m looking at how I might capture data from a browser to populate test coverage, further reducing possible test code duplication.

I am also only one person. If my concerns seem legitimate to others and my proposed solutions seem helpful, then I would love to contribute them. I’m also open to other ideas. For instance, I’m not against duping certain tests into WPT style tests.

I just want to be sure that whatever I do is in alignment with you all, my fellow contributors.

[captainbrosset]

With regards to hosting nice documentation, I agree with @gregwhitworth that some changes to the Open-UI site would be needed first, to avoid confusing people with too many top-level links in the sidebar.

I have created some similar docs for the select control, and for now they are just linked from the select spec, and don't have an entry from the main site navigation. So to get to them, you need to go to the spec first: https://open-ui.org/components/select, scroll down and click "our documentation" (or click here).

[css-meeting-bot]

The Open UI Community Group just discussed moving spicy-sections to openui.

The full IRC log of that discussion

<dbaron> Topic: moving spicy-sections to openui
<josephrexme> JonathanNeal: I don't think we were looking for a consensus but more feedback on #382 . We will move over to discussion #517 moving panelset to the openui org
<dbaron> github: https://github.com/openui/open-ui/issues/517
<josephrexme> bkardell_: We feel at least from the API and the ideas that it is close enough that we should move it here and talk about it. There's known concerns. If we had to map it, it'll be this is the repo we intend to prototype. We're asking if the group objects to us creating a repo/subrepo containing details about what we need to do
<josephrexme> bkardell_: The biggest thing here is that we have some known tests that aren't done yet. A signifcant question was raised by James Norton. It seems better over here
<josephrexme> JonathanNeal: I will plus 1 on that. It feels more like the discussions should happen in openui
<JonathanNeal> this gets a big +1 from me, that future discussion should be solved in OpenUI.
<miriam> +1
<josephrexme> JonathanNeal: It feels like it should be moved into the group as it is where the discussions are coming from
<masonf> +1
<josephrexme> bkardell: There are open questions we have to answer about moving it into the openui org. The proposed resolution is that the group is okay figuring that out and have it under openui officially
<bkardell_> Proposed Resolution: Move (details about how tbd) the repo into openui in its current state
<josephrexme> JonathanNeal: I don't hear objections and I see plus 1s. I believe we are resolved on that
<josephrexme> bkardell_: We need cooperation from Gregg and admins on how we move on with this. Like on test, should a framework be used and if so, how will it be?
<josephrexme> JonathanNeal: Excellent, I am very happy for that :) That's great. We covered all our topics
<josephrexme> JonathanNeal: Since were' not at the 45 mins mark, I want to open the floor if there are things that folks want to discuss

[bkardell]

Since we resolved on the group approving of this, particularly on the 'Separate Repo within OpenUI Organization or under OpenUI Repo' I will leave it to @gregwhitworth to define which of those he would like and define the terms, give us access and we'll make it so. Expect we can then open several follow on issues and move the ones that are currently relevant in the other repo. I kind of think I prefer us just taking the state of that branch, making whatever edits necessary and making a new first commit here (perhaps linking the other as prior art/history)

[gregwhitworth]

@bkardell I would like the issues in one repo for ease of discovery (even this could be discussed). For the component code itself, this can either live alongside the spec content or elsewhere which then raises the question regarding options that we can take of branch, separate folder, repo, etc.

The key thing that I want to ensure is that we have one position and consistently go that route. So I'd like to put it back to the team working on tabs, how would you all like to manage your component while ensuring its discoverability and path for replication by other component authors?

[gregwhitworth]

@bkardell @jonathantneal @davatron5000 friendly ping on this

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.