Posts Tagged ‘HTML’

Web 3.0: Why Flash is not Needed

Friday, February 6th, 2009

As an avid supporter of next generation web technologies and envisioning a web free from plugins and browser dependence, I believe strongly that Flash will not be needed as we move into a Web 3.0 world.  The upcoming features being discussed, implemented, and standardized all help to simplify developer responsibilities that were typically done using Flash.  Even though there are use cases where Flash is useful, the vast majority are not and only require the user to install Flash as a plugin.  In some cases, such as the iPhone, Flash is not even a viable option.  As a result, your website will not function on these next generation devices.

That being said, here are my reasons of why Flash is not needed and alternatives using next generation technologies.

1. Canvas

Canvas provides a 2D/3D drawing surface on an HTML page in which you can do almost anything that a standard thick client application (or Flash) would do.  For instance, you can draw lines, shapes, even create reflections.  For example, on Apple’s me.com gallery page, they use canvas to provide a coverflow effect.  The flot jquery charting library uses canvas to create dynamic graphs.  Functionality with canvas is endless, especially when combined with Javascript.  The developer can use the two to create dynamic animations otherwise only possible with plugins such as flash.  As canvas grows in support from browsers (ie: Internet Explorer does not natively support it yet), more libraries will be available to the developer for creating rich features.

2. Javascript Performance

Current generation browsers have old stack-based implementation of javascript that was slow compared to the engines of tomorrow (and in some cases today).  These implementations were good for the Web 1.0/2.0 days where javascript was simple.  However, as sites continue to grow in complexity, features, and richness, javascript performance becomes a bigger deal.  The performance is already hindering many sites causing them to render slowly or to degrade usabilitiy.  Most of the major browsers already have an improved javascript engine in either release or beta including Firefox, Safari, Chrome, and Opera.

3. CSS Animations

Apple Safari, via Webkit, has begun to introduce and propose an extension to CSS for animations.  The animations use a set of keyframes and settings to smoothly create dynamic animations.  This is very similar to what many users do in flash by defining keyframes and then let Flash automatically create the inner frames for a smooth effect.  Webkit does this for several CSS-based settings including color, transparency, positioning or offsets, and even rotations.  Mixing these animations with CSS selectors, you can create a dynamic animation without any javascript code.  Combine javascript and even canvas, you get extremely rich and powerful sites.  Best of all is that you do not require any plugins and will work on any next generation browser as browsers adopt.

4. Media

The upcoming HTML5 specification defines a new set of media tags for adding media content to pages, such as video or audio.  Typically, video players have been created using flash as the only viable option.  Once HTML5 becomes standard, you can simply drop a tag on the page, define the source and options, and automatically you get a player, without requiring flash.  Combine javascript, custom buttons, etc, you can create dynamic video players.

5. Javascript Libraries

Javascript libraries continue to evolve and provide a powerful environment for developers to create rich applications, especially in the UI arena.  For example, jQuery, Yahoo! UI, Dojo, MooTools, etc all provide complex UI elements and inputs for next generation sites.  Further, with the HTML5 set of new input elements (date selectors, time selectors, spinners, etc), you get native browser control.

These are just a few of the reasons of why the next generation web can be plugin free and still allow richer sites that will thoroughly impress your users without sacrificing usability or dependencies.

CSS Sprites

Saturday, October 18th, 2008

I decided to take the plunge and begin making my site more YSlow compliant. I had already enabled GZip through a custom GZip filter and browser caching for static resources. My next task was to limit the number of resources being served. My first part here was first minifying and combining all javascript and CSS resources. This reduced the number of requests to two for these types of resources. Next was background images. The best way to do this is by using sprites. A sprite is an image that includes one or more other images. CSS is then used to provide offsets into the sprite where the image is actually defined. As a result, you only need a couple of images rather than many. Within my site, this makes a drastic improvement with all the unique background images I use.

I decided to look for an automated tool to convert my CSS and background images automatically. In my findings I came across the utility SmartSprites. This utility uses CSS comments to annotate the CSS file with information about how to create the sprites. Once completed, it processes the CSS file and all images and creates an updated CSS file and sprite images. The CSS updates include the proper background-position attributes that declare the associated offsets. All in all, it was a very useful tool that I highly recommend. It got my images from 15+ to 3 without the hassle of manually creating the sprites.

In using the tool however, I had a couple of issues (which is more of my ignorance for not reading the documentation :) Anyways, here are some helpful tips and advice.

First, the tool uses Ant to launch the process. However, not enough memory wasallocated to the JVM which caused OutOfMemory errors for me. Note that not everyone will need to handle this step. Unfortunately I took several images on my site into one large sprite, so I needed the extra memory. To resolve the memory issues, I merely provided Ant more memory (-Xmx1g) to ensure I had plenty. I did this by creating an antrc_pre.bat file in my home directory with the line:

SET ANT_OPTS=-Xmx1g

Once I had enough memory, I was now ready to start annotating. The first thing I did was define the sprite references at the top of the CSS file. The sprite references allow you to use multiple sprites in the same file. Note that the examples below appear to wrap the lines. Unfortunately that is an issue with the blog software. All examples below should be on a single line in the CSS without wrapping.


/** sprite: sprite; sprite-image: url('../images/sprite.png'); sprite-layout: vertical */

The sprite-layout defines which way to layout images within the sprite. For standard images, this is not important. However, for images with background-repeat, it is very important as CSS and browsers use the image to repetitively show the image over and over. If using the wrong layout, you will get very unexpected results. The best thing to do here is to use three sprites: one for non-repeating images, one for repeat-y based images, and a third for repeat-x images. For example:


/** sprite: sprite; sprite-image: url('../images/sprite.png'); sprite-layout: vertical */
/** sprite: repeatx; sprite-image: url('../images/sprite-horizontal.png'); sprite-layout: vertical */
/** sprite: repeaty; sprite-image: url('../images/sprite-vertical.png'); sprite-layout: horizontal */

Again, make sure those examples are on three separate lines without wrapping. Now that we have our sprites defined, we can being applying to CSS classes. The proper way to do this is to apply a comment after the associated background-image line. You will use the proper sprite reference depending on the type of background repetition.

If using a non-repeating image, use the following example:


.css-class
{
background-image: url('../images/image.jpg'); /** sprite-ref: sprite; */
background-repeat: no-repeat;
}

This example uses a relative path (highly suggested if not required) to obtain the image. In my setup I used a directory structure such as:

build
+ styles
- style.css
+ images
- image.gif

If using repeating images, use one of the following examples:


.repeat-x
{
background-image: url('../images/image.jpg'); /** sprite-ref: sprite; sprite-alignment: repeat; */
background-repeat: repeat-x;
}
.css-class
{

background-image: url(’../images/image.jpg’); /** sprite-ref: sprite; sprite-alignment: repeat; */
background-repeat: repeat-y;
}

Again, verify that the comments are on the same line as the background image without wrapping. With each image properly annotated, we can now build our updated stylesheet and sprites. To do so, just execute the ant process command (make sure to update the build.properties file first). If everything goes according to plan, you should now have new sprite images and stylesheets that you can use in your layouts.

Here are some things to consider before annotating images. If the image is only used on one or a few pages (such as titles, headers, etc), consider not annotating these images unless very small. If the images are large in size, you will end up with a very large sprite which will reduce performance. In such a case you are better off just having those few pages use another image that will be cached.

HTML5 Adoption via Emulation

Saturday, October 11th, 2008

The biggest issue right now with web related specifications is browser adoption. The specs clearly state that at least two mainstream browsers must implement the standard to be considered complete. In most cases that tends to be Firefox, Opera, Safari, and Internet Explorer. The first of these three has always been adapt to adopting standards. The latter is only just beginning to catch up. This results in most of the web authors in the community from not utilizing new features as it results in having to maintain different sites for different browser capabilities. So, how do we change this?

First, as web authors, we need to start showing the promise of future specs like HTML5 in order for browser vendors to realize the promise and create a higher urgency to update their applications. But how can we implement new HTML 5 features without browser support? The answer to that is through emulation. If you look at many of the libraries already on the web, much of this is already in the works, even if not explicitly stated. For example, Google Gears allows authors to utilize the new HTML5 storage support. Javascript libraries such as jQuery support future CSS 3 selectors. The dojo javascript library provides many of the networking stacks and future AJAX support. The piece that is missing is a full emulation layer the builds on those already available but allow a document to be built on HTML5 and rendering the result on the client side.

Imagine the advancement for authors if an emulation layer existed. For example, rather than having to use the APIs within existing libraries to create a calendar control, you could simply drop a date input onto the page via HTML5’s <input type=”date” />. The emulator would pick up that tag and properly utilize the libraries to build the control. This simplifies author development, starts to show the promise of HTML 5, and helps the end user by providing the new features of HTML5. Similar to how browsers adapt pieces of the spec at a time, this emulation layer could provide the same result. However, rather than having to rely on browser developers to find time to build the feature, the emulation layer can use the open source community and the already existent libraries to more quickly adapt features. The features would be smart in that they would fall back to the native browser support, if provided. It would only emulate when non-compliant browsers are used. The end result of all of this is that we build HTML5 pages today and can easily drop the emulation libraries once full support is provided.

I plan to eventually create an open source project and host it to the open source community in order to drive this into existence.  Over the next month I will be analyzing the HTML 5 spec and the already existent libraries to determine some various paths to proceed under.  If anyone is interested in joining, shoot me an email or a comment.  You can follow all of my progress on this blog.