It might be time for me to stop worrying about IE8 and embrace `transform`-dependent icons.
I regularly create one-off semantic icons as long as they don't rely on `transform`. That limits it to ones based on a character glyph - (i), (?), (x), etc - strictly orthogonal blocks - (+), (-), etc. - or CSS triangles - mostly arrows (which don't always render great anywho).
I'm always too concerned about the fallback in browsers without `transform`. But really, that's illogical - it's just IE <= 8, and generally don't need to worry about that support anyways. I guess my hangup is that the meaning of the icon gets garbled when it isn't displayed correctly in older browsers, and that seems like it crosses a line. (Thought about the "semantics" of an icon quickly feels like Philosophy 101 and probably means its time to get back to work!)
As others have pointed out, I wouldn't use the pixel-based positioning/widths as this does, but `em`s, `rem`s or `percent`s. Relying on `tranform: scale(x)` would complicate layout flows - for one thing you'd always need to compensate for the scale with `margin`, `padding`, or other pixel-budging.
That's really smart - However, it seems impossible to use multiple sizes in a single document, which make it impractical over other alternatives such as Ionicons, Icomoon or FontAwesome.
Perfectly viable technique, though if they are written in SASS/LESS/whatever, the author could refactor the icons to mixins with a parameter that sets the scale, so the values themselves are "true".
Downside of using this is transform still leaves the box size that's in the flow of the document the same size. Problematic if you have the icons inline, or in elements like buttons.
While I appreciate the effort and the fact that is is more of an experiment than a production-ready package, it does seem like an odd choice to go with fixed-size pixels instead of something relative, like ems or percentages.
Regardless, well done. Don't let my typical-to-HN negative tone take away from the accomplishment of this.
I regularly create one-off semantic icons as long as they don't rely on `transform`. That limits it to ones based on a character glyph - (i), (?), (x), etc - strictly orthogonal blocks - (+), (-), etc. - or CSS triangles - mostly arrows (which don't always render great anywho).
I'm always too concerned about the fallback in browsers without `transform`. But really, that's illogical - it's just IE <= 8, and generally don't need to worry about that support anyways. I guess my hangup is that the meaning of the icon gets garbled when it isn't displayed correctly in older browsers, and that seems like it crosses a line. (Thought about the "semantics" of an icon quickly feels like Philosophy 101 and probably means its time to get back to work!)
As others have pointed out, I wouldn't use the pixel-based positioning/widths as this does, but `em`s, `rem`s or `percent`s. Relying on `tranform: scale(x)` would complicate layout flows - for one thing you'd always need to compensate for the scale with `margin`, `padding`, or other pixel-budging.