plainblack.com
Username Password
search
Bookmark and Share

    

Graceful degredation

User patspam
Date 9/25/2008 1:55 am
Views 2985
Rating 0    Rate [
|
]
Previous · Next
User Message
patspam
patspam
Hi guys,

Some food for thought..

The current default Navigation menu is rendered dynamically by YUI from WebGUI-generated html markup. This is great because it means we can do graceful degredation for people without Javascript (and also makes the nav links available for SEO).

However if you view the default WG site (attachment: nav-js.png) with Javascript turned off, you will see that the navigation links look pretty aweful (attachment: nav-broken.png). It's pretty easy to fix though (attachment: nav-noscript.png), just edit the navigation template as follows:
  1. Add an extra class called something like "noscript" to the webguinavigation div
    <div id="webguinavigation" class="yuimenubar noscript">
  2. Add an extra line to the javascript which will automatically remove this class for js-enabled viewers:
    YAHOO.util.Dom.removeClass('webguinavigation', 'noscript');
  3. Add some extra CSS targetting the noscript class to make things look nicer for non-js viewers:
    #webguinavigation.noscript {
        background: none; /* hide normal background */
    }
    #webguinavigation.noscript li {
        display: inline; /* display on single line */
        margin-right: 5px;
    }
    #webguinavigation.noscript li div {
        display: none; /* hide sub-menus */
    }
It would be nice to apply this sort of approach in general to templates so that sites degrade nicely. I'm sure someone can suggest a better name than "noscript" for the class too :)

Patrick


Attached Files
Back to Top
Rate [
|
]
 
 
rogier

It would be nice to apply this sort of approach in general to templates so that sites degrade nicely. I'm sure someone can suggest a better name than "noscript" for the class too :)

Patrick

Let's think about javascript in the context of the templates in general. Graceful degradation is ofcourse a requirement as well as unobtrusiveness. There are a couple of places where this might be an issue:

  • YUI navigation
  • The CS post templates Arjan is talking about here
  • The gallery slideshow (I think? - haven't checked out the gallery yet)
  • ...

Lets make an inventory: do we know any other places where js can be found? Is it:

  • degrading gracefully?
  • unobtrusive?
  • ...any other requirements?

I'm no js expert so I'll need some help with this.

 

Rogier | United Knowledge
www.unitedknowledge.nl · www.webgui-help.nl



Back to Top
Rate [
|
]
 
 
patspam
patspam
Hi folks,

I've applied this graceful degredation technique to the hierarchical-top-nav template on the template site.

Some comments for feedback:
  • I noticed that the outer-most containing div of the nav is given a generated id of "navigation-<tmpl_var assetId>". I appreciate that it's nice to have a unique id for the nav if you want multiple navs on one page, however using the assetId is problematic for two reasons
    • the assetId may contain periods "." or colons ":" which, whilst valid html, will cause headaches for designers trying to use CSS selectors to target the id (the period will be interpreted as a class selector, and the colon will be interpreted as a pseudo-selector)
    • if you do use an id selector to target the element, your selector is going to be coupled with the assetId. I'm not sure that's a desirable thing. I think I'd rather have a standard default id (a different one for each nav type) and if users want to have multiple navs of the same type on a page let them customize the template to achieve that.
  • given the aforementioned problem with css selectors targeting the element id, I opted to use a class of "h-top-nav-noscript" as the class that is initially applied to the element for browsers without js, and then dynamically removed with js. The h-top-nav-noscript class is used to hide all but the top-level nav items, and also to give the non-js rendered nav an appearance similar to the js nav (to reduce render flicker). I'm not a designer so if someone wants to tweak the style-sheet to further prettify the non-js version then please do (you can view the non-js version by disabling js in your browser and refreshing the page).
  • The js has been refactored to use the module pattern (function(){}) to reduce namespace pollution
  • Colin has fixed some nav-related bugs recently that has hopefully gotten rid of the issues with invalid html being generated
Post-feedback I'll have a crack at the other nav templates.

Patrick

On Wed, Oct 1, 2008 at 8:12 PM, <rogier@unitedknowledge.nl> wrote:
rogier wrote:

It would be nice to apply this sort of approach in general to templates so that sites degrade nicely. I'm sure someone can suggest a better name than "noscript" for the class too :)

Patrick

Let's think about javascript in the context of the templates in general. Graceful degradation is ofcourse a requirement as well as unobtrusiveness. There are a couple of places where this might be an issue:

  • YUI navigation
  • The CS post templates Arjan is talking about here
  • The gallery slideshow (I think? - haven't checked out the gallery yet)
  • ...

Lets make an inventory: do we know any other places where js can be found? Is it:

  • degrading gracefully?
  • unobtrusive?
  • ...any other requirements?

I'm no js expert so I'll need some help with this.

 

Rogier | United Knowledge
www.unitedknowledge.nl ยท www.webgui-help.nl



http://www.plainblack.com/forums/webgui-templates-working-group/graceful-degredation/1



--

Plain Black&#44; makers of WebGUI
http://plainblack.com




Back to Top
Rate [
|
]
 
 
rogier

  •  
    • the assetId may contain periods "." or colons ":" which, whilst valid html, will cause headaches for designers trying to use CSS selectors to target the id (the period will be interpreted as a class selector, and the colon will be interpreted as a pseudo-selector)
    • if you do use an id selector to target the element, your selector is going to be coupled with the assetId. I'm not sure that's a desirable thing. I think I'd rather have a standard default id (a different one for each nav type) and if users want to have multiple navs of the same type on a page let them customize the template to achieve that.


I'm pretty certain assetIDs are alphanumeric plus underscore and hyphen. Underscores are the only problem here, they may cause problems.

The assetId is not really necessary for navs, since usually there isn't more than one nav of a certain type on a page. For articles or other common assets though, unique IDs are a great feature. They enable designers to style token assets and are very useful for controling css specificity.

A possibility is to add an RFE to remove the underscore from the assetId syntax.

 

Rogier | United Knowledge
www.unitedknowledge.nl · www.webgui-help.nl



Back to Top
Rate [
|
]
 
 
patspam
patspam
    • the assetId may contain periods "." or colons ":" which, whilst valid html, will cause headaches for designers trying to use CSS selectors to target the id (the period will be interpreted as a class selector, and the colon will be interpreted as a pseudo-selector)
    • if you do use an id selector to target the element, your selector is going to be coupled with the assetId. I'm not sure that's a desirable thing. I think I'd rather have a standard default id (a different one for each nav type) and if users want to have multiple navs of the same type on a page let them customize the template to achieve that.

I'm pretty certain assetIDs are alphanumeric plus underscore and hyphen. Underscores are the only problem here, they may cause problems.

I didn't know underscores were problematic too, thanks for the info! All true for auto-generated assetIds, the only problem being that some wG assets have manually chosen ids. One example being the hierarchical-top-nav template. E.g. If you look at the front page of the template site you'll see that the top nav has an id of "navigation-7.0-style0000000000070" which comes from the template having an id of "7.0-style0000000000070".

So we either need to:
  • get the ids changed for all assets with manually chosen ids (dangerous, unlikely to happen - see bottom comment)
  • create a filter to strip dangerous characters and make sure that assetIds are passed through this function prior to use as element ids

The assetId is not really necessary for navs, since usually there isn't more than one nav of a certain type on a page. For articles or other common assets though, unique IDs are a great feature. They enable designers to style token assets and are very useful for controling css specificity.

Agreed. Initially I didn't like the idea of using assetIds at all, but I think I'm warming to the idea.

A possibility is to add an RFE to remove the underscore from the assetId syntax.

I'm pretty sure this would be blocked because it would be pretty much almost impossible to try to change all of the assetIds in the wild to conform to the new standard.

I've submitted a bug report with the suggestion that we create a filter to strip dangerous/invalid characters from assetIds.

Regards,

Patrick


Back to Top
Rate [
|
]
 
 
rogier

  • given the aforementioned problem with css selectors targeting the element id, I opted to use a class of "h-top-nav-noscript" as the class that is initially applied to the element for browsers without js, and then dynamically removed with js. The h-top-nav-noscript class is used to hide all but the top-level nav items, and also to give the non-js rendered nav an appearance similar to the js nav (to reduce render flicker). I'm not a designer so if someone wants to tweak the style-sheet to further prettify the non-js version then please do (you can view the non-js version by disabling js in your browser and refreshing the page).
  • The js has been refactored to use the module pattern (function(){}) to reduce namespace pollution

This all sounds good. I'll take a look at it tomorrow.


  • Colin has fixed some nav-related bugs recently that has hopefully gotten rid of the issues with invalid html being generated


I don't think that solves the validation issues with that specific template, but now you've done your .js magic, that's an easy fix for me.

 

Rogier | United Knowledge
www.unitedknowledge.nl · www.webgui-help.nl



Back to Top
Rate [
|
]
 
 
© 2012 Plain Black Corporation | All Rights Reserved