DEV Community: Polypane

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 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!)

Polypane 6.1: Readability, Content Chaos and rewritten event sync engine

Kilian Valkhof — Tue, 01 Jun 2021 15:09:09 +0000

Polypane 6.1 adds two new debug tools and a much more performant, completely rewritten interaction syncing engine along with numerous smaller improvements and bug fixes.

What's Polypane? Polypane is a web browser for developers, designers and anyone that works on web projects. It shows sites in multiple fully synced panes and has tons of features that help with responsive design, accessibility and overall site quality.

Readability debug tool

The readability debug tool will calculate how difficult each sentence on your page is. Darker, redder sentences are harder to understand while lighter, greener sentences are easier to read.

We calculate this using the Automated Readability Index (ARI), which works well for most western, European languages. For pages in Arabic it uses the Automatic Arabic Readability Index (AARI). If you know of other languages that have a Readability Index algorithm, please let us know!

This is a really neat way to check which of your sentences might be a little on the complex sites and should be rewritten.

Content chaos debug tool

The Content chaos debug tool will randomly halve, double or triple the content of each text node on your page. This is a perfect way to test if your layout wont break when there is unexpected text content (such as much longer titles for things than were used in the design, or languages that take significant more or less space).

Rewritten interaction event sync engine

Polypane is the only browser that syncs all your user interactions out of the box: scrolling, clicking, keyboard input, form events, typing and hovers. Making this feature performant is a difficult problem, since you need the same thing to happen at the same time across all panes.

In 6.1 we have completely rewritten our syncing engine (bringing it up to the third engine we've built for this). We were able to take out an intermediate component that improves performance a lot and at the same time is able to more accurately sync interaction events across panes.

In particular, you'll notice a higher frame rate for scrolling and animations on hover are much smoother across panes.

About Browsersync

Starting in Polypane 6.1, we will automatically disable the built-in syncing when we detect Browsersync with ghostMode turned on.

Browsersync has always been slightly slower than Polypane's internal syncing, and what was essentially happening was that Browsersync was continuously resetting the scroll position after Polypane had updated it, leading to a very janky experience.

Polypane has been showing a warning but unfortunately not many people are aware of the option to turn off ghostMode, or even realise they have Browsersync running in their project in the first place. That's why we decided it was better to instead disable the scroll syncing in Polypane, even though it is more performant.

Images overview in outline panel

The online panel now gives you a list of all the images on a page along with their current source, alt text, title, shown dimensions, aspect ratio and actual dimensions when they differ from the shown dimensions.

When the alt text is missing we'll show a warning, and you can right-click any image to save it to disk.

Like the node tooltip, we'll only show the actual size when it differs from the shown dimensions, and we only show the aspect ratio if it's not the same as the pixel value.

Smaller improvements

Polypane inlines stylesheets to enable access to them from the elements panel. We've made this optional which can be
slightly faster, at the expense of not showing all the styles in the elements panel. Starting in 6.1 we also rewrite
inlined stylesheet so that linked resources (like background images) work correctly.

Polypane now includes the Angular DevTools in the selection of devtools extensions.

We updated our color handling throughout the application making it much more performant. This is most noticable when editing a color
in the Elements panel.

It's now no longer possible to navigate to a Facebook, Twitter or Instagram URL in Polypane. We did this ~~as a productivity measure~~
because these sites have server security settings that make Electron applications (of which Polypane is one) crash. We could
disable the security settings for these sites but we would rather wait for Electron to be fixed, so we're keeping a close eye on that.

Logging in with Google was broken in Polypane 6 but it now works again.

Read through the full changelog to see the other improvements made.

Get Polypane 6.1

Polypane will automatically update on Mac and Windows. Linux users need to download the new version from
the download page and if you're on Mac and Windows but don't want to wait on the update popup, find
your download there as well.

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

Full Changelog

New features

New Readability debug tool
New Content chaos testing debug tool (Thanks Rik!)
New Interaction syncing engine rewritten to v3
New Images overview in outline panel
New Option to disable inlining stylesheets
New Angular DevTools now available in the devtools extensions installer

Improvements

Improved Pane load performance improvements
Improved Remove jank when animating hover styles
Improved Clicks are not synced when they create a new tab (when cmd or ctrl is pressed)
Improved Support shorthand notation in combination with custom properties for hover syncing
Improved Prevent Polypane from opening urls that are known to cause crashes
Improved Inlined stylesheets no longer overwrite background images
Improved Increase opacity for unfocused scrollbar (Thanks Sam!)
Improved Form elements now use the Polypane accent color
Improved Improve performance of color picker in elements panel
Improved Upgrade Chromium version
Improved Better color consistency for dark mode
Improved Outline Link checking now ignores javascript, blob and data links
Improved Polypane shows a warning when a site wants Location API access but there is no Google API key (Thanks Eric!)
Improved Mode switcher shortcut is changed so cmd + m for minimize works (Thanks Charlie!)
Improved Scroll syncing is now disabled when Browsersync with ghostMode is detected

** Fixes **

Fix Log in with Google works again
Fix Fix auto reloading not starting immediately
Fix CSS injection in Live reload for Default mode (Thanks Winston!)
Fix Disabling hover sync also blocked showing the target url on hover
Fix Copy button for empty description was missing (Thanks Charlie!)
Fix Alignment issues in the Outline panel on Mac
Fix Editing text nodes in elements panel sometimes didn't work
Fix Prevent tooltip overlay misalignment on some sites
Fix Prevent duplicate inlining of stylesheets
Fix Polypane console can now print 'null' messages
Fix Escape HTML in attributes in overlay tooltip
Fix Missing rel="noopener" warning was sometimes shown incorrectly
Fix Replace panes button for custom workspaces now replaces panes again (Thanks Sam!)
Fix Elements panel not always showing background image declarations
Fix Show correct version number in getting started page

Debug your visual hierarchy with the squint test

Kilian Valkhof — Fri, 11 Dec 2020 12:11:57 +0000

"The squint test" is a method to get a feel for the visual hierarchy of your page and the name is quite literally what you're supposed to do.

When you squint your eyes and move away from your screen a little you distort your vision to the point where you can no longer focus on the page but can still make out the large areas and colors in your design.

In other words, you only see the visual hierarchy.

When you're designing or building a website, it can be easy to focus in on the details. Is everything precisely aligned to the grid? Are you using the exact right font-size and colors? Is this the right border-radius? But when you focus on the details, the major hierarchy of your website can get away from you.

The squint test is a quick way to check if your page is still on the right track because it hides those details and lets you focus on the larger patterns in your page.

What to look for when doing the squint test 🕵️‍♀️

When you do the squint test there's a few question you're trying to answer:

Is the primary focus of the page clear?
Most pages have one primary focus. One thing they want users to do or one topic. When squinting, is the primary call to action or primary point of focus still recognizable, and is it clear what the primary focus is?

Are relationships between elements clear?
Most visual elements have some sort of relationship with others, like titles and text below it, or the header and the logo. When you squint, is it still clear that they belong together, or is the spacing causing elements to look separate?

Which elements stand out? (and should they stand out?)
Elements with tons of contrast or color stand out more than others. When you squint these elements gain more prominence compared to when you see them with "noisy" text around it. Are these elements the one you want to have stand out?

Another important step for this question is to distinguish between foreground elements and background elements. Are background element like dividers and backgrounds more prominent than the primary focus of the page?

Is the page still recognizable?
Can you still find the logo, are the colors used recognizable as your brand and consistent with the rest of your site?

If an element is interactive, is that still clear when squinting?
You don't want people to have to hunt for buttons and other interactive elements. When squinting, can you still detect whether a link is clickable? If you're just using an underline that might get lost when blurring, but if you also have a different color then it's
still clear.

Are elements that look the same when squint actually related?
A common usability concept is "things that look the same are the same". And when they're not that leads to confusion. Are the elements on the page that look the same, also similar in behavior? If not, you might want to make sure they look
different too.

The squint test ...without squinting 👀

If you keep squinting while checking your design for all those points you'll end up with quite a headache.

Polypane has two debug tools that can help you do the same tests, no squinting required.

Far-sightedness emulation

The Far-sightedness emulation blurs the page you're looking at to emulate what people with farsightedness see.

When you squint your eyes you also can't bring the page in focus making this an ideal substitute for the squint test without needing to physically squint.

Turn on the emulation and scroll through your site, taking note of the questions above and seeing where improvements can be made.

Placeholdifier debug tool

But even a blurred page can give you physical discomfort when looking at it for too long, since your eyes will keep trying to get the page into focus.

With the Placeholdifier debug tool every element stays sharp but text and images become solid blocks of color. With this you take away the focus on the actual words and imagery and are left with the general layout and hierarchy.

Run them side by side

With Polypane, you can also show these two debug tools side by side. Because each highlights some issue more than the other, checking a page in both at the same time lets you see the entire overview in one go.

Try it yourself 🤩

Test out these debug tools, and over 25 others (like color blindness simulators, dyslexia emulation and layout debugging) in Polypane by starting a free 14 day trial. Polypane is available on Mac, Windows and Linux.

CSS breakpoints used by popular CSS frameworks

Kilian Valkhof — Thu, 06 Aug 2020 13:36:44 +0000

When using a CSS framework it often doesn't matter what devices people use. These frameworks come with their own set of CSS breakpoints with components that work well with those breakpoints.

Even though it's usually best to choose your own breakpoints based on your own content (one of our ground rules for responsive design) using the framework-provided ones can be a real time saver.

Breakpoints for each CSS Framework

A huge time saver when building websites with these frameworks are Polypane's workspace presets. Workspaces give you a pre-built set of panes and settings so you get a flying start when working on a site.

Workspace presets are built-in for Bootstrap, Bulma, Material UI and Tailwind CSS. You can find downloads for the others that you can import directly in Polypane.

Which breakpoints are used by each CSS framework? Find the lists below.

Bootstrap v4
Bootstrap v5
Bulma
Foundation
Ionic
Material UI
Materialize
Semantic UI
Skeleton
Tailwind CSS
UIKit

Bootstrap v4

Name	Description	Minimum width
xs	Extra small devices (portrait phones)	none
sm	Small devices (landscape phones)	576px
md	Medium devices (tablet)	768px
lg	Large devices (desktops)	992px
xl	Extra large devices (large desktops)	1200px

Built into Polypane. Find more information in the Bootstrap documentation

Bootstrap v5

Name	Description	Minimum width
--	X-Small	none
sm	Small	576px
md	Medium	768px
lg	Large	992px
xl	Extra large	1200px
xxl	Extra extra large	1400px

Download workspace file for Bootstrap v5. Find more information in the Bootstrap v5 documentation

Bulma

Name	Minimum width
mobile	none
tablet	769px
desktop	1024px
widescreen	1216px
fullhd	1408px

Built into Polypane. Find more information in the Bulma documentation

Foundation

Name	Minimum width
Small	none
Medium	640px
Large	1024px
Xlarge (optional)	1200px
Xxlarge (optional)	1440px

Download workspace file for Foundation. Find more information in the Foundation documentation

Ionic

Name	Minimum width
xs	none
sm	576px
md	768px
lg	992px
xl	1200px

Download workspace file for Ionic. Find more information in the Ionic documentation

Material UI

Name	Minimum width
xs	none
sm	600px
md	960px
lg	1280px
xl	1920px

Built into Polypane Find more information in the Material UI documentation

Materialize

Name	Minimum width
s	none
m	600px
l	992px
xl	1200px

Download workspace file for Materialize. Find more information in the Materialize documentation

Semantic UI

Name	Minimum width
mobile	none
tablet	768px
small monitor	992px
large monitor	1200px

Download workspace file for Semantic UI. Find more information in the Semantic UI documentation

Skeleton

Name	Minimum width
Mobile	440px
Phablet	550px
Tablet	750px
Desktop	1000px
Desktop HD	1200px

Download workspace file for Skeleton. Find more information in the Skeleton documentation

Tailwind CSS

Name	Minimum width
sm	640px
md	768px
lg	1024px
xl	1280px

Built into Polypane. Find more information in the Tailwind CSS documentation

UIKit

Name	Minimum width
s	640px
m	960px
l	1200px
xl	1600px

Download workspace file for UIKit. Find more information in the UIKit documentation

Increasing your productivity as a web developer

Using a CSS framework is one of the 8 ways to increase your productivity as a web developer. Check out the other 7 ways to improve your productivity!

Ground rules for responsive design

Though CSS frameworks help you with a lot of choices, building a solid responsive design still requires you to pay attention to other parts of your page and design. Read about the ground rules for responsive design to created solid responsive websites.

Missing a CSS framework?

Are we missing your favorite CSS framework? Comment and we'll add it to the list!

The complete guide to CSS media queries

Kilian Valkhof — Wed, 22 Jul 2020 13:41:35 +0000

Did you know there is a media query for inverted colors? Or one for saving data?

Media queries are what make modern responsive design possible.

With them you can set different styling based on things like a users screen size, device capabilities or user preferences.

But how do they work, which ones are there and which ones should you use?

I set out to write the ultimate guide to media queries, going over every little detail, like which media types there are, all the media queries you should use now, you will use in the future and the ones you should no longer use.

Here's the complete guide to CSS media queries

It's as much a reference as an opinionated description of how to best use them. It also has many clever tips, like this cheap dark mode that will get you a good looking site in just a few lines of code:

@media (prefers-color-scheme: dark) {
  :root {
    background: #111;
    filter: invert(1) hue-rotate(180deg);
  }

  img,
  video {
    filter: invert(1) hue-rotate(180deg);
  }
}

If you wanna understand how it works, head on over to the complete guide to CSS media queries

Creating files in JavaScript in your browser

Kilian Valkhof — Thu, 28 May 2020 08:59:35 +0000

Did you know you can create files using JavaScript right inside your browser and have users download them? You can create files with a proper name and mime type and it only takes a few lines of code.

For the new Create workspace feature in Polypane, which lets you create a Polypane workspace with panes from the most used browser sizes from your Google Analytics data, I needed an easy way to create a “.ppws” file that Polypane knows how to read an import.

I already knew it was possible, I just didn’t know how little work it turned out to be.

Here’s how it works: first you get your data ready. Your data can be either binary or text. In my case it was json structure, but you can also get image data from the canvas, for example.

Then when you have this data, you store it in a Blob, the “file-like object” that JavaScript supports. Blobs have been supported since IE10, so you can use them without any transpilation.

const workspace = { ... } // some object

const file = new Blob(
  [JSON.stringify(workspace)], 
  { type: 'application/json' }
);

A blob takes your data in the form of an array or array-like object (like an arraybuffer or another blob). In my case, it only has the text string of my json structure so that was pretty simple. The second argument are options and it’s where you set the type. There’s type, which you use to specify the mime type of your file.

After you’ve done this, the Blob exists but it’s not yet ready for downloading. For that we need to create an Object URL:

const fileURL = URL.createObjectURL(file);

This creates an actual link that we can use to link to our created blob, it starts with blob:. Now we have a file URL that refers to our blob, but you’ll notice it doesn’t actually have a name yet. For that we actually need a little bit of DOM/HTML.

The a element has an attribute called “download”. If it’s present without value, it means that the URL should download when a user clicks on it. But we can also give it a value, and that value will be used as a suggestion for the file name.

Because we created our file in JavaScript, we’ll also create the link in JavaScript, then add it to the page:

// create the link 
const linkElement = document.createElement("a");

// add the file url
linkElement.setAttribute('href', fileURL);

// add the download attribute with name suggestion
linkElement.setAttribute('download', 'polypane-workspace.ppws')

// add it to the DOM
document.body.appendChild(linkElement);

You'd add it to a specific element of course, not just at the end of the document, but this is just for illustration.

And there you have it, In just a few lines of code you’ve created a file and given it mime type and file name. If you want to try it out, create a Polypane workspace here.

For many, accessibility is an unknown unknown

Kilian Valkhof — Tue, 19 May 2020 12:31:01 +0000

An unknown unknown is something you don’t know you don’t know. When you’re just starting out with web development there are many unknown unknowns. You don’t know enough about what’s possible to know what the right way to do things is. Accessibility is one of them.

This image recently got shared on Twitter:

(source: https://webaim.org/projects/million/#frameworks)_

The general consensus was “React and Vue developers should do better!” and while I don’t disagree, I don’t think that’s the story this table tells.

I don’t think the accessibility spectrum maps to which framework you use in any meaningful way (Or, to put it more eloquently: React didn’t use a <button>, you did.)

I think it maps much more significantly to your experience level as a web developer in general.

So we’ll move away from frameworks for the rest of this article but let me add one remark: I don’t think it’s unreasonable to say that frameworks that make it easy for people to get started, will attract people that are just getting started.

The starting developer experience

When you start out it’s you, notepad and a browser against the world. You open up that notepad, and you type

<div onclick="alert('hello world');">Click me!</div>

You fire up your browser, you click your div and …it works! It just works! Awesome. You open up the devtools. No errors. Well done! Clearly you did a good job. On to the next thing.

And that’s a problem. For all sorts of reasons, both legitimate and, as always, weird browser legacy reasons, a clickable div will mostly work. Well enough to fool someone starting out anyway.

If everything works, how would they know it kinda doesn’t? We know there are issues because of experience. You can only make so many clickable divs before someone tells you, or you read somewhere, that you should use a button instead.

Waiting for that to happen is probably not the most optimal strategy to improve the knowledge of accessibility among web developers.

What are browsers doing?

Why aren’t browsers telling that new developer opening the devtools “Instead of using a div, maybe you want to use a button. Here’s a handy link explaining why”?

I don’t mean in Webhint or the accessibility panel or some other web extension. Remember, they don’t know they don’t know, so they definitely will not search for it.

If we want people to get serious about accessibility, we need to push it on to them in the places they’ll look. Not three tabs down or behind a configuration button or when you hover over an element for longer than 3 seconds. It needs to be right there when they open devtools.

Obviously, this is something I’m working on with Polypane.

Furthermore we could envision a browser that is much stricter when developing. Modern browsers need to accurately render pages that are over 2 decades old and that comes with a lot of caveats.

But what if they don’t?

What if you can configure your browser to warn about or even block anything that’s not compliant with modern standards, accessibility standards included? Here’s some of the things they could do: (I’ve tweeted about this before)

Color contrast doesn’t meet the minimum? Your browser increases it automatically until it does.
Focus styles? You can style them, but if you turn them off or style them in such a way that they don’t contrast enough with the regular style, then your browser will compensate for that or ignore your styling.
Images won’t show if they don’t have an alt attribute.
onClick handlers now no longer work on all elements, but the elements that they do work on will need to be vastly improved, at least to the point where they have equivalent functionality compared to native buttons (things like buttons-in-buttons, buttons with secondary option etc).

Then there’s also the issue that new developers might be writing HTML the right way, using the elements in the way they’re intended to be used and, surprise! Their site is still inaccessible because the browser implementation of those elements is inaccessible. If browsers don’t even implements the HTML standard in an accessible way, then how can you expect a single web developer to magically get it right?

Are our accessibility efforts effective?

I think the biggest issue with accessibility is that, while the knowledge is out there, it’s very difficult to find the right information, and practically impossible if you don’t know you’re looking for that information.

So we need better ways to reach developers. We need to reach them where they are, and in a way that makes it actionable to them. I think that place is in the browser. The browser is the only non-optional part in a developers technology stack.

Accessibility is, for all intents and purposes, duct-taped onto the web. We need to make it a first class citizen in browsers. Until we do, we’ll keep wondering why developers aren’t making accessible websites.

Oh, and we also need to stop telling people that divs can be used as buttons*. Good job there, WAI-ARIA.

This uses the chrome link-to-text feature. If you use another browser, go to the role description property and scroll down to example 27.