The more time I spend with #Javascript Framework code, the more I am convinced the devolution and/or dislike of the #CSS Cascade makes sense. Whether it's building an entire application interface or a standalone app or a one-size "responsive" plug n' play app/site I'm seeing why.
2
5
7
If one views source derived from a #Javascript #Framework and opens a current in-browser dev tool, the #CSS is a godawful confusing mess! It is logical to just want to override conflicts in style with inline styles and/or !important. Educators may be looking at it backward. Me.
1
3
Instead of explaining the browser sort first, if we start with the most specific rule (Specificity algorithm) we end up with an actual #CSS rule that regardless of origin will apply given we follow (I'm almost sure) likely no more than 3 steps and two exceptions empowering devs.
2
3
The challenge now is to articulate what gets us to "most specific" as we develop, not as browsers interpret per se. I think I have it. I'll share when I'm close. If you know anyone looking at a specificity-first model of #CSS #Cascade please lmk and any feedback always welcome!

Jun 8, 2020 · 11:18 PM UTC

1
2
Replying to @mholzschlag
Some of this I think is still trying to figure out what we're doing (as the web dev community at large) with styling components, and having isolated styles for them. Many of the problems of specificity are about compartmentalising components, as far as I see?
1
1
2
Hey Sneds! Yes, the component issue is a big part of isolating styles. My thought is that can be even more powerful when applied well and of course: WHEN AND WHERE. One component does not fit all needs, and so on. So yes, very much a need to address, I agree my dearest YOU! xo/m
This tweet is unavailable
Bingo! That is exactly the point and goal I hope to articulate and help with using some process. I also believe dev tools are so over the top even I break down and want to just give up and resort to inline styles. I have once or twice when still actively developing for work.
1