3 ms·

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

by 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.

by 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.