Intent to Implement and Ship: Support for SVG in favicons

477 views
Skip to first unread message

Fredrik Söderquist

unread,
Mar 28, 2019, 1:01:59 PM3/28/19
to blink-dev
f...@opera.com Specification: https://html.spec.whatwg.org/#rel-icon This is exposing a previously supported format in one more facet of the platform, thus skipping TAG review. Allows using images in SVG format as favicons with <link rel="icon">. Using a scalable format for favicons allows having fewer such resources in total - i.e maybe have one (or more) hand-tuned icon(s) for small sizes and use a scalable icon as a catch-all.
Low. Lack of support only means reduced fidelity (and presumably only at resolutions where the SVG icon could've been used). Presence and/or ordering of <link rel="icon"> elements could potentially affect icon selection. Firefox: Shipped (https://bugzilla.mozilla.org/show_bug.cgi?id=366324) Edge: No public signals Safari: No public signals (Supported for rel="mask-icon" (with restrictions) but not rel="icon".) Web developers: Positive The security risks are largely the same as for an <img> element, and the handling is also very similar.
No Availability of this feature is dependent on the actual UI in use, and how it presents (or not) the favicon.
No This feature is highly UI-dependent, and what favicon is selected (and which format it is in) is decided by the UA. https://bugs.chromium.org/p/chromium/issues/detail?id=294179 https://www.chromestatus.com/features/5180316371124224

Chris Harrelson

unread,
Mar 28, 2019, 1:06:11 PM3/28/19
to Fredrik Söderquist, blink-dev
LGTM1

Thanks for working on this!



On Thu, Mar 28, 2019 at 10:01 AM Fredrik Söderquist <f...@opera.com> wrote:
f...@opera.com Specification: https://html.spec.whatwg.org/#rel-icon This is exposing a previously supported format in one more facet of the platform, thus skipping TAG review. Allows using images in SVG format as favicons with <link rel="icon">. Using a scalable format for favicons allows having fewer such resources in total - i.e maybe have one (or more) hand-tuned icon(s) for small sizes and use a scalable icon as a catch-all.
Low. Lack of support only means reduced fidelity (and presumably only at resolutions where the SVG icon could've been used). Presence and/or ordering of <link rel="icon"> elements could potentially affect icon selection. Firefox: Shipped (https://bugzilla.mozilla.org/show_bug.cgi?id=366324) Edge: No public signals Safari: No public signals (Supported for rel="mask-icon" (with restrictions) but not rel="icon".) Web developers: Positive

The bug for this feature has 166 stars. It's one of the top most requested features in Paint/SVG.
 
The security risks are largely the same as for an <img> element, and the handling is also very similar.
No Availability of this feature is dependent on the actual UI in use, and how it presents (or not) the favicon.
No This feature is highly UI-dependent, and what favicon is selected (and which format it is in) is decided by the UA. https://bugs.chromium.org/p/chromium/issues/detail?id=294179 https://www.chromestatus.com/features/5180316371124224

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHediLSkG1uzXYx7_Q75%3DtavGqztnFi6qhan0g_f_Jzz3ZKS%3DQ%40mail.gmail.com.

Mathias Bynens

unread,
Mar 28, 2019, 1:11:54 PM3/28/19
to Fredrik Söderquist, blink-dev
Non-owner LGTM. Very excited that this is happening!

--

Rik Cabanier

unread,
Mar 28, 2019, 1:20:55 PM3/28/19
to Fredrik Söderquist, blink-dev
Will these favicons behave like an image (<img src="icon.svg"/>) or as a regular SVG file?

On Thu, Mar 28, 2019 at 10:01 AM Fredrik Söderquist <f...@opera.com> wrote:
--

Fredrik Söderquist

unread,
Mar 28, 2019, 1:29:18 PM3/28/19
to Rik Cabanier, blink-dev
On Thu, Mar 28, 2019 at 6:20 PM Rik Cabanier <caba...@gmail.com> wrote:
Will these favicons behave like an image (<img src="icon.svg"/>) or as a regular SVG file?

As currently written they will behave like an image (<img src="icon.svg" width="..." height="...">; width/height depending on the embedder/embedding point).


/fs

Victor Costan

unread,
Mar 28, 2019, 1:34:25 PM3/28/19
to Fredrik Söderquist, blink-dev
Non-owner cheer. Thank you very much for driving this to completion!

On Thu, Mar 28, 2019 at 10:01 AM Fredrik Söderquist <f...@opera.com> wrote:
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

Chris Harrelson

unread,
Mar 28, 2019, 1:42:54 PM3/28/19
to Fredrik Söderquist, Rik Cabanier, blink-dev
On Thu, Mar 28, 2019 at 10:29 AM Fredrik Söderquist <f...@opera.com> wrote:
On Thu, Mar 28, 2019 at 6:20 PM Rik Cabanier <caba...@gmail.com> wrote:
Will these favicons behave like an image (<img src="icon.svg"/>) or as a regular SVG file?

As currently written they will behave like an image (<img src="icon.svg" width="..." height="...">; width/height depending on the embedder/embedding point).

I think this is the right behavior. Also, the spec implies that behavior since it refers to SVG images. Worth adding a sentence or two to refer to the rendering specs for SVG images.
 


/fs
 

On Thu, Mar 28, 2019 at 10:01 AM Fredrik Söderquist <f...@opera.com> wrote:
f...@opera.com Specification: https://html.spec.whatwg.org/#rel-icon This is exposing a previously supported format in one more facet of the platform, thus skipping TAG review. Allows using images in SVG format as favicons with <link rel="icon">. Using a scalable format for favicons allows having fewer such resources in total - i.e maybe have one (or more) hand-tuned icon(s) for small sizes and use a scalable icon as a catch-all.
Low. Lack of support only means reduced fidelity (and presumably only at resolutions where the SVG icon could've been used). Presence and/or ordering of <link rel="icon"> elements could potentially affect icon selection. Firefox: Shipped (https://bugzilla.mozilla.org/show_bug.cgi?id=366324) Edge: No public signals Safari: No public signals (Supported for rel="mask-icon" (with restrictions) but not rel="icon".) Web developers: Positive The security risks are largely the same as for an <img> element, and the handling is also very similar.
No Availability of this feature is dependent on the actual UI in use, and how it presents (or not) the favicon.
No This feature is highly UI-dependent, and what favicon is selected (and which format it is in) is decided by the UA. https://bugs.chromium.org/p/chromium/issues/detail?id=294179 https://www.chromestatus.com/features/5180316371124224

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHediLSkG1uzXYx7_Q75%3DtavGqztnFi6qhan0g_f_Jzz3ZKS%3DQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Fredrik Söderquist

unread,
Mar 28, 2019, 1:59:00 PM3/28/19
to Chris Harrelson, Rik Cabanier, blink-dev
On Thu, Mar 28, 2019 at 6:42 PM Chris Harrelson <chri...@chromium.org> wrote:


On Thu, Mar 28, 2019 at 10:29 AM Fredrik Söderquist <f...@opera.com> wrote:
On Thu, Mar 28, 2019 at 6:20 PM Rik Cabanier <caba...@gmail.com> wrote:
Will these favicons behave like an image (<img src="icon.svg"/>) or as a regular SVG file?

As currently written they will behave like an image (<img src="icon.svg" width="..." height="...">; width/height depending on the embedder/embedding point).

I think this is the right behavior. Also, the spec implies that behavior since it refers to SVG images. Worth adding a sentence or two to refer to the rendering specs for SVG images.

I updated the Chrome Status entry with the above information and a reference to the SVG spec's "processing modes" section.


/fs

Chris Harrelson

unread,
Mar 28, 2019, 2:00:00 PM3/28/19
to Fredrik Söderquist, Rik Cabanier, blink-dev
On Thu, Mar 28, 2019 at 10:58 AM Fredrik Söderquist <f...@opera.com> wrote:
On Thu, Mar 28, 2019 at 6:42 PM Chris Harrelson <chri...@chromium.org> wrote:


On Thu, Mar 28, 2019 at 10:29 AM Fredrik Söderquist <f...@opera.com> wrote:
On Thu, Mar 28, 2019 at 6:20 PM Rik Cabanier <caba...@gmail.com> wrote:
Will these favicons behave like an image (<img src="icon.svg"/>) or as a regular SVG file?

As currently written they will behave like an image (<img src="icon.svg" width="..." height="...">; width/height depending on the embedder/embedding point).

I think this is the right behavior. Also, the spec implies that behavior since it refers to SVG images. Worth adding a sentence or two to refer to the rendering specs for SVG images.

I updated the Chrome Status entry with the above information and a reference to the SVG spec's "processing modes" section.

Also a PR on the HTML spec right?

Fredrik Söderquist

unread,
Mar 28, 2019, 2:16:43 PM3/28/19
to Chris Harrelson, Rik Cabanier, blink-dev
On Thu, Mar 28, 2019 at 6:59 PM Chris Harrelson <chri...@chromium.org> wrote:


On Thu, Mar 28, 2019 at 10:58 AM Fredrik Söderquist <f...@opera.com> wrote:
On Thu, Mar 28, 2019 at 6:42 PM Chris Harrelson <chri...@chromium.org> wrote:


On Thu, Mar 28, 2019 at 10:29 AM Fredrik Söderquist <f...@opera.com> wrote:
On Thu, Mar 28, 2019 at 6:20 PM Rik Cabanier <caba...@gmail.com> wrote:
Will these favicons behave like an image (<img src="icon.svg"/>) or as a regular SVG file?

As currently written they will behave like an image (<img src="icon.svg" width="..." height="...">; width/height depending on the embedder/embedding point).

I think this is the right behavior. Also, the spec implies that behavior since it refers to SVG images. Worth adding a sentence or two to refer to the rendering specs for SVG images.

I updated the Chrome Status entry with the above information and a reference to the SVG spec's "processing modes" section.

Also a PR on the HTML spec right?

The HTML spec does not really define in which way to actually present something from <link rel="icon"> (like "with a contain constraint" which is how raster images are usually handled). Theoretically a UA could opt to use fewer constraints than the above, if that somehow worked better from their PoV (unlikely but...) So IMHO, this would be more of a recommendation than a requirement, and I'm not sure if a recommendation adds much value to the specification in this case?


/fs

Chris Harrelson

unread,
Mar 28, 2019, 2:29:14 PM3/28/19
to Fredrik Söderquist, Rik Cabanier, blink-dev
On Thu, Mar 28, 2019 at 11:16 AM Fredrik Söderquist <f...@opera.com> wrote:
On Thu, Mar 28, 2019 at 6:59 PM Chris Harrelson <chri...@chromium.org> wrote:


On Thu, Mar 28, 2019 at 10:58 AM Fredrik Söderquist <f...@opera.com> wrote:
On Thu, Mar 28, 2019 at 6:42 PM Chris Harrelson <chri...@chromium.org> wrote:


On Thu, Mar 28, 2019 at 10:29 AM Fredrik Söderquist <f...@opera.com> wrote:
On Thu, Mar 28, 2019 at 6:20 PM Rik Cabanier <caba...@gmail.com> wrote:
Will these favicons behave like an image (<img src="icon.svg"/>) or as a regular SVG file?

As currently written they will behave like an image (<img src="icon.svg" width="..." height="...">; width/height depending on the embedder/embedding point).

I think this is the right behavior. Also, the spec implies that behavior since it refers to SVG images. Worth adding a sentence or two to refer to the rendering specs for SVG images.

I updated the Chrome Status entry with the above information and a reference to the SVG spec's "processing modes" section.

Also a PR on the HTML spec right?

The HTML spec does not really define in which way to actually present something from <link rel="icon"> (like "with a contain constraint" which is how raster images are usually handled). Theoretically a UA could opt to use fewer constraints than the above, if that somehow worked better from their PoV (unlikely but...) So IMHO, this would be more of a recommendation than a requirement, and I'm not sure if a recommendation adds much value to the specification in this case?

Wouldn't it be useful to link to the right place in the SVG spec though? The HTML spec does have various recommendations.

Also, I see from the chromestatus entry that you're suggesting allowing SMIL animations. I'm not sure if this is a good idea. I don't think Chrome allows animated GIFs in favicons right now (you have to use script to change it manually on each frame).
 


/fs
 
 


/fs
 
 


/fs
 

On Thu, Mar 28, 2019 at 10:01 AM Fredrik Söderquist <f...@opera.com> wrote:
f...@opera.com Specification: https://html.spec.whatwg.org/#rel-icon This is exposing a previously supported format in one more facet of the platform, thus skipping TAG review. Allows using images in SVG format as favicons with <link rel="icon">. Using a scalable format for favicons allows having fewer such resources in total - i.e maybe have one (or more) hand-tuned icon(s) for small sizes and use a scalable icon as a catch-all.
Low. Lack of support only means reduced fidelity (and presumably only at resolutions where the SVG icon could've been used). Presence and/or ordering of <link rel="icon"> elements could potentially affect icon selection. Firefox: Shipped (https://bugzilla.mozilla.org/show_bug.cgi?id=366324) Edge: No public signals Safari: No public signals (Supported for rel="mask-icon" (with restrictions) but not rel="icon".) Web developers: Positive The security risks are largely the same as for an <img> element, and the handling is also very similar.
No Availability of this feature is dependent on the actual UI in use, and how it presents (or not) the favicon.
No This feature is highly UI-dependent, and what favicon is selected (and which format it is in) is decided by the UA. https://bugs.chromium.org/p/chromium/issues/detail?id=294179 https://www.chromestatus.com/features/5180316371124224

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHediLSkG1uzXYx7_Q75%3DtavGqztnFi6qhan0g_f_Jzz3ZKS%3DQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHediLQzhcQNwysxU561EVu8RXze1g1WHh8wGNgf%2BWL-LgnR8A%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Fredrik Söderquist

unread,
Mar 28, 2019, 4:42:40 PM3/28/19
to Chris Harrelson, Rik Cabanier, blink-dev
On Thu, Mar 28, 2019 at 7:29 PM Chris Harrelson <chri...@chromium.org> wrote:


On Thu, Mar 28, 2019 at 11:16 AM Fredrik Söderquist <f...@opera.com> wrote:
On Thu, Mar 28, 2019 at 6:59 PM Chris Harrelson <chri...@chromium.org> wrote:


On Thu, Mar 28, 2019 at 10:58 AM Fredrik Söderquist <f...@opera.com> wrote:
On Thu, Mar 28, 2019 at 6:42 PM Chris Harrelson <chri...@chromium.org> wrote:


On Thu, Mar 28, 2019 at 10:29 AM Fredrik Söderquist <f...@opera.com> wrote:
On Thu, Mar 28, 2019 at 6:20 PM Rik Cabanier <caba...@gmail.com> wrote:
Will these favicons behave like an image (<img src="icon.svg"/>) or as a regular SVG file?

As currently written they will behave like an image (<img src="icon.svg" width="..." height="...">; width/height depending on the embedder/embedding point).

I think this is the right behavior. Also, the spec implies that behavior since it refers to SVG images. Worth adding a sentence or two to refer to the rendering specs for SVG images.

I updated the Chrome Status entry with the above information and a reference to the SVG spec's "processing modes" section.

Also a PR on the HTML spec right?

The HTML spec does not really define in which way to actually present something from <link rel="icon"> (like "with a contain constraint" which is how raster images are usually handled). Theoretically a UA could opt to use fewer constraints than the above, if that somehow worked better from their PoV (unlikely but...) So IMHO, this would be more of a recommendation than a requirement, and I'm not sure if a recommendation adds much value to the specification in this case?

Wouldn't it be useful to link to the right place in the SVG spec though? The HTML spec does have various recommendations.

I imagine the same would hold as in HTML 4.8.4.3:

"This specification does not specify which image types are to be supported."

But I could propose that text similar to (or referencing) the preceding paragraph:

"User agents must not support non-image resources <snip> User agents must not run executable code (e.g. scripts) embedded in the image resource. <snip> User agents must not allow the resource to act in an interactive fashion, <snip>"

be added perhaps?


Also, I see from the chromestatus entry that you're suggesting allowing SMIL animations. I'm not sure if this is a good idea. I don't think Chrome allows animated GIFs in favicons right now (you have to use script to change it manually on each frame).

Animation is not supported, but if the document has animations they will be applied for t=0. There will be no frames after that, same as GIF. The other option would be to not apply animations at all, which may change rendering. I'll check what Gecko does here.


/fs

Chris Harrelson

unread,
Mar 28, 2019, 7:28:57 PM3/28/19
to Fredrik Söderquist, Rik Cabanier, blink-dev
On Thu, Mar 28, 2019 at 1:42 PM Fredrik Söderquist <f...@opera.com> wrote:
On Thu, Mar 28, 2019 at 7:29 PM Chris Harrelson <chri...@chromium.org> wrote:


On Thu, Mar 28, 2019 at 11:16 AM Fredrik Söderquist <f...@opera.com> wrote:
On Thu, Mar 28, 2019 at 6:59 PM Chris Harrelson <chri...@chromium.org> wrote:


On Thu, Mar 28, 2019 at 10:58 AM Fredrik Söderquist <f...@opera.com> wrote:
On Thu, Mar 28, 2019 at 6:42 PM Chris Harrelson <chri...@chromium.org> wrote:


On Thu, Mar 28, 2019 at 10:29 AM Fredrik Söderquist <f...@opera.com> wrote:
On Thu, Mar 28, 2019 at 6:20 PM Rik Cabanier <caba...@gmail.com> wrote:
Will these favicons behave like an image (<img src="icon.svg"/>) or as a regular SVG file?

As currently written they will behave like an image (<img src="icon.svg" width="..." height="...">; width/height depending on the embedder/embedding point).

I think this is the right behavior. Also, the spec implies that behavior since it refers to SVG images. Worth adding a sentence or two to refer to the rendering specs for SVG images.

I updated the Chrome Status entry with the above information and a reference to the SVG spec's "processing modes" section.

Also a PR on the HTML spec right?

The HTML spec does not really define in which way to actually present something from <link rel="icon"> (like "with a contain constraint" which is how raster images are usually handled). Theoretically a UA could opt to use fewer constraints than the above, if that somehow worked better from their PoV (unlikely but...) So IMHO, this would be more of a recommendation than a requirement, and I'm not sure if a recommendation adds much value to the specification in this case?

Wouldn't it be useful to link to the right place in the SVG spec though? The HTML spec does have various recommendations.

I imagine the same would hold as in HTML 4.8.4.3:

"This specification does not specify which image types are to be supported."

But I could propose that text similar to (or referencing) the preceding paragraph:

"User agents must not support non-image resources <snip> User agents must not run executable code (e.g. scripts) embedded in the image resource. <snip> User agents must not allow the resource to act in an interactive fashion, <snip>"

be added perhaps?

Sure sounds good.
 


Also, I see from the chromestatus entry that you're suggesting allowing SMIL animations. I'm not sure if this is a good idea. I don't think Chrome allows animated GIFs in favicons right now (you have to use script to change it manually on each frame).

Animation is not supported, but if the document has animations they will be applied for t=0. There will be no frames after that, same as GIF. The other option would be to not apply animations at all, which may change rendering. I'll check what Gecko does here.

Ah ok, that sounds good to me.
 


/fs

 


/fs
 
 


/fs
 
 


/fs
 

On Thu, Mar 28, 2019 at 10:01 AM Fredrik Söderquist <f...@opera.com> wrote:
f...@opera.com Specification: https://html.spec.whatwg.org/#rel-icon This is exposing a previously supported format in one more facet of the platform, thus skipping TAG review. Allows using images in SVG format as favicons with <link rel="icon">. Using a scalable format for favicons allows having fewer such resources in total - i.e maybe have one (or more) hand-tuned icon(s) for small sizes and use a scalable icon as a catch-all.
Low. Lack of support only means reduced fidelity (and presumably only at resolutions where the SVG icon could've been used). Presence and/or ordering of <link rel="icon"> elements could potentially affect icon selection. Firefox: Shipped (https://bugzilla.mozilla.org/show_bug.cgi?id=366324) Edge: No public signals Safari: No public signals (Supported for rel="mask-icon" (with restrictions) but not rel="icon".) Web developers: Positive The security risks are largely the same as for an <img> element, and the handling is also very similar.
No Availability of this feature is dependent on the actual UI in use, and how it presents (or not) the favicon.
No This feature is highly UI-dependent, and what favicon is selected (and which format it is in) is decided by the UA. https://bugs.chromium.org/p/chromium/issues/detail?id=294179 https://www.chromestatus.com/features/5180316371124224

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHediLSkG1uzXYx7_Q75%3DtavGqztnFi6qhan0g_f_Jzz3ZKS%3DQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHediLQzhcQNwysxU561EVu8RXze1g1WHh8wGNgf%2BWL-LgnR8A%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHediLQMW-nZcv_GGJfxWA6ZootPZ%2BgxS%2B-CoscVtwsiBwXwpw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Fredrik Söderquist

unread,
Mar 29, 2019, 9:41:28 AM3/29/19
to Chris Harrelson, Rik Cabanier, blink-dev
On Fri, Mar 29, 2019 at 12:28 AM Chris Harrelson <chri...@chromium.org> wrote:


On Thu, Mar 28, 2019 at 1:42 PM Fredrik Söderquist <f...@opera.com> wrote:
On Thu, Mar 28, 2019 at 7:29 PM Chris Harrelson <chri...@chromium.org> wrote:


On Thu, Mar 28, 2019 at 11:16 AM Fredrik Söderquist <f...@opera.com> wrote:
On Thu, Mar 28, 2019 at 6:59 PM Chris Harrelson <chri...@chromium.org> wrote:


On Thu, Mar 28, 2019 at 10:58 AM Fredrik Söderquist <f...@opera.com> wrote:
On Thu, Mar 28, 2019 at 6:42 PM Chris Harrelson <chri...@chromium.org> wrote:


On Thu, Mar 28, 2019 at 10:29 AM Fredrik Söderquist <f...@opera.com> wrote:
On Thu, Mar 28, 2019 at 6:20 PM Rik Cabanier <caba...@gmail.com> wrote:
Will these favicons behave like an image (<img src="icon.svg"/>) or as a regular SVG file?

As currently written they will behave like an image (<img src="icon.svg" width="..." height="...">; width/height depending on the embedder/embedding point).

I think this is the right behavior. Also, the spec implies that behavior since it refers to SVG images. Worth adding a sentence or two to refer to the rendering specs for SVG images.

I updated the Chrome Status entry with the above information and a reference to the SVG spec's "processing modes" section.

Also a PR on the HTML spec right?

The HTML spec does not really define in which way to actually present something from <link rel="icon"> (like "with a contain constraint" which is how raster images are usually handled). Theoretically a UA could opt to use fewer constraints than the above, if that somehow worked better from their PoV (unlikely but...) So IMHO, this would be more of a recommendation than a requirement, and I'm not sure if a recommendation adds much value to the specification in this case?

Wouldn't it be useful to link to the right place in the SVG spec though? The HTML spec does have various recommendations.

I imagine the same would hold as in HTML 4.8.4.3:

"This specification does not specify which image types are to be supported."

But I could propose that text similar to (or referencing) the preceding paragraph:

"User agents must not support non-image resources <snip> User agents must not run executable code (e.g. scripts) embedded in the image resource. <snip> User agents must not allow the resource to act in an interactive fashion, <snip>"

be added perhaps?

Sure sounds good.

Because of legal-red-tape issues I ended up raising an issue for this: https://github.com/whatwg/html/issues/4461

 


Also, I see from the chromestatus entry that you're suggesting allowing SMIL animations. I'm not sure if this is a good idea. I don't think Chrome allows animated GIFs in favicons right now (you have to use script to change it manually on each frame).

Animation is not supported, but if the document has animations they will be applied for t=0. There will be no frames after that, same as GIF. The other option would be to not apply animations at all, which may change rendering. I'll check what Gecko does here.

Ah ok, that sounds good to me.

Apparently Gecko supports animated favicons, but I'll leave us with "first frame"-like behavior.


/fs

Alex Russell

unread,
Apr 4, 2019, 3:27:43 PM4/4/19
to blink-dev, chri...@chromium.org, caba...@gmail.com
LGTM pending the proposed spec changes landing.
 


/fs

 


/fs
 
 


/fs
 
 


/fs
 

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

Ojan Vafai

unread,
Apr 4, 2019, 3:28:34 PM4/4/19
to blink-dev, chri...@chromium.org, caba...@gmail.com
LGTM3
Message has been deleted

Fredrik Söderquist

unread,
May 1, 2019, 5:23:01 AM5/1/19
to valtteri...@gmail.com, blink-dev
On Wed, May 1, 2019 at 1:41 AM <valtteri...@gmail.com> wrote:
Does this apply to icons in Web App Manifest too?

IIRC it uses the way to acquire/decode the icon, but the icon selection may not be set up to support it at the moment.


/fs
 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/509c1d17-f2a5-4953-bcbd-f4e3c3cbf92a%40chromium.org.

Chris Palmer

unread,
May 1, 2019, 6:27:27 PM5/1/19
to blink-dev, valtteri...@gmail.com
SVG is significantly different from other image formats, in that it can contain script, and is XML. It's one thing to handle SVGs in a sandboxed renderer, but handling them in the browser process is potentially a different story. How are we making this safe?


On Wednesday, May 1, 2019 at 2:23:01 AM UTC-7, Fredrik Söderquist wrote:
On Wed, May 1, 2019 at 1:41 AM <valtteri...@gmail.com> wrote:
Does this apply to icons in Web App Manifest too?

IIRC it uses the way to acquire/decode the icon, but the icon selection may not be set up to support it at the moment.


/fs
 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

Fredrik Söderquist

unread,
May 2, 2019, 4:20:53 AM5/2/19
to Chris Palmer, blink-dev
On Thu, May 2, 2019 at 12:27 AM 'Chris Palmer' via blink-dev <blin...@chromium.org> wrote:
SVG is significantly different from other image formats, in that it can contain script, and is XML. It's one thing to handle SVGs in a sandboxed renderer, but handling them in the browser process is potentially a different story. How are we making this safe?

We are rendering ("decoding") the SVG in a renderer (much like we decode other image formats in these contexts).


/fs
 


On Wednesday, May 1, 2019 at 2:23:01 AM UTC-7, Fredrik Söderquist wrote:
On Wed, May 1, 2019 at 1:41 AM <valtteri...@gmail.com> wrote:
Does this apply to icons in Web App Manifest too?

IIRC it uses the way to acquire/decode the icon, but the icon selection may not be set up to support it at the moment.


/fs
 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/509c1d17-f2a5-4953-bcbd-f4e3c3cbf92a%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a6881411-d071-421c-984e-378f4f2d15f2%40chromium.org.

Philip Rogers

unread,
May 2, 2019, 10:49:06 AM5/2/19
to Fredrik Söderquist, Chris Palmer, blink-dev
I had similar concerns about security and wanted to expand on Fredrik's point about using the renderer. Because the favicon is declared in the html (<link rel="icon" href="favicon.svg">), it can be loaded in the same way as a regular image in that process (<img src="favicon.svg">). This includes security features like access control (e.g., can't load the favicon from file://) as well as treating the svg favicon as being in an image context (no scripts or subresources, unlike a top-level document svg file). This also means performance features like caching are already present, as well as the ability to use devtools to inspect the network / decode performance / etc.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHediLRCWXqO7PU3jTAjb2B8tScJxEngS23gyvRJQd7HSWkwMw%40mail.gmail.com.

Peter Kasting

unread,
May 2, 2019, 11:46:30 AM5/2/19
to Fredrik Söderquist, Chris Palmer, blink-dev
On Thu, May 2, 2019 at 1:20 AM Fredrik Söderquist <f...@opera.com> wrote:
On Thu, May 2, 2019 at 12:27 AM 'Chris Palmer' via blink-dev <blin...@chromium.org> wrote:
SVG is significantly different from other image formats, in that it can contain script, and is XML. It's one thing to handle SVGs in a sandboxed renderer, but handling them in the browser process is potentially a different story. How are we making this safe?

We are rendering ("decoding") the SVG in a renderer (much like we decode other image formats in these contexts).

(For those who had been wondering about this, that means Chrome's UI code still works at the gfx::Image/SkBitmap level, and won't know whether a particular favicon was SVG originally.)

PK

Chris Palmer

unread,
May 2, 2019, 12:43:07 PM5/2/19
to Peter Kasting, Fredrik Söderquist, blink-dev
OK, that's great. Thanks everyone!

steve...@gmail.com

unread,
Feb 26, 2020, 7:29:33 PM2/26/20
to blink-dev
Could I ask a question?


in the old commit, decode bitmaps and  reverse the bitmap vector here:

void MultiResolutionImageResourceFetcher::OnURLFetchComplete(
    const WebURLResponse& response,
    const std::string& data) {
    ...
      std::vector<SkBitmap> decoded_bitmaps =
          WebImage::FramesFromData(
              WebData(reinterpret_cast<const char*>(src_data), data.size()))
              .ReleaseVector();

      bitmaps.AppendRange(std::make_move_iterator(decoded_bitmaps.rbegin()),    // reverse the bitmap vector
                          std::make_move_iterator(decoded_bitmaps.rend()));
    }
  }  
  ......
  std::move(callback_).Run(this, bitmaps);
}

the codes about decoding bitmap were moved into image_downloader_impl.cc,
decode the bitmaps but  not reverse the bitmap vector.

WTF::Vector<SkBitmap> DecodeImageData(const std::string& data,
                                      const std::string& mime_type,
                                      const blink::WebSize& preferred_size) {
   ......
    blink::WebVector<SkBitmap> original_bitmaps =
        blink::WebImage::FramesFromData(buffer);
    bitmaps.AppendRange(std::make_move_iterator(original_bitmaps.begin()),
                        std::make_move_iterator(original_bitmaps.end()));                        // not reverse the bitmap vector
  
}

So why reverse the bitmap vector in the old commit, but not reverse it now ?



在 2019年3月29日星期五 UTC+8上午1:01:59，Fredrik Söderquist写道：

在 2019年3月29日星期五 UTC+8上午1:01:59，Fredrik Söderquist写道：

steve...@gmail.com

unread,
Feb 26, 2020, 7:29:33 PM2/26/20
to blink-dev
Hello, Could I ask a question?

About the  commit:  https://chromium-review.googlesource.com/c/chromium/src/+/1541185

I found in the old commit ,  decode bitmaps and reverse the bitmap vector here.

void MultiResolutionImageResourceFetcher::OnURLFetchComplete(
    const WebURLResponse& response,
    const std::string& data) {
      ...
            std::vector<SkBitmap> decoded_bitmaps =
          WebImage::FramesFromData(
              WebData(reinterpret_cast<const char*>(src_data), data.size()))
              .ReleaseVector();

      bitmaps.AppendRange(std::make_move_iterator(decoded_bitmaps.rbegin()),
                          std::make_move_iterator(decoded_bitmaps.rend()));                            // reverse the bitmap vector
     .....
}

the "decoding bimaps"  was moved into image_downloader_impl.cc:  
decoding bitmaps but not reverse the bitmap vector

WTF::Vector<SkBitmap> DecodeImageData(const std::string& data,
                                      const std::string& mime_type,
                                      const blink::WebSize& preferred_size) {
    ......
    blink::WebVector<SkBitmap> original_bitmaps =
        blink::WebImage::FramesFromData(buffer);
    bitmaps.AppendRange(std::make_move_iterator(original_bitmaps.begin()),
                        std::make_move_iterator(original_bitmaps.end()));                                  // not reverse the bitmap vector
   ....
}

so why not reverse the bitmap vector now, but reverse it in the old commit?


在 2019年3月29日星期五 UTC+8上午1:01:59，Fredrik Söderquist写道：
f...@opera.com Specification: https://html.spec.whatwg.org/#rel-icon This is exposing a previously supported format in one more facet of the platform, thus skipping TAG review. Allows using images in SVG format as favicons with <link rel="icon">. Using a scalable format for favicons allows having fewer such resources in total - i.e maybe have one (or more) hand-tuned icon(s) for small sizes and use a scalable icon as a catch-all.

Fredrik Söderquist

unread,
Feb 27, 2020, 6:57:59 AM2/27/20
to steve...@gmail.com, blink-dev
This reversal was later re-introduced in https://chromium-review.googlesource.com/c/chromium/src/+/1929214. That being said I'm aware of any reason to have it reversed in the first place - i.e it's either a vector of images ordered based on decreasing "size" (IIRC it's sorted based on a tuple of <area, bits-per-pixel> stemming from the decoder for .ico) or increasing "size" (the reversed). The only reason for the reversal is coding making uninformed decisions.


/fs
 

在 2019年3月29日星期五 UTC+8上午1:01:59，Fredrik Söderquist写道：
f...@opera.com Specification: https://html.spec.whatwg.org/#rel-icon This is exposing a previously supported format in one more facet of the platform, thus skipping TAG review. Allows using images in SVG format as favicons with <link rel="icon">. Using a scalable format for favicons allows having fewer such resources in total - i.e maybe have one (or more) hand-tuned icon(s) for small sizes and use a scalable icon as a catch-all.
Low. Lack of support only means reduced fidelity (and presumably only at resolutions where the SVG icon could've been used). Presence and/or ordering of <link rel="icon"> elements could potentially affect icon selection. Firefox: Shipped (https://bugzilla.mozilla.org/show_bug.cgi?id=366324) Edge: No public signals Safari: No public signals (Supported for rel="mask-icon" (with restrictions) but not rel="icon".) Web developers: Positive The security risks are largely the same as for an <img> element, and the handling is also very similar.
No Availability of this feature is dependent on the actual UI in use, and how it presents (or not) the favicon.
No This feature is highly UI-dependent, and what favicon is selected (and which format it is in) is decided by the UA. https://bugs.chromium.org/p/chromium/issues/detail?id=294179 https://www.chromestatus.com/features/5180316371124224

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Reply all
Reply to author
Forward
0 new messages