> 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.
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.
20 years ago everyone was also sold OOP on the premise that inheritance was the best thing to ever happen to programming. Turns out people are wrong sometimes. And especially when they're being idealistic about things.
The concept makes more sense for styling simple document style pages from 20 years ago, but it hasn't scaled to modern designs, complex web UIs and responsive pages that we want to code now, which isn't that surprising.
> 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
I think of HTML + CSS as the presentation layer now, and the data lives in your e.g. database and Markdown files, so the data and its presentation are still separate enough.
The idea of just swapping out the CSS to completely restyle a complex site is nice, but people need to accept this hasn't worked out (and not because devs are bad at CSS) and move on.
If you're good, the same HTML serves mobile and web clients. It's a PITA to write, sure, but if that isn't CSS succeeding then I don't know what is. There's a ton of stuff I wish was different about CSS and HTML (and JS), but going from a small portrait device to a large landscape viewport with the same html? HTML does the HTML stuff and CSS does the style stuff. The fact that you have to tweak the HTML and CSS in a loop until it's right, in order to get to the finished state doesn't indight the fact that it's the same HTML for different clients.
> 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.
> 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.
> 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.
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.
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")
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.
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 <body> 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 the HTML, so they aren't really separate anyway.
Multiple sequential paragraphs all sitting next to two images? Or multiple rows, each containing a single paragraph + two images?
The latter probably would need an element for each row to be maintainable/scalable, but depending on the content, `<article>` could be a semantically-meaningful container. Or (again, depending on the content) it could make semantic sense to put the `<img>` elements inside the `<p>` elements.
This is still adding wrapper elements to get the layout you want. Even if you can force yourself to come up with some vague semantics behind the wrapper elements (that you wouldn't have otherwise added), I don't see how it's much better than using a generic tag and it shows you need to modify HTML to modify the presentation in practice.
Visual design involves a lot of grouping and aligning elements, and there isn't always semantic reasons for it. Grouping is usually best done in the HTML, so it's hard keep this part of the visual design out of your HTML.
Presumably there's some natural semantic relationship between the elements if you're going for that kind of visual layout (and even blind users might benefit from encoding that relationship in the DOM), but I don't necessarily disagree with your overall point.
Sparingly-used non-semantic grouping elements only inserted when absolutely necessary is a pretty different story from the "layers and layers of wrapper elements" that the article mentions, though.
---
> you need to modify HTML to modify the presentation in practice
If you're e.g. grouping together content that was previously unstructured, arguably that's a semantic change as well as a presentational one.
> 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.
You're supposed to only use custom elements with a dash in the name. Otherwise the spec can add an element that means something new, and you've accidentally used that name.
For that to work I would need to define a custom component from JavaScript, wouldn't I? (and I thought custom components had to contain an hyphen in there name, is that wrong?)
afaik to create a CustomElement you need to use dashes, yes, but in this example `<grid>` is an HTMLUnknownElement, which renders just fine. some discussion here: https://stackoverflow.com/a/22545622/2393963
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 <table> 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.
Yes, really. Even <table> 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.
> Yes, really. Even <table> is used to represent the data, not the layout
Nope. It's a html tag to lay out data in a table form!
> but it's probably the only element that does such a thing.
<pre>, <b>, <i> all come with an associated layout implication. But the worst offender are <div> and <span>, which carry zero semantic meaning and just means “I'm a block element” and “I'm an inline element”, those are pure layout element. In fact are the ones I'm using as template for my demand of <flex> or <grid> elements.
And html isn't just tags, it's tags and attributes on these tags, and things like hidden, height or width are indisputably related to layout and not to data.
The idea of HTML as a pure semantic layer with no layout consideration may be a general design philosophy for the language, but that's by no way a faithful description of what HTML actually is in practice. And pretending it is, isn't helping.
Eh. HTML in its recent iterations made it very clear to try and separate itself from layout concerns. It's why <font> was deprecated.
With that: <table> is really only meant for actual tabular data and not about layout. It really isn't about the layout. It got abused for layout because it was the only thing that worked in a lot of cases (especially amusingly enough, email)
<b> and <i> I think I'd agree, even if they did eventually get retconned to be "bring attention to" and "idiomatic text". Same with <strong> and friends. This happened with other elements too.
I think it's fair to acknowledge the realities (people who are writing HTML a lot of times use <b> to mean "bold") of usages but ideally the semantic meanings are useful. I have seen cases where "<strong>" emphasizes it by doing something other than bold for example
> HTML in its recent iterations made it very clear to try and separate itself from layout concerns.
That's what I'm saying, it's a general design principle for new developments, but that's it. (And I don't think that's a good one)
> It really isn't about the layout. It got abused for layout
It wasn't abused for layout, it was all about layout in the first place. If it was about data it would never have been possible to “abuse” it for layout, because an heterogeneous table with nested sub tables makes no sense from a “data” point of view. The fact that this was supported from the beginning shows what it was built for.
> but ideally the semantic meanings are useful. I have seen cases where "<strong>" emphasizes it by doing something other than bold for example
But I agree with that. I'm not saying we shouldn't have semantics elements in HTML, I'm saying that pretending that HTML “is only about data” is silly in a world were something like 80% of HTML tags in web apps are <div> and <span> that are here only for layout purpose.
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.
To call a CSS pixel not an actual pixel but a measurement of an angle at a reading distance is... technically correct... but isn't really representative of how it's actually rendered. On a non Hi-DPI display at 100% scaling in the browser and OS, a px is a device pixel. An css inch is considered 96px, with the assumption that a CSS inch is an imperial inch on a 96 DPI display.
Yes, it's a bit fuzzy now with modern displays (especially when display scaling is not at a whole number haha) but it just kinda feels like searching for something to complain about. If your browser and OS doesn't get in the way you can get exact measurement. This also applies to almost any UI framework that has some integration with the OS.
So many complaints about web technology, where is the replacement? I'd be interested to know if there was the one true layout system that everyone agrees on
TeX [0] is in some sense "the one true layout system", but it's designed for printed documents, so it doesn't work on the web [1]. And in some ways, it's much simpler than CSS (you can build nearly everything from only a dozen typesetting primitives or so), but in other ways it's much more complex (since TeX is itself a fairly complex programming language). It's typesetting quality is still unbeaten by any of its competitors though, even 50 years after its first release.
My understanding is that it's designed for fixed-size documents? There's a big difference between a layout system for that, and one where size of a document can vary wildly, up to completely opposite aspect ratios
I guess I'd call it mostly fixed: most TeX engines only produce a single page size at a time, but you generally only need to modify a single variable to change the page size and, after recompiling the document should be perfectly reflowed into the new page size. This is not helpful at all for someone who wants to be able to freely rotate their phone, but it's still better than InDesign or Word where changing the page size will probably break the layout.
There is actually a TeX extension that supports viewers arbitrarily changing the page size of documents [0], but it's fairly new, and as far as I'm aware it has essentially zero adoption.
The web is probably the closest thing the software industry has to a truly universal, open application platform.
There is corporate influence, but it is substantially more vendor-neutral than any other UI platforms.
The web stuff mostly uses licenses such as MIT, Apache 2.0, and BSD. GPL-licensed projects exist, but still many more on permissive side.
Web is based on open standards developed through organizations and specifications are publicly available, royalty-free, and implemented by multiple independent browser engines rather than being owned by a single corporation.
The complaints shouldn't require a replacement at least in the web's case the replacement is still the web standard, a better, iterated version. It's a living standard and criticism keeps the platform slowly but surely evolving. I think it's a healthy feedback loop.
I remember that there were these talks called "Linux sucks" (IIRC) and the premise wasn't that we should start using Windows but more like "we can do better and improve it." Not every complaint needs to come with a solution or better alternative.
Not which works under the same constraints as the web.
But for simpler scenarios (like fixed-sized paper, desktop displays before super-wide screens), you can have both simpler and more precise layout systems.
> There isn’t a fully general solution to positioning and sizing GUI boxes.
flexbox. You can literally recreate any fully responsive desktop style GUI with it. You just need to layout your elements the same way you would in a GUI designer like QtCreator or Glade. Which means thinking in terms of divs with flex-grow set on them to get the automatic container expansion you get with "vertical boxes" or "horizontal boxes". These divs will sometimes be empty if you want a simple "expander" box.
Once you have it down you can look at any desktop GUI and just inherently understand how it maps into this flexbox model.
Yea, back in the day there was this h-box and v-box containers for the Widgets. I still think of my HTML that way, and div-soup to make them (is it soup tho?). Used to be TD soup.
> Let's start with the basics: if you write`font-size: 16px`then `16px` is the size of what? Sadly, the answer is "nothing in particular" -- this is a size of a virtual box around the glyph, but the box isn't tight, and the size of the glyph varies, depending on the font. Luckily, `font-size-adjust` property can fix it, and make `font-size` consistent across fonts.
All modern browsers default to 16px, but for accessibility and sanity reasons, we shouldn't use pixels.
By default, 16px = 1rem. You don't need to declare it; it just is.
Also by default, 16px = 100% if using percentage for font-size.
> Can you just set `font-size: 18px`or whatever works best for your chosen font? I think the answer is yes, but there are some caveats to keep in mind.
If you want to manually increase the base size, using relative units is the answer: `html { font-size: 1.125rem }`. Since by default, 1rem = 16px, 1.125rem is 18px.
> Setting `font-size` in your CSS disables that second approach.
Setting `font-size` in pixels disables changing the browser's default size; works fine with relative sizes.
If the goal is not having to learn the intricacies of CSS, just use the built-in type scale:
BTW, the main use case of `font-size-adjust` is for changing the font size of your fallback font incase your primary web font doesn't load or if it takes too long depending on what `font-display` is set to. You want the metrics of the fallback font to match the primary font so the text doesn't shift [1].
> > Let's start with the basics: if you write`font-size: 16px`then `16px` is the size of what? Sadly, the answer is "nothing in particular" -- this is a size of a virtual box around the glyph, but the box isn't tight, and the size of the glyph varies, depending on the font. Luckily, `font-size-adjust` property can fix it, and make `font-size` consistent across fonts.
> All modern browsers default to 16px, but for accessibility and sanity reasons, we shouldn't use pixels.
That's not what that means. font-size specifies the size of the font's em box, but the correlation between the em box and the visual size of the font is not consistent across fonts. font-size-adjust can adjust how a font-face responds to the font-size so that the sizing is consistent with other fonts of that size. For example, capsize is easier to implement that way.
This is bad advice. You should only use rem for text, e.g. font sizes and paragraph margins.
If the user is on a phone and has a larger default font size due to vision difficulties, making padding scale with the font size takes screen real estate away from the larger text the user needs.
Thanks for the tip. That does make sense, although I do think having your default CSS-defined font sizes (across your whole app, not just the main content) be a reasonable size should be the first priority.
Also, not having ridiculously oversized margins, like so many 2019-2022 websites trying to look "modern" used to use.
old.reddit.com is one example where the paddings still look good when magnification is set to 150-170% (which I have to do because of the tiny default font size). I think doing it that way but with better readability at 100% zoom, would be a decent solution.
This is true. I use increased font size on my phone, and so many websites are borderline unusable because of massive unnecessary padding. But I am also a culprit of using rem for everything. What is the alternative? Pixels?
Perfect example for you: indeed.com (desktop site). unless its been fixed recently, huge swaths of area are already empty padded space, made worse by zooming
I 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.
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?)
You really don’t have to change your css. My personal website has been using roughly the same css for a decade. Why not?
Sure if you are a designer and want to follow trends, you’ll have to keep your css skills up to date. But for most websites, you can use css from a decade ago.
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, <table> 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.
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!
> Use CSS nesting to avoid writing “far reaching” selectors and style component-per-component
I view nesting as a footgun. I recommend trying to restrain all CSS to one selector, and to instead view additional qualifiers as an escape hatch where needed. Death to specificity.
Person who hasn’t spent enough time understanding web design feels entitled to make a CSS mark sheet.
Most of the “bad” is really “I haven’t worked with this enough and I will judge it from my limited point of view”.
What a waste of time
> An ersatz CSS tutorial for people who need to style a web page, but aren’t web developers. I am a wrong person to write this kind of thing, as I have neither the time, nor experience.
I'd say this disclaimer at the top speaks for itself!
Note: The following of course varies from site to site based on how design focused the site needs to be.
I had thought about writing some things about this, but I will put a quick observation here
>restrict yourself to using only markup-meaningful semantic tags, and then figure out CSS which works with the markup you have.
this used to be the best practice advice about 20 years ago. If you've been around long enough in programming, especially in web development, you will see cycles of best practice advice where the thing you were told as the best practice at one time becomes the worst practice later.
For example at one time it was considered "best practice" to put script tags at the head of the document.
Anyway this guy really isn't the person to give you best practice advice, as he notes.
The semantic tags advice is dear to my heart and I wish it were so, but it is wrong, unless the site you are working on is the online representation of a textbook or something highly structured like that, in which case it is spot on.
The reason why it is wrong is that most of the web is a design focused medium, as opposed to a meaning focused medium. In a meaning focused medium the semantics are the most important thing, because semantics are how we convey meaning. That's pretty much tautological there.
In a design focused medium obviously semantics of things are important, but so is arbitrariness. To see that arbitrariness is important, pick up any highly visual magazine that has been applauded for its design aesthetic. Obviously no magazine is completely arbitrary but even more structured ones like The New Yorker need to do somewhat arbitrary things with the layout and design to enforce the rules of taste which guide it.
It is not impossible for a design focused publication that in moving between articles that the look of headlines change (although always recognizably headlines), the necessity of splitting things up with visually arresting details that delight the reader is common place, typography and images are there to delight the visual sense, not to clarify a point being made in the article, as a common rule.
If you were to try to semantically describe all these effects and things with meaningful class names you would end with lots of drivel, essentially, or things that mixed presentation description with semantics like ".ArtDecoHeading" perhaps, and that is because the difference in presentation of many of these things communicate absolutely not semantic value but only that it looks cool or nice or whatever way you want to describe the effect of design on the target of the design.
This relates to lots of CSS frameworks where the names of classes describe not what the element is or means, but rather what the class does, because when design affects are placed in a somewhat semi-arbitrarily manner this is really the most sensible way to describe a lot of classes.
Again, as nothing is completely arbitrary you will find things that are a mix of semantic classes like
".productTitle"
Semantics and Presentation mixed
".bigHeader"
and pure presentation that is trying its best to seem semantic somehow
".sideBoxSlideIn .upDownJumper"
I mean definitely you have to identify what parts of your application have semantic meaning, where the design will not arbitrarily affect them, such as .productTitle, but I believe in most modern web development much of what you will be doing is not semantic styling, but design styling.
And when you are doing design styling you might find you're creating layers and layers of wrapper elements, because making wrappers is often one of the easier ways to solve arbitrary layout problems.
On edit: this was partially prompted by the guy claiming never to have written production CSS and saying he is not really the person to be giving advice here, and I agree because he does not understand the actual needs of web development as a design based medium. Which is why he suggests such previous best practices as don't use classes and stuff like that which just doesn't work because to be able to do arbitrary layout without classes we would need to have millions of element types to play around with and then you have just recreated the problems with classes, only worse.
My experience working with other peoples code is that they often use too many wrappers. I don't mind using some wrappers, often they're just necessary. But I'll often see components with like 4+ nested divs where half of them or more can just be removed with no visual change. Not to mention spans, some people just use spans for everything, it's all divs and spans.
Personally I like to try to use semantic HTML where possible, as it helps with a11y and is nicer to read and work with. But I don't mind using some container/wrapper divs to make things look right.
It's also worth noting that semantic markup is not a feature of CSS, it is a feature of HTML. CSS has almost no power if something like a scraper or a reader mode chooses to ignore it. Of course that would be pandemonium and we would never get good results.
I feel like something in the CSS camp that could be highlighted in a "great idea, okay implementation, poor reception" that the OP is going for is print stylesheets. Those are incredibly underused.
My experience with responsive breakpoints is that they require compromises and therefore it's hard to make a manager commit to them: everything must look perfect, and identical, on every different device that exists, and if it doesn't it's the designer's fault.
> 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.
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.
20 years ago everyone was also sold OOP on the premise that inheritance was the best thing to ever happen to programming. Turns out people are wrong sometimes. And especially when they're being idealistic about things.
The concept makes more sense for styling simple document style pages from 20 years ago, but it hasn't scaled to modern designs, complex web UIs and responsive pages that we want to code now, which isn't that surprising.
> 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
I think of HTML + CSS as the presentation layer now, and the data lives in your e.g. database and Markdown files, so the data and its presentation are still separate enough.
The idea of just swapping out the CSS to completely restyle a complex site is nice, but people need to accept this hasn't worked out (and not because devs are bad at CSS) and move on.
I feel like CSS would be in a much better place if they went with the Cassowary proposal for layout.
It would avoid the whole mess of block vs table vs float vs flexbox vs grid (and also absolute vs relative vs fixed) positioning.
Basically, it feels like 90% of CSS is it trying to fix its past layout mistakes & limitations.
If you're good, the same HTML serves mobile and web clients. It's a PITA to write, sure, but if that isn't CSS succeeding then I don't know what is. There's a ton of stuff I wish was different about CSS and HTML (and JS), but going from a small portrait device to a large landscape viewport with the same html? HTML does the HTML stuff and CSS does the style stuff. The fact that you have to tweak the HTML and CSS in a loop until it's right, in order to get to the finished state doesn't indight the fact that it's the same HTML for different clients.
GP said:
> completely orthogonal and swappable css.
You're talking about having a single CSS and HTML page for multiple layouts, there aren't the same thing at all.
a lot of semantic features like the document outline algorithm were never actually implemented by browsers so it was hindered from the start
> 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.
> 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.
> 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.
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.
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.
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 <body> 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 the HTML, so they aren't really separate anyway.
Multiple sequential paragraphs all sitting next to two images? Or multiple rows, each containing a single paragraph + two images?
The latter probably would need an element for each row to be maintainable/scalable, but depending on the content, `<article>` could be a semantically-meaningful container. Or (again, depending on the content) it could make semantic sense to put the `<img>` elements inside the `<p>` elements.
This is still adding wrapper elements to get the layout you want. Even if you can force yourself to come up with some vague semantics behind the wrapper elements (that you wouldn't have otherwise added), I don't see how it's much better than using a generic tag and it shows you need to modify HTML to modify the presentation in practice.
Visual design involves a lot of grouping and aligning elements, and there isn't always semantic reasons for it. Grouping is usually best done in the HTML, so it's hard keep this part of the visual design out of your HTML.
Presumably there's some natural semantic relationship between the elements if you're going for that kind of visual layout (and even blind users might benefit from encoding that relationship in the DOM), but I don't necessarily disagree with your overall point.
Sparingly-used non-semantic grouping elements only inserted when absolutely necessary is a pretty different story from the "layers and layers of wrapper elements" that the article mentions, though.
---
> you need to modify HTML to modify the presentation in practice
If you're e.g. grouping together content that was previously unstructured, arguably that's a semantic change as well as a presentational one.
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.
> 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.
There's nothing stopping you from defining those yourself for your own websites:
will work in every modern browser.You're supposed to only use custom elements with a dash in the name. Otherwise the spec can add an element that means something new, and you've accidentally used that name.
For that to work I would need to define a custom component from JavaScript, wouldn't I? (and I thought custom components had to contain an hyphen in there name, is that wrong?)
try it!
afaik to create a CustomElement you need to use dashes, yes, but in this example `<grid>` is an HTMLUnknownElement, which renders just fine. some discussion here: https://stackoverflow.com/a/22545622/2393963TIL thx!
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 <table> 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.
Not really. This would not be different to <table> and associated elements, which are arguably better than a div soup.
Yes, really. Even <table> 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.
> Yes, really. Even <table> is used to represent the data, not the layout
Nope. It's a html tag to lay out data in a table form!
> but it's probably the only element that does such a thing.
<pre>, <b>, <i> all come with an associated layout implication. But the worst offender are <div> and <span>, which carry zero semantic meaning and just means “I'm a block element” and “I'm an inline element”, those are pure layout element. In fact are the ones I'm using as template for my demand of <flex> or <grid> elements.
And html isn't just tags, it's tags and attributes on these tags, and things like hidden, height or width are indisputably related to layout and not to data.
The idea of HTML as a pure semantic layer with no layout consideration may be a general design philosophy for the language, but that's by no way a faithful description of what HTML actually is in practice. And pretending it is, isn't helping.
Eh. HTML in its recent iterations made it very clear to try and separate itself from layout concerns. It's why <font> was deprecated.
With that: <table> is really only meant for actual tabular data and not about layout. It really isn't about the layout. It got abused for layout because it was the only thing that worked in a lot of cases (especially amusingly enough, email)
<b> and <i> I think I'd agree, even if they did eventually get retconned to be "bring attention to" and "idiomatic text". Same with <strong> and friends. This happened with other elements too.
I think it's fair to acknowledge the realities (people who are writing HTML a lot of times use <b> to mean "bold") of usages but ideally the semantic meanings are useful. I have seen cases where "<strong>" emphasizes it by doing something other than bold for example
> HTML in its recent iterations made it very clear to try and separate itself from layout concerns.
That's what I'm saying, it's a general design principle for new developments, but that's it. (And I don't think that's a good one)
> It really isn't about the layout. It got abused for layout
It wasn't abused for layout, it was all about layout in the first place. If it was about data it would never have been possible to “abuse” it for layout, because an heterogeneous table with nested sub tables makes no sense from a “data” point of view. The fact that this was supported from the beginning shows what it was built for.
> but ideally the semantic meanings are useful. I have seen cases where "<strong>" emphasizes it by doing something other than bold for example
But I agree with that. I'm not saying we shouldn't have semantics elements in HTML, I'm saying that pretending that HTML “is only about data” is silly in a world were something like 80% of HTML tags in web apps are <div> and <span> that are here only for layout purpose.
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.
To call a CSS pixel not an actual pixel but a measurement of an angle at a reading distance is... technically correct... but isn't really representative of how it's actually rendered. On a non Hi-DPI display at 100% scaling in the browser and OS, a px is a device pixel. An css inch is considered 96px, with the assumption that a CSS inch is an imperial inch on a 96 DPI display.
Yes, it's a bit fuzzy now with modern displays (especially when display scaling is not at a whole number haha) but it just kinda feels like searching for something to complain about. If your browser and OS doesn't get in the way you can get exact measurement. This also applies to almost any UI framework that has some integration with the OS.
>> So, don’t think “how can I do my layout in a given system”, think instead “what possible layouts are allowed by the system”
Spoken like someone that hasn't been handed designs and expected to 'just figure it out' for a living.
So many complaints about web technology, where is the replacement? I'd be interested to know if there was the one true layout system that everyone agrees on
TeX [0] is in some sense "the one true layout system", but it's designed for printed documents, so it doesn't work on the web [1]. And in some ways, it's much simpler than CSS (you can build nearly everything from only a dozen typesetting primitives or so), but in other ways it's much more complex (since TeX is itself a fairly complex programming language). It's typesetting quality is still unbeaten by any of its competitors though, even 50 years after its first release.
[0]: https://en.wikipedia.org/wiki/TeX
[1]: But it does work on WEB :) [2]
[2]: https://en.wikipedia.org/wiki/Web_(programming_system)
My understanding is that it's designed for fixed-size documents? There's a big difference between a layout system for that, and one where size of a document can vary wildly, up to completely opposite aspect ratios
I guess I'd call it mostly fixed: most TeX engines only produce a single page size at a time, but you generally only need to modify a single variable to change the page size and, after recompiling the document should be perfectly reflowed into the new page size. This is not helpful at all for someone who wants to be able to freely rotate their phone, but it's still better than InDesign or Word where changing the page size will probably break the layout.
There is actually a TeX extension that supports viewers arbitrarily changing the page size of documents [0], but it's fairly new, and as far as I'm aware it has essentially zero adoption.
[0]: https://ctan.org/pkg/hitex
I'm not sure if Tex has a way to express mobile/desktop aware layouts, or to enable the reader to adjust only the font size (my ignorance)
Yup, you're correct that TeX can't really handle arbitrary page sizes; see my reply [0] to a sibling comment.
[0]: https://news.ycombinator.com/item?id=48487199
The web is probably the closest thing the software industry has to a truly universal, open application platform. There is corporate influence, but it is substantially more vendor-neutral than any other UI platforms.
The web stuff mostly uses licenses such as MIT, Apache 2.0, and BSD. GPL-licensed projects exist, but still many more on permissive side.
Web is based on open standards developed through organizations and specifications are publicly available, royalty-free, and implemented by multiple independent browser engines rather than being owned by a single corporation.
The complaints shouldn't require a replacement at least in the web's case the replacement is still the web standard, a better, iterated version. It's a living standard and criticism keeps the platform slowly but surely evolving. I think it's a healthy feedback loop.
I remember that there were these talks called "Linux sucks" (IIRC) and the premise wasn't that we should start using Windows but more like "we can do better and improve it." Not every complaint needs to come with a solution or better alternative.
Not which works under the same constraints as the web.
But for simpler scenarios (like fixed-sized paper, desktop displays before super-wide screens), you can have both simpler and more precise layout systems.
apps are the replacement, be careful what you wish for
> There isn’t a fully general solution to positioning and sizing GUI boxes.
flexbox. You can literally recreate any fully responsive desktop style GUI with it. You just need to layout your elements the same way you would in a GUI designer like QtCreator or Glade. Which means thinking in terms of divs with flex-grow set on them to get the automatic container expansion you get with "vertical boxes" or "horizontal boxes". These divs will sometimes be empty if you want a simple "expander" box.
Once you have it down you can look at any desktop GUI and just inherently understand how it maps into this flexbox model.
Yea, back in the day there was this h-box and v-box containers for the Widgets. I still think of my HTML that way, and div-soup to make them (is it soup tho?). Used to be TD soup.
Google released "Modern Web Guidance" a few weeks back that includes a set of agentic skills: https://github.com/GoogleChrome/modern-web-guidance-src. I wonder if that includes some of the suggestions in this article.
regarding `* { box-sizing: border-box; }`, i usually follow the "Probably Slightly Better Best-Practice"
https://css-tricks.com/inheriting-box-sizing-probably-slight...
In 2026, you can avoid the bad parts.
> Let's start with the basics: if you write`font-size: 16px`then `16px` is the size of what? Sadly, the answer is "nothing in particular" -- this is a size of a virtual box around the glyph, but the box isn't tight, and the size of the glyph varies, depending on the font. Luckily, `font-size-adjust` property can fix it, and make `font-size` consistent across fonts.
All modern browsers default to 16px, but for accessibility and sanity reasons, we shouldn't use pixels.
By default, 16px = 1rem. You don't need to declare it; it just is.
Also by default, 16px = 100% if using percentage for font-size.
See "The Ultimate Ideal Bestest Base Font Size That Everyone Is Keeping a Secret, Especially Chet" - https://adrianroselli.com/2024/03/the-ultimate-ideal-bestest...
> Can you just set `font-size: 18px`or whatever works best for your chosen font? I think the answer is yes, but there are some caveats to keep in mind.
If you want to manually increase the base size, using relative units is the answer: `html { font-size: 1.125rem }`. Since by default, 1rem = 16px, 1.125rem is 18px.
> Setting `font-size` in your CSS disables that second approach.
Setting `font-size` in pixels disables changing the browser's default size; works fine with relative sizes.
If the goal is not having to learn the intricacies of CSS, just use the built-in type scale:
By default, medium is 16px which is 1rem.You can write `p { font-size: medium }`.
BTW, the main use case of `font-size-adjust` is for changing the font size of your fallback font incase your primary web font doesn't load or if it takes too long depending on what `font-display` is set to. You want the metrics of the fallback font to match the primary font so the text doesn't shift [1].
[1]: https://www.w3.org/TR/css-fonts-4/#font-size-adjust-prop
> > Let's start with the basics: if you write`font-size: 16px`then `16px` is the size of what? Sadly, the answer is "nothing in particular" -- this is a size of a virtual box around the glyph, but the box isn't tight, and the size of the glyph varies, depending on the font. Luckily, `font-size-adjust` property can fix it, and make `font-size` consistent across fonts.
> All modern browsers default to 16px, but for accessibility and sanity reasons, we shouldn't use pixels.
That's not what that means. font-size specifies the size of the font's em box, but the correlation between the em box and the visual size of the font is not consistent across fonts. font-size-adjust can adjust how a font-face responds to the font-size so that the sizing is consistent with other fonts of that size. For example, capsize is easier to implement that way.
https://seek-oss.github.io/capsize/
(I agree that specifying font size in pixels rather than rem is bad practice.)
Yup, using rem for as many things as possible has always been good to me.
This is bad advice. You should only use rem for text, e.g. font sizes and paragraph margins.
If the user is on a phone and has a larger default font size due to vision difficulties, making padding scale with the font size takes screen real estate away from the larger text the user needs.
Thanks for the tip. That does make sense, although I do think having your default CSS-defined font sizes (across your whole app, not just the main content) be a reasonable size should be the first priority.
Also, not having ridiculously oversized margins, like so many 2019-2022 websites trying to look "modern" used to use.
old.reddit.com is one example where the paddings still look good when magnification is set to 150-170% (which I have to do because of the tiny default font size). I think doing it that way but with better readability at 100% zoom, would be a decent solution.
This is true. I use increased font size on my phone, and so many websites are borderline unusable because of massive unnecessary padding. But I am also a culprit of using rem for everything. What is the alternative? Pixels?
Thanks for helping me realize my accidental anti-pattern. Can you link some of the sites that do that the worst.
I want to use those as references to fix my UI (on increased font-sizes on small screens) before releasing an app I've spent 4+ months on.
Perfect example for you: indeed.com (desktop site). unless its been fixed recently, huge swaths of area are already empty padded space, made worse by zooming
I 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.
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?)
You really don’t have to change your css. My personal website has been using roughly the same css for a decade. Why not?
Sure if you are a designer and want to follow trends, you’ll have to keep your css skills up to date. But for most websites, you can use css from a decade ago.
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, <table> 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.
at least it changes less than js frameworks
We're going on 13 years since React launched publicly
17 years for flexbox
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!
> Use CSS nesting to avoid writing “far reaching” selectors and style component-per-component
I view nesting as a footgun. I recommend trying to restrain all CSS to one selector, and to instead view additional qualifiers as an escape hatch where needed. Death to specificity.
Person who hasn’t spent enough time understanding web design feels entitled to make a CSS mark sheet. Most of the “bad” is really “I haven’t worked with this enough and I will judge it from my limited point of view”. What a waste of time
> An ersatz CSS tutorial for people who need to style a web page, but aren’t web developers. I am a wrong person to write this kind of thing, as I have neither the time, nor experience.
I'd say this disclaimer at the top speaks for itself!
CSS, the only way to win is not to play
I call my self experienced and informed about bleeding edge css. And I disagree every single item including font sizes and border box
Note: The following of course varies from site to site based on how design focused the site needs to be.
I had thought about writing some things about this, but I will put a quick observation here
>restrict yourself to using only markup-meaningful semantic tags, and then figure out CSS which works with the markup you have.
this used to be the best practice advice about 20 years ago. If you've been around long enough in programming, especially in web development, you will see cycles of best practice advice where the thing you were told as the best practice at one time becomes the worst practice later.
For example at one time it was considered "best practice" to put script tags at the head of the document.
Anyway this guy really isn't the person to give you best practice advice, as he notes.
The semantic tags advice is dear to my heart and I wish it were so, but it is wrong, unless the site you are working on is the online representation of a textbook or something highly structured like that, in which case it is spot on.
The reason why it is wrong is that most of the web is a design focused medium, as opposed to a meaning focused medium. In a meaning focused medium the semantics are the most important thing, because semantics are how we convey meaning. That's pretty much tautological there.
In a design focused medium obviously semantics of things are important, but so is arbitrariness. To see that arbitrariness is important, pick up any highly visual magazine that has been applauded for its design aesthetic. Obviously no magazine is completely arbitrary but even more structured ones like The New Yorker need to do somewhat arbitrary things with the layout and design to enforce the rules of taste which guide it.
It is not impossible for a design focused publication that in moving between articles that the look of headlines change (although always recognizably headlines), the necessity of splitting things up with visually arresting details that delight the reader is common place, typography and images are there to delight the visual sense, not to clarify a point being made in the article, as a common rule.
If you were to try to semantically describe all these effects and things with meaningful class names you would end with lots of drivel, essentially, or things that mixed presentation description with semantics like ".ArtDecoHeading" perhaps, and that is because the difference in presentation of many of these things communicate absolutely not semantic value but only that it looks cool or nice or whatever way you want to describe the effect of design on the target of the design.
This relates to lots of CSS frameworks where the names of classes describe not what the element is or means, but rather what the class does, because when design affects are placed in a somewhat semi-arbitrarily manner this is really the most sensible way to describe a lot of classes.
Again, as nothing is completely arbitrary you will find things that are a mix of semantic classes like ".productTitle"
Semantics and Presentation mixed
".bigHeader"
and pure presentation that is trying its best to seem semantic somehow
".sideBoxSlideIn .upDownJumper"
I mean definitely you have to identify what parts of your application have semantic meaning, where the design will not arbitrarily affect them, such as .productTitle, but I believe in most modern web development much of what you will be doing is not semantic styling, but design styling.
And when you are doing design styling you might find you're creating layers and layers of wrapper elements, because making wrappers is often one of the easier ways to solve arbitrary layout problems.
On edit: this was partially prompted by the guy claiming never to have written production CSS and saying he is not really the person to be giving advice here, and I agree because he does not understand the actual needs of web development as a design based medium. Which is why he suggests such previous best practices as don't use classes and stuff like that which just doesn't work because to be able to do arbitrary layout without classes we would need to have millions of element types to play around with and then you have just recreated the problems with classes, only worse.
on edit2: added note at beginning.
My experience working with other peoples code is that they often use too many wrappers. I don't mind using some wrappers, often they're just necessary. But I'll often see components with like 4+ nested divs where half of them or more can just be removed with no visual change. Not to mention spans, some people just use spans for everything, it's all divs and spans.
Personally I like to try to use semantic HTML where possible, as it helps with a11y and is nicer to read and work with. But I don't mind using some container/wrapper divs to make things look right.
It's also worth noting that semantic markup is not a feature of CSS, it is a feature of HTML. CSS has almost no power if something like a scraper or a reader mode chooses to ignore it. Of course that would be pandemonium and we would never get good results.
I feel like something in the CSS camp that could be highlighted in a "great idea, okay implementation, poor reception" that the OP is going for is print stylesheets. Those are incredibly underused.
LOL @ "I've never written production CSS" followed shortly by "don't use CSS selectors"
Yeah, infuriating that this shit gets so upvoted here
Bad: responsive design
Uhmmm, ok
Poor choice of words there; it would have been better as “Bad: responsive breakpoints”.
My experience with responsive breakpoints is that they require compromises and therefore it's hard to make a manager commit to them: everything must look perfect, and identical, on every different device that exists, and if it doesn't it's the designer's fault.