DEV Community: Kilian Valkhof

HTML Form Inspector: inspect and debug your forms online

Kilian Valkhof — Tue, 01 Jul 2025 13:23:21 +0000

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!

[Boost]

Kilian Valkhof — Fri, 18 Apr 2025 07:04:53 +0000

Sacha Greif

Apr 18 '25

Launching the first ever State of Devs survey

#surveys

Comments 2

3 min read

Black Friday 2024: Save 25% on Polypane

Kilian Valkhof — Mon, 25 Nov 2024 09:46:05 +0000

As developers, we're always looking for tools that can streamline our workflow and make responsive design testing less painful. If you've been eyeing Polypane - the powerful browser built specifically for web developers - now's the perfect time to grab it.

The Deal

Polypane is offering a massive 25% discount on all yearly plans for Black Friday. This deal runs until Monday, December 2nd, giving you a limited window to secure a year of faster, more efficient web development at a significant discount.

Why Polypane Matters

For those unfamiliar with Polypane, it's a specialized browser that transforms how you develop and debug websites. Instead of constantly resizing your browser window or switching between different device views, Polypane lets you see, inspect and edit all your breakpoints simultaneously. This means:

Instant visual feedback across multiple screen sizes
Built-in accessibility checks and debugging tools
Synchronized actions across all panes
Advanced CSS debugging and performance insights

Beyond that, Polypane helps you gain insight into your meta tag info (including previews of how your site looks shared on nine different social media sites), accessibility, cookies and other storage and your web vitals performance. There's tooling for all aspects of your web development.

Developer Productivity Impact

The real value of Polypane comes from the time it saves. By seeing all your layouts at once, you catch responsive design issues immediately rather than discovering them later in testing. This translates to faster development cycles and more robust websites.

Grab the Deal

If you're ready to upgrade your development workflow, head over to Polypane's Black Friday page to claim your 25% discount. Remember, this offer ends Monday, December 2nd.

Your future self will thank you for making the investment in better development tools. Happy coding!

Polypane 20: Browser features and performance

Kilian Valkhof — Wed, 19 Jun 2024 13:16:32 +0000

Polypane 20 improves the features and performance of the Elements and Outline panel, as well as improving general browser features and stability. It's also running the latest version of Chromium, 126.

What's Polypane? Polypane is the web browser for ambitious web developers. It's a stand-alone browser that shows
sites in multiple fully synced panes and helps you make your site more responsive, more accessible and faster.

With Polypane 19 being only a few weeks old we weren't planning on releasing a major version so soon, but we wanted to get the new Chromium version out to you as soon as possible.

Because of that this release is a little light on new features, but it does include a lot of smaller improvements and fixes that make a real difference in day-to-day usage.

Elements panel

The Elements panel is where you can inspect and edit the DOM and CSS across all opened panes at once.

As more CSS features become available we work hard to implement them (often before other devtools do, like @layer support in Polypane 8 or native CSS nesting in Polypane 13) and to make sure the panel is still as fast as possible.

Performance

In this release we made a significant improvement in how we index the CSS styles for each pane. In some situations that is now an order of magnitude faster.

This means that the initial load of the Elements panel is faster, and that the panel is much more responsive when switching between DOM nodes even in more complex pages.

`@starting-style` support

The @starting-style at-rule is really cool: it lets you define the initial style for an element when adding it to the DOM. This means that you can now animate elements as you add them to the DOM without needing JS. In Polypane you can now access that @starting-style like any other CSS rule.

You won't find this in the Chromium devtools yet so if you want to experiment with it, Polypane is the place to do it.

A11y panel updates

In the accessibility panel we now have two new checks for the accessible name.

Warning for missing accessible names

Firstly, Polypane now knows which elements should have an accessible name (like headings, links, buttons etc) and will warn you if the selected element is missing one. Just a quick little test that will catch small issues. Note that this can also easily be checked in the Outline panel.

Warning for repetition in the accessible name

An often found accessibility issue is the following scenario:

<a href="/">
  <img src="home-icon.svg" alt="Home" />
  Home
</a>

Superficially this looks pretty good:

it's a real link;
it has readable text;
the image has an alt text.

But when this is sent to a screen reader, it will read out "Home Home" because the accessible name for the link is the combination of the alt text and the text content.

Polypane now check for repetition in accessible names and warns you when it finds them, and will also work with more complex repetition.

Writing the function/algorithm for this was a lot of fun, and we'll explain how we did it in a future blog post.

Other Elements panel improvements

In this release we've improved the sorting of autocompletion suggestions when adding new CSS properties. In Polypane 19 we made suggestions purely on frequency (so if you types fo that would be autocompleted to font-style, as that's more likely than font or font-display) and in Polypane 20 this is now expanded to prefer the shortest property name when the frequencies are close. Long story short, it should make the suggestion feel even more natural.
When you have a top level & in your CSS that applies the styling to :root. Polypane now correctly shows this selector in the Elements panel.
The Elements panel now supports the round(), mod() and rem() CSS functions.
Along with aria-hidden, the DOM view now also highlights the inert attribute.

Outline panel

We added some new checks to the Outline panel, and improved its performance too.

Performance improvements

Instead of getting accessibility data directly from the rendered page, we now get it from the accessibility tree that Chromium generates. This moves the work out of the main process and into a separate process, which makes the panel faster and more stable.

Looking ahead: full accessibility tree view

In a future release, this means we'll also introduce a full accessibility tree view. If you have suggestions on how we can make that the most useful for you, let us know!

Cap on automatic link testing

The Link overview in the panel will automatically check all links on a page to see if they don't go to broken pages, so you catch broken URLs without having to click each one.

This is great when you have a few links, but when you have a lot of links this takes a lot of processing as well as bandwidth (for you and your server).

So we've added a cap. When there are more than 100 links on a page, Polypane shows a "Check status" button that you have to click before we go and check them all.

Accessible name vs visible name

The Outline panel now also checks the visible name of an element against the accessible name.
The visible text should be the same as the accessible name, or a substring off it. When it's not this could be a violation of WCAG success criterion 2.5.3, so we flag that for you.

For example, on the homepage of Polypane we have a title with some fancy styling, and that styling interferes with the accessible name (removing spaces) so we overwrite that with a aria-label attribute. Then we (let's not hide behind "we". It was I, Kilian) changed the visible text to a much cooler title, but forgot to update the aria-label attribute. Polypane now catches that for me.

If the visible text is a substring of the accessible name, we show the difference but this isn't considered a violation (on its own).

Repetition in accessible names

Like in the Elements panel, we now also check for repetition in accessible names in the Outline panel. Here too we show the repeating parts so you can quickly validate if it's a problem or not.

Support for heading levels 7 through 9

When it comes to accessibility, there's always more to know. Turns out that aria-level doesn't just match up to H1 through H6, but you can actually go all the way up to level 9 and browsers will still understand it.

...Except you probably shouldn't be using them, so we now flag it as a warning. If you find your structure needs them you're probably better off splitting that page or restructuring your content.

Heading levels beyond 9 however are not supported at all by browsers and aren't communicated as such to assistive technology. Those we will flag as an error.

Load failure messages

The earliest few version of Polypane had a load error state but we lost them during a refactor. It took us a while but now they're back, and updated!

When a page fails to load, Polypane will show a message in the pane that failed to load, so you know what's going on. Depending on the type of failure it tries to be a little helpful. Most often it's either a typo, a network issue or the server is gone.

Like any serious browser, this error message should also have some sort of game in it. Obviously. So I'm asking you:

What kind of game would you like to see in Polypane? A snake game where the snake travels across all panes? A pong or breakout game where you control the paddle in all panes and you're playing multiple games at once? A game where you have to find the differences between two panes? Let me know (on Twitter, via email or the chat)! ...Bonus points if I don't have to build something from scratch.

Screenshotting improvements

We've made various small improvements to the screenshotting functionality in Polypane.

Dashed and dotted lines in the screenshot editor

You can now draw dashed and dotted lines in the screenshot editor. Thanks Rik for enabling this in Pintura!

Easy access to the storage folder

When you take a screenshot and quick-save it, it will automatically be saved to the last used folder. We've now added a link to open that folder directly from the context menu of screenshot buttons.

Overview screenshot distortion (fix)

In vertical layout, sometimes the panes in an overview screenshot would get distorted, depending on things like multiple monitors with different pixel ratios and other fun situations. This is now fixed.

Address bar

The address bar in Polypane can match URLs and page titles based on fragments. So you can type po blo 20 to get to e.g. https://polypane.app/blog/polypane-20-browser-features-and-performance/.

The algorithm behind it now prefers perfect matches over multiple partial matches. So if you type "sign in" it will put urls with "sign in" in the url or title higher than other URLs that might contain both "sign" and "in" at different points in the URL.

It's a small tweak but it makes the address bar feel much more dependable.

Chromium 126

Polypane 20 includes an updated Chromium version, 126.0.6478.36. This lands cross-document view transitions and the Chromium devtools performance panel got a lot of improvements.

For an overview of the new experimental features enabled in 126, head over to our experimental features overview: Experimental Chromium Web Platform Features and for additional info, head over to the experimental chromium features docs.

Get Polypane 20

Polypane is available for Windows, Mac and Linux (.deb or AppImage) in both 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 20 Changelog

New

New Elements panel: @starting-style support
New Elements panel: Accessible name missing warnings (Thanks Torrance!)
New Outline panel: check visible name against accessible name (WCAG SC 2.5.3) Thanks Markus!
New Accessible names check for repeating substrings (Thanks Eric!)
New Screenshot editor: dotted and dashed line support (Thanks Eric and Rik!)
New Page load failure messages
New Chromium 126

Improved

Improved Elements panel: better sorting of suggested CSS properties
Improved Elements panel: Support for round(), mode() and rem() CSS functions
Improved Elements panel: Support for top level &
Improved Elements panel: Support for nested at-rules
Improved Elements panel: increase the number of CSS rules Polypane can process at once
Improved Elements panel: significant performance improvements for nested styles
Improved Elements panel: Highlight the inert attribute
Improved Outline panel: With more than 100 links, testing them is now an explicit action
Improved Address bar: Prefer perfect matches in suggestions when typing fragments
Improved Screenshots: add 'open folder' link in context menus of screenshot buttons
Improved Command bar: Allow matching by category (Thanks Artem!)
Improved Show a error message for unsupported state files
Improved Outline panel: support for heading levels 7 through 9
Improved Performance: Get and use accessibility tree out-of-process
Improved Live CSS panel: Support folding CSS code
Improved Touch emulation: Easier toggle between touch in pane and normal mouse outside of pane
Improved Add cmd+shift+brackets to nagivate between tabs (Thanks Jerod!)
Improved Responsiveness of resizing the devtools and browser panels
Improved Updated Google Fonts

Fixes

Fix Elements panel: pressing : when adding a css property no longer applies the suggestion.
Fix Elements panel: Only add anonymous scoping roots when style elements contains them.
Fix Workspace panel: preview for 100% height panes are now visible again (Thanks Artem!)
Fix Command bar: Lorem Ipsum command now works again
Fix Command bar: Show correct shortcuts for next/previous tab on mac
Fix Screenshot menu no longer hidden under devtools (Thanks Ahmad!)
Fix 100% height panes in vertical layout now have a minimum height of 800px.
Fix A11y checks: Prevent input type="hidden" from being marked as focusable
Fix Visible focus styles during signup flow (Thanks Novella!)
Fix Prevent error when failing to write detached panel window state (Thanks John!)
Fix Prevent error when devtools reference is destroyed (Thanks Mike!)
Fix Overview screenshot distortion in vertical layout (Thanks Travis!)
Fix Pane emulation: Prevent auto dark mode from incorrectly showing as on for certain configurations

How to check your site in different languages and writing modes

Kilian Valkhof — Thu, 23 May 2024 09:56:51 +0000

Building sites that support multiple writing modes and languages is challenging. You don't always know the language or even the script, and changing your OS to trigger certain conditions is cumbersome.

Even if you're willing to make that change on your device, during development you might not even have the other languages available to test with.

This post will show you how to test your site in different languages and writing modes without changing your OS settings or having access to your content in other languages (and without having to learn a new language).

Quick terms

When we talk about multi-lingual sites, there are a few terms you should be familiar with:

Writing mode: The direction in which text is written. For example, English is written from left to right, while Arabic is written from right to left.
Page language: The language in which the content of the page is written.
Browser Locale: This defines the user's language and region.

All of these fall under two terms that are also worth knowing:

Localization (often shortened to l10n): The process of adapting a product or content to a specific locale or market: using the right spelling, number formatting, currency, etc.
Internationalization (often shortened to i18n): The process of designing and developing a product or content in a way that it can be easily localized: using the right encoding, designing for multiple text directions, having a resilient layout, etc.

This post dives into how you can test your site in different languages and writing modes without changing your OS settings, so it focuses on the i18n part of the process.

Challenges

When building a site that supports multiple languages and writing modes, you need to consider the following:

Language-dependent Browser APIs like the I18n API, which is used to format dates, numbers, and currencies according to the user's (browser) locale.
Text direction: Some languages are written from left to right, while others are written from right to left. Your site can adapt to this when you take it into account during development.
Text length: Compared to English, some languages have much longer words and sentences while others have much shorter words and sentences. This can cause your layout to break if you don't account for it.

The basics

To make sure your site adapts well to multiple languages and writing modes, you need to make sure that you have the following in place:

The lang attribute: This attribute is used to specify the language of the content of the page.
The dir attribute: This attribute is used to specify the direction of the text of the page.

Both of these attributes go on your <html> tag. From these two attributes, the browser can infer the language and writing mode of the page and adjust accordingly.

The `lang` attribute

The lang attribute should have as its value the language code of the language you are using. It's important to set because it helps search engines know what language your page is in, and assistive technology like screen readers use it to pick the right voice and to make sure pronunciations are correct.

For example, for English you would use en, for Arabic you would use ar, and for Japanese you would use ja.

If you're targeting a specific dialect, you can use the language code followed by a dash and the dialect code. For example, for American English, you would use en-US while for British English you would use en-GB. The general advice though is to use the language code without the region code unless there is a reason why the specific regional dialect is important for this page.

Keep in mind that this doesn't mean you're targeting the USA or the UK specifically, since other countries also use either American English (like Canada) or British English (like Australia).

Occasionally you'll see the language code using an underscore to separate the language and region code, like en_GB. While Firefox normalizes this for you, both Safari and Chrome will not recognize this as a valid language code and so also not expose it to assistive technology.

The `dir` attribute

The dir attribute should have as value either ltr (left-to-right) or rtl (right-to-left) and is used to specify the direction of the text of the page.

The default value on the web is ltr, so you usually only see this added for languages that are written from right to left as <html dir="rtl">.

With these two in place, you've told the browser everything it needs to know about your page.

Testing different languages and writing modes

Now to test for different writing modes and languages, you can change the lang and dir attributes of your page. You could open the element inspector and change these manually but in Polypane, the emulations panel gives you easy access to these features along with the ability to change the browser locale.

Changing the reading direction

To change the reading direction of your page, you can use the dir attribute.

Changing this from ltr to rtl will update the default styling in browsers such that text becomes right-aligned and the "start" value (for example, for flexbox and grid alignment) evaluates to the right. It does this even if your content is still in English.

In Polypane, you can change the reading direction of your page by selecting the desired direction from the emulations dropdown.

With the dir attribute set to rtl, you can test how your site looks when the text is right-aligned. If we check out the screenshot comparing the left-to-right and right-to-left versions we can see that it has done a pretty good job: the navigation is now on the right-hand side and the text mostly still has the correct padding, but we can spot a few things that we should fix:

Visual issues here are:

The 100% bar is still filled to the right.
The "dismiss" button is still on the right side, and the "hide this block" image is no longer pointing at it.
The checkmarks next to each list item are flush against the text and have too much space.

Almost all of these are the result of me using non-logical margins and alignments. Instead of text-align: right on the 100% in the bar, I should be using text-align: end. And instead of margin-right on the checkmarks, I should be using margin-inline-end.

Lastly, the dismiss button is positioned using a float: right. Instead of that, I should be using float: inline-end. The "hide this block" image is a little more involved since the text is baked into the graphic. You would probably switch this out for a different image or decouple the arrow from the text and position them separately.

All in all, the changes you would make here are mostly small and easy to test.

Changing the language

While the lang attribute tells you what language the page is in, it won't change how your page is being displayed.

Browser APIs like the I18n API by default use the browser locale to determine how to format dates, numbers, and currencies. When you emulate the browser locale in Polypane it will update the places where that locale is being used. For example, here's an excerpt with a date from the Polypane blog in English and in Spanish:

To set the language and locale in Polypane you can use the dropdowns in the emulations dropdown. Polypane will autosuggest shortcodes as well as language names so that, for example, you don't have to remember that the language tag for Greenlandic is kl. You type "greenlandic" and Polypane sorts the rest.

Testing your layout

Changing the browser locale or the page lang attribute doesn't change the text itself though. If you want to test how your layout behaves with different text lengths, you'll need to change the text itself.

English text is often shorter than other languages also using the Latin script (like German), but longer than languages like Chinese or Japanese where the characters used often represent more than a single letter in latin script, and sometimes a single character can even be an entire word (For example, 母 is "mother" in Chinese).

Emulating text length

Rather than doing a full-page translation, potentially in a language you can't read, you can use the Content Chaos feature in Polypane to replace all text on your page with random text. This way you can test how your layout behaves with different text lengths without translating the entire page.

Content Chaos testing is not just useful for testing different languages, but also for making sure that once the perfectly designed text is replaced with real content, your layout still holds up.

To check if your layout handles longer titles well, you can use the "More text" option:

You can see that the list of buttons on the left side responds well to more text: the content wraps and stays centered in the button, without having a weird line-height.

The main content is overflowing though, and that's because the button is not constrained in width. I can fix this by adding a max-width to the button, or by using overflow-wrap: break-word on the text.

If you want to test how your layout behaves with shorter text, you can use the "Less text" option:

Here you can see that the layout is still working well. Even with little text the buttons are still easily clickable and the layout doesn't break. I don't have to fix anything here to accommodate for languages with shorter text.

Checking the line length

Another thing to keep in mind is the number of characters in a line. While the specific recommendations differ quite widely between sources, the general consensus is that you want to keep the line length short enough that it's easy to read, but long enough that you're not wasting space: between 45 to 70 characters per line, or (roughly) 10 words for English. To check these values, highlight a line and right-click to see the number of characters and words in that line.

This feature is aware of the language the page is in so will correctly detect real characters and words, as well as emoji and sentences.

for CJK (Chinese, Japanese and Korean) characters you want to aim for roughly half the number of characters per line as you would for Latin characters. This is because CJK characters are about twice as wide as those in the Latin script. This advice comes from the WCAG 1.4.8 Visual Presentation Understanding page. Those are not part of WCAG itself, but meant to help you understand them.

Conclusion

To check your layout and implementation for multiple languages, you'll want to check with different dir, lang, and browser locales. You can change these on an OS level, or emulate them in Polypane.

Rather than translating your entire page into a language you don't understand, you can use the Content Chaos feature to test how your layout behaves with different text lengths and make sure there aren't any errors when the text is longer or shorter than you expected.

The gotchas of CSS Nesting

Kilian Valkhof — Tue, 13 Jun 2023 10:53:40 +0000

I've written before about the problems you can run into with CSS nesting (keep in mind that article uses an older syntax but the point still stands) and the question that @ChallengeCSS tweeted out today made me realize there's actually a few more gotcha's. Here's what they tweeted:

Everyone is exited about CSS Nesting but are you ready for it? Answer the below quiz 👇

What would be the result of the following code (without cheating! 😈)
body {
 @media all {
   background: red;
 }
 background: blue;
}

Take a moment to come up with your own answer (or vote), then read on.

Now, I initially got it wrong. Here was my thinking pattern:

@media doesn't add specificity, so both declarations have a specificity of 0,0,1
background: blue comes later, so it wins

But no, the background is red! It turns out that has to do with the way browsers transform your nested CSS rules to individual rules it can apply. So lets dive into how browsers do that.

A related gotcha: `:is()`

Last week was CSS Day (which was amazing) and of course a bunch of the presentations mentioned CSS Nesting. Unfortunately, some had a simplified explanation of how rules get resolved.

The & in nested CSS isn't just replaced by the ancestor, which is what you might think, but it's ancestor is also wrapped in :is():

body {
    & div {
        ...
    }
}

/* Doesn't become this: */
body div { ... }

/* It becomes this: */
:is(body) div { ... }

Now that doesn't sound like there is much of a difference between body div and :is(body) div, indeed both have a specificity of 0,0,2, but remember that:is() takes on the highest specificity of the selectors in it. So when you have the following:

main, #intro {
    & div {
        ...
    }
}

The resulting selector, even when targeting a div in main, ends up as:

:is(main, #intro) div { ... }

Which makes it go from 0,0,1 for main div to 1,0,1 making it vastly more specific. That gotcha gets lost when examples fail to include the way ancestors are wrapped in :is() (and yes, they also nest :is()!)

Back to the original gotcha

So back to the challenge up top. You can intermingle properties and nesting. You shouldn't to keep your code readable, but the following CSS works just fine and applies all the styling:

body {
  filter: blur(5px);

  @media all {
    background: red;
  }

  background: blue;

  @media all {
    color: deeppink;
  }

  rotate: 20deg;
}

It's when the browser parses this CSS into individual rules that the sneaky thing happens:

The browser adds a new ruleset, body, and starts adding the properties to it/
The browser then adds another new ruleset for the nested media query and starts adding its properties to it/
When it exits the nested media query, it adds the rest of the properties to the original ruleset again until that is exited.

So if we look at this CSS again:

body {
    @media all {
        background: red;
    }
    background: blue;
}

That actually resolves to these two rules in this specific order:

body {
    background: blue;
}
@media all {
    :is(body) {
        background: red;
    }
}

Now from this CSS, it makes more sense that red wins. While it has the same specificity, it comes after the first rule so it wins. And that's the gotcha.

This post originally claimed that only @-rules could be intermingled with properties but this was incorrect. Thanks @ChallengesCSS for correcting me.

:root isn't global

Kilian Valkhof — Wed, 03 May 2023 09:50:47 +0000

Most developers prefer to keep all their CSS custom properties in one place, and a pattern that has emerged in recent years is to put those on :root, a pseudo-element that targets the topmost element in your document (so that's always <html> on web pages). But just because they're in one place and in the topmost element, it doesn't mean they're global.

I first encountered this issue with ::backdrop: Backdrop doesn't inherit from anywhere but after a recent rendering engine update to Polypane I noticed that all my custom selection colors (also powered by CSS custom properties) suddenly stopped working.

Turns out, ::selection is also not supposed to inherit styles, and Chromium 111+ is running an experiment to see what effect changing that has. Polypane runs with experimental features turned on, and so my selection styles became broken.

This is going to catch a lot of people off-guard because I, like many others, expect CSS Custom properties defined on :root to just be available everywhere. I guess I would also expect ::selection and ::backdrop to inherit from their "parent" element to allow more dynamic styling, but the spec writes apparently don't want this.

So if `:root` isn't global, what is?

Well, the jury's still out.

Discussions are happening in this GitHub issue: Custom properties on :root with a few options being discussed:

Use @property with an initial value (not cross-browser supported yet, only uses the initial value).
Make :root special.
Create a new :document pseudo-element that does propagate custom properties.
Create an new at-rule called @global, @root or @document that you could define custom properties in.
Make ::selection etc inherit from their originating element (e.g. "their parent").

That last item would solve both the problems people run into (it not inheriting, and it potentially inheriting directly from :root so you can't overwrite custom properties in the cascade). I hope spec writers choose to do this regardless.

Specifically, I want/expect this to work:

p {
    --selection-bg: #0f0;
    &::selection {
        background: var(--selection-bg);
    }
}

When it comes to "a place to store global variables" I have no strong opinion, though I think it's interesting to keep in mind that in JavaScript there is now window, global and globalThis because the naming across contexts didn't work.

In that light, :document or @document seem potentially problematic. For that reason, I like @global or :global (I haven't actually seen global as a pseudo-element suggested yet, but it seems to be closest to how people expect things to work now).

In the mean time, you can use the suggestion I made in my ::backdrop post and replace :root with :root ::backdrop ::selection. Sorry about that.

A small JavaScript pattern I enjoy using

Kilian Valkhof — Thu, 06 Apr 2023 12:06:32 +0000

There is a JavaScript pattern that I enjoy using that I don’t see a lot around the web, so I figured it would be worth sharing.

When you have a piece of business logic, frequently that depends on a a certain value being true. An if statement:

if ( status === 'active' ) { … }

This is easy to parse for me and I can quickly see what it does. What often ends up happening though is that the business logic gets a second possibility, for example status being active or status being trialing:

if ( status === 'active' || status === 'trialing') { … }

This is still relatively easy to read but there’s repetition with ‘status’ and I always need a second to think about the difference between || and && to understand the behavior. So whenever I move from checking from one value to more than one, I switch to a different pattern:

if (['active', 'trialing'].includes(status)) { … }

I make an array of all possible values and then use Array.includes() to check if the status is contained in that array.

This pattern comfortably grows to many items and can also more easily be read aloud, helping understanding.

There is no repetition so as a small bonus it’s shorter. It has also helped me learn the difference between includes, contains and has.

Partial string matching

I get a lot of mileage out of the above pattern, but it only works when you’re matching the full string. Sometimes you need to check just the beginning or the end of a string and then .includes() won’t cut it because it only accepts values, not a function.

We don’t want to go back to multiple checks and the repetition that gives so if we need to check for a part of the string we need to change the function we use:

['http://', 'https://', 'file://', 'www.'].some(s => clipboard.startsWith(s)) { … }

Array.some() takes a function and returns a Boolean. It’s a little longer but we’re still not repeating ourselves. A nice benefit is that like includes() it will stop evaluating when it returns true, so we usually don’t have to loop over all the elements.

In the examples above I inlined the array but of course you can also store it in a global variable. That gives you the additional benefit of only instantiating a single array that you can reuse and that lets you update many checks in one go, should the business requirements change.

As I said, I get a lot of use out of this pattern. I hope this helps you recognize when it’ll be useful in your code in the future!

The breakpoints we tested in 2021, and the ones to test in 2022

Kilian Valkhof — Wed, 19 Jan 2022 16:23:26 +0000

Which screen sizes to design, build and test on is a perennial topic in web development. While well-built responsive websites will work at any size, during development it's easier to use a small number of sizes to check with (even in Polypane!)

But what sizes to use? There's a number of different approaches we'll go over in this article, all updated to be relevant in 2022.

Base it off device groups: mobile, tablet, laptop and desktop.
Use the breakpoints from popular CSS frameworks.
Using the dimensions your visitors use.
Using the most used breakpoints of 2021.

Based on device sizes

There's mobile phones, tablets, laptops and desktops, so if you use size for each of that category, you cover them:

Name	Width
Mobile	375px
Tablet	768px
Laptop	1280px
Desktop	1920px

This gives a good overview, but you run the risk of missing the in-between sizes, smaller than 375px and between 900 and 1000px wide.

Both of those are often forgotten, but still see quite a bit of real-life usage. The first one in older mobile phones, and the second one on tablets, laptops and desktops in unmaximized browser windows.

Based on popular CSS frameworks

We've written about the breakpoints that popular CSS frameworks use before. These are excellent when you're also using the rest of the framework, or as a starting-off point. For example, here's the breakpoints in Tailwind CSS 3.0:

Name	Width
sm	640px
md	768px
lg	1024px
xl	1280px
2xl	1536px

This gives a nice spread, though with a relatively high starting point you run the risk of having to do extra work after implementing the design to make sure everything fit on mobile devices.

Based on your visitor data

If you use Google Analytics, your visitors browser dimensions are stored as well. This means you can retrieve them from the Google Analytics dashboard and use those to test on.

For example, here's the 5 most used dimension on this site:

Name	Width	Height
4.55%	1900px	940px
2.13%	1900px	970px
2.02%	1520px	750px
1.99%	1350px	660px
1.95%	1350px	630px

While you can use the above it's important to realize that our audience probably isn't your audience. Polypane is a tool for web developers, so the vast majority of our visitors are viewing our site on a desktop device, and fairly large ones at that.

Notice too that none of the most popular sizes here map to the traditional device widths mentioned above. Every audience is different, and it's best to cater to yours.

Create a Polypane workspace based on Google Analytics

You can also use our GA workspace creator to automate the process, select how many panes you want and how to sort them, and then opening them in Polypane with a single click.

The breakpoints we tested in 2021

That leaves us with the last method: using the breakpoints that have been used the most in 2021. For that we can use two sources: the Web Almanac and Polypane.

From the Web Almanac

The Web Almanac analysed 8.2 million websites, old and new, to make an overview of the most used web features, including breakpoints. That also includes all the sites in the web almanacs testing data that existed (well) before this year.

It has a chapter on CSS that includes a list of common breakpoints. It's worth reading the analysis: they make a split between min-width and max-width media queries because you can see a clear difference in sizes used (min-width is more often used for 767px while max-width for 768px, for example). We're splitting those out in the overview below as well, as they give a nice contrast.

Min-width

Name	Width
57%	768px
44%	1200px
40%	992px
31%	600px
25%	782px
24%	480px
16%	1024px
9%	767px
8%	800px
3%	991px

Max-width

Name	Width
52%	767px
38%	600px
38%	768px
36%	480px
30%	991px
27%	1024px
26%	800px
18%	1200px
13%	992px
10%	782px

When it comes to the difference between min-width and max-width, apart from the 1px differences here and there, is
that the spread for max-width is much more diverse. For min-width, the top 10 goes from 57% usage to 3%, while max-width starts lower, at 52%, and ends higher, at 10%.

Min-widths means you're adding styling as you get wider, while max-widths usually disable styling as they get smaller. Because of this, you frequently need less min-widths, and your styling works for a longer time before you need a new breakpoint.

The most-used breakpoints in Polypane in 2021

We can also look at the most used pane sizes in Polypane in 2021. The sizes that real developers have used the most in the past year to develop websites with.

This gives the most accurate look at what sizes modern sites are optimized for. Here is the top 10 for 2021:

Name	Width
5.48%	320px
4.49%	1280px
3.41%	768px
2.41%	1920px
2.19%	500px
1.89%	568px
1.86%	800px
1.81%	375px
1.69%	1024px
1.25%	1440px

If we look at these sizes we see a nice spread between device sizes, breakpoints from CSS Frameworks and the many presets that Polypane ships with.

The breakpoints to develop on in 2022

As you can see from the relatively low percentages, there are thousands of other sizes being used in Polypane. There is no single right set of dimensions.

So the best answer? Pick a set you like and adapt it. Any of the ones on this page are a good choice.

If you notice you often make errors at a size you're not currently developing for, make sure to add it. And if you find yourself fixing the same issue at multiple sizes, maybe you can hide one of them during development.

Regardless of which default sizes you choose to develop on, it's best to see all of them in one overview. That's what Polypane lets you do. All the other parts of your browser are synced as well: your interactions happen in all panes, our elements panel lets you edit and inspect elements in all
panes at the same time, and our console intelligently combines messages from each pane.

Polypane has a free 14 trial available. Check it out!

The EyeDropper API: Pick colors from anywhere on your screen

Kilian Valkhof — Thu, 11 Nov 2021 13:52:32 +0000

With the new EyeDropper API in Chromium, websites can let visitors pick colors from anywhere on their screen, adding another
feature to the web that used to require hacky solutions and is now just a few lines of code. The API is
clean and modern and easy to use. In this article we'll discuss how to set it up, handle edge cases and additional features
we hope will land in future updates.

We've been following the EyeDropper API since it was first proposed and have been experimenting with it as different
parts became available as well as providing input while the feature was being developed. In Polypane 7
we started using it extensively for the new color picker and new palettes.

How to use the EyeDropper API

The API adds a new global, EyeDropper (or window.EyeDropper) that you can use to set up a new eyedropper object:

const eyeDropper = new EyeDropper();

This eyeDropper object has one function, eyeDropper.open(). This starts the color picker and changes the users cursor
into a color picker, complete with magnified area and a highlighted pixel. This function returns a promise, so you can
use it either with await or as a promise.

One gotcha is that it only works when called from a user-initiated event. This is part of the security model, to
prevent websites from potentially scraping pixels without the user knowing.

Detecting support for the EyeDropper API

Because the API is only available in Chromium you will need to check for support before using it. The most straightforward
way to do that is to only offer your color picking UI when window.EyeDropper is not undefined:

if (window.EyeDropper) {
  // Okay to use EyeDropper
} else {
  // Hide the UI
}

`await` based version

// won't work
const result = await eyeDropper.open();

// works
document.queryselector('.colorbutton')
  .addEventListener('click', async () => {
    const result = await eyeDropper.open();
  });

The eyeDropper.open() call will resolve in two situations:

The user clicks anywhere on the screen.
The user pressed the Esc key.

In the last situation the eyeDropper will throw an exception, but in the first situation you will get a ColorSelectionResult
object, which has an sRGBHex property containing the picked color in hexadecimal format. In your code you can check if
result.sRGBHex is defined and then do with it what you want.

document.queryselector('.colorbutton')
  .addEventListener('click', async () => {
    const result = await eyeDropper.open();

    if (result.sRGBHex) {
      console.log(result.sRGBHex);
    }
  });

You don't have to handle the exception but if you wanted to provide the user feedback that they cancelled the eyedropper,
you need to add a try .. catch to the code:

document.queryselector('.colorbutton')
  .addEventListener('click', async () => {
    try {
      const result = await eyeDropper.open();

      if (result.sRGBHex) {
        console.log(result.sRGBHex);
      }
    } catch (e) {
      console.log(e);
      // "DOMException: The user canceled the selection."
    }
  });

Promise based version

You don't have to use the await version. eyeDropper.open() returns a promise, so adding a .then() and .catch() also works:

document.queryselector('.colorbutton')
  .addEventListener('click', () => {
    eyeDropper
      .open()
      .then((result) => {
        console.log(result.sRGBHex);
      })
      .catch((e) => {
        console.log(e);
        // "DOMException: The user canceled the selection."
      });
  });

Things to keep in mind when using the EyeDropper API

There are two gotchas with the API, at least as it's currently implemented in Chromium that we've found that you should
be aware of.

Color picking does not use the live screen

At least in the current implementation, the color picker get the pixels as shown on the screen when you call .open().
This means that if you're playing video the color picker will show the pixels of the frame that was visible then, not the
live video.

This is dependent on the implementation and we hope a future update of Chromium will allow for live data.

Color picking only works as the result of a user action

As mentioned earlier you need a user initiated event to open the eye dropper. This is to prevent sites from opening the
eyedropper UI to start scraping your screen right on load. Instead the user needs to perform an action for the API to work,
like a click or keypress.

Features we want to see added

The EyeDropper API is still very young and minimal. During our implementation we encountered a number of features that we
would like to see added to the API in future updates.

Live preview of the hovered color

A major component of many eye droppers, like those in design tools, is that they also show a preview swatch of the
hovered color. You can use this to compare it to another swatch or quickly check a HEX code. The current API does not
offer this over security concerns. We have filed an issue against the EyeDropper API on GitHub for this: #6 Live feedback is needed.

A more extensive color model

Currently, all colors are returned in the sRGB color model. This means the API won't accurately return colors outside
the sRGB spectrum, for example those on Apple's P3 screens. How to deal with this is an open issue.
Work is also happening on a new Color API for the web. The EyeDropper API could use
this Color API when it lands in future versions of browsers.

A more natural way to select multiple colors

Because of the current security model, each time a user picks a color they need to re-initiate a user action which can be tedious.
For example if you want to create a palette of colors in one go, you want to start picking colors, click on all the colors you
want to add and then close out of the eye dropper. We similarly filed an issue for this on Github: #9 Do we expect multiselect to work? and this feature is currently being considered.

For this it would be nice if we could designate a part of the page (like a button) as an area where the EyeDropper
doesn't work, that instead functions as a "done" button. This way users can select multiple colors and then click that
button when they're done.

Other browsers

For now, the API is only available in Chromium based browsers from version 95 on and there has not been a signal from
Safari and Firefox yet. If you want those browsers to support the EyeDropper API as well, add your support to the open issues:
Issue #1728527 for Firefox and Issue #229755 for Safari.

The EyeDropper API is a nice addition to the browser that we hope to see land in more browsers. We make good use of it
in Polypane and would like to see it be developed further.

Polypane 6.2: HTML validation, robots.txt support, RTL emulation and more

Kilian Valkhof — Mon, 26 Jul 2021 13:48:32 +0000

In Polypane 6.2 we focused on improving the app performance and consistency, particularly around updating, pane resizing, tab handling and dark mode.

We still added a fair few new features, including some that many of you have been requesting. Here's everything new in Polypane 6.2:

HTML validation

The source panel in Polypane now automatically validates your HTML for you. A lot of you have been asking for this, and now it's here!

The HTML validation in Polypane is 100% local so you're not uploading your HTML source (potentially with user data!) to an online validator, and we check the generated source (which the source panel also displays) so you can check the HTML generated by frameworks as well.

For any of the issues you can hover over the element to highlight the elements in all panes. The source panel itself will also scroll to the issue in the HTML and highlight it. Clicking the element takes you to the Elements panel so you can fix the issue.

Toybox systems integration

We've been in contact with the folks that built Toybox systems for a while now and a few months ago we set out to create an integration between Toybox Systems and Polypane. Today, we release it!

Toybox System is a bug reporting tool that makes it really easy to take a screenshot of a part of the page and then share a message with your team. The integration in Polypane lets you create screenshots, drop pins and leave comments and inspect everyone else's comments right inside a pane.

We're very excited about this integration! It makes Polypane an even better tool for QA, since you find issues much faster with Polypane, and now report them super fast using Toybox Systems.

This is the first of a few integrations we plan on releasing. If there are other tools you'd like to see integrated into Polypane, let us know!

Robots.txt support

The Meta panel now shows your site's robots.txt file, ordered by user agent. If you have a robots meta tag, we also show that here so you get the full overview.

Polypane automatically checks if the current page is blocked for each user agent and if you have settings that aren't supported by that user-agent.

As with all other entries in the Meta panel, you can copy each Robots.txt declaration and we'll automatically format it correctly for you.

Other meta panel improvements

The social media previews in the Meta panel have always had support for the light and dark themes of different social media (provided they had one, looking at you LinkedIn) but you had to switch the theme of the entire browser to see them. We've now added a toggle to the previews so you don't have to do that anymore.

We've also improved the accuracy of the Twitter, Facebook and Google previews.

Now that Safari 15 is going to support multiple theme colors, Polypane has been updated to show these in a list together with their media value. Clicking the color preview now copies the color.

Lastly, we've improved many of the checks and warnings in the Meta panel. We now warn about canonical urls that dont have the right format, viewports that limit the user, missing alt attributes and incorrect formatting for image URLs.

RTL emulation

Most of the web is in English, a language that reads from left-to-right. But there are many languages that you read from right-to-left, like Arabic, Hebrew, Farsi and Urdu. Websites in these languages can be given an RTL (right-to-left) direction that tells the browser to render everything in that reading mode. It flips the text-alignment as well as moves the position of markers and other browser-native things.

For people developing bidirectional websites, switching between LTR and RTL often involved editing the source in devtools, updating a cookie or updating the code elsewhere. With the new RTL emulation in Polypane, doing this takes a single click.

Even if you don't create bidirectional websites, you can also use this to check if your logical properties are configured correctly. Properties like margin-inline-end will automatically flip from the right-side to the left-side when switching from LTR to RTL rendering.

Message bus

As a result of our work on supporting Web Components we've been working with a few beta testers to built a new system for developers to communicate between panes, the Polypane Message Bus.

With this message bus you can send and handle messages between panes, letting you implement your own syncing logic where Polypane can't, like for canvas-based websites (like games) or web components with a closed root.

The message bus is very lightweight while unlocking a whole new way for developers and QA to test their sites across viewports and emulated devices. We can't wait to see what you'll do with it!

Check out the documentation on the Message Bus for the API specification.

Other features

Rewritten update logic

The updating logic in Polypane hasn't been touched in a fair few releases and had bugs that prevented some users from automatically updating. For 6.2 we completely rewrote our updating logic. If you experienced issues updating those should be gone from 6.2 onwards.

Disable CSP (Content-security-policy) headers

Polypane does not touch CSP headers in default mode. Unfortunately that means that with very strict CSP settings, certain Polypane functionality is also blocked from running. If this happens on one of your sites, you can now disable CSP in the Edit menu.

New devices

We added new Android devices (based on popularity) and a new UHD (4K) preset. If you're missing a device you want Polypane to emulate, please let us know!

Live reload improvements

Live reload now automatically ignores dotfolders (it already ignored dotfiles) and will ignore any custom query parameters when hot reloading CSS files. This will cause updates to be more performant and CSS updates in particular to happen faster.

Outline panel warnings

We've greatly expanded the number and type of warnings we give in the outline panel, as well as add more support for outlines created with aria attributes.

For the Landmarks overview, we'll now warn about missing-but-expected element, elements of which we expect just one but see multiple, and when landmarks are nested in other landmarks in an unexpected way.

The Links overview now warns you about empty content or href attributes that point to using links for JS logic.

The Focus order overview incorrectly ignored summary elements, but now reports them in the overview.

For the Image overview we made the first step towards helping you create better alt text. Polypane will now warn you when you use redundant language in your alt text, like "image of...".

Of course after implementing that last feature, we promptly found (and fixed) an image on our own site with exactly that alt text!

Color contrast checker

We've improved the color contrast checker under the hood, making it more accurate and implementing an updated design that makes it easier to see which element is checked. We also fixed an issue where some sites didn't allow you to copy the suggestion on click.

Quality-of-life improvements

There's many other Quality-of-life improvements in this release. Interacting with tabs is now more similar to other browsers, the performance of pane resizing has drastically improved, you can right-click a single pane to reload just that pane, we improved the performance of animations across the application and much more.

Check the changelog below for the full list of updates, and of course every new and improved feature has been added to the documentation.

Get Polypane 6.2

Polypane is available for Windows, Mac (with versions for Intel and M1) and Linux (.deb or AppImage).

Polypane automatically updates on Mac and Windows. Linux users need to download the new version from
the download page. You can find the Mac and Windows versions on that page too.

Don't have Polypane yet? There is a 14 day trial available. Try it for free.

Full Changelog

New Features

New HTML validation in the Source panel
New Toybox Systems integration
New Robots.txt support in Meta panel
New RTL emulation
New Disable CSP option
New New Samsung and Redmi devices and UHD presets
New Polypane Message Bus

Improvements

Improved Rewritten update logic
Improved Significant improvement to pane resize performance
Improved Meta Panel previews can now be toggled between light and dark mode
Improved Meta panel warns about incorrectly formatted canonical urls
Improved Meta panel warns about viewports that limit scaling
Improved Meta panel supports multiple theme colors and displays their media attribute
Improved Meta panel click a theme color to copy it
Improved Meta panel checks for missing image alt text
Improved Meta panel checks image url formatting
Improved Meta panel rendering of Twitter preview
Improved Meta panel rendering of Facebook preview
Improved Updated Electron
Improved Updated accessibility rules
Improved Updated Google Fonts list
Improved Live reload now ignored all dotfolders
Improved Live reload ignores query params when injecting CSS (Thanks Winston!)
Improved Color contrast labels have updated design
Improved Color contrast checking can now detect contrast issues for floated elements
Improved Color contrast can now copy colors regardless of site settings
Improved Source panel now includes doctype
Improved Outline panel Headings now includes aria-role headings
Improved Outline panel Landmarks now warn about missing elements
Improved Outline panel Landmarks now warn about duplicate elements
Improved Outline panel Landmarks now warn about illegal nesting
Improved Outline panel Links now warn about href or content being empty
Improved Outline panel Focus order now supports summary elements
Improved Outline panel Images warns about redundant text in the alt attribute
Improved Outline panel shows messages when no elements can be found
Improved DOM Treemap devtools extension added (Thanks Christian!)
Improved Support for web component syncing
Improved Clearer active state for inspect button in dark mode (Thanks John!)
Improved Add 'reload and 'reload this pane' options to context menu
Improved Elements panel now supports complex specificity calculations
Improved Improve consistency of colors in dark mode UI
Improved Pane load performance improvements
Improved Improve help text for undocked devtools in Devtools panel
Improved Animation performance across the app
Improved Double click or middle mouse click the tab bar to open a new tab
Improved Click sync for inputs in labels now syncs correct state
Improved Webvitals logic updated, CLS now live-updates
Improved Hover tooltip now shows font weight (Thanks Stephan!)
Improved Clarify wording in a11y panel (Thanks Roel!)

Fixes

Fix Middle mouse clicking a tab now closes it without first focusing it
Fix Element normalization causing issues with Svelte updating (Thanks Richard!)
Fix Overview screenshot on Windows had incorrect dimensions
Fix 'open with Polypane' for HTML files
Fix Touch emulation toggling applies immediately
Fix Outline Panel Focus elements now match other outlines.
Fix Design issue with viewport/device size toggle
Fix CSS button in address bar opened the wrong panel
Fix Aspect ratios no longer sort largest first
Fix Resolve syntax error when emulating a user agent
Fix Reset Window dimensions on launch if launching on different screen configuration (Thanks Claudia!)
Fix Resolve issue in Outline panel when sites have images without SRC attribute
Fix Elements panel color editor can now set opacity again
Fix Elements panel height of add attribute form now correct
Fix 'nodeName of undefined' error message
Fix Meta panel now supports objects in oEmbed
Fix opening URLs from browser extension on Linux
Fix Release notes overlay displays release notes again
Fix overflow issue in a11y panel with large text size (Thanks Hidde!)
Fix Ctrl + needed shift to zoom in (Thanks Alex!)

Detecting media query support in CSS and JavaScript

Kilian Valkhof — Tue, 13 Jul 2021 13:48:18 +0000

Recently I needed a way to detect support for a media query in CSS and JavaScript. To detect if a browser supports a certain CSS feature, you can use @supports () { ... }, but that doesn't work for media queries. In this article I'll show you how you can.

Why I needed this

For a presentation I did on prefers-reduced-data I wanted to apply something in one of two situations:

There was no support for prefers-reduced-data at all
There was support for prefers-reduced-data and the value was "no-preference".

For this, I couldn't use just @media (prefers-reduced-data: no-preference) because that would be false if either there was no support (since the browser wouldn't understand the media query) or if it was supported but the user wanted to preserve data.

What I needed was a test for the media feature regardless of it's value. To do that, we can use the or notation.

Detecting media query support in CSS

To detect if a media query is supported in CSS at all, you can use the following CSS:

@media not all and (prefers-reduced-data), (prefers-reduced-data) {
  ...
}

That looks like a bit of weird, so lets dissect what it actually says. Firstly, let's split the two media features and begin with the second one:

`(prefers-reduced-data)`

This one looks straightforward but there's something weird: the media feature is missing a value! usually, media features come with a value, like "min-width: 400px", but this one doesn't have a value.

That's because some media features have a "shorthand" when they only have two options and prefers-reduced-data does, it only has "no-preference" (off) and "reduce" (on). When you omit the value, it tests for it being on.

So here's how this will resolve:

no preference: false
reduce: true

But if the browser doesn't support a media feature, it will automatically change to "not all", which resolves to false, so we end with this:

no support: false
no preference: false
reduce: true

`not all and (prefers-reduced-data)`

The notable thing here is not all and. "all" is the default media type, and it applies to both screen and print. You can omit it (and likely you usually do), but if you add it you need to add "and" in between it and the media feature (which is the part between parentheses).

not is how you can negate a media query. For example, @media not print {...} would apply everywhere except print.

With all being the default, what we're really checking here for is "not (prefers-reduced-data)". Unfortunately that's invalid notation until supports for Media Queries level 4 lands, so we need to add the "all and" here.

Here's how this resolves:

no support: still false, since the browser doesn't understand it
support but off: true (its the negation of it being on)
support but on: false

Combined

So when the browser then recombined these values using the OR, meaning only one of them has to be true for the media declaration to be applied:

No support:

not all and (prefers-reduced-data): false
(prefers-reduced-data): false

Combined: false

Support, but off:

not all and (prefers-reduced-data): true
(prefers-reduced-data): false

Combined: true

Support, and on:

not all and (prefers-reduced-data): false
(prefers-reduced-data): true

Combined: true

Anything in the media query will now be applied if the feature is supported, regardless of what its value is.

Detecting media query support in JavaScript

We can use the same media query in JavaScript using the window.matchMedia API:

const isSupported = window.matchMedia(
  `not all and (prefers-reduced-data), (prefers-reduced-data)`
  ).matches;

window.matchMedia returns an object with a "matches" boolean property that is either true or false. For more on the API, check out the using media queries in JavaScript section of my guide on media queries.

After I shared the above out on Twitter, Mathias pointed out a different method.

const query = '(prefers-reduced-data)';
const resolvedMediaQuery = window.matchMedia(query).media;

const isSupported = query === resolvedMediaQuery;

The window.matchMedia api also returns a "media" property, which is the normalized and resolved string representation of the query you tested. If matchMedia encounters something it doesn't understand, that changed to "not all", and if it does support the query it will return that, regardless of if it matches (you can use the matches property for that).

So by comparing your input to the media, you either get:

No support:
'(prefers-reduced-data)' === 'not all' which is false.

Support:
'(prefers-reduced-data)' === '(prefers-reduced-data)' which is true.

Which one to use?

What I like about the first option, with the complex media query, is that all the logic happens inside CSS. I also like how you get a boolean, and don't have to do string comparison.

The second can be a little bit easier to understand at a glance, but you need to make sure that your query input is the same as the browser normalizes it.

For example, if you test (prefers-reduced-data ) (notice the space), that would resolve "matches" to true in supported browsers because the white space is not important, but comparing the normalized media query would return false, since that normalization has removed that extra space. So string comparison can be tricky depending on your input.

When to use this?

We're set to get a whole lot of new media features in the coming years, like prefers-reduced-data, prefers-contrast, screen-spanning and more.

While transitioning to all browsers supporting this, you'll often want to turn on extra features for browsers that support it without causing issues in older browsers since the new default might not always be the best experience in older browsers. With this media feature you can split the behavior in older browsers without support for newer browsers with support.

DEV Community: Kilian Valkhof

HTML Form Inspector: inspect and debug your forms online

Finding issues in forms

Introducing the HTML Form Inspector

How does it work?

Summary

Form configuration

Fields

Fieldsets

Buttons

Try it yourself!

Go even deeper with Polypane

[Boost]

Launching the first ever State of Devs survey

Black Friday 2024: Save 25% on Polypane

The Deal

Why Polypane Matters

Developer Productivity Impact

Grab the Deal

Polypane 20: Browser features and performance

Elements panel

Performance

@starting-style support

A11y panel updates

Warning for missing accessible names

Warning for repetition in the accessible name

Other Elements panel improvements

Outline panel

Performance improvements

Looking ahead: full accessibility tree view

Cap on automatic link testing

Accessible name vs visible name

Repetition in accessible names

Support for heading levels 7 through 9

Load failure messages

Screenshotting improvements

Dashed and dotted lines in the screenshot editor

Easy access to the storage folder

Overview screenshot distortion (fix)

Address bar

Chromium 126

Get Polypane 20

Polypane 20 Changelog

How to check your site in different languages and writing modes

Quick terms

Challenges

The basics

The lang attribute

The dir attribute

Testing different languages and writing modes

Changing the reading direction

Changing the language

Testing your layout

Emulating text length

Checking the line length

Conclusion

The gotchas of CSS Nesting

A related gotcha: :is()

Back to the original gotcha

:root isn't global

So if :root isn't global, what is?

A small JavaScript pattern I enjoy using

Partial string matching

The breakpoints we tested in 2021, and the ones to test in 2022

Based on device sizes

Based on popular CSS frameworks

Based on your visitor data

Create a Polypane workspace based on Google Analytics

The breakpoints we tested in 2021

From the Web Almanac

Min-width

Max-width

The most-used breakpoints in Polypane in 2021

The breakpoints to develop on in 2022

The EyeDropper API: Pick colors from anywhere on your screen

How to use the EyeDropper API

Detecting support for the EyeDropper API

await based version

Promise based version

Things to keep in mind when using the EyeDropper API

`@starting-style` support

The `lang` attribute

The `dir` attribute

A related gotcha: `:is()`

So if `:root` isn't global, what is?

`await` based version

`(prefers-reduced-data)`

`not all and (prefers-reduced-data)`