3 ms·

Neat. Makes me wonder why we can't do complex favicon design using html/css. Imagine being able to enter text and style it using layouts, fonts, colors, etc.

chrismorgan 6y ago
You can. You’ve got all of SVG except for scripting (which is disabled when SVG is loaded as an image, which happens if you use <img src=….svg> or favicons or such things), which should handle all of your complex favicon desires. If you really want HTML, well, SVG has the <foreignObject> tag which you can use to embed HTML (in the XML serialisation, so for once you will need to write <br/> instead of <br>). But pure SVG is likely to be a better idea. Sample markup to drop in an HTML file to get an HTML-powered “Hello, world!” favicon: <link rel=icon href='data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 48 48"><foreignObject width="48" height="48"><div xmlns="http://www.w3.org/1999/xhtml">Hello,<br/>world!</div></foreignObject></svg>'>
- gardaani 6y ago
  Ouch. We have come to the point where rendering a favicon requires a full web browser rendering engine.
  - spicybright 6y ago
    I can't help but think this is a huge step backwards.
    - chrismorgan 6y ago
      Whatever for? It’s a natural consequence of composition of useful elements. It may lead to functionality that you might not design into such a thing if you were making a whole stack from scratch, but the fact that it all works like this is, given HTML and SVG being what they are, categorically a good thing, and is, more generally and subjectively, at least not a bad thing. SVG can include foreign objects, which is decidedly useful in some contexts; in browsers, that includes HTML, because it’s easy. A favicon is an image, so it should allow all the usual types of images, which includes SVG. No reason to exclude SVG or any SVG features other than scripting. (“But now a non-browser can’t render the favicon properly!” you may say. By using <foreignObject>, you’re opting into non-standard functionality and shouldn’t expect all SVG renderers to be able to render that part. For completeness, I’ll note that you can provide an alternative representation for engines that don’t support XHTML in SVG with <switch> and requiredExtensions.)
      - spicybright 6y ago
        I like the idea in principal, but my main qualm is the complexity overhead of forcing the client to render something that is ultimately just a small image. I personally don't see a good reason not to render server side and save page load time, batteries, cpu cycles, etc. It's definitely a natural consequence of constant improvement of the tech, but I don't like each step piles on technical bloat. Yes, CPUs and browsers get faster over time, but all those improvements usually lead to more software bloat and cancel each other out. Which is a shame really. A majority of people in the world use old, non updated phones to access basic websites. Improvements like this can lock people out of portions of the web just because their browser can't handle rendering the favicon.
- arkitaip 6y ago
  Cool, didn't know SVG has this capability but man does it look ugly

chrismorgan 6y ago

You can. You’ve got all of SVG except for scripting (which is disabled when SVG is loaded as an image, which happens if you use <img src=….svg> or favicons or such things), which should handle all of your complex favicon desires. If you really want HTML, well, SVG has the <foreignObject> tag which you can use to embed HTML (in the XML serialisation, so for once you will need to write <br/> instead of <br>). But pure SVG is likely to be a better idea. Sample markup to drop in an HTML file to get an HTML-powered “Hello, world!” favicon: <link rel=icon href='data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 48 48"><foreignObject width="48" height="48"><div xmlns="http://www.w3.org/1999/xhtml">Hello,<br/>world!</div></foreignObject></svg>'>

gardaani 6y ago
Ouch. We have come to the point where rendering a favicon requires a full web browser rendering engine.
- spicybright 6y ago
  I can't help but think this is a huge step backwards.
  - chrismorgan 6y ago
    Whatever for? It’s a natural consequence of composition of useful elements. It may lead to functionality that you might not design into such a thing if you were making a whole stack from scratch, but the fact that it all works like this is, given HTML and SVG being what they are, categorically a good thing, and is, more generally and subjectively, at least not a bad thing. SVG can include foreign objects, which is decidedly useful in some contexts; in browsers, that includes HTML, because it’s easy. A favicon is an image, so it should allow all the usual types of images, which includes SVG. No reason to exclude SVG or any SVG features other than scripting. (“But now a non-browser can’t render the favicon properly!” you may say. By using <foreignObject>, you’re opting into non-standard functionality and shouldn’t expect all SVG renderers to be able to render that part. For completeness, I’ll note that you can provide an alternative representation for engines that don’t support XHTML in SVG with <switch> and requiredExtensions.)
    - spicybright 6y ago
      I like the idea in principal, but my main qualm is the complexity overhead of forcing the client to render something that is ultimately just a small image. I personally don't see a good reason not to render server side and save page load time, batteries, cpu cycles, etc. It's definitely a natural consequence of constant improvement of the tech, but I don't like each step piles on technical bloat. Yes, CPUs and browsers get faster over time, but all those improvements usually lead to more software bloat and cancel each other out. Which is a shame really. A majority of people in the world use old, non updated phones to access basic websites. Improvements like this can lock people out of portions of the web just because their browser can't handle rendering the favicon.
arkitaip 6y ago
Cool, didn't know SVG has this capability but man does it look ugly