21 votes

Single-axis scroll has been adopted into the CSS spec and will be supported in Chromium soon

Posted by RheingoldRiver
Tags: css, chromium, features, scrolling, original content, source.river
https://blog.river.me/single-axis-scroll/

Link information

This data is scraped automatically and may be incorrect.

Title
Single-axis scroll
Authors
River
Published
Oct 2 2026
Word count
504 words

7 comments

  1. [2]
    Lyrl
    Link
    A missing use case documented in 2017, design agreed on and coded in 2026, and rollout expected in 2029. Good things often happen slowly.

    A missing use case documented in 2017, design agreed on and coded in 2026, and rollout expected in 2029. Good things often happen slowly.

    7 votes
    1. RheingoldRiver
      Link Parent
      I'd expect rollout to be done on both Safari and Firefox by the end of 2027, but then you generally want to give 2 years for your users to actually update their software. But yeah, web standards...

      I'd expect rollout to be done on both Safari and Firefox by the end of 2027, but then you generally want to give 2 years for your users to actually update their software.

      But yeah, web standards change slowly....I started having major problems with some of my work projects because of this hole in the spec in about 2018. I was hoping that I'd only have a temporary JS workaround until the spec got adjusted. I left that company in ~2022, and I'm now at my 3rd different company since (not counting temporary contract work). "Temporary" indeed.

      5 votes
  2. [5]
    Narry
    Link
    One of the few times I wish I could embed a GIF. I both love and loathe CSS. When you pull something off and it works right, you feel like a friggin' god. But most of the time I feel like I've...

    One of the few times I wish I could embed a GIF. I both love and loathe CSS. When you pull something off and it works right, you feel like a friggin' god. But most of the time I feel like I've been freshly hit in the head with a hammer. I tried reading this and honestly I haven't the fainest idea what they're talking about.

    3 votes
    1. [4]
      Wes
      (edited )
      Link Parent
      It's a lot of technical keywords, so I can understand it being overwhelming to read. Let me see if I can better explain it. This assumes entry level CSS knowledge. The author is trying to...

      It's a lot of technical keywords, so I can understand it being overwhelming to read. Let me see if I can better explain it. This assumes entry level CSS knowledge.

      The author is trying to implement ideal scrolling behaviour on a very large table. They want the header to stay at the top of the viewport when viewing the table, regardless of how large (or wide) it is. To do this, they rely on position: sticky.

      Position is a very important CSS property because it essentially chooses the layout algorithm used by the browser. Some values, like relative and static, follow the regular document flow. Others, like absolute and fixed, will remove elements from the document flow, anchoring them instead to either a parent or the viewport.

      sticky is sort of a hybrid between the two. The element will stay anchored to its viewport until you scroll past its container, then it remains in document flow. It's likely best explained with a demo. It's very useful for keeping headers on top of content, which is why it's ideal for long tables.

      The problem is that this behaviour isn't very reliable when inside of a container with modified scrollbar behaviour. Scrollbars are controlled with the overflow property. In this case, because their tables can grow very long horizontally, they use overflow-x: auto to say: "If this table pushes right past the browser viewport, only then add horizontal scrollbars". Not being able to combine these features is a long-standing problem.

      The post goes over various suggested fixes, weighing backwards compatibility against syntax/ease-of-use. The solution that was eventually settled on was simply changing the behaviour if using overflow-y: clip with overflow-x: auto.

      clip is a newer value which was designed to fix some of the older problems with overflow: hidden. It can be applied independently to either axis, and doesn't create a (hidden) scroll container which touch users may accidentally swipe across. Since the property is newer, there's far less chance of this creating backwards compatibility issues.

      The post finally explains how to implement this today using the @supports at-rule, which will only apply the CSS in its block if the feature name ("single-axis-scroll-container") is supported in your browser.

      edit: Typo

      11 votes
      1. RheingoldRiver
        Link Parent
        Thanks for this!! I definitely wrote the post assuming a decent amount of background knowledge. Also worth noting that if you apply to the vertical axis in a "normal" document where you are...

        Thanks for this!! I definitely wrote the post assuming a decent amount of background knowledge.

        clip is a newer value which was designed to fix some of the older problems with overflow: hidden

        Also worth noting that if you apply to the vertical axis in a "normal" document where you are letting the content be however tall it happens to be, this property has no real effect. So in the normal case of wanting this feature (sticky to the top, and horizontal scroll), putting overflow-y:clip; is really not doing anything except signal that the new algorithm should be used.

        Honestly I think this is overly conservative, but maybe there's some weird use case of scrolling in vertical axis and sticking to a side that could break...? It's obviously of utmost importance that W3C doesn't go around breaking compatibility, but this just feels like a straight-up bug to me.

        4 votes
      2. [2]
        Narry
        (edited )
        Link Parent
        Thank you for explaining, but I found your explanation as dense as anything in the article; this is probably down my general fatigue trying to parse tech stuff by the time I get the chance to look...

        Thank you for explaining, but I found your explanation as dense as anything in the article; this is probably down my general fatigue trying to parse tech stuff by the time I get the chance to look at Tildes at any given time rather than a reflection your ability to explain. I parse tech for a living and one has his limits.

        The demo explains in a way that I can comprehend. This looks like an improved version of Excel's Freeze Top Panes feature that allows you to lock the very first row of cells from A1:?1 but with additional rows that can overtake the first one as the top column headers. This is indeed a very welcome feature.

        Edit: A few words here and there.

        1 vote
        1. RheingoldRiver
          Link Parent
          That's indeed a good description for sticky, but sticky isn't a new feature; that's been around for years at this point. The new feature is the ability to have both of the following at the same...

          That's indeed a good description for sticky, but sticky isn't a new feature; that's been around for years at this point. The new feature is the ability to have both of the following at the same time:

          1. A horizontal-scrolling element that's smaller than the entire page (look at the scrollbar in the very last image of my blog post, it's only the one table that's able to scroll across, and for most of the page there's no horizontal scrolling at all; and when you scroll, it's only the table that will move, not the rest of the text). You can also play with the demo in the MDN docs if you want, try setting it to "hidden" to see an example of how overflow can work
          2. That same element is able to have the sticky heading behavior

          So this is very specifically to make large tables behave nicely when you're scrolling in both directions at the same time. Previously you had to pick one or the other.

          1 vote