Do Mozilla devs read HN? This is significantly slower in Firefox (Nightly) than on Chrome (Canary). I hope it's someone's job to go through all the CSS posts that make it near the top of HN and figure out what needs to be done to make FF better.
Yes, we do. I've just reported an issue with this page (a crash), and we are specifically working to improve our blur algorithm (which is use to make the box-shadow in CSS).
afaik, it's not a specific position to read the CSS posts that make the front page on Hacker News, but a lot of people read HN and other similar websites, and we usually open tickets and/or bug the right people.
Because Mozilla is an open organization, you could even file a bug [1], or come and tell us on irc [2], if you care. That would be much appreciated and falls into the category of things people have to do for us all to get a better Firefox.
The first thing I did (by accidental movement on the trackpad) was mouse-scroll zoom all the way out to make the thing almost invisible. Since the scroll only triggers when the mouse is over the elements themselves, this made it completely non-functional until I reloaded.
Make the scroll zoom far less sensitive, or at least make it trigger on the whole canvas.
There are two video demos available on http://famo.us/ and you can sign up there to stay informed about our progress and know when we publicly release our library.
Looks nice, but arranging the elements as a sphere, spiral, etc. completely defeats the purpose of the periodic table. Also, your atomic numbers are off by one.
There are a number of alternative period table layouts[1] that highlight different aspects of the relationships between elements. I taught chemistry for a bit, and I coveted this swooping three-dimensional spiral model that gorgeously showed how the electrons were filling out the different orbitals...
Doob is the man, and I was disappointed when I hit the spiral button and it was a demo of putting the things in a spiral, not the half-remembered spiral-esque model in my mind.
Certainly a cool demo — but has anyone already seen a use of 3D in CSS/WebGL for a productive purpose? I'd be really interested in that; showing the atoms/molecules in 3D, as it is the suggested in one of the comments in the link @mmahemoff posted, for example, seems like a great idea.
IMHO, the biggest use case for 3D right now is to add affordances to current flat interfaces. Many interfaces already incorporate 3D affordances, usually demonstrating depth to help the user understand what is happening, but these affordances are almost always faked, the same way that 3D is often faked by photoshop wizards.
At famo.us, we hope to make it much easier for interface designers use real 3D effects to add affordances to their interface and explore how else 3D can be used. Previously, if you wanted to design a 3D interface you had to completely invest in 3D, which is expensive time-wise to do for the sake of experimentation. What we'd like to do at famo.us is bridge 2D and 3D in a way that you can build your interfaces using familiar 2D paradigms, but also give you the tooling to explore 3D using real content you already have in 2D.
As more designers explore 3D and more customers become familiar with 3D little by little, I think we'll see more and more examples of its utility.
Here's a video where 3D is used with a constrained z-depth and orthogonal camera position (i.e. elevation view).
It is a productive purpose, but a very obvious one — designing a 3D object requires 3D display.
We keep seeing impressive 3D interfaces for regular everyday tasks in sci-fi movies, so I was just wondering whether this way of displaying information actually is useful.
three.js is an impressive library but sadly, they still haven't fixed their busy wait architecture: if you do nothing and just stare at the page, it will still peg your CPU.
Library just gives you renderer with render function. It is up to you when and how you call it.
It's just that most of examples use requestAnimationFrame to call renderer.render, which gets called by browser when browser refreshes the screen (usually at 60 fps).
This makes sense when you can expect either changes in the scene or if a camera view changes all the time (most of examples are like this).
But if you know both your scene and camera will be static for a reasonable amount of time, you can update the rendering just at points of time when changes happen.
You can't use a busy wait for animations in JavaScript.
three.js schedules frames with the requestAnimationFrame or setTimout method. (Edit: actually you have to schedule frames yourself via these methods as bd's comment point out). There's no other way to flush the Canvas' drawing buffer than ending the currently running function and giving control back to the browser. If you'd implement a busy wait in JavaScript, the screen would never update and the browser will kill the script after a few seconds.
three.js knows nothing about the animation that is running and thus just attempts to draw at 60fps - whether or not there's anything new to show. You could pause the animation if there's no user inupt (and the animation wouldn't update on its own), but that's your obligation.
"While a "spiral" and a "helix" are distinct as technical terms, a helix is sometimes described as a spiral in non-technical usage." - http://en.wikipedia.org/wiki/Spiral
They are different, but people who don't know the difference often call hexixes spirals, as is the case with spiral staircases.
I'm fairly certain that the non-technical sense by far predates the more narrow technical definition. It's all about context, and there was nothing here that would make helix more correct than spiral.
