There is a famous book (at least it was some time ago), by the person who brought us JSON - JavaScript: good parts. It basically teaches which part...
For further actions, you may consider blocking this person and/or reporting abuse
I don't know that you can really avoid z-index. You have to use it sooner or later anytime there's overlapping elements, and it's at least in common with every single UX design toolkit and animation software ever. But I agree that z-index
9999999(or-999999) is terrible. There's gotta be a better way; but since there isn't, we live with it.P.S. I find it rather ironic how much thinner "Good Parts" is to the "Javascript" book in the picture. Sums up my feelings on JS quite well, ha ha!
We can use SASS to overcome this problem, we can achieve that by making a separate file, let's call it z-indexes-defaults which will contain all the z-indexes definitions for the main elements that will overflow on each other or on the base content,
That will prevent us from facing such a problem and all your all z-indexes definitions are in one place and its values are represented by meaningful variables names
I dunno. Somehow this feels more icky than z-indices.
In the given example author managed to avoid using z-index for a modal. So I guess it is possible to do much less than we do typically.
Margins are inevitable though, can not do FE without them but need to have clear rules of which components can use them and keep consistent within an application.
For example all sub-component should generally avoid having OUTER margins and leave that to the parent or container component(s) to decide by way of padding perhaps. A sub-component should be allowed to define its own internal margins/padding (between its own elements) only.
You can refuse from margins, for example use grid and gap properties, or "spacer" component, or flexbox. (Padding allowed though)
Grid not fully supported on IE 11 so not always possible to use grid ... Many webshops still support this browser. :)
I guess we can wait a bit :-) Or maybe use some kind of polyfill/transpiler, like this one.
I hope you're also making a post about "The good parts"! If so, one of them is definitely utility classes like Giorgos mentioned. A great example of this is Tailwindcss. The speed at which I can now build nice looking applications is great.
I suppose that brings me to one of the bar parts of CSS as well: when you start to mix styling practices, your stylesheets become uncontrollable. So for example, mixing BEM and utility classes, with scope component styles. It becomes a huge mess and you start to replicate your code code to each fit a slightly different use case.
I'm not qualified enough for this task
You definitely are! If anything, you'll learn something new. Give it a shot 😁
I'll leave it to you
Hey stereobooster, I've got the impression that a lot of "old school" developers really like global styles. They praise the cascading feature of css, which helps them keeping their code "dry". I think that's one of the reasons why many of them hate component based spa frameworks/libraries - they're "forced" (or advised) to split their css, too. Unfortunately I struggle to convince them that decoupled components are of much greater benefit than "dry" css.
What's your opinion? Can you give me some more arguments for my discussions?
It's a really big topic here (and to be fair, not what I aimed in this article). I will be not the first and the most significant author to talk on the subject. Maybe check those talks:
I don't consider global code (classes) bad on their own sometimes it is needed. I think they are called utility classes with some of the css frameworks. And yes dry is one of the reasons to use it but another one is consistency. For example you want a certain animation done when hovering over a link on LOTS of parts of your site/app can be different components in modern web apps. Without a reusable utility class you are recreating the same exact code (perhaps with copy/paste) and might run into inconsitencies if you have to modify this behaviour later on but you are also bloating the final .css with the same code multiple times.
In that sense those classes are global and not part of any component and any component can choose to use them when needed.
Oh, I din't mean shared/global code in general, Giorgos. I only had global CSS code without namespaced classes in mind (...where you can shoot yourself in the foot with cascading selectors).
Inline styles ("but look, it works so.... what's the problem") , !important ("just in case"); or id css selectors ("I have always did it this way") ... We have seen and heard it all, please don't ever do this unless you really need to !
Oh nice. I will add this to the list.
Interesting take on not using margins. I wonder how having spacer components are for bloat, accessibility and maintaining code.
I can't say anything about bloat and maintaining code. But accessibility will be fine, it is empty element invisible to screen reader the same way as margin 🤷♀️