In this week’s roundup of platform news, Chrome introduces a new attribute for loading, accessibility specifications for web developers, and the BBC moves visualizations to the Shadow DOM.
Chrome ships the loading attribute
The HTML loading attribute for lazy-loading images and iframes is now supported in Chrome. You can add loading="lazy" to defer the loading of images and iframes that are below the viewport until the user scrolls near them.
Google suggests either treating this feature as a progressive enhancement or using it on top of your existing JavaScript-based lazy-loading solution.
This feature has not yet been added to the HTML Standard (but there is an open pull request), and multiple links to Google’s documentation are listed on its Chrome Status page. (via web.dev)
Overview of ARIA specifications
The main accessibility specifications for web developers:
| Name | Description |
|---|---|
| ARIA in HTML | Defines which ARIA role, state, and property attributes are allowed on which HTML elements (the implicit ARIA semantics are defined here) |
| Using ARIA | Provides practical advice on how to use ARIA in HTML, with an emphasis on dynamic content and advanced UI controls (the “five rules of ARIA use” are defined here) |
| ARIA (Accessible Rich Internet Applications) | Defines the ARIA roles, states, and properties |
| ARIA Authoring Practices | Provides general guidelines on how to use ARIA to create accessible apps (includes ARIA implementation patterns for common widgets) |
| HTML Accessibility API Mappings | Defines how browsers map HTML elements and attributes to the operating system’s accessibility APIs |
| WCAG (Web Content Accessibility Guidelines) | Provides guidelines for making web content more accessible (success criteria for WCAG conformance are defined here) |
Related: “Contributing to the ARIA Authoring Practices Guide” by Simon Pieters and Valerie Young
Shadow DOM on the BBC website
The BBC has moved from <iframe>to Shadow DOM for the embedded interactive visualizations on its website. This has resulted in significant improvements in load performance (“more than 25% faster”).
The available Shadow DOM polyfills didn’t reliably prevent styles from leaking across the Shadow DOM boundary, so they decided to instead fall back to <iframe> in browsers that don’t support Shadow DOM.
Shadow DOM […] can deliver content in a similar way to iframes in terms of encapsulation but without the negative overheads […] We want encapsulation of an element whose content will appear seamlessly as part of the page. Shadow DOM gives us that without any need for a custom element.
One major drawback of this new approach is that CSS media queries can no longer be used to conditionally apply styles based on the content’s width (since the content no longer loads in a separate, embedded document).
With iframes, media queries would give us the width of our content; with Shadow DOM, media queries give us the width of the device itself. This is a huge challenge for us. We now have no way of knowing how big our content is when it’s served.
(via Toby Cox)
In other news…
- The next version of Chrome will introduce the Largest Contentful Paint performance metric; this new metric is a more accurate replacement for First Meaningful Paint, and it measures when the largest element is rendered in the viewport (usually, the largest image or paragraph of text) (via Phil Walton)
- Microsoft has created a prototype of a new tool for viewing a web page’s DOM in 3D; this tool is now experimentally available in the preview version of Edge (via Edge DevTools)
- Tracking prevention has been enabled by default in the preview versions of Edge; it is set to balanced by default, which “blocks malicious trackers and some third-party trackers” (via Techdows)
Read more news in my new, weekly Sunday issue. Visit webplatform.news for more information.
It would be very nice to see native lazyload is stable. I am looking forward to it. I believe it will become more popular after Google Chrome started to support it.
As I understood it, loading=”lazy” is actually the default behaviour. So Devs don’t have to do anything at all unless they want to stop it from happening?
I wish. Google’s article is not very clear on that, but browsers unfortunately load all images eagerly (demo). That is the whole reason why the
loadingattribute was needed to begin with, and Google’ article could have explained that better, IMHO.I think the whole point is that Chrome is going to stop eager loading and lazyload by default.
I can’t remember where I saw it (Possibly Addy on Twitter) but there are a feq articles out there which suggest it should be default in v75.
https://www.androidpolice.com/2019/04/08/google-chrome-to-support-lazy-loading-by-default-starting-with-version-75/
https://hexus.net/tech/news/software/129404-google-chrome-75-support-lazy-loading-default/
See https://twitter.com/addyosmani/status/1161712160466034694.
This is actually what I was thinking of: https://addyosmani.com/blog/lazy-loading/
The default is ‘auto’ which will normally load images in the viewport and lazyload anything below.
So it seems to me that devs don’t actually have to do anything at all and the default may actually be the best option rather than lazyloading everything whether it’s in the viewport or not.
This means, the browser is free to choose whether it wants to lazy-load by default or not.
If you follow the link to Twitter that I posted above, you will see a tweet by Addy that says, “The default value is eager,” meaning, Chrome does not lazy-load by default.