We allowed @mozilla.org WebExtensions to use the '-moz-context-properties' property in bug 1379464. There's the question of whether we should allow all WebExtensions to use '-moz-context-properties': https://bugzilla.mozilla.org/show_bug.cgi?id=1367042 In case you're not familiar with it, 'context-properties' is specified on an element that may embed an SVG image. It list the properties on the embedding element that should have their values exposed to the embedded SVG (e.g. to allow the 'context-fill' value in the SVG to resolve to the computed value for the property on the embedding element). I don't really like that '-moz-context-properties' takes a list of properties, not least because it means that it is not a general solution for exposing properties to a sub-document/image. Specifically, at some point we may want to support exposing a property where an author may want to set one value to affect the embedding element, while also wanting to expose a different value for that same property to the embedded content. The '-moz-context-properties' mechanism doesn't allow for that since it only allows for one value. Maybe '-moz-context-properties' could be a list of properties *and* their values? I'm not sure if our CSS implementation does/could support that. It would also require a keyword (or something) to say "use the current computed value of the property". Or maybe we could change the list of properties to be semicolon separated instead of comma separated, which could give us more flexibility in future to have the list contain either just a property name, or a property name along with a value. heycam, dbaron, any thoughts?
(In reply to Jonathan Watt [:jwatt] from comment #0) > Maybe '-moz-context-properties' could be a list of properties *and* their > values? I'm not sure if our CSS implementation does/could support that. It > would also require a keyword (or something) to say "use the current computed > value of the property". It would be easy enough to make the property support values like "fill, stroke red", for example, would we mean "allow context-fill in the referenced image to refer to the computed value of fill on the referencing element, and make content-stroke just be 'red'". But I think the mechanism here is pretty limited, since all we can do is describe which properties that context-* values are allowed to see/use. I've always thought that it would be great if we could use CSS Custom Properties as the mechanism to pass arbitrary values into referenced content. We do something like this for SVG glyphs in OpenType, where the OpenType tables describe a set of custom properties (all named --color0, --color1, etc.) that can then be referenced with var(--color0) etc. in the glyph document. See also CSS Fonts 4's @font-palette-values rule / font-palette property mechanism which allows defining a named set of palette values to pass into a font (both SVG and COLR/CPAL glyphs). > Or maybe we could change the list of properties to be semicolon separated > instead of comma separated, which could give us more flexibility in future > to have the list contain either just a property name, or a property name > along with a value. Semicolon separation probably isn't going to work in a property value when semicolons separate declarations in a style sheet. A solution similar to @font-palette-values / font-palette could work here, though at this point we're re-investigating the various SVG parameterizations solutions we've come up with over the years. Maybe it's time to settle on one. I would probably rather solidify a general solution than -moz-context-properties.
So after failing to answer this question the first few times I looked at it, I suppose my thoughts are that -moz-context-properties seems like a strange thing at first glance. Did context-fill and context-stroke originate with SVG-in-OpenType, and then this was a solution to allow them to be used elsewhere? Is there a document somewhere that describes why it exists and what problems it is solving? (For example, why you wouldn't want to just allow context-fill and context-stroke by default?) I think in order to form a better opinion here I'd need more background about why -moz-context-properties exists -- something I hope exists in writing somewhere.
We should probably WONTFIX this (and remove the code at some point) and focus on bug 1421329 instead. All the same, replying to comment 2 for completeness. (In reply to David Baron :dbaron: ⌚️UTC-8 from comment #2) > Did context-fill and context-stroke originate with > SVG-in-OpenType, and then this was a solution to allow them to be used > elsewhere? Exactly that. The solution to allow colors to be passed through into embedded SVG images was initially implemented in bug 1058040. That add support for passing through the values of the 'fill' and 'stroke' properties from the embedding element. To allow this to ride the trains for the frontend code to use without exposing it to the Web the -moz-context-properties mechanism to restrict use was added in bug 1350010 (with a follow-up in bug 1360662). > Is there a document somewhere that describes why it exists and > what problems it is solving? (For example, why you wouldn't want to just > allow context-fill and context-stroke by default?) Mostly the comments in bug 1350010. For that specific question the original idea was to prevent leakage from embedding document to embedded document without the embedded document opting-in, but later the reason became because that's the only way to restrict use of the feature (we know enough to restrict use of -moz-context-properties on the embedding side, but on the embedded side we don't know enough to be able to restrict use of context-fill/context-stroke - some Firefox frontend code is hard to distinguish from webpages). > I think in order to form > a better opinion here I'd need more background about why > -moz-context-properties exists -- something I hope exists in writing > somewhere.
`context‑fill` and `context‑paint` are part of the SVG 2 specification (https://svgwg.org/svg2-draft/painting.html#SpecifyingPaint), so Firefox could at least set those two for WebExtension icons which are shown in the browser UI (i.e.: at least browser action and page action icons).
You need to log in before you can comment on or make changes to this bug.