10 ms·

Old dogs, new CSS tricks

175 points by mxbck 2y ago

nolongerthere 2y ago
This article is interesting but when we’re talking about design elements I think it’s always a good idea to include some actual demos or examples showing the final result and not just the “code”. I might also not be the target audience but I still don’t understand what container queries are or what old paradigm they’re replacing. The author does a good job explaining the difference between border-radius and the old way of using photoshop, but fails to do that for the features that he’s trying to promote.
- ervine 2y ago
  Old paradigm (media queries): You make layout changes based on the width / height of the viewport (browser). New paradigm (container queries): You make layout changes based on the width / height of the containing element. This lets you layout a component so that it looks good in any sized container. Picture a component that might be in the main section or in the sidebar - you can now just style directly based on width of the container instead of having to know the total width of sidebar + main section and do the calculation using viewport width.
  - kevindamm 2y ago
    Agreed, but to add to this: media queries are still useful, and since a media query may hide/remove entire containers in the view then the remaining containers may have widths that are no longer a simple proportion of the viewport width (or other property being selected for). So container queries can also enhance styles with media queries, not just replace them.
AltruisticGapHN 2y ago
CSS is becoming too complex. The syntax looks like it wants to be output by some compiler instead of being crafted by hand. Personally I also don't have any pleasure anymore writing CSS these days. Sass and BEM methodology works fantastically well. Naming things isn't that hard, but Tailwind/utility approach is also extremely useful. Those new features, besides container queries is just gibberish. Layer? WTF? The cascade is bad enough as it is, most devs can't even deal with the cascade it's why Tailwind become so popular. And we should dive even deeper into the cascade BS with layers and scoping and whatnpt? Again, this all looks like it was made to be output by some CSS compilers, not written by a developer.
- notRobot 2y ago
  You don't have to use the new fancy features, you can keep doing things the old way.
  - pipeline_peak 2y ago
    I think he means other people will though.
- willio58 2y ago
  I’m unsure if you have specific feedback or just a general misunderstanding of the point of additions like layer to the spec. At the end of the day these are all more tools in our toolbelt. If you want you can keep writing CSS the same way you always have.
  - paulryanrogers 2y ago
    There is a concern that one can have too many tools to do the same -- or very similar -- things. This can reduce readability. Consider Perl's many ways approach to Python's (initial) goal of one way.
    - orhmeh09 2y ago
      Every new release of Python 3.x further erodes this idea. I like using the new features because I find Python generally inexpressive and verbose, but I have a hard time explaining to nondevelopers who read the code about the assignment expression, keyword only arguments, structural pattern matching, typing improvements and deprecations and so on.
  - culi 2y ago
    > At the end of the day these are all more tools in our toolbelt. If you want you can keep writing CSS the same way you always have. I don't really stand by GP's comment but I also don't think their concern can be dismissed this easily. We generally write CSS as teams. You'll have to read as much CSS as you'll have to write. Ideally you actually read more than you write so you can reuse existing rules and follow established patterns Anyone writing CSS for a day-job, an OS project, or even just following a tutorial will have to at least familiarize themselves with these concepts
kerkeslager 2y ago
> Quick question: how many of these have you actively used in production? > Container Queries I haven't used this, but it looks super useful. > Style Queries Eh, I'm sure this is useful for situations that don't come up very often. > CSS Layers Ugh, I'm not going to use this overly-complex silliness, and I'm not looking forward to debugging this when other people use this. > Subgrid Again, overly complex. Grid could already do everything this can do, more simply. > Native Selector Nesting I'm already using this. > Anchor Positioning Eh, I already had solutions to this problem, but this seems like it probably communicates intent a bit better. I guess I'll pick that up. > :has, :is, :where :has is useful :is... okay, fine, syntactic sugar. :where I don't believe in hell. If I did, I'd be against it because burning someone for eternity is inhumane. But I might be willing to make an exception for people who write CSS that requires you to read the MDN article on Specificity to understand it. > Logical Properties Perhaps useful for situations that don't come up very often. Seems complex, but that might be because the thing it's representing is inherently complex. > Scroll-Linked Animations Okay, someone who isn't me will probably do really cool things with this. > View Transitions Another thing that seems complex, but possibly because the thing it's representing is inherently complex.
- bobthepanda 2y ago
  i actually came up with a thing where subgrid would be useful, since subgrid lets you denote that a child wants to use the same grid as the parent. if you wanted to use grid template areas, and you had something that looked like <div id="my parent grid"> <h1>Title</h1> <ul> <li /> <li /> </ul> </div> There isn't a great way to make the <li> adhere to the grid template areas, because without subgrids only direct children (the ul) have coordinate attributes.
  - noduerme 2y ago
    I haven't needed to do CSS grids for awhile, but couldn't this have already been done with `display:contents` ?
    - bobthepanda 2y ago
rafark 2y ago
> I can’t use [feature X], I need to support [old browser]. And that’s not necessarily a bad thing. As I commented a few days ago, nowadays devs don’t seem to care too much about backwards compatibility. I like to hold onto my devices longer than most people and it’s a bit frustrating to see that most sites nowadays expect you to be in the latest and greatest. It didn’t use to be like this.
- parhamn 2y ago
  I'm a bit torn on this when it comes to browsers. We recently had a user email us that our app stopped working for them. After we dug into it it was because their Chromebook was last updated in 2021 and didn't have Object.hasOwn (which a third-party library uses) and it's not even included in most common polyfills either. We fixed it, because I hate these sorts of compatibility issues. Nevertheless, I left a bit concerned that they hadn't updated their Chrome in 3 years. Software decays much quicker than hardware in a real way, especially with the never ending list of security vulnerabilities found every year. Theres definitely a case to be made that forcing software upgrades is good for the end user too.
  - nemomarx 2y ago
    I think you can expect that for a Chromebook, but a different type of laptop might not support modern Chrome? I remember that Steam uses enough chromium nowadays that they had to drop support for Windows 7 early. Chrome doesn't have quite as long a support window for older OSes as the OSes do for security updates.
    - Guidii 2y ago
      Is that true? Windows 7 OS updates ended in 2020, while Chrome continued to update until M109 in 2023[1]. [1] https://support.google.com/chrome/thread/185534985/sunsetting-support-for-windows-7-8-8-1-and-windows-server-2012-and-2012-r2-in-early-2023?hl=en#:~:text=Chrome%20109%20is%20the%20last,requires%20Windows%2010%20or%20later https://support.google.com/chrome/thread/185534985/sunsettin....
  - 2y ago
spartanatreyu 2y ago
> Quick question: how many of these have you actively used in production? > Container Queries They aren't useful yet because: 1. Using them requires a wrapper element which can dirty up the HTML 2. While we were waiting for container queries to arrive, we also got new rules that made fluid layouts easier to implement which handle a chunk of container queries use cases. Container queries will become more useful when elements can query their own size, rather than their size inside a designated parent. > Style Queries A solution in search of a problem. Current selectors are acceptable for most current use cases. May be useful for customizable widget/dashboard style layouts. > CSS Layers Nice, but they currently place too many demands on the developer to understand what layers currently exist. These will become more useful as browser dev tools make debugging them easier to reduce the burden on the developer to keep the layers in their mind while coding/debugging. > Subgrid Very useful when you need things aligned, especially in things like card layouts. The only thing holding this back is developers who are too reliant on 3rd party framework/libraries, e.g. bootstrap developers relying on grid column classes and tailwind developers building things with margin/padding everywhere. This will take time for developers to shift to, but those developer who limit themselves inside their own framework/library bubbles may never use them. > Native Selector Nesting Very nice quality-of-life improvement. > Anchor Positioning Only supported by one browser. I have no idea why this was even in the article to begin with. But it will completely remove the need for some JS placement/layout logic that keeps getting reimplemented all the time with pop-ups (pave the desire paths and all that). It also has the potential to make margin notes easier. > :has, :is, :where :has is super powerful as a parent selector :where is great for simplifying repetitive css > Logical Properties If you maintain the discipline required to use these aliases over {top/left/down/right}, or if you have a linter to remind you, all of a sudden you're now able to support RTL languages without needing to spend time and money to make a different site for them. > Scroll-Linked Animations > View Transitions Both will be abused by marketers and "designers" who don't understand accessibility, but both will also greatly simplify micro-interactions on proper websites that aren't trying to be a "marketing experience".
- o11c 2y ago
  :has isn't available in Firefox ESR (115) yet. The next ESR (128) will trickle out between July and October. @property (not mentioned) is only in Firefox Nightly; hopefully it makes it for 128 ...
npn 2y ago
This is a bad article. > And while support for Container Queries is green in all modern browsers, people still seem reluctant to go all-in, fearing they could break something as fundamental as site layout in older browsers. Don't you know there are still a fuck ton of people that are still using the old iOS versions with their old phones? I have plenty of them, and they are long term supporters that I just can't shut them off. There are new css features that are almost harmless and do not affect the usability, some css features on the other hand...
- thoughtpalette 2y ago
  Bit subjective. I thought it was a great article. Lot's of new properties I've never heard of.
  - npn 2y ago
    It is not hard to keep track of new css/js features, as the articles pop up very often, e.g: https://developer.chrome.com/blog/whats-new-css-ui-2023 https://developer.chrome.com/blog/whats-new-css-ui-2023 Most of us just decide to ignore them, because a significant portion of our userbase stills stuck with old devices. People who agree with this article probably never get accessed to any website statistic dashboard.
    - thoughtpalette 2y ago
      For sure, I understand usage statistics and device targets, etc for your audiences. I don't think it diminishes the informative nature of the article. You can be still be excited about new features even if you can't use them for your particular product/audience/etc.
baggy_trough 2y ago
If you want to use nesting, for example, you will have to give up Windows < 10 and iOS < 17.2. It's a big ask for some sites.
- eviks 2y ago
  why wouldn't this work? > You’d need a separate stylesheet to support everyone.
  - yurishimo 2y ago
    In theory it can, but when you work with 20 other devs all working on the same codebase, tracking those changes can become burdensome. Are we going to add an entirely new testing suite and workflow tools to save 5 lines of legacy CSS in favor of the new version? Probably not in a lot of teams. You also need to write and maintain code to conditionally load that fallback stylesheet and hope your users aren't using some weird user agent hacks (looking at you instagram in-app browser). All of these problems can be solved, but obviously nobody wants to because the juice is not worth the squeeze. This is not our first rodeo. I'm gonna wait another 18-24 months and then start using most of the features released this year. It's fine.
- JimDabell 2y ago
  You don’t. Safari has supported CSS nesting since v16.5. The specification was updated to remove the earlier requirement to use & though, and support for that was introduced in v17.2. As long as you include the &, you can support everything back to v16.5. Not sure what you are referring to regarding Windows < 10, but Windows 10 was released nine years ago. Only a tiny fraction of web developers need to support decade-old clients. If you do need to support browsers that don’t understand CSS nesting, use PostCSS or Lightning CSS. They will transcode your nested CSS to older syntax browsers support. Then, when you drop support and remove those browsers from your browserslist, they will stop transcoding it and the CSS you deploy will get smaller. But you’ll have been writing standard nested CSS all along.
  - baggy_trough 2y ago
InMice 2y ago
Whats the eloquent javascript or think python equivalent for css? is it mdn docs or another? Does anyone know the best active, comprehensive online references? How else do you really keep up on all the crazy new stuff
- emmanueloga_ 2y ago
  The state of CSS surveys [1]. -- 1: https://stateofcss.com/en-US https://stateofcss.com/en-US
- sphars 2y ago
  It may be ran by Google, but https://web.dev/ https://web.dev/ is one good source for keeping up with new web technologies
- chrisweekly 2y ago
  Great Q! Pretty much everyone in the field knows about MDN (https://developer.mozilla.org/en-US/ https://developer.mozilla.org/en-US/ ) and https://web.dev https://web.dev and https://caniuse.com https://caniuse.com but the Interop project is newer and maybe flying under the radar: https://webkit.org/blog/14955/the-web-just-gets-better-with-interop/ https://webkit.org/blog/14955/the-web-just-gets-better-with-... Enjoy!
bruce511 2y ago
>> But take container queries, for example. They were the number one feature requested by front-end devs for a looong time. So why don’t we use them more, now that they’re finally here? A number of things are in play here. 1) when people ask for something it's because they need it now. The client wants it to look like x. Providing it a year later doesn't mean I'll retro-fit it, I'm working for another client now. 2) the new features on offer are (mostly) not low-hanging fruit. 20 years ago we were asking for the basics - not-table layout (flex, grid), variables (var --), conditionals (@media) and so on. The low hanging fruit stuff. Now "most people" aren't really asking for anything. (The sliver of a minority attending css conferences naturally are dreaming up new edge cases.) 3) most of the websites that exist (aka have been styled) are older than these features. Since redesigns are typically multiple years apart it takes years for them to filter in. As a proportion the number of sites built, or updated, in the last year is small. And the proportion of those needing these features is smaller. 4) most sites are not styled from an empty notepad. Most use (reuse) a framework - either personal or public. CSS is starting to move from mid-stage to late-stage development. We're well passed the "terrible to work with" stage, well passed the "good enough" stage, and now into the "what can we dream up stage". That said I can see myself using some of these things - sub-grid and :has being the obvious ones for me.
- atoav 2y ago
  Yeah, I still remember a site where I really would have needed the :has selector, but I have written a workaround in JS and now I would rather so the whole thing new than fix that tiny aspect. I will however definitely rely on the has: selector next time I encounter that situation (it had to do with markdown output putting img tags inside paragraphs, so I needed css that treats a paragraph that has a img inside differently than other paragraphs).
  - noduerme 2y ago
    Does :has function as a parent selector? That's probably the only thing I ever really wanted from CSS and I assumed it would never happen because of the (back propagating) implications for the order the DOM is rendered in.
skolind 2y ago
Great article! CSS doesn’t get enough attention - not outside of Tailwind, which I don’t think is the way to go, but that’s another story. :has() and :is() are awesome. One issue I’ve had with any of the newer CSS features is that, most of the people I work with don’t know what they do, because nobody use them. So, I have to explain myself in each pull request - but I guess that’s ok, because then people learn.
- michaelnny 2y ago
  Agreed, I still prefer to write my own CSS than using tools like Tailwind.
  - swagasaurus-rex 2y ago
    For specific components, I use explicit CSS, but for layout <divs> I use the tailwind shorthand (flex, flex-row, mb-7) and just add those to my CSS as I go so I don't need tailwind as a dependency. It's the best of both worlds.
sir_pepe 2y ago
The real problem in my experience is that people who consider themselves to be "real" developers don't care about CSS. I do a ton of code reviews and consulting for companies of all sizes and their JavaScript and TypeScript is almost always at least in a borderline defensible state? But CSS is always one giant file that has been growing since 2002 and is treated as an append-only log of !important. Nobody even tries to fix their CSS because nobody can imagine the concept of "well written CSS". It's like JavaScript in the early 2000s, where the language has (in the minds of developers) to be worked around with stuff like tailwind.
- graftak 2y ago
  Css scoping has been fixed for ages already by css modules, styled components, or/and (native) support for nested css declarations. If those all fail there’s namespace conventions like BEM. If your css is a mess in 2024 (2016 really) it is all on the developer and not the language.
  - _heimdall 2y ago
    Fixing scoping in userland, like with styled components or BEM, is definitely doable but not really the same as having native support for scoped styles in CSS. There's nothing wrong with those solutions and I've used those and similar plenty, but they are fragile. Those are conventions that have to be maintained and stuck with, and often for scoped style solutions you're also left with a hard dependency on a build step (BEM is an exception there). That may not be a problem at all, if you're using react you almost certainly already have a build and bundle step, but not every project is that way.
- gonzo41 2y ago
  You are not wrong. But my god, the tech debt in any slightly older web app's CSS is bonkers. Even with really well thought out templates you still end up with ~5000 line css files that have all sorts of state and magic in them. And like all tech debt, it's a triage. What I'd really like is more intellisense for css so I could take a css file and get sensible code complete and class suggestions for elements.
andrecarini 2y ago
> Anchor Positioning Are there selectors for this anchor relationship? e.g. style anchored element when anchor is on :hover
holoduke 2y ago
If one wants to replicate exact similar behavior in a webapp conpared to a native app we need the scroll/view animation to be available in all browsers. Right now animation is only possible with js and results in jittery animations.
paavohtl 2y ago
The answer in my team's case is browser support and especially Safari on iOS. Our UI is quite complex and demanding regarding functionality, visual presentation and accessibility and would benefit greatly from most of these features, especially subgrid and container queries (and anchor positioning, but that feature doesn't exist outside of the latest version of Chrome). Even though MDN lists most of these features as "baseline" supported, the reality is that a small but still meaningful share of our users are using old iOS devices – especially iPads – and they can't or won't update their operating system to update Safari. Our oldest supported browser is Safari 14 because of Flexbox gap support. None of the other platforms are a problem, as basically everyone else is using an automatically updating evergreen browser.
- Unai 2y ago
  I've read a few articles like this in the last few days and I don't understand why everyone is ignoring the elephant in the room. It's 2024 and Safari is still not evergreen. When people say Safari is the new Internet Explorer, replies always mention how Safari just adopted such and such bleeding edge CSS feature (while ignoring much older features, though), but the truth is many Apple users won't see those features for years, until their devices break. Apple is stopping both users and developers from enjoying these very same new features they so happily announce. The web is stuck in time, waiting for enough people to update their devices. Just like in the age of Internet Explorer. At least back then people had the option of installing a different browser. So maybe Safari and the apple ecosystem is actually worse than IE and Windows used to be.
  - BeFlatXIII 2y ago
    > but the truth is many Apple users won't see those features for years, until their devices break Yet another case of iPads being held back by their software. IIRC, iPads have slower replacement cycles than either iPhones or Macs.
Flimm 2y ago
For me personally, it's because I've been burned too many times by blog posts announcing that "feature X is here!", when in reality, it's only here in Chrome or behind a feature flag, or the exciting parts haven't been implemented yet. Even this blog post falls into the same trap. There isn't good cross-browser support for view transitions or anchor positioning, and yet they're listed as here now.
- leephillips 2y ago
  It does not fall into the trap: “Granted some things are relatively new, and others might be sort of niche-y.”
- bramus 2y ago
  View transitions are the perfect candidate progressive enhancement. If the browser supports it, then the user will get the rich animations. If it doesn’t, then they get what they currently have. And once other browsers starts supporting it, the experience will automatically work in those browsers too without you needing to touch a single line of code :)
  - strix_varius 2y ago
    > View transitions are the perfect candidate progressive enhancement. Quite the opposite. The alternative to "no view transitions" isn't "clunky hard-refresh page-by-page experience," it's single-page view transitions orchestrated by JavaScript (instead of by Chrome). View transitions require you to fundamentally change the architecture of not just a page, but your entire website/app.
6510 2y ago
I dunno sir, do you just assume everyone knows what these list items are? I would link them to their appropriate mdn article. I think non of the readers know everything about all of the items. This should be one of those articles one can click around in for considerable time. Having to select and search made me wonder at what point in time we lost the ability to click on the bullet to select the list item text? Does anyone remember that feature?
tbm57 2y ago
don't call me a monkey for not using a tool that I don't need, thank you!
PaulStatezny 2y ago
Some comments here are framing CSS as getting too complex. Some folks are recommending the utility-class approach (e.g. Tailwind). I don't want to argue for Tailwind, but as someone who's used it for ~4 years now, it strikes me that I've forgotten what it's like to have to think about sets of CSS rules and how they collide. Utility class systems completely remove the need to even consider conflicting rules. That doesn't mean CSS shouldn't continue to grow though, and I welcome these new features.
marcinreal 2y ago
I simply need wide support. I made some websites for a client who receives many 1. older customers and 2. customers from all over the world. I was conscious of the possibility that these customers could have either ancient devices or some highly obscure foreign devices not reflected on caniuse.com. Now, if your domain ends in .dev you can just assume that your users are up-to-date techies, but otherwise I avoid anything newer than flexbox (which is just so useful).
sebazzz 2y ago
CSS layers are completely unintuitive to work with. I really don't see the use case for them. I hoped to isolate Telerik styling with it but it only made it harder to override styling.

175 points by mxbck 2y ago

This article is interesting but when we’re talking about design elements I think it’s always a good idea to include some actual demos or examples showing the final result and not just the “code”. I might also not be the target audience but I still don’t understand what container queries are or what old paradigm they’re replacing. The author does a good job explaining the difference between border-radius and the old way of using photoshop, but fails to do that for the features that he’s trying to promote.

ervine 2y ago
Old paradigm (media queries): You make layout changes based on the width / height of the viewport (browser). New paradigm (container queries): You make layout changes based on the width / height of the containing element. This lets you layout a component so that it looks good in any sized container. Picture a component that might be in the main section or in the sidebar - you can now just style directly based on width of the container instead of having to know the total width of sidebar + main section and do the calculation using viewport width.
- kevindamm 2y ago
  Agreed, but to add to this: media queries are still useful, and since a media query may hide/remove entire containers in the view then the remaining containers may have widths that are no longer a simple proportion of the viewport width (or other property being selected for). So container queries can also enhance styles with media queries, not just replace them.

AltruisticGapHN 2y ago

CSS is becoming too complex. The syntax looks like it wants to be output by some compiler instead of being crafted by hand. Personally I also don't have any pleasure anymore writing CSS these days. Sass and BEM methodology works fantastically well. Naming things isn't that hard, but Tailwind/utility approach is also extremely useful. Those new features, besides container queries is just gibberish. Layer? WTF? The cascade is bad enough as it is, most devs can't even deal with the cascade it's why Tailwind become so popular. And we should dive even deeper into the cascade BS with layers and scoping and whatnpt? Again, this all looks like it was made to be output by some CSS compilers, not written by a developer.

notRobot 2y ago
You don't have to use the new fancy features, you can keep doing things the old way.
- pipeline_peak 2y ago
  I think he means other people will though.
willio58 2y ago
I’m unsure if you have specific feedback or just a general misunderstanding of the point of additions like layer to the spec. At the end of the day these are all more tools in our toolbelt. If you want you can keep writing CSS the same way you always have.
- paulryanrogers 2y ago
  There is a concern that one can have too many tools to do the same -- or very similar -- things. This can reduce readability. Consider Perl's many ways approach to Python's (initial) goal of one way.
  - orhmeh09 2y ago
    Every new release of Python 3.x further erodes this idea. I like using the new features because I find Python generally inexpressive and verbose, but I have a hard time explaining to nondevelopers who read the code about the assignment expression, keyword only arguments, structural pattern matching, typing improvements and deprecations and so on.
- culi 2y ago
  > At the end of the day these are all more tools in our toolbelt. If you want you can keep writing CSS the same way you always have. I don't really stand by GP's comment but I also don't think their concern can be dismissed this easily. We generally write CSS as teams. You'll have to read as much CSS as you'll have to write. Ideally you actually read more than you write so you can reuse existing rules and follow established patterns Anyone writing CSS for a day-job, an OS project, or even just following a tutorial will have to at least familiarize themselves with these concepts

kerkeslager 2y ago

> Quick question: how many of these have you actively used in production? > Container Queries I haven't used this, but it looks super useful. > Style Queries Eh, I'm sure this is useful for situations that don't come up very often. > CSS Layers Ugh, I'm not going to use this overly-complex silliness, and I'm not looking forward to debugging this when other people use this. > Subgrid Again, overly complex. Grid could already do everything this can do, more simply. > Native Selector Nesting I'm already using this. > Anchor Positioning Eh, I already had solutions to this problem, but this seems like it probably communicates intent a bit better. I guess I'll pick that up. > :has, :is, :where :has is useful :is... okay, fine, syntactic sugar. :where I don't believe in hell. If I did, I'd be against it because burning someone for eternity is inhumane. But I might be willing to make an exception for people who write CSS that requires you to read the MDN article on Specificity to understand it. > Logical Properties Perhaps useful for situations that don't come up very often. Seems complex, but that might be because the thing it's representing is inherently complex. > Scroll-Linked Animations Okay, someone who isn't me will probably do really cool things with this. > View Transitions Another thing that seems complex, but possibly because the thing it's representing is inherently complex.

bobthepanda 2y ago
i actually came up with a thing where subgrid would be useful, since subgrid lets you denote that a child wants to use the same grid as the parent. if you wanted to use grid template areas, and you had something that looked like <div id="my parent grid"> <h1>Title</h1> <ul> <li /> <li /> </ul> </div> There isn't a great way to make the <li> adhere to the grid template areas, because without subgrids only direct children (the ul) have coordinate attributes.
- noduerme 2y ago
  I haven't needed to do CSS grids for awhile, but couldn't this have already been done with `display:contents` ?
  - bobthepanda 2y ago

rafark 2y ago

> I can’t use [feature X], I need to support [old browser]. And that’s not necessarily a bad thing. As I commented a few days ago, nowadays devs don’t seem to care too much about backwards compatibility. I like to hold onto my devices longer than most people and it’s a bit frustrating to see that most sites nowadays expect you to be in the latest and greatest. It didn’t use to be like this.

parhamn 2y ago
I'm a bit torn on this when it comes to browsers. We recently had a user email us that our app stopped working for them. After we dug into it it was because their Chromebook was last updated in 2021 and didn't have Object.hasOwn (which a third-party library uses) and it's not even included in most common polyfills either. We fixed it, because I hate these sorts of compatibility issues. Nevertheless, I left a bit concerned that they hadn't updated their Chrome in 3 years. Software decays much quicker than hardware in a real way, especially with the never ending list of security vulnerabilities found every year. Theres definitely a case to be made that forcing software upgrades is good for the end user too.
- nemomarx 2y ago
  I think you can expect that for a Chromebook, but a different type of laptop might not support modern Chrome? I remember that Steam uses enough chromium nowadays that they had to drop support for Windows 7 early. Chrome doesn't have quite as long a support window for older OSes as the OSes do for security updates.
  - Guidii 2y ago
    Is that true? Windows 7 OS updates ended in 2020, while Chrome continued to update until M109 in 2023[1]. [1] https://support.google.com/chrome/thread/185534985/sunsetting-support-for-windows-7-8-8-1-and-windows-server-2012-and-2012-r2-in-early-2023?hl=en#:~:text=Chrome%20109%20is%20the%20last,requires%20Windows%2010%20or%20later https://support.google.com/chrome/thread/185534985/sunsettin....
- 2y ago

spartanatreyu 2y ago

> Quick question: how many of these have you actively used in production? > Container Queries They aren't useful yet because: 1. Using them requires a wrapper element which can dirty up the HTML 2. While we were waiting for container queries to arrive, we also got new rules that made fluid layouts easier to implement which handle a chunk of container queries use cases. Container queries will become more useful when elements can query their own size, rather than their size inside a designated parent. > Style Queries A solution in search of a problem. Current selectors are acceptable for most current use cases. May be useful for customizable widget/dashboard style layouts. > CSS Layers Nice, but they currently place too many demands on the developer to understand what layers currently exist. These will become more useful as browser dev tools make debugging them easier to reduce the burden on the developer to keep the layers in their mind while coding/debugging. > Subgrid Very useful when you need things aligned, especially in things like card layouts. The only thing holding this back is developers who are too reliant on 3rd party framework/libraries, e.g. bootstrap developers relying on grid column classes and tailwind developers building things with margin/padding everywhere. This will take time for developers to shift to, but those developer who limit themselves inside their own framework/library bubbles may never use them. > Native Selector Nesting Very nice quality-of-life improvement. > Anchor Positioning Only supported by one browser. I have no idea why this was even in the article to begin with. But it will completely remove the need for some JS placement/layout logic that keeps getting reimplemented all the time with pop-ups (pave the desire paths and all that). It also has the potential to make margin notes easier. > :has, :is, :where :has is super powerful as a parent selector :where is great for simplifying repetitive css > Logical Properties If you maintain the discipline required to use these aliases over {top/left/down/right}, or if you have a linter to remind you, all of a sudden you're now able to support RTL languages without needing to spend time and money to make a different site for them. > Scroll-Linked Animations > View Transitions Both will be abused by marketers and "designers" who don't understand accessibility, but both will also greatly simplify micro-interactions on proper websites that aren't trying to be a "marketing experience".

o11c 2y ago
:has isn't available in Firefox ESR (115) yet. The next ESR (128) will trickle out between July and October. @property (not mentioned) is only in Firefox Nightly; hopefully it makes it for 128 ...

npn 2y ago

This is a bad article. > And while support for Container Queries is green in all modern browsers, people still seem reluctant to go all-in, fearing they could break something as fundamental as site layout in older browsers. Don't you know there are still a fuck ton of people that are still using the old iOS versions with their old phones? I have plenty of them, and they are long term supporters that I just can't shut them off. There are new css features that are almost harmless and do not affect the usability, some css features on the other hand...

thoughtpalette 2y ago
Bit subjective. I thought it was a great article. Lot's of new properties I've never heard of.
- npn 2y ago
  It is not hard to keep track of new css/js features, as the articles pop up very often, e.g: https://developer.chrome.com/blog/whats-new-css-ui-2023 https://developer.chrome.com/blog/whats-new-css-ui-2023 Most of us just decide to ignore them, because a significant portion of our userbase stills stuck with old devices. People who agree with this article probably never get accessed to any website statistic dashboard.
  - thoughtpalette 2y ago
    For sure, I understand usage statistics and device targets, etc for your audiences. I don't think it diminishes the informative nature of the article. You can be still be excited about new features even if you can't use them for your particular product/audience/etc.

baggy_trough 2y ago

If you want to use nesting, for example, you will have to give up Windows < 10 and iOS < 17.2. It's a big ask for some sites.

eviks 2y ago
why wouldn't this work? > You’d need a separate stylesheet to support everyone.
- yurishimo 2y ago
  In theory it can, but when you work with 20 other devs all working on the same codebase, tracking those changes can become burdensome. Are we going to add an entirely new testing suite and workflow tools to save 5 lines of legacy CSS in favor of the new version? Probably not in a lot of teams. You also need to write and maintain code to conditionally load that fallback stylesheet and hope your users aren't using some weird user agent hacks (looking at you instagram in-app browser). All of these problems can be solved, but obviously nobody wants to because the juice is not worth the squeeze. This is not our first rodeo. I'm gonna wait another 18-24 months and then start using most of the features released this year. It's fine.
JimDabell 2y ago
You don’t. Safari has supported CSS nesting since v16.5. The specification was updated to remove the earlier requirement to use & though, and support for that was introduced in v17.2. As long as you include the &, you can support everything back to v16.5. Not sure what you are referring to regarding Windows < 10, but Windows 10 was released nine years ago. Only a tiny fraction of web developers need to support decade-old clients. If you do need to support browsers that don’t understand CSS nesting, use PostCSS or Lightning CSS. They will transcode your nested CSS to older syntax browsers support. Then, when you drop support and remove those browsers from your browserslist, they will stop transcoding it and the CSS you deploy will get smaller. But you’ll have been writing standard nested CSS all along.
- baggy_trough 2y ago

InMice 2y ago

Whats the eloquent javascript or think python equivalent for css? is it mdn docs or another? Does anyone know the best active, comprehensive online references? How else do you really keep up on all the crazy new stuff

emmanueloga_ 2y ago
The state of CSS surveys [1]. -- 1: https://stateofcss.com/en-US https://stateofcss.com/en-US
sphars 2y ago
It may be ran by Google, but https://web.dev/ https://web.dev/ is one good source for keeping up with new web technologies
chrisweekly 2y ago
Great Q! Pretty much everyone in the field knows about MDN (https://developer.mozilla.org/en-US/ https://developer.mozilla.org/en-US/ ) and https://web.dev https://web.dev and https://caniuse.com https://caniuse.com but the Interop project is newer and maybe flying under the radar: https://webkit.org/blog/14955/the-web-just-gets-better-with-interop/ https://webkit.org/blog/14955/the-web-just-gets-better-with-... Enjoy!

bruce511 2y ago

>> But take container queries, for example. They were the number one feature requested by front-end devs for a looong time. So why don’t we use them more, now that they’re finally here? A number of things are in play here. 1) when people ask for something it's because they need it now. The client wants it to look like x. Providing it a year later doesn't mean I'll retro-fit it, I'm working for another client now. 2) the new features on offer are (mostly) not low-hanging fruit. 20 years ago we were asking for the basics - not-table layout (flex, grid), variables (var --), conditionals (@media) and so on. The low hanging fruit stuff. Now "most people" aren't really asking for anything. (The sliver of a minority attending css conferences naturally are dreaming up new edge cases.) 3) most of the websites that exist (aka have been styled) are older than these features. Since redesigns are typically multiple years apart it takes years for them to filter in. As a proportion the number of sites built, or updated, in the last year is small. And the proportion of those needing these features is smaller. 4) most sites are not styled from an empty notepad. Most use (reuse) a framework - either personal or public. CSS is starting to move from mid-stage to late-stage development. We're well passed the "terrible to work with" stage, well passed the "good enough" stage, and now into the "what can we dream up stage". That said I can see myself using some of these things - sub-grid and :has being the obvious ones for me.

atoav 2y ago
Yeah, I still remember a site where I really would have needed the :has selector, but I have written a workaround in JS and now I would rather so the whole thing new than fix that tiny aspect. I will however definitely rely on the has: selector next time I encounter that situation (it had to do with markdown output putting img tags inside paragraphs, so I needed css that treats a paragraph that has a img inside differently than other paragraphs).
- noduerme 2y ago
  Does :has function as a parent selector? That's probably the only thing I ever really wanted from CSS and I assumed it would never happen because of the (back propagating) implications for the order the DOM is rendered in.

skolind 2y ago

Great article! CSS doesn’t get enough attention - not outside of Tailwind, which I don’t think is the way to go, but that’s another story. :has() and :is() are awesome. One issue I’ve had with any of the newer CSS features is that, most of the people I work with don’t know what they do, because nobody use them. So, I have to explain myself in each pull request - but I guess that’s ok, because then people learn.

michaelnny 2y ago
Agreed, I still prefer to write my own CSS than using tools like Tailwind.
- swagasaurus-rex 2y ago
  For specific components, I use explicit CSS, but for layout <divs> I use the tailwind shorthand (flex, flex-row, mb-7) and just add those to my CSS as I go so I don't need tailwind as a dependency. It's the best of both worlds.

sir_pepe 2y ago

The real problem in my experience is that people who consider themselves to be "real" developers don't care about CSS. I do a ton of code reviews and consulting for companies of all sizes and their JavaScript and TypeScript is almost always at least in a borderline defensible state? But CSS is always one giant file that has been growing since 2002 and is treated as an append-only log of !important. Nobody even tries to fix their CSS because nobody can imagine the concept of "well written CSS". It's like JavaScript in the early 2000s, where the language has (in the minds of developers) to be worked around with stuff like tailwind.

graftak 2y ago
Css scoping has been fixed for ages already by css modules, styled components, or/and (native) support for nested css declarations. If those all fail there’s namespace conventions like BEM. If your css is a mess in 2024 (2016 really) it is all on the developer and not the language.
- _heimdall 2y ago
  Fixing scoping in userland, like with styled components or BEM, is definitely doable but not really the same as having native support for scoped styles in CSS. There's nothing wrong with those solutions and I've used those and similar plenty, but they are fragile. Those are conventions that have to be maintained and stuck with, and often for scoped style solutions you're also left with a hard dependency on a build step (BEM is an exception there). That may not be a problem at all, if you're using react you almost certainly already have a build and bundle step, but not every project is that way.
gonzo41 2y ago
You are not wrong. But my god, the tech debt in any slightly older web app's CSS is bonkers. Even with really well thought out templates you still end up with ~5000 line css files that have all sorts of state and magic in them. And like all tech debt, it's a triage. What I'd really like is more intellisense for css so I could take a css file and get sensible code complete and class suggestions for elements.

andrecarini 2y ago

> Anchor Positioning Are there selectors for this anchor relationship? e.g. style anchored element when anchor is on :hover

holoduke 2y ago

If one wants to replicate exact similar behavior in a webapp conpared to a native app we need the scroll/view animation to be available in all browsers. Right now animation is only possible with js and results in jittery animations.

paavohtl 2y ago

The answer in my team's case is browser support and especially Safari on iOS. Our UI is quite complex and demanding regarding functionality, visual presentation and accessibility and would benefit greatly from most of these features, especially subgrid and container queries (and anchor positioning, but that feature doesn't exist outside of the latest version of Chrome). Even though MDN lists most of these features as "baseline" supported, the reality is that a small but still meaningful share of our users are using old iOS devices – especially iPads – and they can't or won't update their operating system to update Safari. Our oldest supported browser is Safari 14 because of Flexbox gap support. None of the other platforms are a problem, as basically everyone else is using an automatically updating evergreen browser.

Unai 2y ago
I've read a few articles like this in the last few days and I don't understand why everyone is ignoring the elephant in the room. It's 2024 and Safari is still not evergreen. When people say Safari is the new Internet Explorer, replies always mention how Safari just adopted such and such bleeding edge CSS feature (while ignoring much older features, though), but the truth is many Apple users won't see those features for years, until their devices break. Apple is stopping both users and developers from enjoying these very same new features they so happily announce. The web is stuck in time, waiting for enough people to update their devices. Just like in the age of Internet Explorer. At least back then people had the option of installing a different browser. So maybe Safari and the apple ecosystem is actually worse than IE and Windows used to be.
- BeFlatXIII 2y ago
  > but the truth is many Apple users won't see those features for years, until their devices break Yet another case of iPads being held back by their software. IIRC, iPads have slower replacement cycles than either iPhones or Macs.

Flimm 2y ago

For me personally, it's because I've been burned too many times by blog posts announcing that "feature X is here!", when in reality, it's only here in Chrome or behind a feature flag, or the exciting parts haven't been implemented yet. Even this blog post falls into the same trap. There isn't good cross-browser support for view transitions or anchor positioning, and yet they're listed as here now.

leephillips 2y ago
It does not fall into the trap: “Granted some things are relatively new, and others might be sort of niche-y.”
bramus 2y ago
View transitions are the perfect candidate progressive enhancement. If the browser supports it, then the user will get the rich animations. If it doesn’t, then they get what they currently have. And once other browsers starts supporting it, the experience will automatically work in those browsers too without you needing to touch a single line of code :)
- strix_varius 2y ago
  > View transitions are the perfect candidate progressive enhancement. Quite the opposite. The alternative to "no view transitions" isn't "clunky hard-refresh page-by-page experience," it's single-page view transitions orchestrated by JavaScript (instead of by Chrome). View transitions require you to fundamentally change the architecture of not just a page, but your entire website/app.

6510 2y ago

I dunno sir, do you just assume everyone knows what these list items are? I would link them to their appropriate mdn article. I think non of the readers know everything about all of the items. This should be one of those articles one can click around in for considerable time. Having to select and search made me wonder at what point in time we lost the ability to click on the bullet to select the list item text? Does anyone remember that feature?

tbm57 2y ago

don't call me a monkey for not using a tool that I don't need, thank you!

PaulStatezny 2y ago

Some comments here are framing CSS as getting too complex. Some folks are recommending the utility-class approach (e.g. Tailwind). I don't want to argue for Tailwind, but as someone who's used it for ~4 years now, it strikes me that I've forgotten what it's like to have to think about sets of CSS rules and how they collide. Utility class systems completely remove the need to even consider conflicting rules. That doesn't mean CSS shouldn't continue to grow though, and I welcome these new features.

marcinreal 2y ago

I simply need wide support. I made some websites for a client who receives many 1. older customers and 2. customers from all over the world. I was conscious of the possibility that these customers could have either ancient devices or some highly obscure foreign devices not reflected on caniuse.com. Now, if your domain ends in .dev you can just assume that your users are up-to-date techies, but otherwise I avoid anything newer than flexbox (which is just so useful).

sebazzz 2y ago

CSS layers are completely unintuitive to work with. I really don't see the use case for them. I hoped to isolate Telerik styling with it but it only made it harder to override styling.