Foundation for the Global Design System component library

[gregwhitworth]

I am actively authoring a blog post that will go beyond what I said in this comment but I think we need to make some decisions and start moving forward with some important questions that need to be answered.

I still feel there are two different approaches and they are not mutually exclusive to enable a Global Design System:

1. Testing solution
2. Component Library

I have had discussions with a few people regarding both of the options above and I think it can make sense for us to tackle both but I think option #2 is the most pragmatic one in the short term. One of the key reasons I think this is the best path right now forward is there are some large component library authors interested in up-streaming their solution (I'll allow them to speak for themselves) and it provides one of the key aspects I said on the call "I don't want to waste anyone's time so we need to ensure that we do our best to succeed".

In order to move forward with a component library I've put together the following list of principles and aim for us to align on the foundational component library that meets this and begin working asap on working model; site integration, etc.

Component library principles

1. Ships as web components
   a. This does not preclude Open UI from including a library that help facilitate abstractions, utility methods or polyfills
2. Meets W3C Intellectual Rights
3. Run as an Open Source solution
   a. This does NOT mean that there will not be consensus driven resolutions as key topics will be brought to the Open UI CG telecon for resolution but many of the capabilities should be able to land within a PR with asynchronous review.
4. Align implementations with Open UI global design system blueprints
5. Adopts Open UI primitives as they become available for increased adoption and feedback
6. Has decent adoption and web developer/designer community support (monetary funding is a positive but not required)

I will kick off this discussion on Jun 27th with the aim of us resolving on the foundational framework that adheres to the above principles (please recommend more if I'm missing any). If you have a component library that you recommend or you run/maintain that you would like to offer up as this foundation to bootstrap this library, then please let us know in the comments.

If you're interested in the testing approach, please comment on that as well but that will need to likewise adhere to the same principles above, but it should also adhere to the following:

Testing Framework Principles

1. Needs to be framework agnostic
2. Everything in component library principles section

Desired resolution:

Proposed Resolution: Open UI will build a component library initially built upon and will be augmented to align with the Open UI charter and workstream goals

[css-meeting-bot]

The Open UI Community Group just discussed Foundation for the Global Design System component library.

The full IRC log of that discussion

<jarhar> gregwhitworth: some key folks werent able to join, but we resolved to have a global design system, and i noted that i didnt want to waste anyones time
<jarhar> gregwhitworth: level of effort for component library, two approaches to make us avoid another set of docs. the current approach for this workstream was that we would have a separate workstream that sits at a level higher than the current one, getting it prepped to land in the browser
<jarhar> gregwhitworth: to take it a layer higher would be ??? another component library. building out a component library we dont want to start from scratch, and the other one is to have a test framework of sorts
<jarhar> gregwhitworth: ive reached out to folks of when we will meaningfully discuss this, but i have outlined some key principles that the framework would need to adhere to. we are going to ship standards so they need to be web components and w3c ip policy. nothing surprinsing , second one that makes this separate for the test framework. it would need to
<jarhar> have some kind of schema so that runner can be framework agnostic. you could use react, and if the testing framework is expressive enough, you should be able to test against it and say that it adheres to it even if its not a web component
<jarhar> gregwhitworth: pros of the test framework is that it allows competition between frameworks. they arent mutually exclusive. we do one key principle for both. is there a community around it, willingness to adopt, and willingness to invest
<jarhar> gregwhitworth: in the component library side, the pro is that we can create a flywheel. if we start with a solid foundation that has decent adoption as its upstream counterpart. i havent had the pleasure of working in the webkit land, but i have worked in the chromium land and i want to set this up as that premise, you can have downstream artifacts
<jarhar> in other component libraries
<jarhar> gregwhitworth: in openui its very plain vanilla like the elements that land in the browser
<jarhar> gregwhitworth: the benefit of that is that so interesttarget and all the primitives we work on here we can land as polyfills
<jarhar> gregwhitworth: adoption would increase, that kind of thing
<jarhar> gregwhitworth: this is me setting up that discussion for july 11
<jarhar> gregwhitworth: hopefully there are people willing to upstream their web component libraries
<bkardell_> q+
<jarhar> gregwhitworth: another reason im talking about this today is that there are things we need to answer to run a component library
<jarhar> gregwhitworth: how the working model, what is the browser support matrix, backwards compat, etc
<gregwhitworth> ack bkardell_
<jarhar> bkardell_: you said theres component libraries who would donate to get us started?
<jarhar> gregwhitworth: yeah
<jarhar> bkardell_: lets pretend material is one of those. they all have tabs, but we don't take any of their tabs. how do we get off that hamster wheel
<jarhar> gregwhitworth: thats why i dont want to dilly dally. im working on a blog post. that foundation would not land and thats when the real work would begin
<jarhar> gregwhitworth: we are not inherently blessing this implementation, put banners that say this isnt ready
<jarhar> gregwhitworth: lets take tabs as an example. we are going to rip it apart and what a11y issues does it have, take the reasearch, and say this is how we are adjusting it
<jarhar> gregwhitworth: i want to make this open source since its for incubating these components
<jarhar> gregwhitworth: we would then start taking from that long list of research thats occurred, it would be similar. we are actively adjusting this one and we are adjusting the blueprint thats there
<jarhar> gregwhitworth: we wouldn't just say its good
<jarhar> bkardell_: is the end result that there is a single tabs that is blessed by us and that is this new white label thing that doesn't exist?
<jarhar> gregwhitworth: yes thats the desire
<jarhar> gregwhitworth: if we cant get there then noone else can
<jarhar> bkardell_: im not sure i agree with that, but not objecting
<jarhar> bkardell_: i dont think its plausible. i think its insurmountable. i think that realisticly, we could set something up to let people submit things for wide review and blessing, and we could together choose which ones we do and the order that we do them, maybe find some funding. net result would be that you would just be creating a single place that
<jarhar> you could find web components that are somehow ok or blessed or that you have some informatin about. no perfect component, so this one is great but doesnt have good i18n
<jarhar> bkardell_: trouble right now is that you can get a whole thing with 100,000 choices but you dont know what ones are good and why
<jarhar> bkardell_: thats what i think is plausible
<jarhar> bkardell_: more so than in any way getting the one true tabs
<jarhar> bkardell_: im game for trying to get to one true tabs
<jarhar> bkardell_: if im the only one that believes the other way more likely
<jarhar> gregwhitworth: theyre not mutually exclusive. i want to avoid lots of time talking, given that we arent trying to upstream into html at this moment
<jarhar> gregwhitworth: so thats kicking off, we dont have to ? anything this week
<jarhar> gregwhitworth: if yall know of component libraries to consider or are building a test framework
<jarhar> gregwhitworth: there are enough folks watching this landscape that we need a meaningful answer. we resolved that we would so i want to see that through
<gregwhitworth> Zakim, end meeting

[claviska]

We've discussed volunteering some components we've built for Shoelace and/or the forthcoming Web Awesome (open source) project, which are a bit opinionated but do try to align with the platform when possible. Between that, my other open source projects, and possibly some of @KonnorRogers' open source projects (he's expressed a possible interest in contributing as well), we'd have a pretty good foundation to start from.

[KonnorRogers]

👋 happy to help in any way I can. I maintain Shoelace / Web Awesome with Cory. I have built a number of other components as well including recently a combobox that has given me many gray hairs trying to get VoiceOver / NVDA to read + navigate it correctly.

testing solution:

I have a library I maintain called "shadow-DOM-testing-library" that builds on top of DOM-testing-library to provide queries into the shadow dom.

when we say "framework agnostic", I'm assuming you mean test runner agnostic?

so like needs to work across Playwright, Puppeteer et al? Or do you mean web component framework agnostic?

happy to chat testing somewhere else its more relevant! Don't want to detract from the topic at hand.

[gfellerph]

@KonnorRogers my understanding of framework agnostic testing solution would be that no matter what framework the components under test are built with, they can be tested. So the testing solution should not be usable with React, Angular, lit, ??? components only for example. What benefits would a test runner agnostic testing solution have?

[css-meeting-bot]

The Open UI Community Group just discussed Foundation for the Global Design System component library.

The full IRC log of that discussion

<jarhar> gregwhitworth: we resolved that global design system makes sense. one of the key things is that we dont waste anyones time. everybody has fulltime jobs and this is a passion project, maybe thats why youre here as well, we want to have a high likelihood of success
<jarhar> gregwhitworth: i want to avoid just writing another doc. select is a good example of that because it has an implementation and is going to get adopted
<jarhar> gregwhitworth: someone used a component library as a reference implementation. document should be authored in a way that it can be implemented in anything including html. eventually graduate to that workstream
<bkardell_> q+
<jarhar> gregwhitworth: building a component library doesn't happen overnight. there were some people talked about working on a component library
<jarhar> gregwhitworth: we can align on accessibility etc. and we can work towards possibly landing them in html
<jarhar> gregwhitworth: i used skeleton as an example. most design systems have one
<jarhar> gregwhitworth: i would love for this group to agree that component library would have value
<jarhar> gregwhitworth: if we have testing it would be good if it was framework agnostic
<jarhar> gregwhitworth: we cant adopt the design system overnight as salesforce, but a test suite would be useful
<jarhar> gregwhitworth: i dont want to move away from html itself. we did a lot of this with select for keyboard behavior
<jarhar> gregwhitworth: we can have separate work to get that into html or css
<jarhar> gregwhitworth: cory noted that he would be happy to upstream or define what you are willing to upstream
<jarhar> gregwhitworth: i did want to pivot into heres the working model
<jarhar> gregwhitworth: its ok to fail. ive been trying to set us up for success but i want us to hold ourselves accountable
<gregwhitworth> ack bkardell_
<jarhar> bkardell_: you said that someone used a component library as a reference implementation?
<jarhar> gregwhitworth: so when we produce those blueprints, theyre documents. they only become valuable when someone can use them. we would implement that as a native web component
<jarhar> bkardell_: it sounded like somebody did this and im trying to figure out
<jarhar> gregwhitworth: cory has offered to upstream
<jarhar> bkardell_: there wasn't a reference implementation of somethign that somebody already built
<jarhar> gregwhitworth: no
<masonf> q?
<jarhar> gregwhitworth: the blueprints, there would be a reference implementation that could be wrapped in a framework or could reauthor it in their framework
<jarhar> bkardell_: i have thoughts but id like to write them down
<jarhar> gregwhitworth: the resolution im looking for is that we're game with the component library and we're going to upstream one since theyre web compoentns already to set a foundation
<jarhar> gregwhitworth: does anyone have objections to cory upstreaming from webawesome or shoelace to be that foundation instead of starting from scratch?
<jarhar> q?
<bkardell_> q+
<gregwhitworth> ack bkardell_
<jarhar> bkardell_: im uncomfortable with silence making me agree with this
<jarhar> bkardell_: im not philosophically opposed to the general premise, but i feel like we've not had enough discussion for me to support exactly this at this time
<jarhar> bkardell_: not that in 2 weeks i might not be fine with it
<masonf> q+
<philippgfeller> q+
<jarhar> gregwhitworth: i dont want to spend 6 months talking about it, id rather just move
<gregwhitworth> ack masonf
<jarhar> masonf: no strong opinions, sounds ok. just a commitment to start moving on something. plan would be to host this component library on openui.org?
<jarhar> gregwhitworth: cory has a nice list of 15 very logistical questions. yeah it would be a different repo on openui.org
<bkardell_> I am pro having all of the necessary discussions about the logistics without actually doing the thing this week :)
<jarhar> gregwhitworth: it would be similar to other specs where it says this is not ready but gives us a central place
<scotto8> q+
<jarhar> masonf: repo sounds good. my concern is that whatwg people are very confused about what is this thing and are these all going to whatwg
<jarhar> gregwhitworth: thats why i want to get moving, theres ui stuff to do on the site. heres the implementations, theres a component library. we need a header that says this is not ready
<jarhar> masonf: also a paragraph or page about the purpose and how it fits with the rest of openui
<gregwhitworth> ack philippgfeller
<jarhar> philippgfeller: to move forward what would be the questions that need to be answered to make an agreement brian?
<keithamus> q+
<jarhar> bkardell_: there are some practical logistics questions. say we agree to have a reference implementation. where does that repo live? what are the statements we make about that repo? what license does it have to have? what commitsments? contribution model? feels like easily a weeks worth of conversation
<jarhar> bkardell_: i dont know the right way to do that. i will write my thoughts down, but i dont know that we're able to get to a ... thats the ideal state but to get there you have to review a lot of things
<jarhar> bkardell_: we dont have a specification for us to say what is a reference, its just a library that we're going to work on
<masonf> q+
<jarhar> gregwhitworth: what youre articulating is the working model im talking about
<jarhar> gregwhitworth: i wnat to move forward with heres the browser compat, heres how to land a reference
<jarhar> masonf: my concern is that we have a paragraph/page about this, and maybe thats the same thing that brian is talking about, maybe we do that first
<jarhar> gregwhitworth: sounds good i just dont want to take months
<masonf> ack mason
<jarhar> gregwhitworth: we can be improving and aligning on a working model that improves upstream component libraries while we figure this thing out
<gregwhitworth> ack scotto
<jarhar> scotto8: when i think of a global design system i think of the system used to create a design, not a component library, just docs that explains how it should be set up
<jarhar> scotto8: im not opposed to a companion library, but are we going to be yet another example of someone making a custom element button
<bkardell_> I like this distinction and clarification actually - it kind of needs to be articulated well
<jarhar> scotto8: or would the component library have things like a skeleton. that sounds like a good thing to have an example for
<masonf> Proposed component library name: "the xkcd927 library"
<bkardell_> `<xkcd-927>` `<xkcd-927-2>`
<jarhar> scotto8: would a component library thats being build just be recreating wheels? or would it be a component library that tries to standardize things that are built across various libraries in different ways? value in showing how to do that, i just dont want to have another instance of look at my custom element button
<gregwhitworth> q+
<gregwhitworth> ack keithamus
<jarhar> keithamus: reading between the lines, the hesitation, the questions are concretely answered. the licensing question: yeah its mildly difficult question to answer but we can just put a strawman up and move on. thats what we do. same thing is true for the components. good avenue to use this forum to invest in a component. do we want to invest in
<jarhar> custom button? answer is no. to gregs overarching question of do we want to do this? sure
<bkardell_> q+
<jarhar> keithamus: first step to make is an explainer pr in openui so that we can put strawpeople up for all the questions that need to be torn down
<jarhar> keithamus: we can just make up an answer and people can litigate in the pr
<jarhar> gregwhitworth: i was wanting to do it inverted, everyone is asking about the working model, i can go do that
<bkardell_> q-
<jarhar> gregwhitworth: the spirit is there that people agree about a component library. it can take on its own forms and evolve over time
<jarhar> gregwhitworth: for licensing thing, we already have w3c ip policy
<bkardell_> q+
<jarhar> gregwhitworth: a benefit from this is being able to increase our velocity of getting stuff out there. brian you brought this up 2 years ago, which was should we just pick a component library and pile there, but we didnt want to bless a single component library
<brad_frost> +q
<jarhar> gregwhitworth: will it have a custom button? probably. that wont be where we are spending our time
<jarhar> gregwhitworth: heres our success metrics and get an alpha out there soon
<jarhar> gregwhitworth: heres the priorization of components we want to look at
<jarhar> gregwhitworth: i will take the action of putting together the working model in another repo so it doesn't conflate the two
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack bkardell_
<jarhar> bkardell_: i hear two things. an abstract, and a concrete. one is there is a person with a library so there are questions that go, like license thing. if we pick one we have to make sure that whoever is doning that has ... there is a meta discussion. all that stuff i am ok with us talking about and i dont think it needs to be a 6 month conversation
<gregwhitworth> q+
<jarhar> bkardell_: im not comfortable picking one. thats all im hesitant about
<jarhar> bkardell_: i want to punt that for a week. id like to know why
<scotto8> q+
<jarhar> claviska: we're not looking to just take shoelace and just put it in openui and say these are the components. we are looking for a foundation to strip down and see if its following accessibility rather than start from scratch. im biased but we're using a library that is aligned very much with the platform probably more than most, feel free to do
<jarhar> your reviews. we're not pulling it in verbatim
<jarhar> claviska: all the theming stuff will be gone
<jarhar> claviska: its not going to be the exact thing we're pulling in
<gregwhitworth> ack brad_frost
<gregwhitworth> ack gregwhitworth
<claviska> sorry, not sure on how the Q thing works
<jarhar> brad_frost: a lot of what greg and cory just said - starting with something vs nothing, and i think brian what you're bringing up - the devils in the details - we want to get moving to be able to look at something to be able to pull it apart. as to why, well here's a willing participant which takes an immense lack of ego to throw it to the wolves
<jarhar> brad_frost: that demonstrates the commitment of here are these components, and to meet the criteria of this really high bar
<bkardell_> q+
<jarhar> brad_frost: thats the opportunity, having a well considered starting point that is agnostic of any one organization. implementation of stuff we are looking at was web component ready and consumable, whereas this particular one is the same general shape as the ?? rebuilder as our clients
<jarhar> brad_frost: as for the framing, i welcome volunteering myself, what is this, how is this different than what exists already and standards, we can help do that as well as the track - certain things like skeleton might only be in that layer, whereas other things might go to standards track
<jarhar> brad_frost: spelling that stuff out can help people understand what it is and how its different
<gregwhitworth> ack scotto
<brad_frost> +q
<gregwhitworth> q+
<jarhar> scotto8: to respond to button thing, the worry i have is including things like that - as simple as it may seem thats effort. whatevers pulled in needs to be reviewed. does it actually meet everything that the native platform does for you? do we need to go through any component that we pull in checks off all things that native platforms does, do we
<jarhar> actually agree with these decisions? for something as simple as that, that means we aren't working on stuff that poeple have no idea about. would it be better to serve time to components that people are constantly getting wrong
<jarhar> scotto8: not that there shouldn't be a design system entry for buttons, but do we need to spend the same level of effort rather than for the elements and components that nobody has an idea about
<gregwhitworth> ack bkardell_
<jarhar> bkardell_: its not about shoelace. i just think that we're talking about a global design system. it is worth of a minutes worth of discussion. kind of a big deal. i think we could sleep on it, thats all
<gregwhitworth> Zakim, close the queue
<Zakim> ok, gregwhitworth, the speaker queue is closed
<lwarlow> q+
<jarhar> brad_frost: scott, i think you bringing up time and effort is a big one. greg was saying that understanding everones valuable time and effort is important. definitely dont want to get into a game of rehashing stuff. one thing we can do to differentiate is that html button is a thing with these properties. when you look across implementations of
<jarhar> buttons, its a narrowing function, intentionally adding constraint. button component tends to take a shape
<jarhar> brad_frost: you can put an icon after it, and icon before it. you can have different visual styles. the intention for this thing is not to rehash whats been done, but in a lot of cases heres an encapsulation of a thing done many times, and if we can say yep this implementation is good, a bunch of people will say thank you you gave me the one that
<jarhar> has been blessed
<jarhar> brad_frost: i can do my search with my magnifying glass in front of it. just a huge time save
<jarhar> brad_frost: why these things exist in the first place. having a design system is valuable
<jarhar> brad_frost: text with icons probably wont make it into html, but it is a useful convention
<jarhar> brad_frost: we absolutely should be focused on low hanging fruit and things that get screwed up across the world. if we can solve that, it will make the web a way better place
<jarhar> brad_frost: i agree with you, lets figure out whats the best use of everyones time
<jarhar> gregwhitworth: ill set up an hour with brad to hash out - some people said the would be able to upstream their stuff with the legal implications of w3c
<jarhar> gregwhitworth: please raise those
<jarhar> gregwhitworth: i dont know if we will have it done in one week but i would love to bring back a status update by next thursday
<gregwhitworth> ack gregwhitworth
<gregwhitworth> gitHub-bot, take up https://github.com//issues/1058
<jarhar> lwarlow: toggle buttons. we discussed them before. based on some feedback on mastodon the design changed slightly. the main thing is it does account for the mixed value just so it is a 1 to 1 match with aria

[KonnorRogers]

@KonnorRogers my understanding of framework agnostic testing solution would be that no matter what framework the components under test are built with, they can be tested. So the testing solution should not be usable with React, Angular, lit, ??? components only for example. What benefits would a test runner agnostic testing solution have?

I assumed the same, the testing solution should be usable by any web component library or framework, but wanted to make sure intent was clear of "framework agnostic".

As for being "test runner agnostic", the main benefit is that users can continue to use their "testing framework" of choice. IE: Jest, Playwright, Web Test Runner.

The problem of course with being "test framework agnostic" is more powerful runners / environments like Playwright / Puppeteer have access to a real browser and can recreate native browser behaviors like typing, clicking, accessibility trees, etc without emulating on the client.

[gregwhitworth]

Based on the last meeting, @bradfrost and I met up briefly to focus on the "what this is and what it isn't" request made by @mfreed7. Here is an early draft that we'll ultimately bring in as a PR and land on the main page of the sibling site:

---

The Open UI Global Design System is a combination of blueprints and offers a reference implementation of these blueprints in the form of a component library. The Global Design System has been produced through collaboration from experts across the industry to incubate the best approaches for common UI paradigms that provide a great user experience. Aspects of the Global Design System may graduate towards a proposal within Open UI for new web platform primitives or elements that compliment and improve the user and/or the developer experience.

What it is

• An open-source library of consumable Web Components that serve as the implementation of Open UI’s blueprints.
• Consumable - deliver components and all the best practices baked into them so developers don’t have to reinvent them.
• Vetted by experts for accessibility, internationalization, security, and privacy
• Open source - open to contributions, forking, branching, etc.
• Themeable
• Composable and extensible
• Intuitive to use, providing developers with a cohesive & consistent API language, sensible structure, and simple syntax.
• Interoperable to be able to power any website or app.

What it isn’t

• The end-all-be-all of component libraries
• A substitute for standards track
• Just another library like Bootstrap, Material Design, Ant, et al.
• Imposing a specific aesthetic
• Just a specification or documentation - these are actually consumable, usable components!
• Comprehensive components - Just the common components, not every component in existence
• Comprehensive features - We're aiming for 80% of use cases, not 100%.

If you’re wanting to understand the potential new elements or primitives being incubated in Open UI into the web platform workstream which can be found here.

We’ve put together a diagram that demonstrates the relationship between the Global Design System and the Platform tracks within Open UI.

Roadmap

Not necessarily sequential

• Green light a base component library
• GDS Site is added with clear communication on the fact that it isn’t ready and stipulates what is and isn’t with a goal alpha date.
• Working Model, component and OSS principles defined
• Identify component list to dig into for alpha release
  • Define what it means to “dig into a component” to get it ready for implementation
• Itemize components and assign to volunteers
• Begin implementation and what is means to have a completed implementation
• Test framework, CI/CD, etc
• Aim for Alpha release in mid 2025

[bkardell]

I shared my thoughts on this in https://bkardell.com/blog/927.html

I feel like a TL;DR which is without rationale, etc is not likely to be appreciated well, but I'll try to log a reduced version here with the summarized plan if we imagine it helpful

[css-meeting-bot]

The Open UI Community Group just discussed Foundation for the Global Design System component library.

The full IRC log of that discussion

<hdv> gregwhitworth: one of the key actions was we wanted to make it completely clear what this is and what this isn't
<hdv> gregwhitworth: I wanted to share that here
<hdv> gregwhitworth: and would recommend folks look at the working model
<hdv> gregwhitworth: hope to ship something mid 2025
<bkardell_> q+
<masonf> q+
<hdv> bkardell_: is there a link to the workflow that was sketched out?
<bkardell_> q+
<philippgfeller> https://www.figma.com/board/fyhySRUS8SFoTcOlA9RonR/Global-Design-System-Workflow?node-id=0-1&t=vAM0VuqhBctN6egf-0
<hdv> masonf: my main concern… I want to be very clear that this work is distinct from the work that we are doing in this group, which is work that goes into standards land
<masonf> q?
<masonf> ack bk
<masonf> ack mason
<hdv> gregwhitworth: I tried to say this in a bullet point
<hdv> bkardell_: I wrote about to distill my post, I linked it in a comment to this issue, people can read if they want
<hdv> bkardell_: I think the process would be more efficient if we could get 5 or 10 different submissions that are about tabs, that includes a commitment to work with their accessibility experts with their implementation people to review them together
<hdv> bkardell_: the goal here would be to show the cross review that this had
<hdv> q+
<hdv> bkardell_: along the way you may end up with 6 tabs that are all god
<hdv> s/god/good
<gregwhitworth> hdv: I read Brian's post and it resonated withme
<gregwhitworth> hdv: I don't know how to explain and I work on a design system and we're doing a global design system within the netherlands and they contribute the components and we review multiple components and one of them is the best
<gregwhitworth> hdv: I really like bkardell_ points that he made
<gregwhitworth> hdv: they're being used in different contexts as well
<gregwhitworth> hdv: it's annoying to have 6 paragraph components
<gregwhitworth> hdv: we have this process inside of it
<gregwhitworth> q+
<gregwhitworth> ack hd
<gregwhitworth> hdv: you can get a lot done if a lot of people are contributing
<hdv> gregwhitworth: I kind of want to start moving on this
<hdv> gregwhitworth: so let's figure out what the working model is
<hdv> gregwhitworth: we got some early comments from folks, we don't want to start a component library from scratch
<hdv> gregwhitworth: trying to not reinvent any wheel
<masonf> q?
<masonf> ack greg
<hdv> s/it's annoying to have 6 paragraph components/it's annoying to have 6 paragraph components, but it's nice to see orgs unblocked and be able to do it from their perspective
<hdv> masonf: could there be a place in the repo to add alternatives for components?
<hdv> masonf: the eventual goal is to get to one tabs component
<hdv> bkardell_: ultimate goal would be for a lot of these to get in HTML. but can we get there?
<hdv> bkardell_: the discussion around which checkmarks we can set is helpful because it helps you find out what differences there are
<hdv> bkardell_: it makes it more than an open source project
<keithamus> q+
<hdv> gregwhitworth: anything that makes sense could end up in HTML… if we can hit 80% it's already very useful
<hdv> gregwhitworth: while not perfect, mid 2025, that's okay, it does not have to be utopia, we're starting to get things in place
<bkardell_> yes he has it :)
<hdv> gregwhitworth: if we can use a different contribution process, hdv, we can look at that, just want us to get started
<hdv> keithamus: it sounds like what you're seeking is open governance vs open source… that there's some presteps to this, like RFCs so that we can hash out details of patterns before going to implementations
<hdv> bkardell_: there are already lots of implementations… I'd like people to come together to make performance better, reduce costs and get a new verification, kind of like an experts group, that work together to define more checkmarks about why they are different
<gregwhitworth> q+
<keithamus> ack keithamus
<hdv> bkardell_: if we can say, these different ones are accessible and have good i18n etc
<hdv> gregwhitworth: can you write how it would work?
<hdv> bkardell_: would like it to be a place where people can submit, with specific criteria up front, like licensing and IP
<hdv> gregwhitworth: how can we make it actionable?
<masonf> q+
<masonf> ack gregwhit
<masonf> q-
<masonf> q+
<hdv> masonf: sounds to me that we agree that a deliverable is a set of criteria
<hdv> masonf: tha could be started by a single component
<hdv> q+
<hdv> ack mas
<hdv> ack me
<masonf> hdv: I like the idea of generating a list of criteria. How to decide.
<bkardell_> q+
<hdv> gregwhitworth: I think a test suite is the best we can do, I wrote that in my blog post
<hdv> gregwhitworth: we could have different tracks too
<hdv> gregwhitworth: end of the day we want accessible components that people can reuse
<hdv> bkardell_: what mason was saying is the point I wanted to make… if you want to test you need test cases and a skeleton etc it's a long way but very valuable
<hdv> bkardell_: I also want to start acting not just talk about
<keithamus> Seems like a great case of red-team-testing if bkardell_ & co build a test suite and gregwhitworth & co build a component that adheres to that.
<bkardell_> keithamus: it would be, if that is what I meant :)
<bkardell_> a reusable test suite is not necessary to get very far in my proposal - it's an eventuality you would like to get to, and could practically imagine getting to