Blog Surfer

HTML 5 Spec Released, Warts and All
The W3C released the first draft of the HTML5 spec yesterday — warts and all. As far as technical specifications go, it’s pretty interesting reading. A large part of what is interesting is what is new in everybody’s favourite markup language: header, nav, article, dialog, section, aside, and footer elements The canvas element (shameless plug: there’s an awesome […]

The W3C released the first draft of the HTML5 spec yesterday — warts and all. As far as technical specifications go, it’s pretty interesting reading.

A large part of what is interesting is what is new in everybody’s favourite markup language:

• header, nav, article, dialog, section, aside, and footer elements
• The canvas element (shameless plug: there’s an awesome chapter about it in our latest book)
• Inclusion of the video and audio elements
• Support for persistent client-side data storage
• Support for users to edit documents and parts of documents interactively
• RSS feeds as part of the page’s markup

It’s just as interesting noting what’s missing:

• frame and frameset (hooray!)
• font (cheer!)
• applet, among others

Rumour has it that one faction of the HTML working group were lobbying hard to have the meta tag removed in order to prevent Microsoft from hijacking it, but they were clearly unsuccessful.

Check out the list of differences between HTML4 and HTML5 if you find the thought of tackling the entire spec a little daunting.

For me, what really makes the spec an entertaining read, however, is the fact that so many of the review comments for areas that are still problematic, are still in place. There is obviously still a fair amount of work ahead, though, if the following is anything to go by:

This article provided by sitepoint.com.

In the Lab: Doing strange things to CSS Backgrounds
So, last year you might remember me running through some experiments with using percentages to position your background-image in CSS. The short version: Percentages are slightly counter-intuitive but quite powerful — if it wasn’t for IE6-7 sucking by always minutely miscalculating them. In the original post we stuck mostly to the more predictable and commonly-used percentages […]

So, last year you might remember me running through some experiments with using percentages to position your background-image in CSS. The short version: Percentages are slightly counter-intuitive but quite powerful — if it wasn’t for IE6-7 sucking by always minutely miscalculating them.

In the original post we stuck mostly to the more predictable and commonly-used percentages — from 0-100%. Today I thought we might look at some of the interesting things that happen if start to crank those numbers.

Now to be clear, this is mostly ‘theoretical CSS’ in a Stu Nicholls kind of way and probably isn’t stuff you’ll be finding a use for every day. Hopefully it will, at least, be handy for helping you to get a good grip on the subtleties of how percentages interact with images. With luck it might even come in handy at some point in the future.

Let’s look at a starting example, taking a background-image positioned 150% 0%. The zero is a no-brainer, and will obviously place the graphic on the top edge of the box.

For the horizontal position the browser will first locate a spot 50% to the right side of your DIV. It will then find a spot 50% to the right hand side of your image, and align those two points. This will actually have the effect of moving your image back towards (relative to the original point you located).

This means that if the image is small, that offset will also be small and the image will remain mostly, if not entirely hidden beyond the right edge of your DIV.

If the image and DIV are the same size, these offsets will cancel each other out, and the image will be positioned in the horizontal center of it’s DIV.

Howver, if the image is larger than it’s containing DIV, this offset will actually start to move to the LEFT of the containing DIV. Weird but it makes sense if you think about it.

Negative percentages work the same way, only to the left of screen.

However it’s when you set your background to tile horizontally that really interesting things start to happen (background-repeat: repeat-x;). While the tiling effect will ensure your image will always be visible, setting large percentages means even a small resize of your browser will translate into a massive repositioning your background graphic. For instance, if your background-position is set to -500%, a 50px increase in your browser will slide your background-image 250px to the left.

Rather than explaining this, it’s easiest to just to demonstrate it via this little example I’ve cobbled together for the The Art and Science of JavaScript book launch.

Start your browser smallish, grab a corner and as you begin to resize the application up and down, you should see an animated ‘diorama’ effect happening around the limo. Each of the ’stage layers’ (i.e. the cityscape, background crowd and foreground crowd) is given a larger negative percentage than the one before it (-100%, -250% and -550% respectively).

The limo is given a positive percentage of 150%, which drives it in and out of the right hand stage as you resize.

Kinda mesmerizing in a Mario Brothers kind of way, isn’t it?

So are ‘resize animations’ the future of the web?

Clearly not, but it does offer a few practical possibilities. I could imagine some nice ideas with site headers where a number of partially-transparent layers were overlayed and positioned with large percentages. Resizing the browser would change the way these layers interacted, perhaps making the header appear radically different at various browser resolutions. As an analog, think of the large changes a small twist can create in a kaleidoscope.

James has also speculated about employing the trick in JavaScript animations.

Even if nothing particularly practical ever comes of it, it was a lot of fun to fiddle with and I think I’ve got a rock solid grasp on how percentages work now. Hopefully it clears things up for a few others too.

*Note: Linux doesn’t re-render the browser when resizing until you release the window edge, so you can’t see this animating effect on a Linux box.

**Note: Apparently most Linux distros show the animation fine. Must be a setting in my Gnome setup.

This article provided by sitepoint.com.