My answer to that would be “How about in a small css global file”
When you have multiple css files there’s a tendency to allow them to expand infinitely. It’s just human nature.
I guarantee that if you showed me a large modular site that it could be recoded with almost 60% less css. (If you follow the person from the article I linked to earlier you will see he has just done that very thing. I don’t agree with everything he says but 90% of it is accurate. )
I do understand your approach and I think you are aware enough to do it properly. It’s just keeping a watchful eye on what you code
In the end it’s your site and sometimes you just need to go with what suits you best. No two people will fully agree on anything these days
Aside for your selectors, perhaps the problem is in the kind of CSS you are applying to the various elements.
Going back to the first post:-
Explicitly defining every element with absolute positioning and things like defined heights is the wrong way to go.
Let the content go with the flow so its position and dimensions take care of themselves, rather than rigidly micro-managing every element.
I have seen people code this way, thinking that’s the way to layout a page. It’s absolutely the wrong way to go about it.
I am not sure what you read out of my example but my apps have a header and a footer which is defined by corporate identity and have a fixed height. So it is not my choice to design this two elements
The problem I have with this is that thing may look the same right now, but who’s to say they will remain the same? Let’s say I have a header with links and a footer with links and right now they have the same backgroundcolor, link color, font size, etc. I could code that as one .menu and be done with it.
But, what happens if for some reason the links of footer need to have a different color? Sure, I can add a separate class for that. Now what if the background color changes too? And so on and so forth. At some point you’re left with some .menu that’s being completely frankensteined to behave like something else for the footer.
Now, if I started out with two separate components, one for the menu, one for the footer, this would not happen, because I can change both without affecting the other.
That isn’t to say you should do this always with everything you see. As with many things it’s a spectrum and sometimes it make sense to go to one end (i.e. when the likelihood of change is very high) while sometimes it makes sense to go the other end (i.e. when the likelihood of change is very low) or indeed, somewhere in between.
This is a time where I call upon an axiom you as a developer should be familiar with - refactor when appropriate.
But with the advent of css variables, and the different elements available, then if you’re building your site with semantic elements right out of the gate, then your points are if not moot, then minimized. If you call a header a header, a footer a footer and a menu as nav, then it’s much easier to select those elements without having to change your html at all.
Even if you have multiple navs, say one in the header and footer, then you select header nav and footer nav, again no html changes. Add in an id/class on the body, and you’ve now exponentially opened up the flexibility.
But I think you misunderstood my point (or I didn’t explain myself well). In Thallius’ example earlier, he said
For example one module only needs 1 div with some text inside. the next needs 5 divs and in each div are 3 other div and they all contain different text content, buttons etc.
In the very old past I would have created a div
<diiv width = "300px" height = "200px">
Today I create a class for this with not absolute sizes to make it able to resize on content.
My thought here is…can you approach this a different way? Can you use flexbox and padding/gap to get the look you want? Perhaps not, but it’s worth looking at and a consistent UI with less maintenance.
You will rarely use fixed heights on elements that hold fluid content such as text.
It’s a fragile concept that may break in a responsive design. The user for example may increase their text size via their browser controls and your fixed height will be broken when the words wrap to new line.
If the code that Sam referred to is actual code then I can say that you would never code a site in that way. Absolute positioning is not meant for structural content and would be impossible to manage in a responsive design.
Again this is something that programmers especially do not understand and try to pinhole all their content into fixed blocks. In responsive design you have to let the page breathe and ebb and flow with content as required. You don’t have control over everything as users have power in their own hands as well.
Css is more like herding sheep and you guide content where you want it to go rather than forcing it into a box. CSS is almost about giving up control rather than forcing control. You should create structures that are fluid and responsive and adapt to the content inside them. You never know the size of the device that is viewing your page so you need to cater for all eventualities; some of which will be beyond your control.
Use min-height instead of height and then at least the element can grow if needed.
Use flexbox or grid instead of absolute positioning and then you keep control of the flow of the page. Controlling the flow is a number one priority and a lot of people still get it wrong.
Use absolute positioning only in controlled places where it does not impact the flow. Generally an icon or image to the right is fine but blocks of text are not really suitable candidates for absolute positioning unless you wanted overlapping content.
Apologies if the code Sam referred to was not meant to be actual code .)
