1421329 - Enable privileged embedding documents to set CSS environment variables (or CSS cascading variables) in embedded SVG

Status: RESOLVED DUPLICATE of bug 1782815

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

Description

[Jonathan Watt [:jwatt]]

Spinning this off from bug 1388193.

The current -moz-context-properties mechanism (implemented across bug 1058040, bug 1350010 and bug 1360662) to allow embedding documents to set colors in SVG images isn't a great one to expose to the Web at large.

I don't really like that '-moz-context-properties' takes a list of properties, not least because it means that it's not a general solution for exposing properties to a sub-document/image. For example, 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.

The only proposal that seems to be significantly better than '-moz-context-properties' is the proposal that's been made on and off to the SVG WG over the years to add a mechanism to allow embedding documents to set CSS variables in embedded content. The latest incarnation of that proposal can be found at:

https://tabatkins.github.io/specs/svg-params/#setting

We should consider working out the issues in that draft and then implementing a first pass restricted to our frontend code and possibly WebExtensions.

Comment 1

[Hiroyuki Ikezoe (:hiro)]

I am confident that this feature is very attractive for web extension authors.

What's more, if we have an API to manipulate browserAction icon style, web extension authors easily create animating SVG icon there using transition.  (I believe we should definitely have the API)

Web extension authors can, already today, create animating browserAction icon, but it's a bit tricky.  I did release a proof-of-concept extension to show an animating browserAction icon [1] which is actually needs to set unique SVG via browserAction.setIcon() to make the animation happen.

[1] https://addons.mozilla.org/en-US/firefox/addon/animation-toggle-icon/

Comment 2

[Brian Birtles (:birtles, Feb 26~ parental leave)]

As a first step, simply allowing (non-Mozilla) extension authors to respond to changes to the browser theme via some sort of context-fill equivalent would a big win for extension authors and themers alike and something that would be worth prioritizing this year.

Comment 4

[Jonathan Watt [:jwatt]]

It probably makes more sense to set CSS environment variable[1] than CSS cascading variables. Of course the former are not yet implemented (bug 1462233), while the later are.

1. https://drafts.csswg.org/css-env-1/

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Watt [:jwatt] from comment #4)
> It probably makes more sense to set CSS environment variable[1] than CSS
> cascading variables. Of course the former are not yet implemented (bug 1462233),
> while the later are.

Follow-up: we do now have CSS Environment Variables implemented now, in case that ends up being the approach we want to take here. (Though: per last sentence of section 2 at https://drafts.csswg.org/css-env-1/#environment , we need to get any hypothetical variables standardized & listed there before we support them.)

Comment 7

[ariasuni]

Any news on this?

I wrote about 50 lines of code to listen to theme changes, somehow guess the color that’s used by Firefox to fill its own icons and then generate the SVG with the correct fill=XXXXX in it. But even that falls short because I can set only one sidebarAction icon but a theme can have a different color for sidebar header and popup menus — something that’s easy to get with Firefox Color.

Comment 8

[ariasuni]

To support the new toolbar color of contextualIdentitities.ContextualIdentity, which depends on the current theme, I had to ditch my SVGs with the colors hardcoded, put them on the form of strings in my JavaScript code, replace the color on-the-fly and transform them to a data:image/svg+xml URL so that I can pass them to the menus.create() and have them colored properly.

This would be great to just be able to use an icon with needed to engineer a system to color them properly.

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Watt [:jwatt] from comment #0)

The latest incarnation of that proposal
can be found at:

https://tabatkins.github.io/specs/svg-params/#setting

We should consider working out the issues in that draft and then
implementing a first pass restricted to our frontend code and possibly
WebExtensions.

Ah, I spun off bug 1782815 to cover this (per the CSSWG resolution today) before realizing we had this preexisting bug here. :)

I'll just dupe this older bug forward to bug 1782815 so we can "start fresh" over there, since most of the existing comments are somewhat speculative RE how the feature should work, which isn't as relevant at this point now that we have a relatively-agreed-upon draft spec. jwatt, hope that's OK with you.