DEV Community: Google Web Dev

What’s new in Web Payments

Eiji Kitamura — Fri, 07 Aug 2020 05:42:12 +0000

It’s been a while since my previous post, but Web Payments team at Google including myself have been commited to work on improving it. Some may wonder what’s giong on with it, so let me share my talk at an online event called “web.dev LIVE” which Google’s Web DevRel team organized early July 2020.

It’s a short video, but it contains:

Recap of Web Payments
How it works
Status update
Upcoming features

Most importantly, we’ve published a set of documentation that explains how to build a native and a web-based payment app in detail.

web.dev

Integrate Web Payments into your payment app

Build a native payment app

Build a web-based payment app

…And more articles are coming!

If you are interested in building a Web Payments compatible payment app, let me know.

Announcing web.dev LIVE: A three day digital event

Michael Solati — Wed, 27 May 2020 03:18:35 +0000

Two weeks ago we, at Google, would have hosted our annual developer conference, Google I/O. Out of concern for the health and safety of all participants, and in compliance with local "shelter in place" orders, we decided to not host I/O in any capacity.

To bring together the web community in this unprecedented time, Google's Web Platform team is putting together a 3-day digital event. Watch our 10-20 minute sessions for 3 hours every day, where we'll host talks about modern web development and answer your questions!

From the comfort of your own home join other web developers to, "celebrate our community's actions, learn modern web techniques and connect with each other."

Watch live on:

June 30th, 9am - 12pm PDT (For developers in the Americas)
July 1st, 12pm - 3pm GMT (For developers in Europe & Africa)
July 2nd, 1pm - 4pm IST (For developers in Asia & Australia)

Be sure to sign up and get more information at web.dev/live!

Performance auditing an eCommerce site

Jeff Posnick — Mon, 06 Apr 2020 15:00:00 +0000

Alan's weekly eCommerce livestreams

My teammate Alan's been running a weekly livestream on his YouTube channel, focusing on topics of interest to eCommerce websites. He asked me to come on this week and perform a site performance audit.

Since I'm currently homebound due to Coronavirus concerns in NYC, I haven't had the chance to perform any in-person site audits in a while. Going through the process via a livestream was a great opportunity!

The site review

The review process took about 50 minutes (I'd recommend watching at 2x playback speed...) and covered some relevant findings from WebPageTest.org and Lighthouse.

We choose the site, https://threddies.com/, "at random" based on folks who volunteered. I think it ended up being fairly representative of the types of issues a lot of sites encounter.

Lightly edited from the notes I took during the review.

Tools used:

Observations

11 seconds for main content to load — what's loaded beforehand?
How many of the widgets/analytics tools can be lazily-loaded (or potentially removed, if appropriate)?
HTTP cache expiration best practices.
Use the Coverage panel in Chrome Dev Tools to evaluate how much of your JS/CSS in the critical request path is being used
Q: Can they get away with loading Google Maps static images instead of Google Maps widget? Answer: yes, they can.
Always click on the "Learn More" link in Lighthouse for additional context!
Zach Leatherman's guides to loading web fonts are great.

YEStifications: Exploring how users engage with notification prompts in the Chrome UX Report

Rick Viscomi — Tue, 11 Feb 2020 23:02:58 +0000

📢 example.com wants to show notifications

Notifications can be an effective way to keep users engaged, but many websites are unable to get users past the permission prompt. A common problem is prompting out of context, as soon as the page loads or without an explanation of how they will be used. So how do users tend to engage with these permission prompts? CrUX to the rescue.

The Chrome UX Report (CrUX) now includes data from 30,000 websites on users' engagement with notification prompts. The data is made available in a public BigQuery repository, which we'll explore in this post to see how users engage with prompts across the web. Let's dive in!

The state of notification permissions

For starters, let's get a feel for the number of websites we're working with in this dataset.

SELECT
  COUNT(DISTINCT origin)
FROM
  `chrome-ux-report.all.202001`
WHERE
  experimental.permission.notifications IS NOT NULL

The results show that there are 31,515 origins with permission data. An origin is the top-level address of a website, everything before the first "/" of the path, like https://www.example.com. User experience data from pages on the same website are all rolled up at the origin level.

Now let's look at the permission data for a single website, for example Slack.

SELECT
  SUM(experimental.permission.notifications.accept) AS accept,
  SUM(experimental.permission.notifications.dismiss) AS dismiss,
  SUM(experimental.permission.notifications.deny) AS deny,
  SUM(experimental.permission.notifications.ignore) AS `ignore`
FROM
  `chrome-ux-report.all.202001`
WHERE
  origin = 'https://app.slack.com'

Accept	Dismiss	Deny	Ignore
92.10%	5.67%	1.96%	0.28%

As you can see, the Slack app has a very good permission acceptance rate for their notification prompts at 92%. In other words, 92% of users who get the prompt end up granting Slack permission to show them notifications. About 6% of users close the prompt without explicitly deciding one way or the other, 2% of users explicitly disallow Slack from showing them notifications, and ~0% of users leave the prompt entirely untouched.

But how representative is Slack of the experience across the web? Let's zoom out and see how all 30,000 websites stack up.

SELECT
  origin,
  SUM(experimental.permission.notifications.accept) AS accept,
  SUM(experimental.permission.notifications.dismiss) AS dismiss,
  SUM(experimental.permission.notifications.deny) AS deny,
  SUM(experimental.permission.notifications.ignore) AS `ignore`
FROM
  `chrome-ux-report.all.202001`
WHERE
  experimental.permission.notifications IS NOT NULL
GROUP BY
  origin
ORDER BY
  `ignore` ASC,
  accept DESC

What are we looking at here? The curved gray area on the top right of the chart shows the distribution of ignores across all websites with permission data. Next, the red area taking up the most space in the middle of the chart represents the proportion of user engagements that reject the permission prompt. The green area that curves down from the left edge of the chart represents the proportion of user engagements that accept the prompt. And the remaining yellow area between accept and deny is the dismissal rate.

We can draw a couple of insights from this visualization:

Most glaringly, there's a lot of red and not a lot of green in this chart. Users are highly likely to be denying notification permission prompts rather than accepting them. Slack is an extreme example of an outlier website with a high acceptance rate.
There seems to be an inverse correlation between deny and ignore rates. As sites have smaller deny rates, their ignore rates increase. We could interpret the lack of prompt interaction as an implicit rejection of permission.

So if Slack is such an outlier, what does a typical website look like?

SELECT
  AVG(accept / total) AS accept,
  AVG(dismiss / total) AS dismiss,
  AVG(deny / total) AS deny,
  AVG(`ignore` / total) AS `ignore`
FROM (
  SELECT
    SUM(experimental.permission.notifications.accept) AS accept,
    SUM(experimental.permission.notifications.deny) AS deny,
    SUM(experimental.permission.notifications.ignore) AS `ignore`,
    SUM(experimental.permission.notifications.dismiss) AS dismiss,
    SUM(experimental.permission.notifications.accept +
        experimental.permission.notifications.deny +
        experimental.permission.notifications.ignore +
        experimental.permission.notifications.dismiss) AS total
  FROM
    `chrome-ux-report.all.202001`
  WHERE
    experimental.permission.notifications IS NOT NULL)

Accept	Dismiss	Deny	Ignore
16.71%	23.84%	40.74%	18.71%

This is a more realistic view of the state of notification permissions. Keep in mind that we're averaging the UX for many websites together, even if they have drastically different numbers of users. So this is showing us that the average website has a notification prompt acceptance rate of 17%, 24% dismissal, 41% rejection, and 19% ignore.

What else can we learn about user behavior from this dataset? We could also slice this average distribution by users' device form factor.

SELECT
  device,
  AVG(accept / total) AS accept,
  AVG(dismiss / total) AS dismiss,
  AVG(deny / total) AS deny,
  AVG(`ignore` / total) AS `ignore`
FROM (
  SELECT
    form_factor.name AS device,
    SUM(experimental.permission.notifications.accept) AS accept,
    SUM(experimental.permission.notifications.deny) AS deny,
    SUM(experimental.permission.notifications.ignore) AS `ignore`,
    SUM(experimental.permission.notifications.dismiss) AS dismiss,
    SUM(experimental.permission.notifications.accept +
        experimental.permission.notifications.deny +
        experimental.permission.notifications.ignore +
        experimental.permission.notifications.dismiss) AS total
  FROM
    `chrome-ux-report.all.202001`
  WHERE
    experimental.permission.notifications IS NOT NULL
  GROUP BY
    device)
GROUP BY
  device
ORDER BY
  accept DESC

Device	Accept	Dismiss	Deny	Ignore
phone	22.76%	18.03%	57.33%	1.88%
tablet	18.75%	20.24%	58.34%	2.67%
desktop	6.11%	34.01%	11.61%	48.27%

Ok this is significant. There is a huge difference in engagement between phones and desktops. Phone users are very unlikely to ignore the prompt, whereas desktop users ignore the prompt about half the time on average. The simplest explanation is screen size; it's a lot harder to ignore a prompt when it's taking up a larger portion of your screen. Interestingly, despite the 57% rejection rate, phone users are the most likely to accept permission prompts, at 23%, compared to just 6% on desktop. One explanation may be that a phone is a much more natural and convenient form factor on which to receive notifications because it goes where you go.

Where we go from here

Users have been feeling the frustration of intrusive notification prompts and developers have only anecdotally heard about and experienced this frustration. Now we have actionable data to shed light on the quality of experience across the web. And it's clear from the CrUX data that relatively few websites are effectively enrolling users in notifications.

The Chrome team has announced that it is rolling out changes to how prompts are shown to users to minimize frustration, saying "sites with very low acceptance rates will be automatically enrolled in quieter prompts". So it's especially important for site owners to be aware of their prompt performance.

If your site requests permission to show notifications, add instrumentation so you can monitor the response rates. The CrUX dataset is not a substitute for your own UX monitoring, but it can be helpful for filling in gaps, seeing how similar websites are performing, and tracking the trends across the web. Read up on best practices for requesting permission to improve your response rates and get more yestifications than notifications. 🥁

The queries shown in this post can be run on BigQuery. You're strongly encouraged to remix the queries to discover your own insights. Read more about using CrUX on BigQuery to get started. If you have any questions or feedback about the data, the CrUX team would love to hear from you on any of these channels:

chrome-ux-report on Google Groups
@ChromeUXReport on Twitter
questions tagged with chrome-ux-report on StackOverflow
GoogleChrome/CrUX on GitHub

Fixing layout instability

Rick Viscomi — Wed, 18 Sep 2019 21:32:50 +0000

In an earlier post I wrote about measuring Cumulative Layout Shift (CLS) in WebPageTest. CLS is an aggregation of all layout shifts, so in this post I thought it'd be interesting to dive deeper and inspect each individual layout shift on a page to try to understand what could be causing the instability and actually try to fix the issue(s).

Measuring layout shifts

Using the Layout Instability API, we can get a list of all layout shift events on a page:

new Promise(resolve => {
  new PerformanceObserver(list => {
    resolve(list.getEntries().filter(entry => !entry.hadRecentInput));
  }).observe({type: "layout-shift", buffered: true});
}).then(console.log);

This produces an array of layout shifts that are not preceded by input events:

[
  {
    "name": "",
    "entryType": "layout-shift",
    "startTime": 210.78500000294298,
    "duration": 0,
    "value": 0.0001045969445437389,
    "hadRecentInput": false,
    "lastInputTime": 0
  }
]

In this example there was a single very tiny shift of 0.01% at 210ms.

Knowing the time and severity of the shift is useful to help narrow down what could have caused the shift. Let's turn back to WebPageTest for a lab environment to do more testing.

Measuring layout shifts in WebPageTest

Similar to measuring CLS in WebPageTest, measuring individual layout shifts will require a custom metric. Fortunately, the process is easier now that Chrome 77 is stable. The Layout Instability API is enabled by default, so you should be able to execute that JS snippet on any website within Chrome 77 and get results immediately. In WebPageTest, you can use the default Chrome browser and not have to worry about command line flags or using Canary.

So let's modify that script to produce a custom metric for WebPageTest:

[LayoutShifts]
return new Promise(resolve => {
  new PerformanceObserver(list => {
    resolve(JSON.stringify(list.getEntries().filter(entry => !entry.hadRecentInput)));
  }).observe({type: "layout-shift", buffered: true});
});

The promise in this script resolves to a JSON representation of the array rather than the array itself. This is because custom metrics can only produce primitive data types like strings or numbers.

The website I'll use for the test is ismyhostfastyet.com, a site I built to compare real world loading performance of web hosts.

Identifying causes of layout instability

In the results we can see the LayoutShifts custom metric has this value:

[
  {
    "name": "",
    "entryType": "layout-shift",
    "startTime": 3087.2349999990547,
    "duration": 0,
    "value": 0.3422101449275362,
    "hadRecentInput": false,
    "lastInputTime": 0
  }
]

To summarize, there is a single layout shift of 34.2% happening at 3087ms. To help identify the culprit, let's use WebPageTest's filmstrip view.

Scrolling to the ~3 second mark in the filmstrip shows us exactly what the cause of the 34% layout shift is: the colorful table. The way the website is built is to asynchronously fetch a JSON file, then render it to a table. The table is initially empty, so waiting to fill it up when the results are loaded is causing the shift.

But that's not all. When the page is visually complete at ~4.3 seconds, we can see that the <h1> of the page "Is my host fast yet?" appears out of nowhere. This happens because the site uses a web font and hasn't taken any steps to optimize rendering. The layout doesn't actually appear to shift when this happens, but it's still a poor user experience to have to wait so long to read the title.

Fixing layout instability

Now that we know the asynchronously generated table is causing one third of the viewport to shift, it's time to fix it. We don't know the contents of the table until the JSON results are actually loaded, but we can still populate the table with some kind of placeholder data so that the layout itself is relatively stable when the DOM is rendered.

Here's the code to generate placeholder data:

function getRandomFiller(maxLength) {
  var filler = '█';
  var len = Math.ceil(Math.random() * maxLength);
  return new Array(len).fill(filler).join('');
}

function getRandomDistribution() {
  var fast = Math.random();
  var avg = (1 - fast) * Math.random();
  var slow = 1 - (fast + avg);
  return [fast, avg, slow];
}

// Temporary placeholder data.
window.data = [];
for (var i = 0; i < 36; i++) {
  var [fast, avg, slow] = getRandomDistribution();
  window.data.push({
    platform: getRandomFiller(10),
    client: getRandomFiller(5),
    n: getRandomFiller(1),
    fast,
    avg,
    slow
  });
}
updateResultsTable(sortResults(window.data, 'fast'));

The placeholder data is generated randomly before being sorted. It includes the "█" character repeated a random number of times to create visual placeholders for the text and a randomly generated distribution of the three main values. I also added some styles to desaturate all color from the table to make it clear that the data is not fully loaded yet.

The appearance of the placeholders you use don't matter for layout stability as much as they are for assuring users that content is coming and the page isn't broken.

Here's what the placeholders look like while the JSON data is loading:

Addressing the web font issue is much simpler. Because the site is using Google Fonts, we just need to pass in the display=swap property in the CSS request. That's all. The Fonts API will add the display: swap style in the font declaration, enabling the browser to render text in a fallback font immediately. Here's the corresponding markup with the fix included:

<link href="https://fonts.googleapis.com/css?family=Chivo:900&display=swap" rel="stylesheet">

Verifying the optimizations

After rerunning the page through WebPageTest, we can generate a before and after comparison to visualize the difference and measure the new degree of layout instability:

[
  {
    "name": "",
    "entryType": "layout-shift",
    "startTime": 3070.9349999997357,
    "duration": 0,
    "value": 0.000050272187989256116,
    "hadRecentInput": false,
    "lastInputTime": 0
  }
]

According to the custom metric, there is still a layout shift occurring at 3071ms (about the same time as before) but the severity of the shift is much smaller: 0.005%. I can live with this.

It's also clear from the filmstrip that the <h1> font is immediately falling back to a system font, enabling users to read it sooner.

Conclusion

Complex websites will probably experience many more layout shifts than in this example, but the remediation process is still the same: add layout instability metrics to WebPageTest, cross reference the results with the visual loading filmstrip to identify the culprits, and implement a fix using placeholders to reserve the screen real estate.

(One more thing)

It's nice to be able to run WebPageTest on a page before and after an optimization and see an improvement to a metric, but what really matters is that the user experience is actually getting better. Isn't that why we're trying to make the site better in the first place?

So what would be great is if we start measuring the layout instability experiences of real users along with our traditional web performance metrics. This is a crucial piece of the optimization feedback loop because having data from the field tells us where the problems are and whether our fixes made a positive difference.

In addition to collecting your own layout instability data, check out the Chrome UX Report, which includes Cumulative Layout Shift data from real user experiences on millions of websites. It allows you to find out how you (or your competitors) are performing, or you can use it to explore the state of layout instability across the web.

[Video] The State of the Web: Developing with a global mindset

Rick Viscomi — Sat, 07 Sep 2019 18:55:14 +0000

To many web developers, having a global mindset just means translating the content into various languages. There are also cultural differences that may make a website difficult or even impossible to use. In this video with Andrey Sitnik, he and I talk about some of the tools and techniques for inclusivity.

Some highlights:

Users' names can be anything and might not fit the template of your sign up form. Rather than forcing a first and last name, allow them to enter their name into a single "Name" field. And whatever you do, don't enforce minimum character limits!
The browsers you support and test with can have a big effect on who is able to use your website. There are pockets of the world where some browsers are more popular than others and the distribution of popularity is not evenly spread.
Having fast and reliable access to the internet can be a luxury in some parts of the world. Even in developed countries, connectivity can be intermittent, so building offline resilience lowers the barrier to use.
Expand your global mindset by busting out of your tech bubble. If you have the means, attend conferences in parts of the world where you wouldn't normally go. Something everyone can do is simply follow underrepresented people on social media to be exposed to new and different ideas. When you reshare other people's content, think twice about creating an echo chamber and instead consider amplifying underrepresented voices.

What other takeaways resonated with you?

Hello darkness, my old friend

Thomas Steiner — Mon, 05 Aug 2019 14:12:46 +0000

Overhyped or necessity? Learn everything about dark mode and how to support it to the benefit of your users!

(Originally published on https://web.dev/prefers-color-scheme/.)

Introduction

📚 I have done a lot of background research on the history and theory of dark mode, if you are only interested in working with dark mode, feel free to skip the introduction.

Dark mode before Dark Mode

Green screen (Source)

We have gone full circle with dark mode. In the dawn of personal computing, dark mode wasn’t a matter of choice, but a matter of fact: Monochrome CRT computer monitors worked by firing electron beams on a phosphorescent screen and the phosphor used in early CRTs was green. Because text was displayed in green and the rest of the screen was black, these models were often referred to as green screens.

Dark-on-white (Source)

The subsequently introduced Color CRTs displayed multiple colors through the use of red, green, and blue phosphors. They created white by activating all three phosphors simultaneously. With the advent of more sophisticated WYSIWYG desktop publishing, the idea of making the virtual document resemble a physical sheet of paper became popular.

The WorldWideWeb browser (Source)

This is where dark-on-white as a design trend started, and this trend was carried over to the early document-based web. The first ever browser, WorldWideWeb (remember, CSS wasn’t even invented yet), displayed webpages this way. Fun fact: the second ever browser, Line Mode Browser — a terminal-based browser — was green on dark. These days, web pages and web apps are typically designed with dark text on a light background, a baseline assumption that is also hard-coded in user agent stylesheets, including Chrome’s.

Smartphone used in bed (Source)

The days of CRTs are long over. Content consumption and creation has shifted to mobile devices that use backlit LCD or energy-saving AMOLED screens. Smaller and more transportable computers, tablets, and smartphones led to new usage patterns. Leisure tasks like web browsing, coding for fun, and high-end gaming frequently happen after-hours in dim environments. People even enjoy their devices in their beds at night-time. The more people use their devices in the dark, the more the idea of going back to the roots of light-on-dark becomes popular.

Why dark mode

Dark mode for aesthetic reasons

When people get asked why they like or want dark mode, the most popular response is that “it’s easier on the eyes,”_followed by _“it’s elegant and beautiful.” Apple in their Dark Mode developer documentation explicitly writes: “The choice of whether to enable a light or dark appearance is an aesthetic one for most users, and might not relate to ambient lighting conditions.”

👩‍🔬 Read up more on user research regarding why people want dark mode and how they use it.

System 7 CloseView (Source)

Dark mode as an accessibility tool

There are also people who actually need dark mode and use it as another accessibility tool, for example, users with low vision. The earliest occurrence of such an accessibility tool I could find is System7’s CloseView feature, which had a toggle for Black on White and White on Black. While System 7 supported color, the default user interface was still black-and-white.

These inversion-based implementations demonstrated their weaknesses once color was introduced. User research by Szpiro et al. on how people with low vision access computing devices showed that all interviewed users disliked inverted images, but that many preferred light text on a dark background. Apple accommodates for this user preference with a feature called Smart Invert, which reverses the colors on the display, except for images, media, and some apps that use dark color styles.

A special form of low vision is Computer Vision Syndrome, also known as Digital Eye Strain, which is defined as “the combination of eye and vision problems associated with the use of computers (including desktop, laptop, and tablets) and other electronic displays (e.g. smartphones and electronic reading devices).” It has been proposed that the use of electronic devices by adolescents, particularly at night time, leads to an increased risk of shorter sleep duration, longer sleep-onset latency, and increased sleep deficiency. Additionally, exposure to blue light has been widely reported to be involved in the regulation of circadian rhythm and the sleep cycle, and irregular light environments may lead to sleep deprivation, possibly affecting mood and task performance, according to research by Rosenfield. To limit these negative effects, reducing blue light by adjusting the display color temperature through features like iOS’ Night Shift or Android’s Night Light can help, as well as avoiding bright lights or irregular lights in general through dark themes or dark modes.

Dark mode power savings on AMOLED screens

Finally, dark mode is known to save a lot of energy on AMOLED screens. Android case studies that focused on popular Google apps like YouTube have shown that the power savings can be up to 60%. The video below has more details on these case studies and the power savings per app.

Activating dark mode in the operating system

Now that I have covered the background of why dark mode is such a big deal for many users, let’s review how you can support it.

Android Q dark theme settings

Operating systems that support a dark mode or dark theme typically have an option to activate it somewhere in the settings. On macOS X, it’s in the system preference’s General section and called Appearance (screenshot), and on Windows 10, it’s in the Colors section and called Choose your color (screenshot). For Android Q, you can find it under Display as a Dark Theme toggle switch (screenshot), and on iOS 13, you can change the Appearance in the Display & Brightness section of the settings (screenshot).

The `prefers-color-scheme` media query

One last bit of theory before I get going. Media queries allow authors to test and query values or features of the user agent or display device, independent of the document being rendered. They are used in the CSS @media rule to conditionally apply styles to a document, and in various other contexts and languages, such as HTML and JavaScript. Media Queries Level 5 introduces so-called user preference media features, that is, a way for sites to detect the user's preferred way to display content.

☝️ An established user preference media feature is prefers-reduced-motion that lets you detect the desire for less motion on a page. I have written about prefers-reduced-motion before.

The prefers-color-scheme media feature is used to detect if the user has requested the page to use a light or dark color theme. It works with the following values:

no-preference: Indicates that the user has made no preference known to the system. This keyword value evaluates as false in the boolean context.
light: Indicates that the user has notified the system that they prefer a page that has a light theme (dark text on light background).
dark: Indicates that the user has notified the system that they prefer a page that has a dark theme (light text on dark background).

Supporting dark mode

Finding out if dark mode is supported by the browser

As dark mode is reported through a media query, you can easily check if the current browser supports dark mode by checking if the media query prefers-color-schemematches at all. Note how I don't include any value, but purely check if the media query alone matches.

if (window.matchMedia('(prefers-color-scheme)').media !== 'not all') {
 console.log('🎉 Dark mode is supported');
}

At the time of writing, prefers-color-scheme is supported on both desktop and mobile (where available) by Chrome and Edge as of version 76, Firefox as of version 67, and Safari as of version 12.1 on macOS and as of version 13 on iOS. For all other browsers, you can check the Can I use support tables.

There is a custom element <dark-mode-toggle>available that adds dark mode support to older browsers. I write about it further down in this article.

Dark mode in practice

Let’s finally see how supporting dark mode looks like in practice. Just like with the Highlander, with dark mode there can be only one: dark or light, but never both! Why do I mention this? Because this fact should have an impact on the loading strategy. Please don’t force users to download CSS in the critical rendering path that is for a mode they don’t currently use. To optimize load speed, I have therefore split my CSS for the example app that shows the following recommendations in practice into three parts in order to defer non-critical CSS:

style.css that contains generic rules that are used universally on the site.
dark.css that contains only the rules needed for dark mode.
light.css that contains only the rules needed for light mode.

Loading strategy

The two latter ones, light.css and dark.css, are loaded conditionally with a <link media> query. Initially, not all browsers will support prefers-color-scheme(detectable using the pattern above), which I deal with dynamically by loading the default light.css file via a conditionally inserted <link rel="stylesheet"> element in a minuscule inline script (light is an arbitrary choice, I could also have made dark the default fallback experience). To avoid a flash of unstyled content, I hide the content of the page until light.css has loaded.

<script>
 // If `prefers-color-scheme` is not supported, fall back to light mode.
 // In this case, light.css will be downloaded with `highest` priority.
 if (window.matchMedia('(prefers-color-scheme)').media === 'not all') {
 document.documentElement.style.display = 'none';
 document.head.insertAdjacentHTML(
 'beforeend',
 '<link rel="stylesheet" href="/light.css" onload="document.documentElement.style.display = ``">'
 );
 }
</script>
<!--
 Conditionally either load the light or the dark stylesheet. The matching file
 will be downloaded with `highest`, the non-matching file with `lowest`
 priority. If the browser doesn't support `prefers-color-scheme`, the media
 query is unknown and the files are downloaded with `lowest` priority (but
 above I already force `highest` priority for my default light experience).
-->
<link rel="stylesheet" href="/dark.css" media="(prefers-color-scheme: dark)">
<link rel="stylesheet" href="/light.css" media="(prefers-color-scheme: no-preference), (prefers-color-scheme: light)">
<!-- The main stylesheet -->
<link rel="stylesheet" href="/style.css">

Stylesheet architecture

I make maximum use of CSS variables, this allows my generic style.css to be, well, generic, and all the light or dark mode customization happens in the two other files dark.css and light.css. Below you can see an excerpt of the actual styles, but it should suffice to convey the overall idea. I declare two variables, -⁠-⁠color and -⁠-⁠background-color that essentially create a dark-on-light and a light-on-dark baseline theme.

/* light.css: 👉 dark-on-light */
:root {
 --color: rgb(5, 5, 5);
 --background-color: rgb(250, 250, 250);
}

/* dark.css: 👉 light-on-dark */
:root {
 --color: rgb(250, 250, 250);
 --background-color: rgb(5, 5, 5);
}

In my style.css, I then use these variables in the body { … } rule. As they are defined on the :root CSS pseudo-class—a selector that in HTML represents the <html> element and is identical to the selector html, except that its specificity is higher—they cascade down, which serves me for declaring global CSS variables.

/* style.css */
:root {
 color-scheme: light dark;
}

body {
 color: var(--color);
 background-color: var(--background-color);
}

In the code sample above, you will probably have noticed a property color-scheme with the space-separated value light dark.

Warning: The color-scheme property is still in development and it might not work as advertised, full support in Chrome will come later this year.

This tells the browser which color themes my app supports and allows it to activate special variants of the user agent stylesheet, which is useful to, for example, let the browser render form fields with a dark background and light text, adjust the scrollbars, or to enable a theme-aware highlight color. The exact details of color-scheme are specified in CSS Color Adjustment Module Level 1.

🌒 Read up more on what color-scheme actually does.

Everything else is then just a matter of defining CSS variables for things that matter on my site. Semantically organizing styles helps a lot when working with dark mode. For example, rather than -⁠-⁠highlight-yellow, consider calling the variable -⁠-⁠accent-color, as "yellow" may actually not be yellow in dark mode or vice versa. Below is an example of some more variables that I use in my example.

/* dark.css */
:root {
 --color: rgb(250, 250, 250);
 --background-color: rgb(5, 5, 5);
 --link-color: rgb(0, 188, 212);
 --main-headline-color: rgb(233, 30, 99);
 --accent-background-color: rgb(0, 188, 212);
 --accent-color: rgb(5, 5, 5);
}

/* light.css */
:root {
 --color: rgb(5, 5, 5);
 --background-color: rgb(250, 250, 250);
 --link-color: rgb(0, 0, 238);
 --main-headline-color: rgb(0, 0, 192);
 --accent-background-color: rgb(0, 0, 238);
 --accent-color: rgb(250, 250, 250);
}

Full example

In the following Glitch embed, you can see the complete example that puts the concepts from above into practice. Try toggling dark mode in your particular operating system’s settings and see how the page reacts.

Loading impact

When you play with this example, you can see why I load my dark.css and light.css via media queries. Try toggling dark mode and reload the page: the particular currently non-matching stylesheets are still loaded, but with the lowest priority, so that they never compete with resources that are needed by the site right now.

😲 Read up more on why browsers download stylesheets with non-matching media queries.

Site in light mode loads the dark mode CSS with lowest priority.

Site in dark mode loads the light mode CSS with lowest priority.

Site in default light mode on a browser that doesn’t support prefers-color-scheme loads the dark mode CSS with lowest priority.

Reacting on dark mode changes

Like any other media query change, dark mode changes can be subscribed to via JavaScript. You can use this to, for example, dynamically change the favicon of a page or change the <meta name="theme-color"> that determines the color of the URL bar in Chrome. The full example above shows this in action, in order to see the theme color and favicon changes, open the demo in a separate tab.

const darkModeMediaQuery = window.matchMedia('(prefers-color-scheme: dark)');
 darkModeMediaQuery.addListener((e) => {
 const darkModeOn = e.matches;
 console.log(`Dark mode is ${darkModeOn ? '🌒 on' : '☀️ off'}.`);
 });

Dark mode best practices

Avoid pure white

A small detail you may have noticed is that I don’t use pure white. Instead, to prevent glowing and bleeding against the surrounding dark content, I choose a slightly darker white. Something like rgb(250, 250, 250) works well.

Re-colorize and darken photographic images

If you compare the two screenshots below, you will notice that not only the core theme has changed from dark-on-light to light-on-dark, but that also the hero image looks slightly different. My user research has shown that the majority of the surveyed people prefer slightly less vibrant and brilliant images when dark mode is active. I refer to this as re-colorization.

Hero image slightly darkened in dark mode.

Regular hero image in light mode.

Re-colorization can be achieved through a CSS filter on my images. I use a CSS selector that matches all images that don’t have .svg in their URL, the idea being that I can give vector graphics (icons) a different re-colorization treatment than my images (photos), more about this in the next paragraph. Note how I again use a CSS variable, so I can later on flexibly change my filter.

🎨 Read up more on user research regarding re-colorization preferences with dark mode.

As re-colorization is only needed in dark mode, that is, when dark.css is active, there are no corresponding rules in light.css.

/* dark.css */
--image-filter: grayscale(50%);

img:not([src*=".svg"]) {
 filter: var(--image-filter);
}

Customizing dark mode re-colorization intensities with JavaScript

Not everyone is the same and people have different dark mode needs. By sticking to the re-colorization method described above, I can easily make the grayscale intensity a user preference that I can change via JavaScript, and by setting a value of 0%, I can also disable re-colorization completely. Note that document.documentElementprovides a reference to the root element of the document, that is, the same element I can reference with the :rootCSS pseudo-class.

const filter = 'grayscale(70%)';
document.documentElement.style.setProperty('--image-filter', value);

Invert vector graphics and icons

For vector graphics — that in my case are used as icons that I reference via <img> elements—I use a different re-colorization method. While research has shown that people don't like inversion for photos, it does work very well for most icons. Again I use CSS variables to determine the inversion amount in the regular and in the :hover state.

Icons are inverted in dark mode.

Regular icons in light mode.

Note how again I only invert icons in dark.css but not in light.css, and how :hover gets a different inversion intensity in the two cases to make the icon appear slightly darker or slightly brighter, dependent on the mode the user has selected.

/* dark.css */
--icon-filter: invert(100%);
--icon-filter_hover: invert(40%);

img[src*=".svg"] {
 filter: var(--icon-filter);
}


/* light.css */
--icon-filter_hover: invert(60%);

/* style.css */
img[src*=".svg"]:hover {
 filter: var(--icon-filter_hover);
}

Use `currentColor` for inline SVGs

For inline SVG images, instead of using inversion filters, you can leverage the currentColor CSS keyword that represents the value of an element's color property. This lets you use the color value on properties that do not receive it by default. Conveniently, if currentColor is used as the value of the SVG fill or strokeattributes, it instead takes its value from the inherited value of the color property. Even better: this also works for <svg><use href="…"></svg>, so you can have separate resources and currentColor will still be applied in context. Please note that this only works for inline or <use href="…"> SVGs, but not SVGs that are referenced as the src of an image or somehow via CSS. You can see this applied in the demo below.

<!-- Some inline SVG -->
<svg xmlns="http://www.w3.org/2000/svg"
 stroke="currentColor"
>
 […]
</svg>

Smooth transitions between modes

Switching from dark mode to light mode or vice versa can be smoothed thanks to the fact that both color and background-color are animatable CSS properties. Creating the animation is as easy as declaring two transitions for the two properties. The example below illustrates the overall idea, you can experience it live in thedemo.

body {
 --duration: 0.5s;
 --timing: ease;

color: var(--color);
 background-color: var(--background-color);

transition:
 color var(--duration) var(--timing),
 background-color var(--duration) var(--timing);
}

Art direction with dark mode

While for loading performance reasons in general I recommend to exclusively work with prefers-color-scheme in the media attribute of <link> elements (rather than inline in stylesheets), there are situations where you actually may want to work with prefers-color-scheme directly inline in your HTML code. Art direction is such a situation. On the web, art direction deals with the overall visual appearance of a page and how it communicates visually, stimulates moods, contrasts features, and psychologically appeals to a target audience.

With dark mode, it’s up to the judgment of the designer to decide what is the best image at a particular mode and whether re-colorization of images is maybe not good enough. If used with the <picture> element, the <source> of the image to be shown can be made dependent on the media attribute. In the example below, I show the Western hemisphere for dark mode, and the Eastern hemisphere for light mode or when no preference is given, defaulting to the Eastern hemisphere in all other cases. This is of course purely for illustrative purposes. Toggle dark mode on your device to see the difference.

<picture>
 <source srcset="western.webp" media="(prefers-color-scheme: dark)">
 <source srcset="eastern.webp" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)">
 `<img src="eastern.webp">
</picture>

Dark mode, but add an opt-out

As mentioned in the why dark mode section above, dark mode is an aesthetic choice for most users. In consequence, some users may actually like to have their operating system UI in dark, but still prefer to see their webpages the way they are used to seeing them. A great pattern is to initially adhere to the signal the browser sends through prefers-color-scheme, but to then optionally allow users to override their system-level setting.

The `<dark-mode-toggle>` custom element

You can of course create the code for this yourself, but you can also just use a ready-made custom element (web component) that I have created right for this purpose. It’s called <dark-mode-toggle> and it adds a toggle (dark mode: on/off) or a theme switcher (theme: light/dark) to your page that you can fully customize. The demo below shows the element in action (oh, and I have also 🤫 silently snuck it in all of the other examples above).

<dark-mode-toggle
 legend="Theme Switcher"
 appearance="switch"
 dark="Dark"
 light="Light"
 remember="Remember this"
></dark-mode-toggle>

<dark-mode-toggle> in light mode.

<dark-mode-toggle> in dark mode.

Try clicking or tapping the dark mode controls in the upper right corner in the demo below. If you check the checkbox in the third and the fourth control, see how your mode selection is remembered even when you reload the page. This allows your visitors to keep their operating system in dark mode, but enjoy your site in light mode or vice versa.

GoogleChromeLabs / dark-mode-toggle

A custom element that allows you to easily put a Dark Mode 🌒 toggle or switch on your site:

`<dark-mode-toggle>` Element

A custom element that allows you to easily put a Dark Mode 🌒 toggle or switch on your site, so you can initially adhere to your users' preferences according to prefers-color-scheme but also allow them to (optionally permanently) override their system setting for just your site.

📚 Read all(!) about dark mode in the related article Hello Darkness, My Old Friend.

Installation

From npm:

npm install --save dark-mode-toggle

In the browser:

import * as DarkModeToggle from 'https://cdn.pika.dev/dark-mode-toggle';

import * as DarkModeToggle from 'https://unpkg.com/dark-mode-toggle';

Usage

⚠️ The custom element assumes that you have organized your CSS in different files that you load conditionally based on the media attribute in the stylesheet's corresponding link element. This is a great performance pattern as you don't force people to download CSS that they don't need based on their current theme preference, yet non-matching…

View on GitHub

Conclusions

Working with and supporting dark mode is fun and opens up new design avenues. For some of your visitors it can be the difference between not being able to handle your site and being a happy user. There are some pitfalls and careful testing is definitely required, but dark mode is definitely a great opportunity for you to show that you care about all of your users. The best practices mentioned in this post and helpers like the <dark-mode-toggle> custom element should make you confident in your ability to create an amazing dark mode experience. Let me know on Twitterwhat you create and if this post was useful or also suggestions for improving it. Thanks for reading! 🌒

Acknowledgements

The prefers-color-scheme media feature, the color-scheme CSS property, and the related meta tag are the implementation work of 👏 Rune Lillesveen. Rune is also a co-editor of the CSS Color Adjustment Module Level 1spec. I would like to 🙏 thank Lukasz Zbylut, Rowan Merewood, Chirag Desai, and Rob Dodson for their thorough reviews of this article. The loading strategy is the brainchild of Jake Archibald. Emilio Cobos Álvarez has pointed me to the correct prefers-color-schemedetection method. The tip with referenced SVGs and currentColor came from Timothy Hatcher. Finally, I am thankful to the many anonymous participants of the various user studies that have helped shape the recommendations in this article. Hero image by Nathan Anderson.

Exposing headers on CORS responses

Jeff Posnick — Mon, 22 Jul 2019 12:00:00 +0000

CORS and its discontents

The concept of CORS requests comes up a lot in my professional life. Much of the time, it's in the context of why a given response is opaque, and how to make that response non-opaque so that it plays nicely with service workers and the Cache Storage API.

Fortunately, many popular third-party APIs and hosts support CORS nowadays, and solving your basic CORS-related mystery normally boils down to, say, adding in the crossorigin attribute to your <img> tags.

When CORS is not enough

But while enabling CORS is enough to get back basic information about an HTTP response—like its status code, or access to its body—there's still some information that's locked down by default. The headers exposed on a CORS response, for instance, are limited to the following six "simple" response headers:

Cache-Control
Content-Language
Content-Type
Expires
Last-Modified
Pragma

Some of those headers can come in handy when accessed inside of a service worker, but there's one in particular that can be useful, but isn't exposed by default: Date.

In particular, if you're using Workbox's cache expiration logic and you provide a maxAgeSeconds parameter, the Date of the cached response is checked against the difference between the current time and maxAgeSeconds. If the Date is too old, then the cached response will end up being ignored.

But... this logic only works if there's a Date header exposed on the response. By default, that won't be the case for a CORS response.

Exposition

The workaround, as with so many things related to CORS, involves fiddling with HTTP response headers. You'll either need access to the underlying HTTP server yourself, or you'll need to reach out to your CDN/API provider asking them to make the change.

Setting Access-Control-Expose-Headers: Date will permit the Date response header to be visible to your web app's code, and you could include any additional headers there in a comma-separated list.

If you're using your own Express-based web server, the corser middleware looks pretty reasonable for setting up a working configu ration. Their docs include a recipe for configuring the exposed response headers.

Measuring Cumulative Layout Shift (CLS) in WebPageTest

Rick Viscomi — Thu, 18 Jul 2019 21:36:45 +0000

What is CLS?

Cumulative Layout Shift (CLS) is a relatively new metric to help you understand the delightfulness of the user experience. You might be reading a website when suddenly the text shifts down 100 pixels and you lose your place. That's not a delightful experience.

The value of a layout shift is the percent of the viewport that moved. So in this example perhaps 10% of the viewport shifted. If another shift of 2% happens later, the page's CLS would be 12%.

How can it be measured?

web.dev/layout-instability/api is a great resource to learn more about the API and how to use it to measure CLS. Here's their example code to calculate CLS:



// Stores the current layout shift score for the page.
let cumulativeLayoutShiftScore = 0;

// Detects new layout shift occurrences and updates the
// `cumulativeLayoutShiftScore` variable.
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    cumulativeLayoutShiftScore += entry.value;
  }
});

observer.observe({entryTypes: ['layoutShift']});

// Sends the final score to your analytics back end once
// the page's lifecycle state becomes hidden.
document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') {
    // Force any pending records to be dispatched.
    observer.takeRecords();

    // Send the final score to your analytics back end
    // (assumes `sendToAnalytics` is defined elsewhere).
    sendToAnalytics({cumulativeLayoutShiftScore});
  }
});

At the moment, the layoutShift type is only available when the API is explicitly enabled. If you're running Chrome 76 or newer, you can start it up via the command line with this flag set:



--enable-blink-features=LayoutInstabilityAPI

Measuring CLS in WebPageTest

WebPageTest (WPT) is a popular tool for controlled measurements of web performance stats. Let's take a look at how we can configure it to record CLS.

Choosing the right browser

WPT supports many browsers from many locations around the world. For this test to work, we need a newer version of Chrome that supports the LayoutInstabilityAPI Blink feature. Since WPT's default version of Chrome is on version 75 at this time of writing, we'll select Chrome Canary (version 77), which is available from the Dulles, VA test location.

Setting the command line flag

Under the advanced settings "Chromium" tab there's a field to provide command line options.

Measuring CLS as a custom metric

Custom metrics are snippets of JavaScript that execute as the web page test is wrapping up. The syntax is to give it a name in [name] format on the first line, followed by a script with a single return value. Here's a custom metric to measure CLS:



[CumulativeLayoutShift]
return new Promise(resolve => {
  var CLS = 0;
  new PerformanceObserver(list => {
    list.getEntries().forEach(entry => {
      if (entry.hadRecentInput) return;
      CLS += entry.value;
    });
    resolve(CLS);
  }).observe({type: "layout-shift", buffered: true});
});

Side note: Astute WPT mega-pro power users reading this post are objecting to this script because it returns a promise, and custom metrics only support synchronous code. Not anymore! As of literally a couple hours ago, WPT now supports async custom metrics!

This script will resolve to the CLS value for the test page, whose layout shifts have been saved to a buffer.

Ok! So with those options configured, you're ready to enter the URL of the page you want to test and run it. You can find the results on the Custom Metrics page.

For this page, the CLS is 0.3. It's a page I built, with a large part of its UI dynamically rendered from a script, so ~30% checks out.

To visualize this, we can use the filmstrip view, which shows us what the page looked like while it loaded. In this case it was blank for half a second, then the entire thing rendered. It's not clear where the layout shift is, but it could have happened in a matter of milliseconds. It isn't necessarily a poor user experience if the layout shift happens so close to the start of rendering, so that might be a case for tweaking the CLS algorithm.

Wrapping up

CLS is still a very new metric, so if you do start using it, please leave any feedback on the Layout Instability API GitHub repository.

New "State of the Web" video: BigQuery!

Rick Viscomi — Thu, 04 Jul 2019 23:08:15 +0000

When we pull stats about the state of the web, like the percent of websites adopting HTTPS or the median amount of image bytes per page, these figures come from web transparency datasets on BigQuery like the HTTP Archive and Chrome UX Report. In this video, I chat with Felipe Hoffa (BigQuery Developer Advocate) about the capabilities of BigQuery and how to get started with it.

Disable a HTML form while in-flight using fieldset

Sam Thorogood — Tue, 11 Jun 2019 03:21:49 +0000

I'm a big fan of great UIs that properly control your user's ability to interact with your page: such as changing some value during a form submit. We've all seen the "do not change this form until it's done!" messages. 🙄

There's a standard HTML feature which can help you with this, in <fieldset disabled>. First, here's a demo:

Try submitting the form, clicking on one of the blue links (they don't go anywhere, it's just for the demo) and pressing the Tab key. The inputs cannot be focused! 🤯

The Feature

When your browser sees a <fieldset> with its disabled attribute set: e.g., <fieldset disabled>, it will completely disable every <input>, <textarea> and <button> element found within. 🚫📝

This is pretty powerful. Your code might look like:

yourForm.addEventListener('submit', (event) => {
  event.preventDefault();  // disable normal submit

  const body = new FormData(yourForm);
  const p = fetch('/foo', {method: 'POST', body}).then((response) => {
    // ...
  });

  // important bit here
  yourFieldset.disabled = true;
  p.finally(() => {
    // .finally runs even if the fetch fails
    yourFieldset.disabled = false;
  });
});

Other uses for `fieldset`

The fieldset element also lets you group HTML form elements, including adding a legend(-ary). It's useful for accessibility and as a way to visually style groups. For a simple demo, check out this page on MDN.

Alternatives

Classic alternatives to really simple, powerful features like <fieldset disabled> tend to include:

adding a giant element that covers the form so users can't click on it
iterating through every <input> and marking it disabled
just hiding the form.

And all of these are pretty painful versus <fieldset disabled>. 🤮

Thanks!

If you're curious about controlling user interaction, be sure to read up on the "inert" attribute, which takes <fieldset disabled> one step further, but doesn't have full browser support yet.

11 👋

Beyond appendChild: Better convenience methods for HTML

Sam Thorogood — Sun, 09 Jun 2019 00:09:35 +0000

I've built on the web for a while now. So long that when I'm writing vanilla HTML/JS, my go-to has always been .appendChild() to add new HTML elements, and a huge series of createElement calls along with it.

But there's actually some lesser-known convenience methods that we can use now (well, in a post-IE11 world, where all devs should be). 🌎👍 I'm not arguing against your framework or components, but sometimes, you just have to write vanilla JS. 🍦

One-Line Element Creation

I confess 😅 that this isn't really one line, but it's one statement:

const el = Object.assign(document.createElement('div'), {
  textContent: `Your div now has text`,
  className: 'and-is-classy',
});

The helper Object.assign wasn't available in IE11.

Remove Self

This one is pretty well-known.

const el = document.getElementById('something');
el.remove();   // instead of el.parentNode.removeChild(el)

Insert Element or Text

The .append() method can append any real elements, or it will automatically create a text node if you pass it a string. It takes any number of arguments.

el.append(document.createElement('hr'), 'I get upgraded to a text node!');

There's also .prepend() which is the opposite of .append(). It inserts all the elements, in-order, at the start of the element:

const heading = Object.assign(document.createElement('h2', {
  textContent: 'List Of Awesome HTML Methods',
});
list.prepend(heading, `You Won't Believe How Many We Found!`);

Insert Relative To Element

Every element has methods .before() and .after(). These insert new HTML nodes directly adjacent to the current node. Like the methods above, they accept any number of other elements or strings.

myHeading.before(superHeading);
myHeading.after(`Here's a list of awesome stuff`, theList);

⚠️ There's one caveat: in our example, if myHeading isn't actually on the page—it's a temporary element—these methods will just fail silently without throwing an Error.

Replace Self

Rather than doing a parentNode.replaceChild dance, we can now self-destruct an element and replace it with something new. Again, we can replace ourselves with any number of other elements or strings (even none!).

const fancyItem = Object.assign(document.createElement('strong'), {
  textContent: 'fancy',
});
someFancyHeading.replaceWith('Less', fancyItem, 'heading');
someFancyHeading.replaceWith();  // although you could just use .remove 🤷

Class Force Set

If you want to set the state of a class to a variable true or false, you can pass a second param to .classList.toggle:

const someState = false;
theDiv.classList.toggle('foo', !someState);  // forces foo on
theDev.classList.toggle('bar', someState);   // forces bar off
// result e.g. <div id="theDiv" class="foo">

This is probably well-known. But if you're explicitly not supporting IE11, it's nice to be confident that this now works. 🎉

Done!

What have I missed? Let me know if there any other old habits you've recently discovered you can let go of.

9 👋

DEV Community: Google Web Dev

What’s new in Web Payments

Announcing web.dev LIVE: A three day digital event

Watch live on:

Performance auditing an eCommerce site

Alan's weekly eCommerce livestreams

The site review

Tools used:

Observations

YEStifications: Exploring how users engage with notification prompts in the Chrome UX Report

📢 example.com wants to show notifications

The state of notification permissions

Where we go from here

Fixing layout instability

Measuring layout shifts

Measuring layout shifts in WebPageTest

Identifying causes of layout instability

Fixing layout instability

Verifying the optimizations

Conclusion

(One more thing)

[Video] The State of the Web: Developing with a global mindset

Hello darkness, my old friend

Overhyped or necessity? Learn everything about dark mode and how to support it to the benefit of your users!

Introduction

Dark mode before Dark Mode

Why dark mode

Dark mode for aesthetic reasons

Dark mode as an accessibility tool

Dark mode power savings on AMOLED screens

Activating dark mode in the operating system

The prefers-color-scheme media query

Supporting dark mode

Finding out if dark mode is supported by the browser

Dark mode in practice

Loading strategy

Stylesheet architecture

Full example

Loading impact

Reacting on dark mode changes

Dark mode best practices

Avoid pure white

Re-colorize and darken photographic images

Customizing dark mode re-colorization intensities with JavaScript

Invert vector graphics and icons

Use currentColor for inline SVGs

Smooth transitions between modes

Art direction with dark mode

Dark mode, but add an opt-out

The <dark-mode-toggle> custom element

GoogleChromeLabs / dark-mode-toggle

A custom element that allows you to easily put a Dark Mode 🌒 toggle or switch on your site:

<dark-mode-toggle> Element

Installation

Usage

Conclusions

Related links

Acknowledgements

Exposing headers on CORS responses

CORS and its discontents

When CORS is not enough

Exposition

Measuring Cumulative Layout Shift (CLS) in WebPageTest

What is CLS?

How can it be measured?

Measuring CLS in WebPageTest

Choosing the right browser

Setting the command line flag

Measuring CLS as a custom metric

Wrapping up

New "State of the Web" video: BigQuery!

Disable a HTML form while in-flight using fieldset

The Feature

Other uses for fieldset

Alternatives

Thanks!

Beyond appendChild: Better convenience methods for HTML

One-Line Element Creation

Remove Self

Insert Element or Text

The `prefers-color-scheme` media query

Use `currentColor` for inline SVGs

The `<dark-mode-toggle>` custom element

`<dark-mode-toggle>` Element

Other uses for `fieldset`