Share

Modern Web Weekly #71

If you want to use encryption in your web app to encrypt and decrypt sensitive data, you can use the Web Crypto API to generate an public and private key:

const { publicKey, privateKey } = await window.crypto.subtle.generateKey(
  {
    name: "RSA-OAEP",
    modulusLength: 4096,
    publicExponent: new Uint8Array([1, 0, 1]),
    hash: "SHA-256",
  },
  true,
  ["encrypt", "decrypt"],
);

You can now send the public key to anyone you want to share your encrypted data with and keep your private key safely stored so you can decrypt data. But where exactly would you store your private key?

The only options you have are localStorage, sessionStorage, IndexedDB, and OPFS. While these are relatively safe, there is always the possibility that your web app is compromised and your private key is stolen. For very sensitive data, that can be un unacceptable risk.

Luckily, there’s now a solution.

The WebAuthn PRF extension (Pseudo-Random Function) enables web apps to derive encryption keys using the user’s passkey, without ever touching the private key itself.

Whenever you register a passkey or authenticate with it, you provide a text label for the key and you get a secret back that you can use to derive the encryption key. If you specify the same label, you get the same encryption key back.

So your web app only needs to store the label that you can use to get the key. No need to store the key anywhere else so it can never be stolen.

Here’s how it works.

When registering a passkey

Whenever you register a passkey, you add a prf key to the extensions key of the credential creation options like this:

extensions: {
  prf: {
    eval: {
      first: new TextEncoder().encode("prf-key-v1") // the text label to derive the key
    }
  }
}

In this example, “prf-key-1” is the text label we use for the key. The complete example to register the passkey would look something like this:

const credential = await navigator.credentials.create({
  publicKey: {
    challenge: new Uint8Array([
      21, 31, 105 /* 29 more random bytes generated by the server */,
    ]),
    rp: { name: "Secure Notes" },
    user: {
      id: new Uint8Array(16),
      name: "pwa@whatpwacando.today",
      displayName: "PWA"
    },
    pubKeyCredParams: [{ alg: -7, type: "public-key" }],
    authenticatorSelection: {
      userVerification: "required"
    },
    extensions: {
      prf: {
        eval: {
          first: new TextEncoder().encode("prf-key-v1") // the text label to derive the key
        }
      }
    }
  }
}); 

We can now access the secret that we can use to derive the encryption key:

const prfResult = credential.getClientExtensionResults().prf.results.first;

prfResult is an ArrayBuffer that we can use to create a CryptoKey object using importKey():

const keyMaterial = await crypto.subtle.importKey(
  "raw",
  prfResult,
  "HKDF",
  false,
  ["deriveKey"]
);

And then we can use deriveKey() to get the actual encryption key:

const encryptionKey = await crypto.subtle.deriveKey(
  {
    name: "HKDF",
    hash: "SHA-256",
    salt: new Uint8Array([]),
    info: new TextEncoder().encode("prf-demo"),
  },
  keyMaterial,
  { name: "AES-GCM", length: 256 },
  false,
  ["encrypt", "decrypt"]
);

Don’t worry if you don’t fully understand these last two steps. The important part is that you know how to get the actual encryption key and use it to encrypt and decrypt your data.

Here’s how you can encrypt text:

const textToEncrypt = 'My super secret data';
const iv = crypto.getRandomValues(new Uint8Array(12));

const encryptedText = await crypto.subtle.encrypt(
  { name: "AES-GCM", iv },
  encryptionKey,
  new TextEncoder().encode(textToEncrypt)
);

And here’s how you can decrypt it:

const decrypted = await crypto.subtle.decrypt(
  { name: "AES-GCM", iv },
  encryptionKey,
  textToDecrypt
);

const decryptedText = new TextDecoder().decode(decryptedText);

Notice that the variable iv (Initialisation Vector) needs to be the same for encryption and decryption, so if you want to store the decrypted text on a server, you need to store iv along with it.

If you want to decrypt the text, you simply get the decrypted text and iv from the server, authenticate with your passkey and pass in the correct text label when you get the passkey using navigator.credentials.get():

const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: new Uint8Array([
      21, 31, 105 /* 29 more random bytes generated by the server */,
    ]),
    extensions: {
      prf: {
        eval: {
          first: new TextEncoder().encode("prf-key-v1") // same text label to derive the key
        }
      }
    }
  }
});

Because you use the same text label for the key (“pro-key-1“) you get the exact same key back so you can decrypt your data.

The beauty of this is that you can only get the key after you are authenticated using your passkey. There’s no key stored in the browser storage (localStorage, cookies, IndexedDB etc.) so even when your app is hacked, your private key can’t be stolen.

The WebAuthn PRF extension is supported in all major browsers.

Check out the demo on https://whatpwacando.today/encryption

Do you need help with your web app?

Book a 1-on-1 call with me and I will do my absolute best to answer all your questions and solve your problems.

€100 for one hour, money-back guarantee if you’re not satisfied.

Book a call now

Safari Tech Preview now supports the improved attr() function

After Chrome, Safari Tech Preview 241 now also supports the improved attr() function. This function can read any attribute from the element it’s applied to. Using its output however, was limited to the CSS content attribute, but now you can use it in conjunction with any CSS property.

For example, you can now define the background color of a <div> with a data attribute and then use that in its CSS like this:

<div
  data-bg="#00ff00"></div>

<style>
  div {
    background-color: attr(data-bg type(<color>));
  }
</style>  

The attr() function reads the data-bg attribute and declares that its value is a color value with type(<color>). There are many other value types, for example <string>and <number>. You can find the complete list in the specs.

You can also define a CSS unit if the value you read from an attribute needs to include a unit value, like px for example:

div {
  font-size: attr(data-font-size px);
}

or use this as the value of a CSS custom property:

/* set the value of the "--font-size" custom property */
div {
  --font-size: attr(data-font-size px);
}

If the attribute that attr() reads is not present, you can also define a fallback value:

div {
  background-color: attr(data-bg type(<color>), #00ff00);
}

(note the comma before the fallback value)

This way, you can expose a couple of (data-) attributes that can be used to style an element solely by changing its attribute values. The benefits that this approach has over utility classes and inline styles are that utility classes can only have fixed values and inline styles can be blocked by content security policies

Checkout the codepen where you can change the data-attributes of the <div> to change its styling and the min and max attributes of the slider to change the background color.

Tailwind with attr()?

Ready for a fun experiment? How about we implement the whole Tailwind library with a single stylesheet?

Well, sort of...

Tailwind is a CSS library that uses utility classes to add styling to HTML elements. So instead of setting display: flex on a <div> with CSS like this:

div {
  display: flex;
}

You would do something like this:

<div class="flex"></div>

To be honest, I’m not a fan of this approach because it throws the cascade (the “C” in CSS) out the window in favor of classes, but the new and improved attr() function inspired me to implement something similar.

In case you missed it, in Chrome 133 the attr() function can now be used to set the value of any CSS property whereas before, you could only use this with content. For example, you can now set the background-color of an element with an attribute, say data-bg:

div {
  background-color: attr(data-bg type(<color>));
}  

<div data-bg="red"></div>

The web app now reads the value “red” from the data-bg attribute and sets it as the background-color CSS property on the <div>. We need to specify that the attribute will give a color value so we need to set its type with type(<color>). If we omit this type parameter it will default to string, but a string is not considered a valid color value in CSS since a value like red is a keyword, not a string.

This way, we could map any CSS property to an attribute and that’s exactly what I did in this codepen:

Limitations

For properties that take a value and a unit like px or rem for example, the attr()function needs to specify that unit:

div {
  width: attr(width px);
}

and then you would specify a width of 50px like this:

<div
  width="50"
  >
</div>

But this means that the value of the attribute is always parsed as a pixel value. You won’t be able to specify the value as “%” or “rem” unless you change the CSS rule:

div {
  /* percentage value */
  width: attr(width %);

  /* rem value */
  width: attr(width rem);
}  

Another limitation is that you can’t specify the width with a keyword like fit-content, for example, unless you change the rule to this:

div {
  width: attr(width type(*));
}  

where type(*) is a shorthand for all allowed keywords.

I had hoped I would be able to set this type for keywords as a fallback value like this, but unfortunately, that doesn’t work and causes the whole rule to fail:

/* specify the value as a px value and if that doesn't work, 
 * the fallback value should be used that specifies its type as
 * type(*) meaning keywords can be used but unfortunately, this 
 * doesn't work
*/
div {
  width: attr(width px, attr(width type(*), auto));
}

You can also explicitly mention the keywords to limit the number of allowed values. In the following example, only fit-content and min-content are allowed, and if the user specifies another value, the width will default to auto which is the fallback value specified here:

div {
  width: attr(width type(fit-content | min-content), auto);
}   

Other things to note

For shorthand properties like padding for example, I also added the expanded properties like padding-top, padding-bottom etc.

For the expanded properties (padding-top, padding-bottom etc.) to be able to override the shorthand property (padding), they need to be defined later in the stylesheet and the expanded properties need to have a fallback value equal to the shorthand property attribute value, (attr(padding px)) and if that attribute is not specified (padding) there needs to be a fallback for that as well (so it becomes attr(padding px,auto)):

div {
  /* the shorthand "padding" comes first with a fallback value "auto" */
  padding: attr(padding px, auto);

  /* the expanded properties read their values from the 
   * corresponding attribute and fallback to the attribute
   * value of the shorthand property "padding" and if that is
   * not specified, they fallback to "auto"
  */
  padding-top: attr(padding-top px, attr(padding px, auto));
  padding-right: attr(padding-right px, attr(padding px, auto));
  padding-bottom: attr(padding-bottom px, attr(padding px, auto));
  padding-left: attr(padding-left px, attr(padding px, auto));
}

If you don’t put padding first, the expanded properties won’t be able to override it, and if you don’t set the fallback value of the expanded properties to the value of the paddingattribute (attr(padding px, auto)) they will fall back to 0px and padding won’t work at all. You also need to provide the fallback value auto in attr(padding px, auto) otherwise, you won’t be able to set any of the expanded properties.

Lastly, I haven’t been able to get border to work as a shorthand property. I’ll post any updates here if I manage to fix this.

Just because you can, doesn’t mean you should

While this has been a fun experiment, I’m not sure if this is really of any practical use, so I don’t recommend you use this in production. It has taught me a lot about the attr()function, so I recommend you play with it and see what other uses you may come up with. As more CSS functions are getting support, like ident() I will update this demo and write about it here.

Light dismiss a <dialog> with the closedby property

Safari Tech Preview also joins the light-dismiss-a-dialog party with full support for the closedby property.

This property configures which types of user actions can close a <dialog> element, typically the ESC-button and an outside click. You can declaratively set it using the corresponding closedby attribute:

<dialog closedby="any">

closedby can take three values:

• closerequest: the dialog can be dismissed with a platform-specific user action, typically the ESC-key on desktop

• any: the dialog can be dismissed with a light dismiss user action or a platform-specific user action, typically the ESC-key on desktop or an click outside of the dialog

• none: the dialog can only be closed by a developer-specified mechanism, like JavaScript or an invoker command

When the value is closerequest or any, the dialog can always be closed with JavaScript or an invoker command.

When the closedby attribute is not specified or invalid, and the dialog is opened with showModal() or command=”show-modal”, it falls back to
closedby=”closerequest”.

If the dialog is opened with show(), it falls back to closedby=”none”.

When support lands in the main version of Safari, closedby will be supported in all major browsers.

Check the demo on codepen:

PWA Audit: on your way to a great PWA

Do you already have a PWA, but are you running into issues with performance, security, or functionality? Or are you not sure how to make your PWA better?

I can help you by running an audit of your PWA

I will evaluate it on more than 35 criteria and provide you with clear and actionable instructions on how to improve it. No generic stuff that you can get anywhere, but an in-depth quality checkup to get you on your way to a great PWA.

Some of the criteria I will evaluate it on are:

• Installability

• Cross-device and cross-platform compatibility

• Offline support

• Usability

• Effective use of modern web APIs

• Performance

• Security

Your investment in the improvement of your PWA through the audit is €499, excluding VAT (where applicable).

If you want to request an audit or first would like to know more, you can

fill out the form or book a call with me.

The state of PWA deep linking

One of the best features of native apps is that they are able to capture links within their scope to enable deep linking.

For example, when I have the Instagram app installed on my phone and someone sends me a link to an Instagram post and I click it, it will open the Instagram app instead of a browser.

PWAs also have this capability, but unfortunately, the story of where this works and when is a bit complicated. It differs on various OSes and browsers, so it’s not always easy to know when deep linking will work.

To help understand deep linking into PWAs, I tested all options and here are my findings.

Web App link handling

Chromium-based browsers like Chrome and Edge support the handle_linksmanifest.json member that enables PWAs to capture links within their scope, which simply means that the URL is within the scope as defined in manifest.json.

So when the scope of a PWA is “https://www.example.com/” and the URL of the clicked link is “https://www.example.com/foo”, then it will be captured by the PWA.

When a PWA wants to use this behavior, the handle_links member should be added to manifest.json:

"handle_links": "preferred"

The handle_links member can hold the following values:

• “preferred”: the user agent should handle links using matching PWAs and may promote link handling behavior.

• “not-preferred”: the user agent should not handle links using matching PWAs and may not promote link handling behavior.

• “auto”: default value if handle_links is not found in the manifest. The user agent may choose between “preferred” and “not-preferred”.

See the explainer for details.

I tested the behavior of this on all platforms in all major browsers by sending a link in an email to myself and then clicking that link.

Android

PWA installed with Chrome

When I click the link in the GMail app or in Chrome, it’s always opened in the PWA, even when Chrome is not the default browser.

When the email is opened in Edge through the GMail website and I click the link, it opens in Edge but also offers to open it in the PWA:

PWA installed with Edge

When I click the link in the GMail app, the link is not opened in the PWA but in an in-app browser powered by the default browser:

When the email is opened in any browser through the GMail website and I click it, it’s opened in the same browser the GMail website was opened with.

PWA installed with Firefox

Here, the behaviour is the same as when the PWA is installed with Edge: when I click the link in the GMail app, the link is not opened in the PWA but in an in-app browser powered by the default browser.

Conclusion for Android: deep linking only works reliably when the PWA is installed with Chrome.

iOS

On iOS, there is unfortunately no support for deep linking. All clicked links open in the default browser, regardless of whether a PWA is installed and with which browser.

ChromeOS

On ChromeOS, the PWA can only be installed with Chrome and deep linking works reliably.

macOS

PWA installed with Chrome

When I click the link in the Mail app, it opens in the default browser. When it’s opened in Chrome, it offers to open it in the PWA instead:

When the email is opened in any browser through the GMail website and I click it, it’s opened in the same browser the GMail website was opened with.

PWA installed with Edge

When I click the link in the Mail app, it opens in the default browser. When it’s opened in Edge, it offers to open it in the PWA instead:

Web app added to Dock with Safari

When I click the link in the Mail app, it opens in the default browser. When it’s opened in Safari, it offers to open it in the web app added to the Dock instead:

But when the web app that was added to the Dock has been interacted with for a while, most notably, when it has been opened directly from the Dock at least once, clicked links open in the web app consistently.

On macOS, PWAs can’t be installed with Firefox.

Conclusion for macOS: deep linking only works reliably when the web app is added to the Dock with Safari.

Windows

Unfortunately, deep linking is not supported on Windows as all clicked links open in the default browser. Just like on macOS, Chrome and Edge offer to open the PWA instead when the PWA was installed through them.

On Windows, PWAs can’t be installed with Firefox.

How to install a PWA with Samsung Internet Browser

I found a report on Reddit this week that pointed to issues with installing PWAs through Samsung Internet Browser on Android.

Some PWAs were flagged as “unsafe” by Google Play Protect, and others, including my What PWA Can Do Today, simply failed silently when trying to install. In that case, a message would appear in the Notification Center, stating that the download of the PWA failed, with no further explanation.

After researching, I found that the installation silently failed when manifest.json contained the share_target member with method set to POST, which is used to share files to the PWA:

"share_target": {
  "action": "/share",
  "method": "POST",
  "enctype": "multipart/form-data",
  "params": {
    "title": "title",
    "text": "text",
    "url": "url",
    "files": [
      {
        "name": "files",
        "accept": [
          "image/png",
          "image/jpg",
          "image/jpeg",
          "image/gif",
          "image/webp",
          ".png",
          ".jpg",
          ".jpeg",
          ".gif",
          ".webp"
        ]
      }
    ]
  }
}

While share_target with method GET does work, which is used to share only text content to the PWA:

"share_target": {
  "action": "/share",
  "method": "GET",
  "params": {
    "title": "title",
    "text": "text",
    "url": "url"
  }
}

After I fixed this, the PWA was still marked as “unsafe” by Google Play Protect, and the user was greeted with a rather scary warning:

Samsung is currently the only browser with its own pipeline for generating a WebAPK. This is a thin wrapper around a web app that integrates it into Android to make it behave like a native Android app. Until recently, a WebAPK was only generated when a PWA was installed through Chrome, which prompted Samsung to build its own pipeline to generate one when a PWA is installed through Samsung Internet Browser.

For some reason, Google Play Protect does not always trust this WebAPK, so it displays the warning dialog above. This doesn’t mean there’s anything (technically) wrong with the PWA or that it’s unsafe, but unfortunately, it will scare users.

The criteria for Google Play Protect to flag the PWA as unsafe may have to do with its reputation. For example, the PWAs of X and Uber are not flagged as unsafe. The X PWA lists its Android native app in its manifest.json file with the android_package_name and the related_applications members. This may signal to Google Play Protect that the X PWA is more trustworthy, although Uber doesn’t have this, so the criteria may be based on reputation/usage alone.

When you tap the “Learn more” link, the “Install anyway” link is displayed, and the PWA can be installed without problems.

How to handle installing in Samsung Internet Browser

To make sure your PWA can be installed through Samsung Internet Browser on Android, make sure your manifest.json doesn’t have share_target with method set to POST. For What PWA Can Do Today, this was a problem because I needed this for the Share Target demo.

I managed to solve this by providing a separate manifest.json for Samsung Internet Browser, which limits the Share Target demo to only text sharing by setting method to GET:

<link rel="manifest" href="/manifest.json">
<script>
  if (/SamsungBrowser\//.test(navigator.userAgent)) {
    document.querySelector('link[rel="manifest"]').setAttribute('href', '/manifest-samsung.json');
  }
</script>

When Samsung Internet Browser is detected by parsing the navigator.userAgent string, the href property of the manifest <link> tag is set to point to the
manifest-samsung.json file, which contains method set to GET.

If your PWA installs without (technical) issues but is still flagged as unsafe by Google Play Protect, the only thing you can basically do is inform your users that there’s nothing wrong with your PWA and they can safely install it.

I updated the Installation demo of What PWA Can Do Today with a screenshot of the warning that you could also use to inform your users.

Style an anchor-positioned element based on its fallback position

In Chrome 143+, you can now style anchor-positioned elements based on the fallback position that is applied to them using anchor queries.

An anchor query is a type of container query that applies styles to an anchor-positioned element based on which fallback position applies to it.

You can check out this video by Una Kravetz on YouTube that explains the concept of anchor queries. This enabled me to finally finish a demo of an animated anchor-positioned menu that needed different animations based on the active fallback position:

As you can see in the video above, the menu expands in the direction of the opposite corner of the screen by expanding the width and height of a container <div> inside the menu.

The default position of the button is the top left corner of the screen, and when it’s clicked, the menu expands towards the bottom left of the screen. To accomplish this effect, the container <div> inside the menu is flex-positioned, and the menu itself is aligned with the bottom right corner of the container <div> so when it expands, the menu itself is revealed from its bottom right corner:

The HTML looks like this:

<div id="menu" popover>
  <div id="menu-container">      
    <ul>
      <li>A menu item</li>
      <li>Another menu item</li>
      <li>A very looooong menu item</li>
    </ul>
  </div>
 </div>

The container <div> has this CSS to accomplish this effect:

#menu-container {
  justify-content: flex-end;
  align-items: flex-end;
}

However, when a fallback position is active, for example when the menu button is in the top right corner, the menu needs to expand towards the bottom left corner of the screen, so this CSS would need to be applied:

#menu-container {
  justify-content: flex-end;
  align-items: flex-start; // changed to flex-start
}

Before anchor queries, this wasn’t possible, as only the @position-try at-rule was available that only allows a limited list of CSS properties. Using anchor queries, we can now apply all CSS properties.

First, we need to define the container element, which will be the menu <div> with container-type:

#menu {
  container-type: anchored;
}

Then, we define an anchor query for the container <div> that applies its styles when the fallback position is active for when the menu button is in the top right corner of the screen:

#menu-container {

  // default styles
  justify-content: flex-end;
  align-items: flex-start;

  // styles for the fallback position "--bl"
  @container anchored(fallback: --bl) {
    justify-content: flex-end;
    align-items: flex-start;
  }
}

Now, when the fallback position “--bl” is active, align-items will have the value flex-start instead of flex-end.

This way, we can define anchor queries for all applicable fallback positions.

In addition to named fallback positions, you can also define anchor queries for fallback positions that use the flip keywords:

#menu {
  position-try-fallbacks: flip-block;
}

#menu-container {

  @container anchored(fallback: flip-block) {
    ...
  }
}

Keep in mind that anchor queries are container queries, so the styles inside these queries apply to an element inside the anchor positioned element and not the anchor positioned element itself, since that element is the container.

So in the case of the example above, the menu is the container, and the anchor query is defined inside the container <div> and not the menu itself. This wasn’t fully clear to me in the beginning.

Check out this codepen for the demo.

PWA Audit: on your way to a great PWA

Do you already have a PWA, but are you running into issues with performance, security, or functionality? Or are you not sure how to make your PWA better?

I can help you by running an audit of your PWA

I will evaluate it on more than 35 criteria and provide you with clear and actionable instructions on how to improve it. No generic stuff that you can get anywhere, but an in-depth quality checkup to get you on your way to a great PWA.

Some of the criteria I will evaluate it on are:

• Installability

• Cross-device and cross-platform compatibility

• Offline support

• Usability

• Effective use of modern web APIs

• Performance

• Security

Your investment in the improvement of your PWA through the audit is €499, excluding VAT (where applicable).

If you want to request an audit or first would like to know more, you can
fill out the form or book a call with me.

Updates to basic-service-worker

I made a few updates to my project basic-service-worker to improve its functionality and make it more robust.

basic-service-worker is a, well, basic service worker that makes your web app work offline and that updates as soon as possible when there are changes in your web app.

A common issue with service workers is that they don’t always update immediately when there are changes. basic-service-worker makes sure your service worker updates whenever there are changes and the user navigates to another page.

This works for 99.9% of the time, but in the rare event that it doesn’t work,
basic-service-worker wouldn’t retry, and this is now fixed. Now, when basic-service-worker detects that the newly installed service worker is not activated, it will retry until it is.

Usage in single-page apps

Another issue was that the page needed to be fully reloaded for the newly installed service worker to be activated, which means that this wouldn’t work in single-page apps where navigations do not result in full page reloads.

It now uses the Navigation API to detect single-page app navigations. When there is a newly installed service worker waiting to be activated, it will replace a single-page app navigation with a full page navigation, so the new service worker is activated.

Of course, this may not always be the behavior you want, so in that case you can simply remove this event handler, so the service worker will only be activated when the user restarts the app or does a full page reload.

Check the readme in the repo on Github for details.

Customisable <select> now in Safari Tech Preview 238

After Chrome, Safari has now also implemented the fully customisable <select> element in Tech Preview 238. This means we can now fully style this element, which was barely possible before.

To opt-in to the new customizable <select> add this to your CSS:

select,
::picker(select) {
  appearance: base-select;
}

This will add the new ::picker(select) pseudo-element that represents the popover containing the <option> elements.

With default styling, the <select> with appearance: base-select doesn’t look very different from the regular version, but things get interesting when we customize it further.

We can add a <button> that will open the select and inside it, we can place a <selectedcontent> element, which will contain the currently selected <option>. Inside this <button> we can place a custom indicator to indicate the open and closed state of the <select>. The default arrow indicator can be hidden with:

::picker-icon {
  display: none;
}

The <select> could now look something like this:

<select>
  
  <!-- button to open and close the select -->
  <button>
    
    <!-- element where the selected option will be placed -->
    <selectedcontent></selectedcontent>

    <!-- custom arrow indicator -->
    <span class="arrow"></span>
  </button>

  <!-- options -->
  <option value="1">
    Option 1
  </option>
  <option value="2">
    Option 2
  </option>
  <option value="3">
    Option 3
  </option>
  <option value="4">
    Option 4
  </option>
</select>

Keep in mind that only the contents of the selected <option> will be placed inside <selectedcontent> and not the <option> element itself. This is important to know when you want to style the contents of <selectedcontent>.

In the screenshot below, the second <option> is selected:

By default, a checkmark is shown in front of the selected <option>:

If needed, you can hide this checkmark with:

option::checkmark {
  display: none;
}

Adding HTML elements to <option>
In addition to text, you can now also add other HTML elements to <option>. Here’s an example of a currency picker using flag images that I adapted from an example by Una Kravetz:

You can now simply accomplish this by placing the needed HTML elements inside <option> and style them with CSS:

<option value="eur">
  <img src="europe.png">
  <div class="currency">
    <div class="currency-short">EUR</div>
    <div class="currency-long">Euro</div>
  </div>
  <div class="symbol">€</div>
</option>

option {
  .currency {
    flex-grow: 1;
  }
  
  .currency-long {
    color: #595959;
  }
  
  .symbol {
    justify-self: end;
  }
}

Standing on the shoulders of giants
Internally, the customizable <select> uses Anchor Positioning to anchor the ::picker(select) pseudo-element to it and the Popover API to position it in the top layer, above all other elements on the page.

This is important to know if you want to animate the opening and closing of the picker, which is now possible as well!

Let’s implement a nice sliding transition where the picker’s height is animated and the <option> elements inside it slide down. To do this, we can place a <div> around the <option> elements and then give this <div> the following CSS:

display: flex;
flex-direction: column;
justify-content: flex-end;

which aligns the <option> elements to the bottom so they’ll slide down when the picker is opened by expanding its height.

We can do this by simply wrapping the <option> elements inside a <div> because any content that is placed inside the <select> outside the <button> will be automatically placed inside ::picker(select):

<div class="options">
  <option value="1">
    Option 1
  </option>
  <option value="2">
    Option 2
  </option>
</div>

Even though the <div> will be placed inside ::picker(select), it needs to be styled with select .options and not select::picker(select) .options so it will look like this:

select .options {
  display: flex;
  flex-direction: column;
  justify-content: flex-end;
}

We will then define the styles for ::picker(select) by setting its height to 0 and defining the transitions:

::picker(select) {
  height: 0;
  min-height: 0;
  transition-property: height, overlay, display;
  transition-duration: .3s;
  transition-behavior: allow-discrete;
}

In addition to height, we also need to set overlay and display as transition properties because the picker will not have display by default and it will be moved to the top layer when shown. For that reason, we need to transition these properties as well, otherwise the transition will be instant.

To indicate we want to allow transitioning of overlay and display, which are discrete properties, we set transition-behavior to allow-discrete. The property min-height: 0 is needed for a smooth transition.

Since the picker doesn’t have display when it’s not shown, we need to define a @starting-style rule for it because only elements that have display can be animated. This rule defines the property and value we want to transition from, in our case height: 0:

@starting-style {
  ::picker(select) {
    height: 0;
    min-height: 0;
  }
}

Finally, we need to define the property and value we want to transition to, in our case the height of the picker when the <select> is open:

select:open::picker(select) {
  height: auto;
}

To enable transitioning to a keyword like auto, we need to set this CSS as well:

:root {
  interpolate-size: allow-keywords; 
}

And with that, we now have a smooth sliding <select>! 💪

I created a demo on codepen.io, but unfortunately, Codepen doesn’t work for some reason (bug) in Safari Tech Preview 238. If you want to view it there, you can copy the HTML and CSS to a local HTML page and run it from there for now 🤷‍♂️

I also had to apply a small Safari-only fix to this demo with the sliding opening and closing. When the <select> is opened, the options are correctly displayed below the button, but when closing, the options slide up to the top of the button, covering it:

By adding margin-top to the picker, this is solved:

 @supports (font: -apple-system-body) {
    &:not(:open)::picker(select) {
      margin-top: 38px;
    }
  }

The @supports block makes sure this is only applied in Safari.

Accessible arrow navigation without JavaScript with focusgroup

In Chrome 146 with Experimental Web Features enabled (or an origin trial), you can now try the focusgroup attribute. This is a declarative way to add keyboard arrow-key navigation to widgets like toolbars, tablists, menus, listboxes, etc., without the need for JavaScript.

Before, to implement keyboard navigation with the arrow keys for these widgets, you would need to write a lot of boilerplate code. focusgroup aims to solve all this.

The attribute takes a behavior token and three optional modifier tokens:

focusgroup="[behavior] [modifier1] [modifier2] [modifier3]"

The behavior token defines the widget pattern and can take the values:

• toolbar

• tablist

• radiogroup

• listbox

• menu

• menubar

• none

The first modifier defines the navigation direction and can take the values block (vertical) or inline (horizontal). So a widget with the modifier inline can be navigated with the left and right arrow keys, and a widget with the modifier block can be navigated with the up and down arrow keys.

The second modifier defines the wrapping behavior and can take the values wrap (allow navigation to wrap around) or nowrap (prevent navigation from wrapping). When set to wrap, the navigation will wrap around to the next item in the group, so when the last item is reached, the focus will move to the first item in the group and vice versa. When set to nowrap, the navigation will stop at the last item, and the focus will remain on the last item.

The third modifier determines whether the last-focused item in a group regains focus on re-entry with Tab. Use the nomemory modifier to disable it. This is mainly used in combination with the focusgroupstart attribute (see below).

Any modifier can be omitted if you only want to specify certain ones. By default, toolbar, tablist, and menubar have the modifier inline, menu has the modifier block, and tablist, menu, and menubar have the modifier wrap.

focusgroupstart and nomemory

When a widget with focusgroup is entered with TAB, the first focusable element will get focus, or the element with the focusgroupstart attribute. By default, this only applies when the widget is entered for the first time.

When you focus another element in this group with the arrow keys, then TAB to another group, and then go back to this group with shift+TAB, the last focused element will get focus again, not the element with focusgroupstart.

You can disable this memory behavior with the nomemory modifier. With that modifier, the element with focusgroupstart will always get focus when the widget is entered with TAB or shift+TAB, even if another element was last focused when the widget was exited.

Nested groups

You can also nest elements with focusgroup, where each group has its own scope. A nested focusgroup automatically opts out of its ancestor’s arrow navigation, and you can use TAB and shift+TAB to move between the groups.

Here’s an example of a menubar with horizontal navigation through the menubar behavior, where each button can open a submenu, which has vertical navigation through the menu behavior.:

<!-- menubar with horizontal navigation -->
<ul focusgroup="menubar">
  <li>
    <button type="button" popovertarget="aboutpop">About</button>
    
    <!-- submenu with vertical navigation -->
    <ul focusgroup="menu" autofocus id="aboutpop" popover>
      <li><a tabindex="0">Overview</a></li>
      <li><a tabindex="0">Administration</a></li>
    </ul>

  </li>
  <li>
    <button type="button" popovertarget="admitpop">Admissions</button>
    
    <!-- submenu with vertical navigation -->
    <ul focusgroup="menu" autofocus id="admitpop" popover>
      <li><a tabindex="0">Apply</a></li>
      <li>
        <button type="button" popovertarget="tuitpop">Tuition</button>
        
        <!-- submenu with vertical navigation -->
        <ul focusgroup="menu" autofocus id="tuitpop" popover>
          <li><a tabindex="0">Undergraduate</a></li>
          <li><a tabindex="0">Graduate</a></li>
        </ul>

      </li>
      <li><a tabindex="0">Visit</a></li>
    </ul>
  </li>
</ul>    
    

Excluding elements with focusgroup=”none”

You can exclude elements in a focusgroup by setting focusgroup=”none” on them. This will make an element unreachable by arrow navigation, but you can still use TAB and shift+TAB to access it.

In the example below, the second button is not reachable with the arrow keys:

<div focusgroup="toolbar wrap">
  <button>A</button>
  <button focusgroup="none">(Not arrow reachable)</button>
  <button>B</button>
</div>    
    

Check the demo on What PWA Can Do Today in Chrome 146+ and definitely read the article on the Chrome Developers Blog for more details.

PWA Audit: on your way to a great PWA

Do you already have a PWA, but are you running into issues with performance, security, or functionality? Or are you not sure how to make your PWA better?

I can help you by running an audit of your PWA

I will evaluate it on more than 35 criteria and provide you with clear and actionable instructions on how to improve it. No generic stuff that you can get anywhere, but an in-depth quality checkup to get you on your way to a great PWA.

Some of the criteria I will evaluate it on are:

• Installability

• Cross-device and cross-platform compatibility

• Offline support

• Usability

• Effective use of modern web APIs

• Performance

• Security

Your investment in the improvement of your PWA through the audit is €499, excluding VAT (where applicable).

If you want to request an audit or first would like to know more, you can
fill out the form or book a call with me.

Better title attributes with interestfor

Chromium-based browsers now support Interest Invokers, which you can compare to Invoker Commands. But instead of clicking, they invoke an action when the user hovers over an element. Think of popovers, but then they are opened when a button is hovered instead of clicked.

For example, you can let a button open a popover on hover with the interestfor attribute which holds the id of the popover as its value:

<button type="button" interestfor="title-popover">Hover me</button>

<div id="title-popover" popover="hint">Here I am!</div>

The interestfor attribute also implicitly anchors the popover to the button, so you can use anchor positioning to position the popover:

#title-popover {
  position-area: bottom span-right;
  position-try-fallbacks: flip-block, flip-inline, flip-block flip-inline;
}

Of course, you can use the native title attribute to show a title on hover, but this way, you can style the title and configure the time it takes before the popover is shown and hidden with CSS:

[interestfor] {
  /* delay before interest is shown */
  interest-delay-start: 200ms;

  /* delay before interest is hidden */
  interest-delay-end: 200ms;
}

The API also exposed events when the element with interestfor is hovered and unhovered; respectively, “interest” and “loseinterest”. Just like with the Invoker Commands API, the event is dispatched on the target of the invoker and not the invoker (button) itself, so you only need to set an event on the popover and not an event on each button.

In the demo I created on codepen, I use the “interest” event to read the data-title attribute of the hovered button to show its value (the title of the button) in the popover.

Check the demo here.

check sw update in spa with navigation api

title with interestfor

geolocation element, usermedia element

focusgroup

datatransfer

share_target

https://github.com/danielsakhapov/declarative-scroll-commands-for-html-explainer

clipboardchange

transform in anchor positioning https://codepen.io/bramus/pen/pvyrmWv

A declarative install element

In Modern Web Weekly #65 and #59, I wrote about the Web Install API (now stable in Chrome 144!) that adds the install method to navigator and that enables web apps to be installed as PWAs, also from other domains.

Chrome 147 now also introduces an origin trial for the declarative <install> element for this.

At the time of writing, the original trial hasn’t been launched yet, but you can already enable it in Chrome 147 at chrome://flags/#web-app-installation-api

The declarative <install> renders a button. When the app is not installed, it will show and install icon and the text “Install”. When the app is installed, it will show a launch icon and the text “Launch”.

When used without attributes, it will install the current web app:

<install>
  [optional fallback content]
</install>

With the attributes installurl and manifestid, it can be used to install web apps from other domains:

<install installurl="https://whatpwacando.today/"
         manifestid="https://whatpwacando.today/pwa-today">
  [optional fallback content]
</install>

installurl specifies the URL of the web app to install. If unspecified, the current web app will be installed.

manifestid specifies the computed id of the web app to install. If unspecified, the manifest.json file of the web app at installurl must have a custom id defined. If specified, it must match the computed id of the web app to be installed. You can find the computed app ID of your web app in Chrome Devtools in the Application tab > Manifest > Identity.

When the web app to be installed, either the current one or another one specified by installurl, is not yet installed, the button looks like this:

After the app has been installed, it will look like this:

This makes it very easy for installed PWAs that are opened in a browser to indicate that it was already installed. This is especially nice for PWA app stores that offer functionality to install web apps on other domains. These can now automatically show a “Launch” button instead of an “Install” button.

Just like with the Web Install API, when the current web app is installed and it has screenshots defined in manifest.json, the install dialog will show the enhanced installation dialog. But when a web app at another domain is installed, it will show the simple installation dialog, even if that web app has screenshots defined in its manifest.json.

For the Web Install API, this will soon be fixed so I expect this to be the case for the install element as well.

As soon as the original trial is launched, I will register and you can view the demo of <install> at https://whatpwacando.today/installation in Chrome 147.

If you enable the flag at chrome://flags/#web-app-installation-api you can already view it right now.

How to make sure push notifications open your PWA on Android

I recently worked on a bug where an installed PWA was not opened when a push notification was sent to it and the user tapped it. Instead, the default browser was opened, despite the fact that the notificationclick event handler was correct.

Here’s a condensed version of the handler I use:

const notificationClickHandler = async (e) => {
  const {notification} = e;
  const {data} = notification;

  notification.close();

  e.waitUntil(clients.openWindow(data.url))
};

The notification property of NotificationEvent contains the data that was sent as part of the push notification in its data property. This in turn has a url property that points to the URL that must be opened in the PWA when it’s installed.

This worked fine on iOS but on Android, the URL was opened in the default brower instead of the PWA.

After examining, I found that the manifest.json file of the PWA didn’t have a scope member.

scope defines the top-level URL path that contains the web app’s pages and subdirectories. It effectively defines the scope of the service worker, in the sense that only URLs within the scope will be opened in the app, and any URLs outside it will be opened in the default browser or in-app browser when applicable.

The spec states that when scope is not defined, it will be set to the start_url value after removing its filename, query, and fragment, but on Android this apparently doesn’t apply when a push notification is clicked.

I always specify a scope out of habit so I wasn’t even aware of this issue, but this fixed the issue immediately.

Bottom line: always set scope in your manifest.json.

PWA Audit: on your way to a great PWA

Do you already have a PWA, but are you running into issues with performance, security, or functionality? Or are you not sure how to make your PWA better?

I can help you by running an audit of your PWA

I will evaluate it on more than 35 criteria and provide you with clear and actionable instructions on how to improve it. No generic stuff that you can get anywhere, but an in-depth quality checkup to get you on your way to a great PWA.

Some of the criteria I will evaluate it on are:

• Installability

• Cross-device and cross-platform compatibility

• Offline support

• Usability

• Effective use of modern web APIs

• Performance

• Security

Your investment in the improvement of your PWA through the audit is €499, excluding VAT (where applicable).

If you want to request an audit or first would like to know more, you can
fill out the form or book a call with me.

The importance of keeping the service worker alive with event.waitUntil()

Another bug was reported to me this week that initially left me puzzled.

A user reported that the notifications demo of What PWA Can Do Today never showed a badge on the app icon when a push notification was received. This happened to him since iOS 17.4 on the same model iPhone I have myself.

My initial reply was that he probably had badges not enabled in the Notifications settings for the PWA:

But this was not the case, so what was going on? Same device, same settings, same iOS version, yet it worked on my device but not his…

Some context first; the handler for the push event shows the notification and then updates the badge when the app is not running. It keeps a count of the unread messages in IndexedDB and when a new push notification arrives, it increments the number of unread notifications and shows the number with a call to navigator.setAppBadge(count).

I examined the whole flow multiple times and it consistently worked on my device so I didn’t know what was wrong. Until I took a closer look.

Here’s a condensed version of the handler for the push event:

const pushHandler = e => {
  e.waitUntil((async () => {
    const data = e.data.json();
    const { title, message, interaction, url } = data;

    const options = {
      body: message,
      icon: '/src/img/icons/icon-512x512.png',
      
      ...
    };

    await self.registration.showNotification(title, options);

    const activeClients = await hasActiveClients();
    if (!activeClients) {
      updateBadges();
    }
  })().catch(err => sendMessage(err)));
};

And this is the updateBadges function that updates the number of unread messages and shows the badge:

const updateBadges = async (inc = 1) => {
  const store = await openStore(IDBConfig.stores.badgeStore, 'readwrite');
  const result = await store.get('num') || {num: 'num', count: 0};
  const numBadges = result.count;
  const count = Math.max(0, numBadges + inc);

  await store.put({num: 'num', count});

  navigator.setAppBadge(count);
};

The updateBadges function uses e.waitUntil to make sure the service worker stays active until the Promise that it receives as its argument resolves.

Can you already guess where this is going?

Upon a closer look I realized I called updateBadges without await.

And updateBadges in turn called navigator.setAppBadge(count) without
await as well!

So this could mean that the anonymous async function that was passed to
e.waitUntil could resolve before updateBadges finished, causing the service worker to be terminated before the badge could be shown.

But it worked on my device without await!

Since the await really needed to be there in both places I added them and, lo and behold, it started working for the bug reporter. 💪

Here are the updated versions:

const pushHandler = e => {
  e.waitUntil((async () => {
    const data = e.data.json();
    const { title, message, interaction, url } = data;

    const options = {
      body: message,
      icon: '/src/img/icons/icon-512x512.png',
      
      ...
    };

    await self.registration.showNotification(title, options);

    const activeClients = await hasActiveClients();
    if (!activeClients) {
      await updateBadges(); // await added
    }
  })().catch(err => sendMessage(err)));
};

const updateBadges = async (inc = 1) => {
  const store = await openStore(IDBConfig.stores.badgeStore, 'readwrite');
  const result = await store.get('num') || {num: 'num', count: 0};
  const numBadges = result.count;
  const count = Math.max(0, numBadges + inc);

  await store.put({num: 'num', count});

  await navigator.setAppBadge(count);  // await added
};

Bottom line: in any event handler in the service worker that uses e.waitUntil (install, activate, push, sync, notificationclick), always make sure that the Promise doesn’t resolve untill all work is done.

Add await to all calls to async functions. If you are using .then with Promises, make sure to return them:

e.waitUntil(
  foo().then(() => {
    return bar();
  })
  .then(...)
);

I initially missed this because it worked without issues on my device, but service worker timing may differ between devices, so you can never guarantee that it will work properly unless you properly await or return Promises in e.waitUntil.

Can I compress it? Yes, you can!

If your web app needs to compress and decompress data, you no longer need an external library. The Compression Streams API is now available in all browsers and enables your app to (de)compress data using GZIP a…

Read more

Web Install API now in Chrome 143

Chrome 143 now supports the Web Install API as an origin trial.

This API provides a declarative way of installing web apps through navigator.install().

When it’s called without arguments, it installs the current web app (the one on the domain where this method is called from:

// installs the current web app
navigator.instal…

Read more

Better drag-and-drop with Observer

If you’ve ever built drag-and-drop functionality, you know that this can be tricky to implement and can result in brittle code that’s hard to follow.

You need to implement a handler for the mousemove event, but this handler should only be called when it’s preceded by a mousedown event on the element that needs to be drag…

Read more

CMA designates Apple as having Strategic Market Status

The Open Web Advocacy (OWA) reports that the UK’s Competition and Markets Authority (CMA) has officially designated Apple as having Strategic Market Status (SMS).

SMS means that Apple “has substantial and entrenched market power and a position of strategic significance”. It means that Apple’s iOS plat…

Read more

What We Need To Make Web Apps A Success

We don’t need to wait for Apple to jump on board

Here’s a fun experiment: put your phone in flight mode so there’s no internet connection, and make sure it’s not connected to wifi either.

Read more

Taming the on-screen keyboard with interactive-widget

In Chromium-based browsers, you can now control how the layout of the page behaves when the on-screen keyboard is shown on mobile devices.

Different browsers behave differently when the on-screen keyboard is shown. They can resize the Layout Viewport, the Visual Viewport,…

Read more

iOS 26 for PWAs: The Good, the Bad, and the Ugly

iOS 26 has arrived, and of course, I combed through the release notes and did a lot of testing to see what has changed for PWA support.

In short, there is unfortunately not too much to be excited about, but let’s start with the good news.

Read more

Install your PWA from anywhere

The dev trial for Microsoft’s proposal for the Web Install UI is now live.

This API adds the install method to navigator to install a web app on the user’s device. When navigator.install() is called without any arguments, the browser will prompt to install the current web app, meaning the web app ho…

Read more

Web apps added to the Dock on macOS, use scope

On macOS, you can now add web apps to the Dock and these apps will behave like PWAs. If you have a manifest, it will take the icons and other configurations from there, but you can also “install” web apps that don’t have a manifest and/or service worker.

Read more

The horror of PWA splash screens on iPadOS

When you build a PWA for iOS or iPadOS, you will need to provide so-called splash screen images. This is the image that is displayed while the app is starting up.

Usually, this will be the logo of the app, centered on the screen, but you can really use any kind of image you want.

Read more

Modern Web Weekly chat is now available 🎉

If you’re a paid subscriber, you now have access to the Modern Web Weekly chat.

This is a conversation space exclusively for paid subscribers—kind of like a group chat or live hangout. I’ll post questions and updates that come my way, and you can jump into the discussion.

Read more

This is a conversation space exclusively for paid subscribers—kind of like a group chat or live hangout. I’ll post questions and updates that come my way, and you can jump into the discussion.

I will do my best to answer all your questions, and occasi…

Read more

How screenshots for the install dialog of PWAs really work

If you have created an installable web app, you really should include screenshots in the manifest.json file to enable the enhanced install dialog. This dialog is available in Chrome on desktop and Android and shows a native app-like install dialog that shows the …

Read more

Declarative Web Push in Safari on macOS

Safari 18.5 on macOS now supports Declarative Web Push for both web apps running in Safari and web apps added to the Dock.

In Modern Web Weekly #51, I showed the payload that is needed for a notification to be handled declaratively on iOS (and now also macOS):

Read more

Better event handling with Observers

If you have ever worked with a library like RxJS, you will know how well its declarative API works for composing event handlers. Without such a library, something like drag-and-drop can be complicated because it requires nested event handlers and hard-to-follow callback chains.

For exam…

Read more