Forem: Alan Dávalos

Explaining the new internationalization features in Safari 15.4

Alan Dávalos — Fri, 18 Mar 2022 09:05:36 +0000

Safari 15.4 released recently and among many things it includes a few new internationalization features. And while the blog post does explain which ones they are, it doesn't really mention what they do. So, I'll give you a brief summary for all of them.

`Intl.Locale`

`calendars/collations/hourCycles/numberingSystems/timeZones`

All of these properties will return an array of the things the locale supports. Here are some examples of what each one will return so that you can get an idea of what they're used for.

// calendars for Japanese (Japan) will return the Gregorian calendar and the Japanese calendar
new Intl.Locale('ja-JP').calendars; // ['gregory', 'japanese']

// collations A.K.A. ordering rules for Spanish (Mexico) will return traditional style ordering, European ordering rules, and emoji
new Intl.Locale('es-MX').collations; // ['trad', 'emoji', 'eor']

// hourCycles for Traditional Chinese (China) will be a 23 hour cycle
new Intl.Locale('zh-Hant-CN').hourCycles; // ['h23']
// but for English (USA) it will be a 12 hour cycle
new Intl.Locale('en-US').hourCycles; // ['h12']

// numberingSystems for Arabic (Bahrain) will return Arabic-Indic digits
new Intl.Locale('ar-BH').numberingSystems; // ['arab']
// but for Portuguese (Brazil) it will return Latin digits
new Intl.Locale('pr-BR').numberingSystems; // ['latn']

// timeZones for English (New Zealand) will return Auckland and Chatham
new Intl.Locale('en-NZ').timeZones; // ['Pacific/Auckland', 'Pacific/Chatham']

Previous versions of the spec supported the non-plural versions of each of these properties. However, they will be undefined unless they are set through the options parameter of the Locale constructor.

// not setting with options
new Intl.Locale('ja-JP').calendar; // undefined
new Intl.Locale('ja-JP').calendars; // ['gregory', 'japanese']

// setting with options
new Intl.Locale('ja-JP', {calendar: 'gregory'}).calendar; // 'gregory'
new Intl.Locale('ja-JP', {calendar: 'gregory'}).calendars; // ['gregory'] as the 'japanese' one will get removed due to the options

// you can also set other calendars not there by default on the locale so be careful
new Intl.Locale('ja-JP', {calendar: 'buddhist'}).calendar; // 'buddhist'
new Intl.Locale('ja-JP', {calendar: 'buddhist'}).calendars; // ['buddhist']

`textInfo`

The textInfo property currently contains an object with a single direction property which serves to indicate whether the locale's text is written right-to-left or left-to-right.

// Arabic
new Intl.Locale("ar").textInfo; // { direction: 'rtl'}
// Spanish
new Intl.Locale("es").textInfo; // { direction: 'ltr'}

`weekInfo`

The weekInfo currently contains an object with various information regarding how weeks work on that region. It's especially useful when creating calendar UIs.

// week info for the UK
const gb = new Intl.Locale("en-GB").weekInfo;
gb.firstDay; // 1 - week starts on Monday
gb.weekend; // [6, 7] - weekend is Saturday and Sunday
gb.minimalDays; // 4 - for a week to be shown as the first week of a month it needs to be at least 4 days long

// week info for Algeria
const dz = new Intl.Locale("ar-DZ").weekInfo;
dz.firstDay; // 6 - week starts on Saturday
dz.weekend; // [5, 6] - weekend is Friday and Saturday
dz.minimalDays; // 1 - for a week to be shown as the first week of a month it needs to be at least 1 days long

Browser Support

MDN

All the above features are supported in the following browsers:

Safari: 15.4 - supported
Chrome/Edge: 92* - supported (MDN says only with a flag but it worked in Edge 99 with no flags)
Firefox: 99 - not supported

Intl.DisplayNames

`type: 'calendar'`

This type option will allow you to get the localized name for any of the supported calendar types.

new Intl.DisplayNames(['en'], { type: 'calendar' }).of('gregory'); // 'Gregorian Calendar'
new Intl.DisplayNames(['en'], { type: 'calendar' }).of('japanese'); // 'Japanese Calendar'

`type: 'dateTimeField'`

With this type option you can get localized strings for many different common words related to dates and time. Some examples include:

new Intl.DisplayNames(['en'], { type: 'dateTimeField' }).of('year'); // 'year'
new Intl.DisplayNames(['en'], { type: 'dateTimeField' }).of('minute'); // 'minute'                                               
new Intl.DisplayNames(['en'], { type: 'dateTimeField' }).of('weekday') // 'day of the week'

`languageDisplay` option

The languageDisplay option is an option that can only be used for type: 'language' that determines the format for the string representing the language. It can be either 'dialect' or 'standard'.

new Intl.DisplayNames(['en'], { type: 'language', languageDisplay: 'dialect' }).of('en-AU'); // Australian English
new Intl.DisplayNames(['en'], { type: 'language', languageDisplay: 'standard' }).of('en-AU'); // English (Australia)

Browser Support

No MDN data for these features specifically, but I tested them in the following browsers:

Safari: 15.4 - supported
Chrome/Edge: 99 - supported
Firefox: 99 developer edition - supported

Intl.DateTimeFormat

New `timeZoneName` types

Four new types of timeZoneName were added: 'shortOffset', 'longOffset', 'shortGeneric', and 'longGeneric'.

const date = new Date(Date.UTC(2020, 11, 20, 3, 23, 16, 738));

new Intl.DateTimeFormat('en', { timeZone: 'JST', timeZoneName: 'shortOffset'}).format(date); // '12/20/2020, GMT+9'
new Intl.DateTimeFormat('en', { timeZone: 'JST', timeZoneName: 'longOffset'}).format(date); // '12/20/2020, GMT+09:00'
new Intl.DateTimeFormat('en', { timeZone: 'JST', timeZoneName: 'shortGeneric'}).format(date); // '12/20/2020, Japan Time'
new Intl.DateTimeFormat('en', { timeZone: 'JST', timeZoneName: 'longGeneric'}).format(date); // '12/20/2020, Japan Standard Time'

Browser Support

MDN

Safari: 15.4 - supported
Chrome/Edge: 99* - supported (MDN doesn't list this as supported but it worked in my tests. It might work in earlier versions. MDN issue)
Firefox: 91 - supported

Intl.NumberFormat / Intl.PluralRules

Safari 15.4's release notes mention that it added support for formatRange() and formatRangeToParts() in NumberFormat and for selectRange() in PluralRules. However, as the time of writing, those functions don't seem to be actually implemented in Safari 15.4 (Mac OS 10.15) nor have they been implemented in other browsers.

new Intl.NumberFormat('de-DE').formatRange; // undefined
new Intl.NumberFormat('de-DE').formatRangeToParts; // undefined

new Intl.PluralRules('de-DE').selectRange; // undefined

Conclusion

Hopefully this article helped you understand better what all these new features were about and whether you can actually begin using them.

Credits

Cover photo by Nareeta Martin on Unsplash.

Where to begin building Web Components? - Class-based Libraries

Alan Dávalos — Mon, 29 Jun 2020 09:08:49 +0000

Introduction

Welcome back to this series where I try to help you find which way of building Web Components best suits you!

In the previous post, we covered the Web Components Standards and why you probably will want to use a library to help you build your Web Components at this point of time.

In this article we'll be covering the first pattern commonly used by Web Components libraries, the class-based pattern.

Just before we begin, I have one quick note regarding the "bundle" size data.

I'll be using the fantastic BundlePhobia as the source for the minified + gzip bundle size data of each library.

However, depending on the approach each library follows, how much the library's bundle size affects your application's bundle when using multiple components based on that library may vary greatly.

The folks at WebComponents.dev did an amazing breakdown on that kind of data so if you're interested in that kind of data go check them out. (You can also test out all the libraries covered in this article in their Web IDE.)

Now without further ado.

What's the Class-based Pattern About?

In the first article of this series, we mentioned that in order to create a Web Component you need to create a class that extends HTMLElement and then register that class in the CustomElementRegistry.

And of course, extending a class that extends HTMLElement also counts.

So what this type of libraries do is exactly that, they create a generic class that extends HTMLElement and add a bunch of utility code that helps out make creating components easier.

For example, the SuperAwesomeElement class defined below could help making updating an element after one of it's attributes changed a lot easier than when manually extending HTMLElement.

You can see the code in action here

export class SuperAwesomeElement extends HTMLElement {
  constructor() {
    super();
    this.state = {};
  }

  static get attributes() {
    return {};
  }

  static get observedAttributes() {
    return Object.keys(this.attributes);
  }

  attributeChangedCallback(name, oldValue, newValue) {
    if (oldValue === newValue) {
      return;
    }
    // it basically will just parse the attribute depending on the
    // type you define and set it to the components state property
    const type = this.attributes[name].type;
    if (/array|object/i.test(type)) {
      this.state[name] = JSON.parse(newValue);
    } else if (/number/i.test(type)) {
      this.state[name] = parseFloat(newValue);
    } else {
      this.state[name] = newValue;
    }
    this.update();
  }
}

And creating an actual component based on it would look like this:

import { SuperAwesomeElement } from "super-awesome-element";

const template = document.createElement("template");
template.innerHTML = `
  <p>Text: <span class="text"></span></p>
  <p>Number: <span class="int"></span></p>
  <p>Object: <span class="obj"></span></p>
  <p>Array: <span class="arr"></span></p>
`;

export class MyComponent extends SuperAwesomeElement {
  constructor() {
    super();
    this.state = { text: "", int: 0, obj: {}, arr: [] };

    this.attachShadow({ mode: "open" });
    this.shadowRoot.appendChild(template.content.cloneNode(true));

    this._textNode = this.shadowRoot.querySelector(".text");
    this._intNode = this.shadowRoot.querySelector(".int");
    this._objNode = this.shadowRoot.querySelector(".obj");
    this._arrNode = this.shadowRoot.querySelector(".arr");
  }

  static get attributes() {
    return {
      text: { type: "string" },
      int: { type: "number" },
      obj: { type: "object" },
      arr: { type: "array" },
    };
  }

  update() {
    this._textNode.textContent = this.state.text;
    this._intNode.textContent = this.state.int;
    this._objNode.textContent = JSON.stringify(this.state.obj);
    this._arrNode.textContent = JSON.stringify(this.state.arr);
  }
}

customElements.define("my-component", MyComponent);

Naturally, this is just a super simple example that's nowhere near production ready and actual class-based libraries do a lot more things for you.

But even an example as simple as this reduces the amount of code you need to create a component quite a bit.

Now imagine what a full-featured library can do for you. 💪

Pros and Cons

Components written using this kind of libraries are by definition a lot closer to the standard, which in itself has some pros and cons:

Pros

Easy migration: if you ever need to migrate your components to vanilla or another class-based library the migration will be smoother than if you were using one of the other patterns.
Extensibility: If you need extra common features for your components you can use mixins to add them to your components, and these mixins might actually work no matter which class-based library you end up using as they all extend HTMLElement.
You learn to use the standards: learning how to use one of this libraries will help you understand the standards better.

Cons

More boilerplate code: while extending a class-based library does drastically reduce the amount of code you need to write, classes in JS just generally require you to write slightly more boilerplate code than other approaches.
- This is mostly evident while doing things like having side effects on property changes.
- Note that this doesn't mean the build size will be bigger, it's just about the code you actually write.

Libraries that Follow this Pattern

Here's a list of some of the libraries that follow this pattern in alphabetical order:

Stars/Version/Size data was updated at the time of publishing.

CanJS

Website | Github

Stars	License	Latest Version	TS Support	Bundle Size	Templating
1.8k+	MIT	1.1.2 (June 2020)	Couldn't find	66kB	can-stache (mustache-like syntax)

Fun Facts

CanJS's size is actually quite big compared to pretty much every other library introduced throughout this series.

But that's mostly because unlike the other libraries CanJS is more of a framework based on Web Components than a library to create Web Components.

So if you build your whole app just around it, it might be worth it for you, but if you're just building a reusable components you're probably better off using other libraries.

HyperHTML Element

Github

Stars	License	Latest Version	TS Support	Bundle Size	Templating
0.1k+	ISC	3.12.3 (March 2020)	Yes	8.7kB	hyperHTML (JS Tagged Template Literals)

Fun Facts

This library is mostly meant to be a helper to create Web Components rendered with hyperHTML.

As a side node, hyperHTML might be one of the best rendering libraries in terms of performance. ⚡️

LitElement

Website | Github

Stars	License	Latest Version	TS Support	Bundle Size	Templating
3.5k+	BSD 3-Clause	2.3.1 (March 2020)	Yes, includes decorators	7.1kB	lit-html (JS Tagged Template Literals)

Fun Facts

LitElement being made by the Polymer Project team confuses many people since Polymer v3 still "exists".

To put it simple LitElement is Polymer v4, except that since the approach to creating the components changed quite drastically (and got improved drastically too) they changed the name.

So if you want to use a "Polymer" library just use LitElement. 😉

LitElement's first production-ready release was actually v2.0.0 because the lit-element package was previously owned by other people and already had a v1.0.0 release.

It's sister library, lit-html, has a lot of parallels with a library that was mentioned before, hyperHTML, including the part about being one of the best performing rendering libraries. ⚡️

Omi

Website | Github

Stars	License	Latest Version	TS Support	Bundle Size	Templating
11.1k+	MIT	6.19.3 (May 2020)	Yes, includes decorators	8.3kB	JSX (Preact)

Fun Facts

Omi is probably the only class-based library whose docs are on multiple languages by default.

They seem to all have versions in English and Chinese and some even in Korean. 🇬🇧🇨🇳🇰🇷

SkateJS

Website | Github

Stars	License	Latest Version	TS Support	Bundle Size	Templating
3.1k+	MIT	0.0.1 (December 2018)	Couldn't find	1.8kB + render library	hyperHTML/lit-html (JS Tagged Template Literals), JSX

Fun Facts

SkateJS is actually a pretty unique library as it doesn't provide an "official" way of writing templates.

Instead, it's designed to be used together with either a tagged template literal-based engine like hyperHTML or lit-html or a JSX engine like Preact or React.

The only bad thing is that it seems like the SkateJS team is mostly focused on improving their SSR functionality right now so there haven't been any updates on the Web Component library itself for a while.

SlimJS

Website | Github

Stars	License	Latest Version	TS Support	Bundle Size	Templating
0.7k+	MIT	4.0.7 (April 2019)	Yes, includes decorators	3.3kB	own library (mustache-like)

Fun Facts

As the name suggests, SlimJS is super slim, it's the smallest library on this article's list and it's one of the smallest I will cover throughout the series in general.

Just one thing you might want to consider is that the project doesn't seem to have any updates for the past year or so. ☹️

What's Next?

Now we have covered the class-based approach, how it works, why it can be good for you, and some of the libraries that use this approach.

And maybe you already liked something here so much that you want to test it out ASAP, if you did, that's amazing! 🎉

But don't worry if you haven't, we still have other patterns to cover with many more libraries representing them so stay tuned for the next entry on this series.

Feel free to leave a comment with any corrections, questions, or suggestions you have for the rest of the series. Especially regarding the libraries and the data I showed on them as I'm not an expert on every single one of them so some of it might be slightly off.

Where to begin building Web Components? - The Basics

Alan Dávalos — Thu, 14 May 2020 09:05:12 +0000

Introduction

If you're reading this you've probably at least heard a bit about Web Components, a set of web standards that allow us to create our own reusable UI components that can be used in any kind of web application and natively supported in all modern browsers.

// Detect dark theme var iframe = document.getElementById('tweet-1217578939456970754-490'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1217578939456970754&theme=dark" }

What you might not know is where to start, because if there's anything amazing yet terrible about the web development landscape is that where there's an API there will be a bazillion abstractions to "Make it Simpler™".

And of course, Web Components are not the exception, last time I checked I could find around twenty-something different libraries that provide some sort of abstraction to help you create a Web Component.

So, for anyone just trying to begin building Web Components just even finding out where to start is pretty difficult, which is why I'm here.

Throughout this series of articles (yes, it's a series!), I'll cover the following points:

The basics of the Web Components standard: I'll be covering these in this article 😉
The types of approaches different libraries take to help you be more efficient when creating Web Components: I'll cover each type in a separate article and try to give a brief introduction of most of the libraries I could find that follow each type

Just bear in mind, this isn't a tutorial per se, I won't be explaining how to build Web Components with each library, I believe that's what the docs for each library are there for to begin with.

The main purpose of this article is to try to help developers who are just starting with Web Components find a way of building Web Components that they feel comfortable with. 😊

To quote Justin Fagnani, one of the members of the Polymer Project which greatly contributed in pushing the Web Components standard:

[...] the big idea with web components is that it shouldn't matter which or even if an approach (to create Web Components) becomes more popular. As long as components interoperate we all win.

So, let's stop with the introduction and start with the juicy stuff.

What's actually needed to create a Web Component?

To avoid repeating what many other articles have mentioned, I won't explain all the standards that make up Web Components, but if you need a reminder I recommend you to check this MDN article.

Now, knowing what the standards are about is cool and all, but what does a vanilla Web Component actually look like?

Here's some sample code for a simple Hello World component, don't worry if you don't fully understand what everything is, we'll go through it in more detail later on. 😉

const template = document.createElement("template");
template.innerHTML = `<div>Hello <span class="name"></span></div>`;

class MyGreeting extends HTMLElement {
  constructor() {
    super();
    this.name = "World";
  }

  // Start - Standard Lifecycle Callbacks
  // This gets triggered when the component first is appended to the document
  connectedCallback() {
    if (!this.shadowRoot) {
      this.attachShadow({ mode: "open" });
      this.shadowRoot.appendChild(template.content.cloneNode(true));
    }
    this._nameSpan = this.shadowRoot.querySelector(".name");
    this._nameSpan.textContent = this.name;
  }
  // This defines which attributes will trigger a callback when they get set on the component
  static get observedAttributes() {
    return ["name"];
  }
  // This callback will get triggered when one of the observedAttributes gets changed
  attributeChangedCallback(attr, oldVal, newVal) {
    if (oldVal !== newVal) {
      this[attr] = newVal;
    }
  }

  // End - Standard Lifecycle Callbacks

  set name(value) {
    this.safeSetAttribute("name", value);
    if (this._nameSpan) {
      this._nameSpan.textContent = value;
    }
  }

  get name() {
    return this.getAttribute("name");
  }

  // a helper function to prevent an endless loop on attribute assignment
  safeSetAttribute(attr, value) {
    if (this.getAttribute(attr) !== value) {
      this.setAttribute(attr, value);
    }
  }
}

window.customElements.define("my-greeting", MyGreeting);

In this simple code you can see all the Web Components standards in action:

We create a <template> that will be used for our component.
We create a class that extends the native HTMLElement class which will be registered in the window level CustomElementRegistry. This will make all the <my-greeting> tags rendered use our class to know what to render.
Our class contains some of the custom elements lifecycle callbacks which mostly help us to know when to setup, destroy, or update our component.
We use the attachShadowRoot function to create the Shadow DOM tree for our component.

You might think that this code is slightly too cumbersome for what seems to be too little.

And you're right in thinking that, the Web Components standards, at least in their current form, are low-level standards that require you to write code for things that are needed pretty much for all use cases.

Let's "Make it Simpler™"

This is where the abstractions I mentioned before come in, all of them basically aim to solve the pain points of working with each standard by:

Providing a rendering engine that removes all manual DOM manipulation
Either extend, wrap, or compile to a class that can be registered in the CustomElementRegistry
Extend the native lifecycle callbacks and sometimes add library-specific callbacks that can help with more use cases like state management and many others.
Handle the creation of the Shadow DOM tree with fallbacks either to polyfills or no Shadow DOM at all.

All of these abstractions generally make the overall development experience way more pleasant than working with vanilla web components.

And what's even better is that since most of the final heavy lifting is done by the actual standards the majority of the libraries covered throughout this series won't add even 10kB to your final bundle (after minify/gzip)! 💪

What's Next?

So far, I (hopefully) helped you understand what it takes to create a Web Component and why you probably want to use a library to help you out having a nice experience while doing so.

But let's not forget about the original objective, I'm supposed to be playing cupid here and match you with your perfect library. 💘

And while I mentioned many abstractions the libraries provide over the standards, I believe the one that has the biggest effect on how you actually end up writing the code for your component is the way to define the "class" for your component.

Like I mentioned above, most libraries fall into one of three patterns:

They provide a class that extends HTMLElement and adds the extra features onto it so that you extend that new class in your code.
They provide a function that will create a class for your component with both the extra features and your component code when called.
They provide tools that can be used to compile your code, usually written in a proprietary syntax, into a class for your component with both the extra features and your component called.

In the following articles, I'll go into more detail about how each pattern works in detail and try to briefly introduce as many libraries as I can that fall into that pattern.

Thank you very much for reading this article to the end, I hope you liked it and keep reading the other articles for this series.

Feel free to leave a comment with any questions or suggestions you have for the rest of the series, especially on what kind of data you would like to hear about from the libraries I'll be introducing.

The Quirks of Shadow DOM and How to Take Advantage of Them

Alan Dávalos — Tue, 18 Feb 2020 04:31:26 +0000

Disclaimer:

During this article I'll be referring to the "normal" DOM as "Light DOM" to make it clear when I'm talking about it.

What is Shadow DOM?

While Shadow DOM is considered one of the core standards that make up Web Components it's
actually been in the browsers for quite a while as native HTML Elements like <video>
use it, it just wasn't available for developers to use before it was incorporated in the Web Components standard.

And now that Edge is based on Chromium all Web Component standards, including Shadow DOM, are available in all modern browsers!! 🎉

The whole idea of Shadow DOM is that it allows us to create DOM trees that are isolated
from the Light DOM but that can be appended to the Light DOM and be rendered together with it.

I know that sounds slightly confusing so this image might help understand it better:

Source: "Using Shadow DOM" by Mozilla Contributors

This isolation is the key feature of Shadow DOM and it solves a couple of problems no other approach can really solve:

Nodes inside Shadow DOM aren't accessible via things like document.querySelector() so you can prevent unwanted changes from other scripts.
All CSS in Shadow DOM is scoped to it which has a couple of great benefits:
1. Styles in Shadow DOM don't leak out to Light DOM
2. Styles in Light DOM don't bleed in to Shadow DOM*
3. These two allow you to use super simple selectors like button or #someid without being afraid of anything, this is the biggest reason why we say that Shadow DOM fixes CSS, everything has it's own scope.

Now, you might have noticed that I put an asterisk when I mentioned that Light DOM styles don't bleed in to Shadow DOM.

You see, having Shadow DOM have no way of being stylized from Light DOM would make it a bit too restrictive for many common use cases like theming and light customization.

Which is why Shadow DOM contents can be stylized from Light DOM in certain cases.

Like many CSS-related things, these are slightly difficult to understand just by reading them, so I'm going to take a Quiz-like approach for the rest of this article.

1 - How does inheritance work here?

This is the markup for our first Shadow DOM:



<style>
  .some-class {
    font-family: Arial;
    font-size: 14px;
    color: blue;
  }
</style>

<div>
  This is some text
</div>
<div class="some-class">
  And here's some more text
</div>

And this is the Light DOM



<style>
  .container {
    font-family: Helvetica;
    font-size: 16px;
    color: green;
    padding: 2em;
  }

  .container .some-class {
    color: red;
  }
</style>
<div class="container">
  <!--
  The Shadow DOM from the previous snippet is
  in this web component
  -->
  <question-one></question-one>
</div>

How do you think this will render? Try not to spoil yourself 😉.

Answer

Why?

Nodes inside Shadow DOM by default have no special styles, so properties that inherit such as
font-family or color will inherit their values from the Shadow DOM's ancestors.

Now, as you can see, in some-class we're actually defining font-family, font-size, and color so that part doesn't inherit styles.

Bonus points if you noticed that the .container .some-class selector in the Light DOM is basically useless as it's trying to affect nodes inside the Shadow DOM directly which isn't allowed.

2 - Can you style the host?

Here's the Shadow DOM:



<style>
  /*
  This selector basically applies to the root
  of our shadow DOM
  */
  :host {
    display: block;
    width: 30px;
    border: 1px dotted black;
  }
</style>

<div>1</div>
<div>2</div>
<div>3</div>

And here's the Light DOM:



<style>
  .some-class {
    display: flex;
    flex-flow: row-reverse;
    width: 100%;
    border: 1px solid red;
  }
</style>
<question-two></question-two>
<question-two class="some-class"></question-two>

Once again, how do you think this will render? Ready?

Answer

Why?

Unlike styles applied to the children nodes, host-level styles in Shadow DOM can be overridden from Light DOM.

Basically, anything that you define for the host directly is no more than a default style so if you really want to enforce a certain style you probably want to add a container node as a children and style that instead.

3 - Are CSS variables applied?

Once more, here's the Shadow DOM:



<style>
  div {
    color: var(--my-color, blue);
  }
</style>

<div>
  Some text
</div>

And here's the Light DOM:



<style>
  .custom-color {
    --my-color: red;
  }
</style>

<question-three></question-three>
<question-three class="custom-color"></question-three>

What will happen with the color on this one?

Answer

Why?

CSS Custom Properties (or CSS Variables as most people call them) are one of the few things that can freely style nodes inside a Shadow DOM.

Of course, like on this example, the style used in the Shadow DOM must define which variables it wants to use and where, but this is an easy way of providing customization on key points.

For more information on CSS Variables this article should help as a starting point.

4 - What happens to the children nodes?

Ready for one more question? Here's the Shadow DOM:



<style>
  /*
  the ::slotted(selector) selector applies to
  any nodes appended in the indicated slot
  that match the given selector
  */
  header ::slotted(*) {
    text-decoration: underline;
  }
  article ::slotted(div.special) {
    color: turquoise;
  }
</style>

<section>
  <header>
    <h3><slot name="header">Default Header</slot></h3>
  </header>
  <article>
    <slot></slot>
  </article>
</section>

And here's the Light DOM:



<style>
  .some-class .header {
    color: red;
  }

  .some-class div {
    color: mediumvioletred;
  }
</style>

<question-four>
  <div>1</div>
  <div class="special">2</div>
  <div>3</div>
</question-four>

<question-four class="some-class">
  <div>4</div>
  <div class="special">5</div>
  <div>6</div>
  <span class="header" slot="header">
    Second Element Header
  </span>
</question-four>

This one had a bit more things to figure out so take your time, how do you think it will render?

Answer

Why?

If this is your first time reading about Shadow DOM I won't blame you if you didn't get this one, but bear with me, I'll do my best to explain this.

You see, in Shadow DOM there's a special <slot> tag that serves to basically say what part of the template this element's children will be appended to.

If you've used children in React or slots in Vue you probably are familiar with the concept (Vue's slots are based on this standard).

Now, in styles defined in Shadow DOM we can try to apply styles to children appended through a slot using the ::slotted() selector.

But as you can see, this works really similar to how host level styles behaved a couple questions ago. Styles applied with ::slotted() are also basically default styles that will merge with the styles coming from Light DOM but the Light DOM styles will have a higher priority.

5 - Can you style some parts only?

The last question!! Are you ready? Here's the Shadow DOM:



<style>
  :host {
    display: flex;
  }
  img {
    width: 64px;
    height: 64px;
  }
  div {
    font-family: Arial;
    color: seagreen;
  }
</style>

<img part="avatar" src="https://via.placeholder.com/64x64.jpg?text=Avatar" />
<div part="name">
  Some Name
</div>

And here's the Light DOM:



<style>
  question-five.custom-part::part(avatar) {
    border-radius: 50%;
  }

  question-five.custom-part::part(name) {
    font-family: Verdana;
    color: mediumpurple;
  }
</style>

<question-five></question-five>
<question-five class="custom-part"></question-five>

For the last time, how will this part stuff render?

Answer 5

Why?

Now we're entering into cutting edge grounds, unlike the content for all the four previous questions which are all available in all modern browsers, this last one is not yet available in Safari (it's probably coming soon-ish as it's on the Technology Preview and in my tests it worked just fine), but it's available on all Chromium-based browsers (Chrome, Edge, Opera, etc.) and Firefox.

Update: As of October 2020, Safari has implemented this standard so now it works on all modern browsers!

For this demo we use the Shadow Parts Standard, and as the name suggests, it let's us declare "parts" inside our Shadow DOM that can then be styled from Light DOM using the ::part() pseudo element.

As you can probably tell by now, Shadow Parts work similarly to how slots and host level styles work so the properties set using ::part() on the Light DOM styles will take top priority and styles set on the Shadow DOM will work as fallbacks.

To Close

Shadow DOM is a really powerful part of the Web Standard but it definitely has some quirks that aren't that evident at first glance.

I hope this little quiz helped you understand a bit better how Shadow DOM works and how you can make the most of it both when using and when creating your own Web Components (or even if you just use Shadow DOM by itself).

More Info

https://developers.google.com/web/fundamentals/web-components/shadowdom
https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM

Sometimes Chrome is the problem

Alan Dávalos — Thu, 16 Jan 2020 01:34:02 +0000

Anyone who has been doing web development over the last decade or so has probably faced a situation like this:

I want to use this shiny new JS API/CSS feature, it looks cool!

Wow, I tested it on Chrome and it looks great!

Now I'll test it on the other browsers... And it doesn't work 😢

I know I've been there, and you probably have too, in fact, these kind of browser compatibility problems are so common amongst web developers that they were ranked as the top frustration web developers and designers face in the recent Web DNA Report 2019 by Mozilla. No matter the region, gender, years of experience, or anything else, it's just the top pain point of the current web ecosystem apparently.

And, as of recent years, many times the Chromium team is the first one to implement the newest JS and CSS features and you end up having to drop a feature or include a polyfill due to other browsers not supporting it.

However, as you can tell from the title of this article, that's not always the case, and I'm about to show you an example on how sometimes Chrome does work in weird ways.

The Problem

For a project I'm working on, the designers wanted to include a vertical progress bar divided in small segments with a gradient that went through all of them, basically something like this:

Fortunately, they went for a different idea in the end, but when that was first proposed I was thinking on if there was a way to do this without relying on using images just with CSS.

Eventually, I found out that by using a combination of background-size: cover, background-attachment: fixed, and background-image: linear-gradient(params) in all of the colored segments I could achieve something really close to what I needed.

I was really pleased, I started testing and ended up with the following code:

And while testing this in the browsers I have access to I ended up with this sample

Wait what!? 😵

As you can see, for some reason only Chrome for Android can't display this as intended even when Chrome for Mac OS can.

I found this really weird, I mean, for the most part Chrome for Android and Chrome for Desktop support the same features.

The more I investigated the weirder it got, according to CanIUse Chrome for Android should display it properly while iOS Safari shouldn't, but the tests I did throw completely different results.

Finding the reason

Then I stumbled upon this StackOverflow Question, according to the answer provided here, background-attachment: fixed was actually supported for a while but ended up being dropped due to performance concerns.

I can somewhat understand this, but it still baffled me that iOS Safari (iOS Chrome too since it's basically the same), Firefox for Android, and even IE11 support this while Chrome for Android doesn't.

Conclusions

In the end, I couldn't find another way to achieve this effect for all the browsers I was testing without including images or lots of JS code.

Fortunately I didn't end up needing it, though, if you have other ideas please let me know, I'm curious.

I just wanted to show that, while Chromium is an excellent browser engine and its team does some great work to try to advance what we can do in the web, in the end, they too can decide to just not support something that other browsers do.

Of course, finding examples of this is much much rarer than say finding problems with IE, the old Edge, or Safari, but it still happens and I feel we should never forget about that.

Feel free to post other similar examples in the comments, it's always good to know them.

Differential Serving で必要なコードは2割以上削れる！

Alan Dávalos — Wed, 18 Dec 2019 14:02:46 +0000

Differential Serving と言う技術は実はもう２年ほど前からPhilip Walton さんの記事をきっかけに知る人ぞ知る JS のバンドルサイズを減らせるための技術なんですけど、検索しても、日本語でこのテーマについて話す記事はないので、とりあえずまとめ記事のつもりでこれを書きました、よろしくお願いします！

何のための技術ですか？

今でも IE 11 のサポートを切れないアプリは多いと思います、そう言うアプリを作っている人はほとんど IE 11 を含めた全てのブラウザーにアプリがちゃんと起動できるように ES5 までにコードをコンパイルしていると思います。

しかし、IE 11 のために追加する polyfills や ES5 でコードを書くとどうしても必要になって来る追加コードはビルドされたバンドルを重くします。

どれぐらい重くなるかと言うのはコード次第ですが大体 20%から 30%までになります。

Shubham Kanodia さんがこの記事でいくつかのライブラリーをテストしました

しかも、ユーザー全体のほぼ 90%が ES Modules に対応しています!　つまり、10%のユーザーのために 90%のユーザーに送るコードの量が多くなっています。

それでもその 10%のユーザーを切れないアプリは多いと思います、なんかこう都合良く ES Modules に対応しているユーザーだけにその小さめのコードを送れるためのフロントエンドコードはないのかな…

実はあります、これからそれを紹介します。

もの凄く簡単に言うとこれです

<!-- 主にIE 11のためのJS -->
<script nomodule src="/app.legacy.js"></script>
<!-- 最新ブラウザーのためのJS -->
<script type="module" src="/app.js"></script>

コンセプト的にはアプリのバンドルを二つ用意します。

IE11 などの legacy ブラウザー用の ES5 にコンパイルされたバンドル。
最新ブラウザー用の ES Modules にコンパイルされたバンドル。

ここで重要なのは nomodule と type="module" です、これらを使ってユーザーのブラウザーにどのコードをロードするかの判断を任せます。

`nomodule`と`type="module"`って何ですか？　

nomoduleはscriptタグの属性で ES Modules に対応しているブラウザーにこのコードを無視するように示します。

type="module"は逆にブラウザーにコードは ES Modules で書いてあることを示します。

これらを合わせたサンプルはこれです。

このコードを ES Modules に対応しているブラウザーで見るとこうなります。

見ての通りtype="module"になっているコードだけをダウンロードして実行します。

そして、こちらのサンプルを IE 11 で見るとこうなります。

見ての通りnomoduleになっているコードだけを実行するけど両方をダウンロードしていますね…

そこまで簡単には行かないんですよね

先ほどの例もそうですけど、実は Safari 10 や Firefox 58 や IE 11 や Edge 15-18 などは両方のコードをダウンロードします。

でもこれらはほとんど Wi-Fi でしか使わない PC ブラウザーだからそこまで問題にはならないと思われがちですがタチの悪いことに Safari 10 は両方をダウンロードするだけでなく両方を実行します…

John Stew さんはこちらでいくつかのテストを行ったので詳しくはこれを見てください。

Safari 10 のこの記事を書いている時点でのユーザーの割合は 1%以下ではありますができるだけ多くのユーザーに対応したいのでこれだけだとアウトなんですよね…

じゃもう手詰まり？

実は上記のブラウザーの問題を解決できる方法はあります、しかも、それを都合良くまとめてくれる方法は色々な人気のツールにはすでに入っています。

ツールは何をしていますか？

ツールはこう言ったコードを自動的に書いてくれる。

<!-- これが実際にVue CLIを使うと出て来るコードとほぼ同じものです -->
<script type="module" src="https://example.com/app.js"></script>
<script>
  !(function() {
    var check = document.createElement("script");
    if (!("noModule" in check) && "onbeforeload" in check) {
      var support = false;
      document.addEventListener(
        "beforeload",
        function(e) {
          if (e.target === check) {
            support = true;
          } else if (!e.target.hasAttribute("nomodule") || !support) {
            return;
          }
          e.preventDefault();
        },
        true
      );

      check.type = "module";
      check.src = ".";
      document.head.appendChild(check);
      check.remove();
    }
  })();
</script>
<script
  type="text/javascript"
  src="https://example.com/app.legacy.js"
  nomodule
></script>

これは利用できる範囲の JS の feature の中で Safari 10 を見つけてその場合に module と nomodule の script が両方実行されないように働きかけます。

詳しくはこちらの gistを見てください。

これはあくまで一つのやり方で、こちらではまだ legacy ブラウザーが両方ダウンロードすることになります、これから紹介するツールの中で、それすら解決するものもあるので、自分のプロジェクトに合うものもあると思います。

Vue CLI 3+の場合

Vue CLI を使っているなら話はすごい簡単です、ビルド段階でフラグを一つ追加するだけで済みます。

vue-cli-service build --modern

webpack の場合

webpack を使っているならもう少し設定をいじる必要はあります。

この 2 つのプラグインの内から 1 つをインストールします。
- html-webpack-multi-build-plugin
- webpack-module-nomodule-plugin
次に webpack で ES5 用の設定と ES Modules 用の設定を用意します。こちらの記事の「Generate two bundles」の部分にいい例があります。

Differential Serving

John Stewart ・ May 1 '19

#javascript #performance #webdev
➁ でビルドしたバンドルを ➀ のプラグインに入れます

Rollup の場合

Rollup ではrollup-plugin-index-htmlを使えば簡単にできます。

こちらは性能が良く、設定次第では両方がダウンロードされてしまう問題まで解決できるようになっています。

使い方は先ほどの webpack の使い方に似ています。

Web Components でプロジェクトを作っているなら、先ほどのプラグインを内部で使っているOpen WC の設定がおすすめです。

Web Components のプロジェクトでなくても上記の設定が参考になると思います。

最後に

Differential Serving は個人的に誰もが知っておくべき技術だと思います、これを入れるとまだ legacy ブラウザーを使っているユーザーを犠牲にせず最新ブラウザーを使っているユーザーにもっといい体験をさせられます。いわゆる「Win Win」な話です。

もっと知りたい人には（全て英語の記事ですみません mm）

How to use LitElement in a Vue CLI 3 project

Alan Dávalos — Thu, 13 Jun 2019 13:18:38 +0000

I'm a big fan of web components, I think they are awesome for many different reasons and they are basically what finally got me into liking web front-end development.

However, I'm not here to start another post on how web components are or aren't good, how they will or won't substitute 'X' framework, or anything like that, plenty other people who know more about those topics than me have already discussed that deeply.

I understand how frameworks can be great and how many people already use them successfully in production, but in my opinion the cool part about web components is that they can be used in any framework or with no framework at all, and I'm here to show you a couple of ways a framework (in this case Vue) can coexist with web components (in this case based on LitElement).

Using web components installed from npm

Web components installed from npm don't really need any extra configuration in Vue as long as you only need to support evergreen browsers, nice isn't it?

Now, I know the world isn't all nice and not everyone uses the latest browsers so for info on how to configure the polyfills I would recommend you read this post from Vaadin (by the way, they have a great web components collection).

The actual usage of the components in your Vue CLI 3 app would be something like this:

<template>
  ...
  <awesome-component 
    :attribute="attribute" 
    :property-only.prop="property"
    @an-event="callback"
    ref="awesomeReference"
  >
  </awesome-component>
  ...
</template>
<script>
import 'awesome-component';

export default {...};
</script>

Creating components based on LitElement in a Vue CLI 3 app

I don't really know why you would actually want to do that to be honest but the cool thing is that you just can do it, all you need to do is to add the following to the transpileDependencies property of your vue.config.js after installing LitElement:

module.exports = {
  transpileDependencies: [/node_modules(?:\/|\\)lit-element|lit-html/],
};

This is to explicitly transpile LitElement and lit-html as they only provide es modules exports (for more information check the Vue CLI docs).

And that's it, with that you can create LitElement components in your vue app to your heart's content (just remember, for the polyfills configuration check Vaadin's post out).

On that, if you're using any other base class for web components, this configuration will also be useful, just change the lit-element for your class of choice.

Conclusion

Sometimes as developers we can get so engrossed on proving our technology of choice is supreme that we may forget they can coexist with each other, this is just a reminder that there's no need to fight on whether web components are here to substitute frameworks or not, they're a standard web api that everyone can benefit from and I hope this post motivates more web developers to try them out.

Thank you for reading, this is my first post here at dev so please be nice 😄

Forem: Alan Dávalos

Explaining the new internationalization features in Safari 15.4

Intl.Locale

calendars/collations/hourCycles/numberingSystems/timeZones

textInfo

weekInfo

Browser Support

Intl.DisplayNames

type: 'calendar'

type: 'dateTimeField'

languageDisplay option

Browser Support

Intl.DateTimeFormat

New timeZoneName types

Browser Support

Intl.NumberFormat / Intl.PluralRules

Conclusion

Credits

Where to begin building Web Components? - Class-based Libraries

Introduction

What's the Class-based Pattern About?

Pros and Cons

Pros

Cons

Libraries that Follow this Pattern

CanJS

Fun Facts

HyperHTML Element

Fun Facts

LitElement

Fun Facts

Omi

Fun Facts

SkateJS

Fun Facts

SlimJS

Fun Facts

What's Next?

Where to begin building Web Components? - The Basics

Introduction

What's actually needed to create a Web Component?

Let's "Make it Simpler™"

What's Next?

The Quirks of Shadow DOM and How to Take Advantage of Them

What is Shadow DOM?

1 - How does inheritance work here?

Answer

Why?

2 - Can you style the host?

Answer

Why?

3 - Are CSS variables applied?

Answer

Why?

4 - What happens to the children nodes?

Answer

Why?

5 - Can you style some parts only?

Answer 5

Why?

To Close

More Info

Sometimes Chrome is the problem

The Problem

Wait what!? 😵

Finding the reason

Conclusions

Differential Serving で必要なコードは2割以上削れる！

何のための技術ですか？

もの凄く簡単に言うとこれです

nomoduleとtype="module"って何ですか？

そこまで簡単には行かないんですよね

じゃもう手詰まり？

ツールは何をしていますか？

Vue CLI 3+の場合

webpack の場合

Differential Serving

John Stewart ・ May 1 '19

Rollup の場合

最後に

`Intl.Locale`

`calendars/collations/hourCycles/numberingSystems/timeZones`

`textInfo`

`weekInfo`

`type: 'calendar'`

`type: 'dateTimeField'`

`languageDisplay` option

New `timeZoneName` types

`nomodule`と`type="module"`って何ですか？　