-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Add Support for Dynamic SVG Icons in browser.action.setIcon()
#462
Comments
While on the subject of |
You can allow OffscreenCanvas to support service worker context. |
Which is the point of this issue?
What is the definition of dynamic SVG? Generate SVG file content using JavaScript? Manifest is a static file, so it is not possible to support dynamic SVG, only static SVG. I think supporting file path in manifest is sufficient, there is no need to use data url. For
BTW: Does SVG icon support animation? |
Generating SVG content using JavaScript is the main goal. Dynamic bitmaps are already supported with I agreed in the proposal that data URLs in the manifest have limited utility, but can be useful for writing small single-file tests. SVG does support animation, but they are not be supported in icons (at least in Safari).
|
I've been interested in seeing SVG support for extension and action icons for a while, but to be honest I hadn't really considered the possibility of using the SVG as a source used to generate static raster assets that would be used in browser UI. I think this path has a lot of potential. SVG would allow developers to supply high resolution icons that would render well at a variety of sizes and DPI. It enables browsers to explore more ways of presenting an extension's visual identity without compromising image quality. And the dynamism of a vector format may help us address other challenges, such as adapting to light/dark mode or a user's theme. On that last point, use of I agree with @xeenon's comment that supporting data URLs is "beneficial for … feature parity with the action.setIcon() API." In general, I would like to move towards fewer concepts that behave more consistently across WebExtensions APIs. This practice makes it easier for new developers to learn, for existing developers to predict how different systems will behave, and (hopefully) for browser teams to maintain.
While you can use an OffscreenCanvas to draw an image worker contexts, as far as I know it's not possible to draw an SVG without using DOM methods. The only solutions I've seen for drawing SVGs to a canvas use either, let canvas = new OffscreenDocument(300, 150);
let ctx = canvas.getContext('2d');
let img = new Image();
img.onload = () => ctx.drawImage(img, 0, 0);
img.src = 'data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 48 48"><rect width="48" height="48" rx="8" ry="8" style="fill: green"/></svg>'; The only way I can see to do this in a worker is with a coordinating document context that transfers an ImageBitmap to the worker.
I'm hesitant about setting a single SVG without any size constraints. Icons sometimes require special considerations when rendered at small sizes. See the Pushing Pixels blog post About those vector icons for a good discussion of this topic. |
Currently both
|
There are other issues to consider with regards to SVG & the background Service Worker in Chrome: |
Firefox would support this, though preferably if possible to avoid |
Since blob:-URLs are tied to the context they're associated with, we'd need to be careful with ensuring that the URL remains valid even after its revocation. Or alternatively, consider that a feature and allow extensions to free up the image data without explicitly clearing the badge image? |
Something which might be overlooked and could be useful in the case of action icons for webExtensions is the svg element: Some quick testing reveals: Safari supports the element only for SVGs on webpages but not for extension action icons. It also does not seem to support subtags like en-GB. Chrome somehow selects the wrong language and as we know Chrome does not yet support SVGs for extension icons. |
@carlosjeurissen Safari uses a small subset of SVG that is supported by the system, which is more limited than what WebKit can render. Any further proposal here should build upon |
Currently, the
browser.action.setIcon()
API and the manifest file format support setting extension icons via local image paths or dynamically viaImageData
. These methods are effective but lack native support for dynamic vector images like SVGs, which offer scalable quality. To enhance these capabilities, I suggest extending both the API and manifest specifications to accommodate data URLs for dynamic SVG images.Dynamic Runtime Icons
Developers can use a mix of smaller PNG icons and larger dynamic SVGs:
Manifest Icons
Data URLs can also be used directly in the manifest:
While single-file deployment may not be ideal for production, it is beneficial for testing scenarios and ensures feature parity with the
action.setIcon()
API. Data URLs could also be used in manifest sections that currently accept resource paths, like content scripts, broadening the range of options for specifying resources during testing.Other Considerations
Specifying SVG or Canvas Elements
Developers could directly specify SVG or Canvas elements in the
setIcon
method using a newelement
key. The browser would serialize the element into the required image data.This method simplifies the serialization process but restricts icon creation to specific web elements like SVG and canvas.
Compatibility Considerations
This proposal builds upon existing APIs in a backward-compatible manner. However, data URLs may not be universally supported. Developers should test compatibility and may need to provide fallbacks.
The text was updated successfully, but these errors were encountered: