Icono – Pure CSS icons with only one element(saeedalipoor.github.io)
saeedalipoor.github.io
Icono – Pure CSS icons with only one element
http://saeedalipoor.github.io/icono/
11 comments
could someone explain what's going on here? i looked through the page and some of the code on github and am no wiser.
6 Apple products in these icons...
Was Apple a sponsor?
Was Apple a sponsor?
Absolutely beautiful!
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.
Still a nice showcase, congrats!
Still a nice showcase, congrats!
> it seems impossible to use multiple sizes in a single document
How so? It's possible in most cases to stick an extra class on the icon, say `.2x` and add a rule to your css such as —
How so? It's possible in most cases to stick an extra class on the icon, say `.2x` and add a rule to your css such as —
[class*="2x"] {
transform: scale(2)
}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".
The author could refactor them to use ems or percents instead of pixels, that way they would automatically change size depending on their parent.
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.
Impressive.
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.
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.
Very impressive. Slow as hell on my computer though (3 GHz Core2Duo, Chrome 39, OS X 10.9), to the point where it doesn't seem realistically usable…
Same impression, and I'm on a Macbook Book Pro Retina.
It's really, really slow on the retina display. A bit better on my second, Full HD monitor, but still not really responsive.
It's really, really slow on the retina display. A bit better on my second, Full HD monitor, but still not really responsive.
Speed up the transitions to get rid of the laggy feeling. Add this css rule to your inspector stylesheet:
.demo, .demo i, .demo .about, .change-color i { transition: all 0s !important; }
.demo, .demo i, .demo .about, .change-color i { transition: all 0s !important; }
I think the type of animations make this feel slow when it is actually not slow.
No issue with 1.3 GHz, Chrome 39, OS X 10.10.
second this, impressive but feels a bit sluggish.
These are awesome. Reminds me of the set Nicholas Gallagher created a few years ago. http://nicolasgallagher.com/pure-css-gui-icons/demo/
An incredible achievement. How long did this take to make?
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.
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.
Awesome. Please keep adding more icons.
Drawing with multiple box-shadow's, nice (performant??)