Providing a base/default css

[longrunningprocess]

I'd love to see a common.[base|defaults].min.css provided that would take some of the work of coming up with my own design system away. For now, I get some nice opinions in the reset and I see plenty of tokens out there for common things, e.g., --agnostic-h2. But I'm still in the position of doing stuff like this:

@import 'agnostic-svelte/css/common.properties.min.css';
@import 'agnostic-svelte/css/common.resets.min.css';

...

body {
	/* https://github.com/AgnosticUI/agnosticui/blob/master/agnostic-css/public/css-src/typography.css */
	font-family: var(--agnostic-font-family-body);
	font-size: var(--agnostic-body);

	color: var(--agnostic-font-color);
	-webkit-font-smoothing: antialiased;
}

p {
	max-width: 75ch;
}

/* https://github.com/AgnosticUI/agnosticui/blob/master/agnostic-css/public/css-src/typography.css */
h1 {
	font-size: var(--agnostic-h2);
}
h2 {
	font-size: var(--agnostic-h3);
}
h3 {
	font-size: var(--agnostic-h4);
}
h4 {
	font-size: var(--agnostic-h5);
}

I'd been able to move much faster if the wisdom and experience of this team had gone ahead and put things in place that will, in my opinion, become very boiler-plate (and cause friction to new adopters).

common.[base|defaults].min.css is just one idea, it could be named different things of course or the resets could be renamed normalize and include some of the "base" decisions. Of course everything can still be overridden but I get the impression from the code and what I've read about Rob's experience that very few people would be in a better position to make decisions about common best practices for everyone than he.

What are your all's thoughts? Would you just suggest people bring their own reset, normalize, sanitize, etc.?

[roblevintennis]

I like this idea overall. I think there'd be a delicate balance between too opinionated vs not opinionated enough.

Especially for line measures as that depends on so many factors.

My sense is I could make this defaults script as an opt-in module. My instinct thus would be to not include it in common.min.css so user can import it individually in the same manner as I mention in the advanced usage docs where you import things individually.

Do you agree?

Besides the example you've shown is there anything else you'd expect to see in a n opt in defaults script?

/* ideas */


*,
*:after,
*:before {
  box-sizing: inherit;
}

html {
  box-sizing: border-box;
}

/* block quotes?

Clamped headings? But then we'd have to be careful and weigh benefits vs risk and complexity for zooming cases:

https://www.smashingmagazine.com/2022/01/modern-fluid-typography-css-clamp/#accessibility-concerns

*/

Update: Looks at reset.css in the source code and it already has:

html {
  box-sizing: border-box;
}

*,
*::before,
*::after {
  box-sizing: inherit;
}

Looking at some lighter weight frameworks I don't see much in addition to above plus what you've showed.

I'm a bit nervous about the paragraph ch thing🤔 I could do the thing where it's there but commented out with an explanation though. Thoughts?

[longrunningprocess]

I also will research my friend Austin Gil's project for this:
https://bedrocss.austingil.com/

wow, I really like his stuff! I love that he scaled the fonts on some of the headers! I think I'll plug his stuff in and see how it compares to the modern-normalize.

[roblevintennis]

Interestingly enough, I'm supposed to have a chat with Austin et al on their podcast next week. I had a closer look at bedrocss and filed a couple of issues: AustinGil/bedrocss#10 and AustinGil/bedrocss#11 -- honestly, I'm still very much learning on that level of nuance (we're all still students!) so my tickets could be invalid or won't fixes. We'll see.

Btw, I noticed you started the headings in your example where heading 1 is defined as --agnostic-h2. Is there a reason for that? I would think if you'd like them to be smaller you could just redefine those (especially with the latest :where(html) updates made. Then at least the semantics wouldn't get confusing for say a team of devs. Totally a nitpick but thought I'd ask.

[roblevintennis]

See #123 issue and WIP pull request:
#124

[longrunningprocess]

Interestingly enough, I'm supposed to have a chat with Austin et al on their podcast next week.

I found "The Function Call" in Google podcasts and subscribed so I'll keep an eye for the talk!

Btw, I noticed you started the headings in your example where heading 1 is defined as --agnostic-h2. Is there a reason for that? I would think if you'd like them to be smaller you could just redefine those (especially with the latest :where(html) updates made. Then at least the semantics wouldn't get confusing for say a team of devs. Totally a nitpick but thought I'd ask.

Yeah, you're right, that is a better wya to do it, thank you!

[roblevintennis]

@longrunningprocess try updating agnostic-svelte to version 1.1.8 -- you should then be able to pull it in as I have here.

Here's my test and some hopefully helpful annotations:

[roblevintennis]

I think #123 provides this now. Thanks for the recommendation!

[longrunningprocess]

This is perfect, thank you!