Share

Modern Web Weekly #74

Did you ever wish you could serve some parts of your HTML earlier or later than others?

Imagine your web app has a large dropdown menu at the top of the page. Since HTML is delivered in a top-to-bottom fashion, the HTML after this menu won’t be available until the HTML for the menu is downloaded and parsed, but the user won’t be able to use the menu until the page becomes interactive. The menu HTML might as well be delivered later so the rest of the page is available sooner.

Or how about a single-page app with a page shell. This shell is delivered in the first request, and then JavaScript is needed to plug in all other HTML.

Wouldn’t it be nice if you could do this in one request and choose the order in which the HTML parts are delivered, regardless of their order in the source document?

Well, now you can! 💪

Out-of-order streaming HTML

There have already been some experiments with out-of-order streaming HTML that use Declarative Shadow DOM and <slot> elements to stream HTML out of order:

<div>
  <template shadowrootmode="open">
    <header>Header</header>
    <main>
      <slot name="content"></slot>
    </main>
    <footer>Footer</footer>
  </template>

  <div slot="content">
    This div will be rendered inside the slot above without JavaScript.
  </div>
</div>

In the above example, <slot name=”content”></slot> will be replaced with <div slot=”content”> as soon as it’s available in the browser, without any JavaScript.

This is a very neat feature, but it only works with Shadow DOM.

In Chrome 148, with experimental web features enabled (visit chrome://flags/#enable-experimental-web-platform-features), you can now use Declarative Partial Updates that enable web apps to stream HTML into parts of the document, regardless of the order in which it’s delivered by the server.

For example, web apps can now download the most important HTML first, even when this is not at the top of the HTML document.

How it works

Streaming out-of-order HTML is called “patching”. It means you can interleave content for multiple locations in an HTML document in one HTML stream, and the content doesn’t have to be streamed in the order in which it’s located in the document, hence “out-of-order streaming”.

It works by putting processing instructions in an HTML document that function as the insertion points where the content will be streamed into:

<div>
  <?marker name="content">
</div>

<template for="content">
  <p>Here is the content that will be inserted.</p>
</template>

In the above example, the processing instruction <?marker name=”content”> will be replaced with the contents of the <template>.

The template will look up the processing instruction with a name attribute that corresponds to its for attribute and replace it with its contents.

The above example will end up like this:

<div>
  <p>Here is the content that will be inserted.</p>
</div>

In addition to <?marker>, you can also use the <?start> and <?end> markers that enable you to add temporary content that will be displayed until it’s replaced with the contents of the corresponding <template> element:

<div>
  <?start name="list">
  Loading…
  <?end>
</div>

...

<template for="list">
  <ul>
    <li>Item 1</li>
    <li>Item 2</li>
    <li>Item 3</li>
  </ul>
</template>

In this example, “Loading…” is displayed inside the <div> until it’s replaced with the list inside the <template> element.

This would enable you to first stream a skeleton HTML page with a loading screen, and after that you could append the list HTML, which is maybe fetched from an external API that takes longer to load.

Normally, you would first serve the app shell, then fetch the list with the API data in a separate request, and then use JavaScript to insert the list HTML. With patching, you can do everything in a single HTML response without having to use JavaScript to insert the list.

You can even add processing instructions in the templates to enable updates in multiple steps. Imagine that the list in the previous example is loaded in chunks instead of fully in one request. By including processing instructions in the templates, you can now continuously update the list:

<div>
  <?start name="list">
  Loading…
  <?end>
</div>

...

<template for="list">
  <ul>
    <li>Item 1</li>
    <?marker name="items">
  </ul>
</template>

<template for="items">
  <li>Item 2</li>
  <li>Item 3</li>
  <?marker name="items">
</template>

<template for="items">
  <li>Item 4</li>
  <?marker name="items">
</template>

This results in the following HTML:

<div>
  <ul>
    <li>Item 1</li>
    <li>Item 2</li>
    <li>Item 3</li>
    <li>Item 4</li>
    <?marker name="items">
  </ul>
</div>

This is huuuuge…

…and there’s even more…

Streaming HTML in single-page apps

Single-page apps (SPA) have long been the solution to make web apps feel like real apps, because they only update the changed content when the user navigates to another page, without a full page reload.

The downside of this is that SPAs can’t use the browser’s streaming parser. When a browser loads a web page, it can do so in a streaming fashion. This means that it can already start rendering the page while it’s still downloading; it doesn’t have to wait for the page to be fully loaded before it can start rendering content.

SPAs typically load a skeleton HTML page and then update the content with DOM manipulation using JavaScript. Any content that is inserted into the DOM after the page has been served by the server cannot use the browser’s streaming parser. It has to wait for all content to be ready before it can start to render it when it’s inserted using JavaScript (for example, with innerHTML).

Until now…

New streaming methods

In addition to existing methods like setHTML, setHTMLUnsafe and the innerHTML and outerHTML setters, this proposal adds streaming methods like streamHTML, streamHTMLUnsafe, streamAppendHTML etc.

This enables SPAs to stream HTML into the insertion points marked by processing instructions using JavaScript. This means that instead of using innerHTML to update content, your SPA can now do this:

const response = await fetch('/path/to/content.html');
const html = await response.text();

const writer = document.body.streamAppendHTMLUnsafe().getWriter();

await writer.write(html);
await writer.close();

Note that in this example, the content is added to the <body> element.

When you use <template> elements and markers, you don’t even need to get a reference to the insertion point with JavaScript anymore. You can just define the insertion point of the SPA content with a marker:

<main id="app">
  <section class="page">
    <?marker name="content">
  </section>
</main>

And then you can simply append the <template> to the bottom of the page:

<template for="content">
<?start name="content">
  <p>Homepage content</p>
<?end>
</template>

Since you defined a marker and added this template to the bottom of the page, the browser will now take care of inserting the content in the right place. Also note that this template contains <?start> and <?end> markers, and the resulting HTML will be this:

<main id="app">
  <section class="page">
    <?start name="content">
      <p>Homepage content</p>
    <?end>
  </section>
</main>

This ensures that the processing instructions are ready for when the user navigates to another page. If each partial contains these processing instructions, you can always just add the page HTML to the bottom of the page, and the browser will then insert it in the right location while replacing the contents of the previous page.

And there’s even more good news…

Cross-browser support is coming soon

Not only can you already use this in Chromium-based browsers from version 148 with experimental web features enabled, but the WebKit team (Safari) has announced they will support this and the Firefox team has a positive position on this feature.

This means this feature could be supported in all major browsers soon! 💪

Demo

I created a demo SPA that uses the technique described above to update the page content. It defines markers in the HTML where the page content is to be inserted, and each page partial HTML template contains new markers where the content of the next page is to be inserted. All page templates are simply added to the bottom of the page, and the browser takes care of the rest.

Check out the demo and the source code.

Notice that the demo uses the streamAppendHTMLUnsafe() method to stream the content. The Unsafe variant is required to preserve the <template> element in the HTML that is inserted. Using streamAppendHTML()results in empty HTML and doesn’t work.

Also notice that the streaming methods are required to use templates and markers. When you use non-streaming methods, like appendHTMLUnsafe() for example, the parent of the template when it is parsed is an intermediate document fragment, and the patching happens "in place" inside the fragment instead of in the insertion point indicated by the markers.

The /list route of the demo demonstrates a list that is updated in chunks. The demo just uses setTimeout() to simulate a response that delivers the chunks, but you can probably imagine how this would work in a production scenario where the content is delivered in real chunks.

Also make sure to check out the Chrome developers article and the accompanying demo, which demonstrates the out-of-order streaming very well.

This is a very promising feature that will truly revolutionize how HTML is delivered. When more browsers support this, you will hear it here first!

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

Share

Modern Web Weekly #73

The File System Access API brings access to the native file system to web apps. The API is currently only supported in Chromium-based browsers on desktop, but the Origin Private File System is now supported across all browsers on desktop, Android, and iOS.

The Origin Private File System (OPFS) is a high-performance virtual file system that’s accessible only to the origin the web app (PWA) runs on. You can work with it like any file system, which means that you can create and delete directories and files, and also edit files. It uses the same interfaces that the File System Access API uses, like FileSystemDirectoryHandle and FileSystemFileHandle. These are the interfaces that give access to a directory and fil,e respectively.

OPFS is a virtual file system, which means that the directories and files that are created do not correspond to actual directories and files on the user's device. They can be saved inside a database or a single file; this is up to the browser to implement.

An implication of this is that the user doesn’t have to give permission repeatedly to the web app to get access to the directories and files, as is the case with the File System Access API, which does have access to the actual file system of the user's device.

Just like IndexedDB, localStorage, and sessionStorage, the OPFS is subject to storage quota restrictions. This means that there is a maximum to the amount of data that can be stored (although this will usually be enough for most use-cases) and that the OPFS will be cleared when the user clears all browsing data.

Your web app gets access to OPFS through the StorageManager, which is located in the navigator.storage property. StorageManager is also responsible for managing storage permissions and estimating available storage through its persist() and estimate() methods.

Access to OPFS is obtained through the getDirectory() method:

const opfsRoot = await navigator.storage.getDirectory();

The returned object opfsRoot is a FileSystemDirectoryHandle. In the root, you can create a directory with the getDirectoryHandle() method:

const directoryHandle = await opfsRoot
    .getDirectoryHandle('test_dir', {create: true});

getDirectoryHandle() is used to get a reference to a directory inside OPFS, but by passing {create: true} as the second argument, the directory is created. If the directory already exists, an error is thrown.

To create a file, use the getFileHandle() method:

const fileHandle = await opfsRoot.getfileHandle('test.txt', {create: true});

Just like getDirectoryHandle(), getFileHandle() gets a reference to a file or creates it when {create: true} is passed as the second argument. The above example creates a file inside the OPFS root. To create a file inside a specific folder, you need to call getFileHandle() on the FileSystemDirectoryHandle that references the directory you want to create it in:

// create a directory in OPFS
const directoryHandle = await opfsRoot
    .getDirectoryHandle('test_dir', {create: true});

// create a file in the directory that was just created
// "getFileHandle()" is called on "directoryHandle"
const fileHandle = await directoryHandle
    .getfileHandle('test.txt', {create: true});

If you need to get a handle to an existing file, simply leave out {create: true}. To get the actual file the handle points to, use the getFile() method:

// handle to existing file
const fileHandle = await directoryHandle.getfileHandle('test.txt');

// the actual File object
const file = await fileHandle.getFile();

// get the contents of the file as text
const contents = await.file.text();

To save data to the file, call the createWritable() method of the file handle, which returns a FileSystemWritableFileStream:

const contents = 'This is a test file';
const writable = await fileHandle.createWritable();

// write the contents of the file to the stream.
await writable.write(contents);

// close the stream, the contents are now persisted to the file
await writable.close();

For older browsers that don’t support the FileSystemWritableFileStream, we need to use the synchronous file handle called FileSystemSyncAccessHandle, which has a synchronous write() method. But these synchronous methods are only available inside Web Workers. The reason for this is that synchronous methods can block the main thread, and Web Workers can’t, so synchronous methods are only allowed inside Web Workers.

To get a FileSystemSyncAccessHandle, call the createSyncAccessHandle on the file handle:

const fileHandle = await directoryHandle.getfileHandle('test.txt');

// get synchronous file handle
const syncAccessHandle = await fileHandle.createSyncAccessHandle();

Here’s how you would then save contents to the file:

const syncAccessHandle = await fileHandle.createSyncAccessHandle();
const encoder = new TextEncoder();
const writeBuffer = encoder.encode(contents);
const writeSize = syncAccessHandle.write(writeBuffer, { "at" : 0 });

// truncate the file to the size of the data, otherwise if the new data
// is smaller than any old data, parts of the old data will 
// stay in the file
syncAccessHandle.truncate(writeSize);

// save changes to disk
syncAccessHandle.flush();

// close FileSystemSyncAccessHandle when done
syncAccessHandle.close();

From this example, you can see that to save data to a file synchronously, we always need to have the file handle that points to the file we want to save data to. Since this needs to be done inside a Web Worker, the file handle needs to be sent to the Worker using the postMessage() method. When this file handle is sent, it needs to be serialized, but an additional issue is that some older browsers don’t support serializing FileSystemFileHandle.

A possible workaround for this is to not send the actual file handle to the Web Worker, but the path to the file we want to save data to. We can do this by calling the resolve() method of FileSystemDirectoryHandle.

For example, if a file inside OPFS is located at test_dir/nested_dir/text.txt, calling resolve() on the root directory with the file handle as its argument will return an array with all directory names in the path and the file name:

// "handle" is the file handle of the file located at 
// test_dir/nested_dir/test.txt
const path = opfsRoot.resolve(handle);

console.log(path); // ['test_dir', 'nested_dir', 'test.txt']

You can then use this array to first get the handle to test_dir from the OPFS root, then use that directory handle to get the handle to nested_dir and then use that handle to get the file handle to test.txt.

Inside the Web Worker, you would then use something like this to save the data to the file:

self.addEventListener('message', async ({data}) => {
  // get the path to the file and the contents to save to it
  const {path, contents} = data;

  // get the OPFS root directory
  const root = await navigator.storage.getDirectory();

  // get the file name (last element in the "path" array)
  const fileName = path.pop();
    
  let nestedDir = root;

  // recursively get the handle to the directory the file is in
  for(const dirPath of path) {
    nestedDir = await nestedDir.getDirectoryHandle(dirPath);
  }

  // get the handle to the file we want to save to
  const file = await nestedDir.getFileHandle(fileName);

  // get the sync file handle
  const syncAccessHandle = await file.createSyncAccessHandle();
  const encoder = new TextEncoder();
  const writeBuffer = encoder.encode(contents);
  const writeSize = accessHandle.write(writeBuffer, { "at" : 0 });
    
  // truncate the file to the size of the data, otherwise if the new data
  // is smaller than any old data, parts of the old data will 
  // stay in the file
  syncAccessHandle.truncate(writeSize);

  // save changes to disk
  syncAccessHandle.flush();

  // close FileSystemSyncAccessHandle when done
  syncAccessHandle.close();
});

Both directories and files can be removed with the remove() method of the directory or file handle. To remove a folder and all its subfolders pass {recursive: true}:

The remove() method is currently implemented in Chrome. In Safari, you have to use removeEntry with the name of the directory or file.

directoryHandle.removeEntry('test.txt');

Check What PWA Can Do Today for a demo of both the File System Access API and the Origin Private File System.

Persistent storage for PWAs

In addition to OPFS, web apps can store data in the user’s browser in various ways. You’re probably familiar with cookies that can store simple data, but web apps can also use IndexedDB and Cache Storage to store larger, structured data. These two mechanisms are part of the Storage API. In addition to these, there are also localStorage and sessionStorage that are part of the Web Storage API.

The problem is that the browser may delete this data when a user hasn’t used the app for a certain time. This is especially important when the user’s device runs low on disk space. In that case, data from web apps that the user hasn’t used for the longest time will be removed first.

Safari is the only browser that proactively removes data when Intelligent Tracking Prevention (ITP) is turned on. When a web app hasn’t been interacted with for seven days, the data it saved will be removed; however, installed PWAs are excluded from this.

Web apps can now also request persistent storage in all browsers. This means that the data saved by the app will not be removed unless the data is manually removed by the user or when the device runs low on disk space. When disk space runs low, the browser will notify the user and offer to delete specific data.

How to request persistent storage

In supporting browsers, web apps can request persistent storage through navigator.storage.persist(). This returns a Promise that resolves to true or false. Permission is granted by the browser based on how much the user has interacted with the app and if the app is installed as a PWA.

To check if an app already has persistent storage, use await navigator.storage.persisted() which returns a Promise that resolves to true or false.

If persistent storage is not granted, try interacting with the app more or install it as a PWA. Browsers don’t show any dialogs to ask for permission, so you could consider requesting persistent storage regularly.

How much storage does my web app use?

The available and used storage space can be obtained through navigator.storage.estimate() which returns a Promise that resolves to the quota and usageproperties that return the available and used storage space, respectively, in bytes.

In Chrome and Edge, an additional property usageDetails is returned that specifies the used space by storage type, which may vary per browser.

Here’s a live demo on What PWA Can Do Today.

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

Share

Modern Web Weekly #72

Firefox 151 now supports the Document Picture-in-Picture API after support already landed in Chromium-based browsers last year.

The Document Picture-in-Picture API enables web apps to populate a picture-in-picture window with arbitrary HTML content. This means that you can place custom controls to control a video in a picture-in-picture window, for example

Another use case is that you can use this API to place multiple video streams in a single picture-in-picture window without having to use a <canvas> to place the individual <video> elements. Since you can place basically any HTML in this picture-in-picture window, the possibilities are endless.

Contrary to automatic picture-in-picture, the picture-in-picture window with arbitrary HTML is always on top. This means that when you switch from the browser or PWA to another application or even to another desktop, the picture-in-picture window will still be visible.

To open a picture-in-picture window and save a reference to it:

// open a picture-in-picture window and optionally
// specify the width and height
const pipWindow = await documentPictureInPicture.requestWindow({
  width: 800,
  height: 600
});

The picture-in-picture window now contains a document like any other browser window that you can append HTML elements to. In the demo, I use a <web-cam> web component that I can select and move to the picture-in-picture window:

// get a reference to the web cam Web Component
const webCam = document.querySelector('web-cam');

// add the web cam to the picture-in-picture window
pipWindow.document.body.appendChild(webCam);

The whole web component is now moved to the picture-in-picture window, and it can be controlled from there. When the picture-in-picture window is closed, we listen for the unload or pagehide event and move the web component back to the main document:

// listen for the 'unload' or 'pagehide' event
pipWindow.addEventListener('unload', (e) => {

// get a reference to the parent element of the web component
// in the main document
const webCamContainer = document.querySelector('.web-cam-container');

// get a reference to <web-cam> in the picture-in-picture window
const webCam =  e.target.querySelector('web-cam');

// move <web-cam> back to the main document
  webCamContainer.appendChild(webCam);
});

By default, the picture-in-picture window will contain a “back to tab” button in the title bar that can be hidden by setting disallowReturnToOpener to true when opening the window:

const pipWindow = await documentPictureInPicture.requestWindow({
  width: 800,
  height: 600,
  disallowReturnToOpener: true // will hide the "back to tab" button
});

Here’s a screen recording of the demo running in Firefox, where I swipe between desktops while the PiP window stays visible:

CSS picture-in-picture display mode

When HTML elements are part of the picture-in-picture window, you can use (display-mode: picture-in-picture) to target these elements in CSS with a media-query. I use this in the <web-cam> web component to hide the picture-in-picture button that’s normally shown, as the component is already in picture-in-picture mode, and clicking it again would throw an error:

@media all and (display-mode: picture-in-picture) {
  :is(#pip, #pip-label) {
    display: none !important;
  }
}

Install element is now available as an origin trial

In Modern Web Weekly #67, I wrote about the new declarative <install> element that is used to install a PWA. At the time of writing that, it was only available behind a flag in Chrome Canary, but now it’s also available as an origin trial, which means you can register to receive a key that enables it in your web app.

You add the key in a special meta tag in your web app’s HTML, and it works. You can check it out in the demo on What PWA Can Do Today.

The declarative <install> renders a button with an install icon and the text “Install”.

When used without attributes, it will install the current web app if it has a manifest.json file:

<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:

Before, after the app was installed, it used to look like this, but for some reason, this has been removed:

I hope this behaviour will be restored before the origin trial finishes. It 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 could automatically show a “Launch” button instead of an “Install” button.

When clicking the button, the behaviour fortunately hasn’t been changed. When the app is not installed, it will show the installation dialog, and when it’s clicked after the app was installed, it will just offer to open the installed app.

The install element fires three events to indicate successful installation, dismissal of the prompt, and validation errors:

const installElement = document.querySelector('install');

installElement.addEventListener('promptaction', () => {
  console.log('Installation succeeded');
});

installElement.addEventListener('promptdismiss', () => {
  console.log('User dismissed the install prompt');
});

installElement.addEventListener('validationstatuschanged', (e) => {
  console.error('Invalid install data:', e.target.invalidReason);
});

I haven’t been able to fire the validationstatuschanged event by providing invalid installation data with the installurl and manifestid attributes. In that case, an issue is shown in Chrome DevTools:

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.

Check the demo at https://whatpwacando.today/installation/

AirPlay support on iOS, iPadOS, and macOS

I added a simple demo to What PWA Can Do Today to show how you can stream video from one Apple device (iPhone, iPad, MacBook) to another (AppleTV, MacBook, compatible smart TV) using AirPlay.

When your web app uses a <video> element with the controls attribute and runs on an Apple device, it will automatically display an AirPlay button in the controls. If you provide your own controls, you can programmatically start AirPlay with JavaScript:

const button = document.querySelector("#airplay-button")
let isAirPlayAvailable = false

button.disabled = !isAirPlayAvailable;

player.addEventListener('webkitplaybacktargetavailabilitychanged', e => {
  if (e.availability === 'available') {
    isAirPlayAvailable = true
  }
});

button.addEventListener('click', () => {
  if (isAirPlayAvailable) {
    player.webkitShowPlaybackTargetPicker()
  }
});

To use AirPlay, the video source needs to be a real URL. A stream or object URL will not work.

Check out the demo.

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

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-selec…

Read more

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> ele…

Read more

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