Forem: Wes

Conditional Styles with CSS :has

Wes — Sun, 10 Mar 2024 00:00:00 +0000

I was setting up a simple landing page for Fandwagon and just wanted some text to be strike-through when the user checks a checkbox. So far my landing page has no need for any JavaScript, and thankfully I can keep it that way and still get conditional styles with the :has() pseudo-class.

Demo

Code

First, the HTML - a simple form with a checkbox.

<form>
  <p>
    Want to know when it's ready?
    <span
      >I'll send you one email when it's ready, then delete your email address
      forever.</span
    >
  </p>
  <div>
    <input type="checkbox" switch name="subscribe" id="subscribe" />
    <label for="subscribe">Check this box to subscribe to updates</label>
  </div>
</form>

And the CSS for the conditional strike-through

#example-form:has(input:checked) span {
  text-decoration: line-through;
}

Breaking down the selector

The first part #example-form:has(input:checked) is basically saying "find the element with id of example-form that has a child input element that is checked".

:has is basically a very-flexible "parent selector".

Once we've selected the parent that contains the checked input then we select the descendent span element and apply the text-decoration: line-through style.

💥 Done! No JavaScript needed!

You can get pretty far in conditional styling by combining :has and :checked pseudo-classes. If you have any cool example of combining the two then send me an email, I'd love to see!

Don't use TypeScript enum

Wes — Sun, 03 Dec 2023 00:00:00 +0000

Trying my hand at a zero-nuance take.

Don't do this

enum Shape {
  Sphere,
  Rectangle,
  Triangle,
}

const ball = {
  shape: Shape.Sphere,
};

Do this instead

type Shape = "Sphere" | "Rectangle" | "Triangle";

const ball = {
  shape: "Sphere",
};

Why?

Seems I'm not good at "zero-nuance", I feel compelled to explain the why behind this take... at least I'll keep it brief.

Enums are not part of the JavaScript language, so the TypeScript compiler generates different runtime code when you use enums. You aren't writing "JavaScript with types" any more. You are writing a different language that transpiles to JS. Don't do that. Keep it simple.

TypeScript is great for type checking as a dev-time benefit: it's additive, you can strip off the types and you still have JavaScript. You can even add types to JavaScript files with JSDoc comments - no need for a build step to strip off types, ship/debug the code you write, even better!

Scoped CSS Styles with Declarative Shadow DOM

Wes — Thu, 27 Jul 2023 00:00:00 +0000

I've always thought of the Shadow DOM as something to use for custom elements only... but it can be useful for non-custom elements as well!

I was reading this excellent post by Rob Eisenberg and came across the part about composing shadow DOM and realized that you can use Declarative Shadow DOM to scope CSS to a particular element without any JS. And without any framework/dependencies. 💪

<p>
  <template shadowrootmode="open">
    <style>
      :host {
        color: red;
        font-size: 1.5rem;
      }
    </style>
    <slot></slot>
  </template>
  This paragraph is scoped
</p>

You can see a live example at this Codepen.

One thing to note is that as of July 2023 Firefox has not implemented Declarative Shadow DOM yet (see caniuse), but a polyfill is possible. Firefox does currently support the imperative attachShadow API.

Imperative Shadow DOM

Alternately, you can use the imperative attachShadow JS API to accomplish the same thing. It is supported in all modern browsers, however it's more verbose, requires JS, and is not as SSR-friendly as Declarative Shadow DOM. For an example of using attachShadow check out this codepen.

The imperative Shadow DOM works well when writing custom elements (like side-drawer) and declarative Shadow DOM works well when styling a non-custom element (like <p> or <button>).

theme-color meta tag vs manifest theme_color

Wes — Sun, 25 Jun 2023 00:00:00 +0000

`theme-color` meta tag

You can set your site's theme color with the theme-color meta tag in the <head> of your site:

<meta name="theme-color" content="#4285f4" />

Browsers will use this color for certain browser UI elements (like the address bar) when the user visits your site.

If your theme color causes contrast issues it might not be used by some browsers.

`theme_color` in web app manifest

You can also set a theme_color in your site's web app manifest:

{
  "name": "My Site",
  "theme_color": "#4285f4",
  "background_color": "#fff"
}

The OS will use this color for certain UI elements when the user installs your site as a PWA. For example, this will set the color of your app's title bar on Windows.

Use Both

In my experience, desktop chromium-based browsers (Chrome, Edge, etc) will use the theme-color meta tag over the theme_color in the manifest when setting the color the of the app title bar.

So which should you use? Use both and set them to the same value (as mentioned on web.dev).

There is an App for That (But Shouldn't Be)

Wes — Sun, 04 Jun 2023 00:00:00 +0000

I wish there were fewer low-touch apps on the App Store, and more high-quality mobile sites on the open web.

I saw an advertisement on ADP's website for their benefits mobile app. With that app you can compare plan options, add dependents, and select benefits during open enrollment. All things you would do once a year (maybe a few times if you have some life changes in a given year).

So why download an app that you will use once a year? Why does a company make an app with such presumably small usage? Is it so they can say "We have an app in the App Store"?

Ditch the burden of building and maintaining a native app. Make your existing website responsive/mobile-friendly and your users will be better served for it.

How to Serialize Errors in Javascript

Wes — Sun, 30 Apr 2023 00:00:00 +0000

Don't use a simple `JSON.stringify`

If you want to serialize an Error in Javascript you might be tempted to simply use JSON.stringify, but that won't be very helpful.

const error = new Error("Something went wrong");
const serialized = JSON.stringify(error);
// serialized -> '{}'

Normalize the error

Instead what I like to do is "normalize" the error (in case it's not actually an Error object) and then use the error message:

/**
 * @param {unknown} error
 * @returns {Error}
 */
export function normalizeError(error) {
  if (typeof error === "object" && error instanceof Error) {
    return error;
  } else if (typeof error === "string") {
    return new Error(error);
  }

  // else turn this unknown thing into a string
  return new Error(JSON.stringify(error));
}

// NOW I CAN CATCH ERRORS...
try {
  throw new Error("Something went wrong");
} catch (error) {
  const normalized = normalizeError(error);
  const serialized = normalized.message;
  // serialized -> "Something went wrong"
}

// AND ANYTHING ELSE
try {
  throw "Who throws a string? ME!";
} catch (error) {
  const normalized = normalizeError(error);
  const serialized = normalized.message;
  // serialized -> "Who throws a string? ME!"
}

Alternative: Use overloaded `JSON.stringify`

If you know you are dealing with an Error object (so you don't need to normalize it) then you can use JSON.stringify with a second argument to tell JSON stringify which properties to enumerate:

const error = new Error("Something went wrong");
const serialized = JSON.stringify(error, Object.getOwnPropertyNames(error));
// serialized -> '{"stack":"Error: Something went wrong\\n at REPL9:1:13\\n at Script.runInThisContext (node:vm:131:12)\\n at REPLServer.defaultEval (node:repl:522:29)\\n at bound (node:domain:416:15)\\n at REPLServer.runBound [as eval] (node:domain:427:12)\\n at REPLServer.onLine (node:repl:844:10)\\n at REPLServer.emit (node:events:390:22)\\n at REPLServer.EventEmitter.emit (node:domain:470:12)\\n at REPLServer.Interface._onLine (node:readline:418:10)\\n at REPLServer.Interface._line (node:readline:763:8)","message":"Something went wrong"}'

If you don't want the stack in there you can just list an array of the properties you want:

const error = new Error("Something went wrong");
const serialized = JSON.stringify(error, ["message", "name"]);
// serialized -> '{"message":"Something went wrong", "name": "Error"}'

Netlify Functions in Javascript with Type-Checking

Wes — Sat, 11 Mar 2023 00:00:00 +0000

Shout out to Eduardo for pointing out that netlify already publishes an npm package with types (I don't need to write my own .d.ts file) 💪

Short Version

/** @type {import("@netlify/functions").Handler} */
export const handler = async (event, context) => {
  // all these properties are typed
  const { httpMethod, body, headers } = event;
  // response is typed
  return { statusCode: 200 }
}

Long Version

I really like Netlify Functions. ❤️

I really like ~~TypeScript~~ modern Javascript with type-checking. 👍

The appeal of Netlify Functions is how easy it is to setup: make a file, get a new api endpoint.

Writing code in .ts files makes something that was easy become not quite as easy.

Not quite as easy to get started (step 1: add a tsconfig, step 2: figure out what goes into tsconfig).

Not quite as easy to debug ("Why did the debugger just jump down there, are my source maps messed up?").

It's not too bad, but any config/build ceremony that slows down development should be scrutinized.

I find writing .js files (actually .mjs files, it's 2023, let's embrace ESM) with a combination of .d.ts declaration files and jsdoc comments to be the sweet spot of getting type-checking without any Typescript config or build steps. 🚀

Here is how I setup my Netlify Functions projects.

Step 1: Install `@netlify/functions` npm package

Netlify publishes an NPM package with types for their Functions, add that to your package.json.

npm i -D @netlify/functions

Step 2: JSDoc `@type` the handler

Now in your Function's JS file you can use a jsdoc comment to apply typing.

/** @type {import("@netlify/functions").Handler} */
export const handler = async (event, context) => {
  // all these properties are typed
  const { httpMethod, body, headers } = event;
  // response is typed
  return { statusCode: 200 }
}

That's it! 🎉

Enabling Emoji Shortcodes in Eleventy Markdown Files

Wes — Wed, 24 Nov 2021 00:00:00 +0000

In moving my blog from hugo to eleventy I noticed my emoji shortcodes (ie: writing :fire: and having the 🔥 emoji show up in the generated page) weren't working. 😦

Some quick internet searching didn't turn up a direct result (thus this blog post), but I did stumble upon the answer in the eleventy docs around markdown. We need to tell eleventy to use the markdown-it-emoji plugin with a couple simple steps.

Step 1: Install markdown-it and the markdown-it-emoji plugin

npm i -D markdown-itnpm i -D markdown-it-emoji

Step 2: Update .eleventy.js config file and register the emoji plugin

module.exports = function (eleventyConfig) {
  // setup markdown to use emoji plugin
  const markdownIt = require("markdown-it");
  const markdownItEmoji = require("markdown-it-emoji");
  const markdownLib = markdownIt({ html: true }).use(markdownItEmoji);
  eleventyConfig.setLibrary("md", markdownLib);
};

Now emoji shortcodes work! 💪 🔥 💥

How to Write TypeScript Interfaces in JSDoc Comments

Wes — Sun, 08 Aug 2021 05:19:17 +0000

Updated 2023-07-23 to clarify that jsdoc comments support object types, not interfaces. Thanks to Matt Pocock for the pointer.

I like writing web apps without any build step, just vanilla .js files. But I still like the type-checking that TypeScript provides. Thankfully TypeScript supports type-checking .js files via JSDoc comments.

But how do you write out interfaces without a .ts file? The tl;dr is you can write an object type in a JSDoc comment, or you can write an interface in a .d.ts file and import that into your .js file. Let's dig into each option.

Interfaces in a .ts file

First, let's look at an example in a .ts file.

interface Address {
    street: string;
    city: string;
    zip: number;
}

interface Customer {
    name: sting;
    email: string;
    address: Address;
}

Option 1: Object Types in a JSDoc comment

An object type isn't exactly an interface, but for most use cases it behaves the same way.

The main difference is interfaces support declaration merging but object types do not.

Writing those same interfaces in a .js file would look like:

/**
 * @typedef Address
 * @prop {string} street The street
 * @prop {string} city The City
 * @prop {number} zip The zip code
 *
 * @typedef Customer
 * @prop {string} name The Customer's name
 * @prop {string} email The Customer's email
 * @prop {Address} address The Customer's address
 */

And then you can apply that interface to an object using the @type annotation:

/** @type {Customer} */
const theCustomer = { ... }

Boom 💥 now you've got type-checking and intellisense on your data model right in a vanilla .js file.

Option 2: import interfaces from a .d.ts file

The other option to define interfaces is to put them in a .d.ts file and import that into you .js file.

// models.d.ts

export interface Address {
    street: string;
    city: string;
    zip: number;
}

export interface Customer {
    name: sting;
    email: string;
    address: Address;
}

And then in your .js file you can import those types:

/**
 * @typedef { import("./models").Customer } Customer
 */

 /** @type {Customer} */
const theCustomer = { ... }

This is my preferred approach as I find writing types in .d.ts files to be more terse than writing types out in jsdoc comments. But I like having both options available to use interchangeably.

Type Guards in Javascript Using JSDoc Comments

Hopefully you found this post helpful, if you have any questions you can find me on Twitter.

Detect if a PWA is Visible with the Page Visibility API

Wes — Sat, 07 Nov 2020 00:00:00 +0000

Need to figure out when your PWA comes to the foreground? The modern web has you covered with the Page Visibility API.

document.addEventListener("visibilitychange", () => {
  const state = document.visibilityState;
  if (state === "hidden") {
    // your PWA is now in the background
  }

  if (state === "visible") {
    // your PWA is now in the foreground
    refreshData();
  }
});

Note: this API isn't specific to PWAs, it works for non-PWA websites/webapps as well.

Most documentation talks about how this event fires when switching tabs, but this also fires when a PWA is foregrounded/backgrounded.

Try it out yourself by going to https://visibility-api.netlify.app and adding it to your home screen.

Hopefully you found this post helpful, if you have any questions you can find me on Twitter.

Type Guards in Javascript Using JSDoc Comments

Wes — Sat, 10 Oct 2020 21:02:50 +0000

In Typescript you can write type guards to filter down a union type to a single type. For example:

// user-defined type guard
function isFish(pet: Fish | Bird): pet is Fish {
  return "swim" in pet;
}

const pet: Fish | Bird = getPet();

// at this point you either have a Fish or Bird

if(isFish(pet)) {
    // at this point you (and tsc and intellisense) know you have a Fish
    pet.swim();
} else {
    // at this point you (and tsc and intellisense) know you have a Bird
    pet.fly();
}

JSDoc Type-Checking Version

What if you write your code in Javascript and use JSDoc comments for type-checking and intellisense? You can still write and use type guards!

/** @typedef {{swim: () => void}} Fish */
/** @typedef {{fly: () => void}} Bird */

/**
 * @param {Fish | Bird} pet
 * @returns {pet is Fish}
 */
function isFish(pet) {
  return "swim" in pet;
}

/** @type {Fish | Bird} */
let pet = getPet();

// at this point "pet" is either a Fish or Bird

if (isFish(pet)) {
  // at this point you (and tsc and intellisense) know you have a Fish
  pet.swim();
} else {
  // at this point you (and tsc and intellisense) know you have a Bird
  pet.fly();
}

Hopefully you found this post helpful, if you have any questions you can find me on Twitter.

iOS 14 PWA Improvements

Wes — Sat, 11 Jul 2020 00:00:00 +0000

I recently installed the iOS 14 Beta 2 looking to see what improvements are in store for PWAs. Unfortunately, there aren't really any PWA-specific improvements (ie: features related to service workers or the experience of standalone web apps pinned to the home screen).

The good news is there are some important standards/features being implemented in Safari that a PWA (or any website/webapp) can use.

Improvements

Face ID and Touch ID for the Web

Safari's implementation of the webauthn API will support Face ID and Touch ID, so now a PWA can have that same seemless authentication experience that native apps have.

Resize Observer

Useful for building responsive elements, ResizeObserver can now be used on iOS without any polyfill, resulting in a smaller PWA bundle size. 🎉

CSS Shadow Parts

I use web components in my PWAs so this improvement is exciting to me. This standard helps with styling web components. Now that this standard is implemented in all major evergreen browsers (Chrome, Edge, Firefox, Safari) I hope to see more web components leveraging shadow parts for style customization.

CSS Shadow Parts are actually already implemented in iOS 13.1

HTML `enterkeyhint` attribute

Native apps have been able to set the enter key label on the virtual keyboard for a while, but now PWAs can do the same using the enterkeyhint attribute.

WebP Image Format Support

WebP is a modern image format that supports both lossless and lossy compression. WebP images are smaller than PNGs and JPEGs, resulting in a smaller PWA bundle size. 🎉

PWA-Specific Features Still Not Implemented

Unfortunately, there are some PWA features that still don't work on iOS 14. This isn't an exhaustive list, just a couple of things I've noticed so far.

Background Audio

Like last year, the first thing I checked when I installed iOS 14 was background audio because some PWAs really need it. This time around I was hopeful because there was some activity earlier this year on the webkit bug. Unfortunately, background audio still stops as soon as you leave the PWA.

Do me a favor and go comment on the webkit bug or retweet this to help get this bug prioritized by the Webkit team.

Manifest.json Icon Ignored

The standard way to define icons for a PWA is to set the icons object in manifest.json. Unfortunately iOS ignores that so if you want your PWA icon to show up properly on the user's home screen you will still need to add the following to your HTML:

<link rel="apple-touch-icon" sizes="192x192" href="./logo.png" />

That's easy enough, but it would be nice if you only had to declare your icons in one place and it just works for Android and iOS (and Windows and Linux, etc, etc).

Push Notifications

It's hard for a PWA to rival a native app in terms of user experience without something as basic a push notifications, so it's disappointing to see this still isn't implemented on iOS 14.

BeforeInstallPromptEvent API

This API allows web apps to programmatically pin the web app to the user's home screen as a PWA. This is a non-standard API so it's unlikely for Apple to implement it, but it would be nice if there were a programmatic way to add to homescreen. Having a button the user can tap to install the current site as a PWA is a lot nicer experience than asking the user to dig into the share menu in Safari. Also, "Add to Home Screen" is only available in Safari, not in 3rd party browsers.

PWAs in App Library

iOS 14 introduces the concept of App Libraries to automatically group apps together. What I've noticed so far is any PWAs I add to my home screen don't show up in the "Recently Added" or "Suggestions" app libraries. In fact, all I've used so far since installing iOS 14 are the Twitter and Background Noise PWAs and yet they don't show up anywhere in my App Library.

It would be nice if PWAs got the same treatment as native apps for such a visible OS feature.

Wrapup

There are still some major roadblocks on iOS that prevent PWAs from having parity with native apps when it comes to user experience and OS integration. Developing PWAs for iOS can feel pretty frustrating when compared to Android and Windows. However, I appreciate that Safari is steadily implementing more web standards. I'll try and keep this post updated with my findings as new iOS 14 betas get released.

Follow me on Twitter for more writings about PWAs, web components, mobile development, and adventures in product development.

Forem: Wes

Conditional Styles with CSS :has

Demo

Code

Breaking down the selector

Don't use TypeScript enum

Don't do this

Do this instead

Why?

Related Posts

Scoped CSS Styles with Declarative Shadow DOM

Imperative Shadow DOM

theme-color meta tag vs manifest theme_color

theme-color meta tag

theme_color in web app manifest

Use Both

There is an App for That (But Shouldn't Be)

How to Serialize Errors in Javascript

Don't use a simple JSON.stringify

Normalize the error

Alternative: Use overloaded JSON.stringify

Netlify Functions in Javascript with Type-Checking

Short Version

Long Version

Step 1: Install @netlify/functions npm package

Step 2: JSDoc @type the handler

Enabling Emoji Shortcodes in Eleventy Markdown Files

How to Write TypeScript Interfaces in JSDoc Comments

Interfaces in a .ts file

Option 1: Object Types in a JSDoc comment

Option 2: import interfaces from a .d.ts file

Related Posts

Detect if a PWA is Visible with the Page Visibility API

Type Guards in Javascript Using JSDoc Comments

JSDoc Type-Checking Version

iOS 14 PWA Improvements

Improvements

Face ID and Touch ID for the Web

Resize Observer

CSS Shadow Parts

HTML enterkeyhint attribute

WebP Image Format Support

PWA-Specific Features Still Not Implemented

Background Audio

Manifest.json Icon Ignored

Push Notifications

BeforeInstallPromptEvent API

PWAs in App Library

Wrapup

References

`theme-color` meta tag

`theme_color` in web app manifest

Don't use a simple `JSON.stringify`

Alternative: Use overloaded `JSON.stringify`

Step 1: Install `@netlify/functions` npm package

Step 2: JSDoc `@type` the handler

HTML `enterkeyhint` attribute