Stub out canvas.drawElement() #11588
Conversation
Handwavy things that need fleshing out are marked with 👋
There was a problem hiding this comment.
Glad to see this being worked on, thanks.
Not quite sure how much discussion should be held at this stage. So to note, this doesn't seem to fully match the latest state of https://github.com/WICG/html-in-canvas. e.g. the rename to drawHTMLElement. The layoutsubtree attribute is also missing along with the implications to the existing fallback contents.
Still, thanks for making this move.
| interface mixin <dfn interface>CanvasDrawElement</dfn> { | ||
| // drawing elements | ||
| undefined <span data-x="dom-context-2d-drawElement">drawElement</span>(<span>Element</span> element, unrestricted double x, unrestricted double y); | ||
| undefined <span data-x="dom-context-2d-drawElement">drawElement</span>(<span>Element</span> element, unrestricted double x, unrestricted double y, unrestricted double w, unrestricted double y); |
There was a problem hiding this comment.
Typo here for the latest y argument, which was probably meant to be h.
There was a problem hiding this comment.
Was it explored whether it should get all the cropping options that drawImage has?
|
|
||
| <li><p>If either <var>w</var> or <var>h</var> are zero, then return.</p></li> | ||
|
|
||
| <li><p>👋 Paint <var>element</var> to the specified rectangular area without using any |
There was a problem hiding this comment.
Why limit what can be painted rather than simply tainting the canvas? I guess many use cases won't need any readback.
|
|
||
| <li><p>If <var>usability</var> is <i>bad</i>, then return (without drawing anything).</p></li> | ||
|
|
||
| <li><p>👋 Update the rendering without painting.</p></li> |
There was a problem hiding this comment.
To be clear, that's Recalculate styles and update layout for doc. from the ResizeObserver steps, not the whole update the rendering with all the callbacks?
Should there be some note somewhere that while these element's aren't visible they still are rendered?
edit:
Actually I'm not even sure this step is needed, wouldn't the layout boxes calculation take care of updating the layout? Other methods that do need a layout update don't explicitely call it.
| agent must run these steps:</p> | ||
|
|
||
| <ol> | ||
| <li><p>👋 Let <var>element</var> be the first argument.</p> |
There was a problem hiding this comment.
I believe this can be simplified by doing
The
drawElement(element, x, y, w, h)method steps are: ...
I guess you went copying over drawImage, but that algo is super old and certainly would gain from a style update.
|
|
||
| <li><p>👋 Update the rendering without painting.</p></li> | ||
| <!-- If w/h arguments are given, should that be an input to layout here? | ||
| And if not, is the layout totally unconstrained, infinite width?? --> |
There was a problem hiding this comment.
I would have thought the layout would always be based on the <canvas>'s layout and w and h would act as a "resize". So that even if the content is sized with absolute values, it gets resized the same as the content sized with relative ones.
However one important and complex point here is the pixel-density, which is discussed in WICG/html-in-canvas#30
|
|
||
| <li><p>Let <var>usability</var> be the result of 👋.</p></li> | ||
|
|
||
| <li><p>If <var>usability</var> is <i>bad</i>, then return (without drawing anything).</p></li> |
There was a problem hiding this comment.
Seems a bit harsh to block the rendering entirely when some contents are loading inside of it. For drawImage it made sense to check the usability of the source, but here, the source is the element. It's like drawing an SVG image that embeds an inaccessible <image>. The accessible part of the SVG is still painted.
Handwavy things that need fleshing out are marked with 👋
(See WHATWG Working Mode: Changes for more details.)
/canvas.html ( diff )
/index.html ( diff )