IntersectionObserver VS WHATWG HTML Standard

You should only create the images (or set the src) for the images which are visible to the user. See our infinite scroll example for a naive implementation. More elaborated code might use the https://www.w3.org/TR/intersection-observer/.

I got a little curious on the statuses of these standards and went on a bit of searching.

> CSS contain (CSS Containment Module Level 2) - First published in 2019, still Editor's Draft[1]. Not supported by Safari/WebKit.

> CSS offset-path (Motion Path Module Level 1) - First published in 2015, still Editor's Draft[2]. Not supported by Safari/WebKit.

> CSS overflow-anchor (CSS Scroll Anchoring Module Level 1) - First published in 2020, still Editor's Draft[3]. Not supported by Safari/WebKit.

> Resolution media queries (dppx) - W3C Recommendation since 2012[4]. Not supported by Safari/WebKit.

> :focus-visible (Selectors Level 4) - First published in 2011, still Editor's Draft[5]. Not supported by Safari/WebKit.

- Touch Events - W3C Recommendation since 2013[6]. Supported on iOS 3.2 (2010). I assume the author meant Pointer Events[7] which became W3C recommendation since 2019, and supported on 13.2 (2019).

> BroadcastChannel - WHATWG Living Standard[8]. Blocked by privacy concern on WebKit side since 2020[9]. Initial support landed in WebKit trunk as of 2021-07.[10]

> beforeprint/afterprint - WHATWG Living Standard[11]. Supported by Safari/WebKit since 2019 (iOS 13).

> Regex Lookbehind - ECMAScript 2018[12]. Not supported by Safari/WebKit.

> scrollIntoView (CSSOM View Module) - First introduced in CSSOM View Module since 2011, still Editor's Draft[13]. Not supported by Safari/WebKit.

> Screen Orientation API - First committed in wc3/screen-orientation in 2012, still a W3C Working Draft[14]. Not supported by Safari/WebKit.

> Date and time input types - WHATWG Living Standard[15], partial support by Safari/WebKit since 2012 (iOS 5) but no week/min/max.

> Service Workers - W3C Candidate Recommendation since 2019[16]. Supported by Safari/WebKit since 2018 (iOS 14.5).

- AbortSignal - WHATWG Living Standard[17]. Supported by Safari/WebKit since 2018 (iOS 11.3)

- Intersection Observer - First published in 2017, still W3C Working Draft[18]. Supported by Safari/WebKit since 2019 (iOS 12.2).

- Client-side form validation - WHATWG Living Standard[19]. Supported by Safari/WebKit since 2017 (iOS 10.3).

[1]: https://drafts.csswg.org/css-contain/#contain-property

[2]: https://drafts.fxtf.org/motion/#offset-path-property

[3]: https://drafts.csswg.org/css-scroll-anchoring/#exclusion-api

[4]: https://www.w3.org/TR/css3-mediaqueries/#resolution

[5]: https://drafts.csswg.org/selectors-4/#the-focus-visible-pseu...

[6]: https://www.w3.org/TR/touch-events/

[7]: https://www.w3.org/TR/pointerevents/

[8]: https://html.spec.whatwg.org/multipage/web-messaging.html#br...

[9]: https://github.com/whatwg/html/issues/5803

[10]: https://bugs.webkit.org/show_bug.cgi?id=227924

[11]: https://html.spec.whatwg.org/multipage/timers-and-user-promp...

[12]: https://262.ecma-international.org/9.0/

[13]: https://drafts.csswg.org/cssom-view/#dom-element-scrollintov...

[14]: https://www.w3.org/TR/screen-orientation/

[15]: https://html.spec.whatwg.org/multipage/input.html#date-state...

[16]: https://www.w3.org/TR/service-workers/

[17]: https://dom.spec.whatwg.org/#abortsignal

[18]: https://www.w3.org/TR/intersection-observer/

[19]: https://html.spec.whatwg.org/multipage/forms.html#client-sid...

W3.Org

I've used https://github.com/w3c/IntersectionObserver/tree/main/polyfill in the past and it's pretty much just import and forget.

// app/javascript/controllers/infinite_scoll_controller.js import { Controller } from "stimulus" export default class extends Controller { static targets = ["scrollArea", "pagination"] connect() { this.createObserver() } createObserver() { const observer = new IntersectionObserver( entries => this.handleIntersect(entries), { // https://github.com/w3c/IntersectionObserver/issues/124#issuecomment-476026505 threshold: [0, 1.0], } ) observer.observe(this.scrollAreaTarget) } handleIntersect(entries) { entries.forEach(entry => { if (entry.isIntersecting) { this.loadMore() } }) } loadMore() { const next = this.paginationTarget.querySelector("[rel=next]") if (!next) { return } const href = next.href fetch(href, { headers: { Accept: "text/vnd.turbo-stream.html", }, }) .then(r => r.text()) .then(html => Turbo.renderStreamMessage(html)) .then(_ => history.replaceState(history.state, "", href)) } }

import { Controller } from "stimulus" export default class extends Controller { static targets = ["entry"] static values = { path: String, } connect() { this.createObserver(); } createObserver() { let observer; let options = { // https://github.com/w3c/IntersectionObserver/issues/124#issuecomment-476026505 threshold: [0, 1.0] }; observer = new IntersectionObserver(entries => this.handleIntersect(entries), options); observer.observe(this.entryTarget); } handleIntersect(entries) { entries.forEach(entry => { if (entry.isIntersecting) { // https://github.com/turbolinks/turbolinks/issues/219#issuecomment-376973429 history.replaceState(history.state, "", this.pathValue); } }); } }

WHAT-WG HTML

There's a long-standing WHATWG feature request open for it here: https://github.com/whatwg/html/issues/2791

And several userland custom element implementation, like https://www.npmjs.com/package//html-include-element

One of the cool things that you can do with client-side includes and shadow DOM is render the included HTML into a shadow root that has s, so that the child content of the include element is slotted into a shell implemented by the included HTML.

This lets you do things like have the main page be the pre-page content and the included HTML be a heavily cached site-wide shell, and then another per-user include with personalized HTML - all cached appropriately.

The `allow` attribute on iframes is a relatively recent API addition from 2017

https://github.com/whatwg/html/pull/3287

I think there's a pretty strong argument at this point for this kind of replacing DOM with a response behavior being part of the platform.

I think the first step would be an element that lets you load external content into the page declaratively. There's a spec issue open for this: https://github.com/whatwg/html/issues/2791

And my custom element implementation of the idea: https://www.npmjs.com/package/html-include-element

Then HTML could support these elements being targets of links.

> Consider https://www.ietf.org/rfc/rfc1866.txt vs https://html.spec.whatwg.org/multipage/

I thought, oh, that's not so bad. Then I realized what I was looking at was a 10 page index.

I'd love to see something like HTMX get standardized, but I'm extremely pessimistic for HTMX's prospects for standardization in HTML.

In talking to a few standards folks about it, they've all said, "oh, yeah, you want declarative AJAX; people have tried and failed to get that standardized for years." Even just trying to get

to target a section of the page that isn't an has been argued about and hashed out for years.<p>Why is that? Well, for example, here's the form you have to fill out to start standardizing a front-end feature. <a href="https://github.com/whatwg/html/issues/new?assignees=&labels=addition%2Fproposal%2Cneeds+implementer+interest&projects=&template=1-new-feature.yml">https://github.com/whatwg/html/issues/new?assignees=&labels=...</a><p>It asks three main questions:<p>* What problem are you trying to solve?

The issue with a single global event handler is discussed here: https://github.com/WICG/close-watcher#a-single-event

If you use popover="", you get the kind of functionality you're discussing for free. For

, the discussion is in progress and reaching a conclusion: https://github.com/whatwg/html/issues/9373