Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Path menu in pure CSS3

lab.victorcoulon.fr

Post reply on HN
Print view View original

51–55 of 55 posts

Re: Path menu in pure CSS3

#51

Post by silentOpen »

ajanuary wrote: post #49
gue5t wrote: post #24

Earlier quoted context omitted.

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 co…

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 woul…

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

Re: Path menu in pure CSS3

#52

Post by chrisbroadfoot »

fooandbarify wrote: post #35
billpatrianakos wrote: post #34

Earlier quoted context omitted.

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 t…

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…

It originated from ed

Re: Path menu in pure CSS3

#53

Post by ajanuary »

silentOpen wrote: post #51
ajanuary wrote: post #49

Earlier quoted context omitted.

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 woul…

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

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

Re: Path menu in pure CSS3

#54

Post by 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!)

Re: Path menu in pure CSS3

#55

Post by cmelbye »

masonhensley wrote: post #30
necolas wrote: post #21

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:…

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?

Touching anywhere other than an icon when the menu is open (including swiping to scroll) causes the menu to close.
Post reply on HN