7 ms·

Path menu in pure CSS3

213 points by zeppelin_7 15y ago

robin_reala 15y ago
Would work in Firefox too with if the author had bothered to add the -moz-animation rules.
- Flam 15y ago
  I came to write this. It's a nice experiment anyways.
  - _victa 15y ago
    If you watch the source here : https://github.com/Victa/path-menu/blob/master/sass/app.scss https://github.com/Victa/path-menu/blob/master/sass/app.scss // Generate keyframes // Sass interpolation doesn't work with keyframe. CF : https://github.com/nex3/sass/issues/46 https://github.com/nex3/sass/issues/46 // so I use a tricks ==> "appear-'#{$i}'" - And it doesn't work in Firefox. It's impossible to generate @-moz-Keyframes + interpolation with Sass yet. That's why the experiment works only in Webkit.
    - robin_reala 15y ago
      Fair enough, but my instinct at that point would be to dump Sass rather than restrict an experiment to one browser.
- miles_matthias 15y ago
  Well the code is on github - fork it and update it!
  - WalterGR 15y ago
    I don't understand the "you aren't allowed to comment if you haven't submitted code" sentiment.
    - billpatrianakos 15y ago
      Don't take it wrong. It probably just means that the author was nice enough to make it and give it for free and if you have a problem, try to fix it instead of acting like an entitled asshole and demanding X feature or bug fix for code you didn't contribute to and are using for free. There are a ton of people who like to bitch at open source developers about not including or fixing something and for projects like this tht isn't cool. This is just a guy showing off some cool thing he did. If you want to use it, have at it! Make it better? Contribute! Have a complaint? Go fuck yourself. It's not meant for people who have constructive criticism or are just discussing the merits of the code or technique like us.
      - miles_matthias 15y ago
        Exactly my sentiment :)
      - _victa 15y ago
        thanks Bill. This is exactly that.
      - WalterGR 15y ago
        There are a ton of people who like to bitch at open source developers about not including or fixing something and for projects like this tht isn't cool. Yeah, this is an excellent way to deflect criticism from open source projects. I've seen it frequently stop what could be a useful discussion in its tracks. (And this isn't a comment to you specifically, but that sentiment combined with closed-source-software-as-unethical turns my stomach.)
        billpatrianakos 15y ago
        Yeah, you're right. But I think we can agree that it makes sense for this project, right? This isn't something like Firefox where they actively try to get you to use the software and one day turn around and say "don't complain because it's free". Instead this is an obviously one-off effort and the open sourcing was just to share it with us fine folks so we know it can be done and maybe add a few tools to our boxes. I certainly wouldn't expect any maintenance on this project. Again, I know what you mean, I've seen it, and it's lame but I see this as an exception where it makes sense.
MnkyPwz 15y ago
This is actually pretty awesome!
10dpd 15y ago
Nice! What the the licensing implications of using this code & interaction model? Luckily Path don't seem to have a patent on this, otherwise you'd have to change the circles to squares...
steve8918 15y ago
Obviously Path has done something great in terms of coming up with a beautiful, innovative menu design. Do people here think that Path should have been granted some type of protection so that others couldn't copy its look and feel so quickly, or it is okay that competitors have come out almost immediately? I am just asking the question, I'm not sure how I feel about the issue. I'm against software patents, but I could certainly understand if Path's GUI designers are pissed that people are copying them so quickly, and making them lose their advantage.
- thwarted 15y ago
  I seriously hope they don't consider a menu design to be a major competitive advantage. Presumably, people will use Path not because of the menu system.
- eCa 15y ago
  > Do people here think that Path should have been granted some type of protection Of course not. If so, the same would have had to be said for any number of design elements created in the past.
- endtwist 15y ago
  I think this would fall under a "design patent"[1] (though I may be wrong). Since they didn't bother to get one, as long as the actual assets aren't used, the interaction and design can be imitated. Also, speaking as a designer, I would be thrilled if I saw people so fervently duplicating an interaction scheme I had created. "Imitation is the sincerest form of flattery," and all that. [1] http://en.wikipedia.org/wiki/Design_patent http://en.wikipedia.org/wiki/Design_patent
- moe 15y ago
  understand if Path's GUI designers are pissed that people are copying them so quickly, and making them lose their advantage. Repeat after me: The arrangement of a popup-menu is not patent-worthy.
- AndyJPartridge 15y ago
  I saw a very similar idea a while back here, and bookmarked it. http://playground.mobily.pl/jquery/mobily-blocks/demo.html http://playground.mobily.pl/jquery/mobily-blocks/demo.html It's a short breath away from what Path have done. I love the aesthetics of both, I have to say. Great work.
alex_h 15y ago
Can someone enlighten me as to why "pure CSS" is seen as the pinnacle of web design? It seems that for problems involving a computational element like this, Javascript would be much more concise and readable. Having said that, it is beautifully done.
- aiscott 15y ago
  People like to push a technology as far as they can. It's part of the satisfaction of mastering a tech that you think of ways to push it beyond what is considered the comfort zone of that tech. There might be some inherent value of avoiding javascript, but I think this is just a hack for the satisfaction of being able to do it.
  - sirn 15y ago
    > There might be some inherent value of avoiding javascript CSS transitions are faster than JavaScript animations[1]. Browser could easily optimize them (since each keyframes are predefined) vs. DOM manipulation, which is always slow. [1]: https://developer.mozilla.org/en/CSS/CSS_animations https://developer.mozilla.org/en/CSS/CSS_animations
- 9oliYQjP 15y ago
  I would say that from 2006 and earlier, designers sought to go "pure CSS" primarily because of the possibility of javascript being disabled on the client. Especially for search engine crawlers at the time, this would be a bad thing. Things have changed and more and more people run with javascript enabled, and more and more website stakeholders are willing to put up with things being broken for users who don't have it enabled. I know that's a contentious statement, but it's true. If Google Analytics and ads aren't being pushed down to you because javascript is disabled, most site owners are willing to put up with the experience being broken for you too. I'll sidestep the debate of graceful degradation. Now however, there are performance reasons for going "pure CSS". A lot of CSS transforms and animations are hardware accelerated and/or just animate more fluidly than they would if they were animated via javascript. Javascript is single threaded, and when a webpage is doing a ton of varied activities, it's hard to ensure fluid animation when the only tools at your disposal for drawing frames are pretty crude methods like setTimeout.
necolas 15y ago
I hacked on the core animation of the Path menu for a few minutes last week (it's pretty rough) using a combination of CSS and JS that is a bit leaner and more flexible. http://jsfiddle.net/necolas/RGYUg/ http://jsfiddle.net/necolas/RGYUg/ The benefit of using JS to calculate the positioning (especially in an environment where JS will always be enabled) is that you can have the menu items correctly positioned irrespective of the number of items. Edit: This is also an interesting approach: http://beaucollins.github.com/radial-menu/ http://beaucollins.github.com/radial-menu/
- tingletech 15y ago
  cool; I added some more css selectors (such as -moz and -o) and tested it on Firefox http://jsfiddle.net/RGYUg/5/ http://jsfiddle.net/RGYUg/5/ [edit; saw typo in fiddle, updated link]
- masonhensley 15y ago
  I like how beau's version collapses the nav buttons when you scroll up or down the page on my iPad. I haven't taken a look to see if it was intentional or a bug; but it's neat nontheless, if a user decided to scroll, I think that the nav should collapse out of the way. Can anyone comment on how the iOS path app behaves when you scroll?
  - cmelbye 15y ago
    Touching anywhere other than an icon when the menu is open (including swiping to scroll) causes the menu to close.
- jonah 15y ago
  This is a great illustration of the difference between "works" and Works. This implementation is unsettling to me, while the original Path version is pleasant. It's hard to pin down - they're very close. (I think it's the animation speed and rapidly spinning icons mostly.) As someone put it in another post it's the difference between the works of Google/Microsoft et. al. and the Works of Apple, Path, etc. The former would see this and sign off - "it works" like we specified, while at latter, this would be a good first pass and then "make 10 refinements" to get it to "feel" right. No offense Beau, I'm just using yours as an example.
baby 15y ago
Would it work on firefox if you just remove "webkit-" from the code?
- fooandbarify 15y ago
  s/webkit/moz/
  - billpatrianakos 15y ago
    I hope this isn't dumb but what does "s/Webkit/moz" mean? To answer the poster above you, it would work by adding "-moz-propertyname" not removing the "-webkit" stuff. Each browser will ignore the proprietary prefix that doesn't apply to them and then apply the CSS to any style that is prefixed for them or the official implementation. So you can put prefixes for all vendors in your rules and the browser will choose the one that applies while safely ignoring the rest. Just make sure to add the "official" non-prefixed version last so that future browsers or those who implement the spec completely today can render the final version of their implementation of the specific CSS style instead of the half baked proprietary one. I'd add that vendor prefixes are one of the best reasons to use LESS (or SASS or SCSS, I just prefer LESS). Write one mixin (6 lines of code if you line break between each property) and you've just saved yourself countless keystrokes.
    - fooandbarify 15y ago
      Not dumb at all! It's a common shorthand around here because in vim (and presumably other text editors) that is the syntax for replacing strings - in this case, replace "webkit" with "moz". It was a useless comment on my part. What I meant (and should have said) is that merely removing the vendor prefix "webkit" wouldn't make it work with Mozilla, but replacing it with "moz" probably would. (I'm not certain about the details of Mozilla's feature parity with Webkit when it comes to CSS animations but I suspect they are almost equal.)
      - risratorn 15y ago
        might be easier to remember for non-vi users when you use the term [s]ubstitute instead of replace, makes more sense ... :D (another uselss comment tho)
billpatrianakos 15y ago
This is why I love working on the web! People constantly experimenting and trying to find new/better/alternative ways to do things then others run off and apply them in wonderful new ways but only after the creator gives it out freely. Thank you for this! It's so cool! I don't have a use for it but I certainly appreciate it anyway and I'm sure I can find a legit use.
juanipis 15y ago
saw this one earlier in dribbble, http://dribbble.com/shots/340844 http://dribbble.com/shots/340844 http://sparanoid.com/lab/path-menu/ http://sparanoid.com/lab/path-menu/
tudorw 15y ago
If it does not degrade gracefully, throw it out, the internet is meant to be useful, it's not a playground. (BTW, no disrespect to the author, when it work's it's mighty neat!)

213 points by zeppelin_7 15y ago

robin_reala 15y ago

Would work in Firefox too with if the author had bothered to add the -moz-animation rules.

Flam 15y ago
I came to write this. It's a nice experiment anyways.
- _victa 15y ago
  If you watch the source here : https://github.com/Victa/path-menu/blob/master/sass/app.scss https://github.com/Victa/path-menu/blob/master/sass/app.scss // Generate keyframes // Sass interpolation doesn't work with keyframe. CF : https://github.com/nex3/sass/issues/46 https://github.com/nex3/sass/issues/46 // so I use a tricks ==> "appear-'#{$i}'" - And it doesn't work in Firefox. It's impossible to generate @-moz-Keyframes + interpolation with Sass yet. That's why the experiment works only in Webkit.
  - robin_reala 15y ago
    Fair enough, but my instinct at that point would be to dump Sass rather than restrict an experiment to one browser.
miles_matthias 15y ago
Well the code is on github - fork it and update it!
- WalterGR 15y ago
  I don't understand the "you aren't allowed to comment if you haven't submitted code" sentiment.
  - billpatrianakos 15y ago
    Don't take it wrong. It probably just means that the author was nice enough to make it and give it for free and if you have a problem, try to fix it instead of acting like an entitled asshole and demanding X feature or bug fix for code you didn't contribute to and are using for free. There are a ton of people who like to bitch at open source developers about not including or fixing something and for projects like this tht isn't cool. This is just a guy showing off some cool thing he did. If you want to use it, have at it! Make it better? Contribute! Have a complaint? Go fuck yourself. It's not meant for people who have constructive criticism or are just discussing the merits of the code or technique like us.
    - miles_matthias 15y ago
      Exactly my sentiment :)
    - _victa 15y ago
      thanks Bill. This is exactly that.
    - WalterGR 15y ago
      There are a ton of people who like to bitch at open source developers about not including or fixing something and for projects like this tht isn't cool. Yeah, this is an excellent way to deflect criticism from open source projects. I've seen it frequently stop what could be a useful discussion in its tracks. (And this isn't a comment to you specifically, but that sentiment combined with closed-source-software-as-unethical turns my stomach.)
      - billpatrianakos 15y ago
        Yeah, you're right. But I think we can agree that it makes sense for this project, right? This isn't something like Firefox where they actively try to get you to use the software and one day turn around and say "don't complain because it's free". Instead this is an obviously one-off effort and the open sourcing was just to share it with us fine folks so we know it can be done and maybe add a few tools to our boxes. I certainly wouldn't expect any maintenance on this project. Again, I know what you mean, I've seen it, and it's lame but I see this as an exception where it makes sense.

MnkyPwz 15y ago

This is actually pretty awesome!

10dpd 15y ago

Nice! What the the licensing implications of using this code & interaction model? Luckily Path don't seem to have a patent on this, otherwise you'd have to change the circles to squares...

steve8918 15y ago

Obviously Path has done something great in terms of coming up with a beautiful, innovative menu design. Do people here think that Path should have been granted some type of protection so that others couldn't copy its look and feel so quickly, or it is okay that competitors have come out almost immediately? I am just asking the question, I'm not sure how I feel about the issue. I'm against software patents, but I could certainly understand if Path's GUI designers are pissed that people are copying them so quickly, and making them lose their advantage.

thwarted 15y ago
I seriously hope they don't consider a menu design to be a major competitive advantage. Presumably, people will use Path not because of the menu system.
eCa 15y ago
> Do people here think that Path should have been granted some type of protection Of course not. If so, the same would have had to be said for any number of design elements created in the past.
endtwist 15y ago
I think this would fall under a "design patent"[1] (though I may be wrong). Since they didn't bother to get one, as long as the actual assets aren't used, the interaction and design can be imitated. Also, speaking as a designer, I would be thrilled if I saw people so fervently duplicating an interaction scheme I had created. "Imitation is the sincerest form of flattery," and all that. [1] http://en.wikipedia.org/wiki/Design_patent http://en.wikipedia.org/wiki/Design_patent
moe 15y ago
understand if Path's GUI designers are pissed that people are copying them so quickly, and making them lose their advantage. Repeat after me: The arrangement of a popup-menu is not patent-worthy.
AndyJPartridge 15y ago
I saw a very similar idea a while back here, and bookmarked it. http://playground.mobily.pl/jquery/mobily-blocks/demo.html http://playground.mobily.pl/jquery/mobily-blocks/demo.html It's a short breath away from what Path have done. I love the aesthetics of both, I have to say. Great work.

alex_h 15y ago

Can someone enlighten me as to why "pure CSS" is seen as the pinnacle of web design? It seems that for problems involving a computational element like this, Javascript would be much more concise and readable. Having said that, it is beautifully done.

aiscott 15y ago
People like to push a technology as far as they can. It's part of the satisfaction of mastering a tech that you think of ways to push it beyond what is considered the comfort zone of that tech. There might be some inherent value of avoiding javascript, but I think this is just a hack for the satisfaction of being able to do it.
- sirn 15y ago
  > There might be some inherent value of avoiding javascript CSS transitions are faster than JavaScript animations[1]. Browser could easily optimize them (since each keyframes are predefined) vs. DOM manipulation, which is always slow. [1]: https://developer.mozilla.org/en/CSS/CSS_animations https://developer.mozilla.org/en/CSS/CSS_animations
9oliYQjP 15y ago
I would say that from 2006 and earlier, designers sought to go "pure CSS" primarily because of the possibility of javascript being disabled on the client. Especially for search engine crawlers at the time, this would be a bad thing. Things have changed and more and more people run with javascript enabled, and more and more website stakeholders are willing to put up with things being broken for users who don't have it enabled. I know that's a contentious statement, but it's true. If Google Analytics and ads aren't being pushed down to you because javascript is disabled, most site owners are willing to put up with the experience being broken for you too. I'll sidestep the debate of graceful degradation. Now however, there are performance reasons for going "pure CSS". A lot of CSS transforms and animations are hardware accelerated and/or just animate more fluidly than they would if they were animated via javascript. Javascript is single threaded, and when a webpage is doing a ton of varied activities, it's hard to ensure fluid animation when the only tools at your disposal for drawing frames are pretty crude methods like setTimeout.

necolas 15y ago

I hacked on the core animation of the Path menu for a few minutes last week (it's pretty rough) using a combination of CSS and JS that is a bit leaner and more flexible. http://jsfiddle.net/necolas/RGYUg/ http://jsfiddle.net/necolas/RGYUg/ The benefit of using JS to calculate the positioning (especially in an environment where JS will always be enabled) is that you can have the menu items correctly positioned irrespective of the number of items. Edit: This is also an interesting approach: http://beaucollins.github.com/radial-menu/ http://beaucollins.github.com/radial-menu/

tingletech 15y ago
cool; I added some more css selectors (such as -moz and -o) and tested it on Firefox http://jsfiddle.net/RGYUg/5/ http://jsfiddle.net/RGYUg/5/ [edit; saw typo in fiddle, updated link]
masonhensley 15y ago
I like how beau's version collapses the nav buttons when you scroll up or down the page on my iPad. I haven't taken a look to see if it was intentional or a bug; but it's neat nontheless, if a user decided to scroll, I think that the nav should collapse out of the way. Can anyone comment on how the iOS path app behaves when you scroll?
- cmelbye 15y ago
  Touching anywhere other than an icon when the menu is open (including swiping to scroll) causes the menu to close.
jonah 15y ago
This is a great illustration of the difference between "works" and Works. This implementation is unsettling to me, while the original Path version is pleasant. It's hard to pin down - they're very close. (I think it's the animation speed and rapidly spinning icons mostly.) As someone put it in another post it's the difference between the works of Google/Microsoft et. al. and the Works of Apple, Path, etc. The former would see this and sign off - "it works" like we specified, while at latter, this would be a good first pass and then "make 10 refinements" to get it to "feel" right. No offense Beau, I'm just using yours as an example.

baby 15y ago

Would it work on firefox if you just remove "webkit-" from the code?

fooandbarify 15y ago
s/webkit/moz/
- billpatrianakos 15y ago
  I hope this isn't dumb but what does "s/Webkit/moz" mean? To answer the poster above you, it would work by adding "-moz-propertyname" not removing the "-webkit" stuff. Each browser will ignore the proprietary prefix that doesn't apply to them and then apply the CSS to any style that is prefixed for them or the official implementation. So you can put prefixes for all vendors in your rules and the browser will choose the one that applies while safely ignoring the rest. Just make sure to add the "official" non-prefixed version last so that future browsers or those who implement the spec completely today can render the final version of their implementation of the specific CSS style instead of the half baked proprietary one. I'd add that vendor prefixes are one of the best reasons to use LESS (or SASS or SCSS, I just prefer LESS). Write one mixin (6 lines of code if you line break between each property) and you've just saved yourself countless keystrokes.
  - fooandbarify 15y ago
    Not dumb at all! It's a common shorthand around here because in vim (and presumably other text editors) that is the syntax for replacing strings - in this case, replace "webkit" with "moz". It was a useless comment on my part. What I meant (and should have said) is that merely removing the vendor prefix "webkit" wouldn't make it work with Mozilla, but replacing it with "moz" probably would. (I'm not certain about the details of Mozilla's feature parity with Webkit when it comes to CSS animations but I suspect they are almost equal.)
    - risratorn 15y ago
      might be easier to remember for non-vi users when you use the term [s]ubstitute instead of replace, makes more sense ... :D (another uselss comment tho)

billpatrianakos 15y ago

This is why I love working on the web! People constantly experimenting and trying to find new/better/alternative ways to do things then others run off and apply them in wonderful new ways but only after the creator gives it out freely. Thank you for this! It's so cool! I don't have a use for it but I certainly appreciate it anyway and I'm sure I can find a legit use.

juanipis 15y ago

saw this one earlier in dribbble, http://dribbble.com/shots/340844 http://dribbble.com/shots/340844 http://sparanoid.com/lab/path-menu/ http://sparanoid.com/lab/path-menu/

tudorw 15y ago

If it does not degrade gracefully, throw it out, the internet is meant to be useful, it's not a playground. (BTW, no disrespect to the author, when it work's it's mighty neat!)