
Path menu in pure CSS3 - zeppelin_7
http://lab.victorcoulon.fr/css/path-menu/
======
alex_h
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.

~~~
gue5t
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.

~~~
ajanuary
It has nothing to do with turing completeness.

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.

~~~
silentOpen
Its imperative nature (mutation, side effects) and potential non-termination
makes it unattractive as a catch-all hypertext document language.

By using the language of Least Power (timbl@w3c.org) that still accomplishes
your task, you achieve a more concise and more analyzable document.

I wouldn't call that "nothing to do with TC".

~~~
ajanuary
Its imperative nature is unrelated to TC.

Non TC languages can be sufficiently complex as to make analysis difficult.

I don't see any of the risks of js as linked to TC in any meaningful way
beyond a very hand-wavey "TC tends to lead to complexness".

------
necolas
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/>

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/>

~~~
masonhensley
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
Touching anywhere other than an icon when the menu is open (including swiping
to scroll) causes the menu to close.

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

~~~
miles_matthias
Well the code is on github - fork it and update it!

~~~
WalterGR
I don't understand the "you aren't allowed to comment if you haven't submitted
code" sentiment.

~~~
billpatrianakos
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.

~~~
WalterGR
_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
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.

------
steve8918
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.

~~~
AndyJPartridge
I saw a very similar idea a while back here, and bookmarked it.

<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.

~~~
ConstantineXVI
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.

[1] <http://en.wikipedia.org/wiki/Pie_menu>

------
10dpd
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...

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

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

~~~
fooandbarify
s/webkit/moz/

~~~
billpatrianakos
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
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
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)

------
tudorw
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!)

------
billpatrianakos
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.

------
MnkyPwz
This is actually pretty awesome!

