Download and apply only the styles I need.

Media queries are awesome! They allow me to target CSS rules to very specific solutions. If you’ve been reading my posts here, you’ll realize what my ultimate goal is: to produce a single product that runs properly on all targeted devices (desktop browsers, tablets, and smart phones). And my solution must be fast (light-weight) since mobile devices are still a bit under-powered.

@media queries are commonly part of (within) a CSS file. For example, in the code below, a width of 743 pixels is assigned to the “Hello World” div for only “screen” devices with a width of between 801 and 1280 pixels.

@media only screen
and (min-width :  801px)
and (max-width : 1280px)
{
   #helloWorld
   {
      width: 743px;
   }
}	

Intriguingly, @media queries can also be part of a <link> command. This is the example we often see when researching how to use @media queries.

<link rel="stylesheet" type="text/css" media="screen" href="sans-serif.css">
<link rel="stylesheet" type="text/css" media="print" href="serif.css">

This common example suggests that I should segregate my styles into CSS files intended for specific uses. In my personal project, this is exactly what I’ve done. Basically, I’ve set up 4 style sheets each designated for a specific range of screen widths.

<link rel="stylesheet" media="only screen                          and (max-width :  480px)" href="css/layouts/tiny.css" />
<link rel="stylesheet" media="only screen and (min-width :  481px) and (max-width :  800px)" href="css/layouts/small.css" />
<link rel="stylesheet" media="only screen and (min-width :  801px) and (max-width : 1280px)" href="css/layouts/medium.css" />
<link rel="stylesheet" media="only screen and (min-width : 1281px)                         " href="css/layouts/large.css" />

Problem

Problem is, this code still downloads ALL of the listed CSS files . . . even though I might only need the “tiny.css” on a smaller given smart phone.

Clearly, @media queries are not a complete solution since they still fetch all of the CSS files even if I know ahead of time that these CSS files/rules will never be used.

I want a solution that downloads and applies only the required styles for the given situation.

Solution

The first question is whether to use the @media queries inside the CSS or in the <link> commands. The answer is BOTH.

• You’ll want them in the <link> commands in order to prevent the fetching of a given CSS file. More on this later…
• You’ll also want them inside the CSS files in the event the client downloads multiple CSS files and needs to switch between them. For example, switching from portrait to landscape orientations might trigger switching from the tiny.css to the small.css rules.

Conditionally fetching CSS files

I’ve written a very small snippet of JavaScript that uses the @media queries in the <link> command to only download the CSS files that are relevant to the current device and situation.

This example uses the “width” @media query instead of the “device-width” for the following reasons:

• width takes into consideration the “pixel ratio”. For example, a Google Nexus 7 has a device-width of 1280 x 800. However, it’s pixel-ratio is 1.33 which means that it reports a CSS resolution of 966 x 603 . . . the resolution the vendor believes is optimal for this device.
• width changes based on orientation (orientation is just another resolution!). The iPad reports a device width of 768 in both portrait and landscape modes. The @media width value, however, properly changes as orientation is changed.
• width affects desktop displays as the browser is resized. This allows a Web UI on a browser to relayout as necessary based on the current browser size. Checking @media device-width always reports the same number.
• it’s much easier to base a series of @media statements on width since it doesn’t need to deal with all of the exceptions in dealing with device-width.

This code executes right when the file is loaded, and runs again as needed every time the device’s orientation changes or the window is resized.

NOTE: if the JavaScript method window.matchMedia() is not supported, this code then automatically allows and fetches the specified CSS files. In other words, it’s a fail-safe scenario when the conditional download mechanism is not available.

This code dynamically fetches only those files that are needed for the current situation …and downloads additional CSS files as needs change during execution.

Hope this helps!

   <script type="text/javascript" language="javascript">
      var head  = document.getElementsByTagName('head')[0];
      var links = document.getElementsByTagName('link');

      //Prevent adding the same <link> more than once
      function hasLink ( cssURL )
      {
         for ( x = 0; x < links.length; x++ )
         {
            var href = links[x].getAttribute ( "href" );
            if ( (typeof(href) != 'undefined') && (href === cssURL) )
               return true;
         }
         return false;
      }

      //Include CSS if Media Query matches or @media examination is not supported
      function includeCSS ( mediaQuery, cssURL )
      {
         var deviceQuery = window.matchMedia( mediaQuery );
         if ( (deviceQuery.matches == true) || (typeof(window.matchMedia) === 'undefined') )
         {
            if ( hasLink ( cssURL ) == false )
            {
               var link = document.createElement('link');
                   link.href = cssURL;
                   link.rel  = 'stylesheet';
                   link.type = 'text/css';
               head.appendChild(link);
            }
         }
      }

      function evaluateLayoutCSS()
      {
         includeCSS ( "only screen                          and (max-width :  480px)", "css/layouts/tiny.css"  );
         includeCSS ( "only screen and (min-width :  481px) and (max-width :  800px)", "css/layouts/small.css" );
         includeCSS ( "only screen and (min-width :  801px) and (max-width : 1280px)", "css/layouts/medium.css");
         includeCSS ( "only screen and (min-width : 1281px)                         ", "css/layouts/large.css" );
      }
      evaluateLayoutCSS(); //Run early at least once
   
      //Register events to recalculate the media queries on orientation and size changes
      window.onorientationchange = function() { evaluateLayoutCSS() };
      window.onresize            = function() { evaluateLayoutCSS() };
   </script> 

Responsive Web Sites

For those of you who don’t know what I’m talking about, check out these fine example sites. To see what I mean, click on a picture to load them into a browser window. Then slowly change the size of the browser and watch how these Web sites handle differences in screen size.

You’ll note that they dynamically change font and images sizes, and even completely change layouts, all based on the browser’s display size.

The point is that these sites look great all the way from a huge desktop screen down to the smallest smart phone display. That’s what we’re after.

OWLTASTIC

Deren K

Boston Globe

About.com

Inconsistent @media Values

As I set out to define my CSS files, my simple @media queries weren’t always working. Unfortunately, I quickly realized that I couldn’t just use “@media max-device-width:320px” and other increasing pixel values to define the range of devices I was going to support.

Bottom line, the expected results from the @media queries were not consistent across the various devices. For example:

• While most devices report the “@media device-width” based on the current orientation of the device, the iPad for some reason always reports its width as 768px in both landscape and portrait orientations!
• While most devices report the “@media device-width” as the actual number of pixels that make up the width of the device, some devices report a value less than the actual number of pixels in order to present a larger view to the user. For example the iPad 3′s display is physically 1536 x 2048. However, it reports a value of 768px for the “@media device-width” value.

Determining Actual @media Values for a Device

In order to create @media queries that isolate the range of devices I want to support, I needed to learn the values devices actually report for the various @media queries.

I hoped (assumed) I’d just find some simple Web page that I could load on each of the devices I was targeting and it would tell me the device’s actual values.

Turns out I was very wrong!

After a lot of Googling around, not only does this very useful Web page not exist (at least I can’t find it), but JavaScript can’t directly access these values either! So I can’t easily write my own page as a solution.

Problem

As of this writing, there are currently no properties on the window or screen objects to access the values examined by the @media queries. In other words, I can’t just “alert(‘Device Width: ‘+screen.deviceWidth)” to display all of the @media values.
Turns out a few are available, but I can’t be 100% certain they’re the same as the @media queries

Clearly, I can “test” against a given @media value. For example, I can write window.matchMedia( “min-device-width:768px” ), and this will return true for all devices that are 768 pixels wide or larger.

However, I can’t easily report what the device’s actual pixel width is. For example, my desktop screen is currently 1600 pixels wide, but would also match this query. In some cases, I could use “other” older JavaScript-accessible properties, but I specifically want to know how the @media values are reported since this is how I’m going to code my CSS.

Solution

I have created a simple Web page that you can load into any browser on any device, and it will directly report the value of each of the device’s @media queries.

It does this by simply testing every value until a value reports true. For example, for determining the device’s “@media device-width” value, it tests every value from 0 to 4000, and in the case of my desktop stops once it reaches 1600.

Clearly, there is a distinct speed issue here …especially if I examine 15 or 20 properties. To speed things up, I’ve created a set of “likely’ values for each property. For example, when reporting on the “@media color” value, I pass in [8,10,12,16,24,32] as likely tests. If this list fails, then it will test every value from 0 to 4000. In most cases, the likely values are used. In a few cases — usually when a browser doesn’t support a given @media query — it’ll take a bit longer …but no more than 5 seconds or so.

It’s a work-in-progress. As I get to using it on more devices, I’ll refine, add, update as necessary. But for now, this should do quite well.

Hope it helps you too.

<link rel="stylesheet" media="only screen                          and (max-width :  480px)" href="css/layouts/tiny.css" />
<link rel="stylesheet" media="only screen and (min-width :  481px) and (max-width :  800px)" href="css/layouts/small.css" />
<link rel="stylesheet" media="only screen and (min-width :  801px) and (max-width : 1280px)" href="css/layouts/medium.css" />
<link rel="stylesheet" media="only screen and (min-width : 1281px)                         " href="css/layouts/large.css" />

See your device’s @media values now.

Here’s what the output looks like

]]> http://www.peterclemons.org/blog/?feed=rss2&p=256 0 http://www.peterclemons.org/blog/?p=251 http://www.peterclemons.org/blog/?p=251#comments Tue, 31 Jul 2012 22:32:59 +0000 http://www.peterclemons.org/blog/?p=251 Continue reading →]]> Just a quick note for how to modify a standard JSON reply to support requesting data across domains

The answer here is really quite simple …if the &callback=something parameter is provided, then:

    //JSONP opening
    if ( callback != null )
        jsonBuf.append ( callback + "(" );
    
    //Beginning of standard reply
    JSON data
    //End of standard reply
    
    //JSONP closure
    if ( callback != null )
        jsonBuf.append ( ");" );

If you’re like most people, and JSON-P is being considered long after all of your REST end-points have already been created, then coding a method that simply wraps the existing REST replies within the “something( normal rest reply );” construct is a very fast way of supporting cross-browser scripting for rest clients.

• It appears there’s a performance penalty for using JSON-P instead of straight JSON replies. See http://jsperf.com/ajax-jsonp-vs-ajax-json for more information.
• Just FYI, Jersey already supports JSON-P with a simple annotation of the REST end-points, and a minor wrapping of the reply as noted above. Further, Jersey recognizes the application/x-javascript mine type to return a JSON-P response without requiring the &callback= query parameter.
• JSON-P is a mature enough technology that JQuery, Dojo, YUI, MooTools, Windows WCF, Sencha Touch, IBM BPM, and most other relevant web client and server products now support it.
• Our chosen DataTables also supports JSON-P with the following modification:

  "fnServerData": function( sUrl, aoData, fnCallback, oSettings )
  {
     oSettings.jqXHR = $.ajax(
     {
        "url"       : sUrl,
        "data"      : aoData,
        "dataType"  : "jsonp",
        "cache"     : false,
        "success"   : fnCallback
     } );
  }
  

Goal

Make it MUCH easier for customers to brand Web-based products

Note that the primary goal here is NOT to make it easier for developers to create CSS files. The primary goal is for CUSTOMERS to more easily modify CSS files. In other words, even though we could modify CSS in much more dramatic ways to make it easier for developers to create these files, the goal here is not developers, rather end users. So, the CSS file needs to remain as user friendly and familiar as possible while still making it much easier to brand the CSS.

Problem Statement

Solution 1

Solution 2

What’s Coming in CSS

• CSS Variables is already in draft form
  • http://dev.w3.org/csswg/css-variables/
• CSS Mixins is currently in proposal form
  • http://dev.w3.org/csswg/css-variables/
• Variables, mixins, and nesting are already in WebKit (in an experimental form)
  • http://johanbrook.com/design/css/webkit-css-variables-mixins-nesting/
  • http://www.webmonkey.com/2012/06/css-variables-webkit-brings-the-css-jackalope-to-life/

Looks like whatever solution I find, it’s going to be somewhat temporary since the W3C is already under way to add some of these awesome features into CSS.

The ideal solution would not only be easy to use for customers, but would also easily migrate to the standard solution once that’s fully supported by all browsers in a year or two.

Seeing that the goal is to make it easy for customers to brand our CSS, the ideal solution will look as much like standard css as possible. In other words, it will NOT use all these new Less and Sass CSS features. Bare minimum is best.

Solution 3

• ZUSS is a pure Java package; that’s good already since that means it can be part of my standard development environment. I can use either the jar directly, or modify the source code as needed.
• It’s tiny
  • 89K (Wow!! — compare that to Less and Sass above)
  • 73 files in 1 jar (again Wow!)
• ZUSS supports most of the new CSS features the other packages support:
  • Variables
  • Mixins
  • Nested Rules
  • Functions
  • Includes
  • Conditional Expressions
• ZUSS provides a small servlet that compiles the CSS files on demand (when requested from the browser)
  • This allows our CSS to be either in a War file (which is how Web products are usually distributed) or in an external directory where customers could copy and edit the files.
  • Caches CSS for future requests
  • Recompiles as CSS files are changed
• ZUSS is licensed under the GNU Lesser GPL which means it’s very developer and distribution friendly

Fonts

Here’s how a font is defined in my new CSS:

@global-font-family()
{
   font-family: Helvetica, Arial, sans-serif;
}

Notice that it begins with an @ symbol. This designates a variable in the ZUSS language. In other words, global-font-family() becomes a mixin when used.

Notice also that global-font-family() contains a full CSS attribute declaration: font-family: Helvetica, Arial, sans-serif;    We could have included any number of other attribute definitions, for example size, color, margins, line height, font weight and style, etc. Anything placed within the braces is included when used elsewhere in the CSS file.

Here’s the mixin used elsewhere in the CSS:

.welcomeHeader
{
   @global-font-family();
   font-size: 2em;
}

Sweet !!

Colors

Here’s how a color is defined in my new CSS:

@product-color: #8cc63f; /* product name in nav bar, links, quote bin header, active button background, slider value, bread crumb sep */

Any time I want to use that color, I simply:

.headerLogoText
{
   color: @product-color;
}

Functions

If you paid attention to the comment in the color variable defined above, you’ll note we’re using that same color in lots of areas throughout the product. A good 15 places use that color directly, as is. However, buttons have gradients, hovers, and pressed states. Links change colors when hovered or visited.

And we’d like to use a “faint” version of the color when selecting items in rows. Rather than having the customer specify all the variants of a given color, wouldn’t it be cool if we could automatically “derive” the color from the primary color. That way, all the customer has to specify is a single color …and none of its variants.

ZUSS offers two kinds of functions to do this type of task:

• A simple function defined in CSS permitting basic math functions and color manipulations

  @lighten(@color, @diff: 10%): @color * (1 + @diff);

• Java-defined functions that can be called directly by our CSS and can provide any range of sophistication

  @lighten(@color, @diff: 10%): @import com.netiq.agility.client.internal.ColorUtils;

We chose to go with the more sophisticated Java-based functions permitting more accurate color calculations.

• Here’s our ColorUtils.java class in which we created a series of high-fidelity color rendering methods
• These are based on the HSB (Hue, Saturation, Brightness) color model which is also supported by the basic Java Color class and by Photoshop.
  • It’s much easier to make a color brighter by simply adjusting the “brightness” factor than trying to calculate Red, Green, and Blue values.

Derived Colors

Now that we have color variables and high-fidelity color manipulation routines, let me show you what we did for the single “product color” which I think you’ll agree most Web interfaces have:

/* User-provided Colors */
@product-color:                     #8cc63f;   /* product name in nav bar, links, quote bin header, active button background, slider value, bread crumb sep */

/* Derived Colors - users do NOT need to edit these colors */
@product-color-lighter:             @lighten   ( @product-color, 15% );
@product-color-darker:              @darken    ( @product-color, 15% );

@product-color-hover:               @highlight ( @product-color, "-92%" );
@product-color-hover-lighter:       @lighten   ( @product-color-hover, 3% );
@product-color-hover-darker:        @darken    ( @product-color-hover, 5% );

@product-color-select:              @highlight ( @product-color, "-78%" );
@product-color-select-lighter:      @lighten   ( @product-color-select, 3% );
@product-color-select-darker:       @darken    ( @product-color-select, 5% );

/* hover */
@active-bhover-color:               white;
@active-bhover-background-color:    @lighten   ( @product-color, 10% );
@active-bhover-background-start:    @lighten   ( @active-bhover-background-color, 5%);
@active-bhover-background-end:      @darken    ( @active-bhover-background-color, 12%);
@active-bhover-border:              @darken    ( @active-bhover-background-color, 15%);
@active-bhover-shadow-color:        @shadow    ( @active-bhover-background-end );

/* pressed */
@active-bdown-color:                black;                                          /* invert the hover color */
@active-bdown-background-color:     @darken    ( @product-color, 5% );
@active-bdown-background-start:     @active-bhover-background-end;                  /* invert the hover color */
@active-bdown-background-end:       @active-bhover-background-start;                /* invert the hover color */
@active-bdown-border:               @darken    ( @active-bdown-background-color, 12% );
@active-bdown-shadow-color:         @shadow    ( @active-bdown-background-end );

We’ve created 20 variants on the primary user-provided “Product Color”. These 20 colors are then used throughout the CSS whenever a product-color-related accent is desired.

• Links (normal, hover, visited)
• Buttons (gradients for normal, hover, pressed)
• Product logo
• Header colors
• Scroll bar thumb
• Bread crumb separators
• Triggers in various UI widgets (combo, spinner, date picker, etc.)
• List selection and hover
• many other UI elements use versions of the product color !

In all, there are hundreds of places throughout the CSS where these 21 colors are used.

I think you’ll agree, that’s a lot of benefit for the customer …and they only had to define 1 color value to do so !!!

Note that in our final implementation, we ask the user to define approximately 15 primary colors in a single location at the top of the CSS file. And that’s it. Press refresh in your browser, and the entire color scheme changes throughout.

Includes

To make our files even simpler, we used ZUSS’s include ability to hide our function declarations and derived color definitions in separate include files that our customers will never see as they edit the CSS to make their own Themes.

@include functions.ncss;
@include derived_colors.ncss;

Provide a Theming Generator

Come to think of it, now that our CSS is sssssoooooooo simple, we could very easily produce a simple dialog within our product that allows the user to define the colors right from the UI …rather than having to find/copy/edit/save the CSS in the file system.

This “Theme Creator” dialog would be very simple to create. Just ask for a small set of color and font definitions, show examples of each in action, ask for a Theme name, and that’s it.

I’ll leave this for a future exercise to blog about.

]]> http://www.peterclemons.org/blog/?feed=rss2&p=187 1 http://www.peterclemons.org/blog/?p=175 http://www.peterclemons.org/blog/?p=175#comments Tue, 10 Jul 2012 16:12:18 +0000 http://www.peterclemons.org/blog/?p=175 Continue reading →]]> I propose DataTables is the best choice for any project wanting to provide a single solution for both desktop and mobile devices.

While both jqGrid and DataTables are excellent technology and both meet the “good enough” criteria, DataTables has a slight edge for mobile devices.

* note that SlickGrid was eliminated as a candidate.

Here are my reasons for proposing DataTables:

• DataTables has a smoother scrolling algorithm on mobile devices (iPad 3)
  • Video of jqGrid scrolling on an iPad 3
  • Video of DataTables scrolling on an iPad 3
• DataTables auto-eliminates the scroll bar and uses the device’s scrolling method
• jqGrid’s styling is more heavily bound to JQuery UI, creating greater conflict as we try to be JQuery Mobile compliant
• DataTables implements Virtual Rendering …deferring draw calls until needed
• By Default, DataTables download size is considerably smaller: 25K vs 68K
• DataTables has an excellent unit test suite comprising over 2800 tests
• DataTables provides over 130 pre-built examples
• DataTables provides a nicer ability to “expand” a row to show additional detail

Of course, jqGrid also has some advantages over DataTables. However, we do not need these in our current solution. For more details, see the jqGrid Evaluation post.