undefined | Better HN

0 pointsemmacharp1y ago0 comments

Great questions/problems!

1. I address the problem of relevance by inserting the CSS right into the component with a link tag. If the component is not used, the CSS isn't either. A positive side effect of this technique is that you always have an easy access to the CSS by following the link in your editor of choice. As for the relevance of the rules inside the component, the said component should be light/simple enough that this isn't harder that glancing a minute (max!) at both files.

2. You can use Stylelint to ensure adherence to specific rules. I have developed a config aiming to prevent these kinds of problems. You can find rules, guidelines and a link to the Stylelint config (still beta) at https://ecss.info.

3. A CSS theme file with custom property design tokens is sufficient. As I understand, Tailwind 4.0 made the switch to CSS tokens. You can thus use the same naming convention for your tokens in native CSS.

As complementary advantages you get future-proof code, no build step, and a lot less unused CSS (for instance, Tailwind's own homepage sports 85% unused CSS!).

I'm happy to elaborate further or respond to any subsequent questions you may have!

0 comments

Vinnl1y ago

> I address the problem of relevance by inserting the CSS right into the component with a link tag. If the component is not used, the CSS isn't either.

Do the selectors in those style tags not apply globally? How do I prevent contributors (including myself) from accidentally writing a selector that affects HTML in other components? I see ECSS allows plain tag selectors for example?

Isn't the design token variable file quickly going to balloon? As you mention, it looks like Tailwind provides this now as well, but you'll still want to run the build step of generating the minimal style sheet that provides only the tokens you actually use, rather than having to compile that style sheet manually.

As a related question: if you're already running Stylelint, what's the problem with a build step?

And: is the CSS on Tailwind's homepage actually unused, or used in dynamically added HTML? Is the additional download+parse size actually significant, or does it e.g. compress well and not affect performance that much? Throttling network speed at least doesn't result in a terrible loading experience for me, it seems.

emmacharpOP1y ago

1. The stylelint config will flag any selector not scoped (be it a class or an attribute) to the filename. This way you'll be notified if any selector could be misapplied essentially preventing these global accidents.

2. You could use a build step for this, yes. Personally, I don't because the theme files more or less contain always the same tokens. I rarely add any (colors being the most frequent) and if I do, the cost of it being unused is minimal. My standard full theme file is around 5kb.

3. Stylelint complements my work but isn't necessary. My code does not depend on it to work, contrary to Tailwind, for instance. I'm free to stop using it any time.

4. It's a monolothic file containing all the code needed for the whole site and not only the page I'm looking at now. It may not make that much of a difference in performance, but still, the browser downloads CSS code it does not need now and then must read through all of it to apply needed rules. Not optimal.

By the way, it's great you came back with further questions! Hope to have addressed them at your satisfaction. Still at your disposal if you have more!

Vinnl1y ago

That generated some more question :)

But on the ECSS homepage I see selectors like `html`, `.flex-module` or `.is-loading` (I'm assuming `flex-module` and `is-loading` aren't components - if they are, then that sounds like being pushed towards a layer of indirection that I'd like to avoid?) - aren't those likely to affect other components?

What's the disadvantage of not being able to stop using Tailwind at any time? How likely is that to play out?

Why does it matter if something's "not optimal" if it doesn't make much of a difference in performance? (See also: not removing unused styles from your theme files :)

1 more reply

j / k navigate · click thread line to collapse

0 pointsemmacharp1y ago0 comments

Great questions/problems!

As complementary advantages you get future-proof code, no build step, and a lot less unused CSS (for instance, Tailwind's own homepage sports 85% unused CSS!).

I'm happy to elaborate further or respond to any subsequent questions you may have!

0 comments

Vinnl1y ago

> I address the problem of relevance by inserting the CSS right into the component with a link tag. If the component is not used, the CSS isn't either.

As a related question: if you're already running Stylelint, what's the problem with a build step?

emmacharpOP1y ago

3. Stylelint complements my work but isn't necessary. My code does not depend on it to work, contrary to Tailwind, for instance. I'm free to stop using it any time.

By the way, it's great you came back with further questions! Hope to have addressed them at your satisfaction. Still at your disposal if you have more!

Vinnl1y ago

That generated some more question :)

What's the disadvantage of not being able to stop using Tailwind at any time? How likely is that to play out?

Why does it matter if something's "not optimal" if it doesn't make much of a difference in performance? (See also: not removing unused styles from your theme files :)

1 more reply

j / k navigate · click thread line to collapse