Web Design, Development, Managment and Analysis

2014-01-27T03:29:00.002-08:00

Just click on this link and setup a free account for monthly pay out ...it's absolutely free... so don't wait.

http://getmonthlypay.com/index.php?invite=133361

Create an Image Rotator with Description (CSS/jQuery)

2012-02-14T02:03:00.000-08:00

Create an Image Rotator with Description (CSS/jQuery)

By Soh Tanaka | Published May 4th, 2009 in Tutorials

advertise here

5digg

An image rotator is one great way to display portfolio pieces, eCommerce product images, or even as an image gallery. Although there are many great plugins already, this tutorial will help you understand how the image rotator works and helps you create your own from scratch.

Creating an Image Rotator

View Demo of Image Rotator

Step1. HTML – Image Rotator Wireframe

Start by building the html wireframe of the layout. As you can see in the image below, there will be two major sections (the main image section and the thumbnail list section). In addition to the sections for images, the third section, labeled “desc”, will contain the main_image description.

main_image Section HTML




 


  Close Me!



Title
Date


Copy

image_thumb Section HTML
Note – The thumbnail list section will be very similar in markup as the main image section, but each will all be encapsulated in its own list item.




   



Title
Date


Copy

Step 2. CSS – Image Rotator Wireframe

Next, it’s time to style the image rotator’s HTML wireframe with CSS.
main_image section CSS

.main_image {

 width: 598px;

 height: 456px;

 float: left;

 background: #333;

 position: relative;

 overflow: hidden; /*--Overflow hidden allows the description to toggle/tuck away as it slides down--*/

 color: #fff;

}

.main_image h2 {

 font-size: 2em;

 font-weight: normal;

 margin: 0 0 5px;

 padding: 10px;

}

.main_image p {

 font-size: 1.2em;

 line-height: 1.6em;

 padding: 10px;

 margin: 0;

}

.block small { /*--We'll be using this same style on our thumbnail list--*/

 font-size: 1em;

 padding: 0 0 0 20px;

 background: url(icon_calendar.gif) no-repeat 0 center;

}

.main_image .block small {margin-left: 10px;}

.main_image .desc{

 position: absolute;

 bottom: 0;

 left: 0; /*--Stick the desc class to the bottom of our main image container--*/

 width: 100%;

 display: none; /*--Hide description by default, if js is enabled, we will show this--*/

}

.main_image .block{

 width: 100%;

 background: #111;

 border-top: 1px solid #000;

}

.main_image a.collapse { /*--This is our hide/show tab--*/

 background: url(btn_collapse.gif) no-repeat left top;

 height: 27px;

 width: 93px;

 text-indent: -99999px;

 position: absolute;

 top: -27px;

 right: 20px;

}

.main_image a.show {background-position: left bottom;}

image_thumb section CSS

.image_thumb {

 float: left;

 width: 299px;

 background: #f0f0f0;

 border-right: 1px solid #fff;

 border-top: 1px solid #ccc;

}

.image_thumb img {

 border: 1px solid #ccc;

 padding: 5px;

 background: #fff;

 float: left;

}

.image_thumb ul {

 margin: 0;

 padding: 0;

 list-style: none;

}

.image_thumb ul li{

 margin: 0;

 padding: 12px 10px;

 background: #f0f0f0 url(nav_a.gif) repeat-x;

 width: 279px;

 float: left;

 border-bottom: 1px solid #ccc;

 border-top: 1px solid #fff;

 border-right: 1px solid #ccc;

}

.image_thumb ul li.hover { /*--Hover State--*/

 background: #ddd;

 cursor: pointer;

}

.image_thumb ul li.active { /*--Active State--*/

 background: #fff;

 cursor: default;

}

html .image_thumb ul li h2 {

 font-size: 1.5em;

 margin: 5px 0;

 padding: 0;

}

.image_thumb ul li .block {

 float: left;

 margin-left: 10px;

 padding: 0;

 width: 170px;

}

.image_thumb ul li p{display: none;}/*--Hide the description on the list items--*/

Step3. jQuery – Image Rotation Effect

If you are new to jQuery or have not had much experience with it, first go over the basics.
Show Image Description and Set Transparency on Block
To degrade gracefully, the image banner description is set to be hidden at default with CSS (refer to the “.main_image .desc” class in the CSS). We will show the image description if JavaScript is enabled.



$(".main_image .desc").show(); //Show Banner

$(".main_image .block").animate({ opacity: 0.85 }, 1 ); //Set Opacity

Click and Hover Events for Image List
The following script will change the main_image when a list-item in the image_thumb is clicked. Each line also contains a comment explaining which jQuery actions are being performed.

$(".image_thumb ul li:first").addClass('active'); //Add the active class (highlights the very first list item by default)

$(".image_thumb ul li").click(function(){

 //Set Variables

 var imgAlt = $(this).find('img').attr("alt"); //Get Alt Tag of Image

 var imgTitle = $(this).find('a').attr("href"); //Get Main Image URL

 var imgDesc = $(this).find('.block').html();  //Get HTML of the "block" container

 var imgDescHeight = $(".main_image").find('.block').height(); //Find the height of the "block"


 if ($(this).is(".active")) {  //If the list item is active/selected, then...

  return false; // Don't click through - Prevents repetitive animations on active/selected list-item

 } else { //If not active then...

  //Animate the Description

  $(".main_image .block").animate({ opacity: 0, marginBottom: 
-imgDescHeight }, 250 , function() { //Pull the block down (negative 
bottom margin of its own height)

   $(".main_image .block").html(imgDesc).animate({ opacity: 0.85, 
marginBottom: "0" }, 250 ); //swap the html of the block, then pull the 
block container back up and set opacity

   $(".main_image img").attr({ src: imgTitle , alt: imgAlt}); //Switch the main image (URL + alt tag)

  });

 }

 //Show active list-item

 $(".image_thumb ul li").removeClass('active'); //Remove class of 'active' on all list-items

 $(this).addClass('active');  //Add class of 'active' on the selected list

 return false;

}) .hover(function(){ //Hover effects on list-item

 $(this).addClass('hover'); //Add class "hover" on hover

 }, function() {

 $(this).removeClass('hover'); //Remove class "hover" on hover out

});

Toggle the Hide/Show Option
This is fairly simple. On each click, either show or hide the description.



$("a.collapse").click(function(){

 $(".main_banner .block").slideToggle(); //Toggle the description (slide up and down)

 $("a.collapse").toggleClass("show"); //Toggle the class name of "show" (the hide/show tab)

});

View Demo of Image Rotator

Conclusion

Do keep in mind these jQuery driven image rotators do not degrade in the best fashion. As you can see, when you disable JavaScript, each thumbnail must be clicked on to get the larger image (which opens in the same window). But for those who have a user base with JavaScript enabled, you are in the clear and it can be used and customized to fit various scenarios.
Experiment and customize this to fit your needs. If you have any questions, concerns, suggestions, or comments, please do not hesitate to let me know.
Awesome cloud hosting for designers and their files and apps.
Credits: Much appreciation to Glenn Jones for allowing me to use his beautiful illustrations for the example images.

An Introduction to CSS 3-D Transforms

2012-02-12T04:02:00.000-08:00

Ladies and gentlemen, it is the second decade of the third millennium and we are still kicking around the same 2-D interface we got three decades ago. Sure, Apple debuted a few apps for OSX 10.7 that have a couple more 3-D flourishes, and Microsoft has had that Flip 3D for a while. But c’mon – 2011 is right around the corner. That’s Twenty Eleven, folks. Where is our 3-D virtual reality? By now, we should be zipping around the Metaverse on super-sonic motorbikes.
Granted, the capability of rendering complex 3-D environments has been present for years. On the web, there are already several solutions: Flash; three.js in <canvas>; and, eventually, WebGL. Finally, we meagre front-end developers have our own three-dimensional jewel: CSS 3-D transforms!

Rationale

Like a beautiful jewel, 3-D transforms can be dazzling, a true spectacle to behold. But before we start tacking 3-D diamonds and rubies to our compositions like Liberace‘s tailor, we owe it to our users to ask how they can benefit from this awesome feature.
An entire application should not take advantage of 3-D transforms. CSS was built to style documents, not generate explorable environments. I fail to find a benefit to completing a web form that can be accessed by swivelling my viewport to the Sign-Up Room (although there have been proposals to make the web just that). Nevertheless, there are plenty of opportunities to use 3-D transforms in between interactions with the interface, via transitions.
Take, for instance, the Weather App on the iPhone. The application uses two views: a details view; and an options view. Switching between these two views is done with a 3-D flip transition. This informs the user that the interface has two – and only two – views, as they can exist only on either side of the same plane.

Flipping from details view to options view via a 3-D transition

Also, consider slide shows. When you’re looking at the last slide, what cues tip you off that advancing will restart the cycle at the first slide? A better paradigm might be achieved with a 3-D transform, placing the slides side-by-side in a circle (carousel) in three-dimensional space; in that arrangement, the last slide obviously comes before the first.
3-D transforms are more than just eye candy. We can also use them to solve dilemmas and make our applications more intuitive.

Current support

The CSS 3D Transforms module has been out in the wild for over a year now. Currently, only Safari supports the specification – which includes Safari on Mac OS X and Mobile Safari on iOS.
The support roadmap for other browsers varies. The Mozilla team has taken some initial steps towards implementing the module. Mike Taylor tells me that the Opera team is keeping a close eye on CSS transforms, and is waiting until the specification is fleshed out. And our best friend Internet Explorer still needs to catch up to 2-D transforms before we can talk about the 3-D variety.
To make matters more perplexing, Safari’s WebKit cousin Chrome currently accepts 3-D transform declarations, but renders them in 2-D space. Chrome team member Paul Irish, says that 3-D transforms are on the horizon, perhaps in one of the next 8.0 releases.
This all adds up to a bit of a challenge for those of us excited by 3-D transforms. I’ll give it to you straight: missing the dimension of depth can make degradation a bit ungraceful. Unless the transform is relatively simple and holds up in non-3D-supporting browsers, you’ll most likely have to design another solution. But what’s another hurdle in a steeplechase? We web folk have had our mettle tested for years. We’re prepared to devise multiple solutions.
Here’s the part of the article where I mention Modernizr, and you brush over it because you’ve read this part of an article hundreds of times before. But seriously, it’s the best way to test for CSS 3-D transform support. Use it.
Even with these difficulties mounting up, trying out 3-D transforms today is the right move. The CSS 3-D transforms module was developed by the same team at Apple that produced the CSS 2D Transforms and Animation modules. Both specifications have since been adopted by Mozilla and Opera. Transforming in three-dimensions now will guarantee you’ll be ahead of the game when the other browsers catch up.
The choice is yours. You can make excuses and pooh-pooh 3-D transforms because they’re too hard and only snobby Apple fans will see them today. Or, with a tip of the fedora to Mr Andy Clarke, you can get hard-boiled and start designing with the best features out there right this instant.
So, I bid you, in the words of the eternal Optimus Prime…

Transform and roll out.

Let’s get coding.

Perspective

To activate 3-D space, an element needs perspective. This can be applied in two ways: using the transform property, with the perspective as a functional notation:

-webkit-transform: perspective(600);

or using the perspective property:

-webkit-perspective: 600;

See example: Perspective 1.

The red element on the left uses transform: perspective() functional notation; the blue element on the right uses the perspective property

These two formats both trigger a 3-D space, but there is a difference. The first, functional notation is convenient for directly applying a 3-D transform on a single element (in the previous example, I use it in conjunction with a rotateY transform). But when used on multiple elements, the transformed elements don’t line up as expected. If you use the same transform across elements with different positions, each element will have its own vanishing point. To remedy this, use the perspective property on a parent element, so each child shares the same 3-D space.
See Example: Perspective 2.

Each red box on the left has its own vanishing point within the parent container; the blue boxes on the right share the vanishing point of the parent container

The value of perspective determines the intensity of the 3-D effect. Think of it as a distance from the viewer to the object. The greater the value, the further the distance, so the less intense the visual effect. perspective: 2000; yields a subtle 3-D effect, as if we were viewing an object from far away. perspective: 100; produces a tremendous 3-D effect, like a tiny insect viewing a massive object.
By default, the vanishing point for a 3-D space is positioned at its centre. You can change the position of the vanishing point with perspective-origin property.

-webkit-perspective-origin: 25% 75%;

See Example: Perspective 3.

3-D transform functions

As a web designer, you’re probably well acquainted with working in two dimensions, X and Y, positioning items horizontally and vertically. With a 3-D space initialised with perspective, we can now transform elements in all three glorious spatial dimensions, including the third Z dimension, depth.
3-D transforms use the same transform property used for 2-D transforms. If you’re familiar with 2-D transforms, you’ll find the basic 3D transform functions fairly similar.

rotateX(angle)
rotateY(angle)
rotateZ(angle)
translateZ(tz)
scaleZ(sz)

Whereas translateX() positions an element along the horizontal X-axis, translateZ() positions it along the Z-axis, which runs front to back in 3-D space. Positive values position the element closer to the viewer, negative values further away.
The rotate functions rotate the element around the corresponding axis. This is somewhat counter-intuitive at first, as you might imagine that rotateX will spin an object left to right. Instead, using rotateX(45deg) rotates an element around the horizontal X-axis, so the top of the element angles back and away, and the bottom gets closer to the viewer.
See Example: Transforms 1.

3-D rotate() and translate() functions around each axis

There are also several shorthand transform functions that require values for all three dimensions:

translate3d(tx,ty,tz)
scale3d(sx,sy,sz)
rotate3d(rx,ry,rz,angle)

Pro-tip: These foo3d() transform functions also have the benefit of triggering hardware acceleration in Safari. Dean Jackson, CSS 3-D transform spec author and main WebKit dude, writes (to Thomas Fuchs):

In essence, any transform that has a 3D operation as one of its functions will trigger hardware compositing, even when the actual transform is 2D, or not doing anything at all (such as translate3d(0,0,0)). Note this is just current behaviour, and could change in the future (which is why we don’t document or encourage it). But it is very helpful in some situations and can significantly improve redraw performance.

For the sake of simplicity, my demos will use the basic transform functions, but if you’re writing production-ready CSS for iOS or Safari-only, make sure to use the foo3d() functions to get the best rendering performance.

Card flip

We now have all the tools to start making 3-D objects. Let’s get started with something simple: flipping a card.
Here’s the basic markup we’ll need:

<section class="container">
  <div id="card">
    <figure class="front">1</figure>
    <figure class="back">2</figure>
  </div>
</section>

The .container will house the 3-D space. The #card acts as a wrapper for the 3-D object. Each face of the card has a separate element: .front; and .back. Even for such a simple object, I recommend using this same pattern for any 3-D transform. Keeping the 3-D space element and the object element(s) separate establishes a pattern that is simple to understand and easier to style.
We’re ready for some 3-D stylin’. First, apply the necessary perspective to the parent 3-D space, along with any size or positioning styles.

.container { 
  width: 200px;
  height: 260px;
  position: relative;
  -webkit-perspective: 800;
}

Now the #card element can be transformed in its parent’s 3-D space. We’re combining absolute and relative positioning so the 3-D object is removed from the flow of the document. We’ll also add width: 100%; and height: 100%;. This ensures the object’s transform-origin will occur in the centre of .container. More on transform-origin later.
Let’s add a CSS3 transition so users can see the transform take effect.

#card {
  width: 100%;
  height: 100%;
  position: absolute;
  -webkit-transform-style: preserve-3d;
  -webkit-transition: -webkit-transform 1s;
}

The .container’s perspective only applies to direct descendant children, in this case #card. In order for subsequent children to inherit a parent’s perspective, and live in the same 3-D space, the parent can pass along its perspective with transform-style: preserve-3d. Without 3-D transform-style, the faces of the card would be flattened with its parents and the back face’s rotation would be nullified.
To position the faces in 3-D space, we’ll need to reset their positions in 2-D with position: absolute. In order to hide the reverse sides of the faces when they are faced away from the viewer, we use backface-visibility: hidden.

#card figure {
  display: block;
  position: absolute;
  width: 100%;
  height: 100%;
  -webkit-backface-visibility: hidden;
}

To flip the .back face, we add a basic 3-D transform of rotateY(180deg).

#card .front {
  background: red;
}
#card .back {
  background: blue;
  -webkit-transform: rotateY(180deg);
}

With the faces in place, the #card requires a corresponding style for when it is flipped.

#card.flipped {
  -webkit-transform: rotateY(180deg);
}

Now we have a working 3-D object. To flip the card, we can toggle the flipped class. When .flipped, the #card will rotate 180 degrees, thus exposing the .back face.
See Example: Card 1.

Flipping a card in three dimensions

Slide-flip

Take another look at the Weather App 3-D transition. You’ll notice that it’s not quite the same effect as our previous demo. If you follow the right edge of the card, you’ll find that its corners stay within the container. Instead of pivoting from the horizontal centre, it pivots on that right edge. But the transition is not just a rotation – the edge moves horizontally from right to left. We can reproduce this transition just by modifying a couple of lines of CSS from our original card flip demo.
The pivot point for the rotation occurs at the right side of the card. By default, the transform-origin of an element is at its horizontal and vertical centre (50% 50% or center center). Let’s change it to the right side:

#card { -webkit-transform-origin: right center; }

That flip now needs some horizontal movement with translateX. We’ll set the rotation to -180deg so it flips right side out.

#card.flipped {
  -webkit-transform: translateX(-100%) rotateY(-180deg);
}

See Example: Card 2.

Creating a slide-flip from the right edge of the card

Cube

Creating 3-D card objects is a good way to get started with 3-D transforms. But once you’ve mastered them, you’ll be hungry to push it further and create some true 3-D objects: prisms. We’ll start out by making a cube.
The markup for the cube is similar to the card. This time, however, we need six child elements for all six faces of the cube:

<section class="container">
  <div id="cube">
    <figure class="front">1</figure>
    <figure class="back">2</figure>
    <figure class="right">3</figure>
    <figure class="left">4</figure>
    <figure class="top">5</figure>
    <figure class="bottom">6</figure>
  </div>
</section>

Basic position and size styles set the six faces on top of one another in the container.

.container {
  width: 200px;
  height: 200px;
  position: relative;
  -webkit-perspective: 1000;
}
#cube {
  width: 100%;
  height: 100%;
  position: absolute;
  -webkit-transform-style: preserve-3d;
}
#cube figure {
  width: 196px;
  height: 196px;
  display: block;
  position: absolute;
  border: 2px solid black;
}

With the card, we only had to rotate its back face. The cube, however, requires that five of the six faces to be rotated. Faces 1 and 2 will be the front and back. Faces 3 and 4 will be the sides. Faces 5 and 6 will be the top and bottom.

#cube .front { -webkit-transform: rotateY(0deg); }
#cube .back { -webkit-transform: rotateX(180deg); }
#cube .right { -webkit-transform: rotateY(90deg); }
#cube .left { -webkit-transform: rotateY(-90deg); }
#cube .top { -webkit-transform: rotateX(90deg); }
#cube .bottom { -webkit-transform: rotateX(-90deg); }

We could remove the first #cube .front style declaration, as this transform has no effect, but let’s leave it in to keep our code consistent.
Now each face is rotated, and only the front face is visible. The four side faces are all perpendicular to the viewer, so they appear invisible. To push them out to their appropriate sides, they need to be translated out from the centre of their positions. Each side of the cube is 200 pixels wide. From the cube’s centre they’ll need to be translated out half that distance, 100px.

#cube .front { -webkit-transform: rotateY(0deg) translateZ(100px); }
#cube .back { -webkit-transform: rotateX(180deg) translateZ(100px); }
#cube .right { -webkit-transform: rotateY(90deg) translateZ(100px); }
#cube .left { -webkit-transform: rotateY(-90deg) translateZ(100px); }
#cube .top { -webkit-transform: rotateX(90deg) translateZ(100px); }
#cube .bottom { -webkit-transform: rotateX(-90deg) translateZ(100px); }

Note here that the translateZ function comes after the rotate. The order of transform functions is important. Take a moment and soak this up. Each face is first rotated towards its position, then translated outward in a separate vector.
We have a working cube, but we’re not done yet.

Returning to the Z-axis origin

For the sake of our users, our 3-D transforms should not distort the interface when the active panel is at its resting position. But once we start pushing elements off their Z-axis origin, distortion is inevitable.
In order to keep 3-D transforms snappy, Safari composites the element, then applies the transform. Consequently, anti-aliasing on text will remain whatever it was before the transform was applied. When transformed forward in 3-D space, significant pixelation can occur.
See Example: Transforms 2.

Looking back at the Perspective 3 demo, note that no matter how small the perspective value is, or wherever the transform-origin may be, the panel number 1 always returns to its original position, as if all those funky 3-D transforms didn’t even matter.
To resolve the distortion and restore pixel perfection to our #cube, we can push the 3-D object back, so that the front face will be positioned back to the Z-axis origin.

#cube { -webkit-transform: translateZ(-100px); }

See Example: Cube 1.

Restoring the front face to the original position on the Z-axis

Rotating the cube

To expose any face of the cube, we’ll need a style that rotates the cube to expose any face. The transform values are the opposite of those for the corresponding face. We toggle the necessary class on the #box to apply the appropriate transform.

#cube.show-front { -webkit-transform: translateZ(-100px) rotateY(0deg); }
#cube.show-back { -webkit-transform: translateZ(-100px) rotateX(-180deg); }
#cube.show-right { -webkit-transform: translateZ(-100px) rotateY(-90deg); }
#cube.show-left { -webkit-transform: translateZ(-100px) rotateY(90deg); }
#cube.show-top { -webkit-transform: translateZ(-100px) rotateX(-90deg); }
#cube.show-bottom { -webkit-transform: translateZ(-100px) rotateX(90deg); }

Notice how the order of the transform functions has reversed. First, we push the object back with translateZ, then we rotate it.
Finishing up, we can add a transition to animate the rotation between states.

#cube { -webkit-transition: -webkit-transform 1s; }

See Example: Cube 2.

Rotating the cube with a CSS transition

Rectangular prism

Cubes are easy enough to generate, as we only have to worry about one measurement. But how would we handle a non-regular rectangular prism? Let’s try to make one that’s 300 pixels wide, 200 pixels high, and 100 pixels deep.
The markup remains the same as the #cube, but we’ll switch the cube id for #box. The container styles remain mostly the same:

.container {
  width: 300px;
  height: 200px;
  position: relative;
  -webkit-perspective: 1000;
}
#box {
  width: 100%;
  height: 100%;
  position: absolute;
  -webkit-transform-style: preserve-3d;
}

Now to position the faces. Each set of faces will need their own sizes. The smaller faces (left, right, top and bottom) need to be positioned in the centre of the container, where they can be easily rotated and then shifted outward. The thinner left and right faces get positioned left: 100px ((300 − 100) ÷ 2), The stouter top and bottom faces get positioned top: 50px ((200 − 100) ÷ 2).

#box figure {
  display: block;
  position: absolute;
  border: 2px solid black;
}
#box .front,
#box .back {
  width: 296px;
  height: 196px;
}
#box .right,
#box .left {
  width: 96px;
  height: 196px;
  left: 100px;
}
#box .top,
#box .bottom {
  width: 296px;
  height: 96px;
  top: 50px;
}

The rotate values can all remain the same as the cube example, but for this rectangular prism, the translate values do differ. The front and back faces are each shifted out 50 pixels since the #box is 100 pixels deep. The translate value for the left and right faces is 150 pixels for their 300 pixels width. Top and bottom panels take 100 pixels for their 200 pixels height:

#box .front { -webkit-transform: rotateY(0deg) translateZ(50px); }
#box .back { -webkit-transform: rotateX(180deg) translateZ(50px); }
#box .right { -webkit-transform: rotateY(90deg) translateZ(150px); }
#box .left { -webkit-transform: rotateY(-90deg) translateZ(150px); }
#box .top { -webkit-transform: rotateX(90deg) translateZ(100px); }
#box .bottom { -webkit-transform: rotateX(-90deg) translateZ(100px); }

See Example: Box 1.

Just like the cube example, to expose a face, the #box needs to have a style to reverse that face’s transform. Both the translateZ and rotate values are the opposites of the corresponding face.

#box.show-front { -webkit-transform: translateZ(-50px) rotateY(0deg); }
#box.show-back { -webkit-transform: translateZ(-50px) rotateX(-180deg); }
#box.show-right { -webkit-transform: translateZ(-150px) rotateY(-90deg); }
#box.show-left { -webkit-transform: translateZ(-150px) rotateY(90deg); }
#box.show-top { -webkit-transform: translateZ(-100px) rotateX(-90deg); }
#box.show-bottom { -webkit-transform: translateZ(-100px) rotateX(90deg); }

See Example: Box 2.

Rotating the rectangular box with a CSS transition

Carousel

Front-end developers have a myriad of choices when it comes to content carousels. Now that we have 3-D capabilities in our browsers, why not take a shot at creating an actual 3-D carousel?
The markup for this demo takes the same form as the box, cube and card. Let’s make it interesting and have a carousel with nine panels.

<div class="container">
  <div id="carousel">
    <figure>1</figure>
    <figure>2</figure>
    <figure>3</figure>
    <figure>4</figure>
    <figure>5</figure>
    <figure>6</figure>
    <figure>7</figure>
    <figure>8</figure>
    <figure>9</figure>
  </div>
</div>

Now, apply basic layout styles. Let’s give each panel of the #carousel 20 pixel gaps between one another, done here with left: 10px; and top: 10px;. The effective width of each panel is 210 pixels.

.container {
  width: 210px;
  height: 140px;
  position: relative;
  -webkit-perspective: 1000;
}
#carousel {
  width: 100%;
  height: 100%;
  position: absolute;
  -webkit-transform-style: preserve-3d;
}
#carousel figure {
  display: block;
  position: absolute;
  width: 186px;
  height: 116px;
  left: 10px;
  top: 10px;
  border: 2px solid black;
}

Next up: rotating the faces. This #carousel has nine panels. If each panel gets an equal distribution on the carousel, each panel would be rotated forty degrees from its neighbour (360 ÷ 9).

#carousel figure:nth-child(1) { -webkit-transform: rotateY(0deg); }
#carousel figure:nth-child(2) { -webkit-transform: rotateY(40deg); }
#carousel figure:nth-child(3) { -webkit-transform: rotateY(80deg); }
#carousel figure:nth-child(4) { -webkit-transform: rotateY(120deg); }
#carousel figure:nth-child(5) { -webkit-transform: rotateY(160deg); }
#carousel figure:nth-child(6) { -webkit-transform: rotateY(200deg); }
#carousel figure:nth-child(7) { -webkit-transform: rotateY(240deg); }
#carousel figure:nth-child(8) { -webkit-transform: rotateY(280deg); }
#carousel figure:nth-child(9) { -webkit-transform: rotateY(320deg); }

Now, the outward shift. Back when we were creating the cube and box, the translate value was simple to calculate, as it was equal to one half the width, height or depth of the object. With this carousel, there is no size we can automatically use as a reference. We’ll have to calculate the distance of the shift by other means.

Drawing a diagram of the carousel, we can see that we know only two things: the width of each panel is 210 pixels; and the each panel is rotated forty degrees from the next. If we split one of these segments down its centre, we get a right-angled triangle, perfect for some trigonometry.
We can determine the length of r in this diagram with a basic tangent equation:

There you have it: the panels need to be translated 288 pixels in 3-D space.

#carousel figure:nth-child(1) { -webkit-transform: rotateY(0deg) translateZ(288px); }
#carousel figure:nth-child(2) { -webkit-transform: rotateY(40deg) translateZ(288px); }
#carousel figure:nth-child(3) { -webkit-transform: rotateY(80deg) translateZ(288px); }
#carousel figure:nth-child(4) { -webkit-transform: rotateY(120deg) translateZ(288px); }
#carousel figure:nth-child(5) { -webkit-transform: rotateY(160deg) translateZ(288px); }
#carousel figure:nth-child(6) { -webkit-transform: rotateY(200deg) translateZ(288px); }
#carousel figure:nth-child(7) { -webkit-transform: rotateY(240deg) translateZ(288px); }
#carousel figure:nth-child(8) { -webkit-transform: rotateY(280deg) translateZ(288px); }
#carousel figure:nth-child(9) { -webkit-transform: rotateY(320deg) translateZ(288px); }

If we decide to change the width of the panel or the number of panels, we only need to plug in those two variables into our equation to get the appropriate translateZ value. In JavaScript terms, that equation would be:

var tz = Math.round( ( panelSize / 2 ) / 
  Math.tan( ( ( Math.PI * 2 ) / numberOfPanels ) / 2 ) );
// or simplified to
var tz = Math.round( ( panelSize / 2 ) / 
  Math.tan( Math.PI / numberOfPanels ) );

Just like our previous 3-D objects, to show any one panel we need only apply the reverse transform on the carousel. Here’s the style to show the fifth panel:

-webkit-transform: translateZ(-288px) rotateY(-160deg);

See Example: Carousel 1.

By now, you probably have two thoughts:

Rewriting transform styles for each panel looks tedious.
Why bother doing high school maths? Aren’t robots supposed to be doing all this work for us?

And you’re absolutely right. The repetitive nature of 3-D objects lends itself to scripting. We can offload all the monotonous transform styles to our dynamic script, which, if done correctly, will be more flexible than the hard-coded version.
See Example: Carousel 2.

Conclusion

3-D transforms change the way we think about the blank canvas of web design. Better yet, they change the canvas itself, trading in the flat surface for voluminous depth.
My hope is that you took at least one peak at a demo and were intrigued. We web designers, who have rejoiced for border-radius, box-shadow and background gradients, now have an incredible tool at our disposal in 3-D transforms. They deserve just the same enthusiasm, research and experimentation we have seen on other CSS3 features. Now is the perfect time to take the plunge and start thinking about how to use three dimensions to elevate our craft. I’m breathless waiting for what’s to come.
See you on the flip side.

New form features in HTML5

2012-02-12T03:47:00.001-08:00

Introduction

HTML5 includes many new features to make web forms a lot easier to write, and a lot more powerful and consistent across the Web. This article gives a brief overview of some of the new form controls and functionalities that have been introduced.

Bad form?

Let's face it – HTML forms have always been a pain. They are not much fun to mark up and they can be fiddly to style – especially if you want them to be consistent cross-browser and fit in with the overall look and feel of your site. And they can be frustrating for your end users to fill out, even if you create them with care and consideration to make them as usable and accessible as possible. Creating a good form is more about damage limitation than pleasurable user experiences.
Back when HTML 4.01 became a stable recommendation, the web was a mostly static place. Yes, there was the odd comment form or guest book script, but generally web sites were there for visitors to simply read. Since then, the web has evolved. For many people, the browser has already become a window into a world of complex, web-based applications that try to bring an almost desktop-like experience.

Figure 1: Some complicated non-native form controls, faked with JavaScript.

To fill the need for the more sophisticated controls required for such applications, developers have been taking advantage of JavaScript libraries and frameworks (such as jQueryUI or YUI). These solutions have certainly matured over the years, bringing rich functionality to web pages and even starting to incorporate screenreader support through bridging technologies like WAI-ARIA. But essentially, they're a workaround to compensate for the limited form controls available in HTML. They “fake” the more complex widgets (such as date pickers and sliders) by layering additional (not always semantic) markup and a slew of JavaScript on top of pages.
HTML5 aims to standardise some of the most common rich form controls, making them render natively in the browser and obviating the need for these script-heavy workarounds.

Introducing our example

To illustrate some of the new features, this article comes with a basic HTML5 forms example. It's not meant to represent a "real" form (as you'd be hard-pressed to find a situation where you need all the new features in a single form), but it should give you an idea of how the various new aspects look and behave.

Note: the look and feel of the new form controls and validation messages differs from brower to browser, so styling your forms to look reasonably consistent across browsers will still need careful consideration.

New form controls

As forms are the main tool for data input in Web applications, and the data we want to collect has become more complex, it has been necessary to create an input element with more capabilities, to collect this data with more semantics and better definition, and allow for easier, more effective error mnagement and validation.

`<input type="number">`

The first new input type we'll discuss is the number type:

<input type="number" … >

This creates a special kind of input field for number entry – in most supporting browsers this appears as a text entry field with a spinner control, which allows you to increment and decrement its value.

Figure 2: A number input type.

`<input type="range">`

Creating a slider control to allow you to choose between a range of values used to be a complicated, semantically dubious proposition, but with HTML5 it is easy — you just use the range input type:

<input type="range" … >

Figure 3: A range input type.

Note that, by default, this input does not generally show the currently selected value, or even the range of values it covers. Authors will need to provide these through other means – for instance, to display the current value, we could us an output element together with some JavaScript to update its display whenever the user has interacted with the form:

<output onforminput="value=weight.value"></output>

`<input type="date">` and other date/time controls

HTML5 has a number of different input types for creating complicated date/time pickers, for example the kind of date picker you see featured on pretty much every flight/train booking site out there. These used to be created using unsemantic kludges, so it is great that we now have standardized easy ways to do this. For example:

<input type="date" … >
<input type="time" … >

Respectively, these create a fully functioning date picker, and a text input containing a separator for hours, minutes and seconds (depending on the step attribute specified) that only allows you to input a time value.

Figure 4: date and time input types.

But it doesn't end here — there are a number of other related input types available:

datetime: combines the functionality of two we have looked at above, allowing you to choose a date and a time
month: allows you to choose a month, stored internally as a number between 1-12, although different browsers may provide you with more elaborate choosing mechanisms, like a scrolling list of the month names
week: allows you to choose a week, stored internally in the format 2010-W37 (week 37 of the year 2010), and chosen using a similar datepicker to the ones we have seen already

`<input type="color">`

This input type brings up a color picker. Opera's implementation allows the user to pick from a selection of colors, enter hexadecimal values directly in a text field, or to invoke the OS's native color picker.

Figure 5: a color input, and the native color pickers on Windows and OS X.

`<input type="search">`

The search input type is arguably nothing more than a differently-styled text input. Browsers are meant to style these inputs the same way as any OS-specific search functionality. Beyond this purely aesthetic consideration, though, it's still important to note that marking up search fields explicitly opens up the possibility for browsers, assistive technologies or automated crawlers to do something clever with these inputs in the future – for instance, a browser could conceivably offer the user a choice to automatically create a custom search for a specific site.

Figure 6: A search input as it appears in Opera on OS X.

`<datalist>` element and `list` attribute

Up until now we have been used to using <select> and <option> elements to create dropdown lists of options for our users to choose from. But what if we wanted to create a list that allowed users to choose from a list of suggested options, as well as being able to type in their own? That required fiddly scripting – but now you can simply use the list attribute to connect an ordinary input to a list of options, defined inside a <datalist> element.

<input type="text" list="mydata" … >
<datalist id="mydata">
    <option label="Mr" value="Mister">
    <option label="Mrs" value="Mistress">
    <option label="Ms" value="Miss">
</datalist>

Figure 7: Creating an input element with suggestions using datalist.

`<input type="tel">`, `<input type="email">` and `<input type="url">`

As their names imply, these new input types relate to telephone numbers, email addresses or URLs. Browsers will render these as normal text entry inputs, but explicitly stating what kind of text we're expecting in these fields plays an important role in client-side form validation. Additionally, on certain mobile devices the browser will switch from its regular text entry on-screen keyboard to the more context-relevant variants. Again, it's conceivable that in the future browsers will take further advantage of these explicitly marked-up inputs to offer additional functionality, such as autocompleting email addresses and telephone numbers based on the user's contacts list or address book.

New attributes

In addition to explicit new input types, HTML5 defines a series of new attributes for form controls that help simplify some common tasks and further specify the expected values for certain entry fields.

`placeholder`

A common usability trick in web forms is to have placeholder content in text entry fields – for instance, to give more information about the expected type of information we want the user to enter – which disappears when the form control gets focus. While this used to require some JavaScript (clearing the contents of the form field on focus and resetting it to the default text if the user left the field without entering anything), we can now simply use the placeholder attribute:

<input type="text"… placeholder="John Doe">

Figure 8: A text input with placeholder text.

`autofocus`

Another common feature that previously had to rely on scripting is having a form field automatically focused when a page is loaded. This can now be achieved with the autofocus attribute:

<input type="text" autofocus … >

Keep in mind that you shouldn't have more than one autofocus form control on a single page. You should also use this sort of functionality with caution, in situations where a form represents the main area of interest in a page. A search page is a good example – provided that there isn't a lot of content and explanatory text, it makes sense to set the focus automatically to the text input of the search form.

`min` and `max`

As their name suggests, this pair of attributes allows you to set a lower and upper bound for the values that can be entered into a numerical form field, for example number, range, time or date input types (yes, you can even use it to set upper and lower bounds for dates – for instance, on a travel booking form you could limit the datepicker to only allow the user to select future dates). For range inputs, min and max are actually necessary to define what values are returned when the form is submitted. The code is pretty simple and self-explanatory:

<input type="number" … min="1" max="10">

`step`

The step attribute can be used with a numerical input value to dictate how granular the values you can input are. For example, you might want users to enter a particular time, but only in 30 minute increments. In this case, we can use the step attribute, keeping in mind that for time inputs the value of the attribute is in seconds:

<input type="time" … step="1800">

New output mechanisms

Beyond the new form controls that users can interact with, HTML5 defines a series of new elements specifically meant to display and visualise information to the user.

`<output>`

We've already mentioned the output element when talking about the range input – this element serves as a way to display the result of a calculation, or more generally to provide an explicitly identified output of a script (rather than simply pushing some text into in a random span or div with innerHTML, for instance). To make it even more explicit what particular form controls the output relates to, we can – in a similar way to label – pass a list of IDs in the element's optional for attribute.


<input type="range" id="rangeexample" … >
<output onforminput="value=rangeexample.value" for="rangeexample"></output>

`<progress>` and `<meter>`

These two new elements are very similar, both resulting in a gauge/bar being presented to the user. Their distinction is in their intended purpose. As the name suggests, progress is meant to represent a progress bar, to indicate the percentage of completion of a particular task, while meter is a more generic indicator of a scalar measurement or fractional value.

Figure 9: A progress indicator bar.

Validation

Form validation is very important on both client- and server-side, to help legitimate users avoid and correct mistakes, and to stop malicious users submitting data that could cause damage to our application. As browsers can now get an idea of what type of values are expected from the various form controls (be it their type, or any upper/lower bounds set on numerical values, dates and times), they can also offer native form validation – another tedious task that, up to now, required authors to write reams of JavaScript or use some ready-made validation script/library.

Note: for form controls to be validated, they need to have a name attribute, as without it they wouldn't be submitted as part of the form anyway.

`required`

One of the most common aspects of form validation is the enforcement of required fields – not allowing a form to be submitted until certain pieces of information have been entered. This can now simply be achieved by adding the required attribute to an input, select or textarea element.

<input type="text" … required>

Figure 10: Opera's client-side validation in action, showing an error for a required field that was left empty.

`type` and `pattern`

As we've seen, authors can now specify the kinds of entries they expect from their form fields – rather than simply defining text inputs, authors can explicitly create inputs for things like numbers, email addresses and URLs. As part of their client-side validation, browsers can now check that what the user entered in these more specific fields matches the expected structure – in essence, browsers evaluate the input values against a built-in pattern that defines what valid entires in those types of inputs look like, and will warn a user when their entry didn't match the criteria.

Figure 11: Opera's error message for invalid email addresses in an email input.
For other text entry fields that nonetheless need to follow a certain structure (for instance, login forms where the usernames can only contain a specific sequence of lowercase letters and numbers), authors can use the pattern attribute to specify their own custom regular expression.

<input type="text" … pattern="[a-z]{3}[0-9]{3}">

Styling with CSS3

In concert with HTML5's built-in form validation, the CSS3 Basic User Interface Module defines a series of new pseudo-classes that can be used to differentiate required fields and to change the appearance of form controls dynamically based on whether or not they have been filled in correctly:

:required and :optional let us explicitly style controls based on whether or not they have a required attribute
:valid and :invalid will apply styles to form controls subject to client-side validation
:in-range and :out-of-range specifically works with controls that feature a min and/or max attribute

In our example form, we're only applying specific validity and range styles on text, email, url and number inputs when they are currently focused, so users would get some immediate visual feedback while entering information into those fields, but without affecting the overall look of the form in general.

input[type=text]:focus:valid,
input[type=email]:focus:valid,
input[type=number]:focus:in-range { outline: 2px #0f0 solid; }

input[type=text]:focus:invalid,
input[type=email]:focus:invalid,
input[type=number]:focus:out-of-range { outline: 2px #f00 solid; }

Figure 12: :valid and :invalid styles being applied dynamically as an email address is entered.

Cross browser?

On the desktop, Opera currently has the most complete implementation of new input types and native client-side validation, but support is on the roadmap for all other major browsers as well, so it won't be long before we can take advantage of these new powerful tools in our projects. But what about older browser versions?
By design, browsers that don't understand the new input types (like date or number) will simply fall back to treating them as standard text inputs – not as user-friendly as their advanced HTML5 counterparts, but at the very least they allow for a form to be filled in. However, as with most of the new HTML5 functionalities, we can offer a nicer fallback for users of browsers that aren't quite up to speed with HTML5 forms by doing basic JavaScript-based feature-detection and, only if needed, proceed to load external JavaScript libraries to “fake” the support for more complex form control widgets and validation. This way, we can code for the future, while not alienating any of our users.

Part1: Introducing Android 4.0 - Simple, Beautiful, Useful

2012-01-21T10:04:00.000-08:00

Introducing Android 4.0

Android 4.0 (Ice Cream Sandwich) is the latest version of the Android platform for phones, tablets, and more. It builds on the things people love most about Android — easy multitasking, rich notifications, customizable home screens, resizable widgets, and deep interactivity — and adds powerful new ways of communicating and sharing.

Simple, Beautiful, Useful

Refined, evolved UI

Focused on bringing the power of Android to the surface, Android 4.0 makes common actions more visible and lets you navigate with simple, intuitive gestures. Refined animations and feedback throughout the system make interactions engaging and interesting. An entirely new typeface optimized for high-resolution screens improves readability and brings a polished, modern feel to the user interface.
Virtual buttons in the System Bar let you navigate instantly to Back, Home, and Recent Apps. The System Bar and virtual buttons are present across all apps, but can be dimmed by applications for full-screen viewing. You can access each application's contextual options in the Action Bar, displayed at the top (and sometimes also at the bottom) of the screen.
Multitasking is a key strength of Android and it's made even easier and more visual on Android 4.0. The Recent Apps button lets you jump instantly from one task to another using the list in the System Bar. The list pops up to show thumbnail images of apps used recently — tapping a thumbnail switches to the app.

The Recent Apps list makes multitasking simple.

Jump to the camera or see notifications without unlocking.

For incoming calls, you can respond instantly by text.

Rich and interactive notifications let you keep in constant touch with incoming messages, play music tracks, see real-time updates from apps, and much more. On smaller-screen devices, notifications appear at the top of the screen, while on larger-screen devices they appear in the System Bar.

Home screen folders and favorites tray

New home screen folders offer a new way for you to group your apps and shortcuts logically, just by dragging one onto another. Also, in All Apps launcher, you can now simply drag an app to get information about it or immediately uninstall it, or disable a pre-installed app.

The All Apps launcher (left) and resizable widgets (right) give you apps and rich content from the home screen.

On smaller-screen devices, the home screen now includes a customizable favorites tray visible from all home screens. You can drag apps, shortcuts, folders, and other priority items in or out of the favorites tray for instant access from any home screen.

Resizable widgets

Home screens in Android 4.0 are designed to be content-rich and customizable. You can do much more than add shortcuts — you can embed live application content directly through interactive widgets. Widgets let you check email, flip through a calendar, play music, check social streams, and more — right from the home screen, without having to launch apps. Widgets are resizable, so you can expand them to show more content or shrink them to save space.

New lock screen actions

The lock screens now let you do more without unlocking. From the slide lock screen, you can jump directly to the camera for a picture or pull down the notifications window to check for messages. When listening to music, you can even manage music tracks and see album art.

Quick responses for incoming calls

When an incoming call arrives, you can now quickly respond by text message, without needing to pick up the call or unlock the device. On the incoming call screen, you simply slide a control to see a list of text responses and then tap to send and end the call. You can add your own responses and manage the list from the Settings app.

Swipe to dismiss notifications, tasks, and browser tabs

Android 4.0 makes managing notifications, recent apps, and browser tabs even easier. You can now dismiss individual notifications, apps from the Recent Apps list, and browser tabs with a simple swipe of a finger.

A spell-checker lets you find errors and fix them faster.

A powerful voice input engine lets you dictate continuously.

Improved text input and spell-checking

The soft keyboard in Android 4.0 makes text input even faster and more accurate. Error correction and word suggestion are improved through a new set of default dictionaries and more accurate heuristics for handling cases such as double-typed characters, skipped letters, and omitted spaces. Word suggestion is also improved and the suggestion strip is simplified to show only three words at a time.
To fix misspelled words more easily, Android 4.0 adds a spell-checker that locates and underlines errors and suggests replacement words. With one tap, you can choose from multiple spelling suggestions, delete a word, or add it to the dictionary. You can even tap to see replacement suggestions for words that are spelled correctly. For specialized features or additional languages, you can now download and install third-party dictionaries, spell-checkers, and other text services.

Powerful voice input engine

Android 4.0 introduces a powerful new voice input engine that offers a continuous "open microphone" experience and streaming voice recognition. The new voice input engine lets you dictate the text you want, for as long as you want, using the language you want. You can speak continously for a prolonged time, even pausing for intervals if needed, and dictate punctuation to create correct sentences. As the voice input engine enters text, it underlines possible dictation errors in gray. After dictating, you can tap the underlined words to quickly replace them from a list of suggestions.

Data usage controls let you monitor total usage by network type and application and then set limits if needed.

Control over network data

Mobile devices can make extensive use of network data for streaming content, synchronizing data, downloading apps, and more. To meet the needs of you with tiered or metered data plans, Android 4.0 adds new controls for managing network data usage.
In the Settings app, colorful charts show the total data usage on each network type (mobile or Wi-Fi), as well as amount of data used by each running application. Based on your data plan, you can optionally set warning levels or hard limits on data usage or disable mobile data altogether. You can also manage the background data used by individual applications as needed.

Designed for accessibility

A variety of new features greatly enhance the accessibility of Android 4.0 for blind or visually impaired users. Most important is a new explore-by-touch mode that lets you navigate without having to see the screen. Touching the screen once triggers audible feedback that identifies the UI component below; a second touch in the same component activates it with a full touch event. The new mode is especially important to support users on new devices that use virtual buttons in the System Bar, rather than dedicated hardware buttons or trackballs. Also, standard apps are updated to offer an improved accessibility experience. The Browser supports a script-based screen reader for reading favorite web content and navigating sites. For improved readability, you can also increase the default font size used across the system.
The accessibility experience begins at first setup — a simple touch gesture during setup (clockwise square from upper left) activates all accessibility features and loads a setup tutorial. Once accessibility features are active, everything visible on the screen can be spoken aloud by the standard screen reader.

Contacts and profiles are integrated across apps and social networks, for a consistent, personal experience everywhere — from incoming calls to emails.

Communication and sharing

People and profiles

Throughout the system, your social groups, profiles, and contacts are linked together and integrated for easy accessibility. At the center is a new People app that offers richer profile information, including a large profile picture, phone numbers, addresses and accounts, status updates, events, and a new button for connecting on integrated social networks.
Your contact information is stored in a new "Me" profile, allowing easier sharing with apps and people. All of your integrated contacts are displayed in an easy to manage list, including controls over which contacts are shown from any integrated account or social network. Wherever you navigate across the system, tapping a profile photo displays Quick Contacts, with large profile pictures, shortcuts to phone numbers, text messaging, and more.

Unified calendar, visual voicemail

To help organize appointments and events, an updated Calendar app brings together personal, work, school, and social agendas. With user permission, other applications can contribute events to the calendar and manage reminders, for an integrated view across multiple calendar providers. The app is redesigned to let you manage events more easily. Calendars are color-coded and you can swipe left or right to change dates and pinch to zoom in or out agendas.
In the phone app, a new visual voicemail features integrates incoming messages, voice transcriptions, and audio files from one or more providers. Third-party applications can integrate with the Phone app to add your own voice messages, transcriptions, and more to the visual voicemail inbox.

Capture the picture you want, edit, and share instantly.

Rich and versatile camera capabilities

The Camera app includes many new features that let you capture special moments with great photos and videos. After capturing images, you can edit and share them easily with friends.
When taking pictures, continuous focus, zero shutter lag exposure, and decreased shot-to-shot speed help capture clear, precise images. Stabilized image zoom lets you compose photos and video in the way you want, including while video is recording. For new flexibility and convenience while shooting video, you can now take snapshots at full video resolution just by tapping the screen as video continues to record.
To make it easier to take great pictures of people, built-in face detection locates faces in the frame and automatically sets focus. For more control, you can tap to focus anywhere in the preview image.
For capturing larger scenes, the Camera introduces a single-motion panorama mode. In this mode, you start an exposure and then slowly turn the Camera to encompass as wide a perspective as needed. The Camera assembles the full range of continuous imagery into a single panoramic photo.
After taking a picture or video, you can quickly share it by email, text message, bluetooth, social networks, and more, just by tapping the thumbnail in the camera controls.

A Photo Gallery widget on the home screen.

Redesigned Gallery app with photo editor

The Gallery app now makes it easier to manage, show, and share photos and videos. For managing collections, a redesigned album layout shows many more albums and offers larger thumbnails. There are many ways to sort albums, including by time, location, people, and tags. To help pictures look their best, the Gallery now includes a powerful photo editor. You can crop and rotate pictures, set levels, remove red eyes, add effects, and much more. After retouching, you can select one or multiple pictures or videos to share instantly over email, text messaging, bluetooth, social networks, or other apps.
An improved Picture Gallery widget lets you look at pictures directly on the home screen. The widget can display pictures from a selected album, shuffle pictures from all albums, or show a single image. After adding the widget to the home screen, you can flick through the photo stacks to locate the image you want, then tap to load it in Gallery.

Live Effects let you change backgrounds and use Silly Faces during video.

Live Effects for transforming video

Live Effects is a collection of graphical transformations that add interest and fun to videos captured in the Camera app. For example, you can change the background behind them to any stock or custom image, for just the right setting when shooting video. Also available for video is Silly Faces, a set of morphing effects that use state-of-the-art face recognition and GPU filters to transform facial features. For example, you can use effects such as small eyes, big mouth, big nose, face squeeze, and more. Outside of the Camera app, Live Effects is available during video chat in the Google Talk app.

Snapping a screenshot.

Sharing with screenshots

You can now share what's on your screens more easily by taking screenshots. Hardware buttons let them snap a screenshot and store it locally. Afterward, you can view, edit, and share the screen shot in Gallery or a similar app.

Cloud-connected experience

Android has always been cloud-connected, letting you browse the web and sync photos, apps, games, email, and contacts — wherever you are and across all of your devices. Android 4.0 adds new browsing and email capabilities to let you take even more with them and keep communication organized.

The Browser tabs menu (left) lets you quickly switch browser tabs. The options menu (right) gives you new ways to manage your browsing experience.

Benchmark comparisons of Android Browser.

Powerful web browsing

The Android Browser offers an experience that’s as rich and convenient as a desktop browser. It lets you instantly sync and manage Google Chrome bookmarks from all of your accounts, jump to your favorite content faster, and even save it for reading later in case there's no network available.
To get the most out of web content, you can now request full desktop versions of web sites, rather than their mobile versions. You can set your preference for web sites separately for each browser tab. For longer content, you can save a copy for offline reading. To find and open saved pages, you can browse a visual list that’s included with browser bookmarks and history. For better readability and accessibility, you can increase the browser’s zoom levels and override the system default text sizes.
Across all types of content, the Android Browser offers dramatically improved page rendering performance through updated versions of the WebKit core and the V8 Crankshaft compilation engine for JavaScript. In benchmarks run on a Nexus S device, the Android 4.0 browser showed an improvement of nearly 220% over the Android 2.3 browser in the V8 Benchmark Suite and more than 35% in the SunSpider 9.1 JavaScript Benchmark. When run on a Galaxy Nexus device, the Android 4.0 browser showed improvement of nearly 550% in the V8 benchmark and nearly 70% in the SunSpider benchmark.

Improved email

In Android 4.0, email is easier to send, read, and manage. For composing email, improved auto-completion of recipients helps with finding and adding frequent contacts more quickly. For easier input of frequent text, you can now create quick responses and store them in the app, then enter them from a convenient menu when composing. When replying to a message, you can now toggle the message to Reply All and Forward without changing screens.
For easier browsing across accounts and labels, the app adds an integrated menu of accounts and recent labels. To help you locate and organize IMAP and Exchange email, the Email app now supports nested mail subfolders, each with synchronization rules. You can also search across folders on the server, for faster results.
For enterprises, the Email app supports EAS v14. It supports EAS certificate authentication, provides ABQ strings for device type and mode, and allows automatic sync to be disabled while roaming. Administrators can also limit attachment size or disable attachments.
For keeping track of incoming email more easily, a resizable Email widget lets you flick through recent email right from the home screen, then jump into the Email app to compose or reply.

Android Beam lets you share what you are using with a single tap.

Innovation

Android is continuously driving innovation forward, pushing the boundaries of communication and sharing with new capabilities and interactions.

Android Beam for NFC-based sharing

Android Beam is an innovative, convenient feature for sharing across two NFC-enabled devices, It lets people instantly exchange favorite apps, contacts, music, videos — almost anything. It’s incredibly simple and convenient to use — there’s no menu to open, application to launch, or pairing needed. Just touch one Android-powered phone to another, then tap to send.
For sharing apps, Android Beam pushes a link to the app's details page in Android Market. On the other device, the Market app launches and loads the details page, for easy downloading of the app. Individual apps can build on Android Beam to add other types of interactions, such as passing game scores, initiating a multiplayer game or chat, and more.

Face recognition lets you unlock your phone with your face.

Face Unlock

Android 4.0 introduces a completely new approach to securing a device, making each person's device even more personal — Face Unlock is a new screen-lock option that lets you unlock your device with your face. It takes advantage of the device front-facing camera and state-of-the-art facial recognition technology to register a face during setup and then to recognize it again when unlocking the device. Just hold your device in front of your face to unlock, or use a backup PIN or pattern.

Wi-Fi Direct and Bluetooth HDP

Support for Wi-Fi Direct lets you connect directly to nearby peer devices over Wi-Fi, for more reliable, higher-speed communication. No internet connection or tethering is needed. Through third-party apps, you can connect to compatible devices to take advantage of new features such as instant sharing of files, photos, or other media; streaming video or audio from another device; or connecting to compatible printers or other devices.
Android 4.0 also introduces built-in support for connecting to Bluetooth Health Device Profile (HDP) devices. With support from third-party apps, you can connect to wireless medical devices and sensors in hospitals, fitness centers, homes, and elsewhere.

First Data Global Payment Gateway for Magento by Booklink

2012-01-21T09:50:00.000-08:00

Magento Go, Part 5: Configurable Products - Managing Images

2012-01-21T09:45:00.000-08:00

Creating Accessible JavaScript

2012-01-02T02:20:00.000-08:00

Overview of Creating Accessible JavaScript

Article Contents

Current page: Page 1: Overview of Creating Accessible Javascript
Page 2: JavaScript Event Handlers
Page 3: Other Issues
Page 4: JavaScript Alternatives
Page 5: Accessible JavaScript Summary

What is JavaScript?

This may best be answered by defining what JavaScript is NOT. First, it is not HTML. JavaScript does not use HTML tags or abide by any of the general rules of the HTML language. You can, however, use JavaScript with HTML on a webpage. Second, JavaScript is not Java. Although JavaScript is often called Java, the two are not the same. Java was developed by Sun Microsystems and is a stand-alone programming language. JavaScript, on the other hand, was developed by Netscape Corporation. Although similar to Java in syntax, JavaScript is not a stand-alone language; in order for JavaScript to work, it must be part of a web page that is being displayed in a browser that understands the JavaScript language. Sun's Java programming language can be implemented in webpages as a built in program, whereas JavaScript scripts are reliant upon the client (visitor's) computer in order for them to work.

Once again, JavaScript is not HTML or a version of HTML. It is a distinct, separate scripting language. HTML is read and processed by the web browser. When the browser reads JavaScript code within your HTML document, it processes the code, then displays any output within the web page. The computer reading the JavaScript must have a JavaScript interpreter, a program that interprets the script and runs it, and that interpreter must be enabled.

HTML, alone, creates very static pages. There is little user interaction and little by the way of dynamic content within a particular page. HTML cannot think; it does not have the capabilities to perform mathematics, store variables, or dynamically display content. JavaScript allows your web page to 'think'. Although many server-side scripting programs (such as PHP, JPS, ASP, or ColdFusion) have the ability to perform such functions, JavaScript can perform these functions within the client web browser. Because JavaScript is a scripting language, it allows developers to implement little applications into their pages. These programs may do things as simple as changing a graphic when the mouse rolls over it to something as complex as performing advanced mathematical formulas on user input.

JavaScript Accessibility Issues

JavaScript allows developers to add increased interaction, information processing, and control in web-based content. However, JavaScript can also introduce accessibility issues. These issues include:

Navigation. Inability or difficulty navigating using a keyboard or assistive technology.
Hidden content. Presentation of content or functionality that is not accessible to assistive technologies.
User control. Lack of user control over automated content changes.
Confusion/Disorientation. Altering or disabling the normal functionality of the user agent (browser) or triggering events that the user may not be aware of.

A web page containing JavaScript will typically be fully accessible if the functionality of the script is device independent (does not require only a mouse or only a keyboard) and the information (content) is available to assistive technologies. Unfortunately, there is no easy fix that can be applied to solve all accessibility problems associated with JavaScript. The only way to ensure JavaScript accessibility is by evaluating each individual script and devising a unique solution to the accessibility problem it poses. Developers must be familiar with the issues surrounding JavaScript accessibility and apply techniques to do one or both of the following:

Ensure the JavaScript is directly accessible
Provide an accessible, non-JavaScript alternative

JavaScript that does not impact accessibility

Just because JavaScript is utilized on a page does not mean that the page is inaccessible. In many cases, JavaScript can be used to increase accessibility. Additional information, warnings, or instructions can be given to users through JavaScript prompts. For instance, under the Section 508 guidelines of United States law, a user must be notified when a timed response is required and given sufficient time to indicate more time is required. Such functionality would be difficult with HTML alone.
JavaScript is sometimes used to create visual interface elements that do not affect accessibility. JavaScript is commonly used for image rollovers, where one image is replaced with another when the mouse is placed above it; for example, when a navigation item changes to display a shadow, glow, or highlight when the user mouses over it.

Place your mouse over the following image to see a JavaScript example that does not impact accessibility.

Problems

None. In this example, there is no important content or functionality introduced by the JavaScript. The swapping of images is purely cosmetic.

Solution

No additional accessibility techniques are required. Remember, the image itself must have alternative text (i.e., <img alt="home"...>). You can also accomplish image rollovers without using JavaScript - external link.

Such uses of JavaScript do not need additional accessibility features incorporated because important content is not displayed or functionality introduced by such scripting.
Making JavaScript accessible involves looking at the following issues. Each of these will be discussed in the next lessons.

When using event handlers, use only those that are device independent (e.g., do not require the use of the mouse only).
Content and functionality that is provided through scripting must be made accessible to assistive technologies.
Web pages that utilize scripting must be fully navigable using a keyboard.
JavaScript should not modify or override normal browser functionality in a way that may cause confusion.
When JavaScript cannot be made natively accessible, an accessible alternative must be provided.

Comparison of JavaScript Guidelines

Section 508 of the Rehabilitation Act (in the United States) and the W3C Web Content Accessibility Guidelines (WCAG) 1.0 both address the accessibility of scripting elements. They require that the functionality and content of scripts be accessible to assistive technologies such as screen readers. Additionally, users must be given control over time-based content changes. There are, however, differences between the two accessibility guidelines. WCAG requires that content and functionality be accessible with scripting disabled and that users should be alerted if JavaScript changes the appearance or functionality of the browser window, whereas Section 508 only requires that the scripting be made accessible or that an accessible alternative is provided.

Testing for JavaScript Reliance

As mentioned above, your web pages should be fully functional with JavaScript disabled. This is required under Priority 1 of the Web Content Accessibility Guidelines. Section 508 does not require the page to function if JavaScript is disabled, but does require that the scripts themselves be natively accessible. This tutorial will teach strategies for making your scipts natively accessible and assumes that if you, as a developer, want to achieve a higher level of accessibility or comply with the Web Content Accessibility Guidelines, that you will also test your pages to ensure that they work with JavaScript disabled.

Disabling JavaScript

Follow the directions to disable or enable JavaScript in your browser. You can also determine if JavaScript is disabled. Test a JavaScript enabled web page and see if the content and functionality are accessible. Be sure to re-enable JavaScript when you're done.
Internet Explorer 6.X

Open Internet Explorer.
Select Tools > Internet Options.
In Internet Options dialog box select the Security tab.
Click Custom Level button at bottom. The Security Settings dialog box will pop up.
Under the Scripting category, enable/disable Active Scripting, Allow paste options via script and Scripting of Java applets.
Click OK twice to close out.
Click Refresh.

Netscape 7.X

Open Netscape.
Select Edit > Preferences.
Click the arrow next to Advanced.
Click Scripts & Plugins.
Check/uncheck Navigator beneath "Enable Javascript for".
Click OK.
Click Reload.

Opera 7.X

Open Opera.
Select File > Quick Preferences.
Check/uncheck Enable Javascript.
Click Reload.

Overview

JavaScript can be processed using <script> elements and event handlers. The <script> element can contain JavaScript code directly:


<script type="text/javascript">
  <!--
  function doit();
  -->
</script>

or can open an external JavaScript (.js) file:


<script type="text/javascript" src="scripts.js">

The <script> element is processed when the page is loaded and requires no user intervention. The contents and functionality of the script processed within the <script> element must be directly accessible or an accessible alternative of the content and functionality must be provided.
Event handlers accompany existing HTML code and are triggered by a browser or user event - such as when the page loads, when the user clicks the mouse, or when the time is 8 p.m. Some event handlers are dependent upon use of a mouse or keyboard. These are called device dependent event handlers. Other event handlers are device independent and are triggered by both the mouse and keyboard or by other means. Using device dependent event handlers may cause the content to be inaccessible to someone that is not able to use the device that is required for that specific event handler.

`onMouseOver` and `onMouseOut`

The onMouseOver event handler is triggered when the mouse cursor is placed over an item. As its name implies, onMouseOver requires the use of a mouse, thus it is a device dependent event handler and may cause accessibility issues. onMouseOver, and its companion, onMouseOut, can be used, as long as any important content or functionality is also available without using the mouse.

Example 1

Place your mouse over the following image to see an example of onMouseOver. When the mouse is placed over the image of the word "Accessibility", another image appears in its place which presents the definition of the word "Accessibility".


<a href="page.htm" onmouseover="document.images['myimage'].src='imageoff.gif';" onmouseout="document.images['myimage'].src='imageon.gif';">
<img
 src="media/imageoff.gif" width="289" height="79" id="myimage" 
alt="Accessibility - The quality of being accessible, or of admitting 
approach; receptibility." />
</a>

Important
All of the examples in this lesson are coded to be XHTML 1.0 Strict compliant. XHTML requires lower-case event handler names (e.g., onmouseover instead of onMouseOver).

Try navigating to the image using the keyboard. Notice that the additional information does not display. The alternative text for the image provides the content displayed using the onmouseover event handler. This allows users who know how to access this alternative text to get the content, but is not a truly universal solution.

Problems

In this example, additional content is being displayed using onMouseOver. This content can only be viewed if the user uses a mouse to hover over the image. It is not available to someone who is using the keyboard to navigate through the page. The onMouseOver event handler cannot be made directly accessible to keyboard users. Thus, an alternative must be provided.

Partial Solution

Place the additional content in the alternative text of the image itself. This would work for screen reader users - the screen reader would read the alternative text. But for sighted users whose browser does not display alternative text for images or who do not know to mouse over the image to see the alternative text, this is not a viable alternative. Still, the image must have equivalent alternative text.

Solutions

In addition to onMouseOver and onMouseOut, use onFocus and onBlur. These actions will be triggered when the keyboard is used to navigate to and from a link that surrounds the <img> element.


<a href="page.htm"
onmouseover="document.images['myimage'].src='imageon.gif';" onfocus="document.images['myimage'].src='imageon.gif';"
onmouseout="document.images['myimage'].src='imageoff.gif';" onblur="document.images['myimage'].src
 = 'imageoff.gif';">

<img src="imageoff.gif" width="289" height="79" id="myimage" 
alt="Accessibility - The quality of being accessible, or of admitting 
approach; receptibility." /></a>

You must still provide the descriptive alternative text for non-visual users, but onFocus and onBlur will provide the visual image swap for users that are using a keyboard only.

Example 2

A common use of onMouseOver and onMouseOut is for fly-out or drop-down navigation systems. Place your mouse over the menu items below to view an example of drop-down menus. When the mouse is placed over the main menu items (onMouseOver), additional sub-menu items appear below. When the mouse is removed from the menu system (onMouseOut), then the sub-menus disappear.

Products

Services

Support

Problems

Additional content and functionality is being displayed using onMouseOver. In this example, JavaScript is controlling the display of Cascading Style Sheet elements within the page. The sub-menu items will only be visible if the mouse is placed over the main menu item. These items may not be available if JavaScript is disabled and may not be read by assistive technologies.

Solutions

When possible, use additional event handlers that allow keyboard navigation. When this is not possible, you must provide redundant navigation. This can be done one of two ways. First, provide links within the main content of the page to the pages displayed in the sub-menu navigation. This is often done as a list of categorized links at the bottom of the page. The downside of this approach is that the navigation is only accessible at the bottom of the page, which might be counter-intuitive to most users.
A second method of providing the redundant navigation is to add a standard href link from each main navigation items (e.g., Product, Services, etc.) to a separate web page that contains the sub-menu navigation items. If you select the Products, Services, or Support links above you will see an example of providing redundant navigation.

Example


<a href="productlinks.htm" onmouseover="SlideOutMenu();" onmouseout="SlideInMenu();">Products</a>

While this method does require the creation of an additional page and introduces an additional step, it also provides full access to the navigation elements in an intuitive way. This method also allows the sub-menu items to be accessible if JavaScript is disabled.

`onFocus` and `onBlur`

These event handlers are typically used with form elements, such as text fields, radio buttons, and submit buttons. onFocus is triggered when the cursor is placed on or within a specific form element. onBlur is triggered when the cursor leaves a form element.
Both of these event handlers are device independent, meaning that they can be performed with the mouse, keyboard, or other assistive technology. The actions that are performed as a result of these event handlers must be analyzed to determine if they cause accessibility problems. Typically, these events do not cause accessibility issues unless they are modifying the default behavior of the web browser or are interfering with keyboard navigation within the web page.

Example 1

Place your cursor within the following textbox to see an example of the onFocus event handler.
Enter your name :


<input id="fname" type="text" onfocus="alert('Enter your first name only');" />

Problems

None. Although the alert window may be distracting and unnecessary, it does not introduce any serious accessibility issues. The alert is triggered when the text box gains focus, either by using the keyboard or mouse. JavaScript alerts are read by most modern screen readers and can be used to increase the usability of forms by providing timely feedback, instructions, or cues. However, if JavaScript is disabled, then the alert will not be available at all.

Example 2

In this example, the onBlur event triggers JavaScript code that changes the functionality of the Web browser. Place your mouse into the following text box and enter a number between 1 and 10. Then press the Tab key or click the mouse outside of the text box to trigger the onBlur event which will validate the number you entered to ensure it is correct and present feedback regarding your answer. If it is incorrect, the text box will retain the cursor focus until you enter the correct number. In this example, you MUST enter the correct answer of '6' to allow the browser to navigate to other portions of the page.
Guess a number between 1 and 10?
Enter Answer:


<input type="text" id="input1" size="5" onblur="checkAnswer();">

Problems

Although the onblur event is device independent, it is being used to execute JavaScript code that makes the page difficult to navigate. The textbox maintains focus until the correct answer is given. This change in browser default behavior may be confusing and restricting. Also, the feedback is displayed in a different part of the page. Because focus is maintained within the text box, a screen reader will not be able to access the feedback text or any other part of the page until the correct answer is entered.

Solution

Do not force the focus to remain within the text box. Allow the user to navigate throughout the page. Display the feedback on another page after the form has been submitted (works without JavaScript) or display the feedback with a JavaScript alert (requires JavaScript). Try entering a letter into the textbox above to see a JavaScript alert feedback message.

`onClick` and `onDblClick`

The onClick event handler is triggered when the mouse is pressed when over an HTML element. onClick is intended to be a mouse dependent event handler. However, if the onClick event handler is used with hypertext links or form controls, then most major browsers and assistive technologies trigger onClick if the Enter key is pressed when the link or control has focus. In these cases, onClick is a device independent event handler. Nevertheless, the Enter key will not trigger the onClick event if it is used with non-link and non-control elements, such as plain text or table cells.
The onDblClick event handler is associated with the double click of a mouse on a selected HTML element. There is no device independent or keyboard equivalent to onDblClick, which should be avoided.

Example 1

The following link triggers a JavaScript confirmation box which allows you to confirm whether you want to view the page or not.
View this onClick example


<a href="page.htm" onclick="return confirm('Are you sure you want to view this page?');">View this onClick example</a>

Problems

None. The confirmation box is read by all major screen readers. By using the return JavaScript parameter, the link action is cancelled if the user selects No in the confirmation dialog box. If JavaScript is disabled, the link will work normally.

Example 2

The following text is styled to appear like a link (blue and underlined), but is plain text that has an onClick event which opens another document in the browser window. Use the mouse to click the following text.

View another onClick example


<p style="color:blue; text-decoration:underline" onclick="location.href='page.htm'">View another onClick example</p>

Problems

Because the text is not a hypertext link or form control, it does not receive focus while navigating with the keyboard. Because it does not gain focus, the keyboard cannot be used to activate the onClick event.

Solution

Use the onClick event handler on a link or form control instead of an element that cannot be accessed using a keyboard.

Example 3

A very common use of JavaScript is to validate form information. The following form will use JavaScript to allow you to confirm the information you have entered.
Enter your name in the following box, then press the Submit button.


<form action="page.htm" onsubmit="validate(); return false;">

<p><label for="yourname">Name:</label><input type="text" id="yourname" />

<input type="button" value="Submit" onclick="validate();" /></p>

</form>

Problems

The confirmation and alert dialog boxes that are triggered by the onClick event are accessible to browsers and assistive technologies that have JavaScript enabled. Validating the form information with a server side script and then displaying feedback on another web page allows you to bypass any problems that may occur in the JavaScript code and allows the form to validate if JavaScript is disabled. If JavaScript is used to validate the form, make sure that all form elements and functionality can be completed using the keyboard. Because the onClick handler is used with a form element, it is activated using both the mouse and the keyboard.

Note
Because most browsers will submit the form when the Enter key is pressed, the onsubmit event handler has been added to the <form> tag to ensure that the form will validate if the user does not activate the Submit button, but presses the Enter key while focus is in the text box. Also notice the required form label for the text box.

Example 4

This example also validates the form information, but feedback is displayed in another place within the page.
How many items are in a dozen? Enter the amount into the box below, then press the Check button.


<form action="page.htm" onsubmit="checkAnswer2(); return false;">

<p class="invis" id="answercorrect">Correct, there are 12 items in a dozen.</p>

<p class="invis" id="answerwrong">Incorrect. There are 12 items in a dozen.</p>

<p><label for="answerbox">Enter Answer:</label>

<input type="text" id="answerbox" />

<input type="submit" onclick="checkAnswer2()" value="Check" />

</p>

</form>

Problems

The feedback is not presented in a manner that would be accessible to some assistive technologies. In this example, JavaScript is modifying the display style parameters for elements within the page to make them visible or invisible based upon the response. The screen reader user would not be aware that additional content has suddenly appeared within the page.

Solutions

Validate the form information with a server side script, then display the feedback on another page.
Provide the feedback in a way that is accessible, such as a JavaScript alert or another form element.

`onChange` and `onSelect`

The onChange event handler is triggered when a form element is selected and changed (for example, when a radio button is initially selected or when the text changes within a text box). The onSelect event handler is processed when text is selected within a text field or text area. Although these event handlers are device independent and can be activated using the mouse, keyboard, or other device, the actions that are performed as a result of these event handlers must be analyzed to determine if they cause accessibility problems.

`onChange` example

The following drop-down menu form element is used for navigation. By selecting an item from the list, JavaScript will automatically open the specified page within the browser.

Note
In some browsers you may have to hit the Enter key or click on the page after selecting a menu item to activate the onchange event handler. Click on the Back button in the browser to return to this page.


<script type="text/javascript">

<!--
  

  function goto_URL(object) {

  window.location.href = object.options[object.selectedIndex].value;
  }

  //-->

  </script>

  

  <form action="page.htm" onsubmit="return false;">

  <p><label for="selectPage">Go to:</label>

  <select name="selectName" onchange="goto_URL(this.form.selectName)">

  <option value="">Select a page:</option>

  <option value="page.htm">Page 1</option>

  <option value="page.htm">Page 2</option>

  <option value="page.htm">Page 3</option>

  </select></p>

  </form>

Problems

The JavaScript causes the browser to go to a new page using onChange or when the user selects an item from the select list. If the end user is using a keyboard, the onChange event handler is executed for every item within the list. It is impossible for the user to directly select the last item in the list, as each previous item within the list will trigger the page change. The only way the user can select the last menu item is by navigating to the page for the first item in the list, then pressing the Back button, navigating to the second item, then pressing the Back button, and so forth until the last menu item is accessed.

Solutions

Rather than using the onChange event handler, allow the user to select the item from a list then select a button or submit the form to activate the script. When server-side scripting is used to process the form information and redirect the browser accordingly, there is no need for JavaScript at all. The following code demonstrates one method of fixing the onChange problem.
Select a page using the drop-down menu then select the Go! button. Click on the Back button in the browser to return to this page.


      <form action="page.htm" onsubmit="return false;">
 
      <p><label for="selectPage2">Go to:</label>
   
      <select name="selectPage2" id="selectPage2">
   
      <option value="">Select a page:</option>
   
      <option value="page.htm">Page 1</option>
   
      <option value="page.htm">Page 2</option>
   
      <option value="page.htm">Page 3</option>
   
      </select>
   
      <input type="button" value="Go!" onclick="goto_URL(this.form.selectPage2);" />
 
      </p>

      </form>

Using Device Independent Event Handlers

As mentioned previously, several event handlers are device independent, including onFocus, onBlur, onSelect, onChange, and onClick (when onClick is used with link or form elements). When possible, use device independent event handlers. Other event handlers are device dependent, meaning that they rely wholly upon a certain type of input. For instance, onMouseOver, onMouseOut, and onDblClick rely upon the use of a mouse. There are also some event handlers that are dependent upon use of the keyboard (onKeyDown, onKeyUp, etc.). Multiple device dependent event handlers can be used together to allow both mouse and keyboard activation of JavaScript. For instance, both onMouseOver and onFocus (as well as onMouseOut and onBlur) can be used to provide both keyboard and mouse activation of a script. Using multiple device dependent event handlers together as a method of implementing device independence requires a great deal of testing across different browsers and assistive technologies to ensure that accessibility is not limited in any way.

Dynamic HTML and Accessibility

Dynamic HTML (DHTML) is typically a combination of Cascading Style Sheets (CSS) and JavaScript. DHTML allows developers to display, hide, or move information based upon input from the user or pre-programmed commands. Many of the examples in this section have used DHTML. Most drop-down or fly-out menu systems found on Web pages also use DHTML. Because most of these DHTML elements are modified based upon mouse input, they are typically inaccessible to users who do not use a mouse. When DHTML is used, two items must be evaluated to determine its impact on accessibility:

Is the event used to trigger a change device independent? If the mouse is required, then it is not fully accessible.
Is the DHTML content or functionality itself accessible? If assistive technologies cannot adequately access DHTML triggered content or functionality, then it is not fully accessible.

Using `document.write`

Dynamic, constantly changing information is being written to the page in this example using the document.write command in JavaScript. In most cases, content that is written to the page using JavaScript is accessible to assistive technologies. However, if the dynamic content is constantly changing or otherwise interferes with navigation or browser functionality, then it may cause accessibility problems.

`document.write` example

The current time is displayed in the text box below. It updates and changes every second.

The current time is:

Problems

In this case, because the content is constantly changing and refreshing, a screen reader would not be able to read it and it may cause some confusion.

Solutions

When using dynamic information, you must first ask yourself if it is necessary and vital to the function or content of the page. If so, there is often a way to provide the content without using inaccessible JavaScript. For instance, you could write the current time to the page when it loads using a server-side script. Though it will not be constantly updating, it may suffice. You may also have the user select a link or button to go to another page that displays the current time from server side processing. Another approach that uses a more accessible implementation of JavaScript would be to provide a link or button that allows the user to display the current time at their request.


<input type="button" 

value="Display the current time"


onclick="alert('The current time is ' + timeValue);" />

Pop-up Windows

Pop-up windows provide a unique accessibility problem. First of all, most usability experts would argue against the use of pop-up windows except in the most extreme of cases. If you must use pop-up windows, know that they introduce several very unique accessibility issues. For a visual user, it may be difficult to notice and navigate to the new window. For someone who is using assistive technologies, the new window may be annoying and confusing because the default behavior for the link has been modified. JavaScript implementation may make the new window difficult or impossible to resize or scale for someone using a screen enlarger. For someone who is blind, there is typically no indication that they are presently navigating in a new window. When the screen reader user attempts to return to the previous page by selecting the back button, it may be confusing to find that this does not work.

Pop-up example

Select this link to open a new window


<a href="popup.htm" 

onclick="window.open(this.href); return false;">Select this...</a>

Note
If you are using software to block pop-up windows, you may need disable the software or select the link in a way that bypasses the pop-up blocker (typically Ctrl + click or Ctrl + Enter with the link selected).

In the example code above, the link will continue to work normally (i.e., in the same browser window) if JavaScript is disabled.
When using JavaScript to open new windows, you can modify the size and position of the new window. You can also add or remove functionality of the window, such as the ability to resize, display scroll bars, show tool bars, etc. Be very careful when changing the default behavior of the browser window. If a user has low vision and must enlarge the content, a small window that cannot be enlarged and does not display scroll bars would be very inaccessible. Someone with a motor disability may rely upon large tool bars to accurately control the web browser, so removing or modifying them may introduce difficulties for this user.
As you can see, there are many difficulties in both usability and accessibility that arise through the use of pop-up windows. Care must be taken in making the decision to use them. If they are used, thorough user testing of your implementation is vital to ensure accessibility. Always alert the user to the fact that a pop-up window will be opened.

Redirecting and Refreshing Browser Windows

When the page the browser is viewing suddenly changes or refreshes, the person viewing that page may become disoriented or confused, especially if that person is using an assistive technology. This is commonly done with page redirects when page content has been moved or updated. Section 508 requires that users be given control over time sensitive content changes. Do not automatically change or refresh the browser window without first alerting the user that the change will occur and giving him/her the ability to disable or postpone the change.

Using Pure CSS as a JavaScript Alternative

As mentioned previously, Cascading Style Sheet (CSS) parameters are often modified using JavaScript to create dynamically changing DHTML pages. However, with the advent of CSS version 2, much of the dynamic functionality available with JavaScript is now contained within the specifications for CSS itself. This allows the construction of interactive and dynamic navigation and layout elements without the need for JavaScript events. You can create drop-down menus, interactive images, and other exciting features in Web sites without worrying about device dependent event handlers. However, the new CSS standards are not fully supported in modern browsers, namely Internet Explorer.
Also, screen readers do not have great CSS support, especially when presented with content that can be made visible or invisible using either the display:none or visibility:hidden styles. Many screen readers do not read content that is assigned these styles even though the content is still part of the underlying structure of the page. Until there is better CSS support in both web browsers and assistive technologies, using CSS alone to produce dynamic content should only employed with much testing in a variety of browsers and screen readers.

Introduction

Whenever JavaScript cannot be made directly accessible, an accessible alternative must be provided. Also, many user agents, such as web-enabled cell phones and PDA's, do not yet utilize JavaScript. There are several ways you can provide accessible alternatives when the scripting cannot be made accessible or when the end user does not have JavaScript enabled.

Server-side Processing

In many cases, the functionality provided by JavaScript can be duplicated by server-side scripting. For example, JavaScript is often used to validate form elements before a form is posted. Instead of implementing such JavaScript programming and its accompanying accessibility techniques, you could use a server-side script to validate the form elements. JavaScript is often used to write dynamic information to a web page, such as the current date and/or time. Again, using a server script or server-side include negates the need for additional accessibility implementation.

Using the `<noscript>` Element

Making JavaScript natively accessible is very important. However, in some cases, the end user may not have JavaScript enabled or may be using technologies that do not support JavaScript (e.g., cell phone, PDA, etc.). In such cases, you can provide non-JavaScript alternatives to user's who cannot or choose not to view JavaScript content.
When JavaScript is used within a Web page, the most straightforward way to provide an alternative for the JavaScript-generated content is to provide content within the <noscript> element. The <noscript> element can be used within your page to display content in browsers that do not support or have disabled JavaScript. However, if JavaScript IS enabled the <noscript> element is ignored.

Important
Providing an accessible alternative within the <noscript> element for an inaccessible script will not make the page accessible. The <noscript> content will only display if JavaScript is disabled. Most screen reader users have JavaScript enabled, and will thus encounter your inaccessible script and not the <noscript> content.

The <noscript> element provides alternative text for the JavaScript. If the content or functionality of the script needs an accessible alternative when JavaScript is disabled, then you need <noscript>. The <noscript> content should ideally contain the equivalent content or functionality that is provided by the script. However, this is often not possible. It is not sufficient to simply indicate, "Your browser does not support JavaScript." This does nothing to make the content accessible. You may, for example, provide a link to an accessible HTML alternative or to a page that utilizes server-side scripting instead. Or, at very least, describe the type of content that would be displayed if JavaScript were enabled.
<noscript> should be used anytime alternative or non-javascript content or functionality is required.


    <script type="text/javascript">
  
    <!-- document.write("The current time is " + currenttime) -->

    </script>

    <noscript>
  
    <!-- link to page that displays time from server-side script -->
  
    <a href="time.htm">View the current time</a>

    </noscript>

`<noscript>` example

In the following example, two form buttons are provided within the HTML code. If you have JavaScript enabled, the document.write command within the <script> element will display the first button. If this button is selected, it triggers a JavaScript function that may be used to validate and submit the form using additional JavaScript within the page. If JavaScript is not enabled, then the button contained within the <noscript> element is displayed, which could submit the form to a server-side processing script, which would provide the form validation and feedback.


     <script type="text/javascript">
   
     <!--
  
     document.write('<input type="button" value="Submit" onclick="validateForm();" />');
   
     -->

     </script>

     <noscript>

<p>
 
<input type="submit" value="Submit">
  
</p>

</noscript>

Overview

JavaScript allows developers to add increased interaction, information processing, and control in web-based content. JavaScript can also cause accessibility problems by limiting navigation using a keyboard or assistive technology, presenting content or functionality that is not accessible to assistive technologies, limiting user control over automated content changes, and modifying the normal functionality of the browser. When faced with JavaScript accessibility issues, you must do one of the following:

Ensure the JavaScript is directly accessible
Provide an accessible, non-JavaScript alternative

JavaScript is often used to make cosmetic or other content changes that do not affect accessibility. Content written to the page using JavaScript is accessible if:

Device independent event handlers are used.
JavaScript enabled content and functionality is accessible to assistive technologies.
Scripted pages and elements are navigable using a keyboard.
The normal browser functionality is not modified in a way that may cause confusion or inaccessibility.
An accessible alternative is provided when JavaScript cannot be made natively accessible.

JavaScript Event Handlers

There are two types of JavaScript event handlers - device dependent and device independent. When implementing event handlers, you must either use a device independent event handler or use multiple device dependent event handlers to accommodate all users. Below is a list of common event handlers and their associated accessibility issues.

onMouseOver and onMouseOut: Device dependent (require the use of a mouse); Ensure important content or functionality is not introduced with these event handlers; Use in conjunction with the onFocus and onBlur event handlers to allow keyboard accessibility; Provide an accessible alternative if the content or functionality cannot be made natively accessible
onFocus and onBlur: Device independent (work with both keyboard and mouse); Test to ensure that accessibility is not affected
onClick and onDblClick: Device dependent (require the use of a mouse); onClick is activated by keyboard input when used with links and form elements; There are no device independent or keyboard accessible equivalents to these event handlers; Functionality and content provide by the onClick event handler must also be made accessible
onChange and onSelect: Device independent (work with both keyboard and mouse); Functionality and content provide by the onChange and onSelect event handlers must also be made accessible; Drop-down menu navigation items that are triggered with onChange are not fully keyboard accessible

Dynamic HTML and Accessibility

Dynamic HTML (DHTML) is a combination of JavaScript and Cascading Style Sheets (CSS). By its very nature, DHTML can present dynamically changing content. DHTML is often triggered by user interactions, such as moving the mouse. When implementing DHTML, you must ensure that the DHTML is triggered in a device independent way and that the content and functionality provided by the DHTML is also accessible.
JavaScript can also be used to write dynamic content to the web page. In most cases, this content is accessible, unless the content is constantly changing or is in any other way interfering with accessibility of the page.

Pop-up Windows

The default behavior of the web browser and certain HTML elements can also be affected by JavaScript. Pop-up windows can be triggered by JavaScript or by JavaScript event handlers. If the user is not alerted to the fact that a pop-up window is opening, they may become confused or disoriented by the unnatural behavior of the Web browser. Further modification of browser windows to remove scroll bars, status bars, menu bars, or tool bars may also cause accessibility problems. Use pop-up windows with care and if they are used, always alert the user to this fact. The user must also be alerted when JavaScript is used to automatically perform browser functions, such as redirecting, refreshing, or automatic scrolling. In all cases, user testing and testing with assistive technologies can provide valuable feedback regarding accessibility of specific JavaScript implementations.

JavaScript Alternatives

There are many ways to provide alternatives to JavaScript. Newer versions of CSS allow much of the behavior of JavaScript to be replicated using CSS alone. Drop-down menus, navigation bars, and interactive images can all be developed without relying on JavaScript. However, the implementation of CSS across browsers and assistive technologies is varied and problematic. When JavaScript itself cannot be made natively accessible, you must provide an accessible alternative. This can be done by replicating or replacing the JavaScript behavior with server-side processing. You can also provide <noscript> content which will be accessible when JavaScript is disabled or not available to the end user.

Standards and Guidelines

The following standards and guidelines apply to JavaScript:

Section 508 of the Rehabilitation Act §1194.22:

(l): When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.
(n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
(p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

W3C Web Content Accessibility Guidelines (WCAG) 1.0:

6.3 (Priority 1): Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.
6.4 (Priority 2): For scripts and applets, ensure that event handlers are input device-independent.
6.5 (Priority 2): Ensure that dynamic content is accessible or provide an alternative presentation or page.
7.4 (Priority 2): Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages.
7.5 (Priority 2): Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects.
8.1 (Priority 2): Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies.
10.1 (Priority 2): Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user.

Getting Sourcey — native HTML5 Audio and video

2012-01-02T00:19:00.001-08:00

Hard perhaps to believe, but the world wide web began without an image element. That’s right, there was no way to include images as part of the content of a web page before Mosaic implemented them (here’s Marc Andreesen proposing the img element at the beginning of 1993). The img element ushered in the age of included content so the web browsers could now display gif, jpeg, and more recently PNG format images in a standard way, but that’s where matters stayed for more than a decade. While the non-standard embed element (ironically, now standardized in HTML5, and later standardized object element enabled developers to include audio, video, and interactive content, browsers did not implement native handling of these kinds of media — the actual rendering was left to plugins, like Flash (while the number of different commonly used plugins today is quite low, in the late 1990s there was an explosion of different plug in technologies.)
While HTML5 for the first time specifies a way of incorporating audio and video content via the mundanely named audio and video elements, the revolution in web content these bring is that browsers now no longer require plugins to play the content, rather they do so “natively”. Which has the advantage that users don’t need to download and install plugins, or keep them up to date. But there’s more to it than that. With plugin content, browsers effectively hand over a part of the browser window and say to the plugin — “ok, this is all yours, do your worst”. Which makes applying style to a video player (rounded corners, or adding a drop shadow, for instance) challenging, and effects like layering HTML based content over the top of plugin content a bit of a lottery.
HTML5 audio and video has been, in browser years, quickly adopted by all major browsers (we’ll cover off browser support in just a moment). But let’s first take a look at how we incorporate audio and video content into HTML5 documents, how to provide fallbacks for browsers which don’t support them, and the inevitable gotchas. And once again, I’ll introduce a couple of tools we’ve developed to make life easier for you when using native multimedia content in your web sites and applications.
There are a lot of great resources out there, which go into much more detail on some aspects we only really touch on here, particularly on the complex issue of formats and codecs, as well as the challenges of making your content accessible. There’s a list of further reading at the end of the article.
We’ll begin by looking at audio, and then follow up with video, which we use in almost exactly the same way as audio.

HTML5 Audio

HTML5 introduces the audio element, for embedding audio files in a page. Browsers which support HTML5 audio provide a simple audio player for playing, scrubbing forward and back through content, as well as setting the volume. It’s also possible to hide these controls, and either autoplay files, or build your own player interface using HTML and the audio element’s JavaScript API (which is beyond the scope of this article, but not really that difficult at all if you are competent in JavaScript).

Setting up the element

The first thing we need to do to include audio in a page is to add an audio element to the HTML. Unlike img, audio is a non empty element — that is it can contain other HTML, so has an opening and closing tag.

<audio></audio>

Of course, this isn’t going to play anything, just as an img element with no src attribute won’t display an image. So, you’re probably guessing we add the audio file reference using a src attribute. And you’re more or less right. We can do that, but there is another, better way to add a reference to the sound files we want to play. This is because the audio element can have only one src attribute, but because different browsers support different audio formats, at least for now, and for the foreseeable future, we’ll need to provide browsers with multiple sound files, so that we cover all browser bases. We’ll turn to how we do this in a moment, but let’s first look at several other attributes the audio element can take.

controls: The controls attribute, when present, tells a browser to display the default controls for its audio player. If the attribute is not present, then no controls will be displayed.
loop: another boolean attribute, if this is present, the audio file will begin again after it has played indefinitely
autoplay: if this attribute is present, then once the sound file can begin playing, it will. autoplay should be used carefully and sparingly!
autobuffer: this is now replaced with the preload attribute which we’ll look at in a moment, but as older browsers, for example Safari 4 support autobuffer instead of preload, you may wish to add this attribute as well if you want audio to be buffered by the browser as soon as a page is loaded. Browsers may choose to ignore this, or not support it at all (Opera for example doesn’t support preloading of audio)

Before we continue, these attributes are boolean attributes, which you might not necessarily be as familiar with as you are regular attributes. Boolean attributes (another exampled is checked) are either true, or false, depending on whether they are present or absent on an element. So, they look like this

<audio controls loop></audio>

That is, they don’t take values. If this offends your XHTML sensibilities, they can also be written like so

<audio controls="controls" loop="loop"></audio>

That is, with their name as their value as well. Why they aren’t written as controls=“true” is beyond me, but there you have it.
In addition to these boolean attributes, and the src attribute (which we’ve recommended ignoring) audio can also take the preload attribute, which has one of three values. The preload attribute doesn’t force the browser to preload an audio file, but rather, suggests to the browser how it can provide the best user experience to the user (balancing the impact of downloading a potentially large file, with the benefit of faster response to their choosing to play a file). In the words of the specification, these values are

none: Hints to the user agent that either the author does not expect the user to need the media resource, or that the server wants to minimise unnecessary traffic.
metadata: Hints to the user agent that the author does not expect the user to need the media resource, but that fetching the resource metadata (dimensions, first frame, track list, duration, etc) is reasonable.
auto: Hints to the user agent that the user agent can put the user’s needs first without risk to the server, up to and including optimistically downloading the entire resource.

Getting Sourcey

Having suggested we don’t use the src attribute to link to the audio file to be played, how then can we do this? Well, we saw audio elements can contain other HTML elements, and in this case, we’re going to use the source element (also new in HTML5), to provide links to one or more audio files in various formats. The browser can then download the format it supports, ignoring others to save bandwidth.
Like img, the source element uses the src attribute to link to a file. So, if we want to link to an mp3 file, we do so like this

<source src="http://westciv.com/podcasts/youmayknowmypoetry.mp3">

and, if we put that all together, that’s all we need to play this file in browsers which support mp3 (at present, IE9, Safari, Chrome, Android and iOS).

<audio controls="controls" loop="loop">
 <source src="http://westciv.com/podcasts/youmayknowmypoetry.mp3">
</audio>

While several browsers will be able to play this content, neither Firefox nor Opera support the mp3 format natively. They both however, support the Ogg Vorbis format, so in addition, we’ll link to an ogg version of this same audio file, for the benefit of users of these browsers.

<audio controls="controls" loop="loop">
 <source src="http://westciv.com/podcasts/youmayknowmypoetry.mp3">
 <source src="http://westciv.com/podcasts/youmayknowmypoetry.ogg">
</audio>

Where a browser happens to support both ogg and mp3, it will use the first source it finds which it supports, and so in this case, play the mp3 version.
So now we have an audio element, with two sources, which provide audio that can be played in all modern browsers. But what about older browsers? Can we also include support for them? Let’s find out.
As an aside, beneath the seemingly simple issue of audio and video formats, there’s more than a little complexity. We’ll look at this whole issue separately in the gotchas section, but I’ll just note here, that we can give the browser further information about the file, including it’s MIME type, and a specific codec to be used to decode it using the type attribute. This can further help a browser in deciding whether to download a file — audio and video files are typically large, so browsers really should only download files they can very likely play. For now, just note we have the type attribute, which may be useful, for example, to distinguish between audio files of the same format encoded at different bitrates.

Providing fallbacks

Because we’ve long been able to embed audio and video in a web page using Flash (or Silverlight, and other audio playing plugin technologies), we can use this to provide a fallback player for audio content. There’s two approaches to this (for simplicity, we’ll only consider the case of Flash, but a similar approach can be used with Silverlight).

We use the object element to link to a .swf version of our audio file, which Flash can play
We use object to embed a Flash audio player which can play mp3 files

The first approach is simplest, but Flash won’t display controls for the sound file — the user will have to context menu click to play, rewind, etc.
The second approach potentially involves hosting an audio player at your site, or using a free hosted player such as the Google Reader Audio Player, but has the advantage of reducing the number of audio files we need to encode, and of providing a better user experience.
In both cases, we use the object element, as the only browser we really need to worry about is Internet Explorer versions 8 and older, which support object. Unless you’re looking to also cover an old version of a browser that doesn’t support object (which to be honest is unlikely), there’s no need to also include a nested embed element inside the object.
Here’s how we go about using the object element to add the Google Reader player, and our sound file.

<object type="application/x-shockwave-flash" data="http://www.google.com/reader/ui/3523697345-audio-player.swf" width="400" height="27" >
        <param name="flashvars" value="audioUrl=http://westciv.com/podcasts/youmayknowmypoetry.mp3">
        <param name="src" value="http://www.google.com/reader/ui/3523697345-audio-player.swf"/>
        <param name="quality" value="best"/>
</object>

There’s no great need to go into detail here, because all you really need to know is the value of the flashvars parameter includes the URL of the sound file. Simply replace the URL there, leaving the audioURL= part as is, and you’ll be fine.
Note that this fallback won’t work if the browser supports audio, but none of the audio formats you’ve linked to, or if the files go missing. The browser in these instances will show the native audio player controls (if you’ve used the controls attribute), but no sound will be played.
Lastly, what if we have a browser that supports neither audio, nor the object element? We can include fallback text (and HTML) within the object element (or if we choose not to include a flash based fallback, inside the audio element, after any source elements). We could for example link to a downloadable version of the file. Here’s what this would look like if we haven’t included a Flash based fallback

<audio controls="controls" loop="loop">
 <source src="http://westciv.com/podcasts/youmayknowmypoetry.mp3">
 <source src="http://westciv.com/podcasts/youmayknowmypoetry.ogg">

 <p>Sadly your browser can't play this audio file</p>
 <p>The good news is you can still <a href="http://westciv.com/podcasts/youmayknowmypoetry.mp">download an MP3 version</a></p>
</audio>

Gotchas

We’ve covered most of the things that can trip you up with audio (with the exception of the whole issue of formats and codecs which we’ll cover shortly) but keep in mind these as well:

fallbacks only come into play if the audio element is not supported, not if the file formats aren’t or if the files are missing.
ogg files must be served as audio/ogg or application/ogg. If the server is set up to serve these as another MIME type, Firefox will ignore them.
Fallback text is not for the purposes of accessibility, but as a last resort when audio is not supported (we’ll look at accessibility in a moment).

But, on the whole, HTML5 audio is not particularly complicated, and in my opinion far less of a headache than using plugin based audio with the object and embed elements. As I mentioned earlier, I’ve built a web based tool that helps you create audio elements, including fallbacks, and hopefully helps you understand exactly what’s going on. Let me know what you think

HTML5 Video

Let’s now turn to incorporating video in HTML5 documents, and the good news is, it’s more or less identical to audio. Where audio and video are the same, we won’t repeat what we’ve covered earlier.

Adding the element

In place of the audio element, for video we have, not surprisingly, the video element. As with audio, we recommend you don’t use the src attribute to link to the video file, but again the source element, so we can link to different formats (as with audio, different browsers support different formats, so to cover all modern browsers we need at least two different video files).
video elements can take all the attributes of the audio element — controls, loop, autoplay and preload. But in addition, it can also take the poster attribute. The value of the poster is a url that specifies a file to be used as a placeholder image when video is not playing. Here’s a video element, with controls, and a poster

<video controls="controls" poster="http://westciv.com/podcasts/lesson6.jpg">
</video>

and while this won’t play any video, it will look impressive, something like this

Adding sources

Now we need to specify the video files to be played. As with audio, we use the source element, with the src attribute pointing to the video file to be played. To cover modern browsers, we need at least two formats, to simplify considerably, h.264 and either ogg/theora or webM/VP8.

<video controls="controls" poster="http://westciv.com/podcasts/lesson6.jpg">
 <source src="http://westciv.com/podcasts/lesson6.mp4">
 <source src="http://westciv.com/podcasts/lesson6.ogv">
</video>

Which now gives us video which will play in almost any modern browser, including IE9. again, we’re going to add fallbacks much as we did for audio, to round out our coverage.

Providing fallbacks

The simplest way to add Flash based fallback video content is to create a .swf version of the file, and then embed this in your HTML document using the object element. If Flash is installed this will play in the user’s browser, and while no controls will be shown, if you add a menu parameter with the value of true, then the user can context menu click and play, rewind and otherwise control the video.

<object type="application/x-shockwave-flash" data="http://westciv.com/podcasts/lesson6.swf" width="320" height="400">
    <param name="movie" value="http://westciv.com/podcasts/lesson6.swf">
    <param name="menu" value="true">
  </object>

All we need to concern ourselves with here is that we put the url of our video file as the value of the parameter with the name “movie”, as well as the data attribute of the object element.
There are also various Flash based video players we might include, similarly to the way we included the Google Reader MP3 player. This will likely require serving the Flash application, in addition to the video files.
Again we’ve used only the object element, as we’re really only looking to ensure IE 8 and older is served the video, and as these support object there’s no need to also include the embed element.
Lastly, as with audio, we can provide fallback text or HTML to display when video is not supported. Here, we’ll provide a download link when neither video nor Flash are supported.

<video controls="controls" poster="http://westciv.com/podcasts/lesson6.jpg">
 <source src="http://westciv.com/podcasts/lesson6.mp4">
 <source src="http://westciv.com/podcasts/lesson6.ogv">

 <object type="application/x-shockwave-flash" data="http://westciv.com/podcasts/lesson6.swf" width="320" height="400">
  <param name="movie" value="http://westciv.com/podcasts/lesson6.swf">
  <param name="menu" value="true">

  <p>Sadly your browser can't play this video file</p>
  <p>The good news is you can still <a href="http://westciv.com/podcasts/lesson6.mp4">download an MP4 version</a></p>

   </object>

</video>

Gotchas

HTML5 video gotchas are similar to those with audio. Fallbacks are only for when video is not supported at all. Ensure video files are served with the right MIME type. But on the whole, both audio and video are quite usable today.
As I’ve mentioned, the single biggest challenge is ensuring we serve the right video files, to ensure all browsers can play the video. Which means delving a little into the more complex issue of formats and encodings.

Video and Audio formats

Probably I should skip this part, and just point you in the direction of Mark Pilgrim’s fantastic coverage at Dive Into HTML5. But, I feel I should at least cover this issue briefly, so here goes.
When we think of video formats, like h.264, there are in fact 2 and usually 3 separate pieces of technology involved.

There’s the container file — for example MPEG4, WebM or Ogg
There’s the video data, encoded with one of many possible codecs (decoding/encoding formats) such as H.264, VP8 or Theora
There’s audio data encoded with one of many possible audio codecs such as mp3, AAC or Vorbis

So, when we talk about the video format a browser supports, it’s important to understand what this actually means. It means the combination of container, video and audio encoding.
With this in mind, The current state of browser support for audio and video formats is

Video

Firefox 3.6+, Chrome, Android 2.1+ and Opera support Ogg/Theora (.ogv).
IE9, Safari 4+, Chrome, Android and iOS support MPEG4/h.264 (.mp4), although Chrome 14 will drop support for the format.
Firefox 4+, Chrome, Opera, and Android (2.3+) support WebM/VP8 (.webm), as does IE9 if the required codecs are installed on the system (they can be downloaded from here)

So, to cover all modern browsers, we need at a minimum, MPEG4/h.264 and either Ogg/Theora or WebM/VP8

Audio

Firefox, Chrome, Android and Opera support Ogg/Vorbis (.ogg).
IE9, Safari, Chrome, Android and iOS support MP3 (.mp3).
Safari, Chrome, IE and iOS support AAC (.aac).

To cover all modern browsers, we need Ogg/Vorbis and either MP3 or AAC.

The `type` attribute

We mentioned earlier that the source element can take a type attribute in addition to the src attribute. While not required, this can help a browser decide whether it can actually play the content located at the end of the src URL. You might think that the file extension would be enough, but not necessarily so. For example, iPhone with iOS 4 supports H.264 video up to 720p (the so called H.264 “Main Profile”), so can’t play a 1020p H.264 encoded video (that is, a “High Profile” H.264 video). If we wanted to provide various H.264 profiles, for various devices, all these files will have the extension mp4. But we can provide codec information in the type attribute to differentiate between the various versions.
The type attribute’s value provides two pieces of information, separated by a semicolon. First is the MIME type of the file, then (optionally) the codecs used (separated by a comma). So, for example we could provide various H.264 profiles of our video like so:

<source src='video.mp4' type='video/mp4; codecs="avc1.58A01E, mp4a.40.2"'> <!-baseline profile-->
<source src='video.mp4' type='video/mp4; codecs="avc1.4D401E, mp4a.40.2"'>
<!-main profile-->
<source src='video.mp4' type='video/mp4; codecs="avc1.64001E, mp4a.40.2"'> <!-high profile-->

(Which to tell the truth is taken directly from the HTML5 specification, and is beyond my level of understanding of the ins and outs of codecs.), but depending on your circumstances, you may find it useful to include MIME type and codecs information using the type attribute. If you do, I’m sure you’ll know the codecs information to use, and now where to put it.

Accessibility

The web is about inclusivity and access to as wide an audience as possible, which includes those with hearing and visual disabilities. Creating accessible audio and video content is far beyond the scope of this article, but I do have some links for further reading below. But, it is important to note that, as spelt out in the HTML5 specification

In particular, [fallback] content is not intended to address accessibility concerns. To make video content accessible to the blind, deaf, and those with other physical or cognitive disabilities, authors are expected to provide alternative media streams and/or to embed accessibility aids (such as caption or subtitle tracks, audio description tracks, or sign-language overlays) into their media streams.

The tools

I’m not sure whether it’s stupidity, or laziness, but many aspects of web development, if I’ve not used a particular technology for a while, I quickly find myself reaching for a reference. And sadder still, it’s often the book I wrote myself! But in all seriousness, as aspects of CSS and HTML (not to mention JavaScript and the DOM) become increasingly complex, our chances of remembering every aspect of our craft, along with the subtleties of browser support, grow ever smaller (even Einstein was reputed to have said that he didn’t remember the speed of light as he could always look it up). Well, mine certainly do. So, I write little web based tools to replace my dwindling brain cells.
I’ve recently developed two new tools, one each for audio and video, that help you easily do pretty much all we’ve covered here — create the elements, add controls, a poster, and other attributes, sources, and fallback audio, video and HTML. It will even tell you which browsers can play a particular file (well, it will make a guess based on the files’ extensions).
You can find the audio tool here, and the video tool here.
There’s also a similar excellent tool for creating HTML5 video which I wasn’t aware of when creating mine, the Video for Everybody Generator. It’s highly recommended.

Taking your web sites and apps offline with the HTML5 appcache

2012-01-02T00:18:00.001-08:00

There’s a general (and understandable) belief by even many developers that web sites and web applications can only be used when the browser has a web connection. Indeed, this is routinely cited as one of the real advantages of “native” apps over web apps. But as unintuitive as it sounds, in almost every modern browser and device (except even for now IE10 developer previews, but here’s hoping that changes), that’s not the case, provided the developer does a little extra work to make their app or site persist when a browser is offline. (Of course the user must have visited your site while their browser did have a connection)
In this article, I hope to clear this whole areas up once and for all, show you how to do it, and point to some great resources out there for learning more about creating offline versions of your web sites and apps. Perhaps most importantly, introduce a simple new tool I’ve built to do the heavy lifting for you, ManifestR.
Even if you develop web sites, rather than applications, you can benefit from the techniques outlined here, because caching resources can seriously decrease the load time for your site, particularly on a visitors subsequent site visits.

Making a cache

As I’m sure you know, browsers cache HTML, CSS, JavaScript files, images and other resources of the sites you visit, to speed up the subsequent loading of pages. However, you never know when the browser might discard cached files, and so this is not a reliable way for sites to work offline. But what if we could tell the browser what to cache? Well, with HTML5 application caches (also known as applications caches or “appcaches”) we can do just that. Let’s look at how.

Making it manifest

The heart of the technique is to create an appcache manifest, a simple text file, which tells the browser what to cache (and also what not to). The resources are then cached in an “application cache”, or “appcache”, which is distinct from the cache a browser uses for its own purposes. The anatomy of an appcache manifest is straightforward, but there are a few subtleties.
An appcache manifest

begins with the string “CACHE MANIFEST” (this is required)
has a section, introduced by the string “CACHE:” which specifies the URLs of resources (either absolute, or relative to the location where the manifest file will be located on the server) to be cached.
We can also optionally specify which resources should not be cached, in a section of the manifest file introduced by the string “NETWORK:”. These resources aren’t just not cached, but further, won’t be used when the user is offline, even if the browser has cached them in its own caches.
We can also optionally specify fallback resources to be used when the user is not connected, in a section of the file called “FALLBACK:”
You can add comments to the file with, simply by beginning a line with “#”

It’s recommended that the extension for a manifest file is .appcache (previously, .manifest was the recommended extension).
Here is a very straightforward example

CACHE MANIFEST

CACHE:

#images
/images/image1.png
/images/image2.png

#pages
/pages/page1.html
/pages/page2.html

#CSS
/style/style.css

#scripts
/js/script.js

FALLBACK:
/ /offline.html

NETWORK:
signup.html

The CACHE section

In the CACHE section we list the resources we want cached. We can use either a URL relative to the .appcache file, or an absolute URL. We can cache resources both in the same domain as the cache, as well as (in most cases) other domains (we’ll cover this in more detail in a moment)
Often, the only section of an appcache manifest is this section, in which case, the CACHE: header may be omitted.
Be careful with what you cache. Once a resource, for example an HTML document is cached, the browser will continue to use this cached version, effectively forever, even if you change the file on the server. To ensure the browser updates the cache, you need to change the .appcache file. This can play havoc while you are developing a site, and we’ll cover some techniques for managing this in a moment.
One suggestion is to add a version, and or a date stamp to the manifest as a comment. This way, you can quickly change the date or version number, and then browsers will refresh the appcache. Browsers do this intelligently, checking to see which resources might have changed since they were last cached, and only re-caching those which have.

The Network Section

Probably the most subtle aspect of app caching is the NETWORK section. Because a great many web sites, and particularly applications, have dynamically generated content, pulled in from APIs, CGIs and so on, we may want to ensure certain resources aren’t cached, and are always directly loaded when the browser is online.
That’s where the NETWORK section of the cache comes in. Here, we list the resources we never want to be cached, which is referred to as an “online whitelist”. So, in our example above, we are specifying that the page signup.html (located at the root of our site — remember the entries in our manifest are either absolute or relative URLs) is never cached. When online, any request for this page will always cause the page to be loaded from the server (even if the browser might have previously cached it itself). When the user is offline, any request for this resource resuls in an error (again, even if the browser might have cached the resource in its own caches).
We can also specify a group of resources located within a site in the NETWORK section using a partial URL (technically a “prefix match pattern”) (note that we can’t use this technique in the CACHE section, where all resources must be explicitly listed to be cached in the appcache, with one exception we’ll get to shortly). Any resources which have URLs beginning with this pattern are included in the online whitelist, and never cached. As developers we then need to handle the cases where these resources aren’t available because the user is offline.
There’s also a special wildcard, *. The asterisk specifies that any resources that aren’t explicitly cached in the appcache manifest should not be cached.

Fallbacks

App caching also allow us to specify fallback resources. The form of an entry in the FALLBACK section is two resource identification patterns. The first (in the case above simply “/”, which matches any resource in the site), specifies resources to be replaced with a fallback when the user is offline. The second specifies the resource to replace any resources matching the patter. So, in this case, when any resource in the site has not been cached, and the user is offline, the page offline.html will be used instead. We can also specify resources to be replaced more specifically. For example, we could specify an offline image for any images that haven’t been loaded like so

/images/ /images/missing.png

Here we’re specifying that any resources located in the directory images at the top level of our site that have not been cached, be replaced with the image called missing.png found in that same directory, when we are offline.

Using the appcache manifest

So now we’ve created our appcache manifest, we need to associate it with our HTML documents. We do this by adding the manifest attribute to the html element of a document, where the value of this attribute is the URL of the appcache file.
The current recommendation is the appcache file have the extension .appcache. So, if our manifest is located at the root of our site, we’d link to it like so

<html manifest='manifest.appcache'>

There are also suggestions that using the HTML5 doctype may be required for some browsers to use app cache, so, make sure you use the doctype

<!DOCTYPE html>

And we’re all set. Well, almost. In order for the browser to recognize the appcache file, it needs to be served with the mimetype text/cache-manifest. How you set this up depends on your site’s server. At the time of writing, it’s likely that this is a step you’ll need to take, so if caching isn’t working, that’s very likely why. One of the most common servers is Apache. There are two ways in which you can set up Apache to serve .appchace files as type text/cache-manifest. At the root directory of your site, add a file with the name .htaccess, with the entry AddType text/cache-manifest .appcache (if there’s already a .htaccess file, just add this line to it).

Gotchas

App caching can be very powerful, allowing apps to work while the user is offline, and can increase site performance, but there are some definite gotchas it pays to be aware of. Here’s a few well worth knowing about.

Resources in style sheets

You’d be forgiven for thinking that any images in a style sheet that has been cached will be included in the appcache, but that’s not so. Images your style sheet refers to must be explicitly referenced in the CACHE section of the manifest as well.
Similarly, style sheets that are imported using @import, and resources included via JavaScript must also be explicitly cached.
To help build an appcache manifest, I’ve developed manifestR, which we’ll look at in detail in a moment. It will generate an appcache manifest for you, which includes all the scripts, style sheets, including those @imported, images, linked pages at the same site, and any images linked to in stylesheets.
There’s one exception to the rule that only explicitly listed resources are cached, and it is important to understand. Any HTML document that has a manifest attribute will be cached, even if it is not listed in the manifest. This can cause all kinds of headaches while developing, which we cover shortly.

Caching Cross Domain Resources

While there is some confusion on the issue, you can in general cache content from across different domains in an app cache. In fact, without this ability, the real world value of app caching would be limited, as content distributed via a CDN (content distribution networks like Akamai) could not be cached (even content served from a differently named server within the same domain couldn’t be cached). The exception to this is that when content is served over secure http (https), then the specification says all resources must come from the same origin. In an exception to this exception, Chrome in fact does not adhere to this part of the specification, and it has been argued that the single origin policy for https is too restrictive in the real world for app caching to be of genuine value.

Refreshing the cache

In effect, unlike most caching of web resources, appcaches do not expire. So, once the browser has cached a particular resource, it will continue to use that cached version, even if you change the resource on the server (for example by editing the contents of an HTML document). The exception to this is when a manifest file is edited. When the manifest is changed, the browser will recache all the resources listed in the manifest.
Caching can cause real headaches while developing a site or application, so it is recommended that during development, you avoid appcaching. One way of achieving this is to serve .appcache files with the wrong mimetype. This way, you can include the manifest attribute in your HTML elements, and serve the appcache file, just as you wold in production, but not have the effects of appcaching. Moving from development to production is as simple then as associating .appcache files with the right mimetype.

Resource hogging and lazy loading

To improve the performance of a site, you might be tempted to preload the entire site, by adding all the pages, images etc in it to the appcache manifest. And, in certain circumstances this might be desirable. It will however place considerable demands on your server, and use more bandwidth, as the first time a person visits your site, they will download more resources than they otherwise might have. Luckily, appcaches have an additional feature that can help here.
You might recall earlier that even when an HTML document with a link to an appcache manifest isn’t included in the manifest file, it will still be cached. The benefit of this is that rather than explicitly listing all the pages at your site in a manifest for them to be cached, each time someone visits a page that links to a manifest, it will then be cached.
If the primary motivation for using an appcache is to ensure your site or more likely app works offline, you’ll likely want to explicitly list the pages of the site, so that they’ll be available offline even if the user hasn’t visited them. If your primary motivation is increased performance, then let pages lazily cache when the user visits them, but cache scripts, CSS, and perhaps commonly used images.

Cache failure

An important, but subtle gotcha with appcaching is that if even one of the resources you include in your cache manifest is not available, then no resources will be cached. So, it is really important to ensure that any resource listed in your appcache manifest is available online. There’s a tool we discuss in a moment, the Cache Manifest Validator, to help ensure all those resources are online.

Size limits

While there specification places no limits on the size an appcache can be, different browsers, and different devices have different limits. Grinning Gecko reports that:

Safari desktop browser (Mac and Windows) have no limit
Mobile Safari has a 10MB limit
Chrome has a 5MB limit
Android browser has no limit to appcache size
Firefox desktop has unlimited appcache size
Opera’s appcache limit can be managed by the user, but has a default size of 50MB

User Permission

In Firefox, when the user first visits an appcached site, the browser asks the user’s permission (as it and other browsers do for location with the geo-location API). However, unlike with geo, other browsers don’t ask the user’s permission. Just something to be aware of, as there’ll be no guarantee with Firefox that appcaching is being used, even when supported.

Flakiness and browser support

It must also be noted that the general consensus is that appcaching is currently far from perfect across all browsers which support it. The specification is still in draft, but it should also be noted that most browsers have supported at least some appcaching for quite some time.
According to an amalgam of When can I use, Dive into HTML5 and other online resources:

Safari has supported offline web apps since version 4
Chrome has supported the feature since version 5
Mobile Safari has supported offline apps since iOS 2.1
Firefox has supported it since version 3.5
Opera has supported appcache since version 11
Internet Explorer as yet does not support offline web apps, including in IE10 developer previews
Android has support appcache since version 2.1

Introducing ManifestR

We’ve already mentioned that a particular challenge in creating an appcache is identifying all the resources you need to add to the manifest. To help you with this, I’ve developed ManifestR, an online tool to help you create an appcache manifest for any page. I don’t recommend you use it without at least a little additional fine tuning, as what it attempts to do is locate any resources referenced from a given page. As discussed above, depending on the purpose of your appcache, this is likely to be overkill.
Drag me to your bookmarks bar.
When you use ManifestR on a page, here’s what it looks for

images both in the same and other domains referenced in the src attribute of any img element in the page.
links to pages in the same domain. This can improve the performance of your site for visitors viewing other pages, and is vital if you want the entire site/app to work offline, but means potentially considerable additional load on your server the first time someone visits the site. Whether you choose to keep this list, or remove some or all of the links is an important decision to make.
style sheets, linked, or included via @import statements, located both in your domain, or other domains
images linked to in any style sheet, both those in the same domain, or other domains
JavaScript files, both those in the same domain, and served from other domains. Here too, you’ll need to consider carefully which to include and which you want to add to the online whitelist via the NETWORK section of the manifest.

it then puts them all together in a manifest, ready for you to cut and paste, tweak, save and upload.
I hope you find it useful in building appcache manifests (and make sure you let me know via twitter what you think, and how we can improve it).

Tools

We’ve already mentioned ManifestR, but you should find the The Cache Manifest Validator another really useful tool. Remember, for appcaching to work, every resource you list in your manifest must be available, or nothing will be cached. The Cache Manifest Validator can make sure all your resources are available.

Compatibility

Probably the best place to keep up to date with the ever changing field of HTML, CSS3 and other new web technology support in all modern browsers is When Can I Use?. You can find a snapshot of current browser support above.

HTML5 selectors API — It’s like a Swiss Army Knife for the DOM

2012-01-02T00:17:00.002-08:00

In the infancy of JavaScript, there was little if any concept of an HTML document object model (DOM). Even though JavaScript was invented to enable web developers to manipulate parts of a web page, and in the original implementation, in Netscape 2.0, developers could only access the form elements, links, and images in a page. Useful for form validation, and first widely used for image rollover techniques (think :hover, before CSS), but far from the general purpose tool to create modern web applications we now know (and love/hate).
Newer iterations of the DOM provided developers with access to far more than just that original limited range of elements, as well as the ability to insert, modify and delete elements in an HTML document. But, cross-browser implementations very often differed, and full support for the W3C’s DOM standards have arguably been treated as far more optional than CSS or HTML support.
One of the many reasons for the success of JavaScript libraries like jQuery and Prototype, on top of their easing the pain of cross-browser development was how they made working with the DOM far less painful than it had previously been, and indeed how it was with the standard DOM. Being able to use arbitrary CSS selector notation to get matching elements from a document made the standard DOM methods seem antiquated, or at the every least, far too much like hard work.
Luckily, the standards and browser developers took notice. The W3C developed the Selectors API, a way of easily accessing elements in the DOM using standard CSS selector concepts, and browser developers have baked these into all modern browsers, way back to IE8.
In this short (by my standards) article, we’ll look at the Selectors API, how you use it, browser support, and some little things you might like to keep in mind while using it. Rest assured, it’s now widely supported, so in many cases, you can safely use it, potentially with a fallback for older browsers (IE7 and older specifically) via libraries like jQuery (or more lightweight selector engines like Sizzle, which provides this functionality for jQuery, and other libraries).

The Selectors API

The Selectors API, which many would consider to be part of HTML5, is in fact a separate, small specification from the W3C. It provides only two new methods, querySelector, and querySelectorAll, for the Document, Element, and DocumentFragment objects (typically, you’ll use these methods on the document or element objects.) But do these methods make life easier for developers?
Before the Selectors API, to access an object in the DOM we could use these methods:

getElementById (from DOM Level 2 Core) — available for the document element
getElementsByClassName, standardized in HTML5, after long non standard browser support, which is supported on documents and elements
getElementsByTagName, from DOM Level 2 Core, available on the document and element objects

And there are some legacy ways of accessing elements on a page, which date from the earliest days of JavaScript:

links is a property of the document object which contains all anchor (a) and area elements with an href attribute
anchors is a property of the document object which contains all a elements
forms is a property of the document object which contains all form elements

We can also “traverse” the DOM, using:

childNodes, a property of the document and node objects
nextSibling, a property of a node, which contains the element directly following it in the same parent element
parentElement, a property of a node, which contains its parent element.

and related DOM traversal properties and methods.
But, what developers really often want to be able to do (as the success of jQuery and other libraries has shown) is simply say “give me all the elements which match this selector”, or “give me the first element which matches this selector”. And that’s precisely what the simple, powerful Selectors API does. It doesn’t completely do away with the need for DOM traversal, and legacy methods and properties, but it goes a long, long way.

querySelector

querySelector is a method of the document or any element, which returns the first descendent element which would be selected by its one argument, a CSS selector string. We can use this in place of the document.getElementById('content') like so: document.querySelector('#content') (like me, you’ll probably find yourself forgetting to add the # from time to time in querySelector, something which doesn’t throw an error, so can be frustrating to track down).
And we can do things like find the first header element in an HTML5 document, with querySelector('header'). So far so good. But where querySelector really shines is we can use any selector (attribute, structural, dynamic, UI, and even selector groups) with it. In most cases, this makes traversing the DOM, and locating a specific element far simpler, and most likely far quicker, as we won’t be looping in JavaScript and accessing all kinds of DOM properties, rather, the query is taking place inside the browser’s far faster native DOM engine.

querySelectorAll

Often, when working with the DOM, we want to manipulate several elements at once, For example, we might want to unobtrusively attach an event listener to all the links with a given class value. Here, querySelectorAll is your friend. Just like querySelector, it takes a single string as an argument, which is a CSS selector. Instead of returning a single element, it returns a NodeList (a kind of JavaScript array) of matching elements. We can then iterate through this array, and manipulate these objects.
For example, we could use it to replace document.links like so:

document.querySelectorAll('area[href], a[href]')

This finds all area elements with the href attribute set, as well as all a elements with this attribute set as well (notice how we’ve used a selector group, which is quite acceptable with the Selectors API).
Matching elements are returned in the order they appear in the DOM parse tree.

Document or Element?

I mentioned that both the document, and element objects implement these two methods — what’s the difference? Well, as you might have guessed, these methods find elements that are descendants of the object you query on. So, if you use the method on a paragraph element, it will only find the descendant elements of that paragraph which match the selector. Other elements in the document which might match it won’t be returned. But, if you use the methods on the document, then any matching element in the document can be found.

Gotchas

If you’ve really got your hands dirty with the DOM, you’ll know that when DOM methods return a NodeList, it is live—that is, the members of the list change, depending on the state of the document.
Let’s say we get all the elements with a class of “nav” using document.getElementsByClassName('nav'), and it returns 5 elements, which we keep in a variable.
Now, if we add a new element with class nav, or remove one of the existing elements with a class of nav, the NodeList in our variable will be updated to reflect these changes (that’s why it is called a live NodeList).
But querySelector and querySelectorAll are different. While they return a NodeList, it is static. So, if we similarly get all elements with a class of nav using document.querySelectorAll('.nav'), then regardless of what we subsequently do to the DOM, the length and contents of the NodeList won’t change. Which means, it’s always best to query the DOM just before you need the elements, rather than holding on to elements if your DOM is going to change.
There’s also a performance consideration. Tests of various browsers indicate that querySelectorAll is slower than getElementByTagName (though not it would appear in Opera). But, it’s also possible that once available, manipulating the static NodeList may be higher performance than manipulating a dynamic NodeList. And this issue will likely only have an impact in extreme cases. I’d certainly not recommend prematurely optimising by using getElementsByTagName, getElementsByClass, getElementById and so on in place of querySelectorAll, but it is worth noting you might be able to squeeze a little more performance out by doing so if you really need to.
And it is worth noting too that querySelector and querySelectorAll don’t work with every kind of selector. While pseudo-class selectors (like :visited) work with these methods, pseudo-element selectors, like :first-letter, :first-line, :before and :after although permissible as arguments, will return null in the case of querySelector, and an array of length zero for querySelectorAll.
A little gotcha this aging developer has found I’m so used to getElementById and getElementsByClassName that I find myself forgetting the # or . required in the selector string in querySeletor and querySelectorAll. As I mentioned a moment ago, it can be frustrating, as this won’t throw an error, but simply return null or an empty NodeList.

Support

All modern browsers, including IE8 and up support both querySelector and querySelectorAll. It is however worth noting that the results returned are dependent on what selectors the browser supports. IE8 supports CSS2.1 selectors, though not CSS3 selectors. IE9 supports many CSS3 selectors, but not a number of the UI related pseudo-classes, such as :required and :invalid. IE CSS support for versions 5 through 9 is extensively covered here by Microsoft.
So, keep in mind, even where these methods are supported, what they return is only as good as the CSS selector support in that browser.

The Wrap-up

If you’re more of a web designer who’s always been a little intimidated by the thought of wading through the DOM in search of elements (trust me, even seasoned developers often wince at the thought), then querySelector and querySelectorAll are a boon for you. Or, if you’re a developer who finds yourself going straight for jQuery or another library as soon as the DOM is involved, the Selectors API might just save you a few KBs, additional files and fussing around. And, if you’re one of those seasoned DOM experts, I’m sure there’s plenty of times you’ll breathe a sigh of relief that rather than wading through an entire document with childNodes, nextElementSibling and the like, a single call to querySelectorAll will return all the elements you want. I reckon these two are my favourite, and now most used DOM methods, and I’m only surprised they aren’t more widely covered, as they really are like a Swiss Army Knife for the DOM. Perhaps we need a “top 2 Selectors API methods” article. Then again…

Let the Web move you — CSS3 Animations and Transitions

2012-01-02T00:17:00.000-08:00

A brief history on Animation of the Web

If you’ve been developing for, or even just using the web for more than about 15 years, you’ll likely remember a time when animated effects were the bomb. Animated GIFs adorned just about every page, spinning globes, little men with jack hammers, self-folding winged envelopes. And if you’re very unlucky, you’ll remember the explosion of blinking content on the web around 1995, as the blink element in the then dominant Netscape browser took hold of the imagination of designers everywhere (for killing off the non-standard blink element alone, the web standards movement deserves at the very least a Noble Peace Prize). And perhaps the single widest JavaScript use in its earliest days was for creating image rollovers, until CSS got into the act with the hover state. In short, animation has had a long, if checkered career on the web.
Then, for years, animation fell out of favour, but with the rise of JavaScript libraries, we’ve seen the re-emergence of animated interfaces.

CSS3 animation

In the last 2 or 3 years, CSS3 has got into the act, providing a reasonably straightforward declarative way of creating even quite sophisticated animations, where complex JavaScript had previously been required.
In this article we’ll take a look at two related ways CSS3 provides for creating animations and animated effects, CSS Transitions and CSS Animations. We’ll look at how to create them, browser support, some interesting gotchas, and yet again, I’ll introduce a tool, AnimatR, I’ve created to help you more easily, and quickly, create cross-browser CSS animations. But please use animations wisely, tastefully and sparingly — we’ve take nearly 15 years to recover from the “blink tag”. Let’s not wait until 2026 for our next opportunity to get animations on the web right.

The JavaScript controversy

First up, let’s address a now fading controversy. When CSS animations were first proposed and experimentally introduced in Webkit, (coming up on 4 years ago now), many prominent, thoughtful developers felt strongly that animations were rightfully the domain of JavaScript, not CSS. Among the strongest, and most articulate, of those critics was Jonathan Snook, who subsequently revisited his concerns, and changed his position. In short, the concern is that animation is a kind of behavior, considered the domain of JavaScript, not presentation, the domain of CSS. But the simplest way of understanding an animation is that it is the change of presentational aspects of an element (height, width, color, etc.) over time. In short, animations are presentation, even if prior to CSS3 Transitions and Animations, they could only be achieved via JavaScript.
We also increasingly have the benefit that CSS based animation is being hardware accelerated in browsers, making for smoother animations and transitions even on relatively low powered mobile devices.
Let’s begin with the simpler CSS Transitions, then continue with CSS Animations. Animations reuse many of the concepts, and even syntax of transitions, so what we learn about transitions we can apply with animations as well.

Transitions

In CSS3, there are two kinds of animated effects — transitions and animations, which work in very similar ways. You might even think of transitions as simple kinds of animations. Transitions are the animation from one set of an element’s CSS property values of to another set. At their simplest, that might be a smooth animation from a background-color of red to a background-color of green.
Animations enable multiple changes to the presentational properties of an element over time — for example a 2 second animation from background-color of red to green, then a 1 second transition back to red again, repeated indefinitely (we’ll see less boring, and more useful animation examples shortly).
First introduced in Webkit and now supported across all modern browsers, including IE10 developer previews, transitions allow us to animate the change in presentation between two states, that is two sets of CSS properties. At its simplest, a transition might be just a smooth change from one value of a property to another value, over a specified period of time — for example, the smooth change of height over 2 seconds. To create simple transitions, we use the transition-property property, with a space separated list of CSS properties to be animated, and the transition-duration property, to specify how long the animation should take.
Here’s a really simple example: let’s cross fade a background-color from red to blue in 2 seconds.

p {
 transition-property: background-color;
 transition-duration: 2s;
 background-color: red;
}

Which leaves one simple question to answer — how do we trigger the change, and so the animated transition? Well, here’s the deceptive simplicity of transitions — they take place any time the specified property (in this case background-color) changes. So, if the background-color changes because we have a different background-color specified for the hover or other state, or if we use JavaScript to change the background-color, then those changes in color will be animated! Let’s try it out. If we specify a different background-color when the paragraph is in a hover state, like so:

p:hover {
 background-color: blue;
}

Then any time you hover over a p element, the color will fade. Let’s see that in action below

In all modern browsers (except IE9) this background color should fade from red to blue when you hover over it

A little pro tip as we go along — make sure you put the transition properties (transition-property, transition-delay etc.) on the element in its normal, not hover state.

But what’s with the s unit for the transition-duration property? CSS has in fact had units of time since CSS2. Originally part of Aural Style Sheets, we can specify time in either seconds (s) or milliseconds (ms) — 1,000 milliseconds in a second. CSS3 Transitions and Animations reuse these units, which are also part of CSS3 of course.
So, hopefully the basic idea is clear — with transitions we tell a browser that when a certain property or set of properties change, the change should not be abrupt, but be animated over a certain time period. Now, you might have noticed in the transition above the text color changes too — but does so without an animation. That’s because we’ve only specified that the background-color have an animated transition, via transition-property. We can as mentioned specify multiple properties, by listing each in a comma separated list of property names like so:

transition-property: background-color, color;

If we want all of the transitions to take the same amount of time, we can specify a single transition-duration property value. But, if we want different properties to transition over different time periods, we do so by listing the time values in a comma separated list — with the time periods and properties in the same position in their respective lists. Here for instance, the color will transition over 1s, while the background-color will do so over 2s:

p {
 transition-property: background-color, color;
 transition-duration: 2s, 1s;
 background-color: red;
}

And here this is in action:

In all modern browsers (except IE9) this background color should fade from red to blue when you hover over it, over a 2 second period, while the text color changes from black to green over 1 second.

If we want to animate the changes for any properties which change, we can use the keyword all as the value for transition-property. This will ensure that regardless of which property changes, that change will be animated (not all properties can in fact be animated — we’ll cover which ones can be shortly). Be careful with the all keyword — should future properties support animation, these will be animated, and it may not be clear at this stage just what these animations will look like.
There’s also the shorthand transition property which takes a space separated property name and time values like so:

p {
 transition: background-color 2s;
}

Note how there are no commas between the property and time value.

Or, if we have multiple property and time pairs, we separate each pair with a commas, like so

p {
 transition: background-color 2s, color 1s;
}

And in a nutshell, that’s the core of CSS3 transitions. We’ll touch on some gotchas (most of which are shared with animations) a little later. And we’ll take a look at browser support in detail in just a moment. But there are some optional features of transitions you might find useful, including specifying the nature of the transition, and a delay before a transition starts.

Transition Timing Functions

When a transition occurs, there are various ways the intermediate steps can take place. Let’s take the example of an element moving from left to right across the screen, over 2 seconds:

This element moves from left: 0% to left: 80% in 2s when you click it. It reverses this when you click it again.

Notice how it begins quickly, then slows down as the transition draws to an end. Now, take a look at the same transition below, with a very slight change.

This element moves from left: 0% to left: 80% in 2s when you when you click it. It reverses this when you click it again.

The difference between the two is they have different transition-timing-function properties. This property “describes how the intermediate values used during a transition will be calculated”. There are 5 timing function keywords (as well as some more complicated ways of describing timing functions mathematically using Bezier curves which we won’t go into here), ease, linear, ease-in, ease-out, ease-in-out.
Each of these is defined in mathematical terms in the specification, but it makes much more sense to let you see them all in action.

This transition has a timing function of ease, the default timing function. Click it to see it in action.

This transition has a timing function of linear. Click it to see it in action.

This transition has a timing function of ease-in. Click it to see it in action.

This transition has a timing function of ease-out. Click it to see it in action.

This transition has a timing function of ease-in-out. Click it to see it in action.

We specify an optional timing function (as noted above, the default is ease) using the property transition-timing-function, with one of the keywords above as its value. As mentioned, we can specify a timing function as a cubic Bezier curve, but if you need to get this technical with your transitions, the best place to understand the details is the specification.
Which timing function you choose is a matter of taste, and for most purposes, the default value of ease should be fine.

Delay

There may be occasions on which we want a transition to delay for a certain amount of time before commencing, and we can do this quite straightforwardly with the transition-delay property. As with transition-duration we do this using a time value in seconds or milliseconds.

transition-duration: 150ms;

We can also specify different delays for different transitions, like this (click the element below to see the effect):

This element transitions the change of top value, but delays the transition on the change of left value for .5s.

 transition-property: top, left;
 transition-duration: 2s, 1.5s;
 transition-delay: .5s, 0s;

Browser Support and Backwards Compatibility

So, having introduced such a mouthwatering prospect for designers, just how useable is it today? In fact, surprisingly so. All modern browsers support transitions, including IE10 developer previews. Firefox has done so since version 4, Safari since 3.2, Chrome since at least version 9, Opera since 10.6, iOS since 3.2 and Android since 2.1.
It does need to be noted that not all browsers animate all property changes — we’ll look at this in a little more detail in the animations section, since the list of properties applies to both animations and transitions.
However, as yet, all browsers require vendor prefixes in front of all the properties for transitions — which can make for some unwieldy CSS.
Since transitions only animate changes in style that are triggered either by a change in state (like hover or focus) or via JavaScript, they are effectively backwards compatible to just about any browsers likely to be used today. Users of those browsers simply don’t see the intermediate steps between one state and the other, merely the abrupt transition they’d always have seen. We just need to ensure that in the absence an animated transition, no information is lost.
From a usability and accessibility perspective, we should also be mindful that flashing content can trigger seizures in some users, and that sudden movements of content (for example a block of content from one place to another) in the absence of an animated transition may be disorienting, particularly for users with cognitive disabilities.
Transitions are straightforward to use, widely supported, backwards compatible, and can add a little more to your site or application. However just make sure you don’t overdo them. Remember the <blink>.

Animations

Similar in many ways to transitions, CSS Animations allow us to create multi-step animated content using only CSS and HTML (though we will often want to use just a little JavaScript to trigger the animation).
I’ve mentioned that animations and transitions have a good deal in common — here’s a quick look at their similarities and differences.

Similarities between CSS Transitions and Animations

Both animate the change in CSS property values over a period of time
Both have a duration
Both have an optional delay
Both have an optional timing function, defined in the same way

Differences between CSS Transitions and Animations

Animations can repeat any number of times
Animations can be specified to go in a forward and reverse direction
Animations can have any number of defined intermediate steps, called “keyframes”, but transitions only have a defined start and end “keyframes”.
With transitions we can specify an animation for any property which changes, using the all keyword. With animations, we need to specify every property we want animated.

How CSS Animations are defined

Creating a CSS3 animation is a little more work than creating a transition, involving two interlinked steps.
We need to create a regular CSS rule, which selects the element or elements we want to be animated, and we give this rule a set of CSS properties related to animations (we’ll look at these properties in a moment).
We also create an @keyframes rule, similar to an @media rule, which defines the two or more keyframes in our animation. If we have simply two keyframes, for the beginning and end of our animation, a transition is most likely the better choice. Each keyframe specifies the state of the animated properties at that particular time during the animation.
While it might sound a little complicated, each step is quite straightforward. Let’s take a look at each in turn.

The animation properties

Just as with transitions, we specify various aspects like the duration and timing function of the animation using CSS properties. But first we need to declare which @keyframes rule will be used to specify the keyframes of our animation, which we do using the animation-name property. Animation names follow the same rules as HTML4 id values — alphanumeric characters, dashes and underscores, and begin with a letter. Here we’re specifying that the header element should be animated using an @keyframes rule with the name opening-sequence (we’ll see very shortly how we give @keyframes rules names).

header {
 animation-name: opening-sequence;
}

Notice how the animation-name value is not quoted.

We’ll return to familiar territory by specifying a duration and timing function for the animation, using the properties animation-duration and animation-timing-function. As with transitions, the duration is specified in seconds or milliseconds, while the timing function takes one of the keywords we saw earlier (or again a more complex formula we’ll not go into here).

header {
 animation-name: opening-sequence;
 animation-duration: 5s;
 animation-timing-function: ease-in;
}

As with transitions, we can also delay the beginning of an animation, here using the animation-delay property, with a value once again in s or ms.

header {
 animation-delay: 500ms;
 animation-name: opening-sequence;
 animation-duration: 5s;
 animation-timing-function: ease-in;
}

So far, all should be very familiar from transitions. Now we meet two new properties. The first is for specifying how often the animation runs (once, a certain number of times, or indefinitely). The other is for specifying what happens when a repeating animation completes — should it begin again from its initial state, or play the animation in reverse? Let’s take a look at each.
Specifying that an animation should run more than once is very straightforward. We use the animation-iteration-count property, and give it either a numerical value, or the keyword infinite. The animation then runs the specified number of times, or indefinitely. The delay in commencing the animation only applies to the very beginning of the animation, and there will be no delay between iterations.
When an animation does run more than once, for example if an element moves from left to right on the page, what should happen when the next loop of the animation begins? There’s two possibilities. The animation could begin where it did the first time — for example on the left, as in this example

animation-direction: normal;

Or, the animation could reverse direction, returning to the starting values, as the animation below does:

animation-direction: alternate;

We define this behavior using the animation-direction property, which takes one of two possible keyword values: alternate or normal. To achieve the first of the effects above, we use the animation-direction property with a value of normal. The second of the two has a value of alternate for the animation-direction property.
Now we’ve set up part one of our animation, it’s time to create the animation itself. As we’ve mentioned, this is done using an @keyframes rule. The form of this rule is:

@keyframes opening-sequence {

  0% {
    /*properties to animate*/
  }

  20% {
    /*properties to animate*/
  }

  100% {
    /*properties to animate*/
  }
}

That is, we start with the keyword @keyframes. This is followed by the animation name. Next, inside curly braces (}”{“ and ”}”) we have two or more keyframes. A keyframe has the form of a percentage value, and then a group of CSS properties inside their own curly braces.
The first keyframe must be 0%, and unlike elsewhere in CSS, the % is required. The last keyframe must be 100%. OK, so we can use the keyword from in place of 0% and to in place of 100%, but both the first and last keyframes must appear.
To create the animations above, we’d have this @keyframes rule:

@keyframes opening-sequence {

  0% {
left: 0%;
  }

  100% {
left: 80%;
  }
}

Note how our keyframes rule doesn’t have anything to say about the direction, duration, and so on. These are properties we specify for particular elements using the animation properties we’ve just seen. Both of the animations just above use the same @keyframes rule — they just have different animation-direction properties. Here are the complete rules for each of those animated elements

#normal-animation {
background: red;
position: relative;
width: 20%;
animation-name: opening-sequence;
animation-duration: 5s;
animation-iteration-count: infinite;
animation-timing-function: ease;
animation-direction: normal;
}

#alternate-animation {
background: red;
position: relative;
width: 20%;
animation-name: opening-sequence;
animation-duration: 5s;
animation-iteration-count: infinite;
animation-timing-function: ease;
animation-direction: alternate;
}

The only difference between the two is the value of the animation-direction property.
Let’s take a closer look at the @keyframes rule. Each keyframe is more or less like a regular CSS rule. In place of a selector like p.classname, it has a percentage value. The percentage value specifies where in the animation this keyframe belongs. For example a keyframe percentage of 40% in a 10 second animation occurs after 4 seconds.
It also has a declaration group of properties, separated by semicolons, as we’d find in a regular CSS rule. These define what the appearance of the selected element or elements should be at this point in the animation. The browser then animates the transitions between these keyframes.
Rather than go on in ever greater detail, perhaps the best way for you to get a better understanding of animations is to create some. And you don’t need to fire up a text editor, just head over to AnimatR, the tool I’ve developed to help you create animations. I’ll go into a bit more detail about how it works shortly, but it should make sense if you’ve read this far (and hopefully make more sense of what you have read).

Before and After Animation

Suppose we have this CSS

header {
 width: 90%;
 animation-name: opening-sequence;
 animation-delay: 2s;
 ...
}

And this animation

@keyframes opening-sequence {
  0% {
    width: 40%;
  }

  100% {
    width: 60%;
  }
}

What width is the element during the 2 second delay before the animation begins? What about after the animation completes? In both cases, it’s 90% (which may not be what you want). But we can specify that instead of the applied properties, the opening and closing keyframe properties should apply during the animation delay, and after the animation completes using the animation-fill-mode property.
animation-fill-mode can take the following keyword values:

none: the default state, as described above
forwards: the properties from the 100% keyframe will continue to apply after the animation completes
backwards: the properties from the 0% keyframe apply during the delay period of the animation
both: both the forwards and backwards cases hold

Triggering animations

We saw that transitions occur when we change the associated CSS properties, either using CSS, or JavaScript. But when do animations occur? An animation will begin as soon as a page is loaded, which may not be what we want to occur. There’s various ways we can stop the animation auto-playing. We could not give an animation-name property to the elements we want to animate, and then apply this property using JavaScript when we want the animation to commence. But simpler in a way is to use the animation-play-state property. This takes one of two keywords, running or paused. We can change this using JavaScript:

element.style-animation-play-state="running";

Or even trigger an animation to run only when the user is hovering over an element (far from recommended):

header {
 animation-play-state: paused;
}

header:hover {
 animation-play-state: running;
}

Browser Support

We were in luck with transitions, as we saw they have widespread support in modern browsers, including IE10. We’re not quite so lucky with animations, but support is definitely on the increase. At present, Safari since version 4, Chrome since at least 9, Firefox since version 5, iOS since 3.2 and Android since 2.1 have support for animations. While support in Opera and Internet Explorer 10 has not been announced, as both these browsers support transitions, arguable the hardest part of CSS animations to implement, support for animation in these browsers may not be too far off.
As with transitions, all animation properties must currently have vendor prefixes: –webkit-, –moz– (and so on for future browser support). This is also true for @keyframes rules, but these have a slightly unusual format. Typically we prefix the property name, but for @keyframes the prefix comes after the @ and before the keyframes keyword, like so:

@-webkit-keyframes{
}

@-moz-keyframes {
}

As with transitions, animations will typically be backwards compatible, particularly if they are used to add a layer of enhanced user experience, rather than content in their own right. One area where animations are beginning to see some use is in browser-based games. As many browsers and devices hardware accelerate animations and transitions, for applications where performance is a significant issue, as it often is with games, animations will become an increasingly attractive solution. But here backwards compatibility is a significant issue — with games, animations aren’t simply decoration, they are central to the user experience. So, for some time to come, choosing to use CSS animation to develop games will necessarily mean excluding some users from playing those games.
Animations also pose a potentially significant challenge to creating accessible content. Where sophisticated animations are in essence an important part of the content, there is as yet no consensus as to how to make rich animations developed using CSS3 accessible.

Animation (and Transition) Gotchas

As a technology still in its infancy, animations do have a number of gotchas it is worth knowing about, to save hours of hair pulling and head-on-table banging. I’m sure there are many more than this, but here are some that I’ve come across.

Supported properties

Not all properties are animated. A list of properties that can be animated is outlined in the specification. Noteworthy is that background images can’t be animated (though properties like background-position are), with the theoretical exception of gradients (in practice gradients aren’t animated by any browser as yet).
It’s also important to note that transitions and animations only animate property transitions which would otherwise occur. For example

@keyframes widen {

  0% {
width: 5em;
  }

  100% {
width: 10em;
  }
}

won’t animate the width changes of an inline element like an <a>, because we can’t set an explicit width on an inline element. Similarly, for a paragraph which is statically positioned,

@keyframes move {

  0% {
left: 5em;
  }

  100% {
left: 10em;
  }
}

won’t animate the element, as we can’t set the position of elements with a position: static. So, if your animation or transition isn’t working, make sure the properties make sense. In the case of our link above, we could give it a display: inline-block, while in the case of the paragraph, a position: relative, and then the animations would take effect.

Animations in the Wild

So, just how sophisticated can CSS based animation be? Earlier this year, Naomi Atkinson and Mircea Piturca created an opening title sequence for our European conference, @media. Here’s a video of it appearing on the big screen, in front of hundreds of people in London’s famous Queen Elizabeth Hall:
Opening credits at Web Directions @media 2011 from Naomi Atkinson on Vimeo.
Renowned designer and developer Cameron Adams created these stunning opening titles for our conference, Web Directions South 2010. Displayed on two enormous screens in a theatre with a capacity of 1,000, it was an amazing sight to see. Note, this was expressly designed for 1024x768 resolution, and uses the font Gotham, so if possible, make sure you have the font, and set your screen to that size.
Perhaps the pre-eminent CSS Animator to date is Anthony Calzadilla, whose experiments and commercial work have really opened up people to what’s possible with CSS transitions and animations. Well known examples include Madmanimation, and an animated cover for the Wired Magazine iPad edition.
You’ll also find various collections of animation demonstrations like this one.

Introducing AnimatR

As CSS becomes ever more powerful and sophisticated, understanding, learning and remembering all the associated concepts, property names, syntax and so on becomes an ever more onerous job. So, as I am lazy, I’ve developed yet another tool, this time to help me (and hopefully you) understand and use CSS animations — AnimatR. AnimatR is not a WYSIWYG animation tool like Sencha’s slick Animator, the eagerly awaited Animatable, or the just announced Adobe Edge. Rather, it’s kind of like training wheels, to help you get up to speed with the concepts and syntax of animations (or for me a kind of Zimmer frame to help me totter along with all these new fangled CSS innovations).
It helps you easily set up the animation properties (except animation-play-state), as well as the keyframes for your animation. You can also add further style for the animated element, for example, giving it a position: absolute for animating an element’s location (an ever popular pastime).
To use the code you create with AnimatR, just change the #demo selector to select the element or elements you want to animate in your pages, and paste the contents of the code field into your style sheet. AnimatR will even generate the vendor prefixed versions for –moz– and –webkit– browsers (since Opera and IE have yet to announce support, I’ve not added support for these browsers yet).

Use wisely

Right now, there’s very little “hotter” in web development than animation, shown by the takeoff of Apple’s iAD, and other mobile advertising technologies along with tools like Adobe Edge and Sencha Animator. I hope you’ll agree they really aren’t all that complex to use, but also that they need to be used intelligently. The novelty of stuff on the web which flashes and moves has worn off (I hope). It’s time for web based animation that is smart and engaging. You have the tools — now get to it!

CSS3 Linear Gradients

2012-01-02T00:15:00.001-08:00

It’s been a while since we posted anything particularly technical to the Web Directions blog, but that’s something we plan on changing. Here’s the first in a series of technical articles on CSS3 features (along with tools to help you lean and use them).
We’re starting with linear gradients. We’ll take a look at where they come from, how to use them, and the current level of browser support. Ironically although webkit introduced gradients, until version 5.1, Safari has supported a different syntax from that described here — so, if you are using a version of Safari other than 5.1 (currently in beta) you won’t be able to see the examples.

A little history

webkit first introduced the proposed gradient feature of CSS3 way back in 2008, enabling the browser to generate a gradient to be used where images are in CSS — most commonly as a background image, but also potentially for list items images, border-images, and generated content. Firefox 3.6 followed suit, but introduced a couple of challenges. It introduced a different syntax (now adopted as the proposed CSS3 gradient syntax), and gradients were only available as background images (this restriction is still true today). Not surprisingly, the webkit based Chrome supports gradients, as does Opera since version 11.1 (though only linear gradients (more in a second) are currently supported). What of Internet Explorer you ask? Well, version 10 in fact supports gradients!
Don’t be too alarmed by the two different syntaxes — webkit now supports the same syntax as other browsers, as of Safari 5.1 (we’ll also look at how to ensure maximum browser compatibility in a moment as well).

How they work

Enough history, let’s play with them. There are in fact, as mentioned above, two kinds of gradients (linear and radial gradients). In this article, we’ll focus on linear gradients — and return to radial gradients in an upcoming article.
Gradients aren’t properties (like color), but are a computed values of CSS, something you might not be too familiar with. We use them where we’d typically use a url pointing to an image (most commonly background-image). In essence, the browser generates an image and uses that.
Here’s one in action
OK, so I’ve cheated a little and added a bit more style, but that subtle gradient is all done with CSS. Try increasing the text size — and see how the background gradient continues to fill the element.
Here’s what the CSS looks like.
background-image: linear-gradient(top, #eff6fb, #d3e4f3 68%);
(I said don’t panic for a reason — if you are interested in the underlying concepts, read on. But if you are a more hands-on kind of learner, simply head to the gradient tool I’ve built, and start playing.)
The linear-gradient starts at the top of the element (we’ll see shortly there are other places it can start) and runs vertically to the bottom of the element. At the top, the initial color is #eff6fb. At 68% down the element, the color is #d3e4f3, and the browser generates a gradient image that smoothly transitions from #eff6fb to #d3e4f3. From 68% down the element, to its bottom, the color is a solid #d3e4f3.

BTW, “#d3e4f3 68%” is called a color stop — and gradients can potentially have many stops.
Before we go on, let’s recap. A gradient is value, starting with the keyword linear-gradient, and then containing a number of values inside parentheses. These values specify the direction of the gradient (in this case from top to bottom), a starting color, and then one or more color stops. A color stop is a color value, with an optional length or percentage value (for example, we can have a stop at 1em, 20px and so on).
Here, for example is a gradient with numerous stops

background-image:
 linear-gradient( left, #FF0000, #FFA500 13.0%,#FFFF00 26.0%,#0000FF 
39.0%,#008000 52.0%,#4B0082 65.0%,#EE82EE 78.0%)

The gradient direction

We specify the direction of the gradient in one of two ways. We can specify where it starts horizontally with the keywords left and right, and vertically with the keywords top and bottom. Let’s look at each of these (just follow the link to see each)

We can also combine keywords — to create diagonal gradients from the top left, bottom left, top right and bottom right:

But gradients would be pretty dull if they could only be horizontal, vertical, or diagonal, so there’s a second way to specify the gradient direction-degrees. (You use keywords or degrees, not both together).
To specify a gradient angle, we use the format 90deg (0deg has the gradient start at the left, 90deg at the bottom, 180deg at the right, and 270deg at the top. So, we can think of degrees as going counter-clockwise from 9 o’clock (0deg).)
As usual, the simplest way to understand this is to play with it — so head over to the gradient tool I’ve built expressly for this purpose, and vary the angle to see what happens.

background-image:
 linear-gradient(126deg, #FF0000, #FFA500 13.0%,#FFFF00 26.0%,#0000FF 
39.0%,#008000 52.0%,#4B0082 65.0%,#EE82EE 78.0%)

Repeating gradients

Is your head full of complex stuff yet — color stops, gradient angles, and so on? Well, let’s add to that, with repeating gradients. That’s right, you can repeat a gradient. Here’s how that works. If your last color stop is before the “end” of the element (so, for example if the gradient goes from left to right, the last stop is less than 100% of the width of the element), then the gradient will be repeated from the location of the last color stop. If we have a simple gradient like this
background-image: linear-gradient(0deg, #FF0000, #FFA500 50%)
then we change the value name from linear-gradient to repeating-linear-gradient, then we’ll have the gradient repeat itself from 50% to 100% of the width of the element, like so
background-image: repeating-linear-gradient(0deg, #FF0000, #FFA500 50%)

Forget the math, here’s a tool

As I mentioned above, there’s no need to remember all the syntax and concepts — as I’ve developed the linear gradient tool to make life easier for you. (In fact I significantly overhauled the version I developed something like 2 years ago, to provide widespread browser support, and support the new syntax more fully.)
There are some other good gradient tools out there as well, including ColorZilla. I’ve designed this (and my other CSS3 tools) to closely follow the concepts of CSS gradients, to be as much a tool for learning, as for producing fine looking gradients.
It also has some additional features you might like.

You can tweet a link to a gradient you’ve created by simply clicking a button
You can copy the url of your gradient, and send it to someone via email, put it in a link (like I’ve done for many of these examples) or otherwise share it
Via the magic of HTML5 localStorage, it remembers your most recent gradient, and other settings next time you visit
It adds vendor prefixes for all modern browsers as an option
It adds the start color as a background color for older browsers
There’s a related tool for creating old style Safari gradients
It provides up to the minute browser compatibility information
It looks really pretty, all thanks to CSS gradients of course

So give it a go, and tell me what you think.

Backwards compatibility

Now, you might be asking yourself, what about the backwards compatibility issues with older browsers and are there any accessibility challenges in using gradients? Luckily, gradients are really straightforward to use in an accessible, backwards compatible way, across multiple browsers provided you keep a couple of things in mind.
Firstly, ensure you have a background color (or image) for the element to ensure color contrast with the text. Where gradients aren’t supported, the browser will ignore them, and use the color or image.
At present, all browsers require vendor specific extensions for gradient values. The gradient tool will create those for you. Make sure that you include a gradient value with no vendor extensions, and make this the last of the properties you specify (as we know, if CSS, the last property trumps earlier ones in the rule). So for example

background-color:#AB1364;
background-image: -moz-linear-gradient(114deg, #AB1364, #52FF26 11%);
background-image: -webkit-linear-gradient(114deg, #AB1364, #52FF26 11%);
background-image: -o-linear-gradient(114deg, #AB1364, #52FF26 11%);
background-image: -ms-linear-gradient(114deg, #AB1364, #52FF26 11%);
background-image: linear-gradient(114deg, #AB1364, #52FF26 11%)

For older versions of Safari, we’ll need to have a different background-image property. Not only is the syntax different, the concepts are too, so you might like to use my old style CSS3 Linear Gradient generator to help you out.
And, wth the exception of webkit, gradients are only applicable to backgrounds, (webkit browsers support gradients anywhere images are used.)

Browser Support Notes

A quick summary of current browser support for CSS Linear Gradients.

Safari 4 introduced linear gradients, though as noted with a different syntax from that detailed here. The vendor prefix –webkit– is required for gradients (e.g. –webkit-linear-gradient)
Safari 5.1 introduces the syntax detailed here, as well as continuing to support the older style syntax. Again, the –webkit-vendor prefix is required.
Firefox 3.6 was the first browser to support the current gradient syntax. The –moz– prefix is required, and it’s currently only supported on backgrounds.
Chrome 10 and up (and probably earlier versions) supported the syntax for gradients detailed here. The –webkit– prefix is required.
Opera 11.1 introduced linear gradients, once again with the vendor prefix, –o– required. Currently gradients are only supported on backgrounds.
Internet Explorer 10 also features CSS gradients, using the prefix –ms-, and also only supported on backgrounds.

And just to make life easy, there is talk at the W3C CSS Working Group of changing the syntax yet again.

To do on the Generator

At present, the generator only supports hex color values. Enabling rgba and color keywords (particularly transparent) are important next steps.
Support for multiple background gradients on a single element, used extensively at the CSS Gradient Gallery
Automatic generation of older webkit style syntax.
Taking requests — let me know what you’d like to see

10 responses to “CSS3 Linear Gradients”:

- By:Jason Foss
- July 2nd, 2011
Thanks John, this clears it right up. They’re actually not that complicated when explained properly!
Although one has to wonder why the degrees implementation starts at 9 o’clock and works anti-clockwise. I would have thought starting at 12 o’clock and working clockwise would have been easier to remember. Specifying margins and padding works fine that way, why use a different method?
*shrugs*
- By:Alan Gresley
- July 2nd, 2011
Hello John,
Have you been following the recent debates on www-style? Firstly the angles are changing where 0 degrees indicates the beginning point (first color stop) of a gradient which would be positioned at the top (northern) part of a box. The WD did have for about 2 week the opposite, where 0 degrees indicated the ending point (last color stop) of a gradient. This was also affecting top and bottom which the WD was saying were the referencing the ending points. Now it’s been marked as a CSS issue as mentioned two days ago on the www-style mailing list and in the WD (in red text).
Another thing that could be happening is how gradients with color with alpha transparency work. Some want interpolation in premultiplied space where others (one being me) are saying that gradients should work as they do now which is that interpolation happens in un-premultiplied space. I am currently working with an implementer to explore the consequence of such a change since they are testing in an implementation (browser) that supports interpolation in premultiplied space. Certain gradients are broken (look wrong).
I tried to alert other authors recently but no one seems to know what I am talking about. The truth is, only a few understand the difference between premultiplied space and un-premultiplied space. I can explain it quickly but it’s very hard to do in typed words.
I myself would like the issued resolved since I have been working on gradients transitions (animations) where some color stops are partly transparent. Such a demo.
- By:Joni
- July 5th, 2011
Also rememeber that if you put these to body/html element (or any big element), older machines doesn’t like that so much.. :) it slows down scrolling heavily. Specially with fixed background. I haven’t tested with small elements, like buttons etc.
- By:CSS3 Radial Gradients | Web Directions
- July 19th, 2011
[…] 19, 2011 Leave a response Getting your head around CSS3 radial gradientsWe recently took a detailed look at linear gradients in CSS3. If you’ve not read that, you might like to spend a few minutes doing so, as the concepts are […]
- By:fjpoblam
- September 13th, 2011
Good article, John. I’ve been using the *old* (proprietary) formats for quite awhile as my main website background. Before that, I was using a simple tiled 2px by 800px gradient.
Perhaps I misunderstood, but I *thought* your implication was that the new (5.1+) Safari supported the new format.
FWIW, I tried your new format, on MacOSX 10.6.8 (Snow Leopard), in both Safari 5.1 (6534.50) and the latest Webkit nightly (r94932), with no luck. (My website is coded in “HTML5”, if that makes a difference.) Therefore, I’ve returned to the proprietaries: –moz, –o, and –webkit.
It is curious that your demo shows up correctly in both Safaris, though I didn’t take the time to try it out in FF, Chrome, Camino, or Opera. I don’t know whether you’re using the new spec “behind the scenes” or just an illustrative graphic.
- By:John
- September 17th, 2011
Safari 5.1 supports both the old and new formats. but AFAIK, you sat still need –webkit– for Safari 5/.1 and the new formats
- By:2D Transforms in CSS3 | Web Directions
- September 21st, 2011
[…] make rotating an element easy.The rotate function takes an angle value. If you’ve worked with CSS linear gradients, in particular the newer syntax, then you’ll have seen angle units before. There are several ways […]
- By:CSS3 Radial Gradients | kabayview.com
- October 6th, 2011
[…] recently took a detailed look at linear gradients in CSS3. If you’ve not read that, you might like to spend a few minutes doing so, as the concepts are […]
- By:Cascading Style Sheets Reference Links | kabayview.com
- October 10th, 2011
[…] CSS3 Linear Gradients – John Allsopp […]
- By:CSS3 and gradients — brief introduction « Steve Worley
- December 8th, 2011
[…] CSS3 Linear Gradients | Web Directions (webdirections.org) LD_AddCustomAttr(“AdOpt”, “1”); LD_AddCustomAttr(“Origin”, “other”); LD_AddCustomAttr(“theme_bg”, “ffffff”); LD_AddCustomAttr(“theme_border”, “f1f1f1”); LD_AddCustomAttr(“theme_text”, “555555”); LD_AddCustomAttr(“theme_link”, “059bff”); LD_AddCustomAttr(“theme_url”, “e5f2bf”); LD_AddCustomAttr(“LangId”, “1”); LD_AddCustomAttr(“Autotag”, “science”); LD_AddCustomAttr(“Autotag”, “technology”); LD_AddCustomAttr(“Tag”, “web-development”); LD_AddCustomAttr(“Tag”, “css”); LD_AddCustomAttr(“Tag”, “css-techniques”); LD_AddCustomAttr(“Tag”, “css3”); LD_AddCustomAttr(“Tag”, “css3-gradients”); LD_AddCustomAttr(“Tag”, “gradients”); LD_AddCustomAttr(“Tag”, “website-design”); LD_AddSlot(“wpcom_below_post”); LD_GetBids(); Share this:FacebookStumbleUponDiggTwitterLike this:LikeBe the first to like this post. […]

CSS3 Radial Gradients

2012-01-02T00:14:00.001-08:00

Getting your head around CSS3 radial gradients

We recently took a detailed look at linear gradients in CSS3. If you’ve not read that, you might like to spend a few minutes doing so, as the concepts are very similar, and I don’t spend quite as much time in this article on the fundamentals of gradients which I’ve already covered there.
This time we’ll look in detail at radial gradients. If you’ve got a good sense of how linear gradients work, radial gradients should present no great difficulty. And, I’ll again introduce an updated tool for creating radial gradients, which supports the current syntax, and works across all modern browsers which support radial gradients (more on which they are shortly).

A brief history

Like linear gradients, radial gradients were first introduced in Webkit in 2008. Like linear gradients, they are still in a draft CSS3 specification, and indeed are still in something of a state of flux, so it is more than possible the final specified version will be different from that described here. As with linear gradients, radial gradients as originally proposed by Apple’s Webkit team had a different syntax, and quite significantly different conceptual basis from how they are currently specified, and from how they are supported in current browsers. With Safari 5.1, all modern browsers have harmonized on the same syntax, and conceptual basis for radial gradients, which is what we cover here. Safari 4, and Chrome 10 and up support a very different syntax, and model for radial gradients, which is effectively obsolete, and which we won’t cover here.

What exactly is a radial gradient?

I’ve thought long and hard about whether to try and explain what is really going on with a radial gradient (and for most folks, simply playing around with them is likely the best way to really come to grips with them). But, as I’ve yet to see a very good description of exactly how radial gradients work, here’s my attempt.
You’ll hopefully remember that linear gradients have a straight gradient line, from one edge of the element’s background box. It could be vertically from top to bottom, or bottom to top. It could be horizontally from left to right, or right to left. Or it could be at an angle, from left to right, right to left, upwards or downwards.

Some common linear gradient lines
We then specify two (or more) colors to create the gradient along this line. The gradient “smoothly fades” from one color to the next along the gradient line. So, what exactly does “smoothly fades” mean? To get all technical on you, the Image Values and Replaced Content module of CSS3 says “between two color-stops, the line’s color is linearly interpolated between the colors of the two color-stops, with the interpolation taking place in premultiplied RGBA space”. Glad you asked? And if you really want to get down and dirty with linear interpolation, the spec has a whole section on it.
Radial gradients also specify a gradient line, but this time, the line goes from the center of an ellipse, outwards in each direction to the edge of the ellipse. Along this line color also “fades smoothly” from one color stop to the next.
We also know from linear gradients, that the gradient can have intermediate stops between the starting and final color. Not surprisingly, radial gradients can have color stops, specified as being a certain percentage, or length value, along the gradient, between the start and final colors.
But where radial gradients differ significantly from linear ones, is the shape and size of the gradient, as well as a gradient’s location.
In essence, to specify a radial gradient, we give the gradient

a location
a shape
a size
one or more color stops

Let’s look at each of these, though slightly out of order, because to understand how they all work, we need to understand a little bit about what an ellipse is (this won’t hurt a bit I promise).

Ellipses

An Ellipse, showing the major and minor radii.
An ellipse is what we more colloquially call an oval. It differs from a circle in that its width and height are different from one another (strictly speaking, a circle is a kind of ellipse where the width and height are equal).

As you can see here, a circle is a special kind of ellipse where these two lines are the same length.
If you drop a vertical line through an ellipse at its tallest point, and a horizontal line through it at its widest, where these two intersect is the center of the ellipse. The longer of these two lines is called the major semi-axis or major radius, and the shorter the minor semi-axis or minor radius.
From all this, the key concepts to take away are

What the center of an ellipse is
What the radii of an ellipse are

Radial gradient location

We give a radial gradient a location by specifying where its center will be in relation to the element it is a background image for (we’ll leave aside the case where the gradient is used elsewhere for now).
We can specify the location of the ellipse’s center essentially the same way we specify the location of a background image with the background-position CSS property. We specify the horizontal position of the background, and optionally the vertical position using either keywords (left, center right, or top, center, bottom), length values, percentage values, or some combination of these. For example we might have

left bottom
left 100%
0% bottom
0% 100%

Which all specify that the center of the gradient ellipse should be in the left bottom corner of the element background.
Where the second value is omitted, it is treated as center (similarly, if we omit the first value as well, the center of the gradient ellipse is in the center of the element’s background.)
So, let’s start putting together a radial gradient. As we saw with linear gradients, a gradient is not a CSS property. Rather it is a value, that can in theory be used anywhere an image would be used, but in practice, typically only as a background image on an element. Here we’ll start a radial gradient as the background image of an element, and give it a location. We’ll place the gradient in the center of the element’s background.

background-image: radial-gradient(50% 50%,

Notice how the horizontal and vertical center values are simply separated by a space, and then pair is then followed by a comma. Note too that this is not yet a gradient, just the start of one. We still need to specify the shape and size, plus its color values.

Radial Gradient shapes and sizes

Now we’ve specified the location of the center of the gradient, we need to specify the shape and size of the ellipse. These can be specified in one of two ways, implicitly, or explicitly.

Explicit shapes and sizes

We explicitly specify the shape and size of the ellipse for our radial gradient by specifying the lengths of the major and minor radius, using a length or percentage value. (as of July 2011, this aspect of radial gradients was not supported by any browser, so we’ll only cover this briefly).
For example, we might specify a width of the gradient ellipse as being 50% of the width of the background element and 30% of the height of the element with the values25% 15% (note that these values specify the radius, which is half the width or height). If we specify identical values for width and height, then the two radii are the same length, and so we get a circular gradient. Here’s what our gradient would look like with this explicitly declared width and height

background-image: radial-gradient(50% 50%, 25% 15%,

Notice again, the width and height values are separated only by a space, and then we follow these by a comma.

Implicit shapes and sizes

Alternatively, instead of specifying an explicit width and height to give us the size and shape of our gradient, we can specify the size and shape implicitly with keywords. In practice, this is the only one of the two forms that is supported in contemporary browsers, and so is the one you should use.

Shape

This part is very straightforward, we just use one of two keywords ellipse or circle, to specify the shape of the gradient. So, we create an elliptical shape for our gradient like so

background-image: radial-gradient(50% 50%, ellipse

Now it’s time to give the gradient a size.

Size

If we are declaring the size of the gradient implicitly, we specify the size of the gradient shape using one of several keywords. Each of these keywords specifies an algorithm for giving the gradient a size. These algorithms are sometimes slightly different for ellipses and circles. While they may initially seem quite complicated, they make sense once you understand the key principle of each. Here’s my way of understanding what is going on with each keyword.

Keyword	For Circular gradients	For Elliptical Gradients
closest-side	with `closest-side` a circular gradient is sized so that it “exactly meets the side of the box closest to its center”	with `closest-side` an ellipse is sized so that it “exactly meets the vertical and horizontal sides of the box closest to its center”
closest-corner	with `closest-corner` a circular gradient is sized so that its edge exactly meets the closest corner to its center of the box	with `closest-corner` an elliptical gradient is sized so that its edge exactly meets the closest corner to its center of the box
farthest-side	with `farthest-side` a circular gradient is sized so that it “exactly meets the side of the box farthest from its center”	with `farthest-side` an elliptical gradient is sized so that it “exactly meets the vertical and horizontal sides of the box farthest from its center”
farthest-corner	with `farthest-corner` the gradient-shape is sized so that its edge exactly meets the farthest corner from its center of the box	with `farthest-corner` an elliptical gradient-shape is sized so that its edge exactly meets the farthest corner from its center of the box

There are two additional keywords, contain and cover. The keyword contain is the same as closest-side, while the keyword cover is the same as farthest-corner.
Here we’ll give our gradient a size of closest-corner.

background-image: radial-gradient(50% 50%, ellipse closest-corner,

As with the location of the center of the gradient, the two keyword values are separated by space, then followed by a commas

Color Stops

Now we’ve established the size, shape and location of the gradient, all that remains is for us to specify two or more color stops. As with linear gradients, we specify a color stop with a color, and an optional stop position, which is a length or percentage value. The simplest case is color values alone.
When color stops are specified with color values only, the stops divide the size of the gradient evenly. So, if there are 3 color stops, each color covers a third of the gradient shape, and fades into its adjacent color stop(s).
Let’s take a look at an example. Here’s a simple circular gradient. It’s implicitly sized to touch the closest size to its center, and has three color stops, red, green and blue

background-image: radial-gradient(center center, circle closest-side, #ff0000, #00ff00, #0000ff )

Notice how each stop is separated by a comma.
And here’s what it this will look like in a browser which supports radial gradients.

If we add more stops, these are simply evenly spaced in the same size, as here, where we have 6 color stops, evenly spaced across the size of the gradient.

background-image: radial-gradient(center center, circle closest-side, #ff0000 ,#ff9f40 ,#fff81f ,#050a99 ,#0b990f ,#911c99 ,#d24fe0 )

Color stops can, as we mentioned, optionally also specify a length or percentage value. So, we can make color stops a specific distance apart from one another, like so:

background-image: radial-gradient(center center, circle closest-side, #ff0000 25%, #19ff30 90%, #2f3ced 100%)

Notice again, the color and position of each stop is separated by a space, and again each stop is separated by a comma.
It’s also possible to use length values, like px and em in place of percentages, and to mix all three forms of color stop (color alone, percentage and lengths). Keep in mind that percentage gradients will adapt to the size of the element, so that when it grows or shrinks in size the gradient remains in proportion to the element’s size, and so in many cases, percentage gradient stops (or simple color stops specified only by color) are likely to be the most adaptable choice.

Coloring inside and outside the gradient

You might have noticed that in our examples, outside the gradient shape is a solid color background, the color being that of the last color stop specified. Once the gradient completes, whatever the finishing color is will then fill the remainder of the element’s background.
In this last example, you might also have noticed the same thing happens inside the gradient shape. Our first color stop is at 25%, so from the center of the gradient to 25% of its width, we have a solid red color. The red only fades smoothly into the next color stop, green, from 25% out from the gradient shape’s center.
Stop positions can in fact be greater than 100% of the size of the gradient, so we can fill the entire element with a gradient by specifying a final stop position large enough that the entire element is covered by the gradient.

Repeating gradients

As with linear gradients, radial gradients can repeat. This we specify with a slightly different value name — repeating-radial-gradient. If we take our previous gradient, and repeat it, here’s what we get

background-image: repeating-radial-gradient(center center, circle closest-side, #ff0000 25%, #19ff30 90%, #2f3ced 100%)

Where we would have solid color outside the gradient shape, we now have the gradient repeating. If we reduce the size of the gradient, the effect becomes more pronounced. In this example, we reduce the size of the gradient shape, to get the following non-repeating gradient.

background-image: radial-gradient(center center, circle closest-side, #ff0000 0%,#19ff30 29%)

Now if we repeat the gradient, the effect is far more noticeable.

background-image: repeating-radial-gradient(center center, circle closest-side, #ff0000 0%,#19ff30 29%)

Doing the heavy lifting for you

Shapes, sizes, centers, radii, stops… If it all sounds like a lot to learn and remember, then again we’re here to help. As we’ve done for linear gradients, we’ve built a radial gradient tool, which helps you build gradients, without having to remember all the heavy lifting.
As with our linear gradient tool, in addition to just helping you create radial gradient, it has some other features.

You can tweet a link to a gradient you’ve created by simply clicking a button
You can copy the url of your gradient, and send it to someone via email, put it in a link (like I’ve done for many of these examples) or otherwise share it
Via the magic of HTML5 localStorage, it remembers your most recent gradient, and other settings next time you visit
It adds vendor prefixes for all modern browsers (as an option)
It adds the start color as a background color for older browsers
There’s a related tool for creating old-style Webkit gradients
It provides up to the minute browser compatibility information (provided I remember to update that as browsers change)
It looks really pretty, all thanks to CSS gradients of course

So give it a try, and let us know what you think.

Browser Compatibility

Despite being relatively new, and as yet not completely specified, radial gradients are safe to use in a way that is backwards compatible, and are in fact quite widely supported (we’ll take a look at which browsers support them in a moment).
To ensure compatibility and accessibility when using radial gradients, as with linear gradients, it’s important to

include vendor specific prefixes (-o-, –ms-, –moz, –webkit-), as well as the standard form of gradient values
include a background color for browsers which don’t support gradients. Make sure the text of an element with a gradient background has sufficient contrast with the element’s background color

Browser support

A quick summary of current browser support for CSS Radial Gradients (based on the information at the fantastic When Can I Use).

Safari 4 introduced radial gradients, though as noted with a different syntax from that detailed here. The vendor prefix –webkit– is required for gradients in Safari 4.1 and newer.
Safari 5.1 introduces the syntax detailed here, as well as continuing to support the older style syntax. Again, the –webkit– vendor prefix is required.
Firefox 3.6 was the first browser to support the current gradient syntax. The –moz– prefix is required, and it’s currently only supported on backgrounds.
Chrome 10 and up (and probably earlier versions) supported the syntax for gradients detailed here. The –webkit– prefix is required.
Opera 11.1 introduced linear gradient support, but at present does not support radial gradients of any kind
Internet Explorer 10 also features CSS radial gradients, using the prefix –ms-, and also only on backgrounds.

Gradients can be computationally intensive, and may cause browsers running on older hardware difficulty. At present they are not able to be animated with CSS transitions in any browser which supports transitions.

Get Ready for HTML 5

2012-01-02T00:09:00.000-08:00

A List Apart: Articles: Get Ready for HTML 5

Get Ready for HTML 5

With support in Chrome, Firefox 3.5, Opera, and Safari, HTML 5 is coming at you like a runaway train. Here are some suggestions to help you prepare to get on board rather than be left at the platform or tied to the tracks.

See what others have done

The first thing you can do to prepare for HTML 5 is see how other people are using it. A visit to the HTML 5 gallery will show you how several sites are already using the new HTML 5 elements. Use the source, Luke!

Now you do it

You can look at the sites, read all the articles here and elsewhere, and even read the specification—but none of that will help you understand HTML 5 as much as using the new elements. You can modify part of an existing site or experiment by creating new pages. I did this myself by updating a trip report I made for friends and family. (I never intended it for public display, but here it is.)
By doing this, you’ll find out what works and what doesn’t. For example, I discovered that, as of this writing, Firefox 3.5 treats elements like article and section as display:inline, and I had to explicitly set them to display:block to make them work as expected.

X marks the spot

If you are like most designers, you probably don’t write all your markup by hand. But until the tools you use catch up to the new elements in (X)HTML 5, you will be doing some markup by hand while you learn. There’s been a bit of confusion (and controversy!) about the relationship between HTML 5, XHTML 1.0/1.1, and XHTML 5. Let’s clear that up right now.
HTML 4.0 (the markup language we all know and love) is based on a “rulebook” called SGML. In the SGML rulebook, element names are not case sensitive, you can have elements with optional closing tags (like <p>), and you can have attribute values without quotation marks. XHTML 1.0 and 1.1 are based on a rulebook called XML. In the XML rulebook, element and attribute names are case sensitive, every opening tag must have a closing tag, and attribute values must be quoted.
HTML 5 defines a markup language that isn’t based on either rulebook, but that can be written in either “HTML form” (or serialization, as the spec calls it) or “XHTML form.”
When you write markup in HTML form, you are allowed to leave off some closing (and opening!) tags, you don't have to quote attribute values if they don’t contain blanks, and element and attribute names aren’t case sensitive. You also get to use some of the XML markup; you can have a trailing slash on elements like <img /> or <hr />.
When you use the XHTML serialization, you have to follow the XML rules mentioned a few paragraphs ago.
I suggest that you write your markup in XHTML 5, or, if you use HTML 5, do the markup as if it were XHTML. You will be better off staying with the XML standard that requires a closing tag for each opening tag rather than spending your time optimizing markup for tags that have optional closing and/or opening tags. Similarly, quote all your attribute values rather than trying to decide when you can leave the quotes off. In addition to not having to waste neurons on those decisions, your markup will be more consistent.
Once the automatic markup generation tools catch up, you may still want them to generate XHTML 5 rather than HTML 5. Use of XML is forward-looking; its namespaces allow you to have “polyglot documents” that consist of multiple markups beyond the RDFa, MathML, and SVG of HTML 5. You can also use tools such as XPath, XSLT, and XQuery on XML-based markup, using any XML parser of your choice (though there is a Java-based parser that will process plain HTML 5).
Of course, it’s not all good news. If you do go with XHTML 5, remember that your server must deliver the documents with a MIME type of application/xhtml+xml or text/xml. This may involve negotiation with your hosting service. Also, when you deliver an XML file, any syntax error will cause an error message.

Fig. 1. XML parse error for mismatched tags.

If you are doing markup by hand, think of these error messages as a way to keep you honest. If you are using tools that create XHTML, there is no problem; the tools should always produce well-formed XML.

Regular expressions

HTML 5 extends the input element by offering new attributes that allow you to specify what data you will allow as input. These attributes include min and max (to set a numeric range), and HTML 5 also offers new values for the type attribute, such as url, email, date, and time.
If none of these new input types suits your needs, HTML 5 provides the pattern attribute for input elements with type="text". The value of the pattern attribute is a regular expression, as defined in ECMAScript and used in JavaScript. Regular expressions are a concise and perhaps somewhat cryptic way of specifying a pattern of characters. For example, if I want to match a five-digit or nine-digit US ZIP code or a six-character Canadian postal code, I can use this pattern:

([0-9]{5}(-[0-9]{4})?)|([A-Z][0-9][A-Z]\s+[0-9][A-Z][0-9])

The new web form capabilites are partially implemented in Safari and Chrome, and completely in Opera (see this site for browser capability information). Don’t worry if your browser does not yet support the form extensions for HTML 5; you can download Google’s Web Forms 2 and off you go!
Here is a sample form that validates a date and a postal code:

And here is the relevant markup:

<p>
Enter a date: <input type="date" name="day"
required="required"
title="Use format yyyy-mm-dd" />
</p>

<p>
Enter a US or Canadian Postal Code:
<input type="text" name="postCode"
required="required"
pattern="([0-9]{5}(-[0-9]{4})?)|([0-9][A-Z][0-9]\s+[A-Z][0-9][A-Z])"
title="US: 99999-1234; Canadian: 0A1&#160;B2C" />

</p>

Regular expressions are well worth the time it takes to learn them. Many text editors offer integrated regular expression search-and-replace features, and once you start using them, you’ll wonder how you ever got along without them.

Static art with SVG

Fig. 2. Image of SVG showing colored shapes.

If you want the crisp edges of vector-drawn art, HTML 5 allows you to embed SVG (Scalable Vector Graphics) in your documents. Putting SVG inline is partially implemented in Firefox, Safari, and Opera, according to this site.
You can already link to an SVG file in Firefox 3.5. That graphic is a bit complex—here’s a much simpler one (see Fig. 2) showing some simple colored shapes.
And here’s the SVG that generates it:

<svg xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg" 
viewBox="0 0 200 100"
width="200px" height="100px">

<circle cx="50" cy="50" r="30"
    style="stroke:none; fill:#ff0000;"/>

<g transform="translate(100, 20) scale(1.65)">
    <polygon points="36 25, 25 36, 11 36, 0 25,
        0 11, 11 0, 25 0, 36 11"
        style="stroke:none; fill:#0000ff;" />
</g>

<rect x="60" y="20" height="60" width="60"
    style="stroke:none; fill:#00ff00;
    fill-opacity: 0.5;" />   
</svg>

While it is possible to use JavaScript to dynamically modify an SVG graphic, HTML 5 provides a better solution:

The blank `canvas`

The canvas element is one of the most exciting features of HTML 5, and it’s supported by Firefox, Safari, Opera, and Chrome—but not Internet Explorer. (Color me surprised.) The canvas element is truly a forward-looking feature. You use JavaScript to draw whatever you need on this (literally) blank canvas.
Here’s the same graphic as the SVG graphic, only on a canvas:

Sorry, but your browser does not support <canvas> :(

And here’s the JavaScript that created it (with multiple statements per line to save space):

function drawSimpleCanvas() {
  var canvas =
    document.getElementById("simpleCanvas");
  if (canvas.getContext) {
    var ctx = canvas.getContext("2d");
    
    ctx.beginPath(); // the circle
    ctx.fillStyle = "#ff0000";
    ctx.arc(50, 50, 30, 0, 2*Math.PI, true);
    ctx.closePath();
    ctx.fill();
    ctx.save();
        
    // move and resize the octagon
    ctx.translate(100, 20);
    ctx.scale(1.65, 1.65);
    ctx.fillStyle = "#0000ff";
    ctx.beginPath();
    ctx.moveTo(36, 25); ctx.lineTo(25, 36);
    ctx.lineTo(11, 36); ctx.lineTo(0, 25);
    ctx.lineTo(0, 11); ctx.lineTo(11, 0);
    ctx.lineTo(25, 0); ctx.lineTo(36, 11);
    ctx.closePath();
    ctx.fill();
        
    // restore graphics as they
    // were before move and resize
    ctx.restore();
    ctx.fillStyle = "#00ff00";
    ctx.globalAlpha = 0.5;
    ctx.beginPath();
    ctx.rect(60, 20, 60, 60);
    ctx.closePath();
    ctx.fill();
  }
}

Here is a <canvas> that demonstrates simple user interaction:

Sorry, but your browser does not support <canvas> :(

Normally, you will use a canvas to display graphics that support your content. For example, saying “the mean of a set of numbers is the ‘center of gravity’ of that set” is fine, but using a canvas element with associated JavaScript to let the reader enter a set of numbers and show her that the mean is the “balance point” is much more effective.

These examples don’t even begin to show the scope of the canvas element’s capabilities. See Mozilla’s Canvas tutorial for a more thorough introduction as well as links to examples.

The CSS3 Selectors module and CSS3 Namespaces module

2012-01-01T23:59:00.001-08:00

The CSS3 Selectors module and CSS3 Namespaces module have both been released as official W3C recommendations, becoming the second and third CSS3 modules, respectively, to reach the end of the development cycle, following on from the release of the CSS3 Color module as a W3C recommendation earlier this year.

According to a post on the CSS Working Group’s blog:

Today W3C issued two new Recommendations: Selectors Level 3 and it dependency, CSS Namespaces. Selectors Level 3 has been a core part of CSS for awhile now, and is interoperably implemented by all modern browsers (including IE as of IE9). CSS Namespaces, which allows namespace-specific selectors, just completed its PR review phase, allowing both it and Selectors Level 3 to progress to W3C Recommendation.

The finalized specifications can be found here:
Selectors Level 3 – W3C Recommendation
CSS Namespaces – W3C Recommendation

Radial gradients

2012-01-01T23:58:00.000-08:00

I raised the issue that the radial gradients we were discussing were unreadable to me, and probably therefore to much of the intended audience. It was not at all obvious by looking at the gradient syntax what the various numbers and lengths might be.

radial-gradient(60% 43%, 25px 25px, #b03 99%, transparent)

So Tab Atkins, David Baron, Brad Kemper, Brian Manthos and I hashed out an alternative syntax.

radial-gradient(circle to 25px at 60% 43%, #b03 99%, transparent)

We’d like your opinion on which is preferred and why.

Examples
Current WD	Current ED
`radial-gradient(white, black)`	`radial-gradient(white, black)`
`radial-gradient(farthest-corner ellipse, center, white, black)`	`radial-gradient(ellipse to farthest-corner at center, white, black)`
`radial-gradient(top left, white, black)`	`radial-gradient(at top left, white, black)`
`radial-gradient(top left, farthest-corner ellipse, white, black)`	`radial-gradient(ellipse at top left to farthest-corner, white, black)`
`radial-gradient(circle, white, black)`	`radial-gradient(circle, white, black)`
`radial-gradient(circle, center, white, black)`	`radial-gradient(circle at center, white, black)`
`radial-gradient(center, 5em 5em, white, black)`	`radial-gradient(to 5em, white, black)`
`radial-gradient(center, 5em 5em, white, black)`	`radial-gradient(circle to 5em at center, white, black)`
`radial-gradient(75% 75%, closest-side circle, white, black)`	`radial-gradient(circle at 75% 75% to closest-side, white, black)`
`radial-gradient(25% 2em, 15px 30%, white, black)`	`radial-gradient(ellipse to 15px 30% at 25% 2em, white, black)`

The generic forms are (very roughly speaking):

General Syntax
Current WD	Current ED
`radial-gradient(position, [size \|\| shape], color-stops)`	`radial-gradient(shape [to size \|\| at position], color-stops)`
Shape/size and position are optional, unless the shape/size is given with explicit lengths, in which case the position must also be specified	Each of shape, size, and position are optional. The size and shape clauses can be reordered.

As a side effect, the keyword-based syntax more easily allows us to add other capabilities in the future. For example, offset radials could be expressed using a from position clause for the color origin.

Imagine a multi-column element

2012-01-01T23:55:00.001-08:00

We’ve got a bit of a tricky question on expected behavior of multi-column layout for you folks.
First, I want you to imagine a multi-column element. Like this one:

Now suppose that you want to use a column-spanning element. Column-spanning elements stretch across the entire multi-column element. Content before one balances into a short row of columns before it, and content after it continues in another row of columns after it. Like this:

Next, suppose you place two spanning elements, one after the other, like this:

Finally, suppose you gave each spanner a 1em vertical margin on both sides (margin: 1em 0). Remember that vertical margins between normal block-level elements collapse (so there would be only 1em gap between the two) whereas margins between stacked floating elements do not collapse (so there would be a 2em gap between the two).
In your ideal world, is there a 1em or 2em gap between the two elements?

Separate Margins (2em Gap)	Collapsed Margins (1em Gap)

Post your thoughts in the comment section, and we’ll forward them to the CSS Working Group.

Changes to Gradients Below is a summary of the major changes to CSS gradients over the past year:

2012-01-01T23:54:00.000-08:00

Below is a summary of the major changes to CSS gradients over the past year:

Angles in linear-gradient() changed from polar angles to bearing angles (compass directions). 0° now points up (bottom-to-top), and angles increase clockwise. See Angles in Gradients for the feedback that informed this decision.
Keyword directions in linear-gradient() changed from bare directional keywords (top, right, bottom, left) indicating the starting point to to ‹keyword› where the keyword indicates the endpoint. (to bottom, to left, to bottom, to left). This change was made because Tab felt having 0deg mean bottom-to-top made the fact that top meant top-to-bottom confusing. The WG was split but mostly ambivalent on whether this was necessary, or whether from ‹keyword› was a better alternative; the resolution landed on to ‹keyword›.
Corner-to-corner linear-gradient() has been redefined so that instead of aligning the gradient line to the diagonal, the central color occupies the other diagonal. See Behnam Esfabad’s post for a demonstration showing the old and new (“magic”) versions.
Syntax of radial-gradient() has been changed to (roughly) radial-gradient( [ ‹size› || ‹shape› ] [ at ‹position› ]?, ‹color-stop-list› ): specifically, the shape/size and position parameters are collapsed into the first argument using CSS property value conventions, allowing either or both to be specified. Position is distinguished from size by the preceding at keyword. See Radial Gradient Readability for some of the thinking that went into this change.

Other Features

Although CSS gradients are undoubtedly the most anticipated feature in CSS3 Images, there are a number of other features in this draft:

Media Fragments can be used to clip out part of an image and use it in CSS. The new image() notation, which can be used in place of url(), allows authors to trigger CSS parser fallback in older UAs when using media fragments.
The image() notation allows specifying a list of fallback images in various formats and allows annotating images with left-to-right or right-to-left directionality so that they flip automatically to match the element’s directionality.
The object-fit property allows preserving the aspect ratio of an image when assigning its box a specified size. In conjunction with the min/max-width/height properties, it also allows scaling the image and its box up to a given maximum, or down to a given minimum. The object-position property allows repositioning the image within its content box using background-positioning sytax when object-fit causes the aspect ratio of the image and the content box to mismatch.
The image-resolution property allows for using bitmap resolutions other than 1 image pixel == 1 CSS px unit.

Tools & resources for web professionals

2012-01-01T23:50:00.001-08:00

http://westciv.com/

Tools & resources for web professionals

5 Exciting Things to Look Forward to in HTML 5

2012-01-01T23:40:00.000-08:00

HTML 5 is the upcoming major revision of the HyperText Markup Language (HTML), the main method of marking up content for sharing on the World Wide Web. HTML's development stopped at HTML 4.01 in 1999, and since then web content has evolved so much that current HTML specifications are inadequate for today's requirements.
0diggHTML 5 aims to improve HTML's interoperability and address the growing demand for more diverse and complex web content. It also addresses HTML 4's lacking features for web applications. In this post, we'll look at 5 exciting new features in HTML 5.

A bit of history

The conceptual thinking for HTML 5 began in late 2003. The World Wide Web Consortium (W3C), the organization that oversees the web's standard protocols and guidelines, expressed interest in the HTML 5 draft originally developed by the Web Hypertext Application Technology Working Group (WHATWG), a group formed in 2004 consisting of representatives of Apple, the Mozilla Foundation, and Opera Software. As a result, the W3C HTML Working Group was formed in 2007 to develop the specifications of HTML 5.
Development is underway, and HTML 5 is anticipated to reach W3C Candidate Recommendation status in 2012, though many modern browsers already have partial support for HTML 5 specifications.

Exciting new features

1. New HTML elements that improve our ability to describe content
HTML's primary task is to describe the structure of a web page. For example, by enclosing text between <p></p> elements, HTML tells the browser that the text between those elements is a paragraph.

Increasingly, diverse web content has outgrown HTML 4's ability to accurately describe the content of a web page. Streaming video and audio is now commonplace. Website regions such as navigation menus and branding areas (commonly located in the header) are now staples of most web pages. More importantly, advancements in JavaScript, Flash, and server-side technologies have allowed for the proliferation of rich Internet applications (responsive, user-driven, browser-based applications), despite current HTML specifications.
By adding more HTML elements, HTML 5 aims to give developers a better and more precise way of describing data.
For example, under current HTML specifications, this is how we would describe the structure of a typical web page:

The problem with this layout is that, to the browser, everything is a <div> element. The browser treats everything inside the <div> elements equally because it can't tell the difference between them, and "classes" and "ids," such as content, sidebar, and footer, change from website to website.
In HTML 5, this is how you might describe the layout of the same web page:

In this markup, the browser now knows what each part is. It knows that the web page's main content is inside the <article> element, that the website's navigation is inside the <nav> element, and so on.
Besides prettier-looking and more semantic markup, the practical implications are endless. It increases our markup's interoperability. For example, an external system, such as a search engine spider, would be able to more accurately determine what content on a web page is important. It can skip crawling the <nav> element and the <footer> element because they probably do not contain the main content of the web page. A well-formed HTML 5 document would therefore give search engines a better understanding of the content being displayed.
A crafty developer could create an application that pulls out just the <article> section of a group of websites, say, to aggregate it in a database, or generate a list of all the videos on a web page by finding all the <video> elements.
Screen-reading software could give vision-impaired users a quicker way to traverse content sections. They could go to the <article> element directly if they wanted to read the main content of the web page, or go directly to the <nav> element if they wanted to navigate away from the page.

2. Improved web forms handling
These days, it's hard not to come across forms on websites. You encounter them when submitting a comment on a blog, registering for a user account, or sendinging mail in Gmail. HTML 5's proposed specifications include a huge revamping, called Web Forms 2.0, of how web forms would be handled. It gives web developers a lot of options and new features for effectively and easily handling input fields and form submissions.
The most exciting thing about Web Forms 2.0 is form validation. Currently, developers are required to use JavaScript (client-side) or PHP (server-side) code to validate inputs. For example, many web forms contain required fields (perhaps for the username and email fields):

In HTML 4, the markup of the web form above would look something like:

Currently, you have to use scripting to validate a user's submission. In this example, developers would have to write their own validation code (or use a pre-made script, such as this one) to ensure that required fields aren't left blank by accident or that submitted email addresses are valid (usually by doing something called "regular expression" matching).
In handling this form without requiring the author to include a validation script, HTML 5 (with the current Web 2.0 specifications) would give us additional element attributes, such as required and email attributes, which automatically check that the username and email fields are not left blank and that the email address' format is valid.

3. APIs for easier web application development
HTML 5 will introduce several application programming interfaces (APIs) to new and existing elements, aimed at improving web application development and addressing current issues with HTML 4's lack of ability to allow developers to mark up web applications.
One API is specifically for working with audio and video and will be used with the <audio> and <video> elements. It will provide audio and video playback capabilities and eliminate the need to use third-party applications, such as Flash, to develop and display media (at least for supported media files).

4. The <canvas> element allows image scripting on the fly
Most people take in information more quickly and effectively through visuals. For example, between a table, numerical data, and a pie chart, the pie chart gives users a better feel for the scale and relationship of data (at least most of the time).

The downside of images is that they're static. If you create a pie chart using a traditional method (for example, with an image editor like Photoshop, or a graphing application like Excel), you wouldn't be able to adjust any data that changes without manually editing your graphics.
With the <canvas> element, you can take constantly changing (database-driven) data and apply it to a pie chart like the one above, as well as other types of 2D visuals (even a cat, if you're so inclined), via scripting.
The canvas API also allows users to interact with <canvas> elements. For example, you can write a script that responds to users' clicking on a particular section of the pie chart.
5. Users can edit and interact with sections of a web page
The section in the proposed HTML 5 specifications about User Interaction describes new ways of marking up interactive web pages. The contenteditable attribute (a boolean attribute to which you assign either true or false) allows you to indicate which parts of a web page users can change.
This can be useful for wiki-style websites, in which content is user-generated. Another use of the contenteditable attribute would be to create web page templates. You can allow certain regions of a web page to be open to content editing and lock other regions that shouldn't be changed. This gives users of your website who aren't proficient in HTML an opportunity to input content safely without affecting critical areas that should be handled by more knowledgeable users.
At the document level, you can make an entire page editable via the designMode attribute, which accepts two values: on or off.

In Sum

The proposed specifications are slated to reach W3C Candidate Recommendation status in 2012, but that doesn't mean you have to wait that long to start using some of the new things in HTML 5. A lot of modern browsers, for example, have already implemented the <canvas> element (including Mozilla Firefox, which has partially implemented it since version 1.5).
HTML 5 will redefine how web developers mark up content. It will provide a better way to describe the content displayed on a web page, enable more complex content types, improve media and web application support, and increase the interoperability of HTML documents.
Note that things are still under heavy development and are bound to change; many of the proposed improvements may be heavily revised in the next few years or not implemented at all.
There are a lot of exciting new features in HTML 5. Share your own favorites in the comments.

Top 10 Tips for E-Commerce Sites

2012-01-01T23:33:00.000-08:00

1. DON’T FORCE YOUR VISITORS TO THINK

Ensure your site has intuitive navigation and usable site architecture, not just an appealing look and feel. Visitors should be able to accurately guess what a button or link does before clicking on it.The search function (you do of course have one!) should appear in the navigation bar, preferably at the top right, where users expect to see it — and not as a button but as a type-in field, which saves the visitor from having to go to a search page to do their search.

Upon a keyword search, automatically check spelling and, when appropriate, suggest corrections. If their search is too generic, suggest alternatives (for example,”You just searched for ‘cameras.’ If you’d like, you could try a more specific search like: ‘ canon eos cameras” ‘nikon digital cameras,’ … “).

2. LEAVE A TRAIL

Incorporate “breadcrumb navigation” into your online catalog pages. This will show where in the site hierarchy the currently viewed web page is located and it will give the visitor shortcuts to instantly jump higher up the hierarchy (for example, “Online Catalog > Home Furnishings > Lighting > Table Lamps”). It’s good practice for usability and for search engine optimization.

3. CUT TO THE CHASE

Make maximum use of screen real estate to minimise scrolling. Put the most important stuff (like your 0800 number) “above the fold.” Minimize the number of steps required to locate products and make purchases. Amazon.com’s 1-Click ordering is the epitome of efficiency.

4. BE A LIGHTWEIGHT

Optimise images for small file sizes and fast downloads, strip out extraneous HTML and remove unnecessary graphics. Ideally, a page should load in less than 10 seconds.

5. BE OPEN TO ‘OPEN SOURCE’

Don’t waste budget on unnecessarily expensive software license when an open-source solution exists. Open source offers a highly customizable, stable and low- or no-cost alternative to proprietary software.

6. STUDY YOUR CUSTOMER’S EVERY MOVE

Watch how your customers use your website and learn what frustrates them. Analise your visitor’s traffic patterns (for example, what are the top exit pages, what are the most popular searches that return results), invite customers to complete a survey after they purchase and have informal brainstorming sessions with your most valuable customers.

7. DELIGHT YOUR CUSTOMERS

Service your customers like your survival depends on it, because it probably does. Reply to email within hours. Keep your commitments to your customers; make “under-promise and over-deliver” your mantra. If your site promises delivery in three days, that doesn’t mean five or 10.

You’ll also need 24-hour server support to effectively manage traffic surges.

8. SING TO THE SEARCH ENGINES

Each product or category page has its own unique “song” and should be made to “sing” for its own set of keywords. Your home page can’t be everything to everybody; it can’t be ranked in the top 10 for every product your online shop carries. The numerous pages that make up your online catalog can serve as a virtual sales force.

To illustrate, the home page of Netconcept client SmokeCDs.com ranks in the top 10 in Google for “buy CDs” but it’s their category pages that rank well for genres like “drum and bass music,” and product pages that rank well for artists like “Trick Daddy” and albums like “The Matrix Soundtrack.”

However, there’s no point in making your pages sing if they aren’t being picked up by the search engine spiders. Some of America’s largest online cataloger have problems getting their full catalogs fully indexed by the major search engines, as detailed in our analyst report The State of Search Engine Cataloging 1.0 (published by Catalog Age).

SmokeCDs.com has tens of thousands of product pages in Google, whereas major US music retailer SamGoody.com only has a few hundred. Check how many pages your site has in the major search engines with the free tool at http://web.archive.org/web/20040708075116/.

The best results are achieved when spider-friendliness and search engine optimisation are built into the site from the ground up rather than added as an afterthought.

9. FLOG YOUR PRODUCTS

Merchandising on the web means making clever use of your virtual shelf space. Choose some products to feature on your home page and rotate through them.

Consider having a “Top 10 List” of products (as in the top 10 products you most want to sell). People are like lemmings when it comes to top 10 lists.

Also offer related product recommendations and user-contributed reviews on each of your product pages. Consider promoting limited-time, limited-use special offer codes as a way to stimulate sales.

10. BE FULLY FUNCTIONAL

For starters, visitors should be able to add items to a “shopping cart.” Furthermore, they should be able to abandon their carts and and return days later and still have the cart intact.

They should also be able to create user accounts for ease of repeat ordering and checking order status.

If it’s a consumer site, they should be able to buy and redeem gift certificates.

Online ordering should of course be secure, with a 128-bit secure server certificate installed.

Finally, hopefully you have an admin interface that allows you to add, remove and update website content yourself.

Also, regarding the up-and-coming trend for e-commerce sites to offer online forums and the question of how they can add to the site’s value proposition and also serve as search engine fodder, here’s an example of one Netconcepts did.

Five Technologies That Will Keep Shaping the Web

2012-01-01T23:24:00.001-08:00

As we’re coming to the end of this year, everyone starts to look towards the next one and there will no doubt be an upsurge of articles predicting the web trends of 2010 in the next days to come. However, in this article, we’ll be talking about what’s actually driving these trends now, and what they mean for the future of the internet.

1. CSS3, HTML5 and Fonts as a Service

CSS3, HTML5, and Fonts as a Service such as Typekit that cater to web browsers that already support the @font-face rule, are giving web designers the creative freedom that they have been coveting for a long time.
CSS3 is opening up various new options for styling content on the web, from multiple backgrounds on page elements, better ability to select and style elements with greater specificity, and color gradients without reliance on static graphics, to simpler aesthetical improvements such as support for rounded corners without the need for complicated sliding doors techniques or JavaScript.
HTML5 is slowly but surely changing the way we mark up our pages, bringing us closer to the holy grail of the semantic web, opening up native support for open format multimedia such as video and audio, and bringing us better ways to interoperate with the content of a website.
Another change that web designers have been wishing for is being able to use any font on a web page, without using static CSS background image replacement or relying on JavaScript and Flash. The development of tools like Typekit and greater support for the @font-face rule are enabling site builders to use a much wider range of fonts in their design.

So what will change?

These are all web technologies that are guaranteed to make the web a more aesthetically pleasing place. Of course, expect these new things to be misused by Sunday driver designers; there will be some horrible font choices and misemployed color gradients that will produce unreadable and tacky page designs, but it’s the opportunities that they open up for capable and creative designers that will be most

Ajax: A New Approach to Web Applications

2012-01-01T23:20:00.000-08:00

If anything about current interaction design can be called “glamorous,” it’s creating Web applications. After all, when was the last time you heard someone rave about the interaction design of a product that wasn’t on the Web? (Okay, besides the iPod.) All the cool, innovative new projects are online.
Despite this, Web interaction designers can’t help but feel a little envious of our colleagues who create desktop software. Desktop applications have a richness and responsiveness that has seemed out of reach on the Web. The same simplicity that enabled the Web’s rapid proliferation also creates a gap between the experiences we can provide and the experiences users can get from a desktop application.
That gap is closing. Take a look at Google Suggest. Watch the way the suggested terms update as you type, almost instantly. Now look at Google Maps. Zoom in. Use your cursor to grab the map and scroll around a bit. Again, everything happens almost instantly, with no waiting for pages to reload.
Google Suggest and Google Maps are two examples of a new approach to web applications that we at Adaptive Path have been calling Ajax. The name is shorthand for Asynchronous JavaScript + XML, and it represents a fundamental shift in what’s possible on the Web.

Defining Ajax

Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:

standards-based presentation using XHTML and CSS;
dynamic display and interaction using the Document Object Model;
data interchange and manipulation using XML and XSLT;
asynchronous data retrieval using XMLHttpRequest;
and JavaScript binding everything together.

The classic web application model works like this: Most user actions in the interface trigger an HTTP request back to a web server. The server does some processing—retrieving data, crunching numbers, talking to various legacy systems—and then returns an HTML page to the client. It’s a model adapted from the Web’s original use as a hypertext medium, but as fans of The Elements of User Experience know, what makes the Web good for hypertext doesn’t necessarily make it good for software applications.

Figure 1: The traditional model for web applications (left) compared to the Ajax model (right).
This approach makes a lot of technical sense, but it doesn’t make for a great user experience. While the server is doing its thing, what’s the user doing? That’s right, waiting. And at every step in a task, the user waits some more.
Obviously, if we were designing the Web from scratch for applications, we wouldn’t make users wait around. Once an interface is loaded, why should the user interaction come to a halt every time the application needs something from the server? In fact, why should the user see the application go to the server at all?

How Ajax is Different

An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary—an Ajax engine—between the user and the server. It seems like adding a layer to the application would make it less responsive, but the opposite is true.
Instead of loading a webpage, at the start of the session, the browser loads an Ajax engine—written in JavaScript and usually tucked away in a hidden frame. This engine is responsible for both rendering the interface the user sees and communicating with the server on the user’s behalf. The Ajax engine allows the user’s interaction with the application to happen asynchronously—independent of communication with the server. So the user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something.

Figure 2: The synchronous interaction pattern of a traditional web application (top) compared with the asynchronous pattern of an Ajax application (bottom).
Every user action that normally would generate an HTTP request takes the form of a JavaScript call to the Ajax engine instead. Any response to a user action that doesn’t require a trip back to the server—such as simple data validation, editing data in memory, and even some navigation—the engine handles on its own. If the engine needs something from the server in order to respond—if it’s submitting data for processing, loading additional interface code, or retrieving new data—the engine makes those requests asynchronously, usually using XML, without stalling a user’s interaction with the application.

Who’s Using Ajax

Google is making a huge investment in developing the Ajax approach. All of the major products Google has introduced over the last year—Orkut, Gmail, the latest beta version of Google Groups, Google Suggest, and Google Maps—are Ajax applications. (For more on the technical nuts and bolts of these Ajax implementations, check out these excellent analyses of Gmail, Google Suggest, and Google Maps.) Others are following suit: many of the features that people love in Flickr depend on Ajax, and Amazon’s A9.com search engine applies similar techniques.
These projects demonstrate that Ajax is not only technically sound, but also practical for real-world applications. This isn’t another technology that only works in a laboratory. And Ajax applications can be any size, from the very simple, single-function Google Suggest to the very complex and sophisticated Google Maps.
At Adaptive Path, we’ve been doing our own work with Ajax over the last several months, and we’re realizing we’ve only scratched the surface of the rich interaction and responsiveness that Ajax applications can provide. Ajax is an important development for Web applications, and its importance is only going to grow. And because there are so many developers out there who already know how to use these technologies, we expect to see many more organizations following Google’s lead in reaping the competitive advantage Ajax provides.

Moving Forward

The biggest challenges in creating Ajax applications are not technical. The core Ajax technologies are mature, stable, and well understood. Instead, the challenges are for the designers of these applications: to forget what we think we know about the limitations of the Web, and begin to imagine a wider, richer range of possibilities.
It’s going to be fun.

Ajax Q&A

March 13, 2005: Since we first published Jesse’s essay, we’ve received an enormous amount of correspondence from readers with questions about Ajax. In this Q&A, Jesse responds to some of the most common queries.
Q. Did Adaptive Path invent Ajax? Did Google? Did Adaptive Path help build Google’s Ajax applications?
A. Neither Adaptive Path nor Google invented Ajax. Google’s recent products are simply the highest-profile examples of Ajax applications. Adaptive Path was not involved in the development of Google’s Ajax applications, but we have been doing Ajax work for some of our other clients.
Q. Is Adaptive Path selling Ajax components or trademarking the name? Where can I download it?
A. Ajax isn’t something you can download. It’s an approach—a way of thinking about the architecture of web applications using certain technologies. Neither the Ajax name nor the approach are proprietary to Adaptive Path.
Q. Is Ajax just another name for XMLHttpRequest?
A. No. XMLHttpRequest is only part of the Ajax equation. XMLHttpRequest is the technical component that makes the asynchronous server communication possible; Ajax is our name for the overall approach described in the article, which relies not only on XMLHttpRequest, but on CSS, DOM, and other technologies.
Q. Why did you feel the need to give this a name?
A. I needed something shorter than “Asynchronous JavaScript+CSS+DOM+XMLHttpRequest” to use when discussing this approach with clients.
Q. Techniques for asynchronous server communication have been around for years. What makes Ajax a “new” approach?
A. What’s new is the prominent use of these techniques in real-world applications to change the fundamental interaction model of the Web. Ajax is taking hold now because these technologies and the industry’s understanding of how to deploy them most effectively have taken time to develop.
Q. Is Ajax a technology platform or is it an architectural style?
A. It’s both. Ajax is a set of technologies being used together in a particular way.
Q. What kinds of applications is Ajax best suited for?
A. We don’t know yet. Because this is a relatively new approach, our understanding of where Ajax can best be applied is still in its infancy. Sometimes the traditional web application model is the most appropriate solution to a problem.
Q. Does this mean Adaptive Path is anti-Flash?
A. Not at all. Macromedia is an Adaptive Path client, and we’ve long been supporters of Flash technology. As Ajax matures, we expect that sometimes Ajax will be the better solution to a particular problem, and sometimes Flash will be the better solution. We’re also interested in exploring ways the technologies can be mixed (as in the case of Flickr, which uses both).
Q. Does Ajax have significant accessibility or browser compatibility limitations? Do Ajax applications break the back button? Is Ajax compatible with REST? Are there security considerations with Ajax development? Can Ajax applications be made to work for users who have JavaScript turned off?
A. The answer to all of these questions is “maybe”. Many developers are already working on ways to address these concerns. We think there’s more work to be done to determine all the limitations of Ajax, and we expect the Ajax development community to uncover more issues like these along the way.
Q. Some of the Google examples you cite don’t use XML at all. Do I have to use XML and/or XSLT in an Ajax application?
A. No. XML is the most fully-developed means of getting data in and out of an Ajax client, but there’s no reason you couldn’t accomplish the same effects using a technology like JavaScript Object Notation or any similar means of structuring data for interchange.
Q. Are Ajax applications easier to develop than traditional web applications?
A. Not necessarily. Ajax applications inevitably involve running complex JavaScript code on the client. Making that complex code efficient and bug-free is not a task to be taken lightly, and better development tools and frameworks will be needed to help us meet that challenge.
Q. Do Ajax applications always deliver a better experience than traditional web applications?
A. Not necessarily. Ajax gives interaction designers more flexibility. However, the more power we have, the more caution we must use in exercising it. We must be careful to use Ajax to enhance the user experience of our applications, not degrade it.
This entry was posted on Friday, February 18, 2005 at 3:36 am, and is filed under Technology and Trends.

Top 10 Business Web Site Mistakes inShare1 Share4 Print Print Source: http://www.allbusiness.com/technology/internet-web-development/4015-1.html#ixzz1iHbW44Wk

2012-01-01T23:18:00.000-08:00

Today it takes more than just having a Web site to make the Internet work for your company. Sites are highly competitive, and proper site design has become an area of concern to businesses that want to use the Internet to the fullest. Below are 10 common Web site errors that occur.

Inappropriate domain name: Pick a domain name that is memorable and relates to your business. Since people are likely to forget very long names, shorter domain names are typically better, but not always. For example, a name like Peter.com can be too vague and says nothing about the content of the Web site.
Poor design and functionality: Why have a Web site with content if no one can access it? Good design is largely based on consistency. Menus should appear in the same place on every page, links should all be the same color/typeface, and a logo of some sort should be clearly visible at all times.
Too complicated or too slow: Although flash animation may look amazing, it may be too complex for casual Internet users. Though aesthetics certainly matter, it must be in balance with functionality and ease of use for the typical user. Also, a more complex design takes longer to load on many computers.
Stagnant site: Not only is content time-sensitive, so is format and design. There will always be new tools available to make Web sites better looking and better performing. It is not cost-effective to create a Web site and let it sit. Update content regularly and take advantage of (appropriate) new technologies to make the site look better.
Broken links and 404 error messages: Make sure every link on your site works. You'll lose users quickly if they see a "404 file not found" error message or find broken or incorrectly labeled links. If you have a large site, consider adding a form so users can submit a broken link, which lets users know you are on top of any problems they discover.
No contact info: Users need to be able to contact you with questions, complaints, and suggestions. A Contact Us page, like an Internet business card, should be available from any part of your site. Also, be sure to actually answer these messages either personally or through an auto-reply.
Ignoring statistics: Detailed reports of visitor traffic are available for your Web site. This service may be offered by your hosting provider or obtained through a third party. By monitoring your statistics (such as visitors-turned-customers, users on broadband, etc.) you can tailor your marketing and design toward those who visit most or find weak spots based on who you are not attracting.
Free or cheap hosting: As attractive as some of these services are, realize that the reliability of your business depends on the reliability of your hosting. A good host service should have minimal downtime, offer services such as shopping cart systems, and have good customer support. Be sure to read reviews and apply for free trials (if possible) before you commit to anything.
Avoiding spiders: Spiders are what search engines use to find your page. You want to make sure your pages are designed so that you show up high on search engine rankings. This process is called search engine optimization. There are, however, ethics and strategies to SEO. Some practices (such as hidden text, redirects, etc.) will result in you being banned from search engines.
Not hiring a professional: Search engine optimization is complex. To move up in the listings on Google and other search engines, you may want to hire a professional, especially if your business relies heavily on generating business from the Web.

For more information, check out the Internet and WWW section of AllBusiness.com's Internet & E-commerce Center.

Source: http://www.allbusiness.com/technology/internet-web-development/4015-1.html#ixzz1iHbfzHtN

Web Design, Development, Managment and Analysis

Create an Image Rotator with Description (CSS/jQuery)

Create an Image Rotator with Description (CSS/jQuery)

Creating an Image Rotator

Step1. HTML – Image Rotator Wireframe

Title

Title

Step 2. CSS – Image Rotator Wireframe

Step3. jQuery – Image Rotation Effect

Conclusion

An Introduction to CSS 3-D Transforms

Rationale

Current support

Perspective

3-D transform functions

Card flip

Slide-flip

Cube

Returning to the Z-axis origin

Rotating the cube

Rectangular prism

Carousel

Conclusion

New form features in HTML5

Introduction

Bad form?

Introducing our example

New form controls

<input type="number">

<input type="range">

<input type="date"> and other date/time controls

<input type="color">

<input type="search">

<datalist> element and list attribute

<input type="tel">, <input type="email"> and <input type="url">

New attributes

placeholder

autofocus

min and max

step

New output mechanisms

<output>

<progress> and <meter>

Validation

required

type and pattern

Styling with CSS3

Cross browser?

Part1: Introducing Android 4.0 - Simple, Beautiful, Useful

Introducing Android 4.0

Simple, Beautiful, Useful

Refined, evolved UI

Home screen folders and favorites tray

Resizable widgets

New lock screen actions

Quick responses for incoming calls

Swipe to dismiss notifications, tasks, and browser tabs

Improved text input and spell-checking

Powerful voice input engine

Control over network data

Designed for accessibility

Communication and sharing

People and profiles

Unified calendar, visual voicemail

Rich and versatile camera capabilities

Redesigned Gallery app with photo editor

Live Effects for transforming video

Sharing with screenshots

Cloud-connected experience

Powerful web browsing

Improved email

Innovation

Android Beam for NFC-based sharing

Face Unlock

Wi-Fi Direct and Bluetooth HDP

First Data Global Payment Gateway for Magento by Booklink

Magento Go, Part 5: Configurable Products - Managing Images

Creating Accessible JavaScript

Overview of Creating Accessible JavaScript

Article Contents

`<input type="number">`

`<input type="range">`

`<input type="date">` and other date/time controls

`<input type="color">`

`<input type="search">`

`<datalist>` element and `list` attribute

`<input type="tel">`, `<input type="email">` and `<input type="url">`

`placeholder`

`autofocus`

`min` and `max`

`step`

`<output>`

`<progress>` and `<meter>`

`required`

`type` and `pattern`

`onMouseOver` and `onMouseOut`

`onFocus` and `onBlur`

`onClick` and `onDblClick`

`onChange` and `onSelect`

`onChange` example

Using `document.write`

`document.write` example

Using the `<noscript>` Element

`<noscript>` example