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.
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.
In addition to what the other replies said, there's another reason: effects like this reside purely in the presentation layer, and just like the argument for separating content from presentation, a good argument can be made for trying to separate application code from presentation as much as possible. The less animation you're doing with JavaScript, the less your application code will have worry about updating the presentation layer in a loosely coupled way – just changing a CSS class or whatever already provides that (relatively) loose coupling.
At BigDoor, we ship the same JavaScript code to many different partners, but their widgets can have very different form factors and visual effects. It's nice to not have to distribute a bunch of animation code to every partner just in case one partner's theme happens to use it – we can keep it in the CSS and just swap that out.
Soon I think people will see that using JavaScript for the simple animations they've been performing all this time (fade out, slide in, etc.) is just creating a tightly coupled system.
Javascript is turing-complete. That's a /lot/ of power and that means that security-conscious users (especially given the proliferation of more-powerful JS apis allowing the possibility for exploits in file, GPU, etc. access, along with JIT-enabled exploits as opposed to the old simple interpreting) will have it turned off whenever possible.
Using CSS for non-turing-complete interactions which are limited in their computational ability to a simple automaton means that CSS can be trusted much more than JS, and that there are stricter guarantees on performance. It's also semantically cleaner when used for things like visual effects on windows, because even if CSS doesn't load, the markup representing the menu will be intact. JS systems have the ability to load markup asynchronously or generate it from other data in the page and destroy all notion of graceful degradation.
More complexity leading to bigger surface area for potential attacks, yes. GPU and file access, yes. But nothing to do with turing completeness.
Here's a non turing complete language I wouldn't like to be able to run in a web context. It has a single command: rm {path}
On the other hand a turing complete language that has no access to any IO, DOM manipulation etc. I would be perfectly happy to let run.
It isn't the power that comes from turing completeness that makes javascript a potential security vulnerability, it's the interactions it can have outside of computation.
Let's be clear: "security-conscious users" who turn off Javascript are a very small minority. If a site is geared towards serving developers or small startups, it might be serving this minority. If not, SEO ("how do I make this site readable by search engines?") will be a much larger concern than "graceful degradation for the benefit of the tiny few who care about security enough to disable Javascript or use NoScript but not whitelist my sites' scripts". Often designing something to gracefully degrade will serve both SEO and security-conscious users, but in cases where it won't (this case for example -- where Google decidedly doesn't care about the layout of the navigation items, as long as they're accessible to it), there's not much incentive to find a pure-CSS approach when a pure-JS approach might be simpler.
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.
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.
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.
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.
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?
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.
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.)
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.
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.
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.
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.
The concept itself isn't very far removed from pie menus[1]; which have been around for quite some time. They're much more common in console games these days (the layout maps very well to an analog stick or face buttons); SketchBook (on both the desktop and phones/tablets) is another recent example that comes to mind.
i'm sorry, i don't understand who is competing or how this hurts Path.
all i've seen are people being inspired by Path, saying as much, then cleverly recreating the effect for themselves. these same people turn around and share their own code with the rest of the world via blog post or GitHub.
if anything this has helped spread the word about Path. this was how i first heard of them. throw in a bunch of people sharing and learning code techniques and it's a win for everyone.
> i'm sorry, i don't understand who is competing or how
> this hurts Path.
>
> all i've seen are people being inspired by Path, saying
> as much, then cleverly recreating the effect for
> themselves. these same people turn around and share
> their own code with the rest of the world via blog post
> or GitHub.
Looking at this from the perspective of Path, who have probably spent a fair amount of time thinking and conceiving the menu widget. Not just in how to implement it, but actually coming up with the idea, creating mock ups / wire frames, iterating on those mock ups, designing the icons, the animations, etc. All this for the sole purpose to give the user experience something new, and also to add a bit of delight to an app which could have easily become "yet another social networking app".
Then someone comes along and copied all their hard work (without figuring out the concept, the design, the animation, etc) and (as if to rub salt into the wounds) released it for free for everyone to use.
Honestly, if I were Path I'd be rather frustrated that this has happened though as a developer I love the fact that someone has done this and shared their work :)
I'm unsure why I was down voted for this. Was it because the down-voter didn't agree with my post (strange reason to down vote), or was it because it didn't contribute to the conversation (which I tried quite hard to do - by balancing both sides of the argument).
All I was trying to say was that in the field of UI, it is very hard to innovate though very easy to copy, and I can't help but feel that's what's happened here.
Path have made a very sexy looking widget which definitely added that certain something to their application, and someone has copied their hard work and made it free for everyone to use.
Wait, you mean to tell me you think this menu idea is unique and original? Oh, it's not seen that often, for sure, but it's not unique or original. It is well worn territory, used in a variety of applications prior to Path. This example might have seen their design and drawn inspiration from it, but they aren't the originators of this.
Radial menus have been around for a while. Path have done it very well though. It would be somewhat unwise to have your whole business model based on a menu animation.
I wouldn't have found out about Path without this post, so I imagine that Path are happy about the publicity. It looks like a cool app.
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.
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.)
I'm not exactly sure what you mean by "loops". Can you clarify? Maybe it's because I'm not very familiar with SASS or SCSS. If what you mean is how do you go about not having to repeat certain properties I'm thinking of just simple mixins. Something like:
Then you'd just add that in wherever you want some radius like so:
.star-container {
.circle-outlines-star(optional radius override here);
...and more styles...
}
Yeah, super simple and just off the top of my head but hopefully I addressed the question about loops. I don't know if you mean loops in code or literally like spinning animated loops. It's like 3am, got insomnia, and I'm effing commenting all night. Shoot me.
My question was...
The code on which this example is based uses SASS loops. Given that LESS hasn't got support for loops, how would you generate the required classes etc?
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!)
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.
