1388193 - Consider allowing the '-moz-context-properties' property to be used by all WebExtension

Status: RESOLVED WONTFIX

(Core :: CSS Parsing and Computation, enhancement, P3)

Description

[Jonathan Watt [:jwatt]]

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?

Comment 1

[Cameron McCormack (:heycam)]

(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.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 3

[Jonathan Watt [:jwatt]]

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.

Comment 4

[ExE Boss]

`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).

Comment 5

[ariasuni]

Any news on this?

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1388193 - Enable context-properties for extensions. r=jwatt

I was writing an extension today, and I
was a bit annoyed that the state of the art to support light and dark themes
means I need eigth (!) variants of each icon (disabled/enabled/hovered/active *
light/dark).

I'm not 100% sure it is worth it, both because of the concerns in the bug, and
because other browsers don't support this, and thus add-on developers that would
want their extension to work in every browser would still need to do the eigth
icons...

But I wrote it so I may as well submit it; your call whether we should take
this. There doesn't seem to be any progress on the alternatives both spec and
implementation-wise.

Comment 7

[ariasuni]

because other browsers don't support this, and thus add-on developers that would
want their extension to work in every browser would still need to do the eigth
icons...

Well, a lot of cross-platform extensions already handle a few use cases and I’m pretty sure it’s possible to use a fallback.

In my use case (Tab Center Reborn, but IIRC Tree Style Tab has the same problem with icons), the extension is already Firefox-only because it uses and needs APIs not available in other browsers, and it would make it easier for me to provide icons using the theme colors and so always readable and which feels native/quantum.

Comment 8

[Daniel Holbert [:dholbert]]

I think we can WONTFIX this, now that we have a working-group-approved approach that's being tracked in bug 1782815. (See https://github.com/w3c/csswg-drafts/issues/6988 / https://tabatkins.github.io/specs/svg-params/ ) That feature will address this use-case, so we won't need to address it via exposing this internal non-standard -moz-context-properties hack.

(In fact, we'll plan to remove -moz-context-properties entirely as soon as we can, once we've got the new mechanism implemented and we've migrated our existing icons to use it. So we can consider this and any other associated bugs as "wontfix", in favor of the new thing, barring any showstopper-type stuff that we happen to run across in the meantime).