[resize-observer] Which boxes should we be able to observe?

[gregwhitworth]

In Sydney it was resolved that authors should be able to observe more than the content box of an element. That then leads to which boxes should be able to be observed. The initial ones were quickly agreed upon such as border-box, content-box, and scroll-box.

Is there any other boxes that people have legitimate use cases for observing?

[atotic]

device-pixel-border-box size

device-pixel-border-box size is Element's border-box size in device pixels.
It is always an integer, as there are no fractional device pixels.
It can currently be approximated by Math.round(borderBoxSize * window.devicePixelRatio), but it cannot be computed exactly, because native code uses a different rounding algorithm.

Use case

This unusual size request comes from Chrome's WebGL canvas team. It solves the long standing WebGL developers problem: "How to create HiDPI canvas without moire pattern?".

The existing "best practice" for creating a HiDPI canvas is to set size of canvas context to a multiple of canvas's css width/height. Example:

let cssWidth = 300, cssHeight = 200;
let c = document.querySelector('canvas');
c.style.width = cssWidth + "px";
c.style.height = cssHeight + "px";
let ctx = c.getContext("webgl2");
ctx.width = cssWidth * window.devicePixelRatio;
ctx.height = cssHeight * window.devicePixelRatio;

The webgl context will be HiDPI, one one canvas pixel should correspond to one device pixel.
But, because ctx.width is pixel snapped, ctx.width can differ from "true" device pixel width. This difference can cause visible moire patterns when rendered.

Because of this, WebGL team believes that web platform needs to provide an API for true device pixel width.

Discussion

This size has several interesting differences from others reported by ResizeObserver:

• use case is narrow: only useful for canvas Elements.
• changing only Element's position, not size, can cause device-pixel-size to change.

Q: Does this size belong to ResizeObserver, or should we create a diferent DOM API for it?

I can't think of a clean API that would provide same functionality. Web developers must observe this size, and respond to its changes. ResizeObserver is the only size-observing API. Observing border-box size, and providing "devicePixelSize()" method will not work, because devicePixelSize could change without border-box changing.

Q: Should we observe device-pixel-size on all elements, or just canvas?

Observing device-pixel-size comes with performance cost, because size must be checked when Element's position changes. For all other sizes, we do not need to check size when position changes.
Weak preference: Only allow device-pixel-size observation for canvas.

Q: Should we report device-pixel-size on all elements, or just canvas?

Weak preference: make it canvas-only, because other elements cannot observe this size.

[atotic]

Verbal comment by @bfgeek about observing 'scroll-box':

Ian mentioned that there is an interesting implementation difference between scroll-box and content-box/border-box. This might be an argument against adding scroll-box.

scroll-box can be affected by compositor animations, and in the future, Chrome might want to modify scroll-box without performing style/layout. For example, if there is a css animation that affects scrollbar, animation and scrollbars can be repainted in the compositor thread without performing style/layout on the main thread. Edge already does this.

If we were to add ability to watch scroll-box, then scrollbox animations would have to be performed back on the main thread, so that RO callbacks can be called. Or we could say that RO callback will not get called if scroll-box changes on the compositor thread...

[css-meeting-bot]

The CSS Working Group just discussed Which boxes should an author be able to observe?, and agreed to the following:

• RESOLVED: only content and border boxes

The full IRC log of that discussion

<emilio> Topic: Which boxes should an author be able to observe?
<emilio> github: https://github.com//issues/3326
<emilio> gregwhitworth: what this comes down to is: We want to observe more boxes, v1 has only content box, and then webdevs were confused about that, so we wanted to add the capability to declare which box you'r able to observe
<emilio> gregwhitworth: we had the scrollBox, but we don't have any great use-case, so we'd say contentBox and borderBox
<emilio> Rossen: at some point there was padding / margin / scroll
<emilio> gregwhitworth: content and border are the only two I'd like to propose
<emilio> Rossen: comments / objections?
<emilio> RESOLVED: only content and border boxes

[kenrussell]

Thanks for the notes - does this mean that observing the device-pixel-border-box size will be allowed, at least for Canvas elements? This feature is needed in order to perform pixel-accurate WebGL and Canvas 2D rendering - there is no other way to get the information from the browser, and we would love to solve this longstanding rendering problem on the web.

[emilio]

That is #3554, which will be discussed today I guess.

[gregwhitworth]

To summarize the above issue, the agreed and resolved upon boxes that can be observed are:

• border-box
• content-box

With regards to the device-pixel-border-box it is still an open issue and being discussed in #3554 and until there is agreement on the approach it will be removed from the spec.