Closed thansidwell closed 8 months ago
@thansidwell This is likely a question for this project's lead dev, but what is the team's appetite for adding enforcement rules via Stylelint or ESLint to explicitly disallow tailwinds defaults of text-*
or even these font class additions of font-size-*
? My thought is that while we could add in the heading-*
and body-*
classes as you prescribe here, without enforcing disallows through linting rules of at least text-*
, I'd fear that contributors in the future would just use text-*
classes as they always would for any other project with tailwind, causing future styling inconsistencies.
@thansidwell This is likely a question for this project's lead dev, but what is the team's appetite for adding enforcement rules via Stylelint or ESLint to explicitly disallow tailwinds defaults of
text-*
or even these font class additions offont-size-*
? My thought is that while we could add in theheading-*
andbody-*
classes as you prescribe here, without enforcing disallows through linting rules of at leasttext-*
, I'd fear that contributors in the future would just usetext-*
classes as they always would for any other project with tailwind, causing future styling inconsistencies.
love this idea, are you able to take the lead on this?
Just added the changes in the PR above.
Couple things to note were:
@thansidwell while the PR made the requested wholesale changes throughout the app, it may be cleaner to simply map html elements to heading or body classes (eg: all <h1>
's should be heading-xl
's, all <p>
's should be body-md
's) — if this mapping were provided, we could just define the css once in the global.css
file, and not use any size classes in any of the copy elements, except for one-off cases.
@brandonfcohen1 this project doesn't seem to have any linting enforced — it may be a good idea to add at a minimum the react
and next/core-web-vitals
rules to make sure contributors aren't swapping codestyles based on their own local settings (I think I saw a PR earlier that was mostly just single-to-double-qoute changes). The .eslintrc.json
file I added with this PR would make it easy to add as you'd just need to add the appropriate extends:{}
and plugins: []
, but I figured I should leave that off in case there were team preferences for linting styles.
Hey @paulhchoi and @brandonfcohen1! I just found time to look at the preview. It looks great! I don't see any issues.
@paulhchoi To your question about whether to style by class like "heading-xl" or by HTML tag/element like h1, I've seen most use classes, in design systems and frameworks. I assume it allows for more flexibility. Maybe you want something to be an h1 for search engine purposes, but you want it to look like a small heading, like a heading-s.
@thansidwell gotcha yea I can align with that 👍
@paulhchoi So it looks like these changes are on staging. The headings resize beautifully.
One small issue I found is that the text on the map legend became even smaller. https://share.cleanshot.com/2N94qLst Could you quickly fix that or should we make a new ticket?
@paulhchoi I'll just write a new ticket to fix the text styles on the map legend.
@paulhchoi I'll just write a new ticket to fix the text styles on the map legend.
ah sorry about this miss, opening a PR for this now
Right now the text appears in all different sizes which gives an uneven, haphazard feeling. https://share.cleanshot.com/wSCPdJbF
We need to add a type scale system and text styles.
Next, apply these classes all throughout the site.
Here's the CSS to support this.