4 ms·

It's definitely just showing off what you can do with a single div and CSS, much like your latter examples. It's an experiment in constraints. However, I could

It's definitely just showing off what you can do with a single div and CSS, much like your latter examples. It's an experiment in constraints. However, I could see something like this being useful in the case where you're using a third-party site and are only allowed to edit CSS. You probably don't need something as complicated as a cross-stitched heart, however it does show some techniques for squeezing as much in as possible. It also could be useful for a Font-Awesome-style icon set, where you just type <i class="icon-flower"></i>, although I imagine most people would prefer to just do something like <img src="/flower.svg">.

derefr 10y ago
Personally, I'd prefer .icon-flower:before { content: url(/flower.svg); } —which would effectively treat the SVG not as an image or background or anything, but rather as a character glyph from a synthesized single-character graphical-emoji font—meaning your SVG design would be display:inline'd at the current font-size, including font-styles (oldschool faux-italics) and text-decorations (properly-positioned and shaped underline/outline drawn before the SVG glyph's stroke.) The text engine is already incredibly expressive for doing arbitrary vector-glyph layout; so if you're creating your own one-off vector glyphs, why shouldn't you be allowed to manipulate them using the text engine?
- manmal 10y ago
  That's an option if you want your icon monocolored, but else you'll need the other options. Or, if you want a responsive icon, you'll need the pure CSS approach AFAIK.
  - minitech 10y ago
    What is a "responsive icon"? Keep in mind that you can just switch the path to the SVG in CSS in the same way that you'd alter properties of a CSS image.
    - helb 10y ago
      http://www.responsiveicons.co.uk/ http://www.responsiveicons.co.uk/
  - derefr 10y ago
    Right, that's the way things stand as they are today, where (afaik) only Apple's renderer actually has support for graphical emoji (and even then, it requires mipmapped bitmaps, not color vectors), and everyone else just supports emoji using what they can manage from pure OpenType specifiers. I was more referring to a hypothetical world where text-rendering engines were slightly expanded in their purpose, becoming generalized "inline graphical glyph layout engines", and exposed an API roughly like the following: Text.compileGlyph(Buffer) -> Text.Font.Glyph Text.Font() -> Text.Font Text.Font.mapLigature([Text.Codepoint], Text.Font.Glyph) -> () Text.Font.getUniqueName() -> String Then the above CSS would be a shortcut for doing this Javascript: function createImageIconClass(className, someSVGURL) { const svg_glyph = Text.compileGlyph(someSVGURL) const synthesized_font = new Text.Font() synthesized_font.mapLigature(Text.Codepoint.fromString("\uE075"), svg_glyph) const font_name = synthesized_font.getUniqueName() const synthesized_css = document.createElement('style') synthesized_css.type = 'text/css' synthesized_css.innerHTML = ` .${className}:before { font-family: ${font_name}; content: "\E075"; } ` document.getElementsByTagName('head')[0].appendChild(synthesized_css) } ...where the text-rendering engine would have the full capacity to render all SVG features when rendering an SVG "glyph", but would also do all the same optimizations it does to regular OpenType/TrueType glyphs (doing its own GPU-memory mipmap-generation of used ligatures at each size, etc.) If this was done correctly, you could actually deliver a "font" as a JSON object that would be synthesized in the browser at runtime, if you wanted. (I have no idea why you'd want that, but you could. Allowing for streaming fonts where the characters used above the fold load first, maybe?) And you could generate new text-engine objects at runtime—this could be used with graphical SVG icons to achieve an effect similar to GPU texture-atlassing for games.

derefr 10y ago

Personally, I'd prefer .icon-flower:before { content: url(/flower.svg); } —which would effectively treat the SVG not as an image or background or anything, but rather as a character glyph from a synthesized single-character graphical-emoji font—meaning your SVG design would be display:inline'd at the current font-size, including font-styles (oldschool faux-italics) and text-decorations (properly-positioned and shaped underline/outline drawn before the SVG glyph's stroke.) The text engine is already incredibly expressive for doing arbitrary vector-glyph layout; so if you're creating your own one-off vector glyphs, why shouldn't you be allowed to manipulate them using the text engine?

manmal 10y ago
That's an option if you want your icon monocolored, but else you'll need the other options. Or, if you want a responsive icon, you'll need the pure CSS approach AFAIK.
- minitech 10y ago
  What is a "responsive icon"? Keep in mind that you can just switch the path to the SVG in CSS in the same way that you'd alter properties of a CSS image.
  - helb 10y ago
    http://www.responsiveicons.co.uk/ http://www.responsiveicons.co.uk/
- derefr 10y ago
  Right, that's the way things stand as they are today, where (afaik) only Apple's renderer actually has support for graphical emoji (and even then, it requires mipmapped bitmaps, not color vectors), and everyone else just supports emoji using what they can manage from pure OpenType specifiers. I was more referring to a hypothetical world where text-rendering engines were slightly expanded in their purpose, becoming generalized "inline graphical glyph layout engines", and exposed an API roughly like the following: Text.compileGlyph(Buffer) -> Text.Font.Glyph Text.Font() -> Text.Font Text.Font.mapLigature([Text.Codepoint], Text.Font.Glyph) -> () Text.Font.getUniqueName() -> String Then the above CSS would be a shortcut for doing this Javascript: function createImageIconClass(className, someSVGURL) { const svg_glyph = Text.compileGlyph(someSVGURL) const synthesized_font = new Text.Font() synthesized_font.mapLigature(Text.Codepoint.fromString("\uE075"), svg_glyph) const font_name = synthesized_font.getUniqueName() const synthesized_css = document.createElement('style') synthesized_css.type = 'text/css' synthesized_css.innerHTML = ` .${className}:before { font-family: ${font_name}; content: "\E075"; } ` document.getElementsByTagName('head')[0].appendChild(synthesized_css) } ...where the text-rendering engine would have the full capacity to render all SVG features when rendering an SVG "glyph", but would also do all the same optimizations it does to regular OpenType/TrueType glyphs (doing its own GPU-memory mipmap-generation of used ligatures at each size, etc.) If this was done correctly, you could actually deliver a "font" as a JSON object that would be synthesized in the browser at runtime, if you wanted. (I have no idea why you'd want that, but you could. Allowing for streaming fonts where the characters used above the fold load first, maybe?) And you could generate new text-engine objects at runtime—this could be used with graphical SVG icons to achieve an effect similar to GPU texture-atlassing for games.