Good stuff. The scrollbar-gutter property is new to me. I've wanted that before in cases where content getting longer would cause a scroll bar to show, which would eat into the content space, which would break the layout.
Neither location mentions what should I think be by far the main purpose of scrollbar-gutter: avoiding layout shift when you open a modal and disable the page’s scrollbar to avoid confusion.
Perhaps the best solution there would be some way of designating a certain scrollable area as the document scrollable area when the body element doesn’t have scrollbars, so that Up/Down/PageUp/PageDown/Space/Shift+Space all act as though it were focused when the body is focused. That way, you could have the modal exist in the DOM after the main scrolling area, rather than inside it, and you wouldn’t need to worry about document scrollbars or overscroll behaviour. Multi-pane views (very common in desktop apps) are normally a bit of a mess on the web, and it’s always a pain when you come across a web page that has shunned the body scrollable area and put everything in something like a <main style="overflow:auto">, so that you have to focus that before keyboard scrolling works.
I should finish my draft blog post from a year or two ago where I explored the space and all the hoops you have to jump through to have it work almost perfectly, though it still requires some client-side JavaScript to redirect body focus to the correct element.
> Neither location mentions what should I think be by far the main purpose of scrollbar-gutter: avoiding layout shift when you open a modal and disable the page’s scrollbar to avoid confusion.
This can already be avoided by layering things right and not removing the scrollbar.
If you don’t remove the scrollbar, then the document can be scrolled underneath the modal. You can, these days, significantly mitigate this with overscroll-behavior on the modal backdrop, but the document scrollbar itself still works. (I will note, however, that overscroll-behavior is still missing on Safari. And scrollbar-gutter isn’t on Safari and is still disabled by default on Firefox.)
Expecting your website to be identitical across every browser is not the goal. You need to build sites that respond to the capabilities of the user's device, and progressively enhance to get better as more features become available. If the website is less wide to account for the scrollbar on browsers where it can be that's awesome, and if it's full width on browsers that don't have the gutter feature that's OK too.
Critical functionality should work everywhere. Then users should get the best experience possible that their browser supports on top of that.
Good point, but in my case this caused a horizontal scroll bar to also appear, which looked awful, so I guess it was critical functionality to me and not just an enhancement :)
It is a fairly new property so it may be a while before it is ubiquitous (the MDN page links to a ticket for implementing it is Firefox where it is not yet present at all, for instance).
As it is a property to reduce visual artifacts (as content length changes) it is a safe one to specify and have ignored where not supported: users of other browsers will just not get that minor benefit until the browser catches up. This may be a problem if you are trying to achieve perfectly identical presentation to all users, but you've got a lot of problems coming your way too if that is one of your goals!
A browser not supporting this property of you user it is not going to break a design, not to the point of causing functionality or usability issues, unless you are doing something very strange and complex.
Is there a sensible way with flex box wrapping to say “I want you to do your best to keep the rows even in count. If you can’t fit six on a row, don’t just wrap one, wrap three.”
For 'don't just wrap one, wrap TWO', I've used nested flex wrappers. For three... I'm not sure if there's a good way to first wrap three then wrap two when there's not enough room for three. But for two, just:
That kind of assumes all the inner div's are the same width too; I'm not sure if your question necessarily does or not.
If it's possible to do something more sophisticated and clever with flexbox I don't know... but maybe with grid? I don't have my head completely wrapped around grid, but currently i naively believe it can literally do anything.
It's complex for a reason. Go try some other layout tools and you suddenly realize that half the things you can do in CSS are impossible when limited to just columns and rows.
Certainly there are odd parts to CSS that are due to it originally being only intended for relatively static content, but when you try and create a layout system from scratch you keep running into issues that the CSS people have spent years figuring out already.
Take Figma's layout system for example. They built their own from scratch to keep it simple and straightforward and yet I can't create half of the layouts I need to in Figma that are pretty simple to do in CSS. All the top requested features on the Figma forum are to recreate HTML and CSS behavior and often coming from designers who don't actually know HTML/CSS, indicating these are universal layout requirements, not just something developers are demanding.
Yes the sensible approach of loading a whole layout, drawing, and interaction library before showing anything at all on screen. Why has only Google thought of that?
Really good stuff. No fluff and very comprehensive.
The author has lots of other solid content on his page. I've now gotten to the stage where I can learn so much from people with half my experience in years.
CSS frameworks are a great tool for getting started, or building something where you have some flexibility in the design, but my experience has been that it's often harder to fight a framework to fit a particular design than it is to just write CSS.
I think flex-wrap is more of a problem itself. Some browser (most likely safari) just decide to wrap it even its child explicitly specify flex-shrink to allow shrinking to fit the container (Thus explode the layout). It is better to set as never wrap unless you explicitly want to.
You know I was thinking of creating a text-only website and setting the mime-type to text in Apache. I'm only interested in the text of a website. CSS is added for flair and a sort of 'Look at what I can do with CSS!' virtue signal (for either potential employers or just to show off to your visitors). The amount of times I have to hit Reader View just to read a webpage is astonishing.
When creating a website I start with text first, and bolt on CSS where it's needed, but having a site which is primarily text would be an interesting experiment to run.
Edit: I know having text-only would mean not having hyperlinks, but you could keep everything on one page, and link out to articles via the usual channels (social media, etc)
https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-g...