3 ms·

Just wondering, is there still any legitimate reason for doing this over using something like svg? Or is it mostly to show off in the same spirit as obfuscated

• gkoberger 10y ago
  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.
• Sylos 10y ago
  Sort of to show off, but also simply the very artsy reason of seeing what you can come up with when restricting yourself. Or to quote from the corresponding Mozilla Hacks article (link to which can be found in the page source): But why a single div? When I was learning to paint, my class did these color mixing exercises where we created the many colors of the spectrum from only the three primary colors: red, yellow, and blue. The purpose of the exercise is to learn the behavior of the medium and the constraints show us the power of combination. You can certainly buy green paint, but you can also create green from blue and yellow. Restricting your available options forces you to re-evaluate the tools you already have. I decided to start a CSS drawing project, every few days illustrating something new with only CSS. To further challenge and explore what CSS is capable of, I gave myself the constraint of using only a single div in the markup. Instead of buying green paint (or adding another div), I’d need to stretch and combine CSS properties to achieve my goals.
  • Freak_NL 10y ago
    You might want to use something other than a code block for quotes. That second paragraph is a bit hard to read crammed all on one line.
• xemdetia 10y ago
  I think there is a place for this in performance hacking for the experience around the first load of the webpage experience. You are inevitably going to load a .css file anyway, but if you include it in the .css you aren't now having to download additional assets. So in only 3 GET you could be getting your complete html, javascript and css payload, rather than 6+ of html, javascript, css and core assets. You would be spending your network budget on only the assets that make no sense to replicate via SVG but everything else would show up on time. There's probably a case to be made as well for performance for people using electron or similar.
  • WiseWeasel 10y ago
    You can embed SVG in HTML if you want to limit asset requests.