CSS Containment and container queries

It looks like CSS containment will finally bring container queries into browsers without the need for a polyfill. This post will discuss the current implementation in Chromium browsers. Note: The specification for container queries hasn’t been finalized. It is possible but unlikely that the specification and the corresponding CSS will change. Don’t use @container in production until the feature is finalized. What problem do container queries solve? Container queries give developers finer control over the layout of components. Rather than using media queries that provide responsiveness based on the viewport state, they give responsiveness based on the parent container or

Asking the user for permission

There are times when you’re using an API when it would be nice to know what’s the permission status is for a given API. The Permission API works around two concepts: permissions and “powerful features” The spec defines a powerful feature as: A feature of a UA that some code might not be allowed to access, for example, because its environment settings object doesn’t satisfy some criteria, or because the user hasn’t given permission. Permissions To describe the features, the API provides a registry for the features and their descriptors. Currently only Push and midi have additional parameters specific to

Writing tree-shakeable code

Tree shaking has become one of the most popular performance features when working with bundlers. The idea behind tree shanking is that: You declare all of your imports and exports for each of your modules Your bundler (Webpack, Rollup, and so on) analyzes your dependency tree during the compilation step Any code that appears not to be used is dropped from the final bundle, or ‘tree-shaken’. That means that our library code should export individual functions rather than classes. It would be tempting to do something like this: export class Number { constructor(num) { this.num = num; } add(otherNum) {

Constructable style sheets

One of the outstanding issues about web components is CSS reuse. Right now we either have to use ::part to create an external stylesheet to match the specified parts of the document or encapsulate styles inside each custom element. ::part works well if all custom elements use the ::part attribute and if all the names are unique accross the document, otherwise we may get unexpected results. We’ve always been able to create style sheets in Javascript but it’s not always a straightforward process. It involves creating a style element, using innerHTML to insert a string containing the CSS we want

Web Components: what they are and where are they?

Web Components are a set of specifications that address one of the biggest shortcomings of HTML. We’re stuck with what the spec says we have and the browser implementors decide to give us… At least that’s the theory. Web Components allow developers to create their own elements along with the styles and scripts associated with the elements. These custom elements would be treated the same as the built-in elements available on browsers, as long as the browser supports the APIs. The early version of the web components family of specifications included the following specifications: Custom Elements HTML Imports Shadow DOM