Graded Browser Support Update

July 3, 2008 at 3:49 pm by Nate Koechley | In Development | 15 Comments

Updated July 8th: The chart below has been corrected to include Safari 3.1†, replacing Safari 3.0†.

This post announces an update to Graded Browser Support. The GBS page on the YUI site always has the most current information. This post includes a list of primary changes, the updated chart of browsers that receive A-grade support, the GBS forecast, and notes specific to the YUI Library.

Primary Changes

These changes are included in this update.

  • A-grade support for Firefox 3 begins.
  • A-grade support for Firefox 2 is reduced to Win XP and Mac 10.5.
  • A-grade support for Opera 9.5 begins on Win XP and Mac 10.5.
  • A-grade support for Win 98 is discontinued, as previously forecast.
Win 2000 Win XP Win Vista Mac 10.4 Mac 10.5
Firefox 3.† A-grade A-grade A-grade A-grade A-grade
Firefox 2.† A-grade A-grade
IE 7.0 A-grade A-grade
IE 6.0 A-grade A-grade
Opera 9.5† A-grade A-grade
Safari 3.1† A-grade A-grade

The dagger symbol (as in “Firefox 3.†”) indicates that the most-current non-beta version at that branch level receives support. Put another way, † means “the most recent” instead of “all.”

GBS Forecast

In addition to the effective-immediately changes, we’re keeping our eyes on pending developments.

  • Internet Explorer 8

    GBS does not extend A-grade support to beta versions of browsers. (They receive X-grade support by definition.) However, it’s important to be aware of forthcoming releases, especially from established brands that enjoy rapid adoption once generally available (GA). We are currently watching the development progress of Internet Explorer 8.

    We made an exception to our “no-betas” stance during IE7’s beta phase in recognition of IE’s market share and ability to promote rapid adoption. The exception — committing development and QA resources to provide A-Grade prior to a GA release — gives us an opportunity to learn the new browser’s quirks and provide feedback while it is still being developed. And it means our sites are prepared when it goes GA. We will likely extend the same accommodation to IE8. Stay tuned.

Notes Specific to the YUI Library

  • YUI version 2.5.2

    YUI 2.5.2, released May 28, 2008, includes full support for Firefox 3.0 and Opera 9.5, even though those two browsers were just added to GBS in this update.

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

Implementation Focus: AA | RF’s Redesign of the Pulte Homes Website

July 3, 2008 at 8:23 am by Eric Miraglia | In YUI Implementations | No Comments

Fred WelterlinAs a presentation layer architect, graphical alchemist, and Web Standards advocate for Avenue A | Razorfish, Frederic Welterlin’s experience and areas of focus include designing, architecting, and programming client-side templates, providing interaction and technical recommendations, and developing standards and processes for best of breed Web development.

Frederic has eleven years experience working as a user interface designer and developer — responsible for conceptual and practical design development for a wide range of business and industry needs.

The new Pulte Homes website designed by Avenue A | Razorfish using a variety of YUI components.

Tell us a little bit about your site redesign for Pulte Homes.

The new Pulte Homes, Inc. web redesign was launched in May 2008 to help consumers find homes using a rich and interactive map-based search tool, learn about available homes using interactive multimedia, organize and save properties of interest using personalized notebooks, and finally connect with Pulte sales agents directly through a dynamic, context-specific contact form.

The project was scoped as an end-to-end design and implementation effort lasting approximately 18 months. We used the following and YUI components as part of the redesign:

You chose YUI for the implementation of the Pulte Homes website. What factors went into that decision? You know and use other libraries on a daily basis (and choose them over YUI for some projects) — why was YUI the right choice in this instance?

The presentation layer JavaScript library decision was made based on the following factors:

  1. Time to Market: a need to have solid, pre-built functional components that can be quickly customized to match the desired interaction model and “look and feel.” The web standards based approach that YUI employs makes it easy to customize components while also addressing common development issues such as browser compatibility, performance and accessibility.
  2. Robust set of widgets: a desire to use a front end framework that fits with the client approved interaction specification (for example, our UX team’s use of the Auto Complete design pattern was accommodated using the YUI AutoComplete component). In the deadline-driven agency environment, integrated development practices help to reduce development time and improve continuity.
  3. Reliability: a sense of comfort/security in using products that are already proven on Yahoo! web properties. The YUI website, API, and supporting community are all excellent resources in providing help, feedback, and examples.

One aspect of AA|RF implementations of YUI that’s striking is the degree to which you customize the look and feel. When you use a component like Container, Slider or TabView, you do a full custom skin. How much effort is it for you to do so? What tips do you have for other designers or developers who are skinning YUI?

Pulte is a great example of the typical clients that hire AA|RF — they do so not only because of our end-to-end service capabilities, but also because of our reputation for design and UX excellence. Since branding and user experience are so important to many of our clients, we place considerable effort into building high quality interfaces.

For example, we designed a modular front-end architecture that would accommodate not only Pulte.com, but also two sub brands: DelWebb and DiVosta. All three web sites use the same back-end, content management system, and front-end HTML templates and YUI components. We then dynamically change the CSS reference, and therefore the skin, based on domain. This was accomplished using web standards based separation of the presentation layers (HTML, CSS, and JavaScript). Since YUI also follows web standards best practices, it was easy to integrate functional components with three different skins.

YUI components in use on the Pulte Homes site as designed by AA | RF.

In the image above, the Auto Complete, Slider, and Button Control modules use the same HTML and JavaScript, but different style sheets.

We recommend designers and developers consider using an integrated approach to web development, especially for large scale implementations involving interdisciplinary teams. For Pulte we used Yahoo! based interaction design patterns, functional components, styling guides and performance tools together to achieve the branding and user experience needs that our clients expect in world class products.

Pulte Homes is an ASP.Net site. What does a .Net developer need to know about YUI before getting started — any special tips and tricks?

YUI, like most client side JavaScript frameworks that we use, works well on any platform. The high level technical choices made at the beginning of a project are the factors that most affect developers on a day to day basis, especially in terms of integration pains. As more and more processing occurs on the browser due to demand for such technologies as AJAX and rich internet applications, architects must consider the implications of using end to end frameworks (for their standardized development patterns) versus using customized solutions. We could have used ASP.NET Ajax for most of the components, but we decided that YUI was a better fit for the level of customization and interaction that we wanted. So for this particular project, the most important “trick” was to have an architecture and development process that cleanly incorporates the customized features into the .NET environment.

In your Pulte implementation, we see a custom yui.js rollup that contains your selection of YUI components. You implement this instead of drawing the individual files off Yahoo! servers. Is it ever appropriate to use a third-party hosting service (as Yahoo would be in this case) on your customer’s sites?

Yes, absolutely. From a performance point of view, the advantages of geo-based file serving, caching, HTTP requests, etc, are compelling reasons to serve YUI from a content delivery network. We have actually referenced the Yahoo! Exceptional Performance site for best practices on how to improve performance. The new Pulte site, being a “Web 2.0″ feature rich experience, requires above average bandwidth requirements. We are planning on implementing a number of new performance enhancing tasks over the next several weeks based on information gathered using such tools as YSlow.

As for the use of third-party hosting services, we have found that some clients (and I am not talking about Pulte specifically here) are simply uncomfortable with having key components like JavaScript libraries served from a third party due to lack of SLAs (service level agreements).

What are you most proud of in the Pulte Homes project?

The new home search page is probably the coolest feature- it provides consumers with map-based searching for available homes, coupled with a rich set of filters around the most important criteria that people use to look for homes. This feature is a great mash-up of Microsoft technologies (ASP/.NET), Google technologies (Maps), and Yahoo! technologies (YUI). While the three companies are battling each other for market share, we have found a way to combine some of their best services to help people find homes. I like the symmetry of that…

What’s on the horizon for AA|RF as far as the front-end is concerned? Are there emerging technologies coming into the mainstream that you’re looking at for some clients? I’m thinking, of course, about things like AIR, Gears, HTML5, Silverlight, etc.

Since joining the Microsoft family last year, we have built a number of Silverlight applications to help bring this emerging technology into the limelight. In addition, we feel that mobile web application development is on the cusp of hitting the mainstream in the United States, especially with the advent of Apple’s iPhone and its associated SDK. We are working hard to find ways to bring value to our clients via the mobile channel.

We have always put business and user needs ahead of technology — and will continue to do so. All the new technologies that are emerging offer a lot of potential in terms of solving problems more effectively and elegantly under certain contexts. However, the reality is that many of our clients are yet to fully harness the power of the Web 2.0 technologies that have emerged in the last few years. They are looking for us to do that in the near-term before they can look ahead.

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

A YUI Grids-based WordPress Theme — YUI Autogrid Minimal

July 2, 2008 at 10:22 am by Christian Heilmann | In Development | 7 Comments

As I had to upgrade my personal blog to the newest WordPress version (and my old theme had been hacked to death), I chose to start from scratch with a WordPress theme.

[You can download the new theme here.]

As I am a lazy person and I think blogging is first and foremost about content and availability, I wanted to re-use as much as possible the good stuff other people have done and then tweak it a bit to fit my needs.

Voilå! YUI autogrid minimal, a WordPress theme based heavily on YUI’s Grids CSS and Base CSS with a few changes to fit the HTML that WordPress creates for you.

To work around the issue of YUI Grids being optimized for a certain resolution, I used the autogrids trick blogged here previously.

This is what this WordPress theme gives you:

  • clean, simple markup
  • a grids layout that changes with the available browser space
  • a fixed right side menu for easy access of the search and pages
  • an hCard in the footer to download to Outlook or Mail
  • Nice, easy-to-read typography without any fancy distractions

What it does not give you (as I hadn’t had time to look into these):

  • Ajax that nobody really needs
  • the new WordPress enhancements like the dynamic sidebar
  • pop-up comments (come on, this is 2008!)

You can see a few messier, older versions of this theme at work on my personal blog and on Scripting Enabled, the event I am organising about accessibility hacking later this year.

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

Bookmarklet for the YUI Logger Control

July 1, 2008 at 9:01 am by Eric Miraglia | In Development | 1 Comment

Rajat Pandit's YUI Logger bookmarklet.

Rajat Pandit has put together a bookmarklet for YUI Logger that allows you to pop open a logger console on-demand — a big convenience when you’re debugging. Check out Rajat’s blog and bookmarklet page for more on this project.

Keep in mind that the YUI Logger Control outputs messages logged via YAHOO.log; to see full YUI debugging messages, you’ll need to use the -debug version of YUI files. For example, to use the -debug version of the YUI Event Utility, use http://yui.yahooapis.com/2.5.2/build/event/event-debug.js.

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

Production JavaScript Debugging

June 27, 2008 at 11:00 am by Nicholas C. Zakas | In Development | 11 Comments

You know the scenario. A bug is filed for a JavaScript issue in production. You update your development server to the same files (allegedly) that are in production but you can’t reproduce the issue. Debugging your JavaScript code is horrifically difficult, if not impossible, because you’re following best practices and crunching the file using the YUI Compressor.

You start by typing the URL of the JavaScript into a browser to confirm that the file is there. It is, and in fact, is being loaded into the browser without issue. So something must have gone wrong during the deployment process, but you need to know what part of the code is failing. Firebug, your trusty companion for JavaScript debugging, is essentially useless as it has a hard time deciphering all of your code from a single line.

When I end up in this situation, I turn to a little-known but incredibly powerful tool from Microsoft called Fiddler. Fiddler is an HTTP debugging proxy that filters all the requests coming to your machine via HTTP. It interfaces directly with WinINET, the Microsoft Internet communications stack, so it automatically picks up any requests and responses by programs using this library. By simply starting Fiddler, it will automatically pick up HTTP traffic for Internet Explorer, Safari, and Opera. Firefox doesn’t use WinINET, so you need to manually set it up to go through Fiddler. You can do so by going to the Tools menu and clicking on Options. Go to the Network tab and click the Settings button. Select Manual Proxy Configuration and enter localhost as your server and 8888 as your port. Click OK to apply the settings.

Setting up Firefox's options in preparation for using Fiddler.

Once that’s done, you’re ready to start debugging that production JavaScript. The key to debugging is really to create a readable version of the JavaScript so that Firebug (or any other JavaScript debugger) can be used to step through the code and set breakpoints as normal. To do so, download the file in production to your local machine. Use a pretty printing tool, such as Einars "elfz" Lielmanis’ online beautifier to create a more readable version of your code and save it to a local file. It’s important to follow this process instead of using your development version of the JavaScript to ensure that you’re using the exact same code that is on production; you can more easily rule out deployment issues this way.

The Fiddler Autoresponder tab.

Next, click on Fiddler’s AutoResponder tab. The settings on this tab allow you to intercept requests and respond as if you were the server. It’s possible to respond with a status code or with actual content. To enable this feature, check the Enable automatic responses checkbox. The Permit passthrough for unmatched requests checkbox should be checked by default, which is necessary to avoid interfering with other requests. Click the Add button to create a new entry. The textbox on the left should contain either the complete URI for the JavaScript file you want to intercept, or you can create a regular expression by preceding your text with "regex". The second textbox is for the response that should be sent. Click the dropdown arrow and select Find a file. Select the pretty-printed JavaScript file from your computer and click the Save button. This places your filter in Fiddler’s memory so the next time a file matching the given URI or description is requested, it will respond by sending back the file on your computer.

After that, you can navigate back to the production server on which the problem exists knowing that your file will be inserted in place of the actual production file. The browser itself is none the wiser that the file has been swapped out, so you’re safely able to debug readable code without making any changes to the code on the server. This technique has helped me debug some of the more complex issues I’ve dealt with at Yahoo!, and I hope that it can help you as well.

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

“AutoGrid” for YUI Grids — Using JavaScript to Create Adaptive Grids

June 25, 2008 at 4:39 pm by Christian Heilmann | In Development | 6 Comments

I love YUI Grids. I know my CSS and I know how to work around different problems of browsers, but I am also very much bored about having to fix and test and create these workarounds over and over again. While YUI Grids might not be perfect for all cases of web development out there, I am happy to take a pragmatic approach and just create sites that can be done with them (now you also know why I am not a designer).

One problem I keep having when I put some YUI Grids-based sites live is that people complain about me expecting a certain screen resolution or viewport size. YUI grids can either be 100% wide, which can be pretty silly on high resolutions, or optimized for resolutions of either 800×600 or 1024×768. When you optimize for 800 pixels people on higher resolutions will complain about the length of the page and when you go for 1024 people will say they have to scroll to see your side-bar on 800×600. You can’t win.

Or can you? CSS is not dynamic — it has a fixed state and you can only hope that the browser does the right thing with what you give it (well, there are conditional comments for IE, but technically they are HTML, and of course there are media queries in CSS3 and other goodies, but for the sake of the argument let’s say supporting IE6 is a base). JavaScript, on the other hand, is very dynamic and you can read out and check what is happening to the browser currently in use and react to it.

Putting this feature of JavaScript to good use you can create a YUI-Grids-based layout that remains flexible and changes according to needs. All you need to do is use some YUI Dom magic and change IDs and classes accordingly.

YUI Grids come in several flavours of overall width, defined by the ID on the container DIV:

  • #doc - 750px centered (good for 800×600)
  • #doc2 - 950px centered (good for 1024×768)
  • #doc3 - 100% fluid (good for everybody)
  • #doc4 - 974px fluid (good for 1024×768)
  • #doc-custom - custom width
One thing to remember here is that even doc3 has a minimum width of 750 pixels, which is why for a fully flexible grid you need to override that:
#doc3{
  min-width:0;
}

Inside the container DIV you can have two blocks, and their width and the position of the side bar is defined by the class on the container DIV:

  • .yui-t1 - Two columns, narrow on left, 160px
  • .yui-t2 - Two columns, narrow on left, 180px
  • .yui-t3 - Two columns, narrow on left, 300px
  • .yui-t4 - Two columns, narrow on right, 180px
  • .yui-t5 - Two columns, narrow on right, 240px
  • .yui-t6 - Two columns, narrow on right, 300px

Putting these together you can create a plan for your flexible grid:

  • When the available screen space is larger than 950 pixels, use doc2 and the widest sidebar — either left or right
  • If you have less than 950 pixels, use doc and the medium size sidebars
  • If you have less than 760 pixels, use doc3 and the smallest sidebars
  • If you have even less — say 600 pixels — at your disposal, show the side bar below the main content

The script to allow for this is not really rocket science. All it needs to do is read out the grids settings, the width of the available browser window and then change the IDs and classes accordingly.

YAHOO.example.autoGrid = function(){
  var container = YAHOO.util.Dom.get('doc') || 
                  YAHOO.util.Dom.get('doc2') || 
                  YAHOO.util.Dom.get('doc4') || 
                  YAHOO.util.Dom.get('doc3') ||
                  YAHOO.util.Dom.get('doc-custom');
  if(container){
    var sidebar = null;
    var classes = container.className;
    if(classes.match(/yui-t[1-3]|yui-left/)){
       var sidebar = 'left';
    }
    if(classes.match(/yui-t[4-6]|yui-right/)){
       var sidebar = 'right';
    }
    function switchGrid(){
      var currentWidth = YAHOO.util.Dom.getViewportWidth();
      if(currentWidth > 950){
        container.id = 'doc2';
        if(sidebar){
          container.className = sidebar === 'left' ? 'yui-t3' : 'yui-t6';
        }
      }
      if(currentWidth < 950){
        container.id = 'doc';
        if(sidebar){
          container.className = sidebar === 'left' ? 'yui-t2' : 'yui-t5';
        }
      }
      if(currentWidth < 760){
        container.id = 'doc3';
        if(sidebar){
          container.className = sidebar === 'left' ? 'yui-t1' : 'yui-t4';
        }
      }
      if(currentWidth < 600){
        container.id = 'doc3';
        container.className = '';
      }
    };
    switchGrid();
    /* 
      Throttle by Nicholas Zakas to work around MSIE's resize nasties.
      http://www.nczonline.net/blog/2007/11/30/the_throttle_function
    */
    function throttle(method, scope) {
      clearTimeout(method._tId);
        method._tId= setTimeout(function(){
        method.call(scope);
      }, 100);
    };
    YAHOO.util.Event.on(window,'resize',function(){
      throttle(YAHOO.example.autoGrid.switch,window);
    });
    
  };
  return {
    switch:switchGrid
  };
}();

Let’s go through it step by step:

YAHOO.example.autoGrid = function(){
  var container = YAHOO.util.Dom.get('doc') || 
                  YAHOO.util.Dom.get('doc2') || 
                  YAHOO.util.Dom.get('doc4') || 
                  YAHOO.util.Dom.get('doc3') ||
                  YAHOO.util.Dom.get('doc-custom');
  if(container){

First we check if there is actually a YUI Grid in the current document, by testing for the presence of the correct IDs. If there is, we execute the rest of the code.

    var sidebar = null;
    var classes = container.className;
    if(classes.match(/yui-t[1-3]|yui-left/)){
       var sidebar = 'left';
    }
    if(classes.match(/yui-t[4-6]|yui-right/)){
       var sidebar = 'right';
    }

We define sidebar as null, retrieve the class name of the container element and check if there was a column structure defined. In addition to the preset YUI Grids classes we also defined yui-left and yui-right here. These styles allow you to not have a sidebar without the script functionality but to get one once the script determines that there is enough space for one.

    function switchGrid(){
      var currentWidth = YAHOO.util.Dom.getViewportWidth();
      if(currentWidth > 950){
        container.id = 'doc2';
        if(sidebar){
          container.className = sidebar === 'left' ? 'yui-t3' : 'yui-t6';
        }
      }
      if(currentWidth < 950){
        container.id = 'doc';
        if(sidebar){
          container.className = sidebar === 'left' ? 'yui-t2' : 'yui-t5';
        }
      }
      if(currentWidth < 760){
        container.id = 'doc3';
        if(sidebar){
          container.className = sidebar === 'left' ? 'yui-t1' : 'yui-t4';
        }
      }
      if(currentWidth < 600){
        container.id = 'doc3';
        container.className = '';
      }
    };
    switchGrid();

The method switchGrid() does all the work we defined. We set up the different cases for applying IDs and classes and call the method immediately after it’s been defined.

    /* 
      Throttle by Nicholas Zakas to work around MSIE's resize nasties.
      http://www.nczonline.net/blog/2007/11/30/the_throttle_function
    */
    function throttle(method, scope) {
      clearTimeout(method._tId);
        method._tId= setTimeout(function(){
        method.call(scope);
      }, 100);
    };
    YAHOO.util.Event.on(window,'resize',function(){
      throttle(YAHOO.example.autoGrid.switch,window);
    });

For full flexibility, we also apply an event listener that re-checks the grid specifications when the user resizes the browser. As Internet Explorer has a nasty habit of firing the resize event while the user resizes the window, we need to throttle the execution of switchGrid(). This is explained in detail on Nicholas Zakas’ blog.

  };
  return {
    switch:switchGrid
  };
}();

As the throttle method needs a public method to call from setTimeout() we return a pointer to switchGrid.

That’s all. You can try out the effect on the demonstration page. If you define your sidebar independent of size, you can create some wonderfully dynamic and flexible sites with this little script.

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

Building Your Own Widget Library with YUI

June 24, 2008 at 9:09 am by Satyam | In Development | 10 Comments

The Yahoo! User Interface Library (YUI) has an ample assortment of components. Nevertheless, there will be always some functionality you want that a library like YUI hasn’t anticipated or hasn’t built yet. Sometimes you just want a subset of the many options a component might provide; in other cases, you may have a default configuration that you’d like to bake into a component to facilitate consistent use across your site. The flexibility built into YUI provides intrinsic support for extending, customizing, or creating wholly new components. If you find yourself in one of these situations, then building your own library of YUI-based components may make good sense.

This lengthy article is meant to get you started creating your own custom components using the tools available to you within YUI, including the Element Utility and the Event Utility. Understanding these tools can save you lots of time and make it easy to create API-driven components that expose powerful hooks to implementers making use of your work.

Continue reading Building Your Own Widget Library with YUI…

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

« Previous PageNext Page »
Hosted by Yahoo!

Copyright © 2007 Yahoo! Inc. All rights reserved. Privacy Policy - Terms of Service

Powered by WordPress on Yahoo! Web Hosting.