alt Hacker News> If you “View Source” on any “real” website, you’ll notice that everything has layers and layers of wrapper elements, so you might be tricked into thinking that wrappers are how you solve layout problems. I can’t really agree or disagree here, as I never wrote “production” CSS, but, in my experience, it’s much easier to understand if you do the opposite — restrict yourself to using only markup-meaningful semantic tags, and then figure out CSS which works with the markup you have.
CSS isn't powerful enough by itself to create any layout you want without modifying the HTML. You almost always need wrapper elements to group elements you want to align together for presentation purposes only (e.g. "a vertically centered row containing one paragraph next to two vertically stacked images"), so there often aren't semantic HTML tags that would make sense.
It's similar to how you use numerous groups/frames in design apps like Inkscape and Figma to help align elements, where nobody would suggest you were a bad designer for using groups that don't have semantic meaning.
You can only really avoid wrapper elements for simple Markdown style pages with simple designs, where the CSS for that is straightforward.
I think in these discussions, it needs to be clearer how complex the page designs being discussed are. The CSS advice that makes sense for simple Markdown style pages is very different to what makes sense for a complex web app UI or a highly designed marketing page.
Replies
I think this is a pretty pragmatic take, and I do something similar with all the web apps I’ve created since I started self employment close to 15 years ago.
As you mentioned sometimes there are unavoidable things you need to do in markup to make it work visually. Although lately grid & flex solve 95% of the problems that crop up for me fortunately.
> You almost always need wrapper elements to group elements you want to align together for presentation purposes only (e.g. "a vertically centered row containing one paragraph next to two vertically stacked images")
Challenge accepted: https://codepen.io/editor/mkantor/pen/019eb65b-5b17-70cc-872...
You aren't entirely wrong, but I think I'd change "almost always" to "often" or even "sometimes". A lot of the specifics come down to how you want stuff to reflow when the content and/or viewport sizes change.
> CSS isn't powerful enough by itself to create any layout you want without modifying the HTML.
This is true, but the better you are at CSS the fewer wrappers you'll likely have. It's also easier to manage styles with fewer wrappers, otherwise you often end up having to put things like height:100% on every wrapper to avoid messing up the layout.
I wouldn’t accept the premise that wrappers (i.e., <div>s) are to be avoided in the first place.
Perhaps less nesting is better in that it is more readable. But if you compensate by writing more complex CSS, then I don’t see how that’s an improvement.
> so there often aren't semantic HTML tags that would make sense.
Pet peeve of mine: there should really be `<grid>` and `<flex>` elements, as well as `<fi>` (flex item) and `<gi>` (grid item) for the child element instead of relying on a div soup with CSS attributes everywhere.
20 years ago everyone was sold css entirely on the premise that, once the standards were adopted by all of the browsers, we would all be writing purely semantic html with completely orthogonal and swappable css. And today literally no one designs web sites that way - html today is mostly specific to presentation. It feels like pretty dramatic technological failure to me.