One line of CSS, `container-type: inline-size`, is meant to let a box answer to the width of the box around it. In Chrome 157 on 5 November 2026 it changed six of the seven layouts I tested, and none of the six involved a container query.
Smashing Magazine published an essay on this kind of side effect on 3 November. These are my numbers, what I didn't test, and the habit I'd keep.
What Smashing Magazine argued
On 3 November 2026 Smashing Magazine published "Modern CSS Might Make Your Front-End More Complex" by Gabriel Shoyombo, a 22-minute read. As I read it, the argument is that swapping JavaScript for a modern CSS feature can make one file shorter and leave the wider site "harder to reason about", because the feature shares the page with the CSS and JavaScript already there. He says he isn't against modern CSS.
I'm taking his second scenario, on how marking a box as a container changes layout. My pages are my own code, but the case list, the 16px and 24px margins, the 120px float and the plain block control follow that scenario's demo. This is a modest replication, not new ground. What I add is the exact Chrome build, the 28px result (the essay reports 0px for its cards, and mine kept their padding), the heights, three renders of each case and the limits.
What the line tells the browser
A container query is a CSS rule that styles a component by the width of the box it sits in, not the width of the whole screen. To use one, you first mark the box as a container with that one line, `container-type: inline-size`. ("Inline-size" is width, in English text.)
As I understand it, the line makes the browser promise to work out the box's width without looking at what's inside, which is called inline-size containment. A box that normally takes its width from its content has nothing left to use.
The essay, citing MDN's list of what creates one, says a container is also a block formatting context. These definitions are background, not my measurements. A block formatting context is a self-contained layout area. Floats, which are boxes pushed to one side so text wraps around them, can't overlap it. Margin collapsing, where touching vertical margins merge into the larger one instead of adding up, stops at its edge.
How I measured it
On 5 November 2026 I built seven small test pages and opened them in Google Chrome 157.0.8103.38, driven by a script. Each is 800 pixels wide (CSS pixels, the unit browsers lay pages out in). Five pages use a box padded 8px top and bottom and 14px left and right: flex row, inline-block, fit-content, floated box and the plain block control. The margin page has an unpadded card, and the beside-a-float page a card padded 8px on every side.
For each page I asked Chrome for the box's size and position with the line off, then on, over three renders. All three matched every time. None of the pages contains a container query, only the one line.
What changed
Four of the seven pages put a box whose width came from its own text into a layout. On all four it fell to 28px, the 14px of padding on each side and nothing else. The heights grew too. My reading, from background knowledge rather than measurement, is that the text wrapped at every space with no width left: 16px of padding plus 18px lines gives 52px for two lines and 70px for three. In the flex row all three tags are 88px tall. I put that down to flex stretch, a default that makes every item in a row as tall as the tallest, and 88px matches four lines in the longest tag. The bracketed explanations below are background too.
- Three tag boxes in a flex row (a row that lines its children up side by side, each child being a flex item): 84.9, 141.8 and 154.3px wide became 28px wide each, and 88px tall instead of 34px.
- An inline-block box (one that sits in a line of text but keeps a box shape): 101.8px wide became 28px, and 34px tall became 52px.
- A box set to `width: fit-content` (as wide as its content and no wider): 138.3px became 28px, and 34px tall became 70px.
- A floated box: 99.1px became 28px, and 34px tall became 52px.
- A plain block box, which takes its width from its parent: 800px before and after. This is my one control. A plain block box with no float or margin involved didn't change here, and one control can't show that no such box ever does.
- Margin collapsing: a card whose first heading has a 24px top margin, under a paragraph with a 16px bottom margin. Without the line the card sat 42px down and was 40px tall. With it, 34px down and 64px tall. It grew by 24px, the heading's margin, which fits with that margin now sitting inside the card. That's my reading.
- Beside a float: a card following a 120px-wide float. Without the line it started at x=0 and was 800px wide. With it, x=120 and 680px wide.
What my colour-scheme test found
This part is weaker than the layout results. In my Safari article I added `color-scheme: light dark`, a line telling the browser a page supports both light and dark colour schemes, to local copies of 24 real pages in Chrome, using a meta tag, a line in the page's head that carries settings for the page. Across 48 runs, nothing crossed my threshold in 39 and five differences were timing. In the other four, one default checkbox on one page turned dark. The browser's default page background flipped on my test page and three real pages I checked, and on all 24 in an earlier run that used a style instead. I expected pages to break, and at that threshold I was wrong.
On 5 November 2026 I added one narrower check in Chrome 157, this time as CSS rather than a meta tag, with dark mode emulated. On a page with one paragraph of dark grey text, the computed value (the one the browser ends up using) of `color-scheme` went from `normal` to `light dark`, and the text colour read rgb(51, 51, 51) both times. That's close to a null result: it confirms only that text colour stays put.
So the two tests aren't equally strong: six of seven pages changed in one, and one checkbox and some browser defaults in the other. All I'd say they share, as my reading, is that a one-line change had an effect beyond its job.
What this doesn't show
This is one browser on one day, on seven small pages I wrote to isolate one line, not real pages or components.
- Browsers: Chrome 157.0.8103.38 only. I haven't tested Firefox or Safari, so I can't say what they do.
- Fonts: the "before" widths depend on the fallback sans-serif font on my machine, because the pages name no font. The 28px result is padding, so I'd expect it to hold, but that's my reading.
- Properties: `container-type: inline-size` only.
- Real use: I haven't checked whether a real card is ever sized from its content in these ways.
- The rest of the essay, such as how CSS selectors compete for priority and the speed of the `:has()` selector (a rule that styles a parent by what it contains): untested.
What I'd look at first
I'm not arguing against modern CSS, and I use it. The habit I'd keep is to test a one-line change like this in every layout that hosts the component, not only the one it was built in. If you own a site in Lake Macquarie, Newcastle or the Central Coast rather than building it, ask whoever looks after it whether new CSS gets checked everywhere a component appears. The first four items follow the three questions the essay suggests, and the last two are mine.
- Where the box's width comes from: its parent, or its own text, as with tags and buttons.
- Whether it's a flex item, an inline-block, a float or set to `fit-content` anywhere it's used.
- Whether the first or last thing inside it has a top or bottom margin, and what sits just above it.
- Whether it ever follows a floated image.
- For `color-scheme`, which colours the page leaves to the browser, such as the page background and form controls.
- The size and position in each layout with the line on and off, plus a screenshot of each. Do all of it on a copy or a test page, never on the live site.
Pages worth acting on
Related page
New Website Builds for Local Businesses
Custom-coded builds for local service businesses, made to load fast and explain the service clearly.
View pageRelated page
Will Safari repaint your light website in dark mode?
My earlier test of what adding color-scheme: light dark did to 24 real pages in Chrome.
View pageWhat to read next
Will Safari repaint your light website in dark mode?
Safari 27.3 beta can repaint light websites as dark, and sites can't detect it. What I found on 24 pages, what happened when I tested the light dark tag in Chrome, and what's still unknown.
Read articleCustom-coded vs WordPress: a real-world speed comparison
The same local business, the same services, one website replaced by another, both measured with Google PageSpeed Insights on the same day. Not a laboratory test, but the closest the real world gets.
Read articleGoogle's shared AI training control is a 2027 plan, not a setting yet
Google plans to support a shared AI training control in robots.txt and aims for 2027. I explain what its post says and doesn't, using my own robots.txt as the worked example.
Read articleQuestions local business owners usually ask next
Want someone to look at the site you've got now?
Send me the address and I'll review it. The Free Website Review looks at what's working, what's getting in the way and the clearest next step, whether or not you hire me.