feat: paragraph component

[flo-sch]

Relates to #1250

Add a new <Paragraph /> component, defaulting to HTML <p> element (getting the semantics).
Also add a new doc page for it.

[flo-sch]

First try, let me know what you guys think? @atanasster @isaac-martin @hasparus

Few notes:

• <Text /> remains unchanged, since converting it to a span would be a BC-breaking change, potentially for a separate PR, potentially later (not sure which release this would be included in)?
• No different themeKey yet, since <Heading /> does not have one neither, I am wondering about whether this would be confusing?
• Not too sure about the default __css neither, I was inspired by Heading for those but cannot say whether it is good or not to use them here?

[hasparus]

Nitpick. There's something not right with this sentence.

[flo-sch]

Something like my frenglish, perhaps? 😁

[hasparus]

LGTM, I'll wait for second opinion for a bit, but it's okay to merge I think

[atanasster]

Looks great - just a few small items

• I would suggest to have a separate theme key (variant) paragraph for <Paragraph /> inside the text space
• I have seen Paragraph in some libs to have a default max-width, or default margin-bottom values (tailwind-css, grommet). We can keep for now away from such defaults, but having a separate theme variant key would allow to separate styling from the <Text />

[hasparus]

I have seen Paragraph in some libs to have a default max-width, or default margin-bottom values (tailwind-css, grommet). We can keep for now away from such defaults, but having a separate theme variant key would allow to separate styling from the

Yes, please. Default max-width. We can set something simple there like 760px to avoid resize on font load, but let's set it to set up a precedent. If somebody want full page wide paragaphs, they can suffer.

We use the last value from sizes scale, multiply it by two, whatever, but I'm strongly for setting that max-width.

[flo-sch]

Alright, the reason for using the same themeKey is the consistency with Heading: why would heading variants be based on theme.text when paragraphs are separated?

But if you think it is better, I will add it

[atanasster]

@flo-sch - sorry, I meant the variant (default vs paragraph) - and I called it incorrectly theme key, but not the _themeKey prop. Exactly like Heading.

[flo-sch]

Ah alright, yes no problem with a default paragraph variant, that makes sense :)

[atanasster]

Tailwindcss also resets margins to 0 for paragraph (i think it comes from normalizecss)

[flo-sch]

Box already does that, that's why I did not, but perhaps it is good not to rely on inherited here?

[atanasster]

I think users are complaining Box does it, since its supposed to be non-opinionated.

Its up to you though, i am just drafting suggestions as they come to mind. Your PR looks fantastic in any way.

[flo-sch]

I have added those defaults as part of sx props to make sure anyone can override them (if they want to), also with a hardcoded MQ (since I thought it is better not to rely on breakpoints...? Not too sure myself about that anyway, let me know what you think?)

[atanasster]

excellent, lgtm

[flo-sch]

Sweat :)

I have no clue how the release works here, so I would rather have someone knowing it merging the PR whenever they think it's time

Do not hesitate if you feel something should be added?