One of the things I always want to do with online maps is rotate them – I am used to that with real, physical maps. As physical maps become a lot more clever these days (for example have you seen the zoomable map?) it is time we can do this with the online ones, too.
Whilst Google supports this in the satellite and hybrid maps, the basic ones still can’t be turned. Which is why I took CSS3 transformations (wrapped in a very useful jQuery plugin) and voila – rotating is possible:
We have been long term fans of Román and the fantastic demos and samples that he puts together, usually involving CSS goodness. We messed up the other week though when we linked to his work on a scrolling coke can. I do these postings as a labor of love, and since Ajaxian isn’t my day job, that means that the labor often happens at 2am. In this case I made the rookie mistake of grabbing an iframe to his demo so it would run inline. Román then looked up to see his servers getting pummeled and a bill is associated with that traffic. He quickly rick rolled us (thank you for not going for something much worse ;) and Christian Heilman (who is in Europe along with Román) saw it and kindly switched in an image of the code can effect.
I woke up the next morning to learn about this all and see a post that Román did talking about our hot linking. I immediately responded saying how sorry I am. I aim to highlight the great work that is done, not cause an issue.
Román is a great guy and kindly offered to collaborate and show friendship with Ajaxian (and myself) by putting together more amazing demos to share on the blog. Inline. Not hot-linking. :)
Here they are
These effects are CSS level 1 and 2.1 only. There is no javascript, css3 or whatever, just html and css.
They are all based on the CSS 2D displacement map technique that Román Cortés discovered when he created the infamous CSS Coke Can effect. Since displacement maps are very versatile, Román Cortés wanted to show us more and different applications of these.
This is simple displacement map usage to distort the borders of the prism, with a transparent .png image on top to add the shadows, orange semi-transparent bg and the Ajaxian’s “a” logo. The background painting is an original artwork by Román Cortés. Move the area around to see the effect the prism has on the underlying painting.
There some comments in the original code can posting that the spinning direction was unnatural. So, here he did spin as the commenters wanted it. To make it possible, he had to mirror the label texture and adapt the source code.
By using several cylindrical displacement map layers with a growing radius and png transparent textures, it is possible to do voxel surface rotations like this one.
Thanks for Román for being so reasonable, and for creating such fun examples for us all. We hope to go deeper on the implementation of some of these examples in the future.
Román Cortés is having a lot of fun with CSS tricks these days. He just built an example rolling CSS coke can that uses background-attachment, background-position, and a few other tricks to get the effect. No fancy CSS3 needed here!
Geuis Teses has released an enjoyable library called Helium that has the goal of testing your stylesheets for unused style.
You inject helium into your site (e.g. put it in an included footer) and then when you hit the first page you will have a popup asking for the pages you want to test. Helium will find the style sheets that you use and will store that information and the page information inside of localStorage. Then it will XHR around (so your styles need to be on the same host), test each page, and finally give you results.
I put up a trivial example to give it a ride and ended up with:
I ran into a minor issue with regards to relative stylesheets so I did the Github thing and forked, fixed, and pull requested. I love Github :)
I am right now working on a high-traffic project that will run in a sandbox that doesn't allow me to pull third party JavaScript or use canvas/Flash. Yet I need to generate bar charts from a set of data.
The solution to me was to create the charts from HTML using CSS. There have been some solutionsforthisproblemalready but I wanted something very simple and easy to maintain. Hence all the markup I am using is this:
Instead of hard-coding any of the trickery necessary I wrote a PHP script to generate the HTML, the styles and do all the math. So all that is needed to render one of the charts is the following code:
When I talked about some snow related CSS3 experiment, I could not imagine @Natbat was already preparing something like snowflakes, an almost fully CSS3 featured snow FX created for clearleft, specially suited for Chrome and Safari.
And what about @zacharyjohnson? He put snow all over the network via its Winternetizer, the first snow proxy I have ever seen.
Am I missing anybody? ... sure, me!
Above FX is dedicated to all Ajaxian readers and created via some CSS3 rule handled via JavaScript for a partial cross browser implementation. WebKit based browsers, included Android and iPhone, plus Firefox 3.6, should render properly, while the most interesting thing, snow a part, is that for the first time rather than browser sniffing, I have implemented a sort of "screen resolution to power computation" sniff:
Probably not perfect, the aim is to avoid same number of flakes in mobile devices, netbooks, or desktop PCs.
I guess one day we'll have exposed CPU model and RAM amount as read only userAgent properties, so that all new effects could avoid stress for web surfers.
Something like System namespace in ActionScript, with capabilities for audio and video and extra info about the current navigator ... maybe just an AS to JS bridge 'till that day? We'll see, today the important thing is simply one: Have Fun!
There are a lot of CSS transitions experiments going on right now. Yesterday I discovered another HTML and CSS experiment which went "far far away", compared with my simple CSS gallery.
Guillermo Esteves presented a piece of history translated for tomorrows browsers: the Star Wars Episode IV opening crawl in HTML and CSS:
Unfortunately, the live experiment is not suitable for all browsers and the ideal target seems to be only OSX 10.6 and its latest Safari browser but it partially worked via Google Chrome as well.
Something To Learn About
We are moving complex computations into our favorite "decoration layer": CSS
We also want as much control as possible, and the above concept is brilliant to understand how to tame CSS transitions.
This example includes new and different techniques. Here is what I found interesting:
@font-face
OK, this is not new at all, but in this case I could not find a single valid reason to avoid the original font: a must! The only point here is that the author could have saved a bit of bandwidth via pre-deflated or gzipped fonts rather than serving them without any apparent optimization.
The stage is the block element where the magic happens. The perspective property is able to give us a "deep space" 3D feeling making closer objects look larger than further ones. Via origin modification we can decide where things should disappear, in this case a bit higher point than a central 400px, to create a similar atmosphere respecting the movie choice (and I guess to make content readable as well).
Far far away is the initial text. As we can see with other browsers as well this appears and disappear in 6 seconds.
This fade-in-out happens just once, so at the end of the effect, unless we won't modify the node class, the element won't be displayed anymore. This is what the animation-iteration-count property does while next snippet is the fade-in-out customization:
Via keyframes <transition_name> we can blend FX linearity deciding the amount of opacity, or other properties, at certain moments.
A generic normal linear fade-in-out would be visible 100% only in the middle of the transition while in this case it is forced to be visible for 68% of the time, making fade in and out still homogeneous but controlling the full opacity for longer.
We could have used an ease-in-out effect over opacity property to obtain a similar result but I find definitively more interesting this kind of approach.
Warp Speed: Action!
Thanks to Z axis transitions the initial STAR WARS image can appear and disappear using again a customized FX:
Above mix of webkit properties suggests me that new JavaScript libraries will use run-time actions to CSS transformations soon, rather than hard and manual JS computations over computed styles or similar expensive operations.
We can control delays, we can stop FXs removing classes or simply overwriting existent directives and, moreover, we can split the CSS itself into logical parts as the same @gesteves did, putting custom animations all together: good hint!
The Crawl
Last piece to check out is the text plus its title.
If we have a good broadband connection and we are sure in 12 seconds we have buffered enough audio, the synchronization between JavaScript and the transition delay is almost perfect and the demo experience unique.
It is great to see this work, and I look forward to seeing what he comes up with next. It feels that with HTML5, CSS3, and the Web.Next we will be able to be much more creative. Finally, it's December, I can already imagine a CSS3 based snow effect for our pages ... no?
Tutorialzine is a nice blog but I think sometimes it should should re-dimension chosen titles.
I have discovered only yesterday and thanks to my good old favorite Web related italian blog, a nice (or if you prefer another) jQuery lightbox style experiment.
The post is complete with examples and explanation over PHP, CSS, jQuery, and finally jQuery UI.
So what is the problem? The title: An Awesome CSS3 Lightbox Gallery With jQuery
At the end of the day, the total size of the demo is massive, compared with what it offers, plus the only piece of CSS3 in the stylesheet is a box-shadow and a rotation via -webkit-transform.
Is That It?
If we can define awesome a basic usage of CSS3 requiring both jQuery and jQuery UI to create a Gallery, included a server side language, how can we define my latest experiment realized in half an hour and without using JavaScript, PHP, or whatever programming language at all?
The answer is simple: CSS3 and we can read how I did it via the not-minified and hopefully well commented css file.
OK, agreed my page is dynamically fake and a proof of concept, but honestly, which title would consider appropriate for above example?
Thanks in any case to Tutorialzine for the interesting step by step explanation and to let me try above experiment which works with latest WebKit, Chrome, Safari, and somehow with Firefox, I've not tried the nightly, and Opera as well but in latter cases without transitions.
P.S. for those with poor computation performances like me, here there is a fluid concept variation ;-)
It does not matter if we have the latest CPU able to devour every single bit of a web page, round trip and network delay is still the real bottleneck of whatever website and Steve Souder knows it so well that he summarize best practices in 66 slides.
Steve slides are mainly focused on JavaScript techniques able to download simultaneous files without blocking download first, and layout render after. He is generally right about his assumptions, but as is for everything, there are cases and cases. Please let me share here my thoughts about performances, not necessary too hard if we perfectly know what we are doing, but somehow hard to make it that perfect as well!
Image Sprites Rule
A common technique to avoid unnecessary requests to the server is the usage of image sprites. This means that rather than 16 images, as example, we could have a single 4x4 grid with all required images positioned when necessary via CSS and better compressed. Nothing new? Well, a common side effect of this technique is that if the current page will use only 4 out of 16 images, the total download size will be bigger than required one and the total amount of milliseconds to have a fully rendered layout will be, again, bigger!
Beside, if the image will be cached it won't be downloaded for every other page where other cells in the sprite are necessary. As summary, sprites have pros and cons, if we put every image present in the CSS inside a single sprite but the user is interested only into one page, we are probably wasting bandwidth, and the initial feeling will be a slow website. The good compromise is obtained grouping related images inside a single sprite, being sure that if one is required, the rest of the UI will use at least 2/3 of other images in the same sprite.
JavaScript And Sprites Rule
Even if precedent point could sound obvious, we generally act in the opposite way with JavaScript. Not every library has been created to load incrementally and jQuery, as example, is one of these libraries. Even if we use just Sizzle and few core methods, we usually include the full library.
OK, jQuery is lightweight by default, and I have used it as example for its popularity, but it is a good example to explain that JavaScript is usually served as just one file with everything inside, but this is not the best we can do ... remember sprites rule? Only if we use at least 2/3 of the library in that page it makes sense to include the entire library ...
Other libraries such MooTools, YUI, or dojo allow us to choose the exact package we need for our purpose or, even better, these libraries are able to load dependencies incrementally and run-time ... is this always a better technique?
Well, from parallel download point of view it is, but for overall responsiveness it may be not the right way.
Try to imagine a page with 6 files/namespaces dependencies, if these 6 files would have been served in a single one, minified and gzipped, a single request with a better/shared compressed dictionary would have been better than 6 different files. Still Sprites Rule: for few more milliseconds but a single request and a better compression ratio, the overall responsiveness of the page will be improved, thanks to every included dependency, rather than split files and lazy requests.
In other words, if without those files the page is not usable, the user will have a bad or "slow" experience, compared with the page that uses those files loading them in a shot.
The ideal scenario would be a non-blocking lightweight loader on the top able to call grouped or optimized piece of a library and execute code only at the end, something like this:
Above is just a 420 bytes (265 deflated) example function but fortunately every library able to load incrementally will have a better and more powerful one. Is the suggestion/idea clear?
JavaScript And Evaluated Comments
On slide 16 we can learn about the last amazing technique which aim is to speed up the whole parsing and executing process. I am talking about JavaScript in comments, totally ignored, unless conditionals, from every JavaScript engine, not parsed at all and for this reason faster to include as part of the code. but for some reason faster to evaluate. To be honest, I have not studied internals yet and to me is quite obscure the reason a function call, as eval is, should be that faster than native included code, since the parser will pass the code in any case and the latter one needs to be executed. The only guess I have is that eval misses something compared to native parsing, but I don't know what ... Sure is that via Firefox and enabled Firebug or analogue debuggers, eval will be slower, due to overload caused by the debugger itself, so may I suggest Function(strippedComment)() instead?
Global scope as a native included code will have, and less stress for debuggers!
OK, I went to far with Function suggestion, and my point over this comments technique is that being necessary to retrieve the comment content, as part of the text contained in the script, we cannot gzip/deflate the code unless the entire page has been compressed.
Being the network round trip one of the most costly operations for a mobile device, I don't think this is a universally valid technique for desktop browsers. Parallel downloads are almost a joke for today mobile phones, but hopefully a reality for common ADSL or fiber optic connections.
As best option for both scenarios I think the evaluated code in a string one is more than reasonable since it can be easily included as external file and it can be handled via namespaces.
Well, the whole point is about network round trip, isn't it? At least we know that if we have a dynamic layout but a static script, hopefully based on ETag and caching solutions, above suggestion will make sense as valid alternative.
CSS And Sprites Rule
Following for the last time the Stripes logic, CSS are rarely loaded incrementally. One call? Same style sheet for the whole website? Well, it could be a valid reason to serve a single file but at least we should remove noise from our CSS. How? It is simple, split the CSS for targeted browsers.
In the recent Confessions of a style sheet hacker, Jason Garrison justifies the usage of hacks for a single browser: Internet Explorer 6.
How many hacks are necessary to let this browser behave like every other? Unless our layout is not truly simple, lots of them! If we put "noise" inside a CSS specific for every browser but IE6, every browser will load unnecessary styles, slowing down the parser with messed selectors, and adding bytes, improving used bandwidth and download time as well.
Jason already replied and I would like to thanks him, but I still think an extra call for a single case is more worth it than overall noise for everyone.
My Performances Contribution
What a good occasion to introduce my latest project which aim is to improve performances for every static client file to serve? PHP Client Booster aim is to use some good practice to improve 2 times or more client file serving. A common mistake with PHP website is the one to use
even for static libaries, CSS, recently suggested to serve @font-face compatible fonts ... but this could be a complete waste of resources over performances reductions, rather than improvements, specially if produced generic output could have been pre-compressed.
Compatible with every static file, serving a 304 as soon as possible, including only necessary code, and compatible with load balanced environments as well thanks to a shareable ETag management, PHP Client Builder is a cross-platform tool able to pre-compress resources, serving as default file type a deflated version, optionally a gzipped one, and finally the raw version of the original file.
The reason I have chose deflate as default file serving is that it does not overload the compressed file with initial extra bytes and it may be slightly faster with inflate against gunzip.
Moreover, some old browser had problems with gzip and its extra bytes but it should not have problems with deflate. The tool, which needs lot of documentation I am planning to write, should not be obtrusive, it could be customized or added in our already present Framework/environment, and it comes with a bench/ folder for a "try yourself" purpose. Comments, suggestions, or questions, will be appreciated (for the whole post as well).
This blog post summarizes Paul, Stoyan, and Zoltan’s findings plus some very important discoveries of my own.
Among these discoveries is:
* IE doesn’t render anything in the page until the font file is done downloading.
* In all major browsers, ...no files were blocked [by font downloads].
* Busy indicators... are triggered [differently in each] browser
Steve also found that IE and Chrome didn't time out in their attempts to download a font, meaning in the case of the former that the page never displays while waiting for the font, and in the latter that the text doesn't display.
Steve's conclusions are interesting:
* Only use @font-face is you’re absolutely certain you need it.
* If you have multiple font files, consider sharding them across multiple domains.
* Don’t include unused @font-face declarations - IE will download them whether they’re used or not.
* Gzip the font files and give them a future Expires header.
* Consider lazy loading the font files, at least in IE.
Many browsers have been experimenting with new custom CSS properties lately. Keeping track (and learning how to use them) can be a bit of a challenge.
Via WidgetPad comes a nifty CSS 3 Generator that helps you understand the new CSS 3 features in Webkit with an interactive tool that will build up and show how each new property affects an element. Here, for example, we see the results of applying rounded corners, box shadows, reflections, and a transform to an element:
The CSS 3 Generator works on any webkit based browser, including Safari, the iPhone, and Chrome.
Here's a challenge to the community: can you create an enhanced version of this that works with all the new CSS 3 and vendor-specific properties, including on IE and Firefox, hiding the options that don't work on specific browsers? That would turn this into a more general purpose educational and testing tool that would be very valuable. Even better if you open source it and we can host it on the Open Web Developer Network we've been kicking around. Drop me a line if you create such a thing :)
As a side note, I had never seen the WidgetPad website where this is hosted before this which looks quite interesting. From the site:
[WidgetPad is a] collaborative development environment for developers to develop fully-interactive, stand-alone, downloadable SmartPhone applications in HTML5, CSS3 and Javascript. You don't need to install any special development tools or learn any platform-specific API sets. WidgetPad offers everything you need -- project management, source code editing, debugging, collaboration, versioning and even distribution -- in your own browser!
To be honest, I instantly had a thought about this technique: wasn't the DOMContentLoaded event purpose the one to avoid people waiting a full page download before they're allowed to interact with it? ... never mind, we cannot do much in any case in front of images dedicated layouts.
Finds Background Images: SpriteMe makes it easy to examine the CSS background images used in the current page by listing all the background images and the elements that use them.
Groups Images into Sprites: The logic behind spriting is complex: Background images that repeat horizontally can’t be sprited with images that repeat vertically. Repeating images that are sprited together must be the same width or height, depending on whether they repeat-x or repeat-y, respectively. Background images that are shorter than their containing block should go at the top of a vertically-stacked sprite if their position is “bottom”, but they should go at the bottom if their position is “top”.
Generates the Sprite: Clicking “make sprite” combines the images into a sprite using the coolRunnings service from Jared Hirsch. No zipping, no uploading form - it just happens.
Recomputes CSS background-position: Now comes the math. In Figure 1, the background-position for the #Buy element was “0% 100%”. Most sprite generation tools provide background-positions assuming every element starts off being “0% 0%”. Looking at the Alexa U.S. top 10, only 12% (56/459) of the elements that use a background image have a “0% 0%” background-position. More automated help is needed.
SpriteMe, because it runs in the web page, is able to convert the old background-position (”0% 100%”) to the exact offsets needed to use the sprite
Injects the Sprite into the Current Page: As developers, we know it’s critical to optimize the edit-save-test cycle in whatever we’re doing. In the past, the edit-save-test cycle for spriting was painfully long: regenerating the sprite image, saving it back to the server’s “/images/” directory, editing and saving the CSS, clearing the cache, and reloading the page. SpriteMe bypasses all of that by modifying the live page as you watch.
This is awesome stuff, but does it make a difference?
Steve ran some data on the Alexa top 100 and found these savings:
Congrats on yet another awesome performance tool Steve! What tool are you going to share tomorrow? ;)
Barry van Oudtshoorn has written a CSS minifier that uses some of the same concepts that Ray talked about (ordering for best compression). Here is Barry:
I recently wrote a small CSS minifier in Java that optimizes your CSS output for gzipping. Essentially, it does most of what the YUI compressor does, but additionally, it ensures that property values are always ordered consistently. This means that the gzip algorithm can reduce the file size further.
In my testing, my CSS minifier's raw output is actually slightly larger than that of YUI, but when compressed, it is noticeably smaller, thanks to the gzip optimisations. As this is the an early release, however, I have plans for various optimizations to the raw output which will further reduce its size, which in turn will help to reduce the gzipped size of the file even further.
The code is released under the MPL, and is freely downloadable from my website, at the address linked to above.
