Star Wars opening crawl from 1977 in HTML/CSS/JS(codepen.io) |
Star Wars opening crawl from 1977 in HTML/CSS/JS(codepen.io) |
If anybody's interested why there's aliasing it's important to know how CSS transforms work. If you transform, the browser lifts the transformed rectangle into its own layer and renders its content to a texture. Then, later, it is composited with the page by blitting that texture with whatever transformation was applied.
So CSS transforms are an application of texturing. And in texturing what you do to avoid aliasing is mipmapping (you might also throw anisotropic filtering on top). However as the texture holding the rect the browser rendered isn't square power of two, some devices do not support mipmapping it. It is also quite slow to generate the mipmap for a texture every frame.
So with CSS transforms not being able to utilize mipmapping --> aliasing.
Now, in particular mipmapping text (that's supposed to be sharp) isn't even the best idea. It just gets blurry and looks unappealing (although that's better with anisotropic filtering, but then, anisotropic filtering is also expensive and not every device/GPU supports it).
Running on a retina MBP, both Safari and Chrome render the text pin-sharp with no noticeable aliasing.
Check the farthest text. It's even worse in motion because the aliasing changes discretely.
Thanks in advance.
If you'd be doing WebGL you can do some things like using square power of two textures and enabling mipmapping and if available anisotropic filtering.
You can also do things like using signed distance field fonts or draw fonts by rasterizing (in the fragment shader) the bezier curves, which can be made to nicely anti-alias (using standard derivatives).
Same for the logo. The scale transform should never exceed 1.0.
In any other context, you could safely pull off not preloading. But this example is just too ingrained into people's minds.
Do you know any better ways to preload it?
Logo appears and fades out then nothing but music and blackness.
The code's also on GitHub [2]. It uses HTML5, CSS3, and Box2dJS.
[1] https://github.com/scotch-io/Pure-CSS3-Star-Wars-Lightsaber-...
[2] https://github.com/scotch-io/Star-Wars-Attack-of-the-DOM
http://static03.mediaite.com/themarysue/uploads/2012/08/bts1...
Thanks for sharing!
PS: telnet towel.blinkenlights.nl
The scrolling itself is just a CSS "transform: perspective(300px) rotateX(25deg)".
You can also edit the scrolled text because I added the contenteditable="true" attribute to the titles.
One suggestion. Don't just create a standard for (monopoly) ECMA Script, instead - create a standard for a VM that other languages can compile bytecode to. Create an API in this VM for graphics, video, audio, ETC. This may be self defeating for these clowns, because JavaScript/CSS/HTML may be decimated in a decade if they actually did this, but hey... One can hope.
Once Google firmly owns the browser (like Microsoft in the 2000s) one of two things will happen. One they say to hell with the standards board and push real innovation and opportunity for developers to innovate. Two, they will sit and let it stagnate. Either way, the cycle is coming around again. Android will own the market in a big way soon. Big opportunity is on the horizon and I am getting my hopes up that there is a big shake up with "browser standards". End the monopoly of lame markup, styling, and scripting (HTML/CSS/JS) in the OS of the internet.
That's a weird opinion. The original was analog, created by several people and shoot carefully in specific conditions. This HTML version was made by a guy in his bedroom in a fraction of a time and is sharable, editable and can be viewed on many devices, including mobile, instead of just a movie theatre like the original. For me this is innovation across the board (not only in web standards, but technology overall)
Please no. That's the opposite of where we should be going. Less executable code on the client, more powerful markup.
JavaScript was a huge mistake that we will likely have to live with for decades, let's not compound it.
Well, since when it comes to layout, the union of everybody's desires appears to be simply Every Possible Thing, your more powerful markup is going to end up being executable code anyhow. If you specify a Turing-complete set of needs, you're going to need a Turing-complete language to satisfy them.
You can already see this happening even in CSS, and the more they try to pretend that CSS isn't code (even though it increasingly is), the more frustrating it's going to get for everyone when you end up with a bug in your CSS, which you are not allowed to fix due to the fact that we're all pretending it's not code.
That ship has well and truly sailed. Mozilla and Google both want to make the web into a general purpose app platform, and they have veto power over any proposed standards. Admittedly they both want a slightly different version of the idea (asm.js vs Dart or NaCl), but that gridlock just leaves us investing even more heavily into the current Javascript ecosystem.
How would that bytecode be any less of a "monopoly" than ECMA Script is now?
Web standards may be "far behind" in what they can do compared to native code, but their are far, far, far ahead in terms of giving some control back to the user, whether it's in terms of enabling browser extensions, letting content be viewed without running arbitrary code, doing presentation transformations (e.g. Readability), well defined semantics for sharing content (links), etc.
Your suggestion would grant some more power to developers, at the expense of users. So thanks, but no thanks.
There already is a standard VM with an API for graphics, video and audio - it's called HTML5, and, as a bonus, it also includes an API for text layout. Sure, if you sat down intending to design such a VM, you might not come up with HTML5, but so what; what concrete improvement would you get by distributing programs as bytecode rather than JavaScript?
That sounds a lot like Asm.js [1] Check Emscripten too! [2]
There's no flag to control aliasing migitating strategies for CSS in the spec, nor is there any discussion about it as far as I know.
So, ideally, browsers would be doing this themselves, after applying the transform to any non-text in the texture, and then compositing with the combined texture?
