[HN Gopher] SVG favicons have some cool benefits
___________________________________________________________________
SVG favicons have some cool benefits
Author : feross
Score : 107 points
Date : 2021-07-07 16:32 UTC (6 hours ago)
(HTM) web link (austingil.com)
(TXT) w3m dump (austingil.com)
| lokl wrote:
| Related: If you're looking for a favicon generator, check out
| https://realfavicongenerator.net (I am not affiliated, just a
| satisfied user).
| unilynx wrote:
| I wonder if the Gmail people could use this to give their app a
| non-blurry Favicon. It looks really poor when task switching
| between apps
| legulere wrote:
| I find the most interesting part how < and especially " don't
| need to be escaped inside the href attribute. How does the HTML
| parser know when the attribute stops?
| svieira wrote:
| I don't think it's actually valid - the examples just aren't
| base64-encoding in order to make it possible to read them
| easily.
|
| Edit: Yeah, you at least need to change the `"` to `'` in the
| inline SVG before it will parse correctly (tested in Firefox)
| chrismorgan wrote:
| People keep on talking about (prefers-color-scheme: dark), but it
| isn't what they want it to be--never has been, and probably never
| will be (though I will admit that prefers-color-scheme _could_
| theoretically be special-cased for favicon rendering).
|
| For example, in Firefox, I use the dark theme for the UI, but
| that's completely unrelated to the content, and prefers-color-
| scheme matches the content, not the chrome. Content I keep
| normal, light.
|
| It's quite possible (not uncommon, even) for the active tab to
| have a light background and inactive tabs to have a darker
| background. (A decade ago, this is what would happen by default
| on the default Windows XP theme, though it was the XP blue rather
| than anything _dark_ dark.)
|
| Or Chromium: like Firefox, it has themes; but beyond that,
| incognito window chrome gets a dark background.
|
| Admittedly, (prefers-color-scheme: dark) matching makes it almost
| certain that you're rendering against a dark background of some
| form, but it _not_ matching tells you absolutely nothing about
| the background.
|
| The fact of the matter is that your favicon could be rendered
| against absolutely any colour, and you need to make sure your
| icon will work on very light colours and very dark colours, and
| not be _too_ bad on anything in between.
| krono wrote:
| Yes GitHub does it too. The icon can't update itself so it's
| stuck on the color it was when you last visited the site.
|
| Example: https://i.imgur.com/PTPJ3Fm.png
| mjsir911 wrote:
| > For example, in Firefox, I use the dark theme for the UI, but
| that's completely unrelated to the content, and prefers-color-
| scheme matches the content, not the chrome. Content I keep
| normal, light.
|
| Of note is https://bugzilla.mozilla.org/show_bug.cgi?id=1529323
| which is requesting to change this behaviour to align prefers-
| color-scheme to the UI theme if there is no overriding
| behaviour.
|
| I prefer this because now rather than setting dark mode to each
| site I go to, they can be signalled this already. There's no
| user friendly way to set firefox's prefer-color-scheme: dark if
| the OS does not have the capabilities to do that.
| chrismorgan wrote:
| Yeah, I've been waiting for that to inevitably happen so that
| I can revert it. Speaking overly broadly, dark mode
| everything is normally an at-least-slightly bad idea, but
| there's good cause for aesthetic (low-contrast) dark mode of
| chrome in order to get it mostly out of the way, so that you
| can focus on the content. This is essentially what most
| graphics programs default to nowadays, and the same reasoning
| can be applied to browsers. (Though it only really works if
| your windows are maximised, otherwise dark between two lights
| could become a distraction.) No one says "you have a dark
| desktop background, you must want everything on your system
| to be dark". Comment 47's "When using the "Dark" theme,
| "prefers-color-scheme" should be dark, because that's what
| the user requested." is simply not right. Choosing a dark
| browser theme is honestly quite a weak hint about whether you
| want _content_ to be dark. The conflation of this that recent
| forays into OS-wide dark modes has encouraged is not good.
| dlbucci wrote:
| I agree they are great, especially for simple icons that work as
| SVG. Support for SVG favicons, however, keeps me from using them:
| https://caniuse.com/link-icon-svg
| clone1018 wrote:
| When you look at it compared to actual browser usage, you end
| up with 89.62% support, which is not bad at all. WebP & CSS
| Grid are at about 95%.
| chrismorgan wrote:
| Oh wow, Safari _still_ doesn't do regular SVG favicons? Huh.
| Somehow I thought that got sorted out a couple of years back in
| 12 or something.
| makeworld wrote:
| No need to use SVGs for an emoji favicon. Just put the emoji and
| a space at the beginning of your <title>.
| MattIPv4 wrote:
| Was wondering if you could use this to run a version of your site
| in the favicon directly using `foreignObject`, but it looks like
| Chromium browsers at least render the SVGs in static mode [1][2].
| Maybe it'll work in others though?
|
| [1] https://www.chromestatus.com/feature/5180316371124224
|
| [2] https://svgwg.org/svg2-draft/conform.html#secure-static-mode
| chrismorgan wrote:
| Secure static mode doesn't block foreignObject. Script
| execution, external references, declarative animation and
| interactivity, but not foreign content. Indeed, such processing
| modes are propagated to such foreign content:
| https://svgwg.org/svg2-draft/conform.html#referencing-modes.
|
| See https://news.ycombinator.com/item?id=26922244#26923436 for
| an example. It works in Chromium.
| dmit wrote:
| _Awkward ad intermission_
|
| Tired of all the "404 Not Found: /favicon.ico" log messages from
| your local test server? Fret no more! Just add this minor
| incantation to your HTML and you're set! <link
| rel="icon" href="data:," />
| soheil wrote:
| why not just touch favicon.ico
|
| so it gets cached and forget about it?
| blacksmith_tb wrote:
| Seems like the author is ahead of you, inlining the svg in your
| head tag should fix that too?
| teddyh wrote:
| I prefer this: <link rel="icon"
| href="data:image/svg+xml,%3csvg%3e %3c/svg%3e">
| memco wrote:
| Why is that preferable?
| teddyh wrote:
| Because it's a valid image.
| chrismorgan wrote:
| No it's not: the root <svg> element must exist in the
| http://www.w3.org/2000/svg namespace, or the file won't
| be valid SVG and won't be rendered.
|
| Alas for my beautiful short form that won't work after
| all: <link rel=icon
| href=data:image/svg+xml,<svg/%3E>
|
| I'll just have to settle for this: <link
| rel=icon href="data:image/svg+xml,<svg
| xmlns='http://www.w3.org/2000/svg'/>">
|
| Note, however, that by making it a valid SVG file, the
| browser will render an empty favicon, rather than saying
| "this page has no favicon" and either leaving the space
| out or putting some default icon in instead.
| Consequently, `data:,` is almost certainly preferable.
|
| (If you're not sure why I worded the namespaces remark so
| rather than just talking about an xmlns attribute, here's
| some valid SVG: <foo:svg
| xmlns:foo="http://www.w3.org/2000/svg"/>.)
| sdflhasjd wrote:
| Because it has all the cool benefits of SVG :p
| allyourhorses wrote:
| re: cacheability of favicons, this is basically a non-issue as
| the bandwidth-delay product of even a 10mbit/50ms connection is
| already 62 kB. Anything below this size on such a connection is
| likely to render faster than a separate request round-trip.
|
| This raises to almost 1.2 MB with a 100mbit/100ms connection.
| BugsJustFindMe wrote:
| > _By using an SVG, I'm able to get a lot of cool benefits like:
| Inline icon (no need for a linked resource)_
|
| AFAICT that's not any different than for non-SVG favicons which
| can also use data urls.
| shadowfaxRodeo wrote:
| this is correct
| globular-toast wrote:
| Vector graphics rendered at very low resolutions like 16x16 or
| whatever favicons are rarely look as good as hand-crafted
| bitmaps. Is it possible to make them look good?
| chrismorgan wrote:
| Yes, but it requires some graphics techniques that browsers
| mostly don't implement, or implement in all environments, yet.
| I can't remember the full range of techniques to do it
| properly, but it starts at least conceptually with
| supersampling: not rendering at 16x16, since that causes real
| problems with aliasing when you have overlapping objects, but
| rather rendering at a higher resolution (where the aliasing
| effects are reduced or eliminated) and scaling down. For
| _perfect_ results on 8-bit colour, I think you'd need to do
| 16x16 supersampling (rendering 16x as large in each direction,
| so 256x256 and scale down to 16x16) so that each pixel is the
| combination of 256 pixels, but except for _very_ fine detail,
| 4x4 supersampling (render at 64x64 and scale down to 16x16)
| should generally be good enough.
|
| I think there are fancier ways of doing this, and of getting
| GPU support, but I can't think of the terms now. Hopefully
| someone else will chip in.
|
| But if you're aware of the ways in which most renderers do an
| inferior job, you can work around them and craft your SVG so
| that it won't be affected: things like making sure that objects
| align with pixel boundaries and that each pixel never has more
| than one object partially covering it.
| amelius wrote:
| I wonder if it is possible to have an ML filter that can
| downsample in a way that is aesthetically pleasing, even if
| things are not aligned at pixel-boundaries.
| amelius wrote:
| At retina resolution it shouldn't matter.
| zamadatix wrote:
| Great news for users that weren't going to have the problem
| anyways, horrible news for the 16x16 rendering issues
| otherwise.
| mixmastamyk wrote:
| Have to greatly simplify them. Don't Hidef displays use 32x32
| these days?
| bonestamp2 wrote:
| Yes, 32x32 is typically used by higher density displays (more
| pixels in the same space, relatively speaking).
| matylla wrote:
| Complex SVG Favicons will usually be larger in term of bytes than
| highly compressed PNG icons. We did an extensive study of
| Favicons served on the top 500 websites [1].
|
| If you want to stick with the old-school PNG icons, we open-
| sourced `icopack` - our internal tool for efficient packing of
| individual PNGs into a highly-optimised ICO files [2].
|
| [1] https://optidash.ai/blog/optimizing-favicons-for-the-
| worlds-...
|
| [2] https://github.com/optidash-ai/icopack
| scns wrote:
| Thank you for this. Hope this becomes standard practice.
| CharlesW wrote:
| > _Complex SVG Favicons will usually be larger in term of bytes
| than highly compressed PNG icons._
|
| The post you linked to doesn't include the word "SVG". Is there
| a separate article that compares using one SVG file vs. using
| multiple images?
|
| It's hard to imagine that using a typical suite of PNG images
| at different sizes is going to be more efficient (and future-
| proof) than a single SVG file run through svgo.
| shadowfaxRodeo wrote:
| There's a few things to be aware of with svg favicons.
|
| 1. If a favicon is missing or in a format that's not compatible
| with the browser. The browser will look for a /favicon.ico file
| at the root of the site. It's worth having that as a backup or
| you end up with no favicon and 404 errors in the console.
|
| 2. Google now shows a favicon in some search results. I'm pretty
| sure it works fine with SVG. But, if you use an emoji you end up
| with a missing glyph character as your favicon. it looks bad.
|
| 3. If it's inline it won't be cached
|
| I went a bit overboard optimizing the favicon of my site, and
| found that:
|
| If you design your favicon as colored squares on a 16x16 grid,
| and save it as a 32x32 .ico file at
| https://example.com/favicon.ico
|
| You end up with a smaller file size icon, that can be cached,
| doesn't have any markup on your site, and scales up perfectly on
| all the icon sizes.
|
| here's an example: https://doodad.dev/favicon.ico
|
| it's just 625 bytes (261 minified)
| chrismorgan wrote:
| Your favicon.ico can be compressed further to a 171 byte PNG. I
| confess I find this 271-byte incantation compelling despite
| increasing each response by that much, since it'll load faster
| in the first place and avoid the overhead of another request:
| <link rel=icon href=data:image/png;base64,iVBORw0KGgoAAAANSUhEU
| gAAACAAAAAgCAMAAABEpIrGAAAAG1BMVEU5PT85PT///7X22GDtiUvVOkKxOF5q
| Mk////9bF0DJAAAAAXRSTlMAQObYZgAAAD5JREFUeNq906UBwEAUwNBy95+4cOA
| +09OxWSKsCE2wAQKCRhrsiMrgQFQGJ6IyuBCVwQ1YG1+wTHgQdpbTC3XuCmFsTK
| U6AAAAAElFTkSuQmCC>
| soheil wrote:
| There won't be any overhead once the file is cached. Your
| method requires the favicon to keep getting downloaded on
| every page load.
| TheRealPomax wrote:
| 2: Why? Are there even any systems left on the planet that
| aren't past EOL but don't have emoji fonts preinstalled at the
| OS level?
| reaperducer wrote:
| Maybe because you can't guarantee that even if an OS has
| emoji support that it supports the latest version of emojis.
|
| I run into this every time my wife updates her phone. She
| sends me text messages with "Lookit the cool new emojis!" But
| since I haven't updated mine, they came through as missing
| icon glyphs.
| shadowfaxRodeo wrote:
| I think google renders them in a raster format. Whatever they
| use to do that doesn't support emojis.
|
| It could be by design, by rendering any text in the svg icon
| google is making a design decision for you. They're choosing
| a font, or a specific emoji type. Maybe they want to avoid
| the problems that would ensue.
___________________________________________________________________
(page generated 2021-07-07 23:01 UTC)