Rebuilding a featured news section with modern CSS: Vox news | Hacker News Reader

Rebuilding a featured news section with modern CSS: Vox news

ishadeed.com

187 pointsshadeed84 comments

TIL about CSS Container Queries https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Contain...

That technique of using a style tag to set a CSS var (--horizontal) then using @container tags to shift the UI is really cool.

    <div class="c-newspaper__item" style="--horizontal: true;">
        <article class="c-card"></article>
    </div>

    .c-newspaper__item {
        container-type: inline-size;
        container-name: card;
    }

    @container card (min-width: 300px) and style(--horizontal: true) {
        .c-card {
            display: flex;
            gap: 1rem;
        }
    }

Also, as someone who learned CSS in the early 2000s, seeing grid layouts with `grid-template-columns:` etc make life so much easier. Web devs have it easier these days.

Note that while container queries are available in modern browsers' most recent versions, it is still very fresh, with broad support landing in September, and Firefox support just last month: https://caniuse.com/css-container-queries

If you use them, you'll need to show outdated browser warnings for basically all browsers older than September 2022. Your site will be horrifically broken without container query support.

I'm investigating if we want to even do that at my job. That's a pretty steep cost.

You should consider using a polyfill

Polyfills can be quite expensive on a client device depending on their complexity, so they’re not some kind of free lunch.

Expensive in a few ways. Deferring styles to execution time means users on slow networks or devices will have an absolutely brutal load experience.

This might all be an acceptable trade off depending on one's user base, of course!

I don’t think there is a generally accepted implemented one.

They’d also be pretty expensive on the client

I especially liked the fact that you can use the size of the container element to calculate the size of the children. This is super useful when you want to make sure your text takes the full width of the container regardless of the screen. No need for breakpoints!

    <head>
    ...
      <style>
        .example {
          container-type: inline-size;
        }
    
        @container (min-width: 200px) {
          h1 {
            font-size: 15cqw;
            font-family: monospace;
          }
        }
      </style>
    </head>

    <body>
      <div class="example">
        <h1>hello world</h1>
      </div>
    </body>

the last line makes me laugh.. while it's true grid layouts make things so much easier then back in the 2000s, web dev today is still just as hard, but for different reasons.

That reminds me one of the rules of cycling: "it never gets easier, you just go faster"

Web dev is way easier now, if all you're trying to do is the same stuff we tried to do in the early 2000s. All the stuff that makes it harder is because we can do some much more now.

> web dev today is still just as hard, but for different reasons

As someone who did webdev back in the 2000s and still does it now, I do not agree with this at all. Webdev is easy now. Especially with the development of simpler build systems (esbuild, vite, etc) in the couple of years.

Or maybe you have just gotten better after doing it for 20+ years? I can't imagine anything being easier than plain HTML and CSS

> I can't imagine anything being easier than plain HTML and CSS

Well you can still make websites with plain HTML and CSS today, and the layout modes (and other niceties like border-radius) that are available today so are much nicer than the ones that were available 20 years AND they work the same in every browser!

20 years ago you were cobbling together layout with tables and floats (you didn't even have `display: inline-block`). And people still wanted vaguely responsive layouts even though there weren't any media queries yet. Plus there were 3-4 major browser engines that you needed to test with, and there were often major differences in both feature support, bugs and layout between them. For example you had to deal with the fact that IE used what is now known as `box-sizing: border-box` while other browsers used `box-sizing: content-box`, and the fact that browsers didn't even parse HTML consistently you could easily end up with different node tree in different browsers.

>they work the same in every browser!

That's because there's only one (alright, two) browsers.

There are 3. Safari is distinct from Chrome these days (even though they are derived from a common base). The fact that you consider them the same is evidence of what I'm saying: that differences in rendering between browsers tend to be minimal these days :)

Plain HTML and CSS are tedious.

Combine that with the fact that loops and objects don’t have fantastic support, if any, and it’s no wonder everyone and their mother has tried their hand at a templating framework. (WebComponents exist, but fall into a lot of the same traps; I didn’t like what I saw in the MDN tutorial.)

If you're using a JS build system then your webdev sucks already

Web dev has gotten more complex with more complex requirements, but not linearly - its easier to build more complicated products on the web, and as this article shows the primitives we have are much more powerful.

If you want to build something you build back in the 2000s, its so much easier than it was back then.

I'll take anything over the days of float: left;

float: left is still useful, of course, just for what it was intended rather than what it was abused for.

float: left taught me to never skimp on understanding the things you're using to try do the things your doing!

Not having to use ridiculous hacks and workarounds to make website look pixel perfect on Internet Explorer 6 or 10 browsers makes web development easier. RIP IE, we'll hardly miss you.

Why do this instead of

    <div class="c-newspaper__item display-flex gap-1rem">
        <article class="c-card"></article>
    </div>

    .display-flex {
      display: flex;
    }
    
    .gap-1rem {
      gap: 1rem;
    }

You can use CSS classes like booleans but sometimes its nice to have actual boolean variables, used on the actual HTML element in your component, when designing the logic of your application. Even if it's more verbose.

> That technique of using a style tag to set a CSS var (--horizontal) then using @container tags to shift the UI is really cool

That sounds like using a feature for the sake of using a feature. Couldn't the same be done with a class on the container?

Reading that blog, I see lots of arbitrary widths everywhere.

Whilst it works, and the presented code is certainly clean enough, it could be argued that such techniques are not really true modern CSS, something flex based would likely be the true modern way.

See, for example, the approach taken by Every Layout: https://every-layout.dev/layouts/sidebar/

Even outside of the web arbitrary absolute dimensions are rarely the correct way to do things. It means that your content/app/etc is rendering badly on some set of screens/form factors and usually breaks accessibility affordances like increased font sizes/weights and font substitution.

Meh. "Add a new breakpoint when things look bad" has worked pretty well for the web for a long time.

Also, all browsers these days just do a fancy page zoom instead of directly manipulating font size. It's a much better setup than what we had to do in days of yore, e.g. using different units on different properties so that things didn't fall apart on size increase.

> Also, all browsers these days just do a fancy page zoom instead of directly manipulating font size.

This is very not true. Hit Alt V Z T in Firefox, for example. It's even on WebAIM's accessibility checklist (https://webaim.org/resources/evalquickref/#scaling), which makes it important: that list is very selective.

Microsoft Edge on Windows 10 has at least three different kinds of zoom, depending on which input device you use to trigger it. (Multiple types of zoom: good. None of the keyboard / mouse / touchpad bindings doing the same? Bad.)

Uh, sure. Sort of a pedantic side note, but yes: all browsers' default to a fancy page zoom these days. It's even more buried in Chrome.

For good reason: using rems or ems in sizing values will cause "text only" zoom to do a good bit more than what's on the tin. WebAIM doesn't require it, and only recommends – which is more than I would say, at any rate. It's simply more trouble than it's worth.

It's not bad. But in older browsers that don't support those new CSS features it always defaults to the single column "small" version even with a large browser window. That's not optimal. The current www.vox.com site displays perfectly fine in older browsers.

Sometimes change for the sake of using the latest bleeding edge thing isn't really worth it.

Hello there! The author of the article is here.

The main goal of this is to explore the potential of modern CSS in building such a layout. I agree that some of the features aren't supported yet, but that will become better over time. The article shed light on things like container queries, fluid sizing.. etc.

I think it would have been worthwhile mentioning browser support in quite a few places:

• Container queries have less than a year’s support in any browser;

• Style container queries have only an incomplete implementation in Chromium for a month;

• :has() isn’t in Firefox yet and has been in other browsers for a year at most.

That is: you can’t actually depend on these features yet.

Just want to say thank you. Great article and really enjoyed your other about flexbox vs. grid.

https://gs.statcounter.com/browser-market-share Unless you're targeting some really niche market people will have a relatively up2date browser. It's not a problem to use recent features once they've been implemented by Chrome and Safari.

There's a lot of selection bias in collecting statistics with a package that'll only execute properly in the latest browsers and those running JS (as opposed to looking at webserver logs directly). I'll grant that vox probably only cares about serving content to people that can also see it's ads so it's a legitimate cut corner in this context. Their demographic is accessible eyes on ads and wallets, not people.

If you want to serve content to human people and not just to eyes or wallets then at least be aware that most modern browser share statistics collected with JS don't reflect the reality you'd see in your webserver logs.

I'd be very shocked if the percentage of all human users that have JS disabled is more than <0.1%. Even web crawlers and other bots can (and do) execute JS these days.

I don't think the demographic is realistically relevant.

Some crawlers execute JS, but last I heard or checked even Bing’s crawler seldom did, and Google’s clearly tried to avoid doing so.

Of humans that deliberately disable JS, certainly going to be under 0.1%. (I’m one of them, incidentally, because on average it makes the web much better, lighter and faster.)

Of humans where various JS doesn’t run, due to having an older browser, a corporate proxy that blocks some things, a content blocker like uBlock Origin that incidentally blats your script, unreliable network conditions, and more things… well, that number is regularly quite a lot higher than 0.1%, often above 1%.

As for something like the Statcounter tracker, which these specific stats are built from, their methodology is obviously stupidly broken and has been for many years: ad blockers will tend to block it. (uBlock Origin does by default, and I expect others to as well.) And that number is generally agreed to be well above 10% (some say as high as 40%, though I’m sceptical of that), and heavily overrepresents users of less common browsers like Firefox.

I'd add Firefox to that list; specifically, you shouldn't be using :has until Firefox implements it, and afaik it's not implemented in Firefox because it's still a Working Draft and not finalized. Chrome and Safari implemented it early, and without any vendor prefix, but the implementation details are still subject to change. (Someone correct me if I'm wrong.)

>you shouldn't be using :has until Firefox implements it,

97.23% of internet users do not care.

If you are arguing to not use Working Draft mechanisms in production environments (and you probably are), yes you have a point. Better safe than sorry, it's called a Working Draft for a reason.

But if you are arguing to not use something because Firefox (and only Firefox) does not support it, you are going to have a fun time trying to convince most webdevs to care about just 2.77% of all internet users.

The fact that most browsers aggressively push or even force updates should not be used as a justification for this.

You're essentially saying "I want to use this months old API, and fuck you if you still have a browser from last year." People used to respect some amount of backward compatibility.

Browsers used to not auto-update.

There's no reason to "respect" backwards compatibility in an inherently online product that auto-updates.

There's nothing ideological here, it's just about being practical.

Fwiw, Safari doesn't auto-update beyond a certain point if you are not running the latest OS version from Apple, which may be for several good reasons, but your hardware being unable to run it is surely the top reason.

And neither Firefox nor Chrome self-updated beyond a certain point on my few years old Android tablet, which is still generally very usable for browsing and YouTube.

And the browser on one of my phones stopped updating, once the OS stopped getting upgrades, for about 2 years before I stopped using that phone (because there was nothing as good as it to upgrade to).

Non-latest browsers are a small percentage of users, but it's a myth some site designers believe that all Chrome, Firefox and Safari installs auto-update to latest versions except where the user decided for themselves to block updates.

To the owner of devices in generally great shape, that work fine with alnost all sites, sites designed with the bleeding-edge assunption can feel a bit "unnecessarily buy a new version of the exact same electronics with your copious spare cash and litter some e-waste landfill to view our content today!".

Site designer's choice of course.

But it's a myth that the current mainstrean browsers stay up to date by default for everyone who doesn't disable it. Some users can't update. This should particularly be in the awareness of designers wanting sites to be readable by people without much disposable income, or some accessibility issues.

not sure about Chrome, but you can turn off update on Firefox. I do this, and for good reason. I dont like the constant churn of browser UI moving around and changing every few months.

So users in that situation should not be punished by web devs who only support the bleeding edge browser versions.

Then that's on you.

When 90% of users are on the newest version within a couple weeks, that's not "bleeding edge". It's mainstream.

You're also opening yourself up to security vulnerabilities as you browse.

If you turn off auto update, it's up to you to accept the consequences of both security risks and of sites breaking.

> Then that's on you.

you say that like I am the only person who does this.

> When 90% of users are on the newest version within a couple weeks, that's not "bleeding edge".

[citation needed]

> you say that like I am the only person who does this.

Essentially, yes: https://caniuse.com/usage-table

caniuse uses statscounter. It's really no surprise that statistics collected via javascript fail to include browsers that aren't executing it or don't have the modern JS "features" it uses. https://en.wikipedia.org/wiki/Streetlight_effect

2.7% of ALL browser usage is still a significant number, and certainly more than one person.

Web devs should not punish such users, agreed. Who will pay extra on top of the hourly rate to address the needs you have? Especially when it's your problem with somebody else's software (Firefox) that would require this extra investment.

its not a problem with the software, its a problem with the web site adding features that only work with the newest browser, without any fallback for older browsers.

In times past I would have fervently agreed with you.

But in this day and age of browsers being Chrome and Chrome and Chrome and Chrome and Safari, all with forced autoupdates, there's little practical weight behind "browser <X> doesn't support it!". If Chrome supports it, the internet supports it whether any of us like it or not.

> But in older browsers that don't support ...

I think, regrettably, that 2023 might be roughly the time where the "old browser" support consideration is finally put to bed.

For example, you no doubt have to perform all sorts of code contortions to make things work in old Internet Exploder. It means you have to use old coding methods compared to things that are quicker and easier to implement and get working cross-browser & cross-platform in modern CSS. It also means you are writing more LOC, which means more scope for weird little bugs and time-consuming troubleshooting.

Secondly (and perhaps more importantly), making things work in old browsers means you are removing further incentive for people to upgrade. Given the increasing prevalence of browser-based attacks where people can be pwned simply by visiting a website that contains "specially crafted code", I think the quicker everyone gets onto modern browsers the better...

I work a niche B2B product and we basically made this a requirement.

Unsurprisingly we’ve had 0 issues asking our customers to use recent versions of Chrome/Edge/Firefox/Safari. Obviously not using super new APIs like @container before they are fully read on these 4 but still that’s still basically every modern feature.

At my last company we were selling into the NHS which was traditionally very conservative with browsers (they were one of the last users of IE6). But even they're on Chrome these days.

If you're using older browsers you should be accustomed to a sub optimal experience.

Yeah I always think it's strange that because you have made the deliberate choice to not upgrade your browser in years, ignore all of the "feature not supported on your browser" messages, ignoring security updates, etc. that I should be focusing on your experience, instead for the 98% of people who do do those things.

Isn't it a deliberate choice to have that experience?

Unless you're in an industry that requires not upgrading, backward compatibility is great, up until a point.

In my case the text to speech software I use to interact with my computer doesn't exist in the same form in modern operating systems. The modern installable version and voices are much worse. So I stick to an old OS that supports my text to speech.

But this means my glibc is also an old version. And this OS was released before docker existed in repos (and has no docker support). So I'm using an older brower with JS completely disabled. It displays HTML, text, images, etc pretty well. It's just the for-profit sites that used to cause problems. But now everyone is cargo culting the for-profit stacks, devs are expecting updates to browsers every 2 weeks, and it's getting harder for me.

So yeah, I expect it to be hard. But also, people have legitimate reasons for using old software.

Totally fair. Thanks for educating me on a proper use case.

if you’re using an older browser there’s a good chance you’re vulnerable to a bunch of security holes too, unfortunately we’re past the days of only updating every 2 years

Are users of old browsers likely to be using high resolution displays?

False. I do professional front end development and haven't browser tested with any rigor in over a year. Who cares about Opera. Seriously.

Totally agree. As long as it works in current Chrome, that's all that matters.

https://wikipedia.org/wiki/Poe's_law

Your sarcasm isn't hitting the way you think it is. I've spent enough time doing my job and enough time on CanIUse to know that the era of worrying about browser compatibility is behind us. I dismiss Opera because it's only at 1% use. There has never been an expectation at any point in my 15 years doing that that I should browser test for browsers at !% use. And realistically, the properties that aren't currently browser compatible are one's that I never use and have little need for. Some are cool and will be compatible before long. But I can't really remember the last time I looked up a property I wanted to use and found it would be problematic for anything other than Opera. Granted, my attitude might be different if I was building sites for an international audience.

> I've spent enough time doing my job and enough time on CanIUse to know that the era of worrying about browser compatibility is behind us.

Its not. Its just that many developers have stopped caring about it. Google is releasing new APIs at a ridiculous pace, many of which are not needed for a huge chunk of websites. if developers want, they can avoid using newer APIs, or use them but add fallbacks for older browsers.

> for anything other than Opera.

sure, if you look at the current version of major browsers, support is pretty good for everything. but some users are locked to an old version, either out of personal preference, or work mandates. so its helpful if web developers dont use assume everyone is one the latest browser version. they dont need to support every version of every browser, but I think its reasonable to expect a two year old browser to work with most current websites, and more and more that is not the case.

Google is releasing new APIs at a ridiculous pace, many of which are not needed for a huge chunk of websites.

Worse is that Google demonstrably has no qualms about leaving beta-quality implementations of new APIs in place for months or even years or about forcibly retiring APIs it decides shouldn't be there any more. It has done both of those things many times including with widely used functionality. Don't like it? Sorry guys but you should have been on the pre-alpha-might-release-it-one-day channel so you had a few weeks of notice to rewrite your entire style sheet.

Following one dominant browser at the expense of open standards is exactly how we got years of stagnation with IE6. Those of us who remember that period have no desire to see another like it. But those who do not learn from history...

thanks for sharing the experience and thoughts behind it.

I just went thru a similar page redesign and your layout experience resonate with mine. totally agree flex is probably the most overkilling choice here.

I end up not go with grid but old pal float in 3 col view, mainly bc my use case is not typical [L, M, R] -> [L, M/R] -> [L/M/R] layout pattern, but more complex [L1/L2, M, R1/R2] -> [L1/R1/L2/M/R2], and the variable height of each part make the height attribute very difficult to manage in 3 col view.

So much respect for css devs. That stuff makes my head spin

CSS must be fun to use nowadays, with tons of flexibility and great browser support. I remember the days when you couldn't even rely on CSS2 because IE6 didn't support it, apart from having serious rendering bugs.

Once CSS gets nesting [1] natively (ie, not having to use SCSS or Postcss) the total sum of improvements it will be 100x less annoying vs the early 2000s. Variables, grids, flex, container/media queries, math functions, clamp [2] etc make life so much easier.

The last thing is mixins/functions, but not sure if there's an RFC for that.

[1] https://www.w3.org/TR/css-nesting-1/

[2] https://developer.mozilla.org/en-US/docs/Web/CSS/clamp

CSS needs baseline rhythm for typography. I hope it happens in the next decade

CSS had always been fun. It’s always a puzzle, trying to take advantage of the way all the rules contribute to the final layout. I think people get frustrated with it because they don’t want to mess with it, they just want it to work - that’s where a lot of those css layout frameworks come from, that’s where BEM comes from - people just don’t want to mess with it. But for me, I’ve always thought messing with it was the fun part.

Yeah, I like CSS. And I appreciate it much more since I have to use LaTeX for documents.

I've been a web designer since 1993. It was nice in 1993 because you didn't even have a background color. The color of your page was the default color of the window on your OS. Usually grey.

Then we went through 25 years of dark ages where there were plenty of really great ideas for layout which were completely lost to horrible and competing and half-assed executions.

We are now finally in the golden age of layout where I can make something that looks great on all displays if I have the time and talent to do it. Sadly that is in short supply.

I think we have Chrome to thank for modern web design. Once the browser competition was completely and utterly crushed and everyone was forced to sign on to The One True Layout Engine the benevolent dictators at Google set things on the right path.

There are still edges cases (which JPEG replacement will win?!), but they are now blessedly few and far between.

> I think we have Chrome to thank for modern web design.

I think it's less the dominance of Chrome itself and more the demise of Internet Explorer. The problem was that it didn't get updated like normal software, it was somehow tied to the OS, so old outdated versions lingered around for far too long, limiting what technologies web developers could use.

> There are still edges cases (which JPEG replacement will win?!), but they are now blessedly few and far between.

Last I heard was that the Benevolent Dictators at Google decided that AVIF shall win.

>The problem was that it didn't get updated like normal software, it was somehow tied to the OS, so old outdated versions lingered around for far too long, limiting what technologies web developers could use.

Now that mantle is taken up by Safari, especially on mobile.

Oh really, does Apple repeat that mistake? I assumed Safari would get updates like a normal app.

They're a bit more separated on macOS but still not really separate. On iOS, it's very much tied to the iOS/iPad OS version.

There's perfectly functional iPads out there that are stuck on an iOS version and are thus e-waste as more and more Internet becomes inaccessible to them.

Okay, Microsoft made a mistake with their IE policy, maybe put of ignorance, but Apple repeating that mistake with Safari has no excuse.

It's AWESOME!!! IE died! Bloated frameworks have become irrelevant! No more modernizers. You can just use it the way it's supposed to be used.

And let me take the opportunity to diss the failure that is mixing your styles into your layout with Tailwind and it's endless and illegible bloat of unreadable html.

And let me take the opportunity to diss the failure that is mixing your styles into your layout with Tailwind and it's endless and illegible bloat of unreadable html.

Reading the bloated HTML is less painful than dealing with all the cascading crap.

Lol. I certainly know many people feel that way, otherwise Tailwind wouldn't exist. But I'm a strict adherent to the concept that you keep your languages separate. You should not have to wonder whether you need to go to your html or css file to change the appearance of a site.

> You should not have to wonder whether you need to go to your html or css file to change the appearance of a site.

Not to beat a dead horse, but:

Separation of concerns != separation of languages

If you want to change a button, ideally you go to your one BUTTON FILE.

Same applies doubly so when using Tailwind. You should not be looking around CSS files

I'm not by any measure a CSS expert, but whatever became of the idea of semantic HTML (or even XML files styled with CSS https://www.w3.org/TR/CSS21/intro.html#xml-tutorial)? I've been noticing that there is little difference between the sizes of HTML payloads and JSON payloads when extraneous tag hierarchies are eliminated. I've half a mind to replace some of my React SPAs with old fashioned server side templating (not SSR). Event without using techniques like HTMX to replace partials, things seem to run faster and backend development becomes so much easier.

I guess they should focus a little on typography too.

Extra strong bold headline with super thin text for the body.

Reply on news.ycombinator.com