drawImage should respect -moz-context-properties for a SVG image source
Categories
(Core :: Graphics: Canvas2D, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox136 | --- | fixed |
People
(Reporter: mossop, Assigned: mossop)
References
Details
Attachments
(1 file, 1 obsolete file)
In a chrome document you can have an image element containing an SVG image styled via -moz-context-properties. Using drawImage with this as the source ignores those properties.
Assignee | ||
Comment 1•2 months ago
|
||
Updated•2 months ago
|
Comment 2•2 months ago
|
||
The following patch is waiting for review from a reviewer who resigned from the review:
ID | Title | Author | Reviewer Status |
---|---|---|---|
D232369 | Bug 1937109: Respect -moz-context-properties when using an SVG image as the source for drawImage. r=jfkthame! | mossop | jgilbert: Resigned from review |
:mossop, could you please find another reviewer?
For more information, please visit BugBot documentation.
Assignee | ||
Updated•1 month ago
|
Comment 3•1 month ago
|
||
Hmm, this is an interesting case actually (IMO).... it raises the question of what the "context element" ought to be in such an example. (And the SVG2 spec doesn't seem to help, as it only deals with marker
s and <use>
elements.)
The patch here makes context-fill
and -stroke
use the values from the <img>
element's style, which is one possible interpretation of "context", but ISTM that it would possibly be more useful (and perhaps intuitive?) if "context" referred to the context in which the image is being used, i.e. the paint style of the <canvas>
context when it's being drawn. So then you could have a single <img>
that uses context-*
paint values, and have it paint with different colors depending on the current paint style of the destination where you're drawing it.
This seems more analogous to the (SVG2-defined) case of painting a subtree via a <use>
element, where "the context element is that ‘use’ element", i.e. the context colors are determined separately at each point of use, not constants defined at the source of the thing being (reusably) painted.
WDYT, does this seem worth considering as an alternative design? Or is it nonsensical or unuseful for some reason?
Also cc'ing Robert in case he has any thoughts on this from an SVG perspective (noting that this is outside of anything that's currently spec'd, AFAIK).
Assignee | ||
Comment 4•28 days ago
|
||
Assignee | ||
Comment 5•28 days ago
|
||
(In reply to Jonathan Kew [:jfkthame] from comment #3)
Hmm, this is an interesting case actually (IMO).... it raises the question of what the "context element" ought to be in such an example. (And the SVG2 spec doesn't seem to help, as it only deals with
marker
s and<use>
elements.)The patch here makes
context-fill
and-stroke
use the values from the<img>
element's style, which is one possible interpretation of "context", but ISTM that it would possibly be more useful (and perhaps intuitive?) if "context" referred to the context in which the image is being used, i.e. the paint style of the<canvas>
context when it's being drawn. So then you could have a single<img>
that usescontext-*
paint values, and have it paint with different colors depending on the current paint style of the destination where you're drawing it.This seems more analogous to the (SVG2-defined) case of painting a subtree via a
<use>
element, where "the context element is that ‘use’ element", i.e. the context colors are determined separately at each point of use, not constants defined at the source of the thing being (reusably) painted.
I've put this up as an alternative patch. It turned out to be quite straightforward. I've retained needing to set -moz-context-properties
(though on the canvas element now). See what you think.
Comment 6•27 days ago
|
||
Are we restricting this to Chrome only or mozilla only? jwatt was very reluctant to extend context-fill/stroke outside of what the specification allows (markers and use) which is why everything else is mozilla only i.e. mozilla authored extensions or chrome.
Assignee | ||
Comment 7•27 days ago
|
||
(In reply to Robert Longson [:longsonr] from comment #6)
Are we restricting this to Chrome only or mozilla only? jwatt was very reluctant to extend context-fill/stroke outside of what the specification allows (markers and use) which is why everything else is mozilla only i.e. mozilla authored extensions or chrome.
I was only intending on doing it for chrome only as that is all I need it for.
Comment 8•27 days ago
|
||
Yes, I don't think any of this should be exposed to web content unless we first engage in an appropriate standards discussion. The use of -moz-context-properties
would mean it'd be behind the svg.context-properties.content.enabled
pref (which is disabled by default), but if we switch to a canvas2d attribute (per discussion in the second patch) I assume that'll be declared as chrome-only in the webidl.
Updated•27 days ago
|
Updated•27 days ago
|
Comment 10•26 days ago
|
||
bugherder |
Description
•