Open gregwhitworth opened 3 months ago
The Open UI Community Group just discussed Foundation for the Global Design System component library
.
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.
đź‘‹ 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.
@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?
The Open UI Community Group just discussed Foundation for the Global Design System component library
.
@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.
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
What it isn’t
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.
Not necessarily sequential
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
The Open UI Community Group just discussed Foundation for the Global Design System component library
.
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:
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
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
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