I call my self experienced and informed about bleeding edge css. And I disagree every single item including font sizes and border box
CSS: Unavoidable Bad Parts
71–80 of 88 posts
Re: CSS: Unavoidable Bad Parts
#72I mean, this has a lot of out of date information which I guess is not surprising for someone who says I'm not an expert and don't do production CSS, but it is weird to get the suggestions that are pretty reasonable for 5+ years ago.
This comment could be improved by adding specific examples and explaining what people should be doing today instead.
I did consider to suggest that it was a bit weird to mention flexbox and not grid, but I figured most people who would have an interest in this would pick it up fairly quickly. I did also make another comment on this post that, at a sort of meta level, explained why I felt that the view of the author was wrong headed about modern CSS usage. That comment was pretty much just distilling some points I had been thinking to write as a longer article, but hopefully now I have it out of my system and I can get on to more important things!
Re: CSS: Unavoidable Bad Parts
#73Earlier quoted context omitted.
HTML describes the content, not visual display.
Not really. This would not be different to and associated elements, which are arguably better than a div soup.
Yes, really. Even is used to represent the data, not the layout, though it will be laid out as a table but it's probably the only element that does such a thing.
Re: CSS: Unavoidable Bad Parts
#74Earlier quoted context omitted.
HTML describes the content, not visual display.
If you remember earlier versions of HTML, with all the tables and font tag soup, it was not always the case. Sadly, it was easier building layouts with tables instead of CSS for a very, very long time.
How the elements were abused does not take away from the fact that HTML elements represent their content, not their layout except for which is probably the only the exception.
Re: CSS: Unavoidable Bad Parts
#75> 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 ta…
I think this has changed a lot since CSS Grid, especially. A lot of my HTML work has been removing "wrappers" either physically deleting them or in cases where they are "load bearing" due to some UI framework or component boundary making heavy use of `display: contents;` or `grid-template-${'columns' | 'rows'}: subgrid;`, depending.
Re: CSS: Unavoidable Bad Parts
#76Earlier quoted context omitted.
If you remember earlier versions of HTML, with all the tables and font tag soup, it was not always the case. Sadly, it was easier building layouts with tables instead of CSS for a very, very long time.
How the elements were abused does not take away from the fact that HTML elements represent their content, not their layout except for which is probably the only the exception.
These elements weren't "abused." It was the only alternative before CSS was around! Then CSS took years (decades?) to catch up to the simplicity of table-based layouts.
Re: CSS: Unavoidable Bad Parts
#77> 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 ta…
> 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.
I'd argue that a lot of times those groupings are meaningful.
Re: CSS: Unavoidable Bad Parts
#78> 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 ta…
> using only markup-meaningful semantic tags, and then figure out CSS which works with the markup you have
I agree with the approach you are suggesting, but the reason I find these wrappers pop up: it's VERY hard to make components composable without them.
Let's say you want to have a block that adds spacing between each item within it. Easy: it's flexbox with a gap. Oh no, but a child is displayed inline, and has weird vertical alignment. And another child has an unexpected align-self. Now you get wrappers on the children.
Maybe you want a button. It's got an icon with text. You need a wrapper on the text, because without a wrapper you basically can't get anything right (you can't rather bare text with CSS).
How about a checkbox? Should be easy. You want the component to have the checkbox on the left with the text on the right. You want to allow two rows of text, with the first being in bold (the label) and the second row being a description or help text. You wrap the whole thing in a label element because you care about accessibility. But you need a dummy div to render the checkbox, because you can't reasonably style checkboxes. And each row of text needs a wrapper, because bare text. And maybe another wrapper around the two rows, because while you can use CSS grid to position the two rows above each other, lord only knows what the checkbox is inside of and whether it's flexbox or grid, and the height of the label might be weird and jack up the positioning of your text. God help you if any of the rows have text that doesn't wrap and is wider than the width of the checkbox's container.
The unfortunate truth is that you probably don't need the wrappers, but there's an element of defensive coding that just makes it infinitely easier to get things right all the time with wrappers.
Re: CSS: Unavoidable Bad Parts
#79Earlier quoted context omitted.
> 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…
I was thinking more of a document with multiple paragraphs and images, where some paragraphs are grouped with images and some aren't. In the code from the link, the element is serving as the wrapper element, that gives you a hook to get the layout you want. But when you're not lucky enough to have a semantic wrapper tag like that, you've usually got to add a generic tag help. Or write CSS that's closely coupled with…
Grouped HTML: p text img img /p
Grouped CSS: p:has(img) {...} p img {...}
No group HTML: p text /p img img No group CSS: p:has(+ img) {...} p + img {...} p + img + img {...}
Valid, semantic, easy to target.
Re: CSS: Unavoidable Bad Parts
#80Earlier quoted context omitted.
You know, this speaks volumes. Layout is a complicated business, sure, but CSS just keeps having monumental shifts in how you're supposed to approach it year after year; it's as if it's done without any overarching theory/vision but merely groping in the dark, trying things and fixes, and seeing what sticks and doesn't suck too horribly (this latter part is optional; remember Yandex's BEM?)
Would you prefer that CSS never evolve, and our frustrations remain the same? Writing CSS today has gotten significantly easier with flexbox, variables and now nesting. BEM is not part of the CSS spec, that's just a design methodology.
I would prefer it to finally figure things out properly, and then just stop changing, yes.
> Writing CSS today has gotten significantly easier with flexbox, variables and now nesting.
Which, you know, are not some technically complicated ideas that simply could not have been done thirty years ago. Heck, existed, and so did the algorithm that laid it out, from the outset yet getting flexbox to replicate that functionality took literal decades. And nesting is in no way more complicated to implement than cascading.
> BEM is not part of the CSS spec, that's just a design methodology.
Yes, and it existed for a reason, to paper over the deficiencies of the built-in functionality.