[emmacharp]

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!

[Vinnl]

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 :)

[emmacharp]

Great!

1. some simple selectors can be used in specific contexts (like `html` for type inheritance, for instance). `flex-module` is a component name (albeit a very generic one only used for example purposes...) and `is-loading` is a "state class". I use simple prefixes to distinguish between selector types and `is` is one of them.

2. Breaking changes could be introduced through the Tailwind dependency tree. Some update could be necessary to patch an exploit, again breaking functionality. Updates become routinely necessary. Which is not the case for native code. Also, using new CSS features can be more taxing within the TW ecosystem than in with vanilla CSS. In a nutshell, it's about simplicity, maintenance and the perenniality of your code. On the other hand, you may be "lucky" and never experience something like the above. But I'd wager there's more chance that you will than not. At least, my own dev experience tells me this.

3. Well, I'd say it's a matter of scale... I see 60kb of CSS on Tailwind's homepage. If more than 80% is unused, that's something like 45kb of CSS. I think at this amount, you could see marginal improvements in rendering and loading. At least, more than with comething like 2-3kb of unused CSS. Hehe. But yeah, as I said, marginal. BUT! hehe, with a less monolithic approach to bundling CSS, as with links in components, for instance, there's a real gain to be had: the browser delays reading the files not being used in the current viewport. So, if you footer is not displayed in the first screem it's CSS won't be read, accelerating overall rendering. This, in my experience, makes a palpable difference.

Hope I'm being clear, english is not my first language. And thanks for the mental workout! Hehe.

[Vinnl]

Thanks! (Not a native English speaker here either, but was perfectly clear.)