Fast Performing Photo Galleries With Galleriffic jQuery Plugin

Galleriffic is a jQuery plugin that provides a rich, post-back free experience optimized to handle high volumes of photos while conserving bandwidth. It is easy to implement, cross browser, highly customizable, supports graceful degradation and allows you to add multiple galleries per page.

Features include: smart image preloading after the page is loaded; thumbnail navigation (with pagination); jQuery.history plugin integration to support bookmark-friendly URLs per-image; slideshow (with optional auto-updating url bookmarks); keyboard navigation; events that allow for adding your own custom transition effects; API for controlling the gallery with custom controls; support for image captions.

Developed by Trent Foley; Galleriffic jQuery Plugin is available for download under MIT License.  You can find further information, demos & download on Galleriffic jQuery Plugin Website.

Similar Posts:

• SimpleViewer – Flash Image Gallery
• SlideItMoo MooTools Slider Plugin
• Customizable Animated Slideshow With YUI Slideshow
• Supersized – Full Screen Background Slideshow
• AD Gallery – jQuery Gallery Plugin

You can also stay updated by following us on Twitter, becoming a fan on Facebook or by subscribing to our FriendFeed.

Tags: Gallery/Carousel/Slider, MIT License, Photo Gallery, Trent Foley

Playing with JQuery Validation Library, Part 2

Background: JQuery Validator is JQuery plug-in for validating html form fields.  Microsoft has included the JQuery Validator as part of Microsoft’s new CDN, and it looks like JQuery and JQuery Validator will both be included with Asp.Net MVC 2.  You can find Part 1 here.

From where we left off, the next thing to do is validate a field via a web service. 

AJAX Validation

There are actually two ways of validating fields via an ajax call.  The first one I’ll show it the built in way.  The second is more of a hack, but gives a good background on what is actually going on with the JQuery Validator.

So in part 1 we showed how to do simple validations of a form.  We will start with a simpler form for this example:

   1: <form id='UserNameForm'>

   2:     <input id='userNameEdit' type='text' />

   3:     <button type='submit'>Submit</button>

   4: </form>

Obviously the form can be more complex, but I like starting simple.

The JQuery Validation script should look something like this:

   1: $('#UserNameForm').validate({

   2:     rules: {

   3:         userNameEdit: { required: true }

   4:     }

   5: });

That script will make sure there is something in userNameEdit.  But now we want to make sure the user name is unique in the system.  So to start, I need a web service to call.  For this example, I’m using Asp.Net MVC.

   1: public JsonResult VerifyUserName(string userNameEdit)

   2: {

   3:     return Json(true);

   4: }

OK, a few things about the web service above.  1.  in the current implementation, all user names are valid.  That is the Json(true).   If you want to see the failure case, change it to Json(false).  2. look at the method parameter.  It is the same name as the form field.  That is a convention in the JQuery Validator, and near as I can tell you cannot override that behavior.   Third: JsonResult stipulates that the method will return its data in the Json format. Unlike other web method types, where the output type come from the caller, this one only returns the specified format.

Validation Method 1: remote

Now, lets modify our script from above to call that web method:

   1: $('#UserNameForm').validate({

   2:     rules: {

   3:         userNameEdit: { required: true, remote: "<%=Url.Action("VerifyUserName", "Account") %>" }

   4:     }

   5: });

The new part is the remote in the script.   You give it the name/location of your web service to call to validate the field, and the field name/value are passed in. 

Now about the Url.Action bit in there…If you are not used to Asp.Net MVC, that line will look strange to you.  Here is how I understand it: Url.Action is a method that utilizes the Asp.Net Routing engine to create urls.  In the case of MVC, I need a url to a controller method.  The controller is “Account” (the actual class name is AccountController), and the method is “VerifyUserName”.   The cool part, now you can get a valid url no matter where you are in the project directory hierarchy (that is a problem with WebForms).

But there are downsides: I hope the only data you are going to pass to the method is the data located in the control.  If you need to pass more information to do the validation you could be in trouble.

Validation Method 2: Validator.addRule

The next option is to add a custom rule that make the ajax call and does the validation.  So first we add the custom rule:

   1: function VerifyUserName(value, element) {

   2:           if ( this.optional(element) )

   3:               return "dependency-mismatch";

   4:           

   5:           var previous = this.previousValue(element);

   6:           

   7:           if (!this.settings.messages[element.name] )

   8:               this.settings.messages[element.name] = {};

   9:           this.settings.messages[element.name].verifyUserName = typeof previous.message == "function" ? previous.message(value) : previous.message;

  10:           

  11:           if ( previous.old !== value ) {

  12:               previous.old = value;

  13:               var validator = this;

  14:               this.startRequest(element);

  15:               var data = {};

  16:               data[userNameEdit] = value;

  17:               $.ajax($.extend(true, {

  18:               url: '<%=Url.Action("VerifyEmail", "Account") %>',

  19:                   mode: "abort",

  20:                   port: "validate" + element.name,

  21:                   dataType: "json",

  22:                   data: data,

  23:                   success: function(response) {

  24:                       var valid = response === true;

  25:                       if ( valid ) {

  26:                           var submitted = validator.formSubmitted;

  27:                           validator.prepareElement(element);

  28:                           validator.formSubmitted = submitted;

  29:                           validator.successList.push(element);

  30:                           validator.showErrors();

  31:                       } else {

  32:                           var errors = {};

  33:                           errors[element.name] = previous.message = response || validator.defaultMessage( element, "verifyUserName" );

  34:                           validator.showErrors(errors);

  35:                       }

  36:                       previous.valid = valid;

  37:                       validator.stopRequest(element, valid);

  38:                   }

  39:               }, '<%=Url.Action("VerifyEmail", "Account") %>'));

  40:               return "pending";

  41:           } else if( this.pending[element.name] ) {

  42:               return "pending";

  43:           }

  44:           return previous.valid;

  45:       }

The only thing interesting in that ajax call (as far as JQuery is concerned) is the async = false bit.   That line is telling JQuery to execute this method serially so I can return the result (hope the method doesn’t take too long). But I can customize the AJAX call however I need.

Next, we can edit our ‘validate’ method to use the custom rule.

   1: $('#UserNameForm').validate({

   2:     rules: {

   3:         userNameEdit: { required: true, verifyUserName: true" }

   4:     }

   5: });

So what I did here was take the code from the Validator’s Remote method, and modify the parts I needed for my own purposes.  That said, I had a lot of trouble getting it to work correctly.   I’m sort of hoping someone will tell me what I did wrong actually.

Validation Method 3: Overloaded Submit

The final way I’m going to show to use an AJAX web method to perform a validation check for use is by overloading the submit callback.   This what I’ve actually ended up using for a number of projects.  It is the simplest to code and understand.

   1: function CustomSubmit(){

   2:     var _val = $("#CustomerForm").validate({

   3:         rules: {

   4:             FirstName: { required: true },

   5:             LastName: { required: true },

   6:             Email: { required: true, email: true}

   7:         },

   8:         messages: {

   9:             FirstName: "First name is required",

  10:             LastName: "Last name is required",

  11:             Email: {

  12:                 required: "Please enter a valid email address",

  13:                 minlength: "Please enter a valid email address",

  14:                 remote: jQuery.format("{0} is already in use")

  15:             }

  16:         },

  17:         submitHandler: function(form) {

  18:             var data = {userNameEdit:$("#Email").val()};

  19:             $.ajax({

  20:             url: '<%=Url.Action("VerifyEmail", "Account") %>',

  21:                 dataType: "json",

  22:                 data: data,

  23:                 success: function(response) {

  24:                     var valid = response === true;

  25:                     if ( valid ) {

  26:                         form.submit();

  27:                     } else {

  28:                         _val.showErrors({ "Email": 'Email is already in use.' });

  29:                     }

  30:                 }

  31:             });

  32:          }

  33:     }

  34: }

A couple of key points on this one as well.  First notice what is happening on line 2.  I’m saving the resulting validator so I can use it later.  Then action happens at line 17 with the submitHandler.  submitHandler is a callback (event) which gives you a hook into the normal submit process.  Also you can see on line 26 I am calling the form.submit myself.  Then on line 28 I am displaying a custom error message. 

Summary

Finally, no matter how much checking you do in the client, you still have to recheck everything once you are on the server – sorry it is true.  Until I find a better way to implement Method 2, I will be using Method 3.  It is the most straight forward way to do validation via AJAX methods I have found so far.

If I can get to a Part 3 (Part 2 took WAY too long), I’ll look into using AJAX to handle the submit, and displaying custom error messages when the submit goes wrong.

Tags: Esoterica

ClientIDMode in ASP.NET 4.0

One of the more anticipated features of ASP.NET 4.0 – at least for me - is the new ClientIDMode property, which can be used to force controls to generate clean Client IDs that don’t follow ASP.NET’s munged NamingContainer ID conventions. To be clear, NamingContainer IDs are necessary for complex controls and pages that nest many things inside of a single context, but for most application level Web design scenarios those munged IDs get in the way and don’t provide a lot of value.

The munged IDs affect all sorts of development scenarios from design and CSS styling where ID haven’t been predictable for #id styling:

#ctl00_content_txtName 
{
    font-weight: bold;
}

vs the more expected:

#txtName
{
    font-weight: bold;
}

And even more so there’s the whole nightmare of ClientIds in script pages where code like this:

    <script type="text/javascript">
        var txtName = $("<%= txtName.ClientID %>");
        var txtTitle = $("[id$=_txtTitle]");
    </script>

or some other pre-generation code is necessary to get client id’s properly referenced in script code.

ClientIDMode

In prior versions of ASP.NET you had to live with the problem or work around with various hacks. In ASP.NET 4.0 things get a little easier via the new ClientIDMode property which allows you to specify exactly how a ClientID is generated.

The idea is simple: you get a new ClientIDMode property on all ASP.NET controls which can be set either at the actual control or somewhere up the NamingContainer chain. If the ClientIDMode property is not set on a control it inherits the setting from the nearest NamingContainer with the exception of  the <asp:Content> placeholder which doesn’t participate in ClientIDMode processing (bummer!).

This means if you choose to you can set ClientIDMode on the Page level and it will trickle down into all the child controls on the page, but a custom naming container like a User Control can still override the ClientIDMode to enforce it’s naming container requirements. It’ll be interesting to see how much existing code might break based on this inheritance scheme as custom controls may lose controls over their ClientID naming if the ClientIDMode property isn’t set explicitly.

Anyway let’s take a look at a very simple example and how the ClientIDMode property affects the ID rendering. Imagine you have page that uses a master page and is set up like this:
 

<%@ Page Title="" Language="C#" MasterPageFile="~/Site.Master" AutoEventWireup="true" 
        CodeBehind="WebForm2.aspx.cs" 
        Inherits="WebApplication1.WebForm2"               
        ClientIDMode="Predictable"
 %>
<asp:Content ID="content" ContentPlaceHolderID="content" runat="server" ClientIDMode="Static" >    
    <asp:TextBox runat="server" ID="txtName" ClientIDMode="Static" />        
</asp:Content>

Here’s what the various values for the txtName property can look like:

AutoID

This is the existing behavior in ASP.NET 1.x-3.x where full naming container munging takes place.

<input name="ctl00$content$txtName" type="text" id="ctl00_content_txtName" />

In Beta 2 this is the default value for the Page. According to the latest VS 2010 documentation however, the default behavior by release time will be Predictable.

Static
This option forces the control’s ClientID to use its ID value directly. No naming container naming at all is applied and you end up with clean client ids:

<inputname="ctl00$content$txtName"type="text"id="txtName" />

This option is what most of us want to use, but you have to be clear on that this can potentially cause conflicts with other control on the page. If there are several instances of the same naming container (several instances of the same user control for example) there can easily be a client ID naming conflict. It’s basically up to you to decide whether this is a problem or not.

Predictable

The previous two values are pretty self-explanatory. Predictable however, requires some explanation. To me at least it's not in the least bit predictable :-}.
MSDN defines this enum value as follows:

This algorithm is used for controls that are in data-bound controls. The ClientID value is generated by concatenating the ClientID value of the parent naming container with the ID value of the control. If the control is a data-bound control that generates multiple rows, the value of the data field specified in the ClientIDRowSuffix property is added at the end. For the GridView control, multiple data fields can be specified. If the ClientIDRowSuffix property is blank, a sequential number is added at the end instead of a data-field value. Each segment is separated by an underscore character (_).

The key that makes this value a bit confusing is that it relies on the parent’s ClientID value to build it’s own client ID value. Which effectively means that the value is not predictable at all but rather very tightly coupled to the parent naming container’s ClientIDMode setting.

For our simple textbox example, if the ClientIDMode property of the parent naming container (Page in this case) is set to “Predictable” you’ll get this:

<input name="ctl00$content$txtName" type="text" id="content_txtName" />

If on the other hand the Page is set to “AutoID” you get:

<input name="ctl00$content$txtName" type="text" id="ctl00_content_txtName" />

The latter is effectively the same as if you specified AutoID in this scenario because it inherits the AutoID naming from the Page and Content control of the page.  But again – predictable behavior always depends on the parent naming container and how it generates its id so the ID may not always be exactly the same as the AutoID generated value because somewhere in the NamingContainer chain the ClientIDMode setting may be set to a different value. For example if you had another naming container in the middle that was set to Static you’d end up effectively with an ID that starts with the NamingContainers' ID rather than the whole ctl000_content munging.

Predictable is useful, but only if all naming containers down the chain use this setting. Otherwise you’re right back to the munged Ids that are pretty unpredictable.

Inherit

The final setting is Inherit which is the default for all controls except Page (AFAIK). This means that controls by default inherit the naming container’s ClientIDMode setting.

Inheritance

The explicit values are pretty obvious in what they do. AutoID is classic behavior, Static is what we want in typical client centric apps, and Predictable is what you typically will want to use for list controls and anything that has possible naming conflicts.

Things get a little more tricky with inheritance of these settings. Specicfically the ClientIDMode property inherits from a NamingContainer down. Unlike most other ASP.NET controls the inheritance is based on the NamingContainer not on the Parent Container.

What this means is that if you set ClientIDMode="Static" on a Page or MasterPage all controls inherit that settings:

<%@ Page Title="" Language="C#" MasterPageFile="~/Site.Master" AutoEventWireup="true" 
         CodeBehind="WebForm2.aspx.cs" Inherits="WebApplication1.WebForm2"  
         ClientIDMode="Static" %>

If you don’t set the ClientIDMode on any other controls the entire page will use this ClientIDMode. Any UserControls can override the setting but all controls will use this setting.

Now imagine I do:

and I’m running inside of a master page and I put in a block of controls like this:

    <asp:Panel runat="server"  ClientIDMode="Static">
        This is a test:
        <asp:TextBox runat="server" ID="txtName" />
        <asp:Button ID="btnSubmit" runat="server" Text="Go"  />
    </asp:Panel>

Quick what should you see? Unfortunately not what I would have expected – although it’s true to what the documentation advertises. The block above renders into:

<div>
    This is a test:
    <input name="ctl00$content$txtName" type="text" id="content_txtName" />
    <input type="submit" name="ctl00$content$btnSubmit" value="Go" id="content_btnSubmit" />
</div>

What’s happening here is that even though we specified Static naming on the Panel (which is not a NamingContainer) Predictable naming is used which runs up to the nearest naming container – in this case the Master Page Content control and using that as its base for the name. If I want those controls to render with clean ids I need to use:

    <asp:Panel runat="server"  ClientIDMode="Static">
        This is a test:
        <asp:TextBox runat="server" ID="txtName" ClientIDMode="Static" />
        <asp:Button ID="btnSubmit" runat="server" Text="Go" ClientIDMode="Static" />
    </asp:Panel>

with explicit static extensions on the control – or by changing the Page’s ClientIDMode to Static:

<%@ Page Title="" Language="C#" MasterPageFile="~/Site.Master" AutoEventWireup="true" 
        CodeBehind="WebForm2.aspx.cs" Inherits="WebApplication1.WebForm2"  
        ClientIDMode="Static" %>

With either of those in place I now get:

<div id="Panel1">
        This is a test:
        <input name="ctl00$content$txtName" type="text" id="txtName" />
        <input type="submit" name="ctl00$content$btnSubmit" value="Go" id="btnSubmit" />    
</div>

Notice that when page level ClientIDMode="Static" the <div> tag now renders with an explicit ID which is rather inconsistent (it’s not there if I just have ClientIDMode=”Static” on the Panel alone).

Note that you unfortunately cannot use an <asp:Content> control and specify the ClientIDMode like this:

<asp:Content ID="content" ContentPlaceHolderID="content" runat="server" ClientIDMode="Static">

which would be the ideal situation for many applications. Unfortunately ClientIDMode on the Content control has no effect on its children.

Unfortunately this means that there’s no real clean way for page code to isolate ClientIDMode rendering to just a few controls in a page. In typical pages you often don’t care about generated IDs but for a few isolated controls/areas of the page, but there’s no easy way to isolate just that block of controls with its own naming container to force the ClientID hierarchy to be affected.

The only way around this would be to build a control that creates a naming container (<my:NamingContainerPlaceHolder> maybe?).

ClientIDRowSuffix

Another feature of the ClientID improvements in ASP.NET 4.0 is the ClientIDRowSuffix which can be applied to DataBound/List controls. This setting basically determines how ID values for template controls are generated, but it requires that the ClientIDMode is set to Predictable.

For example if I have  GridView that looks like this:

    <asp:GridView runat="server" ID="gvProducts" AutoGenerateColumns="false"
                  ClientIDRowSuffix="id" ClientIDMode="Predictable" 
                  DataSourceID="xmlDataSource">  
                  <Columns>
                    <asp:TemplateField> 
                        <ItemTemplate>
                            <asp:Label runat="server" id="txtTitle" Text='<%# Eval("title") %>' />
                        </ItemTemplate>
                    </asp:TemplateField>
                    <asp:TemplateField> 
                        <ItemTemplate>
                        <asp:Label runat="server" id="txtId" Text='<%# Eval("id") %>' />
                        </ItemTemplate>
                    </asp:TemplateField>
                  </Columns>  
    </asp:GridView>

ASP.NET will generate the labels inside of the rows with IDs that include the name of the

    <table cellspacing="0" rules="all" border="1" id="content_gvProducts" style="border-collapse:collapse;">
        <tr>
            <th scope="col">&nbsp;</th><th scope="col">&nbsp;</th>
        </tr><tr>
            <td>
                            <span id="content_gvProducts_txtTitle_32">West Wind West Wind Web Toolkit</span>
                        </td><td>
                        <span id="content_gvProducts_txtId_32">32</span>
                        </td>
        </tr><tr>
            <td>
                            <span id="content_gvProducts_txtTitle_33">West Wind West Wind Web Store</span>
                        </td><td>
                        <span id="content_gvProducts_txtId_33">33</span>
                        </td>
        </tr>
    </table>

Too bad that this doesn’t work with ClientIDMode=”Static” – that way you’d get short IDs instead of the long naming container values, but this is better than nothing. I’d much prefer txtTitle_33 for example.

Wouldn’t it be nice if Client Row Ids could be generated?

Another feature that I wish certain controls had was the ability to easily generate a ClientIDs onto the each item – in the case of the GridView each <tr> row element. It sure would be get output like this:

    <tr id="content_gvProducts_33">
        ...
    </tr>

In almost any client scenario I need to know the ID of the row in order to handle navigation and while you can get this done in a GridView with ItemCreated events it’s quite a pain to do this. For example for the gridview I’m using with a simple XmlDataSource control I have to do this:

protected void gvProducts_RowCreated(object sender, GridViewRowEventArgs e)
{
    object dataItem = e.Row.DataItem;

    if (dataItem != null)
    {
        XPathNavigator nav = ((IXPathNavigable)dataItem).CreateNavigator();
        if (nav != null)
            e.Row.Attributes.Add("id", this.gvProducts.ID + "_" + nav.GetAttribute("id",""));
    }
}

to produce output like this:

<tr id="gvProducts_33"> ... </tr>

which is anything but intuitive for such a common scenario (although this IS a bit easier to grab the data if you use Entity list or DataTable binding).

Oh well – guess I don’t use GridView’s much anyway anymore with almost everything I do now using ListView that do allows more control during generation, but still .

What does this all mean?

I suspect it’s going to take some time to figure out all the little nuances of the new ClientIDMode features. At the very least the Static option on individual controls allows you to explicitly force controls to use the name you want it to and that’s a win any way you look at it.

For now I’m thinking ahead and I think my typical usage scenario likely looks like this:

• Add ClientIDMode="Static" to each Page
• Add ClientIDMode="Predictable" explicitly to each List Control on a Page
• Override explicitly to Predictable where necessary only
• For Control Development leave at default behavior if possible (Inherit)
• Override only when necessary and preferrably on individual subcontrols

Also for now I think it’s a good idea to EXPLICITLY specify a ClientIDMode on each page (or in your project) or explicitly declare the value in your web.config file:

<pages clientIDMode="Static" />

to ensure you get a predictable setting since the current Beta 2 implementation and the documentation are at odds of what the default value actually is.

It’s funny to think that such simple functionality should cause such complex workarounds and dependent behaviors but I suspect with a consistent regimen of CLientIDMode settings you can achieve output that works for any scenario.

Accessible Media Player

Playing video in Silverlight is great, but what about viewers who have a hearing impairment? Not important? The World Health Organization (WHO) would beg to differ. According to their 2005 estimates, “278 million people worldwide have moderate to profound hearing loss in both ears.”  That’s almost 17% of the world Internet population.

So you should really think about how to address viewers who are Deaf or hard of hearing. One way to do this is by using closed captions (aka “subtitles for the Deaf and hard of hearing”) in your videos. This tutorial by Sean Hayes in our Accessibility Business Unit describes how to implement closed captions in Silverlight media.

Tags: Application Packaging, Beautiful Examples, Product/Technology Deep Dive, ria, Silverlight, Virtualization

Modern CSS Layouts: The Essential Characteristics

Now is an exciting time to be creating CSS layouts. After years of what felt like the same old techniques for the same old browsers, we’re finally seeing browsers implement CSS 3, HTML 5 and other technologies that give us cool new tools and tricks for our designs.

But all of this change can be stressful, too. How do you keep up with all of the new techniques and make sure your Web pages look great on the increasing number of browsers and devices out there? In part 1 of this article, you’ll learn the five essential characteristics of successful modern CSS websites. In part 2 of this article, you’ll learn about the techniques and tools that you need to achieve these characteristics.

We won’t talk about design trends and styles that characterize modern CSS-based layouts. These styles are always changing. Instead, we’ll focus on the broad underlying concepts that you need to know to create the most successful CSS layouts using the latest techniques. For instance, separating content and presentation is still a fundamental concept of CSS Web pages. But other characteristics of modern CSS Web pages are new or more important than ever. A modern CSS-based website is: progressively enhanced, adaptive to diverse users, modular, efficient and typographically rich.

• Progressively enhanced,
• Adaptive to diverse users,
• Modular,
• Efficient,
• Typographically rich.

Progressive Enhancement

Progressive enhancement means creating a solid page with appropriate markup for content and adding advanced styling (and perhaps scripting) to the page for browsers that can handle it. It results in web pages that are usable by all browsers but that do not look identical in all browsers. Users of newer, more advanced browsers get to see more cool visual effects and nice usability enhancements.

The idea of allowing a design to look different in different browsers is not new. CSS gurus have been preaching this for years because font availability and rendering, color tone, pixel calculations and other technical factors have always varied between browsers and platforms. Most Web designers avoid “pixel perfection” and have accepted the idea of their designs looking slightly different in different browsers. But progressive enhancement, which has grown in popularity over the past few years, takes it a step further. Designs that are progressively enhanced may look more than slightly different in different browsers; they might look very different.

For example, the tweetCC website has a number of CSS 3 properties that add attractive visual touches, like drop-shadows behind text, multiple columns of text and different-colored background “images” (without there having to be actually different images). These effects are seen to various extents in different browsers, with old browsers like IE 6 looking the “plainest.” However, even in IE 6, the text is perfectly readable, and the design is perfectly usable.

tweetCC in Safari.

tweetCC in IE 6.

In CSS 3-capable browsers like Safari (top), the tweetCC website shows a number of visual effects that you can’t see in IE 6 (bottom).

These significant differences between browsers are perfectly okay, not only because that is the built-in nature of the Web, but because progressive enhancement brings the following benefits:

• More robust pages
  Rather than use the graceful degradation method to create a fully functional page and then work backwards to make it function in less-capable browsers, you focus first on creating a solid “base” page that works everywhere.
• Happier users
  You start building the page making sure the basic functionality and styling is the same for everyone. People with old browsers, mobile devices and assistive technology are happy because the pages are clean and reliable and work well. People with the latest and greatest browsers are happy because they get a rich, polished experience.
• Reduced development time
  You don’t have to spend hours trying to get everything to look perfect and identical in all browsers. Nor do you have to spend much time reverse-engineering your pages to work in older browsers after you have completed the fully functional and styled versions (as is the case with the graceful degradation method).
• Reduced maintenance time
  If a new browser or new technology comes out, you can add new features to what you already have, without altering and possibly breaking your existing features. You have only one base version of the page or code to update, rather than multiple versions (which is the case with graceful degradation).
• More fun
  It’s just plain fun to be able to use cool and creative new techniques on your Web pages, and not have to wait years for old browsers to die off.

Learn more about progressive enhancement:

• Progressive Enhancement: What It Is, And How To Use It?
• Progressive Enhancement on Wikipedia
• Progressive Enhancement: Paving the Way for Future Web Design

Adaptive to Diverse Users

Modern CSS-based Web pages have to accommodate the diverse range of browsers, devices, screen resolutions, font sizes, assistive technologies and other factors that users bring to the table. This concept is also not new but is growing in importance as Web users become increasingly diverse. For instance, a few years ago, you could count on almost all of your users having one of three screen resolutions. Now, users could be viewing your pages on 10-inch netbooks, 30-inch widescreen monitors or anything in between, not to mention tiny mobile devices.

In his article “Smart columns with CSS and jQuery” Soh Tanaka describes his techniques that adapts the layout depending on the current browser window size.

Creating Web designs that work for all users in all scenarios will never possible. But the more users you can please, the better: for them, for your clients and for you. Successful CSS layouts now have to be more flexible and adaptable than ever before to the increasing variety of ways in which users browse the Web.

Consider factors such as these when creating CSS layouts:

• Browser
  Is the design attractive and usable with the most current and popular browsers? Is it at least usable with old browsers?
• Platform
  Does the design work on PC, Mac and Linux machines?
• Device
  Does the design adapt to low-resolution mobile devices? How does it look on mobile devices that have full resolution (e.g. iPhones)?
• Screen resolution
  Does the design stay together at multiple viewport (i.e. window) widths? Is it attractive and easy to read at different widths? If the design does adapt to different viewport widths, does it correct for extremely narrow or wide viewports (e.g. by using the min-width and max-width properties)?
• Font sizes
  Does the design accommodate different default font sizes? Does the design hold together when the font size is changed on the fly? Is it attractive and easy to read at different font sizes?
• Color
  Does the design make sense and is the content readable in black and white? Would it work if you are color blind or have poor vision or cannot detect color contrast?
• JavaScript presence
  Does the page work without JavaScript?
• Image presence
  Does the content make sense and is it readable without images (either background or foreground)?
• Assistive technology/disability
  Does the page work well in screen readers? Does the page work well without a mouse?

This is not a comprehensive list; and even so, you would not be able to accommodate every one of these variations in your design. But the more you can account for, the more user-friendly, robust and successful your website will be.

See these resources on user diversity and Web page adaptability:

• Market Share by Net Applications
• Actual Browser Sizes
• Screen Resolutions and Better User Experience
• Fixed vs. Fluid vs. Elastic Layout: What’s the Right One for You?
• Mobile Web Design Trends for 2009

Modular

Modern websites are no longer collections of static pages. Pieces of content and design components are reused throughout a website and even shared between websites, as content management systems (CMS), RSS aggregation and user-generated content increase in popularity. Modern design components have to be able to adapt to all of the different places they will be used and the different types and amount of content they will contain.

Object Oriented CSS is Nicole Sulivan’s attempt to create a framework that would allow developers to write fast, maintainable, standards-based, modular front end code.

Modular CSS, in a broad sense, is CSS that can be broken down into chunks that work independently to create design components that can themselves be reused independently. This might mean separating your style into multiple sheets, such as layout.css, type.css, and color.css. Or it might mean creating a collection of universal CSS classes for form layout that you can apply to any form on your website, rather than have to style each form individually. CMS’, frameworks, layout grids and other tools all help you create more modular Web pages.

Modular CSS offers these benefits (depending on which techniques and tools you use):

• Smaller file sizes
  When all of the content across your website is styled with only a handful of CSS classes, rather than an array of CSS IDs that only work on particular pieces of content on particular pages, your style sheets will have many fewer redundant lines of code.
• Reduced development time
  Using frameworks, standard classes and other modular CSS tools keeps you from having to re-invent the wheel every time you start a new website. By using your own or other developers’ tried and true CSS classes, you spend less time testing and tweaking in different browsers.
• Reduced maintenance time
  When your style sheets include broad, reusable classes that work anywhere on your website, you don’t have to come up with new styles when you add new content. Also, when your CSS is lean and well organized, you spend less time tracking down problems in your style sheets when browser bugs pop up.
• Easier maintenance for others
  In addition to making maintenance less time-consuming for you, well-organized CSS and smartly named classes also make maintenance easier for developers who weren’t involved in the initial development of the style sheets. They’ll be able to find what they need and use it more easily. CMS’ and frameworks also allow people who are not as familiar with your website to update it easily, without screwing anything up.
• More design flexibility
  Frameworks and layout grids make it easy, for instance, to switch between different types of layout on different pages or to plug in different types of content on a single page.
• More consistent design
  By reusing the same classes and avoiding location-specific styling, you ensure that all elements of the same type look the same throughout the website. CMS’ and frameworks provide even more insurance against design inconsistency.

Learn more about modular CSS techniques:

• Object-Oriented CSS
• Making Modular Layout Systems
• Definitive List of CSS Frameworks: Pick Your Style

Efficient

Modern CSS-based websites should be efficient in two ways:

• Efficient for you to develop,
• Efficient for the server and browser to display to users.

As Web developers, we can all agree that efficiency on the development side is a good thing. If you can save time while still producing high-quality work, then why wouldn’t you adopt more efficient CSS development practices? But creating pages that perform efficiently for users is sometimes not given enough attention. Even though connection speeds are getting faster and faster, page load times are still very important to users. In fact, as connection speeds increase, users might expect all pages to load very quickly, so making sure your website can keep up is important. Shaving just a couple of seconds off the loading time can make a big difference.

We’ve already discussed how modular CSS reduces development and maintenance time and makes your workflow a lot faster and more efficient. A myriad of tools are out there to help you write CSS quickly, which we’ll cover in part 2 of this article. You can also streamline your CSS development process by using many of the new effects offered by CSS 3, which cut down on your time spent creating graphics and coding usability enhancements.

Some CSS 3 techniques also improve performance and speed. For instance, traditional rounded-corner techniques require multiple images and DIVs for just one box. Using CSS 3 to create rounded corners requires no images, thus reducing the number of HTTP calls to the server and making the page load faster. No images also reduces the number of bytes the user has to download and speeds up page loading. CSS 3 rounded-corners also do not require multiple nested DIVs, which reduces page file size and speeds up page loading again. Simply switching to CSS 3 for rounded corners can give your website a tremendous performance boost, especially if you have many boxes with rounded corners on each page.

Writing clean CSS that takes advantage of shorthand properties, grouped selectors and other efficient syntax is of course just as important as ever for improving performance. Many of the more advanced tricks for making CSS-based pages load faster are also not new but are increasing in usage and importance. For instance, the CSS Sprites technique, whereby a single file holds many small images that are each revealed using the CSS background-position property, was first described by Dave Shea in 2004 but has been improved and added to a great deal since then. Many large enterprise websites now rely heavily on the technique to minimize HTTP requests. And it can improve efficiency for those of us working on smaller websites, too. CSS compression techniques are also increasingly common, and many automated tools make compressing and optimizing your CSS a breeze, as you’ll also learn in part 2 of this article.

Learn more about CSS efficiency:

• 7 Principles of Clean and Optimized CSS Code
• Simplifying CSS Selectors
• Best Practices for Speeding Up Your Website
• The Mystery Of CSS Sprites: Techniques, Tools And Tutorials
• 35 CSS Lifesavers For Efficient Web Design

Rich Typography

Rich typography may seem out of place with the four concepts we have just covered. But we’re not talking about any particular style of typography or fonts, but rather the broader concept of creating readable yet unique-looking text by applying tried and true typographic principles using the newest technologies. Typography is one of the most rapidly evolving areas of Web design right now. And boy, does it need to evolve! While Web designers have had few limits on what they could do graphically with their designs, their limits with typography have been glaring and frustrating.

Until recently, Web designers were limited to working with the fonts on their end users’ machines. Image replacement tricks and clever technologies such as sIFR have opened new possibilities in the past few years, but none of these is terribly easy to work with. In the past year, we’ve finally made great strides in what is possible for type on the Web because of the growing support for CSS 3’s @font-face property, as well as new easy-to-use technologies and services like Cufón and Typekit.

The @font-face rule allows you to link to a font on your server, called a “Web font,” just as you link to images. So you are no longer limited to working with the fonts that most people have installed on their machines. You can now take advantage of the beautiful, unique fonts that you have been dying to use.

@font-face in action: Teehanlax.com

Craigmod

Nicewebtype

The three screenshots above are all examples of what @font-face can do.

The main problem with @font-face, aside from the ever-present issue of browser compatibility, is that most font licenses—even those of free fonts—do not allow you to serve the fonts over the Web. That’s where @font-face services such as Typekit, Fontdeck and Kernest are stepping in. They work with type foundries to license select fonts for Web design on a “rental” basis. These subscription-based services let you rent fonts for your website, giving you a much wider range of fonts to work with, while avoiding licensing issues.

For A Beautiful Web uses the Typekit font embedding service for the website name, introductory text and headings.

Ruler of the Interwebs uses the Kernest font embedding service for the website name and headings.

We still have a long way to go, but the new possibilities make typography more important to Web design than ever before. To make your design truly stand out, use these modern typographic techniques, which we’ll cover in even greater detail in Part 2.

See these resources on current CSS typography techniques:

• Webfonts.info Wiki
• Beautiful Fonts With @font-face
• Why Web Font Services Are the Future of Fonts on the Web
• The Direction Forward with Web Fonts
• Roundup of Font Embedding and Replacement Techniques

Summary

We’ve looked at five characteristics of modern CSS websites:

• Progressively enhanced,
• Adaptive to diverse users,
• Modular,
• Efficient,
• Typographically rich.

In part 2 of this article, coming soon, we’ll go over the techniques and tools that will help you implement these important characteristics on your CSS-based Web pages.

About the author

Zoe Mickley Gillenwater is a freelance Web designer specializing in CSS and accessibility. She is the author of the book Flexible Web Design: Creating Liquid and Elastic Layouts with CSS, plus a whole bunch of articles. Find out more about her on her blog and on Twitter.

(al)

© Zoe Mickley Gillenwater for Smashing Magazine, 2009. | Permalink | 2 comments | Add to del.icio.us | Digg this | Stumble on StumbleUpon! | Tweet it! | Submit to Reddit | Forum Smashing Magazine
Post tags:

Microsoft DRM part 1

Tags: Blogs, digitalrightsmanagement, drm, Microsoft

RIA Radio Episode 1 – Mike Downey

Tags: adobe, Blogs, flash, Microsoft, riaradio, Silverlight

Which software title do you use most ofter for prototyping?

Tags: News & Events, Prototype

Create cleaner ActionScript with conditional compiling

Tags: actionscript, Blogs