HTML Internet Parts Make Progressive Enhancement and CSS Encapsulation Simpler!

I’ve to thank Jeremy Keith and his splendidly insightful article from late final 12 months that launched me to the idea of HTML Internet Parts. This was the “a-ha!” second for me:

If you wrap some current markup in a customized component after which apply some new behaviour with JavaScript, technically you’re not doing something you couldn’t have achieved earlier than with some DOM traversal and occasion dealing with. But it surely’s much less fragile to do it with an online element. It’s moveable. It obeys the only duty precept. It solely does one factor but it surely does it nicely.

Till then, I’d been underneath the false assumption that all internet parts rely solely on the presence of JavaScript along with the quite scary-sounding Shadow DOM. Whereas it’s certainly potential to writer internet parts this manner, there may be yet one more approach. A greater approach, maybe? Particularly in case you, like me, advocate for progressive enhancement. HTML Internet Parts are, in spite of everything, simply HTML.

Whereas it’s outdoors the precise scope of what we’re discussing right here, Any Bell has a current write-up that gives his (glorious) tackle what progressive enhancement means.

Let’s take a look at three particular examples that exhibit what I believe are the important thing options of HTML Internet Parts — CSS type encapsulation and alternatives for progressive enhancement — with out being compelled to rely on JavaScript to work out of the field. We are going to most positively use JavaScript, however the parts must work with out it.

The examples can all be present in my Internet UI Boilerplate element library (constructed utilizing Storybook), together with the related supply code in GitHub.

Instance 1: <webui-disclosure>

Reside demo

I actually like how Chris Ferdinandi teaches constructing an online element from scratch, utilizing a disclosure (present/conceal) sample for instance. This primary instance extends his demo.

Let’s begin with the first-class citizen, HTML. Internet parts permit us to ascertain customized parts with our personal naming, which is the case on this instance with a <webui-disclosure> tag we’re utilizing to carry a <button> designed to point out/conceal a block of textual content and a <div> that holds the <p> of textual content we wish to present and conceal.

<webui-disclosure
data-bind-escape-key
data-bind-click-outside
>
<button
sort=”button”
class=”button button–text”
data-trigger
hidden
>
Present / Cover
</button>

<div data-content>
<p>Content material to be proven/hidden.</p>
</div>
</webui-disclosure>

If JavaScript is disabled or doesn’t execute (for any variety of potential causes), the button is hidden by default — because of the hidden attribute on it— and the content material inside the div is solely displayed by default.

Good. That’s a extremely easy instance of progressive enhancement at work. A customer can view the content material with or with out the <button>.

I discussed that this instance extends Chris Ferdinandi’s preliminary demo. The important thing distinction is you could shut the component both by clicking the keyboard’s ESC key or clicking wherever outdoors the component. That’s what the 2 [data-attribute]s on the <webui-disclosure tag are for.

We begin by defining the customized component in order that the browser is aware of what to do with our made-up tag title:

customElements.outline(‘webui-disclosure’, WebUIDisclosure);

Customized parts should be named with a dashed-ident, corresponding to <my-pizza> or no matter, however as Jim Neilsen notes, by the use of Scott Jehl, that doesn’t precisely imply that the sprint has to go between two phrases.

I sometimes choose utilizing TypeScript for writing JavaScript to assist get rid of silly errors and implement some extent of “defensive” programming. However for the sake of simplicity, the construction of the net element’s ES Module seems to be like this in plain JavaScript:

default class WebUIDisclosure extends HTMLElement {
constructor()

setupA11y() {
// Add ARIA props/state to button.
}

// Deal with constructor() occasion listeners.
handleEvent(e) {
// 1. Toggle visibility of content material.
// 2. Toggle ARIA expanded state on button.
}

// Deal with occasion listeners which aren’t a part of this Internet Element.
connectedCallback() {
doc.addEventListener(‘keyup’, (e) => {
// Deal with ESC key.
});

doc.addEventListener(‘click on’, (e) => {
// Deal with clicking outdoors.
});
}

disconnectedCallback() {
// Take away occasion listeners.
}
}

Are you questioning about these occasion listeners? The primary one is outlined within the constructor() operate, whereas the remaining are within the connectedCallback() operate. Hawk Ticehurst explains the rationale far more eloquently than I can.

This JavaScript isn’t required for the net element to “work” but it surely does sprinkle in some good performance, to not point out accessibility issues, to assist with the progressive enhancement that enables the <button> to point out and conceal the content material. For instance, JavaScript injects the suitable aria-expanded and aria-controls attributes enabling those that depend on display screen readers to know the button’s goal.

That’s the progressive enhancement piece to this instance.

For simplicity, I’ve not written any extra CSS for this element. The styling you see is solely inherited from current international scope or element kinds (e.g., typography and button).

Nevertheless, the subsequent instance does have some additional scoped CSS.

Instance 2: <webui-tabs>

That first instance lays out the progressive enhancement advantages of HTML Internet Parts. One other profit we get is that CSS kinds are encapsulated, which is a flowery approach of claiming the CSS doesn’t leak out of the element. The kinds are scoped purely to the net element and people kinds is not going to battle with different kinds utilized to the present web page.

Let’s flip to a second instance, this time demonstrating the type encapsulating powers of internet parts and how they assist progressive enhancement in person experiences. We’ll be utilizing a tabbed element for organizing content material in “panels” which might be revealed when a panel’s corresponding tab is clicked — the identical kind of factor you’ll discover in lots of element libraries.

Reside demo

Beginning with the HTML construction:

<webui-tabs>
<div data-tablist>
<a href=”#tab1″ data-tab>Tab 1</a>
<a href=”#tab2″ data-tab>Tab 2</a>
<a href=”#tab3″ data-tab>Tab 3</a>
</div>

<div id=”tab1″ data-tabpanel>
<p>1 – Lorem ipsum dolor sit amet consectetur.</p>
</div>

<div id=”tab2″ data-tabpanel>
<p>2 – Lorem ipsum dolor sit amet consectetur.</p>
</div>

<div id=”tab3″ data-tabpanel>
<p>3 – Lorem ipsum dolor sit amet consectetur.</p>
</div>
</webui-tabs>

You get the concept: three hyperlinks styled as tabs that, when clicked, open a tab panel holding content material. Observe that every [data-tab] within the tab record targets an anchor hyperlink matching a tab panel ID, e.g., #tab1, #tab2, and many others.

We’ll take a look at the type encapsulation stuff first since we didn’t go there within the final instance. Let’s say the CSS is organized like this:

webui-tabs {
[data-tablist] {
/* Default kinds with out JavaScript */
}

[data-tab] {
/* Default kinds with out JavaScript */
}

[role=’tablist’] {
/* Fashion position added by JavaScript */
}

[role=’tab’] {
/* Fashion position added by JavaScript */
}

[role=’tabpanel’] {
/* Fashion position added by JavaScript */
}
}

See what’s occurring right here? We now have two type guidelines — [data-tablist] and [data-tab] — that comprise the net element’s default kinds. In different phrases, these kinds are there no matter whether or not JavaScript masses or not. In the meantime, the opposite three type guidelines are selectors which might be injected into the element so long as JavaScript is enabled and supported. This manner, the final three type guidelines are solely utilized if JavaScript plops the **position** attribute on these parts within the HTML. Proper there, we’re already supplying a contact of progressive enhancement by setting kinds solely when JavasScript is required.

All these kinds are totally encapsulated, or scoped, to the <webui-tabs> internet element. There is no such thing as a “leakage” so to talk that might bleed into the kinds of different internet parts, and even to the rest on the web page inside the international scope. We are able to even select to forego classnames, advanced selectors, and methodologies like BEM in favour of easy descendent selectors for the element’s kids, permitting us to put in writing kinds extra declaratively on semantic parts.

Rapidly: “Mild” DOM versus Shadow DOM

For many internet initiatives, I usually choose to bundle CSS (together with the internet element Sass partials) right into a single CSS file in order that the element’s default kinds can be found within the international scope, even when the JavaScript doesn’t execute.

Nevertheless, it’s potential to import a stylesheet through JavaScript that’s solely consumed by this internet element if JavaScript is obtainable:

import kinds from ‘./kinds.css’;

class WebUITabs extends HTMLElement {
constructor() {
tremendous();
this.adoptedStyleSheets = [styles];
}
}

customElements.outline(‘webui-tabs’, WebUITabs);

Alternatively, we may inject a <type> tag containing the element’s kinds as an alternative:

class WebUITabs extends HTMLElement {
connectedCallback() {
this.attachShadow({ mode: ‘open’ }); // Required for JavaScript entry
this.shadowRoot.innerHTML = `
<type> <!– kinds go right here –> </type>
// and many others.
`;
}
}

customElements.outline(‘webui-tabs’, WebUITabs);

Whichever technique you select, these kinds are scoped on to the net element, stopping element kinds from leaking out, however permitting international kinds to be inherited.

Now contemplate this straightforward instance. Every thing we write in between the element’s opening and shutting tags is taken into account a part of the “Mild” DOM.

<my-web-component>
<!– That is Mild DOM –>
<div>
<p>Some content material… kinds are inherited from the worldwide scope</p>
</div>

———– Shadow DOM Boundary ————-
| <!– Something injected by JavaScript –> |
———————————————
</my-web-component>

Dave Rupert has a wonderful write-up that makes it very easy to see how exterior kinds are in a position to “pierce” the Shadow DOM and choose a component within the Mild DOM. Discover how the <button> component that’s written in between the customized component’s tags receives the button selector’s kinds within the international CSS, whereas the <button> injected through JavaScript is left untouched.

If we wish to type the Shadow DOM <button> we’d have to try this with inner kinds just like the examples above for importing a stylesheet or injecting an inline <type> block.

That doesn’t imply that all CSS type properties are blocked by the Shadow DOM. The truth is, Dave outlines 37 properties that internet parts inherit, largely alongside the traces of textual content, record, and desk formatting.

Progressively improve the tabbed element with JavaScript

Although this second instance is extra about type encapsulation, it’s nonetheless a superb alternative to see the progressive enhancement we get virtually without spending a dime from internet parts. Let’s step into the JavaScript now so we are able to see how we are able to assist progressive enhancement. The total code is kind of prolonged, so I’ve abbreviated issues a bit to assist make the factors slightly clearer.

default class WebUITabs extends HTMLElement {
constructor() {
tremendous();
this.tablist = this.querySelector(‘[data-tablist]’);
this.tabpanels = this.querySelectorAll(‘[data-tabpanel]’);
this.tabTriggers = this.querySelectorAll(‘[data-tab]’);

if (
!this.tablist ||
this.tabpanels.size === 0 ||
this.tabTriggers.size === 0
) return;

this.createTabs();
this.tabTriggers.forEach((tabTrigger, index) => {
tabTrigger.addEventListener(‘click on’, (e) => {
this.bindClickEvent(e);
});
tabTrigger.addEventListener(‘keydown’, (e) => {
this.bindKeyboardEvent(e, index);
});
});
}

createTabs() {
// 1. Cover all tabpanels initially.
// 2. Add ARIA props/state to tabs & tabpanels.
}

bindClickEvent(e) {
e.preventDefault();
// Present clicked tab and replace ARIA props/state.
}
bindKeyboardEvent(e, index) {
e.preventDefault();
// Deal with keyboard ARROW/HOME/END keys.
}
}

customElements.outline(‘webui-tabs’, WebUITabs);

The JavaScript injects ARIA roles, states, and props to the tabs and content material blocks for display screen reader customers, in addition to additional keyboard bindings so we are able to navigate between tabs with the keyboard; for instance, the TAB key’s reserved for accessing the element’s lively tab and any focusable content material contained in the lively tabpanel, and the tabs might be traversed with the ARROW keys. So, if JavaScript fails to load, the default expertise continues to be an accessible one the place the tabs nonetheless anchor hyperlink to their respective panels, and people panels naturally stack vertically, one on prime of the opposite.

And if JavaScript is enabled and supported? We get an enhanced expertise, full with up to date accessibility issues.

Instance 3: <webui-ajax-loader>

Reside demo

This last instance differs from the earlier two in that it’s solely generated by JavaScript, and makes use of the Shadow DOM. It’s because it’s only used to point a “loading” state for Ajax requests, and is due to this fact solely wanted when JavaScript is enabled.

The HTML markup is simply the opening and shutting element tags:

<webui-ajax-loader></webui-ajax-loader>

The simplified JavaScript construction:

default class WebUIAjaxLoader extends HTMLElement {
constructor() {
tremendous();
const shadow = this.attachShadow({ mode: ‘open’ });
shadow.innerHTML = `
<svg position=”img” half=”svg”>
<title>loading</title>
<circle cx=”50″ cy=”50″ r=”47″ />
</svg>
`;
}
}

customElements.outline(‘webui-ajax-loader’,WebUIAjaxLoader);

Discover proper out of the gate that every little thing in between the <webui-ajax-loader> tags is injected with JavaScript, that means it’s all within the Shadow DOM, encapsulated from different scripts and kinds in a roundabout way bundled with the element.

But in addition discover the half attribute that’s set on the <svg> component. Right here’s the place we’ll zoom in:

<svg position=”img” half=”svg”>
<!– and many others. –>
</svg>

That’s yet one more approach we’ve to type the customized component: named elements. Now we are able to type that SVG from outdoors of the template literal we used to ascertain the component. There’s a ::half pseudo-selector to make that occur:

webui-ajax-loader::half(svg) {
// Shadow DOM kinds for the SVG…
}

And right here’s one thing cool: that selector can entry CSS customized properties, whether or not they’re scoped globally or domestically to the component.

webui-ajax-loader {
–fill: orangered;
}

webui-ajax-loader::half(svg) {
fill: var(–fill);
}

So far as progressive enhancement goes, JavaScript provides the entire HTML. Which means the loader is just rendered if JavaScript is enabled and supported. And when it’s, the SVG is added, full with an accessible title and all.

Wrapping up

That’s it for the examples! What I hope is that you just now have the identical kind of epiphany that I had when studying Jeremy Keith’s publish: HTML Internet Parts are an HTML-first function.

In fact, JavaScript does play a giant position, however solely as massive as wanted. Want extra encapsulation? Need to sprinkle in some UX goodness when a customer’s browser helps it? That’s what JavaScript is for and that’s what makes HTML Internet Parts such an incredible addition to the net platform — they depend on vanilla internet languages to do what they had been designed to do all alongside, and with out leaning too closely on one or the opposite.

HTML Internet Parts Make Progressive Enhancement and CSS Encapsulation Simpler! initially printed on CSS-Methods, which is a part of the DigitalOcean household. You need to get the e-newsletter.