Polypane Blog

Polypane 30.1: Selector specificity insights, server HTML validation, and more

Fri, 28 Aug 2026 00:00:00 GMT

Polypane 30.1 adds selector specificity highlighting to the elements panel, a new server-sent HTML view in the sources panel, passkey support on Linux and a bunch of improvements and fixes. Like Polypane 30 this release is built on Chromium 152.

What's Polypane? Polypane has everything a browser has, plus all the tools you need to build responsive, fast, accessible, and SEO-friendly websites and apps with multi-viewport synchronised previews, comprehensive device emulation and extensive accessibility tooling.

Selector specificity insights

Back in 2020 we launched Polypane's Elements panel, which pioneered showing the selector specificity of your styles right in the elements panel. Not much later we added an online specificity calculator that you could open from the Elements panel to explain selectors.

In Polypane 30.1, we're taking this a step further.

When you hover over a selector in the elements panel, Polypane will now highlight the parts of the selector that contribute to its specificity. It works for plain selectors:

and for nested selectors as well:

When you nest CSS, Polypane shows the resolved selector for the nested rule in the tooltip so you know what the engine is doing under the hood. And now this is of course also highlighted!

For nested CSS selectors, you can see that not only does it highlight the parent selector values, but is also intelligent enough to know that .card, #highspecificity counts as a single ID selector, even if #highspecificity is not part of the DOM.

Lastly, If you have a complex selector with lots of nesting, Polypane's highlighting will drill down to highlight the pertinent parts, rather than listing the single top-level wrapped :is() as being one value:

Drilling down into the selector required us to rebuild our specificity calculation engine, but the end result is an even more robust, accurate and understandable specificity.

We made all of these improvements available in our free online specificity calculator as well, so check it out!

When you use the Peek tool to inspect an element, Polypane will now show you the gap values in the tooltip. Just like the Padding and Margin values, this lets you quickly check the gap values without needing to go to the Elements panel and finding the right declaration.

Passkeys support on Linux

Polypane has had support for passkeys/webauthn on Windows and Mac, which both have operating-system backends to support them, and now Linux support has been added as well. The Linux implementation uses software passkeys through 1Password's passkey-rs library.

Because the Linux implementation does not rely on a platform backend it comes with a custom UI:

This brings parity between the three platforms when it comes to passkey support, and allows you to test your passkey implementations on all three platforms!

Server-sent HTML view in the sources panel

The sources panel now has a new toggle to switch between the rendered HTML (after your JS has run) and the plain server-sent HTML (before your JS has run). This is useful for debugging server-side rendering issues, and for checking that your server is sending the correct HTML to the browser.

Both sets of HTML are validated individually, so you can also easily see where HTML validation errors are being introduced.

Updated placeholdifier debug overlay

We've updated our placeholdifier debug overlay to use a scribble-style font instead of the block font we used before. This makes the blocked content more "text-like" and makes it easier to focus on the design instead of the content.

Chromium 152

Polypane 30.1 is built on Chromium 152. For all the experimental features enabled in this release, check out the experimental web platform features overview.

Get Polypane 30.1

Polypane is available for Windows, Mac, and Linux in 64-bit and ARM versions. Polypane automatically updates, but you can also go to the download page to download the latest version!

Don't have Polypane yet? There is a 14-day trial available.
Try it for free. No credit card needed.

Polypane 30 Changelog

New

New Elements panel: Highlight specificity parts in selector
New Source panel: Toggle between rendered and server-sent HTML (Thanks Matija!)
New Passkey/Webauthn support for Linux
New Updated Chromium

Improved

Improved Accessibility panel now also checks for WCAG 2.2 2.5.8 target size
Improved Meta panel: Show a warning for multiple viewport declarations (Thanks Matija!)
Improved Meta panel: improved header order design and updated ruleset
Improved Elements panel: After inspecting an element the DOM tree is now focused
Improved Peek: show gap values in tooltip
Improved Debug tools: Placeholdifier now uses a scribble instead of a block font
Improved Find in page has improved performance
Improved Browse panel: Basic auth popups are now shown in the browse panel
Improved Panel: focuses the first ordered panel on launch

Fixes

Fix Copy image to clipboard works again
Fix Domain custom color was in wrong position in split views
Fix Detached network panel shows data again (Thanks Eric!)
Fix Detached panel window shows overflow menu again
Fix Elements panel: Misaligned layout debugging badge for html element
Fix Elements panel: specificity explainer link works again
Fix Devtools panel: Issue on linux where the panel would not show content
Fix Recording: pages without an explicit background color now record on white instead of black
Fix Peek: decouple showing font-weight from showing line-height value
Fix Peek: prevent peek from showing when inspection mode is chrome devtools
Fix Browse panel: Shortcuts now work in detached panel too

Polypane 30: Playgrounds, Side Panel extension API, updated video recording and Chromium 152

Wed, 19 Aug 2026 00:00:00 GMT

Polypane 30 introduces Playgrounds so you can open directories as real HTTPS URLs in seconds, adds support for the Side Panel extension API, brings major Network panel improvements, and includes a fully rewritten video recording implementation that's much faster and supports recording sound. It runs on Chromium 152.

Polypane Playgrounds

Playgrounds lets you select any directory on your device and open it as a real URL over HTTPS. That gives you access to security-restricted APIs, cookies, and localStorage.

That way you can test your work without all the fuss of setting up a local server, managing ports and dealing with self-signed certificates.

You choose a folder and a localhost domain, and Polypane does all the work.

Setting up a Playground is a matter of opening the Playgrounds Manager (through right-clicking the reload button, finding it in the Edit menu, or typing "playground" in our command bar) and adding a playground:

But Playgrounds is much more than just a slightly-more-convenient http-server, and it comes with a bunch of developer goodness:

Live reloading

By default, Playground URLs hook into Polypane's live reloading system. Any change you make to a file in the playground will trigger an update in Polypane.

Polypane re-injects CSS and images without a full reload, ignores system files, and reloads HTML when it changes. Just open your HTML file in any code editor and every save will be visible in Polypane.

SPA Fallback

Are you trying out an SPA or using client-side routing? Playgrounds can be configured to always serve your index.html for unknown URLs.

That way your SPA can use client-side routing like the history and navigation API without configuring any server!

Directory listings

Open any file directory (without an index.html) to show a listing of the files in that directory. Navigate into sub-directories and show or hide hidden files. The directory listing is fully styled and supports dark mode, so it works well in any pane. This works for Playgrounds and the file protocol.

If you don't want directory listings for a particular Playground, you can disable it in the playground settings.

Portal-enabled

Lastly, Playgrounds work perfectly together with Polypane Portal to make your playground available on other browsers and devices, and have them all synced together.

So you can set a folder up as a Playground, open it in Polypane, and then share it with your team or clients. They can open the same Playground on their devices and see the same content, with synced scroll, hover and focus states.

I don't think there's any faster way to go from an index.html on your device to a fully synced, multi-device test environment that's available worldwide.

Credit where credit is due The only reason Playgrounds exists is because of the Firefox Devtools team creating Local mode for Firefox 153. Go try it out! They came up with the concept, I just took it and gave it a Polypane spin.

Network panel improvements

Thanks to everyone who wrote in to share their experiences with the new Network panel. We fixed several bugs (thanks Matija!) and added a couple of new features to make it even better.

Toggle between per origin and all requests

The Network panel splits requests per origin, a design decision that helps you get a better overview of the requests made by a page and easily see how many external origins are involved in loading it.

Having the full list of requests is still useful because it can tell you when those external requests are made during load, and what the full request tree looks like. So you can now toggle between the two views with a new button in the top right of the Network panel.

Filter requests

You can now filter requests by typing in the filter input. The filter checks against the URL and its headers. Filtering is case-insensitive by default, but also supports case-sensitive and regex filtering.

Testing against headers lets you do things like find every request served by Cloudflare.

Highlighting initiators

When you hover over an initiator, the panel now highlights the request that initiated it. This makes it much easier to see which request caused a specific request to be made, and lets you very quickly drill down your request tree.

The initiator in each request line has a tooltip that also shows which file or function initiated this request. Now you no longer have to find the request that initiated it in the list, as it's highlighted for you.

Video recording improvements

The previous video recording implementation had a couple of things I wasn't happy with. Recording a video took a lot of memory (so you couldn't make long videos), processing the video after creation was slow and it didn't support sound.

Polypane 30 has a fully rewritten video recording implementation that processes videos essentially instantly and because of that has a much lower memory footprint. Videos are created as webm and include any sound that was playing in the pane.

Everything else remains the same: you record a video, Polypane highlights clicks and you can trim and annotate the video with our built-in video editor (made with the amazing Pintura).

Extension side panel API

Polypane's extension API support has been extended with the Side Panel API. Extensions like Look up WCAG SCs by Ian Lloyd (or those AI sidebar tools) can now add a sidebar to Polypane.

The sidebar lives in the Panel, and will automatically be added or removed depending on the extension state.

Extension tabCapture APIs

Extensions using the various tabCapture APIs to create screenshots or videos are now also fully supported.

Other extension improvements

As users report issues with specific extensions, I have been working to make sure Polypane supports those extensions better by fixing gaps in our APIs or adding support for more APIs.

For this release, I made sure that the APIs used by the KeePassXC extension work correctly in Polypane.

Extensions using the browser namespace instead of chrome now have better support, string replacement has broader support, and managing popups and extension permissions now cover more cases.

Polypane now automatically opens chrome-extension:// links in full layout, so you can use the extension's UI as intended.

Elements panel improvements

The elements panel got a few upgrades in Polypane 30.

Quirks mode badge

When a page is running in quirks mode (when you don't have a doctype) the Elements panel now shows a warning badge where normally the doctype is.

Quirks mode has a lot of weird implications for how a page is rendered, but the absence of a doctype isn't the clearest indicator of that. The badge now makes it clear that the page is running in quirks mode.

This suggestion happened in a Mastodon conversation between Nicolas of the Firefox Devtools team, Roma and me, and it's also coming to Firefox: Bug 2040627

Support for `commandForElement` in the DOM tree

The command and commandfor attributes of the invoker API make it easy to create custom interactions without needing JavaScript. But commandfor needs to reference another element by ID, and adding IDs all over the place (that need to be unique) can be bothersome.

The commandForElement API lets you reference any element directly with JavaScript, so no ID is needed. That's really useful, but it creates a challenge for the DOM tree, because the value of commandForElement isn't a string but a direct reference.

The Elements panel now supports this by showing the referenced element as a badge in the DOM tree that you can click to jump to the referenced element.

Support for `if()` in CSS properties with proper indentation

The new if() CSS function broke our CSS parsing logic, causing the elements panel to look broken. We now support if() in CSS properties and even preserve the indentation you're using in your CSS, so things stay readable in the way you prefer.

Selectable pseudos in the DOM tree

Pseudo elements like ::before and ::after are not part of the DOM so in the Polypane elements panel, they were not individually selectable. Editing their styles happens through their parent element.

People expect to be able to click on these pseudo elements though, so in Polypane 30 you can click them and it automatically opens the styles for that pseudo element in the Styles overview.

Expanding text editor

The text and HTML editors in the navigator are one of our favorite features, because they make editing the text or HTML of an element really easy without any of the focus or modal requirements and, in the case of the text editor, live feedback.

At our CSS Day booth, Bernd asked if we could make the text editor resizable so that it's easier to work with larger amounts of text, and we thought that was a great idea. The text editor now automatically scales to the content.

Accessibility property tooltips

If you look at the accessibility overview and are unsure what a specific property means, you can hover over it to see a description of what it is and when it is relevant.

Default inspection tools

The devtools icons, inspect buttons, shortcuts, and context menus now always open the same devtools: Polypane's Elements panel or Chromium DevTools. This lowers the mental load of remembering which devtools you opened last, and makes it easier to use devtools in Polypane.

Right-click the devtools button in the header to set a default devtools, and all devtools buttons and shortcuts will open that devtools.

Both devtools are still available in the panel, so you can default to Polypane DevTools and open Chromium DevTools when you need, for example, React DevTools.

To learn more about the differences between the Polypane and Chromium devtools, check out docs on Chromium & Polypane devtools

Peek improvements

Polypane peek lets you hold ⌥ to inspect elements. It's really, really nice.

This release has a few changes to make it better:

Touch emulation is disabled when using peek so hovering works (Thanks Marc!)
Scroll syncing is disabled when using Peek, so pages no longer jump when the tooltip causes a scroll event to be sent to the other panes
Our color preview now supports the color-mix() function to the previews display those correctly (Thanks Marc!). We'll be updating color support throughout the app in upcoming releases.
If an element has specific aria attributes, Peek now shows those in the tooltip as well (Thanks Eric!)

Emulation improvements

There are new emulation features in Polypane 30, and some existing ones have been improved.

`text-scale` emulation

Browsers, by default, ignore OS-level text scaling, as many sites are not built to handle a default font size other than 16px.

There is a new text-scale meta tag that will let you tell the browser how to respond to the OS-level text scaling. It looks like this:

<!-- The default, old behavior -->
<meta name="text-scale" content="legacy" />

<!-- Opting in to the new behavior -->
<meta name="text-scale" content="scale" />

By setting the text-scale meta tag to scale, you opt in to using the OS-level text scaling. So if a user has e.g. a 200% scale on their Android Phone, your site's default font size is now 32px instead of 16px. This is a great way to make your site more accessible to users that need larger text.

In the emulations panel you can now easily test this by changing the OS text scale from the default of 100% to between 85 and 200%.

With text-scale set to legacy, this will have no effect, but with text-scale set to scale, you can see how your site responds to the OS-level text scaling.

`svh` difference overlay

The svh difference was always applied, but the visual overlay was off by default. This led to confusion for people who didn't realize their sites or themes used svh, and instead reported "blank areas".

To prevent this confusion, Polypane 30 splits out the safe-area-insets and svh overlay displays and turns the svh overlay on for all devices that support it.

The overlay now has a new style to make it clear that the overlay is showing the difference between svh and vh, and has an info icon to explain it.

You can toggle the overlay through the media and emulations popup for a pane.

New devices

The new iPhone 17e and Pixel 10 devices are now available in Polypane. Both are fully emulated, including safe-area-insets and svh emulation, only available in Polypane.

Meta panel improvements

With support for emulating the text-scale meta tag, we also added support for it in the Meta panel. The Meta panel now shows the text-scale meta tag and its value, and will show a warning if the value is invalid.

We took this opportunity to refresh the layout of the meta panel. We removed the "mobile friendly" check (Thanks Robbert!) as it's no longer something used by Google, reordered and grouped the different lists of meta tags and added support for standard-site validation.

Standard site validation

Standard.site is a new standard for sharing publications on the at-proto protocol that's used by Bluesky. When you have it set up properly, your Bluesky sharing links will include the name and icon of your site and a button to visit it, in a color that matches your site.

Polypane fetches your Standard Site configurations for documents and publications, validates them against the standard.site lexicon, and shows you if there are any issues.

The Bluesky preview then takes that data and makes it easy to see what your standard site configuration will look like when shared on Bluesky.

It also supports Leaflet publications.

Mastodon domain validation

Since our initial implementation of the Mastodon preview, the fediverse:creator requirements changed. You now also need a verified domain before the preview sghows your user byline.

Polypane now checks if the domain is verified and shows a warning explaining how to get it verified when that's missing.

OG image size warnings

Different social media sites have different minimum and maximum dimensions and file sizes for OG images. Polypane now shows the dimensions and file size of the OG and Twitter images in the meta panel, and shows a warning if the image is larger or smaller than preferred, or when it's too small or too large to be displayed.

Robots.txt contents

Along with a parsed robots.txt that shows you the rules along with validating the current page against them, the panel now also shows the full robots.txt content.

Now you can also see anything that's commented out and any other information that might be in the robots.txt file.

Console panel improvements

The Console panel has received a few nice upgrades that make it much easier to use. As a result, evaluation is now faster too.

Better object displays

We now support HTML references in arrays and object previews, so you can see the actual element in the preview, hoverable and clickable to open in the Elements panel.

This makes it much easier to see what you're working with. Object nesting support has also been improved, so you can now expand and collapse more deeply nested objects in the console panel, as well as objects inside of arrays and the other way around.

Same-world evaluation

Polypane's console commands used to be evaluated in an 'isolated world', which meant that you couldn't access global variables and functions defined by you in the page's main world.

Console commands are now evaluated in the main world, so you can access your own variables and functions.

This also means we keep assignments around, so if you specify a const foo = "bar" in one command, you can reference it in the next command. This makes it much easier to work with the console panel.

Accessibility display improvements

Did you know a button can have an invalid user entry? or that hr can set values? That's (almost) never relevant, but it's an artifact of the accessibility model.

We consulted a number of accessibility experts to go over some of the accessibility information we show to decide if and when we should show certain properties.

We now hide values that are irrelevant for the element's role in both the Elements and Outline panels, so that the information that is there is more clearly actionable and relevant.

I'm incredibly lucky to have such a group of caring, knowledgeable, and passionate accessibility experts to consult with. Thank you all for lending your expertise and time to make Polypane better.

Outline panel improvements

The outline panel gathers the accessibility info more efficiently on load, making it slightly more responsive.

Updated focus order overlay

The focus order overlay and the way it calculates the tab order got some performance and correctness improvements.

The result is a more complete and accurate focus order that is also much faster to update as your page changes and the focusable elements get reindexed (for example, when resizing the pane or scrolling).

I have yet to find a tool that is as complete and accurate as Polypane's focus order overlay. For example, in the screenshot above you can see that it correctly matches the reading order, even though the DOM order is different.

It means that you can trust the focus order overlay when auditing, rather than you having to tab through all the (sometimes hundreds of) focusable elements to see if the tab order makes sense. You can just look at the overlay and see if the tab order is correct.

Small bugfix

Lastly, we also fixed a bug where the focus overlay would sometimes mark elements as going against the reading order when they were clearly not. This was caused by our reading order logic using the wrong set of focusable elements (including programatically focusable ones) when calculating the reading order. The focus order overlay now only uses keyboard focusable elements in its calculations.

Panes

Our goal for this year is to sand away some of the edges in Polypane, the things that require Polypane-specific knowledge to understand.

Updated pane header design

We've updated the design of the pane header to make the icons more clearly distinguishable and to keep things more consistent as you interact with the pane.

Icons not currently active appear dimmed, and we're distinguishing the devtools-opening icon from the others.

When hovering a pane header, the sizes stay where they are and the scale settings and rotate button appear to the left of them, so things no longer move around.

Panes now zoom to fit vertically

In previous versions in the horizontal and focus layouts, panes that were too tall to fit the window were clipped. This was a conscious design decision because it always kept scrolling locked in one dimension, but it was confusing when your pane wasn't the size you expected.

Starting in Polypane 30, all panes are automatically scaled down to fit the window vertically in the horizontal and focus layouts, just like they were already scaled down to fit horizontally in the vertical layout.

Now you always see the pane at its intended dimensions.

Manual scaling with `⌘`

By holding ⌘ while dragging a pane's resize handle, you scale the pane instead of resizing it. This keeps the internal dimensions the same but displays the pane at a different scale.

Did you know: holding ⇧ while resizing a pane will keep the aspect ratio!

Project improvements

Projects can now have a custom default tab, and adding bookmarks and environments to a project now automatically scrolls the newly added item into view.

Project specific default tabs

The Default tab, or homepage, can now be set up per project. Configure the current tab as you like (which layout, URL, set of panes, location of the panel etc), open the project settings and click "Set current tab as new tab" to set it as the default tab for that project.

The project homepage is optional and will fall back to the globally set default new tab.

Automatically scroll newly added bookmarks and environments into view

When you add a new bookmark or environment to a project, the project editor now automatically scrolls the newly added item into view. This makes it much easier to see what you just added, especially when you have a long list of bookmarks or environments.

Syncing improvements

Polypane's syncing engine is the most robust and complete one out there, syncing everything from scroll position to hover and focus states. But there's always room for improvement.

In Polypane 30 we added syncing for text selection and reset buttons.

Text selection syncing

Your text selection is now synced across panes and portal-connected browsers.

So if you select text, that text is now selected everywhere. Neat!

Reset button syncing

We prevented button clicks from syncing if they were inside forms to prevent duplicate form submissions, but the way we set it up also prevented reset buttons from syncing. If you were working on a form and were counting on resetting the form in one go, that wouldn't work.

You probably shouldn't be using reset buttons as they're not great for UX, but if you do, they now sync across panes and portal-connected browsers. The benefit is that your form state resets everywhere.

Area screenshot improvements

Creating area screenshots is now much easier. Every measurement area you draw has its own camera icon that lets you capture that area.

Previously you had to draw a measurement area and then go to the camera menu to screenshot it. Now you can just click the camera icon to take a screenshot of that area.

Smaller improvements

For the full list there's the changelog below, but we wanted to call out a few smaller improvements that we think are worth mentioning.

Toggle between last two panel positions

You can now toggle between the last two panel positions with a new shortcut ⌘ ⌥ p. For example, you can toggle between the right-aligned and bottom-aligned panel with a single shortcut, or detach and reattach the panel.

Address bar interactions

The address bar, I keep learning, is surprisingly complex. Its text selection logic now follows other browsers:

Click + drag selects text instead of focusing the entire content
Click once selects the entire content
Click again to place the cursor at the clicked position
Double-click selects the word, and triple-click selects the entire content again

We've also updated the logic on when to start showing suggestions to align with other browsers, only starting to show suggestions after the user has started typing.

Automatic layout choice for JSON files

When you drag a JSON file to the tab bar and open it in a new tab, Polypane now automatically opens it in the full layout instead of your default layout.

Emoji picker update

The emoji picker we use in the screenshot editor and project selector now uses Emoji 17.0, so you can use the latest emojis in your screenshots and projects.

The context menus now let you copy email addresses without the mailto: part, telephone numbers without the tel: part, and you can now copy or save a video frame from any video.

Chromium 152

Polypane 30 is built on Chromium 152. For all the experimental features enabled in this release, check out the experimental web platform features overview.

Get Polypane 30

Polypane is available for Windows, Mac, and Linux in 64-bit and ARM versions. Polypane automatically updates, but you can also go to the download page to download the latest version!

Don't have Polypane yet? There is a 14-day trial available.
Try it for free. No credit card needed.

Polypane 30 Changelog

New

New Polypane Playgrounds
New Video recording supports sound and improved performance
New Extensions: Side Panel extension support
New Network panel: filter requests
New Network panel: sort by all requests or per origin
New Emulation: svh difference overlay is now on by default
New Emulation: text-scale emulation support
New Emulation: Pixel and iPhone device previews
New Elements panel: Support commandForElement display in DOM tree (Thanks Rik!)
New Projects can now have project-specific default tabs (Thanks Silas!)
New Syncing engine: Synced text selection
New Meta panel: Standard Site validation and previews
New Chromium 152

Improvements

Improved Faster startup-time due to Electron improvements
Improved A roughly 20% performance improvement due to Electron improvements
Improved Network panel: hover initiator to highlight the request that initiated it (Thanks Matija!)
Improved Meta panel: Head order overview now recognises viewport-fit as valid value
Improved Meta panel: Redesign layout and add text-scale
Improved Meta panel: Show warnings for incorrectly sized OG images (Thanks Ky!)
Improved Meta panel: Improved fallback suggestions in OG tag lists
Improved Meta panel: Improve Google SERP preview
Improved Meta panel: Show plaintext robots.txt content (to help with comments)
Improved Meta panel: Mastodon preview now checks for verified domain value (Thanks Manuel!)
Improved Meta panel: Update Mastodon preview colors
Improved Outline panel: Faster updating of focus overlay when scrolling and resizing
Improved Outline panel: Faster accessibility tree parsing
Improved Elements panel: Show a warning badge for quirks mode (Thanks Roma!)
Improved Elements panel: The text editor is now resizable (Thanks Bernd!)
Improved Elements panel: Support if() in CSS properties with proper indentation
Improved Elements panel: consistent opening of Elements panel or chromium devtools under one shortcut/menu item
Improved Elements panel: You can now click on pseudo elements in the DOM tree
Improved Elements panel: Newly supported CSS Properties and values
Improved Elements panel: Add support for focusgroup attribute autocomplete
Improved Console panel: Improved performance, better previews and evaluation in main world and portals
Improved Console panel: Element references like $0 now work across shadow boundaries
Improved Console panel: Assignments are now kept in scope
Improved Accessibility overviews now provide additional information for properties on hover
Improved Accessibility overviews now hide irrelevant properties depending on the element role (Thanks Christian, Eric, Manuel, Sara, Jules and Ronny!)
Improved Peek: Turn touch emulation off when inspecting with Peek (Thanks Marc!)
Improved Peek: Show values of aria-current, aria-pressed and aria-expanded if defined (Thanks Eric!)
Improved New tab: now open with the last used layout
Improved Rendering: the 'in-polypane' class is now off by default
Improved Extensions: automatically open chrome-extension links in full layout
Improved Extensions: Support extension id substitute strings in CSS
Improved Extensions: Correctly support browser namespace in extensions
Improved Extensions: support for tabCapture APIs (Thanks Kathryn!)
Improved Extensions: Support for KeePassXC extension (Thanks Mateus!)
Improved Extensions: Decrease logging in the terminal
Improved Panes: now zoom out to fit in horizontal and focus layouts instead of clipping (Thanks Brady!)
Improved Panes: Cmd/Ctrl + dragging now scales panes
Improved Panes: Shift + scale now follows the larger side when resizing
Improved Image overlay: renamed from reference image
Improved Debug overlays: Renamed from Debug tools
Improved Debug overlays: Improved performance for contrast checker, text spacing, z-index and disable * debug tools
Improved Shortcuts: toggle Panel between last two positions (Thanks Bas!)
Improved Shortcuts: Esc no longer removed focus from pane (Thanks Eric!)
Improved All file size notations across the app now use the same SI 1000-base units
Improved Context menus: Now detect email address and phone numbers for easy copying
Improved Context menus: Copy and save video frame options
Improved Panel: Automatically update tab widths for larger text sizes (Thanks Ashlee!)
Improved Syncing engine: Reset buttons are now synced across panes
Improved Project editor: Automatically scroll newly added bookmarks and environments into view (Thanks Eric!)
Improved Screenshots: Improve performance of full-page screenshots for very long pages (Thanks Brad!)
Improved Rulers: Measure areas now have a camera icon to create screenshots of the measured area
Improved Address bar: You can now click + drag to select text, instead of it focusing the entire content (Thanks Rick!)
Improved Emoji picker: Now supports Emoji 17.0
Improved Polypane Peek: disables scroll syncing on inspect
Improved Dragged-in JSON files automatically open in full layouts
Improved JSON and XML viewers: improve dark mode styling
Improved Passkey support should now work with more authentication methods
Improved Updated list of Google Fonts

Removed

Removed Meta panel: The "mobile friendly" check is removed as it's no longer used by search engines (Thanks Robbert!)
Removed A11y.css is now available as a snippet and no longer part of the Debug overlays

Fixes

Fix Meta panel: Whatsapp card was missing title
Fix Meta panel: Opening a new tab no longer resets preview order
Fix Network panel: Sort origins by first connection time, rather than last activity (Thanks Matija!)
Fix Network panel: Web Vitals data was cleared when switching tabs (Thanks Matija!)
Fix Network panel: Prevent resetting of size bars
Fix Elements panel: Fix missing computed styles for some websites (Thanks Matija!)
Fix Elements panel: Properly expand attribute value fields for long values
Fix Elements panel: Show nested declarations in @scope rules (Thanks Rick!)
Fix Peek: the color preview for color-mix() was broken (Thanks Marc!)
Fix Pane URL bar: prevent selecting a preset on enter and applying URL on blur
Fix Polypane Message Bus: Message bus is now available again
Fix Console panel: Prevent console from getting its element references from different tab
Fix Reference image: Properly support non-ascii characters (Thanks Sigmundur!)
Fix Panes: Fix sizer position for zoomed out panes
Fix Debug overlays: Disable Images now correctly restores when turned off
Fix Debug overlays: Right-click no longer re-applies debug overlays twice
Fix Address bar: Pressing enter on an empty address bar no longer submits
Fix Address bar: Make sure the address bar doesn't overlap warning icons (Thanks Vadim!)
Fix Outline panel: Focus overlay correctly ignores tabindex=-1 elements for comparisons
Fix Outline panel: styling issue fixes for warnings and indicators
Fix Screenshots: Fix issue where images weren't saved to disk directly
Fix Screenshots: Prevent visual glitch when taking a full height screenshot
Fix Screenshots: Prevent silent error when trying to save to a non-existent folder
Fix svh and safe area insets now redraw faster during resize
Fix Google Fonts import didn't use variable fonts
Fix Extensions: Automatically support default permissions for all extensions
Fix Middle click ruler button on full layout now clears the rulers
Fix Portal only syncs events from the portalled tab
Fix Portal syncs non-tab originated navigation events again
Fix Focus overlay now only uses tabbable elements for tab order validation instead of all focusable elements (Thanks Eric!)

Cheatsheets for flex, grid, anchor positioning and invoker commands

Mon, 27 Jul 2026 00:00:00 GMT

For CSS Day this year we created a set of cheatsheets explaining Flexbox, Grid, Anchor positioning and Invoker commands.

They came out beautifully and a lot of people really liked them at our booth, so we decided to make them available as free downloads at polypane.app/cheatsheets.

CSS Day swag

This year we had a booth at CSS Day in Amsterdam, and it was a ton of fun to talk to so many Polypane users (the crowd as well as the speaker line-up was full of them!) and to meet so many people for who Polypane was new and who were excited to try it out.

Of course we made sure to bring stickers, badges and pins, but for our booth at CSS Day we also wanted to create some swag that wasn't just 'thing with our logo', but something that you'd actually want to keep and use.

Having recently struggled a lot with Anchor positioning and always forgetting the exact syntax for Grid areas made those easy topics to pick because, if nothing else, we would find them useful ourselves.

Flex to go along with Grid and the very exciting new Invoker commands were natural choices to go along with those two, so that's how we ended up with the four cheatsheets we made.

Photo by Richard Theemling for CSS Day

The cheatsheets aren't Polypane-specific, they're just nice-looking references for these topics that (for the print versions) you can keep on your desk and refer to for a quick lookup of 'how to do that thing again'.

Photo by Richard Theemling for CSS Day

The cheatsheets

We had the cheatsheets printed on very nice card stock with a matte finish and rounded corners and wanted to make sure at least some of that came across in the online version, so as you pick one of the cards on polypane.app/cheatsheets you'll see a nice rendering of the card with the same matte finish as you mouse over it. Definitely recommend checking out that page (and bookmarking it for later) if you want to see the cards in all their glory.

If you just want to download them, you can scroll down to download them directly from this page. All downloads are free and print-ready (they have a 3mm bleed and are in A5 format).

Want them printed and shipped to you?

We're planning on making them available as printed A5 cards in the future, so if you'd like to be notified when that happens, please sign up for our newsletter and we'll let you know when they're available.

Or catch us at a conference and we'll be happy to give you a set of printed cards for free!

Got suggestions?

If you have any suggestions for other cheatsheets you'd like to see, or if you have any feedback on the ones we made, please let us know!

Experimenting with the new pure CSS random() function

Wed, 24 Jun 2026 00:00:00 GMT

CSS is getting a random() function that lets you set properties with a random value, opening up a ton of interesting creative possibilities. In this article, I’m taking an early look at the function to see how it works and where the gotchas are (and there are a few) and really putting it through its paces.

I built seven different demos that you can play around with and edit yourself in the interactive examples below: bokeh, falling petals a stack of fling-able polaroids, a visual poem, a shaky grid, rotating rectangles and finally, recreating an aurora.

You probably don’t want your UI to be random every time someone loads the page. There are plenty of places where a little randomness, in for example a small animation, on a button click or something as simple as how a popup appears, can elevate the entire experience. Having it be easily accessible in CSS is really exciting, and a big win for designers and developers alike. The demos here are big and highly visual to show off the possibilities, I hope they inpire you to think about how you can use randomness in your own designs.

A note on the code examples

We're using random() directly in the code examples below, and don't have a fallback for browsers that don't support it yet. If you want to see the examples in action, you can get Polypane and try it for free.

The code examples have fully editable CSS, but only show the relevant CSS for each effect (for example the bokeh below does show the positioning, but not the border-radius).

You can edit the CSS in the examples to see how it works. In the code example we only show the most relevant CSS, but if you copy the code you'll get the full HTML and CSS for the example. Click the 'randomize' button to reload the example with a new random value for each property.

A note on browser support

We're using random() directly in the examples below without fallbacks, so many of these demos currently only work properly in Polypane, which we used to build and test them. Chromium 148+ also supports random() behind the Experimental Web Platform Features flag. Safari 26.2+ has partial support and several demos do not work correctly there yet. Safari 26.2+ support random(), but doesn't fully support all the demos I show in this article. Firefox currently has no support for random().

For the best experience, including the editable live demos and the most complete implementation, open this article in Polypane 29+ and try the examples yourself.

Some demos may behave differently or fail entirely outside Polypane right now. We'll keep the article updated as the spec and implementations evolve. If you're in the future right now and notice some of the demos no longer work, please let us know and we'll update the article!

My first experiment: Bokeh effect

I first learned about the availability of random() in browsers when I saw it listed in the newly available experimental features in Chromium 148, as I was implementing that in Polypane 29. Whenever I think of visual randomness, bokeh is the first thing that comes to mind.

Bokeh is a photography effect that creates out-of-focus light spots, and I find it absolutely mesmerizing to look at. I thought it would be fun to try to create a bokeh effect using random(). So I grabbed the MDN page on random() and got to work.

If you look at a bokeh effect, it's essentially a bunch of circles that differ in a few ways:

the position of the circles
the size of the circles
the color of the circles
the out-of-focus-ness of the circles
the rate at which they change (if it's an animated bokeh)

Position

The position of the circles is easiest: set them to position:absolute, and then use random() in the left and top properties. This will place the circles at random positions:

.bokeh {
  position:absolute;
  left: random(0%, 100%);
  top: random(0%, 100%);
  border-radius: 100%;
}

.bokeh {
  position:absolute;
  left: random(0%, 100%);
  top: random(0%, 100%);
  border-radius: 100%;
}

The CSS in these examples is live and interactive. Want to experiment with these examples live? Open this article in Polypane.

The random() function in its simplest form takes a minimum (0%) and a maximum (100%) and returns a random value between those values.

Note: The minimum size here is 0, but it has to include the % to make sure both values are of the same type. If you just put random(0, 100%), it would be invalid because the minimum is a <number> and the maximum is a <percentage>.

Size

Each circle in a bokeh effect has a different size, but it's still a circle. So if we want to use random() to set the size, we need to make sure that the width and height are the same value.

My idea was to 'store' the random value in a custom property (like --size: random(50px, 20vmin)) and then use that custom property for both the width and height. That way, the width and height will always be the same value.

Or so I thought.

.bokeh {
  left: random(0%, 100%);
  top: random(0%, 100%);

  --size: random(50px, 20vmin);
  width: var(--size);
  height: var(--size);
}

.bokeh {
  left: random(0%, 100%);
  top: random(0%, 100%);

  --size: random(50px, 20vmin);
  width: var(--size);
  height: var(--size);
}

Yikes, width and height are different!

When you set a custom property to a random value, it will generate a new random value every time you use that custom property, not just when you declare it.

To fix this, we have to add a custom keyword to the random function called element-scoped.

This tells the browser to generate one random value per element. So each element gets a different random value, but the width and height of each element will be the same:

.bokeh {
  top: random(0%, 100%);
  left: random(0%, 100%);

  --size: random(element-scoped, 50px, 20vmin);
  width: var(--size);
  height: var(--size);
}

.bokeh {
  top: random(0%, 100%);
  left: random(0%, 100%);

  --size: random(element-scoped, 50px, 20vmin);
  width: var(--size);
  height: var(--size);
}

Note: element-scoped is not the final name for this feature, but it's the one currently supported in Polypane and Safari. It will be renamed to per-element. Neither is yet part of the MDN docs, though a PR has been submitted to add it.

Position, revisited

I wanted to start with the position because it was simplest, but the position actually has an issue: if a circle starts at 99% from the left and has a size of 100px, it will overflow the container and cause scrollbars.

To fix this, we can use calc() to subtract the size of the circle from the position:

.bokeh {
  left: random(0%, calc(100% - var(--size)));
  top: random(0%, calc(100% - var(--size)));

  --size: random(element-scoped, 50px, 20vmin);
  width: var(--size);
  height: var(--size);
}

.bokeh {
  left: random(0%, calc(100% - var(--size)));
  top: random(0%, calc(100% - var(--size)));

  --size: random(element-scoped, 50px, 20vmin);
  width: var(--size);
  height: var(--size);
}

We don't know exactly what the size of the circle is, but because --size is the same for this element in each property, we can use it to be sure that the circles are always fully within the container.

The color of the circles

For the colors of the circles, I wanted all of them to be roughly the same lightness and saturation, but each circle to have a different hue. So I used the hsl() function with random() for the hue value.

Additionally, when you look at images of bokeh, some circles are more visible and some are less visible. So I also added a random opacity:

.bokeh {
  left: random(0%, calc(100% - var(--size)));
  top: random(0%, calc(100% - var(--size)));
  --size: random(element-scoped, 50px, 20vmin);
  width: var(--size);
  height: var(--size);

  background: hsl(random(0, 360) 80% 50%);
  opacity: random(0.1, 1);
}

.bokeh {
  left: random(0%, calc(100% - var(--size)));
  top: random(0%, calc(100% - var(--size)));
  --size: random(element-scoped, 50px, 20vmin);
  width: var(--size);
  height: var(--size);

  background: hsl(random(0, 360) 80% 50%);
  opacity: random(0.1, 1);
}

The hue in HSL is just a number, so it doesn't need a unit. The same goes for opacity.

Note: We've increased the number of circles in this and the next few examples so the effect is more clearly visible.

Out-of-focus-ness

Next up, some of the circles in a bokeh image are really sharp while others are more blurry.

In CSS, we can achieve a blur effect with the filter: blur() function. When you add a blur you also lose some of the vibrancy that some of the colors have, so I also added a contrast() filter to make some of the circles more vibrant.

Lastly, I added a mix-blend-mode to make the circles blend together using "plus-lighter", That increases the brightness of the circles where they overlap, which makes it look more like real bokeh:

.bokeh {
  filter: blur(random(2px, 6px)) contrast(random(50%, 200%));
  mix-blend-mode: plus-lighter;
}

.bokeh {
  filter: blur(random(2px, 6px)) contrast(random(50%, 200%));
  mix-blend-mode: plus-lighter;
}

That blur helps make the circles look more like actual bokeh circles, and the contrast makes some of them look more vibrant and some of them look more dull, which adds to the effect.

For contrast we specifically chose a range where most random values would increase the contrast (the 100% to 200% range) and only a handful of circles would have a contrast value that decreases the contrast (the 50% to 100% range).

Animation

Finally, I wanted to add some animation to the bokeh circles. When you look at bokeh through a camera and you increase and decrease the focus, some circles become larger and more blurry, while others become smaller and sharper.

The easiest way to do that is with a simple pulse animation. We only need to define the 50% keyframe. The 0% and 100% keyframes will be the default state of the element (a scale of 1).

@keyframes pulse {
  50% {
    scale: 1.2;
  }
}

We can re-use this same animation for all circles, because we can set the animation timing and the animation delay to a random value for each circle. This way, each circle will pulse at a different rate and start at a different time, which makes the animation look more natural:

.bokeh {
  animation: pulse random(2s, 5s) ease-in-out infinite;
  animation-delay: random(-5s, 0s);
}

We let the animation run infinitely so it just keeps looping with an ease-in-out timing function to smooth out the start and end of each pulse. By setting a random negative delay, some circles will start the animation somewhere in the middle, which makes it look more natural as you refresh the page. If we only used no delay or a positive delay, all circles would start their animation by growing.

Combining it all

So when we combine all of these properties together, we get this:

.bokeh {
  filter: blur(random(2px, 6px)) contrast(random(50%, 200%));
  mix-blend-mode: plus-lighter;
  animation: pulse random(2s, 5s) ease-in-out infinite;
  animation-delay: random(-5s, 0s);
}

@keyframes pulse {
  50% {
    scale: 1.2;
  }
}

.bokeh {
  filter: blur(random(2px, 6px)) contrast(random(50%, 200%));
  mix-blend-mode: plus-lighter;
  animation: pulse random(2s, 5s) ease-in-out infinite;
  animation-delay: random(-5s, 0s);
}

@keyframes pulse {
  50% {
    scale: 1.2;
  }
}

Note For animations like the one above that have animations, we show a "show demo" button to activate the preview, for two reasons: 1) the animation can be distracting or annoying and 2) it can be performance-intensive.

Falling flower petals

We have a cherry tree in our backyard, and when the wind blows in spring, the petals fall off the tree and float down to the ground. It's very soothing.

I thought it would be fun to try to recreate that effect using random(), and lets front-load the final animation so you can see what we're trying to achieve:

Note In Safari sometimes you don't see any petals in the demos. If that happens, click randomize a few times. I don't know why this happens, but it seems to be a Safari bug.

Lets look at what parts need to be random to achieve this result.

The petals all need to start at a different position off-screen
They should all be a slightly different size and should look a little different
They all need to move vaguely in the same direction as if blown by the wind, but each petal should fall slightly differently
They should fall at different speeds
They should randomly twirl as they fall

Starting position

The starting position of each petal should be above the current viewport, and then randomly across the width of the viewport so that they each fall from a different place.

For the top value we can use a fixed one so they all start at the same place, and then for the horizontal starting value, we'll use a custom property, since we're going to reuse it once we get to the falling animation.

We'll use element-scoped so that each petal has a different starting position, and we're not going to set left, but translate because we want to animate the petals falling down the screen, and animating translate is more performant than animating left:

.petal {
  position: absolute;
  top: -100px;
  --initial-position: random(element-scoped, -40vw, 100vw);
  translate: var(--initial-position) 0;
}

We'd show a demo, but they all start off-screen and don't animate, so you wouldn't see anything. That's our starting position sorted, lets move on to size and shape.

Size and petal style

For the size, lets use aspect-ratio instead of an explicit width this time so we can keep things simple:

.petal {
  width: random(30px, 50px);
  aspect-ratio: 1/1;
}

For the petals themselves I found four different petals by Pram Samnak that I liked and wanted to randomly pick one from.

Theoretically you would be able to use random-item() to randomly pick one of the four petals, but that function is not yet implemented in any browser. It would look like this, if it worked:

.petal {
  background-image: random-item(url(petals/1.png), url(petals/2.png), url(petals/3.png), url(petals/4.png));
}

I had to think a while on how to get around this, and I ended up realising that if each petal starts at a random place I could just use nth-child,

The repeating pattern of the nth-child() selector wouldn't be noticeable since each petal starts at a random position.

All of this still happens off-screen so there's no demo. Let's quickly add the falling animation and see something!

Falling animation

When petals fall down they also get pushed around by the wind, so they don't fall straight down. To achieve this, we can animate translate and move the petals down and to the right.

Because each petal catches the wind differently, we want them to fall at different speeds and at different angles. For the speed, we can vary the duration of the animation. For the angle we can set an end value for the translate that takes the --initial-position that we already had, and add a random amount.

.petal {
  --initial-position: random(element-scoped, -40vw, 100vw);
  --end-position: calc(var(--initial-position) + random(20vw, 50vw));

  translate: var(--initial-position) 0;
  animation: fall random(5s, 10s) linear infinite;
  animation-delay: random(-10s, 0s);
}

@keyframes fall {
  to {
    translate: var(--end-position) calc(100vh + 100px);
  }
}

.petal {
  --initial-position: random(element-scoped, -40vw, 100vw);
  --end-position: calc(var(--initial-position) + random(20vw, 50vw));

  translate: var(--initial-position) 0;
  animation: fall random(5s, 10s) linear infinite;
  animation-delay: random(-10s, 0s);
}

@keyframes fall {
  to {
    translate: var(--end-position) calc(100vh + 100px);
  }
}

Just like with the bokeh example, Each petal has a different timing and we set a negative delay so that some petals start in the middle of their animation, which makes it look more natural as you load the page.

We only have to set the to keyframe to the end position at the bottom of the screen. When the petal leaves the screen, it jumps back to the top and starts falling again, creating a continuous effect.

Twirling animation

To achieve the idea of the petals twirling in 3D, we scale them randomly as they fall as if they are moving closer and further away from the camera, and we rotate them along the X, Y and Z axis.

We use two separate animations for that, so we can have both of these happen at different random durations and starting times to make a unique animation for each petal.

For the rotation we use transforms with perspective() to get a nicer looking 3D effect on the petals. We also want each petal to twirl at a different speed, so we also use random() in the animation duration.

Lastly, we set the transform-origin to the top center of the element, so that it twirls around that point rather than around the center of the petal.

.petal {
  --initial-position: random(element-scoped, -40vw, 100vw);
  --end-position: calc(var(--initial-position) + random(20vw, 50vw));
  --rotx: random(-45deg, 45deg);
  --roty: random(-45deg, 45deg);

  translate: var(--initial-position) 0;

  animation:
    fall random(5s, 10s) linear infinite,
    rotate random(2s, 4s) linear infinite,
    grow random(2s, 4s) ease-in-out infinite alternate;
  animation-delay: random(-10s, 0s), random(-10s, 0s), random(-10s, 0s);
  transform-origin: top center;
}

@keyframes fall {
  to {
    translate: var(--end-position) calc(100vh + 100px);
  }
}

@keyframes grow {
  to {
    scale: random(1.5, 2);
  }
}

@keyframes rotate {
  from {
    transform: perspective(300px) rotateY(var(--roty)) rotateZ(-30deg) rotateX(var(--rotx));
  }
  to {
    transform: perspective(300px) rotateY(calc(var(--roty) + 360deg)) rotateZ(330deg)
      rotateX(calc(var(--rotx) + 360deg));
  }
}

.petal {
  --initial-position: random(element-scoped, -40vw, 100vw);
  --end-position: calc(var(--initial-position) + random(20vw, 50vw));
  --rotx: random(-45deg, 45deg);
  --roty: random(-45deg, 45deg);

  translate: var(--initial-position) 0;

  animation:
    fall random(5s, 10s) linear infinite,
    rotate random(2s, 4s) linear infinite,
    grow random(2s, 4s) ease-in-out infinite alternate;
  animation-delay: random(-10s, 0s), random(-10s, 0s), random(-10s, 0s);
  transform-origin: top center;
}

@keyframes fall {
  to {
    translate: var(--end-position) calc(100vh + 100px);
  }
}

@keyframes grow {
  to {
    scale: random(1.5, 2);
  }
}

@keyframes rotate {
  from {
    transform: perspective(300px) rotateY(var(--roty)) rotateZ(-30deg) rotateX(var(--rotx));
  }
  to {
    transform: perspective(300px) rotateY(calc(var(--roty) + 360deg)) rotateZ(330deg)
      rotateX(calc(var(--rotx) + 360deg));
  }
}

To finish it off, we got a nice background image as a background.

A stack of Polaroids you can fling away

For the third example, I want to create an "untidy" stack of Polaroid photos, where they're all slightly rotated and offset from each other to create a natural looking pile. Additionally, i wanted to fling them in random directions when you click on them.

Let's look at how we can add interactivity to our randomness!

Building the stack

The easiest way to create a stack of elements is to use CSS Grid and place all the elements in the same grid cell:

.container {
  position: absolute;
  margin: 0;
  inset: 0px;
  display: grid;
  grid-template-columns: 1fr;
  place-items: center;

  .polaroid {
    grid-area: 1/1/2/2;
  }
}

And then we can style each polaroid. This time they all have the same dimensions but it's the transform that we're going to use to add some randomness.

The HTML structure of each polaroid looks like this:

<div class="polaroid">
  <div class="img">
    <img src="polaroids/1.jpg" alt="" />
  </div>
</div>

Because of the grid they're already all stacked in the same position on top of each other. We can use random() in the transform property to rotate and offset each card randomly:

.polaroid {
    grid-area: 1 / 1 / 2 / 2;
    position: relative;
    background: #f9f0db;
    border-radius: 3px;
    box-shadow: 0 0 10px rgba(0, 0, 0, 0.2);
    width: min(400px, 82vw);
    aspect-ratio: 2.1 / 2.5;
    padding: 25px;
    transform:
      rotate(random(-15deg, 15deg))
      translate(random(-10px, 10px), random(-10px, 10px));
}

.polaroid {
    grid-area: 1 / 1 / 2 / 2;
    position: relative;
    background: #f9f0db;
    border-radius: 3px;
    box-shadow: 0 0 10px rgba(0, 0, 0, 0.2);
    width: min(400px, 82vw);
    aspect-ratio: 2.1 / 2.5;
    padding: 25px;
    transform:
      rotate(random(-15deg, 15deg))
      translate(random(-10px, 10px), random(-10px, 10px));
}

The transform here takes care of the entire effect: rotate it randomly between -15 and 15 degrees, and then translate it randomly by up to 10 pixels in both directions. This creates a nice "messy" stack of polaroids.

Adding interactivity

For the interactivity, we need to be able to set a state for each card when we click on it, and ideally we also want a way to reset the cards back to their original position.

Each card gets a checkbox that we overlay on top of the card:

<div class="polaroid">
  <div class="img">
    <img src="polaroids/1.jpg" alt="" />
  </div>
  <input type="checkbox" />
</div>

The CSS to make sure the checkbox is invisible and covers the entire card:

.polaroid {
  input {
    position: absolute;
    inset: 0px;
    opacity: 0;
    cursor: pointer;
  }
}

That gives us a :checked state for each card that we can use, but to uncheck it, we need to click each card separately again. If we want to be able to reset all cards at once, we're going to need use the platform.

By wrapping all the checkboxes in a <form>, we can use the native reset behavior of the form to uncheck all the checkboxes at once when we click the reset button.

By placing the reset button before the cards in the same grid stack, it will appear when the last polaroid is flung away:

<form>
  <button type="reset">Stack them back up</button>
  <div class="polaroid">
    <div class="img">
      <img src="polaroids/1.jpg" alt="" />
    </div>
    <input type="checkbox" />
  </div>
  <div class="polaroid">
    <div class="img">
      <img src="polaroids/2.jpg" alt="" />
    </div>
    <input type="checkbox" />
  </div>
  <!--- etc -->
</form>

A note on accessibility: This is not an accessible form and should not be used as-is in production. This is just a demo to show how you can use the :checked state of a checkbox and the reset feature of a form to trigger animations.

Now we can use the :checked state of each checkbox to trigger an animation that flings the card away in a random direction.

.polaroid {
    transition: transform 0.33s ease-in-out;

    &:has(input:checked) {
      pointer-events:none;
      transform:
      translate(random(-50vw, 50vw), -70vh)
      rotate(random(-120deg, 120deg));
    }

    &:has(input:active) {
      transform: scale(1.2);
    }
  }

.polaroid {
    transition: transform 0.33s ease-in-out;

    &:has(input:checked) {
      pointer-events:none;
      transform:
      translate(random(-50vw, 50vw), -70vh)
      rotate(random(-120deg, 120deg));
    }

    &:has(input:active) {
      transform: scale(1.2);
    }
  }

When a card is checked, it's translated to a random position near the top of the screen and rotated by a random amount to make it look like it's being thrown. As you click a card we use :has(input:active) to scale the card up slightly so it looks like you're picking it up, and then when you release the mouse button, it flies away and scales back down to its original size.

When we click the reset button, all checkboxes are unchecked and all cards return to their original position in the stack.

Ordering

Now a keen eye might see that each item on the stack is flung below the previous one, which is what you expect from the HTML structure, but isn't exactly how a real stack of polaroids would work.

In a real stack, the latest polaroid to flung away would land on top of the other ones, not below them.

We can fix that with some clever use of animation values to store the time you clicked each polaroid and append that to the z-index (so the last clicked is always highest), but we're going to leave that out-of-scope for this article.

Let us know if you want to see a follow-up article where we go into how to do that!

Designing a poem with `random-item()`

I had this idea of a poem where I would randomly start words on a new line or with different offsets, just like some visual poems do. Something like display: random-item(block, inline-block) would be perfect for that.

But random-items() doesn't exist yet.

As I was watching Kevin Powell at CSS Day show off how he uses if() in CSS, I realised we could combine random() with style queries in an if() function to get a similar effect.

Note the if() function is not supported in Safari yet, so the demos below won't work there.

random() gives you a value between two numbers, but if you want to get a random value like display: block or display: inline-block, you can't do that directly.

What you can do is use the step value in random() to create an integer value between 1 and 0, and use that as a toggle in an if() function.

Using the step value in `random()`

If you add a third value to the random function, it will only return values that are a multiple of that value.

If we set the step value to 1, it will only return whole numbers. If we also set the minimum to 0 and the maximum to 1, it will only return either 0 or 1.

Then we can use @property to cast that to an <integer>, and use that as a toggle in an if clause:

@property --discrete-number {
  syntax: '<integer>';
  inherits: false;
  initial-value: 0;
}

span {
  --discrete-number: random(0, 1, 1);
  display: if(style(--discrete-number: 1): inline-block; else: block;);
}

Combining that, we can essentially recreate random-item(). For example, if we wanted to randomly pick a different petal for our falling petals demo instead of looping through them, it would look like this:

@property --discrete-number {
  syntax: '<integer>';
  inherits: false;
  initial-value: 0;
}

.petal {
  --discrete-number: random(0, 3, 1);
  background-image: if(
    style(--discrete-number: 0): url(petals/1.png) ; style(--discrete-number: 1): url(petals/2.png) ;
      style(--discrete-number: 2): url(petals/3.png) ; style(--discrete-number: 3): url(petals/4.png) ;
  );
}

That's not too bad, is it!

Styling the poem with discrete random values

With this implemented I build a little demo of a poem where each word is randomly offset and randomly set to either display: block or display: inline-block to create a more interesting layout:

@property --discrete-number {
  syntax: "<integer>";
  inherits: false;
  initial-value: 0;
}

.poem span {
  --discrete-number: random(0, 1, 1);
  display: if(
    style(--discrete-number: 1): inline-block;
    else: block;
  );
}

@property --discrete-number {
  syntax: "<integer>";
  inherits: false;
  initial-value: 0;
}

.poem span {
  --discrete-number: random(0, 1, 1);
  display: if(
    style(--discrete-number: 1): inline-block;
    else: block;
  );
}

Refreshing that demo a bunch of time I realised that with this discrete number, I had a 50/50 chance of a word being on a new line or not. That didn't look great.

I wanted to have more control over those odds, i wanted to be able to say "I want 70% of the words to be display: inline-block and only 30% to start on a new line".

Weighted random values

By increasing the max value to 10 and then using a style query that checks if the value is above or below 3, we can achieve that:

span {
  --discrete-number: random(0, 10, 1);
  display: if(style(--discrete-number > 3): inline-block; else: block;);
}

Currently, the proposal for random-item() does not include a way to weight the odds of each item being selected. That would be very useful though, so I opened an issue on the CSSWG repo. If you want to see that feature implemented, please go and comment on that issue.

A visual poem

Using that weighed value we can set a number of options based on that single discrete number and use different weighting for each value.

This ended up being a fun way to create a visual poem where each refresh puts the emphasis on different aspects of the same poem:

@property --discrete-number {
  syntax: "<integer>";
  inherits: false;
  initial-value: 0;
}

.poem span {
  --discrete-number: random(0, 10, 1);
  display: if(
    style(--discrete-number > 2): inline-block;
    else: block;
  );
  margin-left: if(
    style(--discrete-number < 2): random(0rem, 6rem);
    else: 0;
  );
  font-weight: if(
    style(--discrete-number > 5): random(400, 800);
    else: 400;
  );
}

@property --discrete-number {
  syntax: "<integer>";
  inherits: false;
  initial-value: 0;
}

.poem span {
  --discrete-number: random(0, 10, 1);
  display: if(
    style(--discrete-number > 2): inline-block;
    else: block;
  );
  margin-left: if(
    style(--discrete-number < 2): random(0rem, 6rem);
    else: 0;
  );
  font-weight: if(
    style(--discrete-number > 5): random(400, 800);
    else: 400;
  );
}

We can even use random inside the if clause, so there is a higher chance of a word being on a new line, but if it is on a new line, it also has a random chance of being offset by a random amount.

More demos

I have a few more demos that I created but this article is already quite long and covered most of what I wanted to show, so I'll just show the additional demos below.

Make sure to also check out Randomness in CSS by Alvaro Montoro. Some of the terminology has already changed since that article, but it takes a more descriptive approach at introducing the new function that you might like.

Shaky Grid

No animation here, but I thought it would be fun to create a shaky grid pattern where each line is slightly offset and rotated.

.line {
  transform:
    scale(1.5)
    rotate(random(-10deg, 10deg))
    skew(random(-10deg, 10deg), random(-10deg, 10deg));
}
.vertical .line {
  width: random(5px, 10px);
}

.horizontal .line {
  height: random(5px, 10px);
}

.line {
  transform:
    scale(1.5)
    rotate(random(-10deg, 10deg))
    skew(random(-10deg, 10deg), random(-10deg, 10deg));
}
.vertical .line {
  width: random(5px, 10px);
}

.horizontal .line {
  height: random(5px, 10px);
}

Randomly rotating rectangles

This was sort of a step-up to the petal example. Each rectangle sits inside a grid area and is randomly rotated and offset. The animation is continuous.

.tile {
  width: random(25%, 75%);
  height: random(25%, 75%);
  border-radius: random(10px, 20px);
  transform-style: preserve-3d;
  --rotx: random(-25deg, 25deg);
  animation: rotate random(5s, 10s) linear infinite;
  animation-delay: random(-5s, 0s);
}

@keyframes rotate {
  from {
    transform: perspective(500px)rotateY(0deg) rotateZ(-30deg);
  }
  to {
    transform: perspective(500px) rotateY(360deg) rotateZ(330deg);
  }
}

.tile {
  width: random(25%, 75%);
  height: random(25%, 75%);
  border-radius: random(10px, 20px);
  transform-style: preserve-3d;
  --rotx: random(-25deg, 25deg);
  animation: rotate random(5s, 10s) linear infinite;
  animation-delay: random(-5s, 0s);
}

@keyframes rotate {
  from {
    transform: perspective(500px)rotateY(0deg) rotateZ(-30deg);
  }
  to {
    transform: perspective(500px) rotateY(360deg) rotateZ(330deg);
  }
}

Aurora

This one is quite interesting because it uses a few @property declarations to make things like the length portion of a linear gradient offset configurable.

It is however very similar to the bokeh example in terms of how the style is achieved, and it's also quite a bit more resource intensive. Dig in and play around with it, but be aware that it might be a bit heavy on your CPU.

Note This demo doesn't work well in Safari, presumably because it's using random() inside animations.

 @property --skew {
  syntax: "<angle>";
  inherits: true;
  initial-value: 0deg;
}

@property --length {
  syntax: "<percentage>";
  inherits: true;
  initial-value: 100%;
}

.beam {
  background: linear-gradient(
    to bottom,
    hsl(random(100, 280) 100% 50%),
    hsl(random(100, 280) 50% 0%) var(--length)
  );

  mix-blend-mode: plus-lighter;
  filter: blur(8px);
  animation:
    rotate random(3s, 8s) ease-in-out infinite alternate,
    grow random(2s, 11s) ease-in-out infinite alternate,
    move random(8s, 12s) ease-in-out infinite alternate;
  animation-delay: random(-5s, 0s), random(-5s, 0s), random(-8s, 0s);
  transform: perspective(300px) rotateX(20deg) skewX(var(--skew));

}

@keyframes rotate {
  from {
    --skew: random(10deg, 14deg);
  }
  to {
    --skew: random(12deg, 18deg);
  }
}

@keyframes grow {
  from {
    --length: random(20%, 50%);
  }
  to {
    --length: random(40%, 60%);
  }
}

@keyframes move {
  from {
    translate: random(-2vw, 0vw) -10%;
  }
  to {
    translate: random(0vw, 2vw) -10%;
  }
}

 @property --skew {
  syntax: "<angle>";
  inherits: true;
  initial-value: 0deg;
}

@property --length {
  syntax: "<percentage>";
  inherits: true;
  initial-value: 100%;
}

.beam {
  background: linear-gradient(
    to bottom,
    hsl(random(100, 280) 100% 50%),
    hsl(random(100, 280) 50% 0%) var(--length)
  );

  mix-blend-mode: plus-lighter;
  filter: blur(8px);
  animation:
    rotate random(3s, 8s) ease-in-out infinite alternate,
    grow random(2s, 11s) ease-in-out infinite alternate,
    move random(8s, 12s) ease-in-out infinite alternate;
  animation-delay: random(-5s, 0s), random(-5s, 0s), random(-8s, 0s);
  transform: perspective(300px) rotateX(20deg) skewX(var(--skew));

}

@keyframes rotate {
  from {
    --skew: random(10deg, 14deg);
  }
  to {
    --skew: random(12deg, 18deg);
  }
}

@keyframes grow {
  from {
    --length: random(20%, 50%);
  }
  to {
    --length: random(40%, 60%);
  }
}

@keyframes move {
  from {
    translate: random(-2vw, 0vw) -10%;
  }
  to {
    translate: random(0vw, 2vw) -10%;
  }
}

A work in progress

random() in CSS is still very much a work-in-progress. Support across browsers is patchy, the specification is still evolving and there are quite a few bugs (that hopefully I've sneakily worked around in the examples above, while also reporting reduced test cases). Still, having the ability to use randomness in CSS opens up so much new possibilities for creative designs and effects, and i'm really only scratching the surface of what can be done with it.

There are a number of things you can do with random() that I left out:

using custom identifiers to create a random value that is the same across multiple elements
setting different scopes
forcing fixed seed values

Things that I simply didn't find an immediate use-case for (or, to be honest, fully understand).

If you have an idea for a cool use-case for any of those features, or if you want to see a follow-up article where we go into some of those more advanced features, please let us know!

If, like me, you simply want to have a go at some fun and creative experiments with random(), you can get Polypane and play around with it before it lands in normal browsers.

Using safe-area-inset to build mobile-safe layouts

Wed, 06 May 2026 00:00:00 GMT

Modern phones are not simple rectangles. They have rounded corners, camera cutouts, dynamic islands, and home indicators that double as gesture areas. Browsers know the dimensions of all of these and expose the parts that could obscure content as safe area insets.

The "safe area" is the portion of the screen that is guaranteed to be free from being obscured by system UI. The safe-area-inset is the measurement of how much space the system UI is taking up on each edge of the screen. By using these values in your CSS, you can make sure that important content and controls are not obscured by the system UI.

If you don't want your floating chat button to end up sitting behind the home indicator, where it's unreachable, you need to account for the safe area inset.

Environment variables for safe area insets

With the safe-area-inset environment variables, you can make your layout adapt to the current device's safe area and avoid those bugs. The env() function is how you read those values in CSS:

body {
  padding-top: env(safe-area-inset-top);
  padding-right: env(safe-area-inset-right);
  padding-bottom: env(safe-area-inset-bottom);
  padding-left: env(safe-area-inset-left);
}

Browser support

Safe-area-insets are baseline widely available, which means you can use them in production today and be confident that they will work for almost all your users on mobile devices.

Since it's baseline widely available, you don't really need to think about fallbacks but if you want to be extra safe, you can provide a fallback padding if the browser doesn't support env():

body {
  padding-top: 1rem; /* Fallback for browsers that don't support env() */
  padding-top: calc(env(safe-area-inset-top) + 1rem);
}

And for browsers that support env() but not safe-area-inset-* variables, you can provide a fallback value directly in the env() function. If safe-area-inset-top is not supported, it will fall back to 1rem:

body {
  padding-top: env(safe-area-inset-top, 1rem);
}

It's worth noting that this situation is purely theoretical, as all browsers that support env() also support safe-area-inset-* variables. That might not be the case with other environment variables, so it's good to know that this fallback mechanism exists.

Using safe-area-inset values

Before we get into problem areas, let's get a general understanding of how these variables work and how you can use them to affect the layout.

In this demo, change each inset and watch how a realistic mobile UI that takes safe area insets into account shifts to remain usable:

Cutout type

Top inset (44px)

Right inset (0px)

Bottom inset (34px)

Left inset (0px)

OverlayShow safe inset areas

The specific px values here are not particular to any specific device, the point is to show how the device sets these variables and how your layout can respond to them as they change.

On real devices, you can think of these values as constants. They're provided by the browser and while they might change when switching from portrait to landscape or between OS updates that change the device UI as well as simply differ per device, they don't change dynamically as the user scrolls or interacts with the page. The browser provides them as a constant value that you can use to ensure your content is not obscured by the system UI.

Which web pages actually need this?

If you want your pages to look the best they can, all of them.

Browsers by default will prevent your site from being obscured by the notch or home indicator, so your content will be safe without any special handling. That does come with a downside, which is that the browser will give you a smaller viewport to reserve space:

You'll notice the edges here keep the site from being obscured, but they also don't look that great. Ideally we want the content to stretch edge-to-edge, but we want to make sure they're not obscured by system UI. To get that, you need to opt in to the full viewport and handle safe areas yourself.

To do so is a two-step process. First, you need to add viewport-fit=cover to your meta viewport tag:

<meta name="viewport" content="width=device-width, viewport-fit=cover" />

This will make the browser stretch your page edge-to-edge:

As you can see, the content sits behind the dynamic island and home indicator. viewport-fit=cover tells the browser that you want to be responsible for making sure your content is not obscured by the system UI.

And now we can move those elements away from behind the system UI using env(safe-area-inset-*).

.content {
  padding-right: env(safe-area-inset-right);
  padding-left: env(safe-area-inset-left);
}

If you opt into the full viewport, here are the kinds of things you now have to think about to make sure your content is not obscured by the system UI:

Fixed headers and navigation bars should have enough space above or below for the notch/dynamic island/camera punch hole or home indicator
Floating chat or help buttons should remain inside the safe area
Full-screen dialogs and drawers should take up the right height without being obscured by the home indicator
Map or video controls near screen corners

Safe-area-inset doesn't provide margins

Safe-area-insets are defined to be exactly the space that the system UI is taking up. That means they don't provide any margin between the system UI's edge and your content.

If you set padding to just the safe-area-inset value, your content will sit right up against the edge of the safe area, which is right up against the system UI.

To add some breathing room, you can add your own padding on top of the safe area insets by combining things with calc(). This way you can ensure that your content is not only safe from being obscured but also has some space to breathe:

body {
  padding-top: calc(env(safe-area-inset-top) + 1rem);
  padding-right: calc(env(safe-area-inset-right) + 1rem);
  padding-bottom: calc(env(safe-area-inset-bottom) + 1rem);
  padding-left: calc(env(safe-area-inset-left) + 1rem);
}

Safe-area-inset only has non-zero values on mobile devices

env() is supported across browsers and platforms, but the safe-area-inset-* variables really only have non-zero values on mobile devices.

Desktop browsers always return 0 because there is no UI on top of pages in desktop browsers. It's only on mobile devices that these values are non-zero and that you have to account for them.

That's exactly why these bugs are so easy to miss. If you test in the Chrome responsive view, the safe area insets will still be 0 and you won't see any issues during development.

Testing on real devices is often delegated to the end of the project. By then, making layout changes to accommodate safe areas can be expensive, and the bugs can slip through to production. Even worse, they often only affect users on certain devices, so they can go unnoticed for a long time.

Polypane's device emulation supports safe area insets

Polypane is the first and only desktop browser to emulate safe area insets. Every device in Polypane's device emulation has correct safe area inset values for both portrait and landscape orientations.

We added this as part of Polypane 26, along with emulation for small viewport units, another common source of mobile layout bugs.

Here's Polypane showing the safe area insets in blue, and the small viewport height difference in pink:

We're also the only desktop browser to emulate svh, but that's a topic for another article.

With Polypane's safe-area-inset overlay visualization, you can see exactly where the unsafe areas are on each device.

Solving a specific issue: Floating buttons

Let's look at a specific example of how to use safe-area-inset values to solve a common issue: floating buttons that end up behind the home indicator and become unreachable.

Cutout type

Bottom inset (34px)

Right inset (0px)

Button offset (10px)

OverlayShow safe inset areas

Positioning

.chat-button {
  position: fixed;
  right: 10px;
  bottom: 10px;
}

Toggle the positioning between 'Fixed position' and 'Using env()' to switch between hard-coded offsets and offsets that use safe-area-inset-bottom and safe-area-inset-right.

`safe-area-max-inset`

Along with safe-area-inset-*, the specification also describes safe-area-max-inset-* variables. Those are not widely supported yet, but they are worth mentioning because they have slightly different behavior:

safe-area-inset-* gives you the current inset value right now. On scroll, the browser chrome can collapse, and the inset value can shrink all the way to 0. Your element moves with that change.
safe-area-max-inset-* gives you the maximum inset the browser can report for that edge. It stays stable even when the browser chrome collapses. Use it when you want a reserved zone that does not jump around.

inset vs max-inset

Drag or scroll the phone to simulate the browser address bar appearing and disappearing.

The green button uses safe-area-inset-bottom and follows the current inset. The blue button uses safe-area-max-inset-bottom and stays put.

OverlayShow safe inset areas

When to use which really depends on your situation. For some UI components it makes sense to move with the live viewport state, like a floating chat button that should always be just above the home indicator.

For other things, like a persistent cookie banner or a full-screen dialog, it can be better to reserve a stable zone that doesn't shift when the browser chrome collapses so that users don't inadvertently tap the wrong button.

/* Moves with the live viewport state */
.floating-cta {
  bottom: calc(env(safe-area-inset-bottom) + 1rem);
}

/* Holds a stable reserved zone regardless of browser chrome */
.persistent-zone {
  bottom: calc(env(safe-area-max-inset-bottom) + 1rem);
}

Browser support for `safe-area-max-inset-*`

As of now, only Chromium implements safe-area-max-inset-* so there is no support in (mobile) Safari or Firefox. That means you can't depend on it yet and should provide a fallback stack for other browsers:

.bottom-spacer {
  padding-bottom: 1rem;
  padding-bottom: calc(env(safe-area-inset-bottom) + 1rem);
  padding-bottom: calc(env(safe-area-max-inset-bottom, env(safe-area-inset-bottom)) + 1rem);
}

Notice how we're using the env() fallback mechanism to fall back to safe-area-inset-bottom if safe-area-max-inset-bottom is not supported.

Testing safe areas in Polypane

As covered earlier, safe area bugs are easy to miss during development. Chrome's responsive view always reports inset values of 0, and real-device testing tends to get pushed to the end of the project, when fixing layout issues is expensive and bugs have already reached production.

Polypane changes that. You can test safe area insets (and small viewport behavior) directly on your desktop, across multiple devices and orientations simultaneously, as part of your normal development workflow.

Catch real-device layout failures during development, not after shipping.

What to take away

Safe areas are not edge cases for unusual devices. They are the reality of modern mobile devices with camera punch holes, notches, dynamic islands, and home indicator bars. Your users are on those devices, and if you want to give them the best experience, you need to make sure your content is not obscured by the system UI.

Make sure your viewport is set to viewport-fit=cover so you get the full viewport and that you use env(safe-area-inset-*) so all your content is visible and accessible. That gives users the best experience.

Get started with testing safe areas in Polypane today, and catch real-device layout failures during development, not after shipping.

Polypane 29: New network panel, snippet store and Chromium 148

Mon, 04 May 2026 00:00:00 GMT

Polypane 29 introduces an updated panel UI, a new network panel for inspecting requests, a new snippet store for discovering and installing snippets, and a custom selectors overview in the outline panel, plus many other improvements and fixes.

Re-introducing the panel

We redesigned the panel navigation to be more familiar to people coming from other browsers. The new single level with overflow menu is a familiar pattern used in devtools in other browsers, while the drag and drop reordering makes it easy to customize the panel to your own needs.

The old multi-level panel navigation was a bit different from what people were used to, and while it had its advantages, it also made it harder for new users to find the features they were looking for.

With the new design, we hope to make it easier for people to get started with Polypane and also for them to find the many features that Polypane has to offer.

It also made it really easy for us to add a new panel:

Network panel

The new network panel is our take on the network panel. Built from the ground up with Polypane's multi-pane architecture in mind and with a focus on showing you actionable data, the new network panel starts off with a high-level overview of your page's load performance and then lets you drill down.

The top of the network panel is meant for glancing: domContentLoaded and load timing, Web Vitals timings and the number of requests and origins. All of these are shown as ranges when they differ per pane.

Polypane then shows you the origins your page connects to. Each origin has its own performance characteristics, so it's really useful to see this split out.

It can be quite the eye-opener seeing all the origins your page connects to.

Each origin shows a quick overview of the type of connection and number of requests. If you're accidentally connecting to a slow HTTP/1 server, this tells you instantly.

Your main origin is always expanded, showing you how many requests are active, stalled or completed, how many concurrent connections the origin supports and the average download time.

The request table is fully featured and interactive, so you can really dig into the performance characteristics of your page and find bottlenecks and issues.

By default the table shows the load waterfall so you know which resources depend on which other resources and how long they took to load, and you can sort the table by any column to find the slowest resources, or the ones that are blocking the most other resources.

For each request you can show the headers split out in general info, response and request headers. If headers are different per pane, they're annotated and the differences are highlighted so you can easily spot them.

The network panel lets you see things at a glance or really dive deep into the performance characteristics of your page, and we have a lot of plans to expand on this in the future.

If you have suggestions for what you'd like to see in the network panel, let us know!

Server bottleneck monitoring

Most dev servers use HTTP/1, which only supports up to 6 concurrent connections. That can lead to requests in Polypane being stalled while it's waiting for a connection to become available.

Some people mistakenly think that this is a Polypane issue. In reality, we're just waiting for the server to send data. Starting in 29, we show a warning in the address bar and the network panel when we notice this server bottleneck.

We're also expanding our connection whitelist, that allows us to open more connections to servers running on localhost, to Docker IPs running on the local subnet. This means faster local servers even if they are running in a container.

Snippet store

The new Snippets store is the place to find and install snippets and snippet collections created by the Polypane team and our community. You can find snippets for all kinds of use cases like accessibility, performance, quick debugging and even some that are just for fun.

Installing snippets

Open the snippet store in Polypane to browse the available snippets and install the ones you find useful right from the website. Click an install button and Polypane will automatically install the snippet for you, no need to download files or import them manually.

After installing, the snippet is available from the snippets panel and the command bar and you can apply it to all panes or specific panes as needed.

In other browsers, snippets can be downloaded as a file so you can import them into Polypane.

Contributing snippets

You can contribute your own snippets to the store by submitting a PR to the Polypane snippets repository on GitHub. You can find all the instructions on how to do that in the README in that repository.

We are looking forward to seeing what snippets the community will come up with!

Snippet live preview

Snippets replaced our old Live CSS Preview panel with a much more powerful and flexible system, but in the process we lost the ability to see your CSS be directly applied to the page as you type it. The new live preview option brings it back!

When editing or adding a CSS snippet you can now toggle the "live preview" on to see the changes you make to your CSS snippet directly applied to the page.

Even with the live preview, we will still automatically load any Google fonts you use in your snippets, so you can use those without having to worry about it.

Polypane Peek improvements

We made two quite significant improvements to Polypane peek: iframes are now inspectable, and grid and flex visualisations.

Peek lets you hold ⌥ while hovering over an element to quickly see the styles, dimensions, accessibility information and more. It's a great way to inspect elements without having to open the Elements panel and find the element in the tree view.

Grid and flex visualisations

We now automatically show visualisations for grid and flex containers when inspecting them with Peek. While you could already turn these on from the tree view in the Elements panel, having them be available in Peek makes it much easier to quickly check if things are laid out the way you expect.

Now, it wouldn't be a Polypane feature if we didn't do a little bit extra in our visualisations compared to what you can find in other browsers.

Polypane highlights the child nodes instead of the areas. This means that you don't just see the container configuration, but you can also see the alignment of child nodes within those areas.

Inspectable iframes

When you hover over an iframe, we now correctly show the information and element highlight, something that was previously not possible.

Outline panel

We added a new overview, and improved the accessibility tree in the outline panel.

Custom selectors overview

Between headers, landmarks, images and links, the outline panel already gives you a great overview of the structure of your page. But sometimes you need an overview of something more specific.

With the new custom selectors overview, you can now use any CSS selector to get an overview of all the elements that match that selector on your page. For example, use table to find all tables, [aria-live] to get an overview of all the live regions on your page, or use button, [role="button"] to get an overview of all the buttons split out between real ones and those that have a button role. This is especially useful for accessibility debugging, but can also be used for finding specific elements on the page.

When you add multiple selectors, separated by a comma, the outline panel automatically groups them and gives each selector a unique color so you can easily see which elements match what selector in the overlay.

Accessibility tree improvements

The accessibility tree now lists the description for an element and makes it easy to inspect the referenced element IDs.

Additionally, the tree should now both update more quickly and also be more stable when you're working with a page that has a lot of accessibility tree changes so you don't lose your place in the tree when you're inspecting accessibility issues.

Elements panel improvements

The elements panel got a few nice bug fixes and improvements in this release, making for a more stable environment even when dealing with a DOM with lots of events, changes and hot reloading logic.

Much easier pseudo state toggling

Toggling pseudo states like :hover and :active is now much easier to do. Instead of opening the pseudo state menu in the navigator, the style tab now has toggle buttons for all the pseudo styles you have defined for an element. Co-locating these with the styles for that pseudo state makes it so much easier to use, and a big thanks to Eric for coming up with this feature.

Oh, by the way, it also works for @starting-style rules!

For the A11y tab we made two improvements that make it easier to see what's going on. Firstly, it now shows the aria-describedby value if set, so you know what additional information is being provided to assistive technologies.

Secondly, we now link all labelledby and describedby elements right below their value and make it easy to see how your accessible name and description are being constructed.

Tree view keyboard interactions

The tree view already has arrow keys navigation and lets you hide elements using h. Now you can also use the del key to remove elements from the tree view.

Deleting elements was already available in the context menu, but if you're already on the keyboard, it's much faster to just hit del.

Quicker data refreshing

We've updated the logic that determines when we need to update element styles. This makes it work much better for modern dev servers with very precise style updates and injection.

Passkeys keychain integration on macOS

It took us a while to go through Apple's process to integrate with the passkey system, but Polypane now has first-class support for passkeys on macOS. As a result, the Apple password manager browser extension should now also work much better in Polypane.

Passkey support on Windows was already supported through Windows Security, and on Linux, which has no centralised security system, passkeys are supported by installing an extension that supports them, like 1Password.

WhatsApp preview in Meta panel

As our 11th(!) social media visualisation we added support for WhatsApp's link previews:

It's pixel perfect in both Light and Dark mode (but you expected that, right?)

Devtools panel: Inspect shared workers and service workers

If you've ever needed to inspect shared workers or service workers, you know that it's a bit of a hassle to have to go to chrome://inspect and find workers there. In Polypane we now just show shared workers and service workers in the devtools panel dropdown when you have a page open that has them.

Just select the worker you want to inspect from the dropdown and you'll get a full devtools window to inspect the worker, just like you would in Chrome.

Smaller improvements and fixes

Quickly inspect elements in the Elements panel from the Find elements bar

When using the find element feature to find elements on the page, you can now jump to the Elements panel with that element selected by hitting ⌘ enter. This makes it much easier to inspect the element you found in the Elements panel without having to find it again in the tree view.

Find elements inside shadow DOM

We have a new helper function $$$() in the Console that works just like $$() but also searches inside shadow DOM. If you make use of web components, this will help you find elements that are otherwise hidden from the console's $$() function!

Form autofilling

Form autofilling is now a little bit smarter. If you right-click an input field, we now automatically move matching lists to the top of the custom values context menu. Right click a field with a type of email, and the first item in the list of custom values is email addresses. If the autocomplete asks for a postcode, then the first item in the list of custom values is Postcodes. This way, you can fill in common fields with the right values without having to scroll through your entire list of custom values.

Speaking of email addresses, there's now also the option to fill the input with a custom email address. By default we use your account email address, but you can change that right from the context menu to whatever is most useful to you. This makes testing real forms even easier, since you can quickly fill in the form with a valid email address that you have access to.

JSON viewer

When opening a JSON file, the built-in JSON viewer now also makes the JSON available in the console as window.json. This means that you can easily access the data from the console to do further debugging or testing with it, or when you want to drill down and get a programmatic overview of the path rather than just inspect it.

Chromium 148

Polypane 29 is built on Chromium 148.0.7778.56. Notably available in this release is the new html-in-canvas API that we have enabled by default. For all the experimental features enabled in this release, check out the experimental web platform features overview.

Get Polypane 29

Polypane is available for Windows, Mac and Linux in 64 bit and ARM versions.

Polypane automatically updates on Mac, Windows and on Linux when using the AppImage. Otherwise, go to the download page to download the latest version!

Don't have Polypane yet? There is a 14-day trial available.
Try it for free. No credit card needed.

Polypane 29 Changelog

New

New Network panel
New Snippet store
New Panel: Switch to single-line with overflow tab bar
New Grid/Flex visualisations in Polypane Peek
New Outline panel: Custom selector overview
New Passkeys keychain integration on macOS
New Meta panel: WhatsApp preview
New Devtools panel: Inspect shared workers and service workers (Thanks Przemyslaw!)
New Snippets panel: live preview option (Thanks Kari!)
New Activated html-in-canvas API by default
New Chromium 148.0.7778.56

Improvements

Improved Polypane Peek: iframes are now inspectable and can be selected
Improved Load performance for custom local domains (Thanks Mike!)
Improved Confirmation dialogs are now deduplicated when called multiple times in a row (Thanks Matija!)
Improved JSON viewer: Makes data available in the console as window.json
Improved Elements panel: A11y tab now links all labelledby elements (Thanks Eric!)
Improved Elements panel: A11y tab now shows aria-describedby value (Thanks Eric!)
Improved Elements panel: Stable references to elements for hot reloading dev servers (Thanks Matyáš!)
Improved Elements panel: Load new styles on injection by hot reload servers (Thanks Matyáš!)
Improved Elements panel: Toggle pseudo styles in style panel (Thanks Eric!)
Improved Elements panel: del key now removes element in tree view
Improved Console panel: new $$$() helper that also searches shadow DOM.
Improved Outline panel: Accessibility tree now shows a description as well as the referenced IDs (Thanks Eric!)
Improved Basic auth popup now follows the system design
Improved Form autofill: Ability to use a default email address (Thanks Tom!)
Improved Form autofill: Move lists matching the element to the top
Improved Find elements: cmd/ctrl + enter now shows element in Elements panel (Thanks Ricky!)
Improved Debug tools: Improve wording in Color contrast tool (Thanks Ana!)
Improved Snippets Editor: Improved layout when editing
Improved Traffic lights alignment on macOS 26 is now improved
Improved Session management: Add confirmation dialog before deleting session
Improved Pane resizing performance when you have a lot of panes open
Improved More deterministic page loading after click actions
Improved Integrations: new Marker.io logo

Fixes

Fix Elements panel: Improve accessible name calculation labeled by elements with roles without accname (Thanks Eric!)
Fix Elements panel: Events badge was not visible in tree view (Thanks Ashlee!)
Fix Elements panel: Allow editing the color of an image-only background property
Fix Elements panel: Copy CSS for keyframes was missing the animation name
Fix Elements panel: Font weight wasn't accurate for contrast calculation in A11y tab
Fix Browse panel: Previous tab shortcut was not working (Thanks Matija!)
Fix Browse panel: New window from panel did not always create new tab
Fix Browse panel: New tab should focus access bar (Thanks Matija!)
Fix Browse panel: Add extension button did not work
Fix Full page screenshots: use correct viewport height when making screenshots
Fix Context menu: 'Save link as...' option did not work
Fix Outline panel: Prevent accessibility tree from collapsing focused elements
Fix Outline panel: Prevent double tooltips when hovering over elements
Fix Styles: Prevent React router from trashing styles on load (Thanks Nathan!)
Fix Console panel: Prevent extra white space in styled console messages
Fix 'No internet connection' warning is now aligned correctly
Fix Meta panel: The suggested file name now includes correct name

The Intl API: The best browser API you're not using

Wed, 08 Apr 2026 00:00:00 GMT

Chances are you've used Moment.js, date-fns, Luxon, or numeral.js at some point. Developers have relied on these libraries for years to format dates, numbers, and currencies. Those are all very useful libraries, but they also come with a cost: they add kilobytes to your download size and they require client-side code parsing:

Library	Size
Moment.js	295 kB
date-fns	77 kB
luxon.js	82 kB
numeral.js	11 kB

The Intl API is baseline widely available (except for Intl.DurationFormat. It works in all current evergreen browsers, but hasn't been around long enough to qualify for "widely available".) and can handle almost all of your formatting requirements directly in the browser, with zero kB of download and no JS bundle parsing required. It also knows your users' locale preferences so you can format dates and numbers in a way that feels natural to them without any extra work.

Prefer video?

This article is a written version of a talk by Kilian Valkhof, Polypane's creator. You can watch the video here:

Interested in having this talk at your conference or meetup? Get in touch!

Why you need an internationalization API

You might be thinking: "My site is only in one language. Why would I need an internationalization API?"

That's the most common reason developers skip over Intl. But Intl is less about translating your UI and more about formatting data correctly for your users.

Consider a date like 09/12/2025. If you're from the US, you'd read it as September 12th. Almost anywhere else in the world, you'd read it as December 9th. That's quite a big difference, and if a carelessly (un)formatted date leads to someone missing an appointment or even just confusion, that reflects very poorly on your site.

The Intl API formats dates, numbers, currencies, lists, and text in a way that fits the user's locale. Even if your site is just in English, users from different English speaking countries still have different formatting conventions. Intl handles all of that for you, so you don't have to worry about it.

What Intl gives you

0 kB added to your bundle: it's built into the browser
Baseline widely available: works in every major browser
Locale-aware: knows not just languages but country-specific conventions
Fast: native implementations are significantly faster than userland libraries

The APIs we'll cover:

Intl.DateTimeFormat: format dates and times
Intl.RelativeTimeFormat: "yesterday", "in 3 days"
Intl.DurationFormat: "2 hours, 5 minutes and 30 seconds"
Intl.NumberFormat: format numbers, currencies, and units
Intl.ListFormat: "Apples, Oranges, and Bananas"
Intl.PluralRules: figure out plural forms correctly
Intl.Segmenter: break text into words, sentences, or graphemes
Intl.Collator: sort strings in a locale-aware way

What Intl doesn't do

We'll get into plenty of examples later on in this article but a common misunderstanding, or maybe wish, is that Intl also handles data wrangling. Unfortunately, Intl is a formatting API, not a calculation or measurement API. It just takes objects (like dates, numbers and arrays) and turns them into strings.

For example if you want to format a relative time compared to now, like to show when a blog post was released compared to the current time, you need to calculate the difference yourself and then pass that to Intl.RelativeTimeFormat. We have an example of how to do that in the section on RelativeTimeFormat.

Later on in the article you'll also see that it can format numbers with units (like degrees Celsius or miles) but it has no conception of what those units mean. So while it knows to put a °C after a number when you ask for Celsius, it doesn't know how to convert from Fahrenheit to Celsius. It's just takes a number and returns a string with an unit in it.

How the Intl API works

All Intl functions have roughly the same shape:

Pick a locale.
Pick some options.
Create a formatter.
Reuse that formatter with your data.

Here's the general setup with Intl.DateTimeFormat:

const locale = 'en-US';

const options = {
  dateStyle: 'full',
  timeStyle: 'short',
};

const formatter = new Intl.DateTimeFormat(locale, options);

Then, once you have the formatter, you pass it the value you want to format:

const publishedAt = new Date('2026-04-07T16:45:00Z');

formatter.format(publishedAt);
// → "Tuesday, April 7, 2026 at 4:45 PM"

formatter.format(new Date('2026-06-01T09:00:00Z'));
// → "Monday, June 1, 2026 at 9:00 AM"

That same pattern shows up throughout Intl:

new Intl.DateTimeFormat(locale, options).format(date);
new Intl.NumberFormat(locale, options).format(number);
new Intl.ListFormat(locale, options).format(items);

new Intl.PluralRules(locale, options).select(number);
new Intl.Collator(locale, options).compare(a, b);

The constructor arguments are consistent too:

A locale string such as 'en-US', 'nl-NL', or 'fr-FR'. If you omit it, the browser uses the user's system locale. You can also pass undefined to use the browser's default locale explicitly, which you need if you also want to set options.
An options object that controls the output. The available options differ per formatter, but the setup pattern stays the same.

Creating the formatter is the expensive part, because that loads the locale data and sets up the internal structures. Calling .format(), .select(), or .compare() afterwards is cheap. That means you should create the formatter once and reuse it when you're handling a lot of values.

// Good: create once, reuse many times.
const formatter = new Intl.DateTimeFormat('en-US', {
  dateStyle: 'short',
});

dates.map((date) => formatter.format(date));

// Less good: create a new formatter every time.
dates.map((date) => new Intl.DateTimeFormat('en-US', { dateStyle: 'short' }).format(date));

That matters most with Intl.Collator, the API that lets you sort strings in a locale-aware way. Sorting can call the comparison function many times, so you definitely want to create the collator once and reuse it.

Setting the locale

For locales, you can use any valid BCP 47 language tag, such as 'en', 'en-US', 'nl-NL', or 'fr-FR'. You can also specify a list of locales, and the browser will pick the first one it supports.

Support for locales differs between browser and operating system combinations. The browser will know of thousands of locales, but it will actually only have data (like translated units or date formats) for a few hundred of those. By passing a list of locales, you can provide fallbacks in case the browser doesn't have data for the first one. For example, if you specify ['en-US', 'en-GB'], the browser will use US English if it has that, but if it doesn't, it will fall back to British English.

If you don't specify a locale, the formatter uses the browser's locale. You can set it to undefined to get the same effect. That means you can create a formatter that automatically adapts to the user's locale without any extra work. Alternatively you can explicitly ask for navigator.language or navigator.languages to get the user's language preferences and pass those to the formatter:

// Choose a specific locale
const formatter = new Intl.DateTimeFormat('nl-NL');
// Pass a list of locales, the browser picks the first one it supports
const formatter = new Intl.DateTimeFormat(['en-US', 'en-GB']);

// Use the browser's locale
const formatter = new Intl.DateTimeFormat();
const formatter = new Intl.DateTimeFormat(undefined);

// Use the browser's locale but specify options too
const formatter = new Intl.DateTimeFormat(navigator.language);

// Use the user's full language preference list
// (the browser picks the first one it supports)
const formatter = new Intl.DateTimeFormat(navigator.languages);

navigator.languages is an array like ['en-US', 'en', 'nl'], so works like a list of locales you can pass directly to the formatter.

What's the difference between a language and a locale? A locale is a language as spoken in a specific country. For example, both the US and the UK speak English, but they have different formatting conventions for dates and numbers. So you have en-US for American English and en-GB for British English. If you just specify en, the browser will pick a default locale for that language, which is usually the most common one.

Dates & Times

Let's start with the APIs that have the clearest naming: the ones for formatting dates and times.

Intl.DateTimeFormat

Intl.DateTimeFormat is the API for formatting dates and times.

dateStyle

timeStyle

hour12

timeZone

const formatter = new Intl.DateTimeFormat(undefined, {
  dateStyle: "full",
  timeStyle: "short",
  timeZone: "UTC"
});
formatter.format(new Date("2026-04-07T16:45:00.000Z"));

Your locale

Tuesday, April 7, 2026 at 4:45 PM

English (US)

en-US

Tuesday, April 7, 2026 at 4:45 PM

Dutch

nl-NL

dinsdag 7 april 2026 om 16:45

French

fr-FR

mardi 7 avril 2026 à 16:45

Japanese

ja-JP

2026年4月7日火曜日 16:45

Arabic

ar-EG

الثلاثاء، ٧ أبريل ٢٠٢٦ في ٤:٤٥ م

At its simplest:

const formatter = new Intl.DateTimeFormat();
formatter.format(new Date());

// → "4/7/2026" (in en-US)

The default output is a bit terse. Most of the time you'll want to specify a style. The easiest way is with dateStyle and timeStyle:

const formatter = new Intl.DateTimeFormat('fr-FR', {
  dateStyle: 'full', // 'full' | 'long' | 'medium' | 'short'
  timeStyle: 'short', // 'full' | 'long' | 'medium' | 'short'
});

formatter.format(new Date());

// → "mercredi 8 avril 2026 à 09:19"

What's nice here is that you didn't have to know that "mercredi" is Wednesday in French, or that "avril" is April, or have arrays of days and months somewhere. You ask the browser for French, and the browser already knows.

When you need more control, you can specify exactly which parts of the date to show and how to format them:

weekday

day

hour

minute

second

month

year

era

const formatter = new Intl.DateTimeFormat(undefined, {
  weekday: "long",
  day: "numeric",
  hour: "numeric",
  minute: "2-digit",
  second: "2-digit",
  month: "long",
  year: "numeric"
});
formatter.format(new Date());

Your locale

Monday, September 14, 2026 at 5:30:41 PM

If you specify individual parts like this, only those parts will appear in the output. Mixing dateStyle/timeStyle with individual part options throws an error, you can use one or the other but not both.

You might have seen them in the interactive example, but there's a few more options that are worth mentioning:

const options = {
  hour12: true | false, // override the locale's 12/24-hour preference
  timeZone: 'UTC' | 'Europe/Amsterdam' | ..., // specify a time zone
  timeZoneName: 'short' | 'long', // "CET", "Central European Time", etc.
  dayPeriod: 'narrow' | 'short' | 'long', // "in the morning", "AM", etc.
};

formatToParts()

All Intl formatters that have a .format() method also have a .formatToParts() method. Instead of returning one big string, it returns an array of { type, value } objects. This makes it easy to wrap individual parts in markup for styling, such as making the day bold or adding a tooltip to the time zone name.

const formatter = new Intl.DateTimeFormat('en-US', {
  dateStyle: 'long',
  timeStyle: 'short',
});

formatter.formatToParts(new Date('2026-04-07T16:45:00Z'));
// → [
//     { type: 'month',     value: 'April' },
//     { type: 'literal',   value: ' '     },
//     { type: 'day',       value: '7'     },
//     { type: 'literal',   value: ', '    },
//     { type: 'year',      value: '2026'  },
//     { type: 'literal',   value: ' at '  },
//     { type: 'hour',      value: '4'     },
//     { type: 'literal',   value: ':'     },
//     { type: 'minute',    value: '45'    },
//     { type: 'literal',   value: ' '     },
//     { type: 'dayPeriod', value: 'PM'    },
//   ]

Intl.RelativeTimeFormat

Intl.RelativeTimeFormat gives you human-friendly relative time strings like "yesterday" and "in 3 days".

Value (negative = past)

Unit

numeric

const formatter = new Intl.RelativeTimeFormat(undefined, {
  numeric: "auto"
});
formatter.format(-3, "day");

Your locale

3 days ago

English (US)

en-US

3 days ago

Dutch

nl-NL

3 dagen geleden

French

fr-FR

il y a 3 jours

Japanese

ja-JP

3 日前

Arabic

ar-EG

قبل ٣ أيام

Unlike DateTimeFormat, it works with a number and a unit, not a Date:

const relative = new Intl.RelativeTimeFormat('nl-NL', {
  numeric: 'auto', // 'auto' | 'always'
});

relative.format(-3, 'month'); // → "3 maanden geleden"
relative.format(1, 'day'); // → "morgen"
relative.format(-1, 'day'); // → "gisteren"

With numeric: 'auto', the formatter uses words like "tomorrow" and "yesterday" when it can. With numeric: 'always', it always uses a number: "in 1 day", "1 day ago".

Units can be: 'second', 'minute', 'hour', 'day', 'week', 'month', 'quarter', or 'year'.

Since you need to calculate the difference yourself, here's a helper pattern for calculating days between two dates:

const date = new Date('2026-05-01T00:00:00Z');
const diffInMs = date - new Date();
const diffInDays = Math.round(diffInMs / (1000 * 60 * 60 * 24));

const relative = new Intl.RelativeTimeFormat('en-US', { numeric: 'auto' });
relative.format(diffInDays, 'day');
// → "in 24 days" (or however far away May 1st is)

Dates are in milliseconds. So you can convert it by dividing it to the unit you want. Instead of a really big number, like 86400000 for the number of milliseconds in a day, your code is easier to read if you do it step by step: 1000 milliseconds in a second, 60 seconds in a minute, 60 minutes in an hour and then 24 hours in a day.

RelativeTimeFormat also has .formatToParts(), which breaks the output into 'integer', 'literal', and 'unit' pieces. This lets you wrap each part and style it separately.

const relative = new Intl.RelativeTimeFormat('en-US', { numeric: 'always' });

relative.formatToParts(-3, 'month');
// → [
//     { type: 'integer', value: '3', unit: 'month' },
//     { type: 'literal', value: ' months ago' },
//   ]

Intl.DurationFormat

Intl.DurationFormat formats time durations.

style

Hours

Minutes

Seconds

const formatter = new Intl.DurationFormat(undefined, {
  style: "long"
});
formatter.format({
  "hours": 2,
  "minutes": 45,
  "seconds": 30
});

Your locale

2 hours, 45 minutes, 30 seconds

English (US)

en-US

2 hours, 45 minutes, 30 seconds

Dutch

nl-NL

2 uur, 45 minuten en 30 seconden

French

fr-FR

2 heures, 45 minutes et 30 secondes

Japanese

ja-JP

2 時間 45 分 30 秒

Arabic

ar-EG

ساعتان، و٤٥ دقيقة، و٣٠ ثانية

It lets you choose between an output like 2:05:30 and one like "2 hours, 5 minutes, 30 seconds":

const duration = new Intl.DurationFormat('en-US', {
  style: 'long', // 'long' | 'short' | 'narrow' | 'digital'
});

duration.format({ hours: 2, minutes: 5, seconds: 30 });
// → "2 hours, 5 minutes, 30 seconds"

const clock = new Intl.DurationFormat('en-US', { style: 'digital' });
clock.format({ hours: 2, minutes: 5, seconds: 30 });
// → "2:05:30"

While the other date and time formatters use options to control which parts of the date to show, by default the DurationFormat just shows all the parts you give it in the formatter. So if you pass it hours, minutes and seconds, it will show all three. If you only pass it minutes and seconds, it will only show those two.

You can however force it to always show certain parts, even if they're zero by setting the *Display options:

const options = {
  yearsDisplay: 'auto' | 'always',
  monthsDisplay: 'auto' | 'always',
  daysDisplay: 'auto' | 'always',
  hoursDisplay: 'auto' | 'always',
  minutesDisplay: 'auto' | 'always',
  secondsDisplay: 'auto' | 'always',
  millisecondsDisplay: 'auto' | 'always',
  microsecondsDisplay: 'auto' | 'always',
  nanosecondsDisplay: 'auto' | 'always',
};

auto will only show the part if it's specified in the object, while always will always show it even if it's omitted.

The default option for all of these is almost always auto, except when you set style to digital, in which case the default for hours, minutes and seconds becomes always.

When you use digital, hours, minutes, and seconds are all shown by default even if they're zero, so you get 00:45:00 rather than just 45.

You can also format much finer durations, down to nanoseconds, which is useful for displaying performance measurements:

const perf = new Intl.DurationFormat('en-US', { style: 'narrow' });
perf.format({ milliseconds: 423, microseconds: 195 });
// → "423ms 195μs"

Numbers & Currencies

Intl.NumberFormat

Intl.NumberFormat formats plain numbers, currencies, and units.

Number

style

notation

useGrouping

const formatter = new Intl.NumberFormat(undefined, {
  style: "decimal",
  notation: "standard",
  useGrouping: "auto"
});
formatter.format(1234567.89);

Your locale

1,234,567.89

English (US)

en-US

1,234,567.89

Dutch

nl-NL

1.234.567,89

French

fr-FR

1 234 567,89

Japanese

ja-JP

1,234,567.89

Arabic

ar-EG

١٬٢٣٤٬٥٦٧٫٨٩

Those are all the same API, but they solve different problems, so it helps to keep them separate.

Plain numbers and percentages

For plain numbers, you normally use the default decimal style. That gives you locale-aware grouping and decimal separators without any extra work.

const formatter = new Intl.NumberFormat('nl-NL');

formatter.format(1000000); // → "1.000.000"
formatter.format(123456.789); // → "123.456,789"

Even for plain numbers, locale matters: Dutch uses . for thousands and , for decimals, while US English does the opposite.

Percentages use the same API with style: 'percent':

const pct = new Intl.NumberFormat('fr-FR', { style: 'percent' });
pct.format(0.1); // → "10 %"
pct.format(0.753); // → "75 %"

The general number formatter also supports different notations, which lets you set compact numbers like 1M :

const compact = new Intl.NumberFormat('en-US', {
  notation: 'compact',
  compactDisplay: 'short',
});

compact.format(1007800); // → "1M"
compact.format(1534); // → "1.5K"

// For a longer version, use 'long' instead of 'short'

const compactLong = new Intl.NumberFormat('en-US', {
  notation: 'compact',
  compactDisplay: 'long',
});

compactLong.format(1007800); // → "1 million"
compactLong.format(1534); // → "1.5 thousand"

Note how the compact notation rounds the number to fit the format. 1,007,800 becomes "1M", and 1,534 becomes "1.5K". If you want to control the rounding, you can use the fraction digit options or switch to significant digits.

You can control how many decimal places appear with the fraction digit options, or switch to significant digits for scientific or measurement data:

// Always show exactly two decimal places
const price = new Intl.NumberFormat('en-US', {
  minimumFractionDigits: 2,
  maximumFractionDigits: 2,
});

price.format(9.9); // → "9.90"
price.format(9.999); // → "10.00"

// Cap to three significant digits
const approx = new Intl.NumberFormat('en-US', {
  maximumSignificantDigits: 3,
});

approx.format(123456); // → "123,000"
approx.format(0.001234); // → "0.00123"

Currencies

A big feature in the number formatting API is formatting currencies, which even in its simplest form has quite a few differences between countries like if the symbol goes before or after the number, and getting them wrong in your UI will easily make your site look unprofessional or untrustworthy.

Amount

Currency

currencyDisplay

const formatter = new Intl.NumberFormat(undefined, {
  style: "currency",
  currency: "EUR",
  currencyDisplay: "symbol"
});
formatter.format(123456.789);

Your locale

€123,456.79

English (US)

en-US

€123,456.79

Dutch

nl-NL

€ 123.456,79

French

fr-FR

123 456,79 €

Japanese

ja-JP

€123,456.79

Arabic

ar-EG

‏١٢٣٬٤٥٦٫٧٩ €

Currency formatting is more than putting a symbol in front of a number. The symbol position, thousands separator, decimal separator, and rounding rules all vary by locale even when using the same currency (see how different euros are formatted compared between the Netherlands and France). Intl.NumberFormat handles all of that for you without you having to know the specifics across locales.

const moneyNL = new Intl.NumberFormat('nl-NL', {
  style: 'currency',
  currency: 'EUR',
});
const moneyFr = new Intl.NumberFormat('fr-FR', {
  style: 'currency',
  currency: 'EUR',
});

moneyNL.format(123456.789); // → "€ 123.456,79"
moneyFr.format(123456.789); // → "123 456,79 €"

You can also customize how the currency itself is displayed, such as showing the currency code instead of the symbol or even the full, localized name of the currency:

const options = {
  style: 'currency',
  currency: 'USD',
  currencyDisplay: 'name', // 'symbol' | 'narrowSymbol' | 'code' | 'name'
  currencySign: 'accounting', // 'standard' (default) | 'accounting'
};

new Intl.NumberFormat('nl-NL', options).format(123456.789);
// → "123.456,79 Amerikaanse dollar"

The difference between symbol and narrowSymbol is that narrowSymbol can be "lossy". For example, the symbol for US dollars is US$ because other countries also use dollars and it needs to differentiate between US dollars and, say, Canadian dollars, which is CA$. The narrow symbol for both is just $, which is more compact and works when you operate in a single country, but can be confusing if you have an international audience.

currencySign controls how negative currency values are displayed. Normal people expect a minus sign in front of the number, but accountants, non-conformists that they are, prefer to put negative numbers in parentheses.

const standard = new Intl.NumberFormat('en-US', {
  style: 'currency',
  currency: 'USD',
  currencySign: 'standard',
});

const accounting = new Intl.NumberFormat('en-US', {
  style: 'currency',
  currency: 'USD',
  currencySign: 'accounting',
});

standard.format(-123.45);
// → "-$123.45"

accounting.format(-123.45);
// → "($123.45)"

Units

The unit style is one of the most underused parts of Intl.NumberFormat. It formats a number with a physical unit (or units!) in a locale-appropriate way:

Value

Unit

unitDisplay

const formatter = new Intl.NumberFormat(undefined, {
  style: "unit",
  unit: "kilometer-per-hour",
  unitDisplay: "short"
});
formatter.format(100);

Your locale

100 km/h

English (US)

en-US

100 km/h

Dutch

nl-NL

100 km/u

French

fr-FR

100 km/h

Japanese

ja-JP

100 km/h

Arabic

ar-EG

١٠٠ كم/س

Supported units cover length, mass, temperature, speed, volume, digital size, and time. To get all of them, run Intl.supportedValuesOf("unit") in your console.

const boiling = new Intl.NumberFormat('nl-NL', {
  style: 'unit',
  unit: 'celsius',
  unitDisplay: 'short', // 'short' | 'long' | 'narrow'
});

boiling.format(100);
// → "100°C"

new Intl.NumberFormat('nl-NL', {
  style: 'unit',
  unit: 'celsius',
  unitDisplay: 'long',
}).format(100);
// → "100 graden Celsius"

The unit style also lets you combine any two units together when you need to display something like "miles per hour" or "kilometers per hour". The notation for that is unit1-per-unit2:

const speed = new Intl.NumberFormat('nl-NL', {
  style: 'unit',
  unit: 'kilometer-per-hour',
  unitDisplay: 'short', // 'short' | 'long' | 'narrow'
});

speed.format(100);
// → "100 km/u"

new Intl.NumberFormat('nl-NL', {
  style: 'unit',
  unit: 'kilometer-per-hour',
  unitDisplay: 'long',
}).format(100);
// → "100 kilometer per uur"

Breaking the output into parts

NumberFormat also has .formatToParts(). It's particularly useful for currencies, where you might want to wrap the different parts of the number and style them:

const money = new Intl.NumberFormat('en-US', {
  style: 'currency',
  currency: 'USD',
});

money.formatToParts(1234.56);
// → [
//     { type: 'currency', value: '$'   },
//     { type: 'integer',  value: '1'   },
//     { type: 'group',    value: ','   },
//     { type: 'integer',  value: '234' },
//     { type: 'decimal',  value: '.'   },
//     { type: 'fraction', value: '56'  },
//   ]

Lists & Text

There are two APIs for working with natural language text: one for formatting lists and one for finding plural forms.

Intl.ListFormat

Intl.ListFormat turns arrays into natural-language lists.

type

style

Items (one per line)

const formatter = new Intl.ListFormat(undefined, {
  type: "conjunction",
  style: "long"
});
formatter.format([
  "Apples",
  "Oranges",
  "Bananas"
]);

Your locale

Apples, Oranges, and Bananas

English (US)

en-US

Apples, Oranges, and Bananas

English (UK)

en-GB

Apples, Oranges and Bananas

Dutch

nl-NL

Apples, Oranges en Bananas

French

fr-FR

Apples, Oranges et Bananas

Spanish

es-ES

Apples, Oranges y Bananas

When you need to turn an array into a human-readable list, use it instead of Array.join(', '). A comma-joined list is usually not how lists work in natural language. When you list things, you don't say "a, b, c", you say "a, b and c". ListFormat handles that for you, so you don't have to break out an Array.reduce and keep track of whether you're on the last item or not.

// ✗ Not natural language
['Apples', 'Oranges', 'Bananas'].join(', ');
// → "Apples, Oranges, Bananas"

// ✓ Natural language
const formatter = new Intl.ListFormat('en-US', { type: 'conjunction' });
formatter.format(['Apples', 'Oranges', 'Bananas']);
// → "Apples, Oranges, and Bananas"

The three list types each fit a different kind of UI copy.

Use conjunction when the items belong together and you mean "and":

new Intl.ListFormat('en', { type: 'conjunction' }).format(['Cowboy', 'Hat', 'Horse']);
// → "Cowboy, Hat, and Horse"

This is what you want for summaries like supported features or anything else where all listed items apply.

Use disjunction when the items are alternatives and you mean "or":

new Intl.ListFormat('en', { type: 'disjunction' }).format(['Cowboy', 'Hat', 'Horse']);
// → "Cowboy, Hat, or Horse"

This works for option lists, fallback choices, or messaging like "Choose email, SMS, or push notifications."

Use unit when you want a compact list without an explicit conjunction:

new Intl.ListFormat('en', { type: 'unit' }).format(['Cowboy', 'Hat', 'Horse']);
// → "Cowboy, Hat, Horse"

This is useful for tight UI labels, specs, measurements or lists of ingredients.

The style option ('long', 'short', 'narrow') affects how the connector words are shown. In English, short uses an ampersand: "Cowboy, Hat, & Horse".

In American English (en-US), a conjunction list uses the Oxford comma ("...Hat, and Horse"). Switch to British English (en-GB) and the Oxford comma disappears. So you can stop arguing about the Oxford comma in your team and just let the browser handle it for you.

Intl.PluralRules

Intl.PluralRules tells you which plural form to use for a given number. A plural form is the "s" when you go from "1 bird" to "2 birds", but it can be more complex than that in other languages.

type

Number

const count = 1;
const rules = new Intl.PluralRules(undefined, { type: 'cardinal' });
rules.select(count);

Your locale

one

English (US)

en-US

one

Dutch

nl-NL

one

French

fr-FR

one

Japanese

ja-JP

other

Arabic

ar-EG

one

What's weird about PluralRules is that, unlike the other formatting APIs, it doesn't actually do the formatting, it just gives you consistent categorization for the plural forms in the language.

So for bird/birds, it would tell you that for 1 bird the plural form is "one", and for 0, 2, 3, etc. the plural form is "other". You can then use that information to display the correct word form in your UI: "one" gets nothing appended, and "other" gets an "s".

const plurals = new Intl.PluralRules('en-US');

plurals.select(0); // → "other"
plurals.select(1); // → "one"
plurals.select(2); // → "other"

const count = 5;
const label = `${count} bird${plurals.select(count) === 'other' ? 's' : ''}`;
// → "5 birds"

"Cardinal" is the default plural type, and it basically means "count". English has just two cardinal plural forms: 'one' (for the number 1) and 'other' (everything else, including 0). Other languages have more. Arabic, for example, has six plural forms: zero, one, two, few, many, and other.

Along with cardinal, you also have ordinal, which is used for ranking or ordering things: "1st", "2nd", "3rd", "4th", etc. In English, the plural forms for ordinals are one (for 1), two (for 2), few (for 3), and other (for everything else). So you can use that to get the correct suffix for any number:

const rules = new Intl.PluralRules('en-US', { type: 'ordinal' });
const suffixes = { one: 'st', two: 'nd', few: 'rd', other: 'th' };

const ordinal = (n) => `${n}${suffixes[rules.select(n)]}`;

ordinal(1); // → "1st"
ordinal(2); // → "2nd"
ordinal(3); // → "3rd"
ordinal(4); // → "4th"
ordinal(21); // → "21st"

As you can see from these two examples, it's your job to provide the right suffix or, in the case of other language, the right word form.

For example, 3 in Dutch is "drie", but 3rd is "derde". You can't easily append a suffix to get from "drie" to "derde", so you need to provide the full word forms for each plural category.

Segmentation

Intl.Segmenter

Intl.Segmenter breaks text into meaningful segments.

granularity

const segmenter = new Intl.Segmenter('default', {
  granularity: "word"
});
const segments = Array.from(segmenter.segment(text));

English (US)

en-US

How many words are in this sentence?

7 word-like segments

Dutch

nl-NL

Hoeveel woorden zitten er in deze zin?

7 word-like segments

Japanese

ja-JP

この文には何語ありますか？

8 word-like segments

Arabic

ar-EG

كم عدد الكلمات في هذه الجملة؟

6 word-like segments

Blue = word-likeGray dashed = whitespacePink = punctuation

Breaking up sentences into parts might sound simple, but it quickly becomes complicated when you consider all the edge cases in natural language. For example, how would you count the number of words in a sentence? You might be tempted to do this:

'How many words are in this sentence?'.split(' ').length; // → 7 ✓

Splitting on a space and then calling .length works well for English and other western languages, but it relies on the assumption that words are separated by spaces. That is not a universal rule in natural language. It falls apart here:

'これは日本語のテキストです'.split(' ').length; // → 1 ✗

Japanese doesn't use spaces between words. So splitting on a space doesn't work and you're out of luck.

But even String.length to get the number of characters isn't as straightforward as it seems. How long is this single emoji in a string?

'👨‍👩‍👧‍👦'.length; // → 11

Not one, but eleven! That's because .length doesn't count visible characters, it counts code units. And this emoji happens to be a ligature of four individual emojis joined by zero-width joiners, which are invisible characters that connect them together. So while you see one emoji, JavaScript sees eleven code units and .length returns 11.

Detecting sentences gets even trickier. Since formatted numbers, abbreviations, and contractions all contain punctuation, splitting on a period also doesn't always work:

`This article could be 100.000 words long if
 you don't look out. Do you really need
 that many examples?`.split('.').length; // → 3 ✗
// (splits on the period in "100.000" too)

Of course, some sentences might also end with a question mark or an exclamation point, so splitting on a period isn't a reliable way to count sentences either.

Intl.Segmenter handles all of these correctly and it has three different levels of granularity so you can get characters, words or sentences in a text string.

'grapheme' (default): user-perceived characters (what you see as a single character, even if it's made up of multiple code points)

const graphemes = new Intl.Segmenter('en', { granularity: 'grapheme' });
Array.from(graphemes.segment('👨‍👩‍👧‍👦')).length; // → 1 ✓
Array.from(graphemes.segment('café')).length; // → 4 ✓

'word': words, plus non-word segments such as spaces and punctuation. Each segment has an isWordLike boolean to help you filter out the non-word segments.

const words = new Intl.Segmenter('ja-JP', { granularity: 'word' });
Array.from(words.segment('これは日本語のテキストです')).filter((s) => s.isWordLike).length; // → 6 ✓ (the browser knows Japanese word boundaries)

'sentence': complete sentences, with abbreviation and number handling:

const sentences = new Intl.Segmenter('en', { granularity: 'sentence' });
Array.from(sentences.segment('I went to the dr. smith yesterday. How are you?')).map((s) => s.segment);

// → [
//     "I went to the dr. smith yesterday. ",
//     "How are you?"
//   ]

One caveat: the sentence segmenter handles dr. as an abbreviation when followed by lowercase, but if the next word is capitalized (like you would expect for a proper name), it may be treated as a sentence boundary. The segmenter is smart, but not perfect.

The segment() method returns an iterable, which is why we wrap it in Array.from(). Each item is an object with at minimum:

segment: the text of the segment
index: where it starts in the original string
input: the original string

For the 'word' granularity, items also have a boolean property:

isWordLike: true if the segment is a word rather than whitespace or punctuation

For more, check out our article on just the Segmenter API.

Collation

Intl.Collator

Intl.Collator sorts strings in a locale-aware way.

sensitivity

Items (space separated)

const items = ["ñ","n","o","á","A","ß","z"];
const collator = new Intl.Collator(undefined, {
  sensitivity: "base"
});
items.sort(collator.compare);

array.sort()

plain sort

Your locale

English (US)

en-US

Spanish

es-ES

German

de-DE

Swedish

sv-SE

Built-in Array.sort() sorts strings by their Unicode code points, which doesn't match the alphabetical order humans expect in many languages:

['ñ', 'n', 'o'].sort();
// → ['n', 'o', 'ñ']  ✗  (ñ has a higher code point, sorts after z)

const collator = new Intl.Collator('es'); // Spanish
['ñ', 'n', 'o'].sort(collator.compare);
// → ['n', 'ñ', 'o']  ✓  (ñ correctly sits between n and o in Spanish)

This matters anywhere you show an index, a directory, or any other sorted list.

You might already know String.prototype.localeCompare(), which also does locale-aware string comparison. Under the hood it uses Intl.Collator too, but it creates and destroys a new collator instance every time you call it. This is pretty slow (remember, creating the formatter is the expensive part) so what you can do instead is set up a collator once and then reuse its compare method.

// Works, but slow:
items.sort((a, b) => a.localeCompare(b));

// Better: creates the collator once and reuses it
const collator = new Intl.Collator('en');
items.sort(collator.compare);

Intl.Collator has a handful of useful options. The most important one is sensitivity, which controls what differences in characters are considered:

// 'base': only base letters differ ('a' ≠ 'b', but 'a' = 'á' = 'A')
// 'accent': base letters and accents differ, but not case
// 'case': base letters and case differ, but not accents
// 'variant': all differences matter (default for sort order)

const collator = new Intl.Collator('en', { sensitivity: 'base' });
collator.compare('a', 'á'); // → 0 (considered equal)

Other useful options:

usage: 'sort' (default) or 'search'. Use 'sort' for ordering lists. If you want to use collator to filter lists based on language-specific logic, you can use search and test if the result is 0 to check for a match. for the collator, cafe, café and CAFE are all considered equal with sensitivity: 'base', so using search means you have a more natural search experience for users in languages with accents and case differences.
caseFirst: 'upper', 'lower', or 'false' (default). Controls whether uppercase or lowercase sorts first when case differences matter.
ignorePunctuation: true or false (default). When true, punctuation differences are ignored during comparison.
collation: requests a specific collation variant. Common values are:
- 'phonebk': phonebook-style sorting, used in German where ä sorts as ae, ö as oe, ü as ue
- 'pinyin': pinyin ordering for Latin and CJK characters, common for Chinese
- 'stroke': stroke-count ordering for CJK characters, used in Traditional Chinese
- 'trad': traditional ordering, for example treating ch and ll as distinct letters in Spanish
- 'emoji': recommended ordering for emoji characters
- 'standard': the locale's standard ordering (the default)

You can get the full list your browser supports with Intl.supportedValuesOf('collation').

Numeric sorting

The numeric option is worth a special mention. By default, string sorting is done character-by-character. That means 10 sorts before 9 because 1 is less than 9. This is almost never what you want when sorting anything with numbers in it.

const files = ['chapter10.txt', 'chapter9.txt', 'chapter2.txt', 'chapter1.txt'];

// Default sort per-character
files.sort();
// → ['chapter1.txt', 'chapter10.txt', 'chapter2.txt', 'chapter9.txt']  ✗

// Numeric sort
const collator = new Intl.Collator('en', { numeric: true });
files.sort(collator.compare);
// → ['chapter1.txt', 'chapter2.txt', 'chapter9.txt', 'chapter10.txt']  ✓

This comes up frequently with file names, version numbers, and any list where users use numbers in names: image1, image2, … image10. Without numeric: true, image10 sorts right after image1 and before image2. With it, they sort the way users expect.

Conclusion

When you first look at Intl, it can feel like a loose collection of unrelated APIs. It does something with dates, currencies and also sorts lists or counts words? What an API! If you only look at the constructor names, it can seem like a lot to memorize.

But Intl is built on one core idea: you have a type of data, and you want an easy way to format it in natural language. You pick a locale. You pick some options. You create a formatter, parts formatter, comparator, or segmenter. Then you reuse it with your data. Whether you're formatting dates, numbers, currencies, lists, plurals, words, or sorted strings, the API shape stays similar.

Understanding that shared foundation makes the whole API much easier to reason about and easier to reach for when you come across a string formatting task. It means less hand-rolled formatting code, fewer dependencies, and fewer subtle bugs where a value looks correct to you but confusing or wrong to someone in another locale.

The browser already knows how this stuff works and did the hard work for you. Intl gives you a way to use that knowledge directly.

How to debug the @starting-style at-rule in Polypane

Thu, 12 Feb 2026 00:00:00 GMT

The @starting-style at-rule makes it possible to animate in elements as you add them to the DOM, something that previously needed JavaScript trickery to achieve. In this article, we'll go over how to use @starting-style and how to debug it in Polypane. Once you get the mental model, it becomes very easy to use, and lets you create smooth animations for elements as they are added to the page, without needing any JavaScript.

@starting-style is supported across Chromium, Firefox and Safari and has been since 2024. It's ready to use!

Despite @starting-style being implemented since the very end of 2023 (in Chromium, which Polypane uses), debugging it became available only in the Chromium DevTools in version 143, released in November 2025. Polypane on the other hand, has supported inspecting, editing and debugging the @starting-style at-rule since Polypane 20 released all the way back in June of 2024, over a year and a half earlier.

Why did Polypane get support for this so much earlier? Because Polypane is built for web developers, not browser developers. That seems like splitting hairs, but it has a direct impact on how we approach devtools for new features. First, though, let's look at what the @starting-style at-rule is and how it works.

The problem @starting-style solves

When the browser animates something, it needs to know two things:

Where to animate from
Where to animate to

When an element is already in the DOM, and you change its style, the browser can easily figure out both of these things. The "from" is the current state of the element, and the "to" is the resolved, computed new styles. Add a transition time and the browser can animate between the two.

When an element is added to the DOM, however, there is no "from" state. There is nothing, and then there is something. The browser only knows the "to" state, the resolved styles of the element. The browser doesn't know where to animate from, so it just snaps the element into place without any animation.

Previously, you had to add the element hidden (opacity 0, height 0, off-screen), then reveal it after it was added to the DOM. This gives the browser a "from" and a "to" state to animate. Having to do any animation like this in two stages is a pain and it also means you needed JavaScript.

@starting-style solves this issue by letting you define that "from" state directly in your CSS.

How to add a starting style

To add a starting style to an element, you use the @starting-style at-rule in your CSS. It's easiest to use CSS Nesting for this. The syntax looks like this:

div {
  size: 50px;
  height: 50px;
  border-radius: 5px;

  background: green;
  opacity: 1;

  transition: all 1s ease;

  @starting-style {
    filter: blur(5px);
    background: red;
    opacity: 0;
  }
}

The "to" state is what you want the element to be styled as. In this case, a rounded green square. And the "from" state is the stuff in the @starting-style block: the background color starts as red, the opacity starts at 0 and it's blurred. When you add this div to the DOM, it will transition from a blurred transparent red square to a solid green one.

I'll admit that an "at-rule" without anything after it looks a bit odd (like only writing @media without the media query), but that's because @starting-style doesn't need parameters.

You get used to it.

Keeping the `@starting-style` separate and dealing with specificity

If you want, you can keep the @starting-style separate as well:

div {
  size: 50px;
  height: 50px;
  border-radius: 5px;

  background: green;
  opacity: 1;
  transition: all 1s ease;
}

@starting-style {
  div {
    filter: blur(5px);
    background: red;
    opacity: 0;
  }
}

If you look at the above code sample you might be tempted to place the @starting-style block before the regular styles to make it clear you're going from those first styles to the regular styles. Unfortunately, that won't work. @starting-style itself has no specificity (like any at-rule), so the div selector inside it has the same specificity as the div selector above it.

When specificity is the same, the last specified one wins, so if the @starting-style was first, its styling would always be overwritten by the "to" styling from the declaration below it, and your animation would never play.

You define the "from" styles last to deal with specificity, and the browser makes sure to only apply those styles initially for the animation, and then remove them once the animation is done.

Inspecting and debugging the starting style

To debug the @starting-style at-rule in Polypane, inspect the element by holding ⌥ and clicking it. This opens up the elements panel with all the styles that apply to the element, including the @starting-style styles. If you're reading this article in Polypane, try it with the demo above!

These styles can be edited and changed like any other styles, with changes applied directly just like editing any other CSS property.

Because they are only applied to the "from" part of the animation, to see them in action you have two options. For the demo above: press the button to add a new div with the updated @starting-style:

Or force the @starting-style from the Polypane elements panel, which you can do from the same menu that lets you force hover, focus and other element states:

With just those tools, you can easily inspect and debug your @starting-style styles, without needing anything more than the regular elements panel.

You might be wondering why this needs a tutorial, it's literally just "select element, edit styles, see changes". That's kind of the point. It's that simple because of the design choices we made for the elements panel.

Why Polypane's Elements panel makes this so easy

So what's different about Polypane that makes this so easy? It has everything to do with the design choices we made for the Elements panel.

Regular developer tools are built from the viewpoint of people building browsers.

If you build a browser and the devtools to support it, you want to be able to use the elements panel to verify that the browser is showing the correct styles for an element. You want to be able to see the styles that apply to an element in its current state. So the elements panel need to show you the exact same thing the browser is showing you (and only that thing). The devtools implementation only cares about the current state, and that means the @starting-style style declaration is not visible in your styles tab:

Anything that is not part of the page's current state is irrelevant if your elements panel is designed to verify the current state. This is why you also don't see :hover styles in any browser's devtools unless you force a hover state.

This works exactly how you want it to work when you're interested in confirming that the browser is rendering styles correctly. But it creates friction for the actual work of web development, where you constantly need to inspect, compare, and debug styles across different states. In the Chrome DevTools, you need to activate the @starting-style badge to see the starting styles:

Polypane's devtools are different. Polypane's developer tools are built from the viewpoint of web developers. As a web developer, the current state of an element is just one of the states you care about, just like you care about your design at all screen sizes, not just the one your screen happens to have.

Polypane's elements panel is designed to show you all the styles that apply to an element, even if those styles are for states your element currently isn't in, like :hover and :active styles:

This means you can still inspect and edit them without needing to force them first. For the @starting-style at-rule, this means you can see all the styles that apply to the element and edit them directly.

In Polypane you can work with these styles directly and see the changes in real time.

Safari and Firefox do a bit of both

It should be noted that, despite only showing the current state of elements when it comes to states like :hover and :focus, both Firefox and Safari do actually show @starting-style styles directly in the devtools!

While I appreciate that functionality, this inconsistency creates a confusing developer experience. Why show @starting-style but not :hover? Both are non-current states. This means developers have to learn different workflows for different CSS features: you edit @starting-style one way, but :hover styles another way.

Polypane is for web developers, not browser makers

Polypane's more consistent approach means you learn one workflow that works for all states. Whenever new features like this are added, my primary concern when implementing developer tooling is

What do web developers need to know to use this feature effectively?
How can I make it easy for web developers to understand the whole feature in the context of the rest of the page?

The choice to show all styles for an element regardless of state is a direct result of that. As a developer, you want an overview of the styles of an element, because comparing styles between states is a common task when debugging hover effects, animation or transitions.

Yes, if you've spent years following the traditional browser devtools workflow, there's a small learning curve. But the payoff is immediate: you understand your own code better because everything is visible. You spend less time hunting through panels and forcing states.

That's why Polypane had @starting-style support over a year before Chrome DevTools itself: The design choices we made for the elements panel made it the natural, obvious thing to do.

Polypane 28: Project improvements, Elements panel updates and Chromium 146

Tue, 10 Feb 2026 00:00:00 GMT

The first release of 2026 comes with plenty of improvements to Projects, the new Environments feature prevents you from confusing production for localhost, the Elements panel is faster and more powerful than ever, and Polypane now runs on Chromium 146.

Projects

We continue to get really good feedback and user requests on Projects, which helps us prioritize what to work on next. In Polypane 28, we're introducing a new Environments option, Bookmarks are now available in the Browse panel too and Projects, Bookmarks and Environments can now be re-ordered with Drag and Drop, so you get to decide what order they appear in.

Project Environments

When working on any project, you probably have it running in multiple places: locally on your machine, on a staging server/acceptance environment and in production. And you switch between them depending on what you're working on.

And maybe more often than you'd like to admit, you accidentally keep refreshing production in utter frustration because the changes you made on localhost aren't showing up. (yeah, absolutely never happens to me neither).

With the new Projects environments, not only is it incredibly easy to quickly switch between your different environments, the color indicators in the tab and address bar let you see at a glance which environment you're currently working in. For example, my localhost is always yellow:

Each environment can have its own color that is shown in the tab, the address bar and the environment switcher. At a glance you immediately know which environment you're working in, and you're never stuck refreshing production waiting for changes you've made on localhost to show up.

Switching between environments makes it easy to keep the same context while testing your site in different setups: switching the environment will keep you on the same page, just on the different domain.

Switch to specific environments using the environment switcher, or middle click the icon to simply advance to the next environment in the list.

This feature has been on our backlog since early 2025 and having used it in the past few weeks I can say it's a much bigger productivity boost than I anticipated.

Want to try Environments? Start your free 14-day trial. No credit card required.

Learn more about Project Environments →

Project, bookmarks and environment reordering

You can now reorder Projects, Bookmarks and Environments using drag and drop. Just grab the item you want to move and drag it to the desired position in the list.

For projects, this can be done right in the project switcher so you can put the projects with the highest priority on top.

Bookmarks and environments can be reordered in the Project editor, again using drag and drop:

Color indicator for panes

The color indicators for domain and tab overrides were only shown in the tab and address bar. In Polypane 28 we now also show this for any pane that has navigation sync disabled. When you're comparing multiple environments in a single tab, this makes it easy to see which environment you're currently viewing.

Be Inclusive integration

Thr accessibility auditing tool Be Inclusive can now export audit reports as Polypane projects, making it super easy to import your audits into Polypane.

Export your audit from Be Inclusive and load it into Polypane. The target samples you specified in Be Inclusive are automatically added as bookmarks in your project, so you can quickly jump to those pages and test your fixes.

Polypane subscribers get a 15% discount on Be Inclusive! If you have an active subscription, find a discount code on our Deals page.

CLI options

Polypane now has several new and improved command line options, including a completely new --help/-h overview that shows all available options:

You can now open as many URLs as you want when starting Polypane from the command line. Just add them after any options and they will be opened in tabs in the current project.

$ polypane https://polypane.com/docs/ https://polypane.app/support/

You can use --project to switch to a specific project when opening Polypane from the command line,

$ polypane --project=projectname

or you can open a URL directly in a specific project

$ polypane --project=projectname https://polypane.com/docs/

When you try to open a project that doesn't exist, Polypane will now ask if you want to create it. You can also automatically create the project without prompt by adding the --create flag. That will create the project if it doesn't exist yet, and open any URLs in the newly created project.

$ polypane --project=projectname --create https://polypane.com/docs/

Altogether this makes for an incredibly easy way to quickly instantiate new projects from the command line. You could even add this to your scaffolding scripts for new projects and automate the creation workflow entirely.

This new set of CLI options also makes it easy to integrate Polypane in your existing workflows, for example by always opening specific urls in a specific project.

Learn more about CLI options →

Tray/Dock options

On macOS and Windows, you can now right-click the Polypane icon in the Dock/Tray to quickly open or switch to a specific project. This makes it easy to switch projects without having to open the project switcher first.

This feature is not available on Linux because it's not possible to populate a .desktop file with dynamic menu items.

Disabled cache logic improvements

Polypane's cache disabling logic has been improved in Polypane 28. Instead of applying cache disabling to sessions, which could lead to unexpected cache handling in specific panes, we now apply cache disabling directly on the web content instances of individual panes.

What you will notice is that a disabled cache behaves more consistently across all panes and tabs, and that there are fewer instances of stale caching on normal reloads. With this change, cache disabling is more predictable and in line with the 'disable cache' button in the Chrome devtools.

Cache is still enabled by default

Polypane continues to have caching enabled by default. I strongly think the Chromium Devtools feature that automatically disables caching is harming web developers more than it helps them.

It obscures real-world issues that only appear when caching is enabled, and it gives a false sense of security that your site works correctly when in reality it might be broken for your users.

Console panel: console.group support

The Console panel now supports console.group, console.groupCollapsed and console.groupEnd, making it easier to structure your console output when debugging.

Polypane's console is built from the ground up and shares no code with Chrome DevTools so we can support collecting console messages from all panes. Since we can't re-use existing code it took us a while to get this feature in while making sure that the console clearly shows where messages come from and consolidating groups across panes correctly.

Elements panel

When using the Elements panel in Polypane 28 you'll notice how much quicker it shows styles when inspecting elements. What took a few hundred ms now takes less than 50ms for the majority of pages. We've made several performance improvements under the hood that make inspecting elements and switching between them much faster, especially on pages with a lot of styles.

Editing CSS selectors

New in Polypane 28 is that you can click on any CSS selector in the Styles pane to edit it. This makes it easy to refine your selectors or re-apply styles to other elements by changing the selector to match those elements.

Other browser devtools also have this feature, but of course the Polypane developer tools apply the changes live across all panes, so you can see how your changes affect different viewports and devices immediately.

Improved `!important` visibility

!important css properties now have a new design that makes them much more visible than the previous design.

In Polypane 28 both the property name and value have a different color when you use !important, making them much more visible in the list of styles. !important is best avoided of course, but sometimes it's the most practical solution. With this new style highlighting, figuring out what's going on with your styles is a bit easier.

Notable Fixes and improvements

Editing styles on parents nodes were not being applied in Polypane 27.x. This has been fixed in Polypane 28, so changing styles on parent elements now works as expected.

When you're editing the HTML of an element you no longer have to click 'Apply changes', you can also press ⌘ Enter so you don't have to leave your keyboard.

There were some sites where a specific border-radius style would cause an issue with our box model visualisation (which also shows border radius, shadows and positioning). This has been fixed in Polypane 28 so the box model now always renders correctly.

The attributes tab will now check the autocomplete values on input elements and show a warning when an invalid value is used. This makes it easier to spot typos or incorrect values that prevent browsers from autofilling forms correctly.

Learn more about the Elements panel →

UI updates

Polypane 28 includes several UI updates to improve usability and consistency throughout the app.

New macOS installer background

Our macOS installer now features a new background image that aligns with the updated Polypane branding, and we've also made the icons larger.

Panel design updates

Several panels have received design updates to improve their usability and visual consistency. The outline panel has a completely new design for when it's bottom-aligned to make much better use of the space.

The meta panel now keeps the social media preview header visible as you scroll, so you can quickly switch between light and dark previews, overwrite with different domains or reorder and hide specific previews.

Live reload redesign

The live reload panel has been in Polypane since 2019, and it's a beloved feature for many users because it makes testing changes so easy without having to build complex setups.

In Polypane 28, we've redesigned the live reload panel to better fit with the overall Polypane UI. It's now more consistent with the other panels in Polypane and provides more context on the available options.

Learn more about Live reload →

Browse panel

The Browse panel has received several improvements to its ergonomics in Polypane 28. The new bookmarks button lets you quickly open your bookmarks in the Browse panel (even if you've hidden the Project selector). The Browse panel now also has better focus handling for keyboard users, supports default browser shortcuts when focused, and has a new Find in page feature.

Bookmarks in Browse panel

The Browse panel now has a new drop down showing your bookmarks for the current project. This makes it easy to open your bookmarked pages directly in the Browse panel.

Additionally, if you've decided to hide the Project Selector in the tab bar, you can still access your bookmarks from the Browse panel.

Shortcuts

When the Browse panel has focus, 'normal' browser shortcuts, like opening and closing tabs or focusing the address bar, work as expected in the Browse panel instead of triggering Polypane-wide shortcuts. This makes it easier to use the Browse panel as a full browser experience without leaving your keyboard.

Search in page

With the Browse panels primary goal of being a supplemental browser where you can have your docs and references open, having a search feature has been a frequently requested feature. In Polypane 28, you can search in the Browse panel using ⌘ F when it's focused to quickly find text on the page.

Both text and HTML search are supported, and the search results are highlighted on the page as you type.

Learn more about the Browse panel →

Meta panel

We've added several nice improvements to the meta panel along with the design update mentioned earlier.

New Bluesky preview for pages without OG image

When a website doesn't have an OG image defined, Bluesky uses either the description or the page content to create a rich preview. This is quite different from other social media sites, and now Polypane replicates this behavior in the Meta panel. That way, you see exactly what your users see.

Security.txt warning

A while back, the security.txt of our website expired and we failed to notice it until someone reached out to us about it. Polypane 28 now checks the expires date of your security.txt and warns you if it's expired, or if it's about to expire in the next 30 days.

Learn more about the Meta panel →

Outline panel

We've made various updates to the form overview in the outline panel to make testing forms easier.

Autocomplete value

The autocomplete value is now always visible directly below the label, so you can quickly assess if the correct value is being used.

Autocomplete values are automatically checked against a list of valid values for a particular input type and that list is now also aware of the shipping and billing prefixes for address related values. When an invalid value is used, a warning icon shows next to the value so you can see which fields need your attention.

The form overlay now also shows these warnings, making it easier to spot issues when inspecting forms.

Form outline now warns about small font sizes

The form outline now checks the font size of text input elements and warns you when the font size is smaller than 16px, which causes the page to zoom in on iOS devices on input focus. This is a poor user experience on mobile devices, so the warning helps you catch and fix it early.

Form outline expand all details option

You can now click the 'details' header in the form outline to expand or collapse all details sections at once. This makes it easier to get an overview of all issues or warnings in your forms without having to open each section individually.

Learn more about the Outline panel →

Snippets from the command bar

You can now activate and deactivate snippets directly from the command bar. Just open the command bar with ⌘ K and type the name of your snippet to quickly toggle it on or off, or activate it.

This lets you quickly apply (and remove) snippets without having to open the snippets manager, and it's all accessible from your keyboard.

Learn more about snippets →

Page Load performance

We've made several improvements specifically to the page load performance in Polypane 28. Polypane now does less work setting up its various listeners and indexers when loading a page, resulting in faster load times, especially on pages with a lot of elements or complex structures.

Polypane and WCAG updates

Accessibility consultant Jules Ernst has updated his overview of WCAG success criteria and how Polypane helps you test for them.

Check out the updated Polypane and WCAG overview on his site for the latest information.

Chromium 146

Polypane 28 is built on Chromium 146. For all the experimental features enabled in this release, check out the experimental web platform features overview.

Get Polypane 28

Polypane is available for Windows, Mac and Linux in 64 bit and ARM versions.

Polypane automatically updates on Mac, Windows and on Linux when using the AppImage. Otherwise, go to the download page to download the latest version!

Don't have Polypane yet? There is a 14 day trial available.
Try it for free. No credit card needed.

Polypane 28.0.3 Changelog

Fix Issue preventing Mac users from auto-updating

Polypane 28.0.2 Changelog

Improvements

Improved Added cmd/ctrl+shift+d shortcut to reload all debug tools (Thanks Florian!)
Improved Snippet manager UI improvements
Improved Outline panel: now ignores hidden headings for duplicate content checks
Improved Outline panel: Improved logic for aside elements in sectioning content (Thanks Eric!)
Improved More resilient build and update internals
Improved Elements panel: Improve performance for large DOM trees
Improved Context menu performance in browse panel
Improved Peek now shows the currentSrc for videos
Improved Meta panel: Warn when the og:url is not the same as the canonical or page url
Improved Breakpoints no longer list negative value widths
Improved Breakpoint panes adhere to the minimum pane width
Improved Reduced installer download size by an average of 25%
Improved Updated list of Google Fonts
Improved Updated Chromium to 146.0.7680.31

Fixes

Fix Prevent Polypane shortcuts overwriting global ones on app launch (Thanks Benoit!)
Fix Elements panel: issue where autocomplete cleared the typed value when adding attributes or css values
Fix Color picker not setting correct background color when inspecting from Elements panel
Fix Snippets: Last save location is now correctly remembered when saving snippets
Fix Install extensions from suggestion box when you have multiple sessions
Fix Reinstate sync engine after main window reopen on macOS

Polypane 28.0.1 Changelog

Improvements

Improved Environments switcher: Add cmd + click as option to cycle through environments for mac (Thanks Nicolas!)
Improved Meta panel: Improved Bluesky preview for pages with missing og info (Thanks Matija!)
Improved Outline panel: Form list now also indexes role=form
Improved Address bar now recognises localhost paths as valid urls (Thanks Harald!)
Improved Portal: You can now middle-click the icon to close the portal
Improved Peek: Improved area rendering logic

Fixes

Fix Elements panel: prevent collecting styles too fast for CSS-in-JS libraries to apply (Thanks Lara!)
Fix Elements panel: Show force starting-style option for styles nested inside starting style
Fix Elements panel: Calculation error in box model (Thanks Bramus!)
Fix Elements panel: Currently selected element could not be collapsed by mouseclick (Thanks Harald!)
Fix Meta panel: Breadcrumbslist microdata with single item would break updates (Thanks Marc!)
Fix Environments dropdown: Prevent horizontal scroll in dropdown

Polypane 28 Changelog

Full changelog (yes, there's more!):

New

New Environments for Projects
New Elements panel: Edit CSS Selectors
New Console: Support for console.group (Thanks Giles!)
New Command bar: Activate or deactivate snippets from the command bar (Thanks Eric!)
New Chromium 146.0.7650.0

Improvements

Improved Projects, Bookmarks and Environments can now be re-ordered (Thanks Michael!)
Improved Projects: Open or switch from the CLI (Thanks Marc!)
Improved Projects: Open or switch from the macOS and windows dock/taskbar (Thanks Benoit!)
Improved Elements panel: Constructed stylesheets no longer open browse tabs when clicked
Improved Elements panel: Updated performance when inspecting elements
Improved Elements panel: make !important styles more visible
Improved Elements panel: press ⌘ Enter when editing HTML to apply it
Improved Elements panel: Show warning for invalid autocomplete values
Improved Elements panel: Support for ::search-text pseudo-element styling
Improved Meta panel: Improved UI
Improved Meta panel: Handle broken link tags on pages
Improved Meta panel: Link meta tags containing URLS are now clickable
Improved Meta panel: Show the type of 'alternate' link tags
Improved Meta panel: New Bluesky preview for pages without OG image
Improved Meta panel: Show warning if security.txt is expired
Improved Meta panel: Allow webp for og images
Improved Meta panel: Updated Discord designs
Improved Outline panel: Form outline warns about small font sizes
Improved Outline panel: New bottom-aligned panel layout
Improved Outline panel: Support shipping and billing values in Form autocomplete
Improved Outline panel: Expand all details option (Thanks Jules!)
Improved Outline panel: show autocomplete warnings in form overlay
Improved Context menu: Hold ⌘ when clicking 'reload pane' to do a hard reload
Improved Cache: Disable cache now applies to panes instead of sessions
Improved Improved page load performance
Improved Improved tab creation performance
Improved Debug tools: Polypane UI is excluded from placeholdifier debug tool (Thanks Dave!)
Improved Browse/devtools panel: Improve resize performance
Improved Browse panel: Show bookmarks in Browse panel (Thanks Matija!)
Improved Live reload: Redesigned to fit better with Polypane UI
Improved Consistent 'clear input' UI throughout the app
Improved New macOS installer background
Improved Tab customisation UI redesign
Improved Panes without navigation sync now get a color indicator when environments or domains match
Improved Browse panel: Search in page (Thanks Matija!)
Improved Browse panel: Better focus handling for keyboard users (Thanks Matija!)
Improved Browse panel: Support for default browser shortcuts when focused
Improved Rulers: Middle click button to disable rulers quickly
Improved Reference image: updated UI
Improved When setting a new default new pane, the default new layout is updated too (Thanks Michael!)
Improved Form autofilling now has Dutch and Canadian postal code formats (Thanks Maarten!)
Improved We no longer hide the browse and devtools panels when drop downs overlay them
Improved Emoji pickers now always start with search, and default to Unicode 16 emojis
Improved Accessibility panel: Update ruleset
Improved Updated list of Google fonts

Fixes

Fix Prevent UI from breaking when there are many open tabs (Thanks Ron!)
Fix Projects: prevent duplicate project names
Fix Browse panel: Prevent issue where new tabs could not be created
Fix Snippet panel: Prevent stale focus outlines after use
Fix Elements panel: Box model would sometimes not render (Thanks Scott!)
Fix Elements panel: Updating parent styles works again (Thanks Scott!)
Fix Outline panel: Make sure numbering and focus arrows are visible again
Fix Outline panel: Prevent link errors from being clipped
Fix Outline panel: Show broken links now filters list again
Fix Outline panel: Tracking button in detached panel works again
Fix Outline panel: Detached panel did not always get new data
Fix Outline panel: add missing street-address autocomplete value
Fix Outline panel: correctly support autocomplete on implicitly typed input elements
Fix Storage panel: Fix bug where session could not be accessed for initial panes
Fix Meta panel: Robots.txt duplicate warning layout issue
Fix Bookmarks: Middle clicks open new tab
Fix Context menus in Chrome devtools panel not showing
Fix Emulation: Correctly show the current network throttling profile
Fix Emulation: scrolled settings no longer prevent tabs from being clickable (Thanks Dave!)
Fix Update measured screenshot button correctly on activation
Fix Background color of overview screenshots did not match UI
Fix Request new permission on launch to allow sites to use desktopCapture on macOS

Understanding the fundamentals of CSS Layout

Thu, 22 Jan 2026 00:00:00 GMT

When developers say that CSS is hard, they're usually talking about CSS layout. What often gets omitted though is that developers are assumed to understand and effectively use CSS without being taught how it works in the first place.

I think this is because the syntax of CSS is simple, especially compared to JavaScript and even to HTML.

select-thing-here {
  guess-a-property: give-it-a-value;
  /* ...and repeat */
}

It leads to the impression that all you need to write CSS is to understand the syntax and have a reference for the properties and values.

That, of course, is not true.

Imagine if you were assumed to learn JS by just looking at its syntax. How would you ever learn what this refers to, or how closures work, or how prototypal inheritance works? It would make no sense!

CSS is no less deserving of understanding its underlying concepts, so let's build that foundation.

Prefer video?

This article is a written version of a talk by Kilian Valkhof, Polypane's creator. You can watch the video here:

Interested in having this talk at your conference or meetup? Get in touch!

Gall's law

When you look at CSS as a whole, it's a complex system that is hard to understand. But it's also a system that works.

We have a programming principle that covers that:

All complex systems that work, evolved from simple systems that worked.

This is known as Gall's law, and it applies to CSS layout as well. At its core, CSS layout is built on a few fundamental concepts that work together to create the complex layouts we see on the web today.

CSS Layout started out with a single layout algorithm called normal flow.

Normal flow has a few basic rules, which all subsequent layout algorithms built upon. Indeed, that's the first lesson:

CSS has multiple layout algorithms.

Specific properties in CSS let you opt into different layout algorithms, each with their own rules and behaviors.

Once you understand the foundation of normal flow, you can start to understand how other layout algorithms like positioning, Flexbox, and Grid build upon it.

In other words, this article will help you go from this:

…to this:

Are you ready?

Everything is a box

The most fundamental concept in CSS is that everything is a box. Every element creates a rectangular box, and the x and y position of the box, along with it's width and height create the combined layout on the page.

CSS is:

A bunch of boxes,
placed on the screen,
according to layout algorithms.

This might seem like an obvious statement, but it's important to understand: before screens became ubiquitous, the idea of a "live" layout algorithm wasn't really needed. Boxes didn't interact with each other. They were put in a place and then just ...stayed there.

Print pages are laid out of course, and have been for centuries, but that didn't really happen in real time by a system of rules, an algorithm.

So, CSS is a bunch of boxes. The initial layout algorithm that places them on the screen is:

Normal flow

Normal flow is the default layout algorithm in CSS. It's what you get when you don't explicitly opt into any other layout algorithm.

It comes from when the web was made for document sharing, and "normal flow" refers to the way text flows across a page: from left to right, from top to bottom (for western languages).

/* Normal flow is the default - no CSS needed! */

From left to right is the inline direction, from top to bottom is the block direction. So text characters will be inline, side by side, and wrap to the next line. Paragraphs and headings are block, and they stack vertically.

Inline →

Block →

Browsers ship with a default stylesheet that dictates which elements are block and which are inline: <p> is block, but <em> is inline.

So that's why, if you write semantic HTML, the browser already makes your page look like a document.

Non-western languages

Not all languages are written left to right, top to bottom. Some languages are written right to left (like Arabic and Hebrew), and some are written top to bottom (like traditional Chinese and Japanese).

This is why CSS has a writing-mode property that lets you change the inline and block directions to fit the language you're using.

Along with that writing mode, many of the explicit directional and sizing properties, like "left" or "height" now have logical equivalents. Instead of left, which for western languages is the start of inline text, the property name is inset-inline-start. Instead of height, which is the size in the block direction, the property name is block-size.

Writing CSS with these logical properties makes them more portable. For this article though, we'll stick to the physical properties like left and width for simplicity.

Formatting context and anonymous boxes

Block and inline tell you how a given element lays out in comparison to the elements around it. This state of being block or inline is called the formatting context, and each element has a formatting context.

But not everything is an element. Consider this HTML:

<p>This is <em>emphasized</em></p>

<p> is a block element and <em> is inline.

But what about the words "This is"? How does that work?

Earlier I wrote that in CSS, everything is a box, and that's also how normal flow solves this. The browser creates something called an anonymous box around that text. In this case because <em> is an inline box, the anonymous box will also be inline: it will be an anonymous inline box.

<p>This is <em>emphasized</em></p>

With that, the browsers now has two inline boxes, and it knows what do to with that. It can lay them out next to each other.

If the code was this though:

<div>
  This is
  <p>a new paragraph</p>
</div>

Both the <div> and <p> are block-level, so the anonymous box generated for "This is" will be an anonymous block box, and the browser can lay out the two boxes on top of each other:

<div>
  This is
  <p>a new paragraph</p>
</div>

Whitespace and anonymous boxes

This anonymous box generation is why some things you might expect to work don't. Take this example.

<div>
  <div class="half">First</div>
  <div class="half">Second</div>
</div>

.half {
    display: inline-block;
    width: 50%;

    background: hotpink;
}
.half + .half {
    background: dodgerblue;
}

Both divs are 50% wide, but they don't sit on the same line. Even though 50% + 50% is 100%.

This is caused by an anonymous inline box created by the newline, the whitespace, between the two divs. That inline box takes up space (the width of a single space character) to the right of the first div, and so the second div no longer fits on the same line:

First

Second

It would be great if we can select that anonymous box and hide it but unfortunately that's not something we can do with CSS.

We can only target named boxes.

Solving the whitespace issue

We can solve this whitespace problem in several ways:

Remove the whitespace

Remove the character space between the two divs, and the anonymous box is never created (...until you run prettier on your code).

<div>
  <div class="half">
  </div><div class="half">
  </div>
</div>

First

Second

Disable wrapping

.container {
  white-space: nowrap;
}

First

Second

When you disable wrapping, you force both divs on the same line regardless of the width of the container. Notice that there is still that space between the two divs, they don't sit flush against each other and that the second div overflows the container.

Since the total width is still 50% + the width of a space character + 50%, the second div overflows the container.

Set the font-size to 0

.container {
  font-size: 0;
}
.container > div {
  font-size: 16px; /* Reset for children */
}

First

Second

If you set the font-size of the parent to 0, the anonymous box will still be created, but it won't have any width since the width of a space at font-size 0 is 0.

If your child elements have text in them, you will need to reset the font size in them or your text won't show up either.

White-space-collapse: discard (in the future!)

.container {
  white-space-collapse: discard;
}

First

Second

To show you how much CSS is still being worked on, white-space-collapse is part of the newest CSS specification, text level 4.

The value we mention above, 'discard', isn't even supported in any browser as of January 2026. So this is a feature for the future and doesn't work yet.

Even normal flow, which has been around since literally the beginning of CSS, is still being worked on!

The box model

We're not done talking about boxes interact by a long shot, but for the next few concepts we need to understand how boxes themselves are built up. For that we need to talk about the box model.

You have probably seen a version of this diagram before. A box in CSS actually consists of a few distinct areas.

The center area is where you content is, the text or child elements. This content is pushed inwards by the padding. The edge of a box is called the border, and outside of the border is the margin which pushes a box away from other boxes.

margin

border

padding

content

For stupid browser reasons there are two models when it comes to determining the size of a box when you give it a width: content-box and border-box.

One of those is the default in browsers, and the other one makes sense.

Content-box

The default is content-box. In that model, width is applied to the content-box, and padding and borders are added to it for the final rendered width.

margin

border

padding

content

Actual width = width + padding + border

This is confusing because when you set width: 200px, the actual rendered width might be 250px after padding and borders.

Border-box

To improve this situation, most modern CSS resets include the following CSS

* {
  box-sizing: border-box;
}

With border-box, the width you set is applied to the border-box of the element, so it includes the border and padding layers. The space for the content is width minus padding minus border.

margin

border

padding

content

Actual width = width

This means that when you see width: 200px in your CSS, you know the element is actually 200px wide regardless of the padding and border. It's much easier to work with.

Try editing the values in the example below to see how content-box and border-box differ. Notice that both boxes have the same width value (200px), but the content-box is physically larger because padding and borders are added outside the content width.

<div class="content-box">Content Box</div>
<div class="border-box">Border Box</div>

div {
  width: 200px;
  padding: 20px;
  margin-bottom: 1rem;
}
.content-box {
  box-sizing: content-box;
  border: 5px solid blue;
  background: lightblue;
}
.border-box {
  box-sizing: border-box;
  border: 5px solid green;
  background: lightgreen;
}

With this understanding of the box model, we can go back to talking about how boxes interact.

How inline boxes work

Everything in CSS is a box, but "box" isn't always what you expect.

A block box makes sense: the element is a rectangle, and the border sits on all edges.

But inline elements can wrap to the next line without becoming a block element, and so the box around an inline element is split up and looks, well, kind of broken:

The top and bottom borders are drawn for each line the element spans, while the inline borders and padding (left and right) are only drawn at the very start and very end.

That looks really broken, doesn't it? Browsers render an inline element as one, long, single line (it's inline after all), and then they slice that up into different line segments where it wraps. Thinking about it in that way makes it a bit easier to visualize what is happening and why it's happening. The box is sliced up into different parts.

Decorations

If you have "decorations" (which is what borders and padding are called) on an inline element, you probably expect those to be applied to each line segment.

Luckily, we can tell browsers how to treat each broken-up line with box-decoration-break. The default value is slice, which is quite literally slicing up the box into different parts.

But you can also tell the browser to treat each line as its own box with clone. Each line becomes its own box with borders and padding on all sides.

span {
  box-decoration-break: clone;
}

Placement of inline elements

Some things like vertical margins, explicit widths and height don't apply to inline elements. This is because when an element is "in line", it's placement on the page is determined by the line it's in. So we know text is "in line", but what's a line?

Lines and baselines

Browsers started out as a way to lay out lines of text. The inline text inside a box is laid out in a number of lines, and these lines are laid out based on the line-height:

What are lines in browsers?

Within each of these lines there is a baseline. The baseline is determined by the font you use, and it's the bottom of your text characters (except for descenders, which go below the baseline).

What are lines in browsers?

What you should understand here is that:

Inline elements are laid out in lines
Each line has a baseline
The baseline is determined by the font
All inline elements align with the baseline by default.

IF you want your text to be in a different place (vertically) in the line, you can change the vertical alignment of an inline element with vertical-align.

span {
  vertical-align: baseline; /* default */
  vertical-align: top;
  vertical-align: middle;
  vertical-align: bottom;

  vertical-align: text-top;
  vertical-align: text-bottom;
}

The top and bottom values are determined by the line height you set on the element:

topBaselinebottom

The text-top and text-bottom are determined by the font. Text-top will align the x-height with the top of ascenders (the parts of letters like b, d, f, h that extend above the x-height), and text-bottom will align the bottom of normal letters with the bottom of descenders.

text-topBaselinetext-bottom

Lastly, middle is weird.

It's calculated from a combination of the font metrics and the line-height, and that causes it to not always mean the exact middle of the line:

middle = baseline + (x-height / 2)

In the example below, you can see that the word "middle" is actually closer to the bottom of the line than to the top.

Baseline middle

I'd like to apologize for that on behalf of CSS.

For practical purposes, just know it exists but might not behave exactly as you expect.

From the explanation above, what you need to remember is that, by default, all inline elements sit on the baseline.

Inline elements sit on the baseline

With that knowledge, does the following situation already make sense?

If you now find this obvious, then good job! The inline image is sitting on the baseline, and that's why there is 'unexpected' whitespace below it.

In the past, you might have fixed that by setting display: block on the image, but this has other layout effects too:

img {
  display: block;
}

The whitespace is gone, but the image now also no longer sits inline with any text, nor does it follow the text align.

Another way you could have fixed this is by setting line-height: 0 on the parent:

div {
  line-height: 0;
}

If the line-height is 0, then the space below the baseline is also 0, so the whitespace is gone. If you have other text in the parent, that text will also be affected and could even start overlapping.

'Fixing' images

The easiest 'fix' in this case it to simply move the image off the baseline, for example by aligning it to the top or bottom of the line instead:

img {
  vertical-align: top; /* or bottom */
}

The bottom of the image no longer sits on the baseline, so there is no longer whitespace reserved below it!

Now that we have discussed inline behaviour and understand how layout happens inside boxes when they're in normal flow, lets move outside the box and see how the space between boxes works.

Margin behavior

Margins are outside of an element and you can use them to push boxes away from each other.

gr gerg dg dsgf d gz

For block elements, this happens in all directions. For inline elements, as we previously mentioned, it's the line they sit on that determines their placement. Adding margin to inline elemens will only apply in the inline direction (left and right).

Margin collapse

When there are two block elements with margins stacked vertically and there are no other box parts (like border or padding) between them, the larger margin of the two is picked and they 'collapse' into each other.

.hotpink {
  margin-bottom: 1rem;
}
.dodgerblue {
  margin-top: 2rem;
}

We've made the margins semi-transparent here so you can see how they actually overlap, or 'collapse', rather than add up.

This happens when any two elements in the same formatting context (remember that one?) have margins that interact.

Margin collapse between parents and children

Elements and their children also share a formatting context, and that is why you also get margin collapse between parents and children.

You might add a margin to the first element inside a parent with the idea of pushing that element down from the top of the parent element, but due to margin collapse that margin is applied outside of the parent, rather than pushing down the first element.

.parent {
  margin-top: 1rem;
}

Hello there

You'll frequently want to prevent this, and while there is no explicit margin-collapse: none property, You can instead prevent margin collapse or create a new formatting context.

Firstly, adding a padding or a border, no matter how small, to the parent element will prevent margin collapse since the margins are no longer adjacent.

.parent {
  margin-top: 1rem;
  padding-top: 1px;
}
.child {
  margin-top: 3rem;
}

Hello there

And while this works, you can see that 1px of padding is affecting the layout. This might matter, or it might not.

another way is to use overflow: auto (or hidden) on the parent element. This creates a new formatting context inside the element, and now the element and the child element are in different formatting contexts, which prevents margin collapse.

.parent {
  overflow: auto;
}
.child {
  margin-top: 3rem;
}

Hello there

Overflow auto will prevent other elements from being shown outside of the parent element, and when you have restrictions on the width or height of the element, it will show a scrollbar when the content overflows.

The explicit option is to define the parent as a new formatting context, which you can do with display: flow-root.

.parent {
  display: flow-root;
}
.child {
  margin-top: 3rem;
}

Hello there

flow-root is a bit of a magical property that creates a new block formatting context without affecting other layout aspects of the element. It's a great way to prevent margin collapse without side effects.

Negative margins

Margins can also be negative. When you use negative margins you're not adding space between element, but you're changing the position of the element itself in a way that no longer interacts with the elements around it.

.top {
  margin-bottom: 1rem;
}
.overlap {
  margin-top: -2rem;
}

The way they get calculated is by taking the margin value, which can also be collapsed, see how the two margins overlap, then subtracting the negative value and starting the new element there.

Negative margins exist, but you're better off ignoring them and using positioning instead for overlapping layouts. (More on positioning later.)

Centering block elements with margin: auto

You can use margins to center elements horizontally by setting the left and right margins to auto:

.block {
  width: 200px;
  margin-left: auto;
  margin-right: auto;
}

This element gets centered because the layout for horizontal margins uses a constraint-based layout when either width or margin is set to auto.

A constraint-based layout means that there is a formula that gets solved to determine the layout. The rule is:

total width = margin-left + border-left + padding-left + width + padding-right + border-right + margin-right

Because borders and paddings are fixed values we can leave them out and instead simplify it to this:

available space to fill out = margin-left + width + margin-right

Let's see what happens when we plug in different values for the width and margins into this formula.

Case 1: everything is set to auto

When all three values are set to auto, the width takes up all available space, and both margins are set to 0.

.block {
  margin-left: auto;
  margin-right: auto;
  width: auto;
}

This is because the "preferred width" of a block element is 100%. So the equation becomes:

total width = 0 + 100% + 0

Case 2: the width is auto

If you have values for both margins but aren't defining with, then the width takes up all remaining space between the two margins.

.block {
  margin-left: 2rem;
  margin-right: 2rem;
  width: auto;
}

This is because the preferred width is still 100%, and the constraint then makes this formula:

total width = 2rem + (100% - 4rem) + 2rem

Case 3: the width is fixed

When the width is fixed and both margins are set to auto, the remaining space is divided equally between the two margins.

.block {
  width: 50%;
  margin-left: auto;
  margin-right: auto;
}

This is because the equation becomes:

total width = 25% + 50% + 25%

Case 4: width and one of the margins are fixed

When the width is fixed and one of the margins is also set to a fixed value, the other margin is set to the remaining space.

.block {
  width: 200px;
  margin-right: 50px;
  margin-left: auto;
}

The equation becomes:

total width = (100% - 250px) + 200px + 50px

The browser calculates the remaining space as 100% - 250px and adds it to the left margin, and so even though block elements normally start at the left edge of their container, this one is pushed to the right even though it doesn't have a specific value for margin-left.

Inline-block: The hybrid

There's one last trick normal flow has: display: inline-block.

Given all the time we spent figuring out the differences between inline and block elements and how their specific behavior differs, what even is inline-block?

Inline-block tells the browser that an element behaves as inline for the formatting context around it, but is &rendered as a block box, creating its own formatting context.

.tag {
  display: inline-block;
  padding: 5px 10px;
  margin: 5px;
  background: dodgerblue;
  width: 250px;
}

text text text

We have a bunch of text that wraps across lines.

More text text text

You can see that the element sits inline with the rest of the text and you can even see that the text is placed on the same baseline, but the element itself behaves as a block element, since it has a width, padding on all sides and the content inside of it wraps to multiple lines.

The CSS specification calls this behavior "shrink-to-fit". Before Flexbox, this was a great way to render things like a list of tags or navigation items:

.nav-item {
  display: inline-block;
  padding: 5px 10px;
  margin: 5px;
  background: dodgerblue;
}

Home

About

Contact

Display values: outer and inner

The display property can have two parts: an outer and an inner value. inline-block as a value is from before this was introduced, but in "modern" CSS it's equivalent to:

display: inline flow-root;

The outer value is how the element behaves in relation to other elements, so inline, and the inner value is how the element behaves in relation to its own content. We want that to have a block formatting context. You don't set that with "block", but with flow-root. Think of it as "a new 'normal flow' starting point".

When you set a single item, that item is either for the inner or outer value depending on the value: some are inherently outer values, and some are inherently inner values. For example display: grid creates a grid for the content, and the outer value is inferred to be block, making it the same as display: block grid. display: inline on the other hand is inherently an outer value, so the inner value is inferred to be flow, making it the same as display: inline flow.

flow-root and flow are the two new keywords here and they are roughly equivalent to block and inline, but only for the inner value.

That's Normal Flow

CSS's simplest layout algorithm! Would you have expected that there was so much behind something that you can essentially describe as "text goes from left to right, top to bottom"?

The good news is that all other layout algorithms build upon these concepts. In fact, unless you explicitly take an element "out of flow", elements are still considered "in flow" regardless of what other layout algorithm you use, and the normal flow algorithm is used in addition to it.

Key takeaways for normal flow

Block elements stack vertically (↓)
Inline elements flow horizontally (→)
Everything is a box
Anonymous boxes get created for text outside of elements
Margins collapse vertically
All inline elements sit on the baseline

Other layout algorithms

To get any other layout algorithm, you need to opt into them. There are three main layout algorithms in CSS:

Positioning (relative, absolute, fixed, sticky)
Flexbox
Grid

There's a few more, like table layout, floats and multi-column, but the first two are hacks that we haven't needed in well over a decade, and multi-column is too niche for this already long article (and indeed, might soon be replaced by the masonry-style grid layout algorithm).

A small detour: sizes in percentages

Before we dive into the other layout algorithms, we need to talk about percentages. When you use a percentage value for a size or a margin, padding etc, what is that percentage based on?

div {
  width: 50%;
  height: 25%;
  margin: 10% 5%;
  padding: 5% 2.5%;
}

Well, for width and height (and their min and max and logical equivalents), percentages are based on the size of the containing block. So 50% width is 50 percent of the width of the containing block, and 25% height is 25% of the height of the containing block.

Hold up, containing block?

So we have offset parents, stacking contexts and now also "containing block".

The containing block is the box that contains the element. For most elements, this is the content-box (remember the box model) of the first parent element that is display: block.

For position: absolute elements, it's the padding-box of the closest stacking context, and for position: fixed elements, it's the viewport.

Those last two are exceptions but in practical use those exceptions actually result in elements sizing in ways you would expect.

Percentages for margin and padding

For margins and paddings, percentages are always based on the width of the containing block, even for margin-top and padding-bottom.

That's a bit confusing, but it's because of how the rest of CSS works. Most elements have a vertical size that changes based on their content: the more lines of text you add to a paragraph, the taller it gets.

If you were able to add a padding-top based on a percentage of the height, then that would increase the absolute height of the element, which in turn would increase the padding-top's absolute value, which would then update the height of the element and so on: it would create an infinite loop.

Instead, having percentages for vertical margins and paddings based on the width of the containing block gives you a predictable value that doesn't change when it causes the height of an element to increase.

Positioning schemes

With positioning, we can tell the browser how to place an element either in relation to its calculated flow position, or explicitly take it out of normal flow. It's also where the third dimension is introduced with z-index. That concept doesn't exist in normal flow, and adding z-index to an element without a position does nothing.

Elements by default have position: static, which means no explicit positioning. To activate the positioning layout algorithm, pick a different value:

static (the default)
relative
absolute
fixed
sticky

Each of these are their own little layout algorithm, so let's go through them one by one.

Position: relative

relative is the basic value that lets you opt in to positioning layout. A relatively positioned element has a box placed in the same spot as normal flow, but you can move the element away from that box using top, left, bottom, and right, which are called inset properties. There's also a inset shorthand property that lets you set all four inset properties at once.

.box {
  position: relative;
  top: 40px;
  left: 40px;
}

text text text

Notice that the original box is the one that takes up space and pushes the text away, but the element itself is elsewhere. The original box is used for the rest of the layout.

This pushing away of the element from it's original box is something you'll rarely want, or need. What you mainly use position: relative for is to make an element an offset parent for absolutely positioned children. Before we get into what an offset parent is, let's explain position: absolute.

Position: absolute

Where elements with position: relative are still in normal flow, position: absolute elements are not. This means they do not interact with other elements: they don't take up space and don't push other elements out of the way.

Inset properties don't move them away from their initial box like relative, they instead position the element in relation to the offset parent.

.box {
  position: absolute;
  top: 40px;
  right: 40px;
}

text text text

The offset parent

The offset parent is the first element in the list of ancestors that is itself also positioned (any position value other than static). By default, the body is the only offset parent. So position: absolute; top: 0; will place an element at the top of the page.

If you add positioning to any parent element, it becomes an offset parent, and now top: 0 no longer means the top of the body element, but of that parent element.

Any element that is positioned will become an offset parent, so you can have many offset parents inside of other offset parents. You're always positioning against the nearest offset parent up the DOM tree.

Finding the offset parent

Layout issues where your absolutely positioned element isn't where you expect it are almost always because what you think the offset parent is is different from what the browser thinks.

To find the offset parent in Chrome, Safari, Firefox etc

Find the element in the element inspector
Switch to the console panel
Type $0.offsetParent and hit enter

In Polypane, you can see the offset parent directly in the element inspector's debug panel.

Find the element in the element inspector
Switch to the debug tab
See Offset parent under "contexts"

Learn more about that in our dedicated article on Offset parent and stacking context (more on that second one later).

Position: fixed

position: fixed is a lot like absolute. Elements are taken out of the normal flow, but in this scheme, the offsetParent is always the viewport, and inset properties are used to position from the edge of it.

.header {
  position: fixed;
  top: 0;
  left: 0;
  right: 0;
}

That means that while absolutely positioned elements scroll along with the rest of the page, fixed elements will always stay in view.

Position: sticky

The last scheme is position: sticky. It was added to CSS much later than the other ones, and it's for elements that you like to keep in view for some part of the time, but still want to scroll along with their offset parent.

With position:sticky, the element will be placed the same way as position: relative, but the top/left/bottom/right values don't move the element. Instead they determine where an element gets stuck relative to the scrolling context, which is usually the viewport.

.sticky-header {
  position: sticky;
  top: 50%;
}

As an element scrolls it will behave like a relatively positioned element, until it hits that inset value where it gets stuck.

Then it will stay stuck, until the offset parent's bottom catches up with it, at which point the element will get unstuck and continue scrolling with it's offset parent.

A tricky thing here is that it will only get stuck if the browser determines it can get stuck. To learn more about debugging sticky positioning, check out our article: Getting stuck: all the ways position sticky can fail

Overview of positioning schemes

So to compare the different positioning schemes, here's a quick overview:

Position	In Flow?	Offset Parent
static	Yes	Not applicable
relative	Yes	Nearest positioned
absolute	No	Nearest positioned
fixed	No	Viewport
sticky	Yes*	Scrollport

* until it gets stuck, then it becomes like fixed.

The stacking context

Remember how I said that with positioning, we introduce the third dimension? Well we haven't talked about that yet.

While the offset parent tells you how an element is positioned in the x and y directions, the stacking context tells you how it's positioned in the third dimension, the z-axis. Or in other words, how close it is to the "front of the screen". And like offset parents, you have stacking contexts inside stacking contexts.

The default stacking context is not the body element, but the html element. So all elements are stacked in relation to the html element by default.

Default stacking order

Elements by default have a stacking order that's the same as source order andz-index lets you reorder them.

div::before {
  background: hotpink;
  z-index: 1;
}
div::after {
  background: rebeccapurple;
  z-index: -1;
}

/* Flip them around: */
div::before {
  z-index: -1;
}

div::after {
  z-index: 1;
}

Reordering happens inside the stacking context

In the example below, the purple element has a z-index of 99, which is (much) higher than the blue element's z-index of just 2. So you'd expect the purple element to be in front of the blue one. However, because the purple element is inside of the pink element with a z-index of 1, it's stuck inside the stacking context of the pink element.

.first {
  background: hotpink;
  z-index: 1;

  .inner {
    background: rebeccapurple;
    z-index: 99;
  }
}

.second {
  background: dodgerblue;
  z-index: 2;
}

So instead of 99 being more than 2, you should actually think of it as (1,99) which is less than 2. No matter how high your z-index is, it will never win from elements in a stacking context with a higher z-index than the stacking context you're currently in.

Creating a stacking context

There's just a few CSS properties that can create a stacking context:

position of fixed or sticky
z-index other than auto (with a position other than static or when in a flex or grid layout)
opacity less than 1
mix-blend-mode other than normal
filter, backdrop-filter, transform, perspective, clip-path, mask, mask-image or mask-box-image other than none
isolation set to isolate
container-type set to size or inline-size (so any container element)
will-change property set to mix-blend-mode, filter, transform, perspective, clip-path, mask, mask-image or mask-box-image
contain set to layout, paint, strict or content

… This makes offsetParent sound easy right? It's quite a lot if you list them all out. Most of these properties aren't used very often though.

The most common ones are:

position
z-index
opacity
transform

Explicit stacking context

Out of the entire list, isolation: isolate is the most explicit way of indicating in your CSS that you're creating a new stacking context:

.container {
  isolation: isolate;
}

A practical stacking context example

Here's a practical example, a simple block quote design with a decorative quote mark. After positioning the quote mark correctly in the X and Y axis we can now see that the quote mark is in front of the text. Because the text itself isn't an element (it's an anonymous box), we can't bring it forward using z-index.

blockquote {
  /* offset parent */
  position: relative;
}

blockquote span {
  position: absolute;
  top: 0;
  left: 0;
}

<blockquote>
  <span>&ldquo;</span>
  Lorem ipsum dolor sit...
</blockquote>

“Lorem ipsum dolor sit amet consectetur adipisicing elit. Tempora tenetur molestias consequatur, quidem nam ipsum minima aliquid recusandae delectus enim.

Instead, we need to bring the quote backwards with z-index: -1:

blockquote span {
  position: absolute;
  top: 0;
  left: 0;
  z-index: -1;
}

“Lorem ipsum dolor sit amet consectetur adipisicing elit. Tempora tenetur molestias consequatur, quidem nam ipsum minima aliquid recusandae delectus enim.

When you do that however, the quote mark disappears behind the background of the blockquote. That's because the current stacking context is still the HTML element. So we need to make the parent element the stacking context.

blockquote {
  isolation: isolate;
}

“Lorem ipsum dolor sit amet consectetur adipisicing elit. Tempora tenetur molestias consequatur, quidem nam ipsum minima aliquid recusandae delectus enim.

The blockquote is now a new stacking context, and the quote mark can no longer go behind the background. Instead, it sits at the beginning of the stacking context inside the blockquote: behind the text but in front of the background.

Finding the stacking context

Finding the stacking context of an element is not as easy as finding the offset parent. Unlike element.offsetParent, there is no element.stackingContext property.

That's why we built a debug panel into Polypane that not only shows you the offset parent, but also the stacking context of the selected element, along with whether the element itself creates a stacking context. It's very neat, and you can learn more about it in our article on Offset parent and stacking context.

The Polypane debug panel

The top section in the debug panel shows you CSS attributes that commonly cause issues, like display, position and z-index.

Below that, it shows the different contexts that the element is in: the offset parent, the containing block and the stacking context.

Lastly, it shows whether the element itself is an offset parent, containing block or stacking context.

These three sections make it very easy to figure out what's going on with the layout of an element, and really speed up your CSS layout debugging.

Grid and Flexbox

That leaves Grid and Flexbox. I'm not going to spend any time on the syntax or specific features of either layout algorithm, instead focusing on how they interact with the previous layout algorithms and concepts like offset parent and stacking context.

For Flexbox, check out Every Layout by Heydon Pickering and Andy Bell or Flexbox Simplified by Kevin Powell. For Grid, check out Grid by Example by Rachel Andrew.

Both Flex and Grid are significantly different from the layout algorithms that came before. That's because they were developed not as a way to lay out web documents, but as a way to lay out web apps.

The key differences

When you look at Flex and Grid, they each approach layout from a different direction.

Flexbox is "bottom up"

Get a bunch of elements
Order them in a row or column
Distribute them according to rules you provide

Grid is "top down"

Create a bunch of areas
Determine their sizes and positions of those areas according to rules you provide
Place elements inside those areas

So Flexbox starts with the elements you have and distributed them, while Grid starts with defining the available spaces and then adding the elementes to them.

Additionally, Flex is fundamentally one-dimensional (though it can wrap to a next line) while Grid is two-dimensional.

Flex and Grid versus normal flow

Both are replacements of sorts for normal flow. They reason about the distribution of multiple elements in a specific way, rather than the positioning of a single element in relation to other elements.

A very big difference between Flex and Grid on one hand and previous positioning on the other hand is that Flex and Grid no longer depend on font properties. The layouts you make and their alignment are based on the generated boxes, not on the font properties of the elements.

This makes a lot of things much simpler.

Both also try to make sure that regardless of the elements inside of them, the layout will be adhered to. In Flexbox this means that if an element has a fixed width, but that width doesn't fit in the space the Flex container has available for it, the elements size will be overwritten to make it fit the Flex layout. In Grid, an elements width and height are constrained by the grid area they're placed in.

Flex and Grid combined with positioning

Both flex and grid are display properties, separate from the position property. This means that the way to determine offset parents and stacking contexts doesn't change.

You can take an element out of a flex or grid layout with position: absolute or position: fixed. Likewise, each element inside a flex or grid container, including the container itself, can be made an offset parent with position: relative or a stacking context with isolation: isolate.

What not being dependent on font properties means

Unline vertical-align: middle which uses the line-height and font properties (as mentioned above) to determine the middle of a line, both flex and grid align based on the boxes they create.

align-items: center in both layout algorithms will align the boxes of the elements in the middle of the flex or grid boxes, regardless of the font properties or line height of the elements.

.grid,
.flex {
 align-items: center;
}

This new type of alignment logic is the same in Flex and grid and it worked so well that it was actually added to display: block as well.

The align-content property lets you vertically center content in block elements, as long as they have a determined height. It was added to CSS Box Alignment level 3 and works across browsers.

.block {
  align-content: center;
}

<div class="block">
  <div>1</div>
  <div>2</div>
  <div>3</div>
</div>

-items and -content

Flex and grid both have align-items, align-content and justify-content properties. Grid also has justify-items. So what is items and what is content?

*-items properties align the individual items, for example inside a grid area.
*-content properties align the items as a group (usually as a row or column).

In the example below, we have a simple grid that has repeating rows of 50px high, and three 1fr columns. In the first/left example, we have align-items: end which aligns the items to the end of their grid area. In the second example, we set align-content: end. This keeps the items the full size of their grid area, but aligns the entire group of items to the end of the container

Grid and position: sticky

Though the way to determine offset parents and stacking contexts doesn't change with Flex and Grid, when you combine Grid and position: sticky, that won't work as you might expect.

The reason for that is the default value that grid has for align-items, which is stretch. That means that the element with position: sticky already is as tall as the grid area and that means that when it reaches that inset value to get stuck, the bottom of the element is already at the bottom of the grid area and so it never gets stuck.

It's easy to miss that, because elements in a grid area without a background or border look like they are not filling the entire area.

An element doesn't have to fill the entire grid area though. You can set align-items: start on the grid container to have all items align to the start of their grid area instead of stretching to fill it, or align-self: start on the element itself

.grid-container {
  /* the default */
  align-items: stretch;

  div {
    position: sticky;
    top: 50%;
  }

  .start {
    align-self: start;
  }
}

stretch

start

Check out our article: Getting stuck: all the ways position sticky can fail for more on this.

The final boss: centering a `<div>`

An age old joke about CSS is that it's impossible to center a <div> vertically.

Now that you know the fundamentals, you know that's not true.

The reason vertical centering is 'hard' is because CSS is built on normal flow, where the height of elements is determined by their content.

If the height is determined by the content, and the content is a single line of text, then the height of the element is the height of that line of text. It's already vertically centered, it's just not the height you want.

With that knowledge, there are actually dozens of ways to vertically center a <div>. But modern CSS gives us one way that's definitely the simplest: place-content.

place-content is a shorthand for the combination of align-content and justify-content and as we mentioned earlier in the article, that works in Flex, Grid and Block elements. For it to work, your element does have to have a defined height (because if not, the contents define the height).

.container {
  height: 400px;
  place-content: center;
}

I'm centered!

That's all it takes. Vertically centering is trivial.

Things we left out

The purpose of this article is to explain the fundamentals of CSS layout, but there are more concepts that can help you understand your layouts that we didn't cover:

Content sizing: how min-content, max-content and fit-content work, and how intrinsic sizing works.
Container queries: how they create new layout contexts.
Aspect-ratio: how it affects sizing of elements.
Subgrid: how it works and how it relates to grid.
Honestly, a deeper dive into both Flexbox and Grid.

Each of these topics deserve their own article and we might cover them in the future.

Conclusion

When you get started with CSS layout, it can feel overwhelming. There are a lot of concepts to learn, beyond the mere syntax and available properties. If you don't take the time to understand those concepts, you'll end up always fighting or guessing your way around designing pages.

CSS is built on a set of small, logical concepts that each are easy to understand, from "text goes left to right, top to bottom" to "everything is a box" to "elements can be taken outside of flow". Each layout algorithm builds upon these concepts, adding new ways to position and align elements to handle more and more complex situations. But the building blocks remain the same.

Understanding these building blocks of layout makes it easier to reason about CSS, to visualize how the browser is going to lay out your page and how to fix layout issues when they arise.

Not All Browser APIs Are "Web" APIs

Fri, 09 Jan 2026 00:00:00 GMT

When we talk about "the web platform", we often treat it as a unified, standards-based system: browsers implement features from the same specifications, even if they do so in different time frames. That should mean that when they're implemented, we can rely on APIs to work the same across browsers, and definitely across browsers using the same rendering engine.

But dig a little deeper, and you'll find that many APIs we rely on aren't actually part of "the web" at all. They're standardized interfaces, but with browser-specific implementations that depend on third-party services, proprietary systems, or vendor-specific infrastructure.

What that means in practice

For example, to use the Geolocation API in Polypane you need to add a Google API key. The same API works fine in Chrome without any configuration, so are we just being annoying?

Actually, the Geolocation API in Chromium uses Google's online geolocation services. While Google Chrome obviously gets to use Google's services for free, other browsers don't.

When we tell people this they're often surprised. Surely web standards wouldn't rely on proprietary services?

Yet they do, and when you think about it, that's even a little insidious. No where does the browser tell you that by using the Geolocation API, you're potentially sending your users' location data to Google (or Apple, depending on the browser).

So let's go over these APIs that are available in (some) browsers, but aren't actually part of the web platform in the way you and I think about 'the web'.

The illusion of standardization

Let's zoom in on that Geolocation API. It looks like a clean, standardized web API:

navigator.geolocation.getCurrentPosition(
  (position) => {
    console.log(position.coords.latitude, position.coords.longitude);
  },
  (error) => {
    console.error('Geolocation failed:', error);
  }
);

The interface is standardized. The specification is maintained by the W3C. The docs on MDN are excellent. But the actual implementation? That's entirely up to the browser vendor.

Where does your location actually come from?

Browsers don't magically know where you are. Behind that clean API, they're making decisions about data sources:

OS service/GPS: On mobile devices, accessing the operating system's location services (often using GPS).
Wi-Fi positioning: Your browser sends nearby Wi-Fi access point MAC addresses to a location service provider. They're hashed first, but still.
IP geolocation: Querying third-party databases that map IP addresses to approximate locations.

In the best case scenario, the browsers calls out to the Operating System's location services, which uses GPS to determine your location. But not all devices have GPS and not all operating systems provide that API. So even when the OS has location services, it still might be using third-party services. All browsers fall back to sending data to a location service provider in the absense of that OS API.

Chrome uses Google Location Services. Safari uses Apple's servers. Firefox had something called Mozilla Location Service but they retired it in 2024 and now also use Google's services.

This means the "web standard" geolocation depends on:

Their integration and access to your device's OS location services
The browser vendor's relationship with location service providers
The quality and coverage of their Wi-Fi database
Their privacy policies around location data
Whether their servers are operational and accessible in your user's region

A PWA relying on precise geolocation might work flawlessly during Chrome testing but fail for users in regions where Google services are blocked.

Speech Synthesis: Shouting from clouds

The Web Speech API seems straightforward, and pretty cool:

const utterance = new SpeechSynthesisUtterance('Hello, world!');
utterance.voice = speechSynthesis.getVoices()[0];
speechSynthesis.speak(utterance);

But where do those voices come from? It varies wildly:

Desktop browsers often use operating system TTS engines (which themselves vary by OS and version).
Mobile browsers might use online services for better quality voices.
Chrome can use both local and cloud-based voices depending on the selected voice and network availability.
Safari primarily relies on system voices but quality varies significantly across iOS and macOS versions.

Whatever voices your user has available depends on the browser, the operating system, and the device, and you're not guaranteed that the voice you selected in testing will be available for all your users.

Some "good" voices only work when you're online because they're processed on vendor servers: your text is sent to a server, processes there and the audio is sent back.

That should give you some pause about what kind of information you're sending to those servers. Are you reading aloud a user's private data or private messages? You might be sending explicitly private data to third-party servers without realizing it.

The API is standardized. The implementation is anything but.

Speech Recognition: Guess where your voice goes

The flip side of speech synthesis is speech recognition:

const recognition = new SpeechRecognition();
recognition.continuous = true;
recognition.interimResults = true;

recognition.onresult = (event) => {
  const transcript = event.results[0][0].transcript;
  console.log('You said:', transcript);
};

recognition.start();

Until recently the speechRecognition API was not available without an internet connection (MDN has a note about this at the top of the page), and that's a clue. Speech recognition in Chrome is powered by Google's cloud speech services in many instances. Your users' voice data is:

Captured by the browser
Sent to Google's servers
Processed by Google's speech recognition models
Returned as text

Safari uses Apple's speech recognition services. Edge might use Azure Cognitive Services. The API looks the same, but:

Accuracy varies based on which vendor's models you're using.
Language support differs dramatically between providers.
Privacy implications: some vendors explicitly use your users' voice data to improve their models.
Offline capability only exists where vendors provide on-device models (basically iOS/macOS).

This is streaming audio of your users' voices to vendor servers in real-time. The "web API" is really just a JavaScript wrapper around vendor speech services.

In more recent versions of Chrome (139, release in August 2025), you can set a processLocally flag to specify it should use local processing instead of sending data to Google's servers:

const recognition = new SpeechRecognition();
recognition.processLocally = true;

It does this by downloading a language pack to the user's device to use for processing. If the specified language pack is not available locally, you'll get an error.

So that's good, however note that it's not the default behavior, and it's only available in Chrome.

Passkeys: a web API built on the browser password manager

The WebAuthn API promises passwordless authentication:

const credential = await navigator.credentials.create({
  publicKey: {
    challenge: new Uint8Array(32),
    rp: { name: 'Example Corp', id: 'example.com' },
    user: {
      id: new Uint8Array(16),
      name: 'user@example.com',
      displayName: 'User Name',
    },
    pubKeyCredParams: [{ alg: -7, type: 'public-key' }],
    authenticatorSelection: {
      authenticatorAttachment: 'platform',
      requireResidentKey: true,
    },
  },
});

The WebAuthn API is a standard, but passkeys only work because browsers have invested heavily in their password management infrastructure. When you create a passkey:

Chrome stores it in Google Password Manager (synced via Google's cloud).
Safari stores it in iCloud Keychain (synced via Apple's infrastructure).
Edge stores it in Microsoft Account (synced via Microsoft's cloud).

Passkeys are not part of the web stack, they're part of each browsers password manager, and only work because browsers have hooked up the APIs to their own password managers. The specification defines the API surface, but the actual credential storage, synchronization, and recovery mechanisms are entirely vendor-specific.

You're not just using a web standard, you're integrating with your browsers password manager (and full authentication ecosystem).

WebAuthn being tied to that built-in password management means Polypane doesn't support passkeys natively. We could build a password manager, but Electron currently has no way of hooking the Passkey APIs into a password manager backend. The workaround here is to use a password manager extension with Passkeys support like 1Password.

Payment Request API

The Payment Request API looks like it standardizes online payments:

// set up a payment
const request = new PaymentRequest(
  [
    {
      supportedMethods: 'https://google.com/pay',
      data: { merchantId: '12345' },
    },
  ],
  {
    total: {
      label: 'Total',
      amount: { currency: 'USD', value: '29.99' },
    },
  }
);

// show the payment UI
const response = await request.show();

But which payment methods work depends entirely on browser vendor partnerships:

Chrome: Deep integration with Google Pay
Safari: Apple Pay
Edge: Microsoft integrations, but often defers to system capabilities.
Firefox: no support.

The supportedMethods field looks like a standard way to declare payment options, but in practice:

You need separate integration contracts with each payment provider.
Browser support for payment methods is often region-specific.
The UX varies wildly: Safari shows a native Apple Pay sheet, Chrome shows its own UI.
Some browsers require additional user setup (like adding cards to Apple Wallet).

You're not building on a payment standard. You're building adapters for each browser's preferred payment partners. Which, for the big three browsers, happen to be... themselves. That's convenient.

Web Push: three different push networks

The Push API promises a standard way to send notifications:

const registration = await navigator.serviceWorker.register('/sw.js');
const subscription = await registration.pushManager.subscribe({
  userVisibleOnly: true,
  applicationServerKey: urlBase64ToUint8Array(publicKey),
});

But when you send that push notification, where does it actually go?

Chrome/Edge: Firebase Cloud Messaging (FCM) - Google's infrastructure.
Safari: Apple Push Notification service (APNs) - Apple's infrastructure.
Firefox: Mozilla Push Service - Mozilla's infrastructure (or FCM on Android).

Each service has different:

Rate limits: FCM allows 10,000 notifications per second per sender, but others have different limits
Message size limits: FCM allows 4KB, APNs allows 5KB for modern devices
Delivery guarantees: Each service handles offline delivery differently
Privacy models: Each service has different data retention and encryption practices

Your push notification doesn't go directly to the user. Instead it routes through the browser vendor's servers first. If Google's FCM has an outage, Chrome push notifications stop working. If your server is in a region where Apple services are restricted, Safari push won't work for your users.

You're not just implementing push notifications. You're integrating with cloud infrastructure.

Media Source API and Widevine: codec politics and DRM dependencies

MSE lets you build custom video players:

const video = document.getElementById('video');
const mediaSource = new MediaSource();
video.src = URL.createObjectURL(mediaSource);

mediaSource.addEventListener('sourceopen', () => {
  URL.revokeObjectURL(video.src);

  const sourceBuffer = mediaSource.addSourceBuffer('video/mp4; codecs="avc1.42E01E"');

  // fetch and append video segments here (not shown for brevity)
});

But which codecs are actually supported? That depends on:

Patent licensing: Browsers ship codecs they're willing to pay for or that are royalty-free
Platform support: Some codecs only work if the OS provides hardware decoding
Vendor strategy: Google pushes VP9/AV1, Apple prefers H.264/HEVC, Mozilla champions open codecs

Safari has limited VP9 support. Chrome's HEVC support depends on hardware availability. Your "standard" video playback depends on vendor decisions about codec licensing, hardware partnerships, and competitive strategy.

So the API is standard, but you're either going to use the lowest-common-denominator codec, or build a complex system that encodes videos in multiple formats and serves the right one to each browser.

The Widevine Problem

Then there's DRM. The Encrypted Media Extensions (EME) API looks standard:

const config = [
  {
    initDataTypes: ['cenc'],
    videoCapabilities: [
      {
        contentType: 'video/mp4; codecs="avc1.42E01E"',
      },
    ],
  },
];

navigator
  .requestMediaKeySystemAccess('com.widevine.alpha', config)
  .then((access) => access.createMediaKeys())
  .then((mediaKeys) => video.setMediaKeys(mediaKeys));

// start a video playback session here (not shown for brevity)

But Widevine isn't a web standard, it's Google's proprietary DRM system. And it's not universally available:

Chrome, Edge, Firefox: Include Widevine by default (through licensing agreements with Google).
Safari: Uses Apple's FairPlay DRM instead, requiring a completely different integration.
Smaller browsers: Often don't have Widevine at all due to licensing costs, technical, legal and business requirements. The licensing barriers are often prohibitive.
Polypane: Supports Widevine (mostly), but we too are at the mercy of whether a Widevine module is available for the OS and hardware you use, as well as it being available in the version of Electron we use.

Streaming services like Netflix, Disney+, and Spotify require not just codec support, but specific DRM and won't work without it.

The way this is currently set up strongly disadvantages smaller browsers and enforces vendor lock-in.

AI APIs

Recently, browsers (Chrome) have started exposing "AI" capabilities directly through web APIs. Google has a number of these AI-backed APIs in development, like summarization, translation, prompting, writing, and proofreading. They have some impressive demos, and clever people working on them.

// Summarization
const summarizer = await Summarizer.create({
  type: 'key-points',
  expectedInputLanguages: ['en'],
  outputLanguage: 'en',
});

const longText = document.querySelector('article').innerHTML;
const summary = await summarizer.summarize(longText, {
  context: 'This article is intended for front-end developers.',
});

// Translation
const translator = await Translator.create({
  sourceLanguage: 'en',
  targetLanguage: 'es',
});
const translated = await translator.translate('Hello world');

The above APIs are not 'web standards' like the previous examples: they're not standardized and they're not available in other browsers. They're an experimental proposal by the Chrome team with the intent of standardizing them later.

The AI features in Chrome are only available in Chrome. They rely on a "small language model" called Gemini Nano, that is downloaded to your device when you first use it (...provided you have enough disk space and a good enough GPU). The model then runs locally on your device.

That's pretty cool, because it means you're not sending your user's data to a server where it can be logged, stored, used for training or sold to third parties. Your users' data stays on their device.

Unfortunately, "small" is only in comparison to the terabyte-scale models that power services like ChatGPT or Claude. Gemini Nano is still 4GB (varies per language) that needs to be downloaded by your user and requires significant compute resources to run effectively. It's also fully proprietary. Only Google gets to use it.

A small model running on a users device means that the same API can be used with a different model in a different browser. Theoretically that's cool.

However, while Microsoft will have no problem to train their own small Copilot model, smaller companies simply don't have the same resources to scrape, steal, build, train and maintain LLM models and pay for the infrastructure to host them and each of their users to download them.

That's simply something smaller browsers and open source projects can't compete with.

Why This Matters

These APIs blur the line between web standards and browser features in ways that have real consequences:

Portability Illusions

Code that works perfectly in Chrome might fail silently in Safari, not because of a bug or because you failed to check for availability, but because the underlying service infrastructure is different. Your geolocation might be accurate in one browser and wildly off in another, even on the same device for the same user.

Privacy Surprises

Your users might not realise that the feature you offer is sending their data to vendor servers. The Speech Recognition API feels local, but you're streaming audio to Google or Apple. Geolocation phones home to different companies depending on the browser. Web Push routes through vendor networks.

Web standards become a way for big players to keep out smaller competitors

The web is a level playing field. The web is open. The web is for everyone. It's an idea we want to be true.

But with the above APIs, the web is not a level playing field. Big players have the resources to build and maintain the services these APIs depend on. They can afford to offer them for free to their users because they have other ways of monetizing them (ads, ecosystem lock-in, data collection).

Standardization should guard against this kind of vendor lock-in. But instead, web specifications are mostly written by the people working for these big players because these companies can afford to employ people to work on specs full-time and employ people to implement the specifications. And when there's implementations, specifications become standards.

The W3C has guards to prevent abuse, but in practice the process is weighed towards the wishes of large companies. The specification process is a way for the big players to entrench their dominance.

Smaller browsers and open source projects either need to rent access to the services that Google, Apple and Microsoft can afford to offer for free or deal with explaining to users why their browser can't offer the same features. This creates feature parity gaps that look as if they are browser bugs to end users.

What this means for developers

The above APIs are really useful. I'm not saying browsers are bad for having more capabilities. These are features we want to offer to our users, and having them "build right into the browser" feels great.

But we need to understand that these APIs are not truly portable web standards, and understand the consequences of using them for our users.

They're abstractions over vendor services, and we should treat them as such. We sign data processing agreements with all our vendors to keep our users data safe. Why does the browser get a pass?

What Should We Do?

As developers, we need to be aware of these realities: the APIs you choose to use come with consequences.

Treat these APIs as abstractions over vendor services, not as truly portable web standards. Document which browsers you've tested with and what the fallback behavior is. Consider feature detection not just for API availability, but for quality and behavior.

Design for graceful degradation. Don't assume geolocation will be accurate, passkeys will sync, speech will sound the same everywhere, or push notifications will be delivered reliably. Build fallbacks.

Be transparent about privacy. If an API might send data to third-party servers, your users deserve to know. Especially if the browser abstracts it away. Document which vendor services your app depends on.

Consider the vendor relationship. When you use these APIs, you're implicitly depending on each browser vendor's ongoing commitment to maintaining their backend infrastructure. What happens if a vendor decides to deprecate a service or changes their pricing model?

This isn't just theoretical: There are vast swaths of web pages with broken Google Maps embeds because Google changed the deal and started requiring API keys (with usage limits and billing) for them.

Test across browsers and regions. That speech recognition that's accurate for you might not support your users' languages.

Plan for vendor lock-in. If you build heavily on one of these features, you're making a strategic choice to depend on that vendor's platform. That might be fine, but make it a conscious decision.

The web we think we have vs. The web we actually have

The promise of web standards is that you write code once and it works everywhere. But the above APIs are really thin wrappers around vendor-specific services.

The interface is standardized, but the implementation, its dependencies, limitations, and privacy implications are not.

When you call navigator.geolocation.getCurrentPosition(), you're not just using a web API. You're using Google Location Services or Apple's location servers. When you send a push notification, you're routing through FCM or APNs or Mozilla's infrastructure. When you use speech recognition, you're streaming audio to vendor cloud services.

The specification says what the function call looks like. But specifications don't tell you:

Where your data is sent to,
How accurate or reliable the results will be,
Whether it works in your users' regions,
What the privacy implications are,
Whether it will still work for free (or at all) next year.

This doesn't make these APIs bad or unusable. It just means we need to design our applications with a clearer understanding of where the standardization ends and the vendor specifics begin.

The web platform is powerful, but it's also more fractured than we often acknowledge. And that's worth keeping in mind every time we reach for an API that looks standard but depends on infrastructure that isn't.

Polypane 27.1: Expanding Portal

Wed, 17 Dec 2025 00:00:00 GMT

Polypane 27.1 is here and Polypane Portal has expanded! The Polypane console will now show the console messages from all connected browsers so you get instant feedback on errors and your own logs. Snippets are now also injected and ran in connected portals. This combination makes Polypane's Portal an even more powerful tool for testing and debugging across multiple browser and real devices. The elements panel and projects have also received a lot of quality of life improvements in this release.

Portal

Polypane Portal is a powerful way to test and debug your site across browsers and devices by making your localhost available to the entire network or even the entire internet with zero setup. Once connected, browsers or devices are kept in sync with Polypane so as you scroll, type, inspect and edit in Polypane, your actions are mirrored in all connected browsers. It's pretty awesome.

Console messages in Portal

In 27.1 all connected browsers now send their console messages back to Polypane where they're shown in the Polypane Console. This means you can now see errors and logs from all connected browsers without needing to open devtools on each device or using other convoluted methods.

Code inputted in the Polypane console is also ran in all connected browsers, so inspecting and debugging is now easier than ever.

Snippets in Portal

When Portal is connected you can opt to run snippets in all connected browsers. Whether you have specific CSS debugging snippets, JS utilities you want to have available on page load or specific JS functions you run through the Snippets panel, all of those can now be ran in your Portal connected browsers too.

Elements panel

The Elements panel has received quite a few improvements in this release to make it easier to use and more powerful.

When selecting an element in the DOM tree, you can now use the arrow keys to navigate around the tree:

Up/Down arrows move to the previous/next line.
Left arrow collapses the current node or moves to the parent if already collapsed.
Right arrow expands the current node or moves to the first child if already expanded.

This is a really quick way to navigate deeply nested trees without needing to click around a lot, and an easy way to quickly move back up the DOM.

When the DOM tree has focus, you can also press h to hide the currently selected element.

Constructed stylesheet editing

You can now edit constructed stylesheets in the elements panel. These are stylesheets that are added to a document or web component root through JavaScript using the adoptedStyleSheets API.

Polypane had support for this in the Elements panel before, but the API for constructed stylesheets has changed (they're no longer available on the shadowRoot) and the implementation had to be updated. You can now again view and edit styles set through constructed stylesheets.

Collapsing unused custom properties

A common pattern has emerged where all custom properties are defined on :root or html to make them available throughout the app. Because of the way the elements panel collects styles, this means that each inspected element had dozens, if not hundreds of custom properties to be rendered in the elements panel.

Because these custom properties often have a color widget, rendering them is relatively expensive and this had a performance impact on the elements panel.

To improve performance, Polypane now initially only renders the custom properties that are used by the selected element and hides the rest behind a "Show unused custom properties" button. Clicking that button will expand all custom properties so you can inspect and edit them as needed. All other places where Polypane shows custom properties, like in the value suggestions, will continue to list all of them for easy access.

This performance improvement was recently added by the Firefox' DevTools team and it was such a good idea that I decided to implement it in Polypane as well.

Filtering computed styles

The computed styles overview now has a filter input at the top so you can quickly find the property you're looking for without needing to scroll through the entire list. Filter on both property names and values.

Hold cmd/ctrl to hide element info

When hovering elements in the DOM tree, Polypane shows a tooltip with information about the element like its dimensions, font, contrast, accessible name and role.

You can now hold the ⌘ key while hovering to show the margin, padding etc while hide the info panel. so nothing is obscuring parts of the page.

Projects

I'm overwhelmed by the positive response to Polypane Projects! It's great to see so many people using this powerful way to manage their work in Polypane, and I immediately went to work to make Projects even better based on your feedback.

Opening the bookmarks panel now focuses a filter input so you can quickly find the bookmark you're looking for. As you type, the bookmarks list is filtered to only show matching bookmarks.

You can also now navigate the bookmarks list using the Up and Down arrow keys to move through the list and Enter to open the selected bookmark in a new tab.

Import/export projects and bookmarks

A new import and export system for Projects and Bookmarks makes it easier to back up you work, share projects with colleagues or move projects between different Polypane installations.

Projects import/export

Projects with all their settings can now be exported to JSON files. These files can then be imported into other Polypane installations to recreate the exact same project structure, settings and bookmarks.

We'll be sharing out the JSON Schema for this soon, so third party tools can also generate Polypane projects for you. Imagine configuring your accessibility audit in an online tool, then exporting it and having all the pages that are part of your audit automatically set up in Polypane!

Bookmarks import/export

Separately Bookmarks are now also importable and exportable. You can export all bookmarks in a project to a JSON file which can then be imported into other Polypane installations.

Additionally, Polypane now supports importing bookmarks from a bookmarks.html, a weird and old format that all browsers support.

This makes it easy to migrate your bookmarks from any browser to Polypane. When importing a bookmarks.html file all non-URL entries (like bookmarklets or browser internals) are filtered out automatically.

Hide project selector button

If you do not need the projects feature, you can now hide the project selector button by going to the settings in the address bar and unchecking "Show project selector". Thanks Artem for the suggestion!

Snippets panel improvements

Snippets are now also available in portal, but the snippets panel itself has also received two quality of life improvements.

Importing Bookmarks.html

You can now import snippets from a bookmarks.html file. The import automatically filters down to the bookmarklets, and adds them as snippets. If your bookmarks has folders, those are also recreated and the snippets are automatically placed in the folder they were in in the bookmarks.html file.

Deleting folders

When deleting a folder in the snippets panel, all contained snippets are now also deleted. Previously Polypane would just move the snippets to the root folder, but this created a lot of additional work when you wanted to delete a whole folder of snippets. Now you can just delete the folder and all its contents in one go.

Any snippet you want to keep can be moved out of the folder before deleting it.

Outline panel

The Outline panel is one of the most used features in Polypane, but heavy pages could feel slow in Polypane as it indexed, analysed and rendered sometimes thousands of links, headings and images parsed from the page, and doing so after every DOM change on the page.

To prevent this performance impact, the outline panel for new tabs now always starts in a paused state. From there you have two options:

Get the outline once by clicking the load button, which fetches the data once and then pauses again.
Enable automatic tracking by clicking the Track button: As the DOM changes, for example through user interaction or scripts running on the page, the outline will update automatically so you're always seeing the actual outline of the page.

This way, you can choose when you want the outline to update automatically, when you want to just get the outline once without impacting performance, and when you don't need the outline at all.

Outline rendering improvements

There are also made a number of improvements to the outline rendering performance so that even when automatic updating is enabled, the outline panel is more responsive than before, especially on large outlines.

Image outline role=img support

The image outline now also includes elements with the role="img" attribute. This is especially useful for SVG images that use this role to provide accessible names and descriptions.

It took a while to find the right solution for this, as elements with role="img" are not transportable like regular image files. They might simply be a HTML div, or SVGs might have external CSS or even import a specific group from an external SVG file.

role="img" elements are shows as a placeholder in the aspect ratio of the element. The outline will show you all the important information like the accessible name and dimensions so you can verify that these images are accessible. Thanks Robbert for the suggestion!

Focus outline accessible name warnings

The focus outline falls back to the text content of an element if it has no accessible name to make it easier to see what element has focus. This is a deliberate choice, but it also can make it seem like an element has an accessible name when it actually doesn't.

The Focus outline will still fall back to the text content to aid the visual identification of focused elements, but now also shows a warning next to elements that have no accessible name so you can easily identify these elements and fix them. Other outlines and the Polypane Peek tooltip have always shown these warnings, so this makes the focus outline consistent with the rest of Polypane. Thanks Ron for the suggestion!

Meta panel

The meta panel now uses the newly released Capo.js 2.0.0 for its head order overview. Capo 2 is smaller and faster.

Marker.io integration update

The Marker.io integration needed an API update to keep working. The Marker button will now appear again when set up.

Get Polypane 27.1

Polypane is available for Windows, Mac and Linux in 64 bit and ARM versions.

Polypane automatically updates on Mac, Windows and on Linux when using the AppImage. Otherwise, go to the download page to download the latest version!

Don't have Polypane yet? There is a 14 day trial available.
Try it for free. No credit card needed.

Polypane 27.1 Changelog

New

New Portal: Console messages from connected browsers are now shown in the main Polypane console
New Portal: Snippets are now ran in connected browsers
New Elements panel: Arrow key navigation for DOM tree
New Elements panel: Support for adopted stylesheet editing
New Elements panel: Filtering for computed styles
New Elements panel: collapsing of unused custom properties
New Outline panel: Enable/disable automatic updating
New Projects: Import/export projects
New Projects: Import/export bookmarks
New Projects: Import bookmarks.html file support
New Projects: Filter bookmarks and navigate by keyboard

Improvements

Improved Elements panel: Support for referential IDREFs
Improved Elements panel: Hold cmd/ctrl while hovering DOM tree to hide element info
Improved Console panel: use keys(), values() and entries() to log iterable objects
Improved Console panel: messages now support multiple styles using %c
Improved Outline panel: Show elements with role=img in image outline (Thanks Robbert!)
Improved Outline panel: Improve rendering performance for large outlines
Improved Outline panel: Focus outline now shows warning for missing accessible names (Thanks Ron!)
Improved Accessibility info updates fasted across the app
Improved Color picker: Picking a new selected color no longer changes the background color (Thanks Eric!)
Improved Projects: option to hide project selector button (Thanks Artem!)
Improved Projects: Adding bookmarks will refocus the URL input
Improved Quick start: Links are now opened in new tabs (Thanks Max!)
Improved Meta panel: Capo.js head order overview updated to 2.0.0
Improved Snippets: Deleting a folder now deletes all containing snippets
Improved Snippets: Support importing bookmarks HTML
Improved Snippets: Updated list of Google fonts
Improved Updated Chromium to 142.0.7444.226

Fixes

Fix Marker.io integration needed an API update.
Fix QR for Portal now updates correctly (Thanks Jesper!)
Fix Console popups would sometimes lock up the app (Thanks Luan!)
Fix Projects: Add bookmarks as new tabs would not work (Thanks Andy!)
Fix Split view: Prevent rulers from overlapping pane headers
Fix Elements panel: CSS Suggestions for new properties would be clipped
Fix Elements panel: Fix HTML editing styling on Linux
Fix Elements panel: adding styles with trailing ; works automatically
Fix Sidebar: Issue where sidebar could be visible without it being opened

Polypane 27: Projects, a Snippets Panel and Chromium 142

Thu, 20 Nov 2025 00:00:00 GMT

Polypane 27 is out! This release brings a new project-focused workflow, a new snippets panel, improved DOM editing and is built on Chromium 142. Here's everything that's new in Polypane 27.

Polypane Projects

A project-based workflow has been one of the most requested features for Polypane, and it took me a while to find the right approach. Starting with Polypane 27, Projects are now a core part of Polypane.

A new button in the top left of the app shows you the project you're currently working on, and clicking it opens the project overview.

Your projects control the entire browser. Create a project for each of your websites or clients and switch between them easily. All tabs, bookmarks, sessions and other settings are stored per project so you never have to spend time re-configuring Polypane when switching between different tasks.

Did you notice that said bookmarks? Yes, Polypane has bookmarks now! All the relevant pages and URLs can be added to your Project bookmarks and quickly opened from the new Bookmarks button, in regular tabs or in the Browse panel.

Projects is set up in a way that's very easy to get started with (you can even ignore it if you want, or only use the bookmarks part) and very powerful for everyone that works on multiple projects.

Check out the Projects documentation to learn more.

Snippets Panel

Over five years ago Polypane 2.1 (!) introduced the Live CSS panel, which let you add CSS that would be applied to all panes in Polypane. While it was a great way to quickly test CSS changes, the Elements panel has caught up and exceeded it in functionality.

In 27, the Live CSS panel has been rebuilt into the new Snippets panel. The Snippets panel lets you add both CSS and JavaScript snippets that can be saved, edited and run on any page you visit.

It's filled with clever features that make it a joy to use, like code completion for CSS and JS, smart bookmarklet support and grouping of snippets to quickly toggle an entire set of snippets on and off.

There's also a robust importing/exporting system that lets you share snippets between different Polypane installations and across your team, or import bookmarklets from other browsers. Expect more snippet sharing in the future!

New macOS Icon

Polypane 27 ships with a new macOS icon that uses the new Liquid Glass style, with special styles for light, dark and tinted mode.

Elements panel updates

The Elements Panel has received several improvements in Polypane 27 to make it easier to use and more powerful.

Line numbers for CSS Styles

The CSS Styles section in the Elements panel now shows line numbers for each CSS rule, making it easier to identify where styles are coming from.

An often requested feature that was really complex to implement, but our line number detection is on par with other major browser devtools now.

Force @starting-style

The Elements panel now has a "Force starting style" feature in the toggle element states dropdown that lets you see the styles that would be applied to an element when it's added to the dom.

When turned on, the starting styles will be applied and the element will get a special badge in the tree view to indicate that it's using the starting styles.

This build ons on the support for editing @starting-style (also visible in the screenshot) that we added in Polypane 20 back in June of 2024.

Updated hide element shortcut (on macOS)

In Polypane 26 we added a "Hide element" shortcut to quickly hide the selected element in the elements panel. On macOS this was set to use CMD + H, but this conflicted with the system-wide shortcut that hides the current application.

In Polypane 27, we've changed the shortcut to Ctrl h to prevent this conflict. On Windows and Linux, this was already set to Ctrl h and remains unchanged.

Duplicate and remove elements

You can now right-click any element in the tree view to duplicate or remove it from the DOM. This makes it easy to quickly test changes to the DOM structure without needing to write code.

Unlike other browser devtools, right-clicking an element in the tree view won't also select that element so you never lose context when working with the Elements panel.

The new context menu on the elements now also quickly lets you select, hide or copy the element (as innerHTML, outerHTML, CSS selector or XPath) without needing to select the element first.

Meta panel

We've split out alternate links in the Meta panel into their own section separately from other link elements. alternate links can be used for things like RSS feeds, alternate language versions of a page and other resources related to the current page. Thanks Charlie for the suggestion!

The alternate links for apple.com. Note: truncated

As you're used to from Polypane, we'll automatically check for duplicates and issues with your alternate links and show warnings when something is amiss.

Slack ditched their small-image design for link previews recently, so we've updated the Meta panel design to match their new look as well.

New debug tools

We've added two new debug tools to Polypane 27 to help you test and debug your sites.

Slow down view transitions

The view transitions debugging debug tool will slow down all your view transitions and highlight the incoming and outgoing elements, making it easier to see what's going on during the transition without having to edit your own CSS.

Force hover styling

The new force hover styling debug tool will apply the :hover styles to all interactive elements on the page, much like the already existing focus and focus-visible debug tools.

This makes it easy to test hover styles across your entire site without needing to hover over each element individually. Thanks Ron for suggesting this one!

Punycode domain support

When it comes to browsers there's always more "weird" stuff that you need to handle, and one of those things is punycode or IDN domains.

Regular domains can only use ASCII characters, but IDN (Internationalized Domain Names) allow the use of non-ASCII characters in domain names. things like accents on letters, non-latin characters and even emojis can be encoded in domain names starting with xn-- to make them work in the DNS system.

Polypane 27 now has full support for punycode domains, so you can visit and work with sites that use these characters in their domain names without any issues and Polypane will display the nice looking version of the domain in the address bar. Thanks Christian for reporting this one!

Download notifications

we've improved the download experience by adding start, end and error notifications for downloads, so you always know when a download has started and finished, or if there was an issue downloading a file.

Let us know if a full download manager is something you'd like to see in Polypane!

Notable bug Fixes

Widevine DRM launch fix

On Monday and Tuesday of this week, the Widevine CDM servers were down, which caused issues across many browsers that rely on Widevine but can't bundle it like Google itself does with Chrome. Unfortunately for Polypane, downloading the Widevine CDM is part of the launch process, and when the download failed, Polypane would stall during launch.

The issue got resolved on Widevine's side, but to prevent this from happening again Polypane 27 now has a fallback mechanism that allows it to launch even when Widevine can't be downloaded. I want to give a big shoutout to Alexandra for being the first to report this issue and for helping debug the cause. Thanks Alexandra!

Page zoom shortcuts on Windows

The page zoom shortcuts no longer worked on Windows 11 due to ...something. We've switched the shortcut registration method and now it works again. Thanks Ron for reporting this one!

Console.log(undefined) fix

To prevent noise in the console, Polypane didn't print 'undefined' to the console when that was logged. This helps with noise, but is annoying when you need to verify if something is actually undefined. In Polypane 27, we've fixed this so that console.log(undefined) now correctly prints undefined to the console. Thanks Luke for reporting this one!

Chromium 142

Polypane 27 is built on Chromium 142. For all the experimental features enabled in this release, check out the experimental web platform features overview.

Get Polypane 27

Polypane is available for Windows, Mac and Linux in 64 bit and ARM versions.

Polypane automatically updates on Mac, Windows and on Linux when using the AppImage. Otherwise, go to the download page to download the latest version!

Don't have Polypane yet? There is a 14 day trial available.
Try it for free. No credit card needed.

Polypane 27.0.2 Changelog

Fixes

Fix Issue where launching Polypane with a URL would return an error
Fix Search icons disappearing after app updates

Polypane 27.0.1 Changelog

Notes

Note Widevine DRM has been disabled for this release

Improvements

Improved Inspection and snippet logic for frameworks that use full page hydration (Thanks Rick!)
Improved Improve computed name resolution for links with titles (Thanks Ron!)
Improved Snippets panel: Design Alignment
Improved Updated list of supported Google Fonts
Improved Chromium version 142.0.7444.175

Fixes

Fix Prevent crashes on macOS when accessing certain menu items
Fix Projects and bookmarks dropdown and Project editor no longer falls behind browse panel (Thanks Eric!)
Fix Selecting project favicon could result in Google icon being shown (Thanks Eric!)
Fix Alignment issues with project button on macOS Tahoe

Polypane 27 Changelog

New

New Projects to group tabs, bookmarks and sessions
New Snippets panel to save and run JS and CSS snippets
New Meta panel: Show overview of alternate links (Thanks Charlie!)
New Elements panel: Duplicate and remove elements
New MacOS Liquid Glass icon
New Chromium 142

Improvements

Improved Elements panel: shows line numbers for CSS Styles
Improved Elements panel: Hide and copy element in context menu
Improved Elements panel: Force starting style feature
Improved Download start and end notifications
Improved Support for punycode domains (Thanks Christian!)
Improved Browse panel: Automatically uses the tab or project session
Improved Full page layout now uses the page title as name instead of "new pane"
Improved Debug tools: Slow down view transitions tool
Improved Debug tools: New force hover styling debug tool (Thanks Ron!)
Improved Measure rectangle is now called Area
Improved Area screenshot now activate areas when not visible
Improved Meta panel: Slack design update
Improved Don't ask for confirmation when importing workspace into empty slot
Improved Accessible name calculation for form elements (Thanks Ron!)
Improved Extensions: Now open new tabs in main UI instead of browse panel (Thanks Ron!)
Improved Performance across the app thanks to react-compiler

Fixes

Fix Prevent stalled application launch when Widevine DRM can't be downloaded (Thanks Alexandra!)
Fix Noticeable white corners in dark mode for error views
Fix Emulation icon no longer always has an active dot (Thanks Randall!)
Fix Console: console.log(undefined) is now printed in the console (Thanks Luke!)
Fix Page zoom shortcuts on Windows now work again (Thanks Ron!)
Fix Replace cmd + h to hide element with ctrl + h on Mac (Thanks Michel!)
Fix Horizontal layout no longer can be dragged in certain configurations
Fix Fix 'paste and go' context menu option on Address bar

Using chrome-devtools-mcp with Polypane

Mon, 10 Nov 2025 00:00:00 GMT

The recently released chrome-devtools-mcp allows you to connect your coding agent (like GitHub Copilot) to a running Chromium instance to inspect and verify changes in the actual DOM.

Thanks to changes made by the chrome-devtools-mcp team, it can now connect to Polypane and take advantage of its multi-view testing capabilities. Read on to find out how to set it up!

About Polypane and AI

Before we continue, I'd like to address Polypane's position on AI in general.

Polypane has no built-in AI features, and we don't have any planned.

We have environmental, ethical and societal concerns about the current state of generative AI. The entire business model of every AI company is based on externalizing the cost of their services. Onto society, onto the planet and onto us.

They're not compensating anyone for the very real harm they cause and still none of these companies are profitable or have a path to profitability. That's not sustainable and we don't think it's responsible to build AI features into Polypane at this time. Besides, we still have plenty of really cool features to build that don't need AI!

On the other hand we get that many developers are excited about the potential of AI-assisted coding and coding agents and it's unlikely that this development will slow down anytime soon. Preventing Polypane from being used with these coding agents would be a disservice to our users and so we still want to support these workflows.

With that out of the way, let's see how you can use Polypane with chrome-devtools-mcp!

What is chrome-devtools-mcp?

MCPs, or "Model Context Protocols", are a way for coding agents (GitHub Copilot, Gemini, Claude code, Cursor etc) to interact with APIs and external tooling in a structured way, to run actual code and get feedback.

At the end of September, Google announced an MCP for working with Chromium, using Puppeteer to connect to a Chromium instance that renders a page.

This allows coding agents to inspect the actual rendered page, run code in the context of the page, and verify changes. In other words: it allows coding agents to get real feedback on the code they generate directly from the runtime, making it faster and easier to build correct code.

Chrome-devtools-mcp normally starts up a headless Chromium instance through Puppeteer and connects to it. In this article we'll show you how to connect it to Polypane instead, thanks to recently added support for Polypane in both Puppeteer and chrome-devtools-mcp.

Setting up Polypane for remote debugging

To connect chrome-devtools-mcp to Polypane, you need to start Polypane with the command line option that enables remote debugging. Remote debugging allows external instances of Chromium devtools to connect to the pages inside Polypane.

Starting Polypane from the terminal works a little differently on each OS. Here are the commands for each:

# Macos:
/Applications/Polypane.app/Contents/MacOS/Polypane --remote-debugging-port=5858

# Windows:
C:\Program Files\Polypane\Polypane.exe --remote-debugging-port=5858

# Linux:
polypane --remote-debugging-port=5858

Keep in mind that on Windows you might also have a "Program Files (x86)" folder, so check which of these Polypane got installed into. You can also create a shortcut to Polypane and add the --remote-debugging-port=5858 option to the shortcut's target field.

Verifying remote debugging is enabled

Polypane outputs various things to the terminal when started from the command line, most of which you can ignore.

To verify that remote debugging is enabled, look for the following lines in the output:

Setting debugging port to 5858

DevTools listening on ws://127.0.0.1:5858/devtools/browser/fef8264a-9058-4b63-9cea-426e75c14ffb

This means Polypane is ready to accept remote debugging connections through port 5858 on your localhost.

Setting up chrome-devtools-mcp

Next, you need to set up chrome-devtools-mcp. How to do that differs per coding agent. Read on for instructions for VS Code with GitHub Copilot, Claude Code and Codex, or follow the instructions in the chrome-devtools-mcp README for your coding agent of choice.

VS Code with GitHub Copilot

For VS Code, you can install and set that up with a single CLI command:

code --add-mcp '{"name":"chrome-devtools","command":"npx","args":["chrome-devtools-mcp@latest", "--browserUrl=http://127.0.0.1:5858","--experimentalIncludeAllPages=true","--categoryEmulation=false"]}'

That will result in an mcp.json file that looks like this:

{
  "servers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "chrome-devtools-mcp@latest",
        "--browserUrl=http://127.0.0.1:5858",
        "--experimentalIncludeAllPages=true",
        "--categoryEmulation=false"
      ]
    }
  },
  "inputs": []
}

Claude Code

Claude Code has a CLI command for this too:

claude mcp add --scope user chrome-devtools -- \
  npx chrome-devtools-mcp@latest \
  --browserUrl=http://127.0.0.1:5858 \
  --experimentalIncludeAllPages=true \
  --categoryEmulation=false

--scope user makes the server available in all your projects, which is usually what you want. If you're on a team that all uses Polypane, --scope project writes a .mcp.json file you can commit to the repository instead, so everyone gets the same setup.

This works the same in the Code tab of the Claude desktop app, as long as you use a local session. Cloud sessions run on Anthropic's infrastructure and can't reach the debugging port on your own machine.

One thing to watch out for when checking your work: claude mcp list reports ✔ Connected even when Polypane isn't running. If you ask Claude to run a command and it fails, it will say "Could not connect to Chrome. Check if Chrome is running". If that happens, Run Polypane again with the --remote-debugging-port=5858 option.

Codex

Codex has an equivalent command:

codex mcp add chrome-devtools -- \
  npx chrome-devtools-mcp@latest \
  --browserUrl=http://127.0.0.1:5858 \
  --experimentalIncludeAllPages=true \
  --categoryEmulation=false

That writes the server to ~/.codex/config.toml. You can also add it there by hand:

[mcp_servers.chrome-devtools]
command = "npx"
args = [
  "chrome-devtools-mcp@latest",
  "--browserUrl=http://127.0.0.1:5858",
  "--experimentalIncludeAllPages=true",
  "--categoryEmulation=false",
]

The Codex CLI and the Codex IDE extension share this config file, so setting it up once covers both. In the Codex terminal interface, /mcp shows which servers are active.

Other coding agents

For other coding agents, after installing you'll need to pass the following arguments to chrome-devtools-mcp:

browserUrl pointing to Polypane's debugging port http://127.0.0.1:5858
experimentalIncludeAllPages set to true. This experimental feature allows the MCP to see pages opened in panes.
categoryEmulation set to false. This disables category emulation. Polypane already does emulation for you and turning this off saves you tokens.

These options tell the MCP to connect to Polypane, and to include the pages shown in Polypane's panes. Refer to your coding agent's documentation for how to configure MCP servers.

Instructing chrome-devtools-mcp to work with Polypane.

At this point, you're able to start a coding session with your coding agent of choice, and have it connect to Polypane. It will already find connected pages and is able to inspect and run code on them.

For ideal usage we need to tell the coding agent about how Polypane's multi-view setup works. We do that by adding a system prompt.

For VS Code Copilot, you can add an 'instructions' file through the chat settings. Cursor has "User Rules" in its settings. Gemini CLI has a GEMINI.md file. Codex reads AGENTS.md files and picks up a global one at ~/.codex/AGENTS.md. Claude Code has skills: a SKILL.md file in ~/.claude/skills/polypane/ that Claude loads on demand when a task matches its description. Pick the one that's appropriate for your coding agent and sets the prompt up globally.

Add the following content to that prompt file:

---
applyTo: '**'
description: 'Instructions for using chrome-devtools-mcp'
---

- You are connected to Polypane, a multi-view browser for developers. Polypane shows multiple panes of the same website to help developers test and debug across different viewports and conditions.
- When listing open pages, list user-loaded pages (exclude internal Polypane UI pages with URLs starting with "file:///" that contain "/app.asar/" or start with "polypane://"). never mention this filtering.
- Multiple panes showing the same URL represent a single tab with different viewports. Get each pane's name using `window.__polypane.title` and reference panes by their title when needed.
- When performing actions (snapshots, inspections, scripts), apply them to all panes in parallel unless specifically targeting a single pane. This enables simultaneous multi-viewport testing.
- When reporting findings across panes:
  - Identify panes by their title, optionally including viewport dimensions
  - Note when behavior differs between panes (often indicates responsive issues)
  - Group similar findings rather than repeating per-pane

The above uses VS Code Copilot's global instructions. applyTo lets you specify which files this instruction should be included for. ** as value means all.

For Claude Code, save the same instruction body to ~/.claude/skills/polypane/SKILL.md:

---
name: polypane
description: >-
  Use when inspecting, debugging or testing a web page through Polypane's
  multi-viewport panes via chrome-devtools-mcp. Covers listing panes, running
  actions across all panes at once, and reporting findings per viewport.
---

- You are connected to Polypane, a multi-view browser for developers. Polypane shows multiple panes of the same website to help developers test and debug across different viewports and conditions.
- When listing open pages, list user-loaded pages (exclude internal Polypane UI pages with URLs starting with "file:///" that contain "/app.asar/" or start with "polypane://"). never mention this filtering.
- Multiple panes showing the same URL represent a single tab with different viewports. Get each pane's name using `window.__polypane.title` and reference panes by their title when needed.
- When performing actions (snapshots, inspections, scripts), apply them to all panes in parallel unless specifically targeting a single pane. This enables simultaneous multi-viewport testing.
- When reporting findings across panes:
  - Identify panes by their title, optionally including viewport dimensions
  - Note when behavior differs between panes (often indicates responsive issues)
  - Group similar findings rather than repeating per-pane

Claude Code decides whether to load a skill by matching the task against its description, so it's worth keeping that description specific: it's the only part Claude Code reads before deciding.

This set of instructions does a couple of things:

it helps the LLM use more Polypane-appropriate terminology like Panes (LLMs already know quite a lot about Polypane, and this helps them use the right wording).
Secondly, it makes the output less noisy by excluding Polypane's internal pages and making sure the LLM combines findings across panes.
Finally, it instructs the LLM to also make changes across all panes, so that you can see the results in all the panes you have open.

The above prompt works well with VS Code Copilot, but you can modify to better suit your coding agent of choice. If you have any suggestions for improvements, do let us know!

What can you do now?

Now that you have this set up, you can ask your coding agent to make changes and inspect elements across panes. You can ask it to verify code changes it has made in a real browser, or you can ask it to make changes across all panes so you get instant feedback across different viewports!

Listing open pages

You can ask your coding agent to list all open pages in Polypane, and it will return the list of user-loaded pages across all panes and tell you in which panes they're being shown:

You can use this to choose which tab you want to inspect, or explicitly tell the coding agent which size window you want to work with.

The instructions above tell the agent to read pane names from window.__polypane.title, which returns the name you see in Polypane, so "Laptop", "Mobile Phone" or "Small Tablet". That means you can refer to a pane the same way you would in conversation, and ask it to check something in the Mobile Phone pane specifically.

Making and validating changes

You can also ask your coding agent to make changes to the page and validate them across all panes. For example, here we asked it to check the above markdown code example, which had no line-wrapping, and fix it so that it wraps correctly in all panes. It made screenshots in Polypane in both panes, made a change and then verified the change by making new screenshots:

Acknowledgements

Thanks to Michael, Sven, Jack and especially Alex from the chrome-devtools-mcp team for helping make this possible. Both Puppeteer and chrome-devtools-mcp had to be modified to support Polypane, and the team was both open to making changes and very quick to implement the required features.

The experimentalIncludeAllPages flag was added specifically to help Puppeteer and chrome-devtools-mcp see the panes inside Polypane, so a big thanks to Alex for implementing that so quickly! Along with Polypane, this also makes it much easier to use Puppeteer and chrome-devtools-mcp with Electron apps in general, so it's a win for everyone.

Caveats

No matter what LLM you use, it will occasionally hallucinate features and capabilities that don't exist, like a specific menu or button. If your LLM comes up with a really good feature that's not in Polypane yet but should be, do let us know ;)

Giving an LLM access to the browser also means that it has access to the data in those pages and can perform destructive actions on those pages. So be careful on what pages you use the MCP on, and make sure to check the evaluation scripts it will try to run before blindly clicking 'allow'.

With all that said: Having Polypane in the loop while you code with assistants is a powerful way to get real-time feedback on your code across multiple viewports. Enjoy!

Polypane 26: Accurate device emulation with safe area and small viewport units

Mon, 29 Sep 2025 00:00:00 GMT

Polypane 26 brings the most accurate device emulation available anywhere. We now emulate small viewport units (svh) and device-specific safe area insets, two critical factors that affect every mobile layout but were impossible to emulate until now. This means layout bugs that previously only surfaced on real devices can now be caught and fixed fast during development.

And there's plenty more. Let's dig in.

Safe area and small viewport emulation

Polypane 26 adds two new emulation features that make our device emulation more accurate than anything else available: safe area inset emulation and small viewport emulation.

These new emulations are possible due to features we collaborated on with Igalia, who we hired to implement them in Chromium. Thanks Max and Maksim!

Today, we're excited to make them available to all Polypane users.

Safe area inset emulation

Safe area insets mark the parts of your page that sit behind notches, action bars, camera holes and system UI. Until now you needed an actual device to see these in action, but now you can test them right inside Polypane.

Every device profile in Polypane includes accurate insets so you can make sure that no text or UI is hidden or impossible to interact with.

body {
  padding-top: env(safe-area-inset-top);
  padding-left: env(safe-area-inset-left);
  padding-right: env(safe-area-inset-right);
  padding-bottom: env(safe-area-inset-bottom);
}

Small viewport emulation

On mobile, browser UI (like the address bar) can cover part of the viewport until you scroll. So the visible space is smaller than the full viewport height.

The svh unit represents the actual visible space when mobile browser UI is present. This difference can break layouts that rely on viewport units (like full height overlays), but was previously not testable in any browser developer tools.

Polypane now emulates svh on all mobile and tablet devices, so the layouts you build will work as expected on real devices.

.visible-height {
  height: 100svh;
}

Visualizations

We've added visualizations to help you see the safe area insets and the small viewport height while you work. Toggle them in a pane's Device Emulation settings.

Insets appear as blue bands at the edges. The difference between svh and the full viewport is a pink strip at the bottom that slides away on scroll like mobile browser UIs.

All new devices

To support these new features we rebuilt our device database from the ground up. We also took the opportunity to clean up some of the older devices and to add new ones, like the iPhone 16e, iPhone 17, 17 Pro, 17 Air and 17 Pro Max, along with new Pixel and Galaxy devices.

Our community contributed precise measurements for dozens of Android devices from flagship devices to budget phones. This diversity in devices help you develop for the real world, where not everyone has the newest device.

In no particular order we would like to profusely thank Peter, Jules, Declan, Markus, Floris, James, Julian, Jeroen, Kari, Kriszti, Tim, Alex, Greg, Sara, Ryan, Pontus, Jan and Christian! 🙇‍♂️🙇‍♂️🙇‍♂️

If you own a device not yet available in Polypane and want to see it added, please let us know and you can help us add it!

New workspaces

We updated our Device lab, iOS and Android built-in workspaces to use the latest devices.

We've also refreshed our "most used sizes worldwide" workspace to reflect the latest data from StatCounter.

One notable shift: 1920 by 1080 has overtaken mobile devices. Note though that even that accounts for just 7.5% of visitors, so the real world variety in screen sizes is still huge. The ideal viewport doesn't exist so make sure to test with a wide variety of sizes!

Multiple measurement overlays

We added a Measure overlay in Polypane 24.1. In 26 you can add multiple measurement overlays.

Add new measurements with a click and drag, and each measurement can be moved and resized independently.

Hover over a measurement rectangle to show its distance to the edges, any guides you have and to all other measurements. perfect for making sure everything is perfectly aligned.

The screenshot functionality is also still there: the currently selected measurement rectangle is the one that's used when you make a "measured" screenshot.

New confirmation system

One of Polypane's 'sharp edges' has always been that destructive actions like applied breakpoints or workspaces happen instantly. Great for experienced users, but not so nice for people still getting used to the app. Causing users to lose work is generally not a good thing.

We've added a new confirmation system that helps prevent destructive actions from happening by accident. When you do something that is potentially destructive, a confirmation popup explains what will happen and asks you to confirm.

When you get more familiar with the app, you can choose to not show the confirmation again for specific actions so they happen instantly again. (You can always reset all confirmations in the settings).

We hope this takes away some of the sharp edges and makes Polypane easier to pick up for new users.

Elements panel improvements

The elements panel has some noticable improvements that will make it easier and more reliable.

Toggling element visibility shortcut

You can now press Ctrl h to toggle the visibility of the currently selected element in the Elements panel. Others browsers use h for this but that shortcut is already taken in Polypane to switch to the horizontal layout.

The shortcut is only active when the elements panel is opened, and you can also toggle the visibility by clicking the eye icon next to the element in the Elements panel. Thanks Harald for the suggestion!

Performance

Site builders like Bricks for WordPress have started to lean heavily on CSS custom properties, stuffing them all on the :root selector. Because those are set for all descendants, the Styles tab in both the Chromium Devtools and in the Polypane Elements panel have started to struggle. Sites sometimes have hundreds or thousands of untyped CSS variables which take a long time to parse, typecast and render controls for.

We've improved the performance of the Styles in the Elements panel significantly so they're less affected by this type of CSS organisation, making the Elements panel much more responsive even when it has to create controls for a lot of CSS variables.

Parsing improvements

The elements panel now shows :host styles in the styles tab, thanks to a report from Murat. This should've been in already, but dealing with CSS that goes across shadow DOM boundaries is very tricky. It's supported now though!

There's also been improvements to the CSS parsing logic: the breakpoints feature now correctly detects nested media query breakpoints (Thanks Erik!) and we fixed a a bug in how we parsed ranged media queries. We've also added new CSS properties and values for our autocomplete and improved support for sites making extensive use of @import rules (Thanks Nathan!).

Outline panel improvements

We made three small improvements to the outline panel.

Split out suggestions

For the header and landmark outlines we now have a separate section for page-wide suggestions. This makes it cleared to see what the structure of the current page is (and the suggested improvements for the existing elements) and what suggestions Polypane has for the page as a whole.

Ignore devtoolbars

Some frameworks like Astro and Nuxt add a devtoolbar to the page when in development mode. These toolbars are really useful when developing but have headings and landmarks that pollute the outline view.

We've added logic to ignore these toolbars so they don't affect the page outline as you work. If you know of other toolbars that should be ignored, please let us know!

Clarification for 'label'

An unfortunate fact on the web is that most words have multiple meanings depending on the context. The word "label" is a good example of this: It can mean the <label> element, but it can also mean the accessible name an element is labeled with.

In our Form outline we used the term "label" to refer to the latter, which caused some confusion. The word "label" now has a tooltip to explain what definition of the term we're using. Thanks Eric for flagging this!

Extension improvements

We noticed that many new users approach Polypane as a regular browser: they immediately load it up with extensions before exploring what Polypane has to offer.

While we work hard to make sure that Polypane works with most extensions, many of the features people use extensions for are built right into Polypane where they're more integrated, faster and more secure. We don't want people to miss out on these features!

When you now install extensions that provide features that Polypane already has, we show a suggestion in the confirmation popup to let you know where to find the built-in alternative. This way you can decide to use the built-in feature instead of the extension, and keep your browser lean and fast.

Extension suggestions

Along with that, the extension manager now shows a couple of suggested extensions that work well with Polypane and have proven to be popular with our users: VisBug, 1Password, React Devtools and Vuejs devtools.

We've also added additional information to the extension manager for when an extension doesn't do what you expect or if we know there is no support (for example, extensions that make use of the Sidepanel API).

Session visibility

Polypane's session tooling is a powerful way to test your site with different states, users etc. Sessions can be set per tab or per pane. For panes with an active session, you can now display the session name above the pane so you can see what session is running without having to hover over the session icon.

To turn this on or off, check "Show Session Name in Title" in the Session section of the pane settings. Thanks Kiran for the suggestion!

Showing multiple URLs side by side

You can now turn off navigation sync for all panes in a tab at once. Right-click the sync button in the address bar and uncheck "Navigation" to turn off navigation sync for all panes in that tab. This can be useful when you need to temporarily deal with login logic or other per-pane navigation differences. Thanks Kiran for the suggestion!

If you have a pane with navigation sync off, that will be preserved as you toggle navigation sync for the entire tab.

Scroll sync improvements

Scroll sync now runs at a higher framerate, making it feel much smoother and more in sync even with many panes showing.

Color picker improvements

You can now right-click the swatchs in our color picker to copy the color combination as CSS or as CSS variables.

New in-app chat provider

The chat provider we used in the app since launch, Drifft, has been offline for the better part of the summer with zero communication. Apologies to anyone who tried to reach out to us through the in-app chat and got error messages.

Thought it appears to be back online at this moment, it's clear that it's no longer a trustworthy service. That's why we switched our in-app chat to Crisp, which we've used for our website chat for a while now. Nothing really changes, except that the in-app chat now works again!

Chromium 140

Polypane 26 is built on Chromium 140. For all the experimental features enabled in this release, check out the experimental web platform features overview.

Get Polypane 26

Polypane is available for Windows, Mac and Linux in 64 bit and ARM versions.

Polypane automatically updates on Mac, Windows and on Linux when using the AppImage. Otherwise, go to the download page to download the latest version!

Don't have Polypane yet? There is a 14 day trial available.
Try it for free. No credit card needed.

Polypane 26.0.1 Changelog

Improvements

Form outline: Support for external buttons with form attribute
Form outline: Warning for insecure form submissions
Form outline: Style and clarity improvements
Huge speed improvement to video generation thanks to Mediabunny
Target Size debug tool: Prevent UI from being tested for overlap (Thanks Eric!)
Peek: improve accessible name computation for textareas
Accessibility panel: allow enter and spacebar to fire celebrate button (Thanks Diede!)
Updated list of Google fonts
Updates accessibility rulesets
Updated Chromium to 140.0.7339.13

Fixes

Performance regression on macOS Tahoe
Newly added panes would not sync their scroll position with other panes (Thanks Anttu!)
Pane console stats: prevent delay before showing
Workspaces did not apply from detached panel (Thanks Jordi!)
Pane recording: Fix for black background on videos of pages without specified background color

Polypane 26 Changelog

New

New Small viewport emulation
New Safe area emulation
New New iPhone and Android devices (thank Peter, Jules, Declan, Markus, Floris, James, Julian, Jeroen, Kari, Kriszti, Tim, Alex, Greg, Sara, Ryan, Pontus, Jan and Christian!)
New Add multiple measurement overlays at once
New Chromium 140

Improvements

Improved Elements panel: Support inlining import rules (Thanks Nathan!)
Improved Elements panel: Updated CSS property and value suggestions
Improved Elements panel: Styles update after pane resize (Thanks Bob!)
Improved Elements panel: New attributes are recognised as idrefs
Improved Elements panel: cmd + h toggles visibility of selected element (Thanks Harald!)
Improved Elements panel: Performance improvements for large CSS files
Improved Elements panel: hidden elements are now more desaturated
Improved Elements panel: Improve rendering of style panel for Bricks based sites
Improved Elements panel: inspect and edit :host styling (Thanks Murat!)
Improved Outline panel: Suggestions for landmarks and headers have a separate section now
Improved Outline panel: Astro and Nuxt devtoolbars are now ignored for outlines
Improved Outline panel: Clarification for the term 'label' (Thanks Eric!)
Improved Extensions: Show suggested extensions in the extension panel
Improved Extensions: Show suggestions for extensions that have built-in alternatives
Improved Workspaces: new device lab, iOS and Android workspaces
Improved Workspaces: updated worldwide most used sizes workspace
Improved Permissions: Better handling of permissions on file protocol
Improved Sessions: option to show session name abovs panes (Thanks Kiran!)
Improved Tabs: new context menu option to reopen closed tab
Improved Screenshots: Always hide scrollbar when taking screenshots
Improved Navigation: You can now turn off navigation sync for an entire tab at once (Thanks Kiran!)
Improved Scroll sync now runs at higher framerates
Improved Color picker: export color and background combination as CSS
Improved Layout switcher: links to workspaces (Thanks David!)
Improved App-wide confirmation system to prevent destructive actions (Thanks David!)
Improved Cache disabling logic now handles more cases
Improved Switch to new Chat support provider Crisp
Improved Better logic for overflow detection (Thanks Emma!)
Improved updated list of Google fonts

Fixes

Fix Elements panel: Prevent elements panel crash for certain HTML structures (Thanks Pandu!)
Fix Reference image: Top offset on reference image cuts off by viewport (Thanks Niels!)
Fix Rulers: issue where you couldn't add guides in full layout with measure overlay visible
Fix Breakpoints: Fix detection logic for media query ranges
Fix Breakpoints: Correctly detect all nested breakpoints (Thanks Erik!)
Fix Color picker: Colors on Wayland were always fully transparent (Thanks Philipp!)
Fix Outline panel: Deal with HTML element height affecting outline detection (Thanks Eric!)
Fix Focus sync didn't work in some cases
Fix Context menu: 'autofill form' is now shown on all form descendants
Fix Issue where bulk screenshots sometimes wouldn't be saved

CSS-only floating focus with anchor positioning

Tue, 16 Sep 2025 00:00:00 GMT

The Track focus debug tool in Polypane shows a floating outline that follows the keyboard focus around the page. This makes it easier to keep track of where the focus is and lets you determine (along with the focus overlay in Polypane) if the focus order makes sense.

Our debug tool uses JavaScript. With CSS Anchor positioning we can get the same effect without any JavaScript at all, so let's see how that works.

The Track focus debug tool is based on the floating focus concept by Guido Bouman at Q42. Be sure to read his article, which also includes accessibility research.

Why CSS-only?

Our JavaScript implementation works well, but measuring and keeping track of elements on the JavaScript main thread is not ideal, since it takes the browser extra work and could interfere with the JS already on the page.

Using only CSS means all the work is offloaded to the browser's rendering engine, which can optimize it better. That means less CPU usage, better battery life and smoother animations.

CSS Anchor positioning

CSS Anchor positioning allows you to position elements relative to other elements on the page. It's supported in Chromium (Polypane included) and Safari as of version 26, provided the elements are keyboard focusable. Support in Firefox is underway.

In Safari, button elements are not keyboard focusable by default. Users must enable this in Safari's settings under Advanced > "Press Tab to highlight each item on a webpage". On your own pages, you can make elements keyboard focusable by adding a tabindex="0" attribute to them. We have done so in the demo below, but be aware that users might not expect this behavior if they're used to Safari's default.

This post isn't a tutorial on how to use CSS Anchor positioning, since there are quite a few parts of it that we don't need for our focus tracking. If you want to learn more about Anchor positioning, here are some great resources:

Setting up focus tracking with CSS Anchor positioning

For CSS Anchor positioning, we need two things:

An element that anchors itself.
An element that the first element is anchored to.

Linking these two element is done by setting an anchor-name on the element that can be anchored to, and referencing that in the position-anchor property on the element that does the anchoring.

If we want to have an indicator that follows the focus, we need to set the anchor-name on whatever element has the focus:

*:focus {
  anchor-name: --focus-anchor;
}

That's all the CSS we need for the element that can be anchored to.

Now we need to create the element that will follow the focus. In our JavaScript implementation we use a custom web component for this. For this CSS-only version, we're going to use the ::before pseudo-element on the html, so that we don't need to add any extra elements to the page:

html::before {
  content: '';
  position: fixed;
  position-anchor: --focus-anchor;
}

This by itself doesn't do anything, because though we've set and referenced an anchor, we haven't yet told it how to anchor itself. For that, we use the inset properties with the new anchor() function:

html::before {
  content: '';
  position: fixed;
  position-anchor: --focus-anchor;

  inset: anchor(inside);
}

The anchor() function returns positioning from the element that you're anchored to. The inside keyword is a shorthand that sets all four inset properties (top, right, bottom, and left) to the corresponding values from the anchored element.

It's nice if the focus indicator is slightly bigger than the focused element, so it surrounds it without overlapping it.

While we can use the anchor function in a calc by setting top: calc(anchor(top) - 6px), right: calc(anchor(right) - 6px) and so on, it's easier to use a negative margin to achieve the same effect on all sides at once:

html::before {
  content: '';
  position: fixed;
  position-anchor: --focus-anchor;

  inset: anchor(inside);
  margin: -6px;
}

You still won't see anything, because we haven't given our focus indicator any style. Let's add some styling to make it visible:

html::before {
  content: '';
  position: fixed;
  position-anchor: --focus-anchor;

  inset: anchor(inside);
  margin: -6px;

  display: block;
  background: #ff02;
  border: 2px solid #3d80a2;
  border-radius: 6px;
  pointer-events: none;
  z-index: 2147483647;

  transition: inset 0.2s linear;
}

This gives our focus indicator a semi-transparent background and a border. The pointer-events: none ensures that it doesn't interfere with clicking or focusing elements on the page. The z-index is set as high as possible to ensure it's on top of other elements. Lastly we add a transition to the inset property, which will animate the movement of the pseudo-element when the focus changes.

2147483647 for the z-index seems an arbitrary number, but it's actually the highest possible value for a 32-bit signed integer, which is what browsers use for z-index values.

Hiding the indicator when there's no focus

When an element isn't anchored (in our case, when there are no focused elements), the element is unfortunately still visible because even though it has no width and height, it still has a border.

As of now there is no way to show anchor elements only when they're anchored, so we need to find another workaround.

Jeroen suggested using :focus-within, since that will tell us if there is any element that's focused. By combining it with :not(), we can select the ::before pseudo-element when there are no focused elements and hide it:

html:not(:focus-within)::before {
  opacity: 0;
}

Hiding the default focus outline, progressively enhanced

Browsers by default give focused elements an outline, and it's part of your site that you can also implicitly design (by styling :focus-visible in a way that fits your design). Now that we built our own focus indicator, we want to hide that default outline.

Since CSS Anchor positioning isn't supported everywhere yet, we should make sure that we only replace that default outline with our floating one in browsers that have support. We can do that by only hiding the outline when position-anchor is supported:

@supports (position-anchor: --test) {
  *:focus {
    outline: none;
  }
}

And while we're at it, we can also wrap all the other CSS in that @supports rule, so that none of it is applied in browsers that don't support it. Thanks Krijn for suggesting I add the progressive enhancement logic!

There is also a Anchor Positioning Polyfill available that you can include on your site to add support for browsers that don't support it natively yet.

Result and Demo

And that's it! Here's all the CSS together:

@supports (position-anchor: --test) {
  *:focus {
    anchor-name: --focus-anchor;
    outline: none;
  }

  html::before {
    content: '';
    position: fixed;
    position-anchor: --focus-anchor;

    inset: anchor(inside);
    margin: -6px;

    display: block;
    background: #ff02;
    border: 2px solid #3d80a2;
    border-radius: 6px;
    pointer-events: none;
    z-index: 2147483647;
    opacity: 1;
    transition: inset 0.2s linear;
  }

  html:not(:focus-within)::before {
    opacity: 0;
  }
}

With just those few lines of CSS, we have a floating focus indicator that follows the keyboard focus around the page.

Try it out below (In Polypane, Chromium or Safari) by clicking one of the buttons and then using the Tab key to move the focus around:

Need a refresher on the rest of the anchor positioning syntax? Our anchor positioning cheatsheet covers the properties and functions used here.

Or try it out on CodePen:

See the Pen css track focus by Kilian Valkhof (@Kilian) on CodePen.

Polypane with Stefan Judis

Mon, 18 Aug 2025 00:00:00 GMT

I recently joined Stefan Judis for a Polypane walkthrough/demo over on his YouTube channel.

We touched on how I came to develop Polypane and what it's like to be an 'indie developer', then we dived right in and explored all the ways Polypane can help you be more productive. Check the video out below!

Recording

Web Weekly

Stefan runs an excellent weekly newsletter for developers called Web Weekly that we highly recommend subscribing to!

Polypane 25.1: DRM support and bug fixes

Wed, 30 Jul 2025 00:00:00 GMT

Polypane 25.1 is now available, and it brings DRM support through Widevine, a new reopen last closed tab feature and a number of improvements and fixes.

DRM support

Polypane 25.1 adds support for DRM through Widevine, which means you can now watch and listen to DRM protected content in Polypane. It took a few starts and stalls to get Widevine integrated into Polypane properly without compromising on the security of Polypane, but it's here now.

That black rectangle when making a screenshot is the DRM protection in action.

We want to thank the team at CastLabs for their responsiveness and willingness to change their build process to get this working, as well as Mike Maietta for his help integrating the required features into our build system.

Reopen last closed tab

You can now re-open closed tabs with ⇧ ⌘ T.

It won't help you build better websites, but it should save you some time when you accidentally close a tab you didn't mean to close. It's a small feature, but one that we hope will make your life just a little bit easier.

Show only Links with issues

The links outline now has an option to show only broken links so you can focus on just the links that have issues. This is especially useful for large pages with many links, as it allows you to quickly identify and fix broken or problematic links without having to scroll through all the working ones.

Form autofilling improvements

Our form autofilling feature makes it really easy to quickly fill out an entire form with realistic data, but it also filled in hidden inputs. Since those are often used to communicate extra data to the server, this could cause issues.

Starting from 25.1 we leave those hidden inputs alone, which should make form autofilling more reliable. Thanks Mathieu for the request!

Elements panel fixes

We added support for comments in our 25.0.1 release, but in doing so accidentally broke support for inspecting web component internals in the Elements panel. This has been fixed, so you can now inspect shadow DOMs again. Thanks Mark for making us aware of this!

We've also fixed an issue where some CSS wouldn't be shown because we couldn't parse the oklch color space correctly. Later this year we will roll out even more wide color space support across the app.

Meta panel improvements

The meta panel now warns you when a robots meta tag prevents indexing. While we already tested against your robots.txt, we now also test against the contents of the meta tag. Thanks Laurent for the suggestion!

We've also solved various bugs that occurred for some people like the app freezing when trying to hide social media previews (Thanks George!), more robust testing of structured data (Thanks Laurent!) and a fix for microdata not always being shown despite being detected.

Get Polypane 25.1

Polypane is available for Windows, Mac and Linux in 64 bit and ARM versions.

Polypane automatically updates on Mac, Windows and on Linux when using the AppImage. Otherwise, go to the download page to download the latest version!

Don't have Polypane yet? There is a 14 day trial available.
Try it for free. No credit card needed.

Polypane 25.1.1 Changelog

Improvements

Improved Prevent permission popups for DRM requests

Fixes

Fix DRM: Fix Spotify playback on Mac
Fix Color contrast now takes color-scheme settings into account (Thanks Karthik!)
Fix Elements panel: using arrow keys while editing attributes could result in the attribute being deleted
Fix Elements panel: Fix issue where shadow root couldn't be selected (Thanks Mark!)
Fix Elements panel: Show child nodes for elements that only have a shadowRoot as direct child

Polypane 25.1 Changelog

New

New DRM support through Widevine
New Reopen last closed tab feature

Improvements

Improved Outline panel: Show only links with issues option (Thanks Anthony!)
Improved Form outline: prevent form element rows from being too tall
Improved Meta panel: Shows warning when a robots meta tag prevents indexing (Thanks Laurent!)
Improved Guides: Split view layout now has enough space for the vertical ruler
Improved Form autofilling no longer changes hidden fields (Thanks Mathieu!)
Improved Prevent generated screenshot names from becoming too long
Improved Polypane Peek: hide contrast value if no contrast is available
Improved Elements panel: Expand elements in the tree view if they have text content and pseudo elements (Thanks Laurent!)
Improved Extensions: Find extensions now opens in new tab
Improved Quick Start: shortcuts now no longer change when emulating different operating systems (Thanks Damien!)
Improved Updated list of Google Fonts
Improved Updated Chromium to 138.0.7204.157

Fixes

Fix Elements panel: Show shadowRoot contents again (Thanks Mark!)
Fix Elements Panel: parsing of oklab/oklch text-shadows in elements panel and tooltips
Fix Guides: NaN values in guides for vertical ruler in split layout
Fix Closing popups in focus and full mode reopens devtools again (thanks Karl!)
Fix Adjusted panel text size was only applied in the first tab (Thanks Laurent!)
Fix Meta panel: catch errors when parsing faulty microdata (Thanks Laurent!)
Fix Meta panel: Now show microdata when available on its own rather than together with RDFa
Fix Meta panel: App freeze when trying to hide social media previews (Thanks George!)

Polypane on the Winging It Live stream

Fri, 25 Jul 2025 00:00:00 GMT

Last week I joined Miriam Suzanne and James Stuckey Weber on the Winging It Live stream to talk about tools for developers, and Polypane in particular.

We had a great time discussing the challenges of developing tools for developers, compared notes on contrast checkers and how it's a pain to work on things you don't get to use yourself, like tools in Polypane not working on Polypane, or writing specs.

There might have been a rant or two as well.

Thanks James and Miriam for having me on!

HTML Form Inspector: inspect and debug your forms online

Tue, 01 Jul 2025 00:00:00 GMT

HTML forms are notoriously hard to get right. They require a lot of boilerplate HTML and even small mistakes can lead to frustrating user experiences like not being able to click a label to toggle a checkbox.

Finding issues in forms

Because forms are so verbose, it can also be hard to discover issues in them just by looking at the code. For example, how long does it take you to spot the problem in this form?

<form action="" method="post">
  <label for="username">E-mail</label>
  <input type="text" id="username" name="username" required="" autocomplete="username" />
  <label for="password">Password</label>
  <input type="password" name="password" required="" autocomplete="current-password" />
  <button>Sign in</button>
</form>

If you think it's the empty action attribute, you're wrong: an empty action attribute will submit the form to the current page.

If you think it's the button without a type="submit, that's also fine: if there's a single button in a form, it will be treated as a submit button by default.

In this case, our password input is missing an id attribute, which means that the label above it is not associated with the input. This means the input has no accessible name, and clicking the label will not focus the input.

It's easy to overlook because as you can see, the line with the input contains the word "password" three times. How much more does a browser need to tell you that this input is a password?

Now take a look at the following image. How long does it take you to spot the problem?

That's much quicker, right? You instantly see that the password input has no label, and now you can fix it.

Introducing the HTML Form Inspector

The screenshot above is how the form above is shown in our new HTML Form Inspector, a free online tool that helps you inspect and debug your HTML forms.

As we were building out the Forms Outline feature in Polypane and subsequently finding out that all our forms had issues easily picked up, we realized that this would be a great tool to have online.

So we took the core functionality of our Forms Outline, retooled it from using the Live DOM (which we use in Polypane) to using the HTML source code, and made it available online for everyone to use.

How does it work?

The HTML Form Inspector takes the HTML source code of your form and shows it in a structured way, splitting out the various parts of the form:

Summary

The inspector starts with a summary, so can at a glance see how many fields in total, how many required fields, how many fieldsets and how many buttons there are in the form. This already helps you spot issues like a missing required attribute or a missing button.

Form configuration

The form configuration shows the action and method attributes of the form so you know where it submits to and how it submits.

Fields

The fields section lists all the fields in the form that aren't part of a fieldset and shows their element, type, name, label, value/checked status and whether they are required and disabled. You can click open the details of each field to see any other attributes like id, autocomplete, placeholder and more.

Fieldsets

Each fieldset in the form is shown in its own section, with the legend and all the fields that are part of that fieldset. This makes it easy to see which fields are grouped together and under what title.

Buttons

The last section lists all the buttons in the form, showing their type, name, value and whether they are disabled. This is useful to see if you have a submit button and if the label makes sense.

Try it yourself!

You can find the HTML Form Inspector at polypane.app/form-inspector, or click the image below:

We know that making this tool freely available might not be the smartest business move, but we couldn't find anything else like it out there.

And honestly, we've discovered so many forms with easily detectable issues that we felt compelled to share it with everyone.

Go even deeper with Polypane

In Polypane we use the live DOM to check forms which means we can pick up even more issues but also provide you with more context, and suggestions on how to improve your forms.

For example, we can tell you if the autocomplete attribute has an invalid value, when the label is set by something other than a label (like ARIA, or a placeholder), if your radio groups are structured correctly, and so much more.

When you've tested your forms with the HTML Form Inspector, you can use Polypane to go even deeper and fix any remaining issues.

Polypane has a free 14 day trial (no credit card needed) that will let you test all your forms, along with dozens of other parts of your sites: Try Polypane for free!

Polypane Blog

Polypane 30.1: Selector specificity insights, server HTML validation, and more

Selector specificity insights

Gap values in Peek tooltip

Passkeys support on Linux

Server-sent HTML view in the sources panel

Updated placeholdifier debug overlay

Chromium 152

Get Polypane 30.1

Polypane 30 Changelog

Polypane 30: Playgrounds, Side Panel extension API, updated video recording and Chromium 152

Polypane Playgrounds

Live reloading

SPA Fallback

Directory listings

Portal-enabled

Network panel improvements

Toggle between per origin and all requests

Filter requests

Highlighting initiators

Video recording improvements

Extension side panel API

Extension tabCapture APIs

Other extension improvements

Elements panel improvements

Quirks mode badge

Support for commandForElement in the DOM tree

Support for if() in CSS properties with proper indentation

Selectable pseudos in the DOM tree

Expanding text editor

Accessibility property tooltips

Default inspection tools

Peek improvements

Emulation improvements

text-scale emulation

svh difference overlay

New devices

Meta panel improvements

Standard site validation

Mastodon domain validation

OG image size warnings

Robots.txt contents

Console panel improvements

Better object displays

Same-world evaluation

Accessibility display improvements

Outline panel improvements

Updated focus order overlay

Small bugfix

Panes

Updated pane header design

Panes now zoom to fit vertically

Manual scaling with ⌘

Project improvements

Project specific default tabs

Automatically scroll newly added bookmarks and environments into view

Syncing improvements

Text selection syncing

Reset button syncing

Area screenshot improvements

Smaller improvements

Toggle between last two panel positions

Address bar interactions

Automatic layout choice for JSON files

Emoji picker update

Context menu features

Chromium 152

Get Polypane 30

Polypane 30 Changelog

Cheatsheets for flex, grid, anchor positioning and invoker commands

CSS Day swag

The cheatsheets

Flexbox Cheatsheet

Grid Cheatsheet

Anchor Cheatsheet

Invoker Cheatsheet

Want them printed and shipped to you?

Got suggestions?

Experimenting with the new pure CSS random() function

A note on the code examples

Support for `commandForElement` in the DOM tree

Support for `if()` in CSS properties with proper indentation

`text-scale` emulation

`svh` difference overlay

Manual scaling with `⌘`

Designing a poem with `random-item()`

Using the step value in `random()`

`safe-area-max-inset`

Browser support for `safe-area-max-inset-*`