Add initial research for Text component

[theerebuss]

This PR adds initial research for the Text component for the following design systems:

• Ant Design
• Atlassian Atlaskit
• Auth0 Cosmos
• Bootstrap
• Carbon Design
• Evergreen
• Fluent UI - Fabric
• Fluent UI - Stardust
• Salesforce Lightning
• Google Material Design
• GitHub Primer
• Semantic UI
• Adobe Spectrum

[chrisdholt]

Thanks for submitting this research @andrefcdias. As it pertains to Open UI, I think it could be confusing to have multiple instances of Fluent UI adding to research. While I know some of the background as to why there are deltas, and multiple instances, I think that's a slippery slope to hoist into Open UI. IMO, I think a single set of research representing converged Fluent UI makes the most sense. Happy to hear @levithomason, @gregwhitworth, and @una's thoughts on this as well.

[una]

Agree we should stick to one Fluent UI if possible

[una]

I'm also wondering if we should even include this as an OpenUI component. It seems to me that text and typography already have base primitives that are widely used and non-contested across design system, and even reflected here.

We had a conversation about a Link component a while back, and concluded it wasn't necessary to include due to it essentially being styling on top of the <a> element. OpenUI tries to avoid prescribe styling decisions when possible.

[theerebuss]

To clarify the double Fluent UI representation, as of today Fabric and Stardust are still two separate component libraries with different APIs. While we are in the process of converging both into one and have a single source of truth, this is still not the case and why we chose to document them.

As for the inclusion in Open UI, there didn't seem to be a consensus across libraries from the research we did.
Some treat it as a Typography primitive and others have components for it. For the latter case, there are scenarios with "fixed" components, like Paragraph and Header, and others with a do-it-all Text component (like our case).
I agree with the comparison to Link but have previously had research approved for the Flex component, which technically is a styling component, which leads me to the following questions.

• For future research, where should we draw the line to avoid this?
• Is there a list defining what components Open UI wishes to harbor?
• Does research of components that aren't included in Open UI bring any value towards the initiative?

[chrisdholt]

To clarify the double Fluent UI representation, as of today Fabric and Stardust are still two separate component libraries with different APIs. While we are in the process of converging both into one and have a single source of truth, this is still not the case and why we chose to document them.

If we are looking at design systems for research, each design system should be represented once. Alternatively, if we're looking for any variation of the design system, should we not include Fluent UI Web Components as part of the Fluent research as well? If that is different - why? There is a longer goal of convergence there and that is an additional implementation of Fluent which is unique from the react versions such as Fabric and Stardust. Similarly, this road opens up the possibility to add various versions of different design systems which I think ends up creating a lot of noise.

If Fluent is the converged instance which hasn't been addressed yet, should these instead be represented as Fabric and Stardust in the research? I think that given that argument, Fluent as a converged instance of these should be expected to be different - so these really would be three unique design systems represented in research.

On the flex research, I personally wasn't a fan of that being added - it seemed like an implementation detail necessary for a specific system which is already represented by primitive styling cases. With that said, there was consensus on moving it through, so not something I felt needed to be escalated more. IMO though, while anything can be documented as research, I think its fair to discuss if that's still a good policy or if it opens up room for distraction or confusion from the broader web community.

I think the below are good questions and perhaps should stand as their own GH discussions or issues which could be resolve as part of a future call.

• For future research, where should we draw the line to avoid this?
• Is there a list defining what components Open UI wishes to harbor?
• Does research of components that aren't included in Open UI bring any value towards the initiative?

[theerebuss]

Thanks for the clarification Chris, I totally agree with your point of view.
How should we spin up said conversation to address those questions?

[theerebuss]

Closing this as there seems to be no interest in the contribution or a follow-up.