<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">

    <title type="text">Filament Group, Inc: Lab</title>
    <subtitle type="text">Lab:What we&apos;re thinking at Filament Group</subtitle>
    <link rel="alternate" type="text/html" href="/lab" />
    <link rel="self" type="application/atom+xml" href="http://filamentgroup.com/lab/atom/" />
    <updated>2012-11-28T16:27:13Z</updated>
    <rights>Copyright (c) 2012, Zach</rights>
    <generator uri="http://expressionengine.com/" version="1.6.1">ExpressionEngine</generator>
    <id>tag:,2012:11:26</id>


    <entry>
      <title>Chatting with Adobe about Responsive Design and BostonGlobe.com</title>
      <link rel="alternate" type="text/html" href="http://filamentgroup.com/lab/filament_group_adobe_video/" />
      <id>tag:,2012:/lab/6.152</id>
      <published>2012-12-14T17:07:01Z</published>
      <updated>2012-12-14T17:17:41Z</updated>
      <author>
            <name>Scott</name>
                  </author>

      <category term="announcements"
        scheme="http://filamentgroup.com/lab/tag/announcements/"
        label="announcements" />
      <category term="progressive enhancement"
        scheme="http://filamentgroup.com/lab/tag/progressive_enhancement/"
        label="progressive enhancement" />
      <category term="responsive design"
        scheme="http://filamentgroup.com/lab/tag/responsive_design/"
        label="responsive design" />
      <content type="html"><![CDATA[
       <p class="postData">Posted by FG on 12/14/2012</p>

<dl class="topics">
					<dt>Topics:</dt>
					<dd><a href="http://filamentgroup.com/lab/tag/announcements/" rel="tag">announcements</a></dd><dd><a href="http://filamentgroup.com/lab/tag/progressive_enhancement/" rel="tag">progressive enhancement</a></dd><dd><a href="http://filamentgroup.com/lab/tag/responsive_design/" rel="tag">responsive design</a></dd>
				</dl>
						<p>Earlier this fall, Todd, Scott and our friends at The Boston Globe and Upstatement sat down with Adobe's video production team in Boston to discuss our development process for BostonGlobe.com, considered to be the world's first large-scale responsive website, and how the Adobe product suite helped out with the process.  Thanks to everyone at Adobe for inviting us to the table!</p>

<p>You can view the video below on the Adobe website.</p>

<p><a href="http://tv.adobe.com/watch/create-now/the-boston-globe-filament-group-inc-and-upstatement-and-rwd/"><img src="/images/bg-adobe-video.jpg" alt="The Boston Globe, Filament Group, Inc. and Upstatement and RWD
" /></a></p>
					</div>
		
					
<a href=""></a>
      ]]></content>
    </entry>

    <entry>
      <title>SocialCount, a jQuery Plugin for Lighter &amp;amp; Faster Social Networking Widgets</title>
      <link rel="alternate" type="text/html" href="http://filamentgroup.com/lab/socialcount/" />
      <id>tag:,2012:/lab/6.151</id>
      <published>2012-11-26T22:16:00Z</published>
      <updated>2012-11-28T16:27:13Z</updated>
      <author>
            <name>Zach</name>
                  </author>

      <category term="jQuery"
        scheme="http://filamentgroup.com/lab/tag/jquery/"
        label="jQuery" />
      <content type="html"><![CDATA[
       <p class="postData">Posted by Zach on 11/26/2012</p>

<dl class="topics">
					<dt>Topics:</dt>
					<dd><a href="http://filamentgroup.com/lab/tag/jquery/" rel="tag">jQuery</a></dd>
				</dl>
						<p>You're minding your own business, casually browsing around on the World Wide Web. You navigate to a page that begins to load and render, but suddenly it stalls. For a few seconds you stare at a partial white screen, appalled at the hiatus your device has placed on your browsing flow. Finally, the page yields and loads the remainder of the content. What just happened? It's likely that you've fallen prey to a poorly implemented Facebook, Twitter, or Google Plus share button.</p>
					</div>
		
					<p>Social Networking widgets are a digital blot on the beautiful canvas we call the web. They often do not (with intent) blend with a site's design or with each other.</p>

<p>Design considerations aside, the widgets' biggest affliction is their file size.  Even though current implementations of sharing widgets from the &#8216;Big 3&#8217; social networks unanimously recommend the use of non-blocking JavaScript (despite widespread use of older blocking versions), they still include a ~200KB mass of JavaScript and CSS (transfer size is <strong>after</strong> minification and GZip). Initializing all of these widgets simultaneously on page load causes multiple DOM modifications often resulting in pages that feel unresponsive and resistant to scrolling (read: janky).</p>

<p>A discerning developer might begin to wonder if it is possible to use these sharing tools without adversely affecting page performance and accessibility.</p>

<p>To solve these problems, we built SocialCount. It's a jQuery plugin to add sharing widgets in a responsible way. The project has the following goals:</p>
<ul>
<li>Easily customize to your site's design.</li>
<li>Works with mouse, touchscreen, or keyboard.</li>
<li>Progressively enhanced from simple sharing links: share without JavaScript or before JavaScript has loaded (touchscreen experience).</li>
<li>Lazily load individual native widgets when the user expresses intent to share, allowing embedded Like/+1 without leaving the current page (non-touchscreen experience).</li>
<li>Small and concise, only 3KB for the JavaScript and CSS (after minification and gzip).</li>
</ul>

<h2>See it in action</h2>

<style>
#socialcount-example {
  width: 100%;
  max-width: 320px;
  border: none;
  height: 60px;
  -webkit-transition: height .4s ease;
  -moz-transition: height .4s ease;
  transition: height .4s ease;
}
#socialcount-example:hover {
  height: 320px;
  max-width: 100%;
}
</style>
<iframe id="socialcount-example" src="http://fgte.st/SocialCount/examples/blog.html" scrolling="no"></iframe>

<p>SocialCount comes in <a href="http://fgte.st/SocialCount/examples/index.html">a variety of sizes and orientations</a>.</p>

<h2>How to use it</h2>

<p>Add <a href="https://raw.github.com/filamentgroup/SocialCount/master/dist/socialcount.js"><code>socialcount.js</code></a> and <a href="https://raw.github.com/filamentgroup/SocialCount/master/dist/socialcount.css"><code>socialcount.css</code></a> to your page, ideally the CSS in the &lt;head&gt; and JS at the end of the &lt;body&gt;.</p>

<p>Use the included <a href="http://fgte.st/SocialCount/examples/#generator">Markup Generator</a> to create your baseline HTML.</p>

<pre><code>
&lt;ul class=&quot;socialcount&quot; data-url=&quot;http://www.filamentgroup.com/&quot; data-counts=&quot;true&quot;&gt;
  &lt;li class=&quot;facebook&quot;&gt;&lt;a href=&quot;https://www.facebook.com/sharer/sharer.php?u=http://www.filamentgroup.com/&quot; title=&quot;Share on Facebook&quot;&gt;&lt;span class=&quot;count&quot;&gt;Like&lt;/span&gt;&lt;/a&gt;&lt;/li&gt;
  &lt;li class=&quot;twitter&quot;&gt;&lt;a href=&quot;https://twitter.com/intent/tweet?text=http://www.filamentgroup.com/&quot; title=&quot;Share on Twitter&quot;&gt;&lt;span class=&quot;count&quot;&gt;Tweet&lt;/span&gt;&lt;/a&gt;&lt;/li&gt;
  &lt;li class=&quot;googleplus&quot;&gt;&lt;a href=&quot;https://plus.google.com/share?url=http://www.filamentgroup.com/&quot; title=&quot;Share on Google Plus&quot;&gt;&lt;span class=&quot;count&quot;&gt;+1&lt;/span&gt;&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
</code></pre>

<p>That's it!</p>

<h3><a href="https://github.com/filamentgroup/SocialCount">View the code on GitHub</a></h3>

<p>Special thanks to <a href="https://twitter.com/ematthys">Eric Matthys</a> for his <a href="http://codepen.io/ericmatthys/pen/FfcEL">base inline loading widget</a> and to <a href="https://twitter.com/johndyer">John Dyer</a> for his post on <a href="http://johndyer.name/getting-counts-for-twitter-links-facebook-likesshares-and-google-1-plusones-in-c-or-php/">retrieving counts from various Social Networks</a>.</p>
<a href=""></a>
      ]]></content>
    </entry>

    <entry>
      <title>The `main` Element</title>
      <link rel="alternate" type="text/html" href="http://filamentgroup.com/lab/the_main_element/" />
      <id>tag:,2012:/lab/6.150</id>
      <published>2012-11-09T19:00:00Z</published>
      <updated>2012-11-09T23:01:53Z</updated>
      <author>
            <name>Mat</name>
                  </author>

      <category term="accessibility"
        scheme="http://filamentgroup.com/lab/tag/accessibility/"
        label="accessibility" />
      <category term="web standards"
        scheme="http://filamentgroup.com/lab/tag/web_standards/"
        label="web standards" />
      <content type="html"><![CDATA[
       <p class="postData">Posted by Mat on 11/09/2012</p>

<dl class="topics">
					<dt>Topics:</dt>
					<dd><a href="http://filamentgroup.com/lab/tag/accessibility/" rel="tag">accessibility</a></dd><dd><a href="http://filamentgroup.com/lab/tag/web_standards/" rel="tag">web standards</a></dd>
				</dl>
						<p>Here at Filament Group, we love us some markup. We&#8217;re the sort of nerds that can quote the HTML5 specification from memory, and we&#8217;re always champing at the bit for opportunities to work richer semantic meaning into our content. We&#8217;re also no strangers to the web standards process, and staying current gives us a chance to spot new and exciting proposals as they&#8217;re coming down the pike.</p>

<p>Lately we&#8217;ve been keeping a close eye on the <a href="https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html"><code>main</code> element extension spec</a> championed by <a href="http://twitter.com/stevefaulkner">Steve Faulkner</a>, which aims to provide an element that delineates the primary content on a page, independent of HTML5&#8217;s <a href="http://html5doctor.com/outlines/">document outline</a>.</p>
					</div>
		
					<h3>HTML5 semantics and ARIA landmarks</h3>

<p>ARIA roles allow us to assign additional semantic meaning to existing elements&#8212;a means of enhancing legacy markup, in a way that would be completely ignored by browsers that might not understand those role attributes. They&#8217;re supported by JAWS (10+), NVDA (2010.1+),  Apple&#8217;s VoiceOver for keyboard or gesture-based navigation, and other assistive technologies.</p>

<p>These ARIA attributes were intended to be something of a stop-gap while we waited for HTML5&#8217;s new semantic elements to fully mature and gain wider support. For example: <code>&lt;div role="navigation"&gt;</code> was intended to eventually be replaced by <code>&lt;nav&gt;</code>, which would have all the same meaning to browsers and assistive technologies. This way we wouldn&#8217;t end up with two disparate but redundant means of assigning meaning to our content.</p>

<table>
<thead>
<tr>
<th scope="col">ARIA Role</th>
<th scope="col">HTML5 Element</th>
</tr>
</thead>
<tbody>
<tr>
<td>banner</td>
<td>header</td>
</tr>
<tr>
<td>complementary</td>
<td>aside</td>
</tr>
<tr>
<td>contentinfo</td>
<td>footer</td>
</tr>
<tr>
<td>navigation</td>
<td>nav</td>
</tr>
<tr>
<td>article</td>
<td>article</td>
</tr>
<tr>
<td>main</td>
<td><i>N/A</i></td>
</tr>
</tbody>
</table>

<p>The ARIA role <code>main</code> is intended to serve as an alternative to a &#8220;skip to main content&#8221; link, something especially helpful to users accessing a site by way of assistive tech or navigating by keyboard alone. It provides the browser (or the users&#8217; assistive software) with a predictable landmark for the page&#8217;s primary content so that &#8220;skip to main content&#8221; functionality can be built into the browsing software, rather than being dependent on the developer adding a link at the top of the document.</p>

<p>Up to this point, HTML5 has lacked a functional equivalent to ARIA&#8217;s <code>main</code>, however&#8212;at least until the proposed <code>main</code> element came along.</p>

<h3>Seamless accessibility, no downsides</h3>

<p>The <code>main</code> proposal replaces a common markup pattern&#8212;<code>&lt;div id="main"&gt;</code>, <code>&lt;div class="wrap"&gt;</code>, and the like&#8212;with an element that has a much greater potential benefit to users, and no costs. Newer operating systems, browsers, and assistive technologies have begun treating HTML5&#8217;s elements like their ARIA counterparts, meaning we&#8217;ll start seeing all the benefits of ARIA anytime we&#8217;re writing semantically-meaningful markup. </p>

<p>I&#8217;m a big advocate of finding ways to encourage developers to build accessible websites &#8220;by accident,&#8221; without requiring a pass at &#8220;bolting on&#8221; accessibility as a separate step. As much as I&#8217;m all about ARIA's the benefits for users, adding the extra roles is still an extra layer on the markup, and a set of concerns separate from our structure. You don&#8217;t see them getting quite as much use as they should, given that additional effort&#8212;not to mention the effort involved in memorizing the whole roster of roles and the interplay between them. Adding the new 'main' element would alleviate the need for that extra markup and still identify key content on many, many web pages.</p>


<h3>On the other hand&hellip;</h3>

<p>There are <a href="http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0055.html">a few opponents</a> of this extension specification, with the reasoning being that the role of the main content can be inferred using other existing HTML5 elements&mdash; i.e., by ignoring any elements that <em>couldn&#8217;t</em> be the main content (<code>header</code>, <code>aside</code>, etc.), we can assume that whatever remains must be the main content. It&#8217;s being called the &#8220;<a href="https://gist.github.com/4032962">Scooby-Doo algorithm</a>&#8221;: by eliminating everybody who couldn&#8217;t possibly be the one running around in a swamp monster mask, you&#8217;re left with only one possibility: it was old man Jenkins all along. And he would&#8217;ve gotten away with it, too.</p>

<aside>
<blockquote>
<p>When you have eliminated the impossible, whatever remains, however improbable, must be the <del>truth</del> main content.</p>
<address>Arthur Conan Doyle</address>
<cite>Sherlock Holmes; The Sign of the Four</cite>
</blockquote>
</aside>

<p>This line of reasoning is true in principle, but can be relied upon only as long as all the other markup on the page structured correctly&mdash;which is far more involved (and perhaps more error-prone) than simply replacing a common pattern with a single element.</p>

<h3>Can we use this today?</h3>

<p>At this time, the <a href="https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html">main element spec</a> is still an unofficial extension specification. As of now, it hasn&#8217;t been implemented or merged into <a href="http://filamentgroup.com/lab/thetwospecs/">either of the HTML specifications</a>, so it&#8217;s a bit too early to use it. Once <a href="http://lists.w3.org/Archives/Public/public-html/2012Oct/0133.html">accepted as an FPWD</a> (&#8220;First Public Working Draft,&#8221; standards-speak for &#8220;likely to be implemented in browsers&#8221;) we&#8217;d likely want to start using it in conjunction with a redundant <code>role="main"</code> attribute until it saw wider adoption, for the sake of browsers that currently recognize the role but not the new element.</p>

<p>If the <code>main</code> element sounds interesting to you, get involved in the ongoing discussions on both the <a href="http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-November/037800.html">WHATWG mailing list</a> and the <a href="http://lists.w3.org/Archives/Public/public-html/2012Oct/0133.html">HTML WG mailing list</a>&#8212;or at least keep a close eye on this proposal as it evolves.</p>
<a href=""></a>
      ]]></content>
    </entry>

    <entry>
      <title>Compressive Images</title>
      <link rel="alternate" type="text/html" href="http://filamentgroup.com/lab/rwd_img_compression/" />
      <id>tag:,2012:/lab/6.149</id>
      <published>2012-10-30T20:08:00Z</published>
      <updated>2012-10-30T22:13:04Z</updated>
      <author>
            <name>Scott</name>
                  </author>

      <category term="progressive enhancement"
        scheme="http://filamentgroup.com/lab/tag/progressive_enhancement/"
        label="progressive enhancement" />
      <category term="responsive design"
        scheme="http://filamentgroup.com/lab/tag/responsive_design/"
        label="responsive design" />
      <content type="html"><![CDATA[
       <p class="postData">Posted by Scott on 10/30/2012</p>

<dl class="topics">
					<dt>Topics:</dt>
					<dd><a href="http://filamentgroup.com/lab/tag/progressive_enhancement/" rel="tag">progressive enhancement</a></dd><dd><a href="http://filamentgroup.com/lab/tag/responsive_design/" rel="tag">responsive design</a></dd>
				</dl>
						<p>Here at Filament Group, we've invested a great deal of time thinking about how best to deliver images that look sharp on devices from a low-resolution phone to High-resolution (HD) screens like Apple&#8217;s Retina&#8482; or the new Nexus 10, while being as lightweight as possible for performance. In practice, this is more difficult than it may sound, as there is currently no <a href="http://responsiveimages.org">native HTML solution to deliver different versions of an image</a>, so we <a href="https://github.com/scottjehl/picturefill">resort to JavaScript</a> or server-side workarounds to achieve a similar result.</p>


<p>This week we came across an interesting technique. In his article titled <a href="http://blog.netvlies.nl/design-interactie/retina-revolution/">Retina Revolution</a>, Daan Jobsis shared the following premise: when considering a jpeg image's file size, the level of compression makes more of a difference than its physical dimensions. In other words, given two identical images that are displayed at the same size on a website, one can be dramatically smaller than the other in file size if it is both highly compressed and dramatically larger in dimensions than it is displayed. </p>

<p>While we&#8217;re not sure it stands to replace the responsive image techniques currently in play, we are very excited about its potential for complementing them.  The article discusses the technique's "retina" implications, though in practice, the approach may have much more potential than differentiating high resolution "retina" (HD) and standard definition (SD) screen density alone.
</p>
					</div>
		
					<h3>An example comparison</h3>

<p>Let's look at an example. Both images below are displayed at 400 pixels width and 300 pixels height. </p>

<p>This first image is saved with those dimensions specifically (it's displayed at 100% size), with a typical 90% quality jpeg compression from Photoshop. It weighs 95kb.</p>

<p><a target="_blank" href="https://a248.e.akamai.net/camo.github.com/ddeccae870ea23f2480cb6ed59a60f49a8ec0f6f/687474703a2f2f73636f74746a65686c2e636f6d2f696d6774657374732f746573742d6e61746976652e6a7067"><img src="https://a248.e.akamai.net/camo.github.com/ddeccae870ea23f2480cb6ed59a60f49a8ec0f6f/687474703a2f2f73636f74746a65686c2e636f6d2f696d6774657374732f746573742d6e61746976652e6a7067" alt="Full-size sample image" width="400" height="300" style="max-width:100%;"></a></p>

<p>This second image, however, is actually scaled down by the browser. Its natural size is 1024x768px, but its compression was set to 0 (zero!) quality when saved from Photoshop. As a result, it weighs 44kb.</p>

<p><a target="_blank" href="https://a248.e.akamai.net/camo.github.com/7fc3bbf72304a558915cb5241586e0970876b714/687474703a2f2f73636f74746a65686c2e636f6d2f696d6774657374732f746573742d6c617267652e6a7067"><img src="https://a248.e.akamai.net/camo.github.com/7fc3bbf72304a558915cb5241586e0970876b714/687474703a2f2f73636f74746a65686c2e636f6d2f696d6774657374732f746573742d6c617267652e6a7067" alt="Lightweight, scaled-down sample image" width="400" height="300" style="max-width:100%;"></a></p>

<p>The images look roughly similar in quality, yet <strong>the second one is less than half the weight</strong>. Since that image is more than twice the resolution of the display size, it also looks sharp on retina screens.</p>

<h2>Implications</h2>

<p>Assuming there aren't drawbacks we've yet to consider (and there usually are), we're unsure how this affects our current thinking on responsive images.</p>

<p>For one thing, we're sure that this does not entirely replace the features of the proposed <code>picture</code> element. For example, picture's ability to deliver different image sources altogether means we can provide different crops of an image depending on the size, and a single image can't currently do that. In this context, it&#8217;s possible that we might use this technique to reduce the size of those sources.</p>

<p>Still, for images that are merely delivered at different sizes without any changes to the crop, this technique could present a much simpler solution.</p>

<p>Regardless, we think it's a pretty interesting twist. We'd love to hear your thoughts!</p>

<p class="note"><strong>Note:</strong> Daan has posted <a href="http://blog.netvlies.nl/design-interactie/retina-revolutie-follow-up/">a followup article</a> worth reading as well.</p>
<a href=""></a>
      ]]></content>
    </entry>

    <entry>
      <title>Grunticon: A Grunt.js plugin for managing and delivering sharp icons to all devices</title>
      <link rel="alternate" type="text/html" href="http://filamentgroup.com/lab/grunticon/" />
      <id>tag:,2012:/lab/6.148</id>
      <published>2012-08-31T16:52:00Z</published>
      <updated>2012-09-19T21:15:50Z</updated>
      <author>
            <name>Scott</name>
                  </author>

      <category term="announcements"
        scheme="http://filamentgroup.com/lab/tag/announcements/"
        label="announcements" />
      <category term="css"
        scheme="http://filamentgroup.com/lab/tag/css/"
        label="css" />
      <category term="icon design"
        scheme="http://filamentgroup.com/lab/tag/icon_design/"
        label="icon design" />
      <category term="progressive enhancement"
        scheme="http://filamentgroup.com/lab/tag/progressive_enhancement/"
        label="progressive enhancement" />
      <content type="html"><![CDATA[
       <p class="postData">Posted by Scott on 08/31/2012</p>

<dl class="topics">
					<dt>Topics:</dt>
					<dd><a href="http://filamentgroup.com/lab/tag/announcements/" rel="tag">announcements</a></dd><dd><a href="http://filamentgroup.com/lab/tag/css/" rel="tag">css</a></dd><dd><a href="http://filamentgroup.com/lab/tag/icon_design/" rel="tag">icon design</a></dd><dd><a href="http://filamentgroup.com/lab/tag/progressive_enhancement/" rel="tag">progressive enhancement</a></dd>
				</dl>
						<p class="note">Note: Grunticon was formerly named Unicon. The name was changed on September 19, 2012.</p>
 
<p>Creating sharp-looking icons and background images in our client work has always been more complicated than we want it to be, and with the growing popularity of higher-definition screens, it's only getting harder. CSS sprites have traditionally worked alright, but they can be a pain to manage, are often difficult to use in CSS layouts, and require generating and serving multiple fixed-pixel sizes. Icon fonts are a nice too, but they cause problems in some of the popular mobile environments we need to support, they aren't easy to manage for custom-designed icons, and they're limited to a single color.</p>

<p>What we really want is a way to efficiently manage and serve vector icons so they'll be crisp on displays of all resolutions, while delivering them in a way that is fast and non-blocking (for performance), and  with appropriate fallbacks for older devices. So we built one!</p>
					</div>
		
					<h2>
<a name="grunticon-a-mystical-css-icon-solution" class="anchor" href="#grunticon-a-mystical-css-icon-solution"><span class="mini-icon mini-icon-link"></span></a><a href="https://github.com/filamentgroup/grunticon">Grunticon: A mystical CSS icon solution</a>
</h2>

<pre><code>         /'
        //
    .  //
    |\//7
   /' " \     
  .   . .      
  | (    \     
  |  '._  '        
  /    \'-'
</code></pre>

<p><a href="https://github.com/filamentgroup/grunticon">Grunticon</a> is a <a href="https://github.com/cowboy/grunt/">Grunt.js</a> task that efficiently manages icons and background images for delivery to a variety of browsers and devices. It takes a folder of SVG files (typically, icons that you've drawn in an application like Adobe Illustrator), and outputs them to 3 CSS files containing CSS for the icons with class names that match the file that generated them. The CSS files contain the icons in the following formats:</p>

<ol>
<li>All of the icons inline in the CSS as vector SVG data URLs,</li>
<li>All of the icons inline in the CSS as PNG data URLs, </li>
<li>All of the icons referenced externally as PNG images, which are automatically generated from the source SVG and placed in a directory alongside the CSS files.</li>
</ol><p>The 3 files are necessary to support different browsers, and only one of the formats is intended to be served to a particular device, based on a browser's capabilities for SVG, data URLs. Basically, most modern browsers like Chrome, Firefox, Opera, Safari, and IE9+ can handle the SVG icons. IE8 and Android 2.x browsers can handle the PNG data URLs, but not SVG, so stylesheet #2 is intended for them. Lastly, browsers like IE7 and older, and those without JavaScript enabled, receive the fallback external image requests.</p>

<p>Figuring out which CSS file to serve based on these support divisions is complicated, so grunticon generates a small snippet of JavaScript and CSS that you can drop into your page, which asynchronously (*read: in a way that does not block the page from rendering immediately) loads the appropriate CSS file depending on a browser's capabilities. Lastly, grunticon also creates a preview HTML file so you can use the icons and their classnames as a reference during development.</p>

<h3>
<a name="output-samples" class="anchor" href="#output-samples"><span class="mini-icon mini-icon-link"></span></a>Output Samples</h3>

<p>You can see an example of the files that grunticon uses and creates by browsing the <a href="https://github.com/filamentgroup/grunticon/tree/master/example">Grunticon project's example folder</a>. The <code>source</code> directory contains the SVG icon source files, and the <code>output</code> folder contains the files that Grunticon creates.</p>

<p>You can also view a demo of the icon output, with the Grunticon loader in-place, here: <a href="http://filamentgroup.com/examples/grunticon-output/preview.html">Grunticon Output Preview</a></p>

<h2>
<a name="getting-started-with-grunticon" class="anchor" href="#getting-started-with-grunticon"><span class="mini-icon mini-icon-link"></span></a>Getting started with Grunticon</h2>

<p>Grunticon is a <a href="https://github.com/cowboy/grunt/">Grunt.js</a> task, and it also uses <a href="http://phantomjs.org/">PhantomJS</a>, a headless WebKit browser, for rendering the SVG files into various formats. Both of these are open-source command-line tools that can be installed following the instructions on the <a href="https://github.com/cowboy/grunt/">Grunt.js</a> documentation. Once you have Grunt installed, you can <a href="https://npmjs.org/package/grunt-grunticon">get Grunticon via NPM</a>, the Node.js package management utility. </p>

<p>Once installed and configured with Grunt.js, Grunticon will run alongside your other Grunt tasks whenever you run Grunt itself. Its configuration is fairly simple, requiring a <code>src</code> directory, containing your SVG files, and a <code>dest</code> directory that you'd like Grunticon to export the icons to. </p>

<p>For installation steps, <a href="https://github.com/filamentgroup/grunticon#readme">check out the Grunticon readme</a>.</p>

<h2>
<a name="future-plans-and-contributing" class="anchor" href="#future-plans-and-contributing"><span class="mini-icon mini-icon-link"></span></a>Future plans and contributing</h2>

<p>We chose to write Grunticon as a Grunt.js task because we've found Grunt to be incredibly helpful in our production process and wanted our icon tool to work alongside our other CSS and JavaScript tasks. That said, we understand that this dependency presents a significant barrier and learning curve to use the tool. In the coming weeks, we're going to consider how else the tool might be made useful, such as perhaps an application that would allow you to upload a zip file and download the same output that Grunticon currently creates.</p>

<p>If you have ideas or thoughts on the tool, the direction of the project, or would like to help contribute, just drop us a note here or in the <a href="https://github.com/filamentgroup/grunticon/issues">issue tracker</a>. Enjoy!</p>
<a href=""></a>
      ]]></content>
    </entry>

    <entry>
      <title>The Two HTML Specs</title>
      <link rel="alternate" type="text/html" href="http://filamentgroup.com/lab/thetwospecs/" />
      <id>tag:,2012:/lab/6.147</id>
      <published>2012-08-22T19:22:00Z</published>
      <updated>2012-08-22T21:07:46Z</updated>
      <author>
            <name>Mat</name>
                  </author>

      <category term="web standards"
        scheme="http://filamentgroup.com/lab/tag/web_standards/"
        label="web standards" />
      <content type="html"><![CDATA[
       <p class="postData">Posted by Mat on 08/22/2012</p>

<dl class="topics">
					<dt>Topics:</dt>
					<dd><a href="http://filamentgroup.com/lab/tag/web_standards/" rel="tag">web standards</a></dd>
				</dl>
						
					</div>
		
					<p>I recently posted some news on the <code>picture</code> proposal based on Florian Rivoal&#8217;s suggested compromise: namely, that the <code>picture</code> element is being <a href="http://www.w3.org/community/respimg/2012/08/04/picture-in-the-html5-spec/">considered for inclusion as a part of HTML5.</a></p>

<p>This is exciting news, but the details seem to be causing a bit of confusion: in particular, the difference between being considered a part of &#8220;HTML5&#8221; versus a part of &#8220;HTML.next.&#8221;</p>

<p>The short explanation is that there are two HTML specifications. One is versioned as &#8220;HTML5&#8221;/&#8220;HTML.next&#8221; and managed by the W3C (specifically, the W3C&#8217;s HTML Working Group) and the other is the non-versioned &#8220;living standard&#8221; specification, managed by the WHATWG.</p>

<article>
<blockquote>
<p>&#8230;there are two specs now, the WHATWG HTML spec and the W3C HTML5 spec, and they are independent.</p>
<address>Ian Hickson</address>
<cite><a href="http://krijnhoetmer.nl/irc-logs/whatwg/20120720#l-1108">#WHATWG IRC Channel</a></cite>
</blockquote>
</article>

<p>At face value, this seems like a potentially terrifying development in the world of web standards. With two disparate specs, we would be forever left wondering which standard is <em>the</em> standard. If two browsers were to implement the same feature per differing specs, we could be facing a scenario hauntingly similar to the &#8220;Netscape vs. IE&#8221; situation of yesteryear.</p>

<p>Fortunately, the two teams have assured me that (at least, on paper) this isn&#8217;t the case. They've stated that they plan to work on HTML in parallel and coordinate their efforts. The WHATWG will continue to work on adding new features and improving aspects of the HTML &#8220;living standard.&#8221;  In the meantime, the W3C will work on nailing down a stable and thoroughly-tested snapshot of the HTML living standard&#8212;including their own contributions&#8212;as &#8220;HTML5.&#8221; Newer and less stable features, elements, attributes, and APIs will be pushed to &#8220;HTML.next&#8221;, another upcoming snapshot of the living standard.</p>

<p>The HTML WG has chosen to help the Responsive Images Community Group publish a final draft specification of the markup codified in an <a href="http://www.w3.org/community/respimg/wiki/Picture_Element_Proposal">early draft spec</a>, and <a href="http://www.w3.org/community/respimg/2012/06/18/florians-compromise/">described in this news post</a>. Given the amount of work that the developer community and browser representatives have already put into the <code>picture</code> markup pattern it&#8217;s likely that there won&#8217;t be any major barriers to a formal specification, and as such the HTML WG is considering the <code>picture</code> proposal as a part of the current HTML snapshot: HTML5. All this means is that <code>picture</code> would be likely to receive feedback and potentially&#8212;though not necessarily&#8212;native implementations more quickly than it would if it were moved to &#8220;HTML.next.&#8221;</p>

<p>However, the WHATWG is still in favor of the <code>srcset</code> approach, despite the fact that it only covers a use case equivalent to pixel-based <code>max-width</code> and <code>max-height</code> media queries and resolution switching, at this time. Ian Hickson in particular feels this approach will be sufficient for authors both today and in the future, due to a <a href="http://logbot.glob.com.au/?c=freenode%23whatwg&s=7+Aug+2012&e=7+Aug+2012#c711835">disagreement in the value of using <code>em</code>s in media queries</a>, which is covered in-depth on the <a href="http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/">CloudFour blog</a>.</p>

<p>It&#8217;s unclear what the conflicting standpoints of the WHATWG and the W3C will mean for an &#8220;adaptive images&#8221; element. Where the WHATWG is comprised entirely of browser representatives, they&#8217;ve stated outright that &#8220;their&#8221; spec is the one most likely to see real-world implementations right away. In the meantime, the <a href="http://www.w3.org/community/respimg/">RICG</a> is working with multiple vendors on native implementations of the <code>picture</code> markup pattern. In the end, it may just be that the first native implementation takes it&#8212;or that this is where we authors finally have our say in the standards process, eschewing one approach in favor of the other.</p>

<p>In either case, the upcoming discussion will benefit from thoughtful and informed participation by the developer community. We encourage all to participate in the discussion, review our progress, and weigh in on the direction the specification takes.</p>
<a href=""></a>
      ]]></content>
    </entry>

    <entry>
      <title>Responsive Carousel Project: Now Open Source</title>
      <link rel="alternate" type="text/html" href="http://filamentgroup.com/lab/responsive_carousel/" />
      <id>tag:,2012:/lab/6.145</id>
      <published>2012-08-09T17:33:00Z</published>
      <updated>2012-08-17T16:00:46Z</updated>
      <author>
            <name>Scott</name>
                  </author>

      <category term="javascript"
        scheme="http://filamentgroup.com/lab/tag/javascript/"
        label="javascript" />
      <category term="jQuery"
        scheme="http://filamentgroup.com/lab/tag/jquery/"
        label="jQuery" />
      <category term="mobile"
        scheme="http://filamentgroup.com/lab/tag/mobile/"
        label="mobile" />
      <category term="progressive enhancement"
        scheme="http://filamentgroup.com/lab/tag/progressive_enhancement/"
        label="progressive enhancement" />
      <content type="html"><![CDATA[
       <p class="postData">Posted by Scott on 08/09/2012</p>

<dl class="topics">
					<dt>Topics:</dt>
					<dd><a href="http://filamentgroup.com/lab/tag/javascript/" rel="tag">javascript</a></dd><dd><a href="http://filamentgroup.com/lab/tag/jquery/" rel="tag">jQuery</a></dd><dd><a href="http://filamentgroup.com/lab/tag/mobile/" rel="tag">mobile</a></dd><dd><a href="http://filamentgroup.com/lab/tag/progressive_enhancement/" rel="tag">progressive enhancement</a></dd>
				</dl>
						<p>In our responsive client work, we frequently find ourselves in need of a carousel component that is lightweight, fluid in layout, usable with different input modes (mouse, keyboard, touch), and extensible to the particulars of each implementation. We've found that most third-party carousels available online fall short of these requirements in one way or another, so we built our own, and recently made it public for others to use as well.</p>
<p>The Responsive Carousel project is <a href="https://github.com/filamentgroup/responsive-carousel/#readme">available on Github</a>. It&#8217;s dependent on jQuery to work. But it&#8217;s is also compatible with &#8220;Shoestring,&#8221; a minimalist DOM framework we&#8217;ll be releasing soon.</p>
					</div>
		
					<h2 id="how-to">How-to</h2>
<p>To use the responsive carousel, just reference the following required CSS and JS files, and add a class of <code>carousel</code> to any element in your page that contains a series of sibling elements:</p>

<pre class="sourceCode html"><code class="sourceCode html"><span class="kw">&lt;script</span><span class="ot"> src=</span><span class="st">&quot;jquery.js&quot;</span><span class="kw">&gt;&lt;/script&gt;</span>
<span class="kw">&lt;script</span><span class="ot"> src=</span><span class="st">&quot;dist/responsive-carousel.min.js&quot;</span><span class="kw">&gt;&lt;/script&gt;</span>
<span class="kw">&lt;link</span><span class="ot"> href=</span><span class="st">&quot;src/responsive-carousel.css&quot;</span><span class="ot"> rel=</span><span class="st">&quot;stylesheet&quot;</span><span class="kw">&gt;</span>

<span class="kw">&lt;div</span><span class="ot"> class=</span><span class="st">&quot;carousel&quot;</span><span class="kw">&gt;</span>
    <span class="kw">&lt;div</span><span class="kw">&gt;</span>
        <span class="co">&lt;!-- carousel item content here --&gt;</span>
    <span class="kw">&lt;/div&gt;</span>
    <span class="kw">&lt;div</span><span class="kw">&gt;</span>
        <span class="co">&lt;!-- carousel item content here --&gt;</span>
    <span class="kw">&lt;/div&gt;</span>
<span class="kw">&lt;/div&gt;</span></code></pre>
<p>With the default build, slides switch immediately with "Prev" and "Next" buttons. We've created several slide transition options (among other extensions&mdash;see more below) like the slide/drag transition, which you can apply by adding a data attribute and including some additional CSS.</p>

<pre class="sourceCode html"><code class="sourceCode html"><span class="kw">&lt;script</span><span class="ot"> src=</span><span class="st">&quot;jquery.js&quot;</span><span class="kw">&gt;&lt;/script&gt;</span>
<span class="kw">&lt;script</span><span class="ot"> src=</span><span class="st">&quot;dist/responsive-carousel.min.js&quot;</span><span class="kw">&gt;&lt;/script&gt;</span>
<span class="kw">&lt;link</span><span class="ot"> href=</span><span class="st">&quot;src/responsive-carousel.css&quot;</span><span class="ot"> rel=</span><span class="st">&quot;stylesheet&quot;</span><span class="kw">&gt;</span>
<span class="kw">&lt;link</span><span class="ot"> href=</span><span class="st">&quot;src/responsive-carousel.slide.css&quot;</span><span class="ot"> rel=</span><span class="st">&quot;stylesheet&quot;</span><span class="kw">&gt;</span>

<span class="kw">&lt;div</span><span class="ot"> class=</span><span class="st">&quot;carousel&quot; data-transition=</span><span class="st">&quot;slide&quot;</span><span class="kw">&gt;</span>
  <span class="kw">&lt;div</span><span class="kw">&gt;</span>
        <span class="co">&lt;!-- carousel item content here --&gt;</span>
    <span class="kw">&lt;/div&gt;</span>
    <span class="kw">&lt;div</span><span class="kw">&gt;</span>
        <span class="co">&lt;!-- carousel item content here --&gt;</span>
    <span class="kw">&lt;/div&gt;</span>
<span class="kw">&lt;/div&gt;</span></code></pre>
<h2 id="extensions">Extensions &amp; Demos</h2>
<p>There are a range of transition, interaction and display extensions in the <code>src</code> folder, such as a <a href="http://filamentgroup.github.com/responsive-carousel/test/functional/fade.html">fade</a> transition, touch-draggable <a href="http://filamentgroup.github.com/responsive-carousel/test/functional/slide.html">slide</a> and <a href="http://filamentgroup.github.com/responsive-carousel/test/functional/flip-auto.html">flip</a> transitions, <a href="http://filamentgroup.github.com/responsive-carousel/test/functional/fade-auto.html">autoplay</a>, <a href="http://filamentgroup.github.com/responsive-carousel/test/functional/slide-keybd.html">keyboard handling</a>, <a href="http://filamentgroup.github.com/responsive-carousel/test/functional/pagination.html">pagination</a>, and even an <a href="http://filamentgroup.github.com/responsive-carousel/test/functional/responsive-containers.html">extension that automatically adjusts the number of visible elements per slide, depending on the viewport dimensions</a>.</p>
<p>If you&#8217;d like to create a build that includes certain extensions, your can add them to the JS files listed under <code>concat</code> in the <code>/grunt.js</code> file, and run <code>grunt</code> from a command line (you&#8217;ll need Grunt and Node.js installed on your machine for this to work). Be sure to include the relevant CSS files to match the JS features you choose.</p>
<p>Check out the <a href="http://filamentgroup.github.com/responsive-carousel/test/functional/">test/functional/</a> directory for demos of many of the extensions listed above, also previewed in the iframe below:</p>
<iframe src="http://filamentgroup.github.com/responsive-carousel/test/functional/" style="width: 100%; height: 45em; border: 1px dotted #aaa;"></iframe>
<h2 id="additional-information">Additional information</h2>
<p>We will continue to update the <a href="https://github.com/filamentgroup/responsive-carousel/#readme">project readme</a> with information about how to use the responsive carousel. Please refer there for current information.</p>
<h2 id="issues-ideas-and-contributions">Issues, Ideas, and Contributions</h2>
<p>If you find a bug or have a fix or enhancement, please use the <a href="https://github.com/filamentgroup/responsive-carousel/issues">issue tracker</a> or send us a pull request.</p>
<a href=""></a>
      ]]></content>
    </entry>

    <entry>
      <title>On ems and rems</title>
      <link rel="alternate" type="text/html" href="http://filamentgroup.com/lab/on_ems_and_rems/" />
      <id>tag:,2012:/lab/6.144</id>
      <published>2012-07-19T15:47:00Z</published>
      <updated>2012-07-21T03:45:03Z</updated>
      <author>
            <name>Scott</name>
                  </author>

      <category term="css"
        scheme="http://filamentgroup.com/lab/tag/css/"
        label="css" />
      <category term="responsive design"
        scheme="http://filamentgroup.com/lab/tag/responsive_design/"
        label="responsive design" />
      <content type="html"><![CDATA[
       <p class="postData">Posted by Scott on 07/19/2012</p>

<dl class="topics">
					<dt>Topics:</dt>
					<dd><a href="http://filamentgroup.com/lab/tag/css/" rel="tag">css</a></dd><dd><a href="http://filamentgroup.com/lab/tag/responsive_design/" rel="tag">responsive design</a></dd>
				</dl>
						<p>In our most recent post, <em><a href="http://filamentgroup.com/lab/how_we_learned_to_leave_body_font_size_alone/">How we learned to leave default font-size alone and embrace the <code>em</code></a></em>, we noted a few reasons why we&#8217;ve recently stopped setting a <code>body</code> <code>font-size</code> in our CSS. Several readers commented that they now prefer using <code>rem</code> units instead of <code>em</code>s, and as a result, they don&#8217;t run into the issues we observed. We agree that <code>rem</code>s are fantastic, but thought we should note that <code>rem</code>s and <code>em</code>s serve different purposes and need not be mutually exclusive; both can be very useful in the same CSS layout, depending on what you&#8217;re trying to do!</p>
					</div>
		
					<p>Perhaps the most attractive aspect of <code>rem</code>s is that they are always relative to the root element's (<code>&lt;html&gt;</code>) <code>font-size</code> regardless of the context in which they are used in an HTML document. In other words, <code>1rem</code> always equals the same thing (by default, usually about <code>16px</code>), and that consistency does make <code>rem</code>s a lot easier to work with than <code>em</code> units, which are relative to the <code>font-size</code> of the parent of the element you're styling. (If you're new to <code>rem</code> units, we'd recommend checking out <a href="http://snook.ca/archives/html_and_css/font-size-with-rem">Jonathan Snook's great article on the topic</a>.)</p>

<p>But that same benefit of <code>rem</code>s also means that they can be less helpful when designing proportional whitespace, such as padding and margins that surround the typography in a fluid layout. This is where <code>em</code> units shine. Take for example, a block of content that contains a heading and a paragraph. The amount of spacing that feels comfortable between the heading and the paragraph (and the space between them and adjacent pieces of content) will often change depending on the size of the text. Using <code>em</code> units for the margins and padding in cases like this mean the spacing will automatically adjust in proportion to the <code>font-size</code>, regardless of what it may be.  If used in this same situation, <code>rem</code>s would require manual adjustment. <a href="http://jsbin.com/ehoben">This jsbin example</a> attempts to demonstrate this difference simply, but it becomes more obvious when designing complex, gridded layouts.</p>

<p><code>em</code>s come with another benefit: when components are set entirely in <code>em</code>s, they scale in unison depending on the <code>font-size</code> of their containing element. This can be very powerful, particularly when reusing the same components in different parts of a layout, where it might make sense for a component to be larger or smaller as a whole.</p>

<p>Meanwhile, <code>rem</code>s have another potential downside. If you care to support Internet Explorer 8 and older, or any version of Opera Mini, you&#8217;ll need to provide a fallback <code>px</code>- or <code>em</code>-based number alongside every use of <code>rem</code>s, which makes our jobs a little harder, while increasing the code weight that we&#8217;re delivering to the user (however minimally).</p>

<p>To sum things up, <code>rem</code>s are a great emerging technology. Knowing when it&#8217;s a good idea to use them, and when it&#8217;s not, is something we&#8217;re still considering ourselves.</p>
<a href=""></a>
      ]]></content>
    </entry>

    <entry>
      <title>How we learned to leave default font&#45;size alone and embrace the em</title>
      <link rel="alternate" type="text/html" href="http://filamentgroup.com/lab/how_we_learned_to_leave_body_font_size_alone/" />
      <id>tag:,2012:/lab/6.143</id>
      <published>2012-07-18T21:52:00Z</published>
      <updated>2012-07-18T23:13:46Z</updated>
      <author>
            <name>Scott</name>
                  </author>

      <category term="accessibility"
        scheme="http://filamentgroup.com/lab/tag/accessibility/"
        label="accessibility" />
      <category term="css"
        scheme="http://filamentgroup.com/lab/tag/css/"
        label="css" />
      <category term="responsive design"
        scheme="http://filamentgroup.com/lab/tag/responsive_design/"
        label="responsive design" />
      <content type="html"><![CDATA[
       <p class="postData">Posted by Scott, Mat, Zach, and Patty on 07/18/2012</p>

<dl class="topics">
					<dt>Topics:</dt>
					<dd><a href="http://filamentgroup.com/lab/tag/accessibility/" rel="tag">accessibility</a></dd><dd><a href="http://filamentgroup.com/lab/tag/css/" rel="tag">css</a></dd><dd><a href="http://filamentgroup.com/lab/tag/responsive_design/" rel="tag">responsive design</a></dd>
				</dl>
						<p>Building with <code>em</code> units in CSS brings benefits in flexibility to users and developers alike, but working with <code>em</code>s can be tedious for a number of reasons. Most famously, the value of <code>1em</code> only vaguely correlates to pixel-based design; the inconvenience of translating fixed design comps into flexible CSS units has long driven web designers to declare a global <code>font-size</code> to make that math a bit easier to manage. But using contemporary responsive design principles is convincing us to leave global <code>font-size</code> alone and embrace the standard <code>em</code>.
</p>
					</div>
		
					<p>Perhaps the most popular global <code>font-size</code> workaround was introduced in Richard Rutter's brilliant 2004 article, <a href="http://clagnut.com/blog/348/">"How to size text using ems,"</a> which revealed that by setting a <code>body</code> <code>font-size</code> of 
<code>62.5%</code>, we change the default value of <code>1em</code> to equal 10 pixels. This of course makes the conversion of pixels to ems dramatically easier. Ever since that article was released, we at Filament Group would typically start our CSS files with that rule, and happily carry on in our developer-convenient way. </p>

<p>But in the recent past, as we began building Responsive layouts&mdash;particularly layouts that use flexible 
<a href="http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/"><code>em</code>-based media query</a>  breakpoints&mdash;we've encountered several reasons that the practice of setting the <code>body</code> <code>font-size</code> is no longer such a good idea in our own work. We've observed that others have seemingly come to this realization as well, but hadn't seen anyone document why they made the change, so here are the reasons we've found:
</p>

<ul>

<li>The value of <code>1em</code>, when used in a CSS3 Media Query such as <code>@media (min-width: 20em)</code>, is unaffected by the <code>font-size</code> of the <code>body</code> element in most browsers. This means that if we change the <code>font-size</code> of the <code>body</code> to something other than 100%, we will need to calculate <code>em</code> values differently when they're used in a media query than in a CSS property value. This creates inconsistency across a CSS file that is difficult to maintain and document. <em>(We recall that Opera Mobile or Mini actually behaved differently in this aspect, compounding the issue further, but we couldn't reproduce in the latest versions of the browsers.)</em>
</li>

<li>A default font-size of 10px is illegibly small for text, so if we use a <code>62.5%</code> base <code>font-size</code>, we have to specifically set the <code>font-size</code> of every element that appears on our site to make it readable. Alternatively, if we leave the <code>body</code> <code>font-size</code> at 100%, we can allow elements to display in their natural size determined by the browser's default stylesheet. This makes for lighter CSS and more flexibility in the markup we choose to use.
</li>

<li>Lastly, as we move into the browser earlier and earlier in our design processes, we're finding that the very idea of an <code>em</code> value relating to pixels is becoming less relevant. Our design decisions are now more commonly informed by the context in which a component lives in the page, and how it adapts fluidly and proportionally within that environment, regardless of its pixel-based scale.
</li>

</ul>

<p>
So for those reasons, we're now tending to leave the <code>body</code> <code>font-size</code> alone, and we'd recommend other developers do the same.
</p>

<p>
Observant readers may notice that, ironically, at the time of writing this very website is still built using a <code>body</code> <code>font-size</code> of <code>62.5%</code>. We're  in the process of redesigning this site, and while we haven't gotten around to changing that part yet, the difficulty in creating our new <code>em</code>-based responsive layout with that default <code>font-size</code> in play was enough to prompt us to write this post!
</p>

<p>
Thoughts? We'd love to hear your ideas below.
</p>
<a href=""></a>
      ]]></content>
    </entry>

    <entry>
      <title>SouthStreet: a workflow for Progressive Enhancement, presented at An Event Apart Boston</title>
      <link rel="alternate" type="text/html" href="http://filamentgroup.com/lab/southstreet_event_apart/" />
      <id>tag:,2012:/lab/6.142</id>
      <published>2012-06-20T16:51:00Z</published>
      <updated>2012-06-20T21:52:04Z</updated>
      <author>
            <name>Scott</name>
                  </author>

      <category term="accessibility"
        scheme="http://filamentgroup.com/lab/tag/accessibility/"
        label="accessibility" />
      <category term="css"
        scheme="http://filamentgroup.com/lab/tag/css/"
        label="css" />
      <category term="javascript"
        scheme="http://filamentgroup.com/lab/tag/javascript/"
        label="javascript" />
      <category term="presentations"
        scheme="http://filamentgroup.com/lab/tag/presentations/"
        label="presentations" />
      <category term="progressive enhancement"
        scheme="http://filamentgroup.com/lab/tag/progressive_enhancement/"
        label="progressive enhancement" />
      <category term="responsive design"
        scheme="http://filamentgroup.com/lab/tag/responsive_design/"
        label="responsive design" />
      <content type="html"><![CDATA[
       <p class="postData">Posted by FG on 06/20/2012</p>

<dl class="topics">
					<dt>Topics:</dt>
					<dd><a href="http://filamentgroup.com/lab/tag/accessibility/" rel="tag">accessibility</a></dd><dd><a href="http://filamentgroup.com/lab/tag/css/" rel="tag">css</a></dd><dd><a href="http://filamentgroup.com/lab/tag/javascript/" rel="tag">javascript</a></dd><dd><a href="http://filamentgroup.com/lab/tag/presentations/" rel="tag">presentations</a></dd><dd><a href="http://filamentgroup.com/lab/tag/progressive_enhancement/" rel="tag">progressive enhancement</a></dd><dd><a href="http://filamentgroup.com/lab/tag/responsive_design/" rel="tag">responsive design</a></dd>
				</dl>
						<p>Yesterday at <a href="http://aneventapart.com/2012/boston/">An Event Apart conference in Boston</a>, Filament Group's Scott Jehl presented <em>Interacting Responsibly (and Responsively!)</em>, which included an overview of <a href="https://github.com/filamentgroup/southstreet">SouthStreet</a>, a new project that assembles the tools we typically use to develop cross-device, accessible sites and applications. Luke Wroblewski posted <a href="http://www.lukew.com/ff/entry.asp?1565">very thorough notes from the session</a> on his website.</p>

<p><img src="/images/aeabos-screencap.jpg" alt="Scott Jehl presenting at An Event Apart Boston 2012"></p>


					</div>
		
					<h2>About SouthStreet</h2>

<p>The projects in SouthStreet focus in two key themes to help reduce overhead and improve performance in responsive designs: </p>
<ul>
<li>better qualifying the application of enhancements so they're delivered only when and where they'll be useful, and</li>
<li>improving our delivery mechanisms to ensure that we deliver critical content and functionality as quickly and efficiently as possible, and offer secondary content with best impact and least risk.</li>
</ul>

<p>Specifically, the projects are a suite of interrelated tools intended to optimize delivery of HTML, CSS, JavaScript, and images, so that devices are delivered the least amount of code possible while maintaining broad accessibility and support.</p>


<p>You can find an overview of the SouthStreet project at <a href="https://github.com/filamentgroup/southstreet">its home on Github</a>. There, you'll also find a list of related projects that we build that may be useful in conjunction with SouthStreet projects.</p>

<p>And SouthStreet is a work in progress. We welcome comments, posts to the issue tracker, questions and contributions. Let us know what you think, and help us make it better!</p>


<h2><a href="https://github.com/filamentgroup/southstreet" class="book-site">SouthStreet Project</a></h2>
<a href=""></a>
      ]]></content>
    </entry>

    <entry>
      <title>A different approach to qualifying CSS position: fixed</title>
      <link rel="alternate" type="text/html" href="http://filamentgroup.com/lab/a_different_approach_to_qualifying_css_position_fixed/" />
      <id>tag:,2012:/lab/6.141</id>
      <published>2012-05-22T15:22:00Z</published>
      <updated>2012-05-22T18:32:05Z</updated>
      <author>
            <name>Scott</name>
                  </author>

      <category term="accessibility"
        scheme="http://filamentgroup.com/lab/tag/accessibility/"
        label="accessibility" />
      <category term="css"
        scheme="http://filamentgroup.com/lab/tag/css/"
        label="css" />
      <category term="javascript"
        scheme="http://filamentgroup.com/lab/tag/javascript/"
        label="javascript" />
      <category term="mobile"
        scheme="http://filamentgroup.com/lab/tag/mobile/"
        label="mobile" />
      <category term="usability"
        scheme="http://filamentgroup.com/lab/tag/usability/"
        label="usability" />
      <content type="html"><![CDATA[
       <p class="postData">Posted by Scott on 05/22/2012</p>

<dl class="topics">
					<dt>Topics:</dt>
					<dd><a href="http://filamentgroup.com/lab/tag/accessibility/" rel="tag">accessibility</a></dd><dd><a href="http://filamentgroup.com/lab/tag/css/" rel="tag">css</a></dd><dd><a href="http://filamentgroup.com/lab/tag/javascript/" rel="tag">javascript</a></dd><dd><a href="http://filamentgroup.com/lab/tag/mobile/" rel="tag">mobile</a></dd><dd><a href="http://filamentgroup.com/lab/tag/usability/" rel="tag">usability</a></dd>
				</dl>
						<p>CSS fixed-positioning <a href="http://bradfrostweb.com/blog/mobile/fixed-position/">varies widely in browser support</a>, and it's quite difficult to test. Unfortunately, unlike many CSS features, when fixed-positioning fails, page content can end up overlapping in ways that inhibits accessibility&mdash;never a good thing. Still, fixed positioning is a very desirable feature, particularly when designing for mobile devices, so we're continually exploring better and more practical ways to approach it. Today we're making public a new approach, <a href="https://github.com/filamentgroup/fixed-fixed">Fixed-fixed</a>, for qualifying fixed-positioning that builds on what we've learned.</p>
					</div>
		
					<h2>How it works, in brief</h2>

<p>In our extensive testing for jQuery Mobile and our client work, we discovered a number of complexities in testing fixed-positioning:</p>

<p>First, there are a few known browsers that report false results when running the included feature test (Some Android 2.x builds, and some older versions of Firefox Mobile and Opera Mini and Mobile for example, have reported false positives in our testing). A false negative is generally safer than a false positive, and we would never want to opt a non-supporting browser into this feature. These browser versions are no longer in development, but they are popular, so we know we need to find a solution that will make sure we don't deliver a broken experience.</p>

<p>Second, we noted an up-front test requires programmatically scrolling the browser window during page load, which we found could sometimes interfere with other scripts running on the page, and generally make for a less-smooth loading sequence. </p>

<p>For these reasons, our approach differs from a typical CSS feature test. Rather than testing immediately, the script waits for the user to scroll, as a physical scroll is required for checking if fixed-positioned elements retain their position properly. Prior to scroll, the script assumes fixed positioning works, adding a class of fixed-supported to the HTML element that can be used to qualify any  <code>position:fixed</code> CSS rules. After the scroll, if fixed positioning is deemed unsupported through our feature test, the class is removed, allowing any fixed-positioned elements to safely degrade to a fallback layout that can be specified through rules that do not use that qualifier selector.</p>

<p class="note">A TIP OF THE HAT: The idea behind the feature test portion of this approach was inspired by Kangax's <a href="http://kangax.github.com/cft/#IS_POSITION_FIXED_SUPPORTED">Position Fixed Test</a>.</p>

<h2>Usage</h2>

<p>To use this technique, just include <a href="https://github.com/filamentgroup/fixed-fixed/blob/master/fixedfixed.js">the JavaScript from the project repo</a> and qualify any <code>position:fixed</code> usage in your stylesheet with a <code>.fixed-supported</code> parent class selector, like so:</p>

<pre><code>.fixed-supported header { position: fixed; }
</code></pre>

<p>That class will be present on the HTML element in CSS fixed-supporting browsers. You can apply an initial/degraded layout in browsers that don't support fixed positioning properly by writing selectors that do not use the <code>.fixed-supported</code> selector.</p>

<p>For an example, you can view and test <a href="http://filamentgroup.github.com/fixed-fixed/">the project example page</a> .</p>

<h2>Hey, help us out!</h2>

<p>We're releasing this idea early-on in development because we're looking for feedback on the concept as well as the code, and we're also very eager to get some additional testing contributions. There may well be errors to address, and edge cases we've yet to find. Please test it out, let us know if you have ideas for improvements, and <a href="https://github.com/filamentgroup/fixed-fixed/issues">file issues in the tracker</a> if you find any. With any luck, we hope this will grow into a reliable tool for use in our future projects, and yours.</p>
<a href=""></a>
      ]]></content>
    </entry>

    <entry>
      <title>Device &amp;amp; browser quirks: tracking the weirdness</title>
      <link rel="alternate" type="text/html" href="http://filamentgroup.com/lab/tracking_the_weirdness/" />
      <id>tag:,2012:/lab/6.139</id>
      <published>2012-03-29T07:15:00Z</published>
      <updated>2012-05-15T15:26:15Z</updated>
      <author>
            <name>Scott</name>
                  </author>

      <category term="css"
        scheme="http://filamentgroup.com/lab/tag/css/"
        label="css" />
      <category term="javascript"
        scheme="http://filamentgroup.com/lab/tag/javascript/"
        label="javascript" />
      <category term="mobile"
        scheme="http://filamentgroup.com/lab/tag/mobile/"
        label="mobile" />
      <content type="html"><![CDATA[
       <p class="postData">Posted by Scott on 03/29/2012</p>

<dl class="topics">
					<dt>Topics:</dt>
					<dd><a href="http://filamentgroup.com/lab/tag/css/" rel="tag">css</a></dd><dd><a href="http://filamentgroup.com/lab/tag/javascript/" rel="tag">javascript</a></dd><dd><a href="http://filamentgroup.com/lab/tag/mobile/" rel="tag">mobile</a></dd>
				</dl>
						<p>We do a lot of browser testing, and we often see ourselves and others running into buggy behavior without knowing if an issue is already known, or perhaps if a workaround is available. Problem is, there's no good place (that we know of) to easily search for known HTML, CSS, and JS quirks and bugs in browsers &#8211; particularly issues that occur in mobile devices, or require more explanation than a simple, "feature xyz isn't supported in browser xyz."</p> 

<p> The <a href="https://github.com/scottjehl/Device-Bugs/issues">Device Bugs project on Github</a> is an attempt to address this problem. It's an open, generic bug tracker where we can keep track of the browser issues we commonly face, and make note of various related information and workarounds. While it'd be silly to suggest that it could ever be comprehensive, we think there's a good chance for it to become a useful resource &#8211; especially with the help of the broader community. As such, we've begun filing some of our favorite quirks, and we hope you will too!</p>

<p>While Device Bugs is a normal Github project, it is only meant to be used via its issue tracker. You'll need a Github account to start adding issues, but you can browse and search them without an account. Please feel free to add any legitimate non-framework-specific browser issues to the tracker &#8211; desktop browser issues are indeed helpful as well. If an issue deals with a browser in active development, please remember to file the issue with that browser's tracker as well (but please still file it at Device Bugs too). The <a href="http://movethewebforward.org/">Move the Web Forward</a> site gives more information on where popular browsers' trackers are found; some of which are not public, making a resource like Device Bugs all the more useful.</p>

<p>Lastly, the Device Bugs project contains an <a href="https://github.com/scottjehl/Device-Bugs/blob/master/ISSUE%20TEMPLATE">issue template</a> to make issue filing faster. If you don't want to use it, that's fine, but including any of the information suggested in the template would be very helpful to all.</p>

<p>Happy filing!</p>
					</div>
		
					
<a href=""></a>
      ]]></content>
    </entry>

    <entry>
      <title>An Ajax&#45;Include Pattern for Modular Content</title>
      <link rel="alternate" type="text/html" href="http://filamentgroup.com/lab/ajax_includes_modular_content/" />
      <id>tag:,2012:/lab/6.140</id>
      <published>2012-03-28T14:22:00Z</published>
      <updated>2012-04-06T10:41:14Z</updated>
      <author>
            <name>Scott</name>
                  </author>

      <category term="ajax"
        scheme="http://filamentgroup.com/lab/tag/ajax/"
        label="ajax" />
      <category term="javascript"
        scheme="http://filamentgroup.com/lab/tag/javascript/"
        label="javascript" />
      <category term="jQuery"
        scheme="http://filamentgroup.com/lab/tag/jquery/"
        label="jQuery" />
      <category term="mobile"
        scheme="http://filamentgroup.com/lab/tag/mobile/"
        label="mobile" />
      <category term="php"
        scheme="http://filamentgroup.com/lab/tag/php/"
        label="php" />
      <category term="progressive enhancement"
        scheme="http://filamentgroup.com/lab/tag/progressive_enhancement/"
        label="progressive enhancement" />
      <content type="html"><![CDATA[
       <p class="postData">Posted by Scott on 03/28/2012</p>

<dl class="topics">
					<dt>Topics:</dt>
					<dd><a href="http://filamentgroup.com/lab/tag/ajax/" rel="tag">ajax</a></dd><dd><a href="http://filamentgroup.com/lab/tag/javascript/" rel="tag">javascript</a></dd><dd><a href="http://filamentgroup.com/lab/tag/jquery/" rel="tag">jQuery</a></dd><dd><a href="http://filamentgroup.com/lab/tag/mobile/" rel="tag">mobile</a></dd><dd><a href="http://filamentgroup.com/lab/tag/php/" rel="tag">php</a></dd><dd><a href="http://filamentgroup.com/lab/tag/progressive_enhancement/" rel="tag">progressive enhancement</a></dd>
				</dl>
						<p>While developing the front-end of the <a href="http://bostonglobe.com">BostonGlobe.com</a> site last fall, one of the toughest challenges we faced was delivering roughly the same content to all devices (and connection speeds) while ensuring the most important content on a page was usable as soon as possible. We approached this challenge with a variety of techniques, such as only loading the most essential JavaScript up-front (weighing roughly 4-6kb tops) and lazy loading the rest, dynamically injecting advertisements, and loading "nice-to-have" content via JavaScript&mdash;all after the initial content was delivered and usable. </p>
					</div>
		
					<h2>Bullet-proofing our Content Includes</h2>

<p>The idea of conditionally or lazy loading content is not a new one; indeed, <a href="http://adactio.com/articles/5043/">Jeremy Keith covered a similar pattern last year</a>, and many sites already employ similar techniques. These techniques help a great deal when optimizing a page, but&mdash;particularly when dealing with conditionally loading HTML content&mdash;we need to be careful to use them in ways that do not introduce barriers to universal accessibility.</p>

<p>In order to lazy load nonessential content on BostonGlobe.com without introducing access barriers, we developed a simple, markup-driven &#8220;Ajax-include&#8221; pattern that enhanced certain links on a page by including a fragment of content from a URL related to their linked resource. For example, the header of BostonGlobe.com contained a link to the Weather section of the website, and that same link is also used as a marker for including a fragment of content from that section that is used to create a weather widget.</p>

<h3>Initial State:</h3>
<div><img src="http://filamentgroup.com/images/bglobe-weather-initial.png" style="max-width:100%" alt="initial Boston Globe weather widget"></div>

<h3>Expanded, Ajax-enhanced state:</h3>
<p><img src="http://filamentgroup.com/images/bglobe-weather-full.png" style="max-width:100%" alt="expanded Boston Globe weather widget"></p>

<p>With this pattern in place, we found a nice balance between loading performance and accessibility: the content begins lightweight, and accessible without Javascript, and it is enhanced into a richer experience on capable devices&mdash;all without holding up the initial page load.</p>

<p>From a technical standpoint, the approach was simple: any element in the page could reference an external HTML fragment by URL through a small set of predefined HTML5 <code>data-</code> attributes; our JavaScript would simply loop through those elements, Ajax-request their referenced content, and inject it into the page (either before, after, or in place of the referencing element, depending on which <code>data-</code> attribute was in play). </p>

<p>Pseudo-markup for the particular scenario above, which the JS would enhance by including the referenced fragment:</p>
<pre><code>&lt;a href=&rdquo;fullpage.html&rdquo; data-include=&rdquo;fullpage-fragment.html&rdquo;&gt;Full Page&lt;/a&gt;</code></pre>

<p>The technique worked well, and we began using it in several places to lighten the Globe&#8217;s initial load. Around that time, we also tweeted a <a href="https://gist.github.com/983328">gist snippet</a> of the technique as it stood (crediting <a href="http://scottgonzalez.com/">Scott Gonzales</a> for some of the initial thinking behind the idea).</p>

<h2>A tipping point</h2>

<p>Unfortunately, as we began to use this technique more within our templates, its effectiveness began to decrease: each Ajax-include incurred a separate HTTP request, and with more than a few includes on a page at a time, those requests often clogged the time it took for a basic experience to become enhanced. On many mobile devices, this problem could quickly become serious: you only need to read a couple Steve Souders posts to know that the number of concurrent requests allowed by devices can be quite low. With varying connection speeds, it often resulted in our "nice-to-have" content taking too long to arrive. </p>

<p>This limitation meant restricting our usage to a few particularly worthwhile components per page, and continuing to strive to keep the total page weight as low as possible. (Which is, of course, a good plan in any case). Still, we wondered if the concept could be extended somehow without the drawbacks.</p>

<h2>Getting-by with a little help</h2>

<p>Skip forward a few months to yesterday: <a href="http://nicolasgallagher.com">Nicolas Gallagher</a> and I were <a href="https://twitter.com/#!/scottjehl/status/184635150792003584">chatting on Twitter about dynamic content inclusion</a>, particularly the non-essential parts:</p>

<blockquote class="twitter-tweet" data-in-reply-to="184630372942884864"><p>@<a href="https://twitter.com/necolas">necolas</a> agreed. In those situations, I like the idea of something like an anchor-include pattern for nice-to-haves. <a href="https://t.co/LbJC7R1f" title="https://gist.github.com/983328">gist.github.com/983328</a></p>&mdash; Scott Jehl (@scottjehl) <a href="https://twitter.com/scottjehl/status/184635150792003584" data-datetime="2012-03-27T13:37:04+00:00">March 27, 2012</a></blockquote>
<blockquote class="twitter-tweet" data-in-reply-to="184647008500449282"><p>@<a href="https://twitter.com/necolas">necolas</a> Thanks! working on a pattern to bring those under 1 lazy request right now&#8230;</p>&mdash; Scott Jehl (@scottjehl) <a href="https://twitter.com/scottjehl/status/184652139514167296" data-datetime="2012-03-27T14:44:35+00:00">March 27, 2012</a></blockquote>
<script src="//platform.twitter.com/widgets.js" charset="utf-8"></script>



<p>After a bit of hacking, it appeared that our existing Ajax-include approach could be extended to handle all content includes via a single HTTP request. Not long after that, a <a href="https://github.com/filamentgroup/Ajax-Include-Pattern/">Gitub repo</a> was pushed, which offers the code for you to use anywhere you&#8217;d like, and perhaps help us improve too (if you please).</p>

<h2>A Quick Demo</h2>

<p>The page linked below contains with 3 links to hypothetical, non-essential content. <code>Data-after</code> attributes in the page reference content by URL as well, which is pulled in dynamically and automatically with Ajax. If you use a browser inspector tool, you&#8217;ll notice that the 3 Ajax-include&#8217;d sections of the page arrive via one request.</p>

<p><strong>Demo page:</strong> <a href="http://filamentgroup.com/examples/ajax-include/demo.html">http://filamentgroup.com/examples/ajax-include/demo.html</a></p>

<p><strong>Github code repo</strong> <a href="https://github.com/filamentgroup/Ajax-Include-Pattern/">https://github.com/filamentgroup/Ajax-Include-Pattern/</a></p>


<h2>How it works</h2>

<p>The difference between the initial approach and this single-request version is not major: instead of requesting each piece of content via separate HTTP requests, the JavaScript makes a single request to a server-side helper script (included in the code repo), telling it which pieces of content to pack into a single response back to the UI. </p>

<p>Technically, all this means is a PHP-or-otherwise script is configured to accept a query string of comma-separated URLs and spit out the contents of those files in a single response. To identify the separate pieces of content within the response, the PHP proxy wraps each one in an invented <code>&lt;entry&gt;</code> element with a <code>url</code> attribute referencing the location from which it was fetched (<strong>note:</strong> this was formerly a <code>&lt;page&gt;</code> element, but now that our demo is using <a href="https://github.com/filamentgroup/quickconcat">quickconcat</a>, it's using <code>&lt;entry&gt;</code>. As such, the JS is now updated to look for <code>&lt;entry&gt;</code> element elements.). When this response arrives back to the UI, the JavaScript notifies all of the Ajax-include elements on the page, and the proper subset of content for each element is injected into that element's location in the page.</p>

<p>The proxy, by the way, is optional; without it, the script will revert to multiple requests. Depending on the use case, this might be preferable as well. For more information on the proxy that we're using in the demo (and that is included in the code repo) check out the <a href="https://github.com/filamentgroup/quickconcat">quickconcat project on Github</a>.</p>

<p>As far as dependencies go, the current script uses jQuery, but it could probably be done pretty concisely without it (though the event handling might make for some fun workarounds). It could also easily be built without PHP. We would love to see a pull request or two with alternatives!</p>


<h2>Using the code</h2>
<p>To use the technique yourself, grab the code from the Github repo above and...</p>
<style>
ol,li{list-style: decimal; padding-left: 0;}
ol pre { font-size: 12px; }
</style>
<ol >
<li>Include jquery.js and jquery.ajaxinclude.js in your page (anywhere&#8217;s fine)</li>
<li>Add attributes to elements in your page where nonessential fragments of content can be included from an external URL, using jQuery-api-like qualifiers like <code>data-after</code>, <code>data-before</code>, and <code>data-replace</code>:
<pre><code>
&lt;h2 data-after=&quot;/related-articles/45?fragment&quot;&gt;&lt;a href=&quot;/related-articles/45&quot;&gt;Related Articles&lt;/a&gt;&lt;/h2&gt;
</code></pre>
</li>
<li>When the DOM is ready, select the Ajax-include elements on the page and call the ajaxInclude method on them, passing the URL of the server-side proxy and expected query string:
<pre><code>
$( "[data-after]" ).ajaxInclude( "quickconcat.php?wrap&files=" );
</code></pre>
</li>
</ol>


<p><strong>Note:</strong> an ideal use case might have an anchor link somewhere in the page referencing a full HTML document, and a data-attribute somewhere else in the page referencing a smaller HTML fragment to include into the page (pseudo-coded above with the ?fragment in the URL). You might also employ smarter server logic to simply return the fragment when the page is requested via Ajax instead of regular HTTP, but let&#8217;s not get ahead of ourselves...</p>

<p>For more information on using the code, check out the <a href="https://github.com/filamentgroup/Ajax-Include-Pattern/#readme">project readme</a>.</p>

<h2>Taking this pattern further</h2>

<p>The idea of a building websites in a more modular, container-independent manner is a hot topic, and for good reason: every day we&#8217;re dealing with more diversity across the devices that access our sites, and we want to deliver the best experience we can to all. </p>

<p>With the downsides of this pattern tamed, perhaps we could even start to consider ways to extend our notion of what&#8217;s essential in a webpage...</p>

<p>Perhaps a news article&#8217;s initial HTML delivery consists of nothing but the article itself and some links to the top-level sections of the website, while the rest of the page is deferred to Ajax-includes... or maybe a landing page consists of nothing but links to the top-level sections of a website, and then the rest of the content (headlines, article teases, etc) is included via ajax in a separate request.</p>

<p>In both of these examples, the page would deliver light-weight and lightning fast, allowing you to prioritize the truly essential bits that should be there at the start, and let the slow stuff come in moments after.</p>

<p>You might even take it farther to apply a DRY-like pattern across all pages on a site or application, where each piece of content truly has only one home, and pages can borrow freely from the content of others to create mashup pages that resemble the sorts of pages we use today. (And perhaps a slightly smarter server-side helper could find the fragments within a page by their identifiers to facilitate this....)</p>

<p>A related sketch from my notes during last year&#8217;s Mobilewood meetup (click image for full size):</p>

<p><a href="http://filamentgroup.com/images/modular-page.png"><img src="http://filamentgroup.com/images/modular-page.png" style="max-width:100%" alt="a concept diagram of a modular webpage"></a></p>


<h2>Thoughts? Ideas?</h2>

<p>Whether you do or don&#8217;t use this particular script, we&#8217;d love to hear what you think of the pattern. We&#8217;re pretty excited by the potential optimizations that could come out of it, so please drop us a note, or even fork the code and extend it further!</p>
<a href=""></a>
      ]]></content>
    </entry>

    <entry>
      <title>A Responsive Design Approach for Navigation, Part 1</title>
      <link rel="alternate" type="text/html" href="http://filamentgroup.com/lab/responsive_design_approach_for_navigation/" />
      <id>tag:,2012:/lab/6.135</id>
      <published>2012-02-27T19:32:00Z</published>
      <updated>2012-03-27T15:20:57Z</updated>
      <author>
            <name>Maggie</name>
                  </author>

      <category term="progressive enhancement"
        scheme="http://filamentgroup.com/lab/tag/progressive_enhancement/"
        label="progressive enhancement" />
      <category term="responsive design"
        scheme="http://filamentgroup.com/lab/tag/responsive_design/"
        label="responsive design" />
      <content type="html"><![CDATA[
       <p class="postData">Posted by Maggie on 02/27/2012</p>

<dl class="topics">
					<dt>Topics:</dt>
					<dd><a href="http://filamentgroup.com/lab/tag/progressive_enhancement/" rel="tag">progressive enhancement</a></dd><dd><a href="http://filamentgroup.com/lab/tag/responsive_design/" rel="tag">responsive design</a></dd>
				</dl>
						<p>As we create responsive websites, we must consider a number of factors to make sure both the design and code are as bullet-proof as possible: the design must scale across a wide range of screen sizes from mobile to tablet to desktop; and the code must start with a mobile-first approach, work well for screen readers or with JavaScript disabled, and be robust enough to adapt to differences in text size and rendering across devices or user settings.</p>  

<p>Adapting site navigation to be understandable, usable and attractive across a wide range of devices is particularly challenging. On the <a href="http://bostonglobe.com/">Boston Globe site</a>, we gained some key insights about how to build robust mobile-first responsive navigation systems. This is the first in a series of articles in which we'll explore navigation design techniques from very simple nav bar design, to complex multi-level hierarchies, search, and fuller featured navigation systems.</p>
					</div>
		
					<h2>Truly responsive navigation</h2>

<p>Using progressive enhancement, CSS media queries, and a little JavaScript, we built a navigation list that adjusts to fit the size of the screen and adapts to differences in text sizing. <a href="/examples/rwd-nav-patterns/"><strong>View the demo</strong></a></p>

<p>We're in the process of rethinking our site design, so we used our own navigation list as a test case.  It consists of 5 options &#8212; What We Do, What We've Done, What We're Thinking, Who We Are, and Contact Us.  These  options can take up a lot of space on a tiny mobile screen, so our goal was simple: for smaller screens we'll make the navigation as compact as possible to save room for the main content, and on larger screens with ample space we'll display all options in a horizontal bar for quicker access.</p>

<p>We marked up a standard unordered list of links, usable on any device that renders HTML, layered on a few mobile-friendly styles to make the hit area bigger for finger taps, and then added a little JavaScript to transform the list into a custom dropdown menu.  Users that don't have JavaScript enabled will just see the full list &#8212; no harm, no foul.</p>

<p>For larger screens, we used CSS3 media queries to display the options in a horizontal bar.  We wanted to ensure that the screen has enough room to display the entire bar in a single line (we don't want the nav or its options to wrap because, in this case, wrapping would make the page look broken or mess with the navigation hierarchy), so we estimated the minimum width value: width of the horizontal navigation bar + the width of any neighboring elements + a little wiggle room.  We tested this breakpoint across a wide range of browsers, and increased the value when we saw options wrap.</p>

<p>We could've stopped there, but we can't forget that screen size is just one of many factors that effect how a layout is displayed.  Take text rendering, for example:  the type, size, and shape of fonts can vary among operating systems/browsers, and users have the option to adjust sizing with browser controls.  (And, as Stephanie Rieger notes, the list of user-controlled variables <a href="http://stephanierieger.com/the-trouble-with-ice-cream-sandwich/">is growing</a>.)  So, while it makes sense to use media queries as a baseline for altering the layout, we made our navigation bar feel smarter and more responsive with a little JavaScript to detect whether the horizontal nav bar fits in the available space, regardless of screen size; when the fit test fails, the navigation remains a custom dropdown menu.</p>

<p>The final result is a navigation list that's optimized for use on a wide range of screen widths and with variable text sizes.  We'll walk through this example in detail below.</p>


<h2>Markup</h2>

<p>The menu is a list of links, so that's what we'll use: a standard unordered list with anchor tags.  We'll group the list with a heading to identify the navigation element, "Sections", and give the outer container a descriptive class for scoping styles, <code>nav-primary</code>.</p>

<pre><code>&lt;div class=&quot;nav-primary&quot;&gt;
   &lt;h3&gt;Sections:&lt;/h3&gt;
	&lt;ul&gt;
		&lt;li&gt;&lt;a href=&quot;http://www.filamentgroup.com/services&quot;&gt;What We Do&lt;/a&gt;&lt;/li&gt;
		&lt;li&gt;&lt;a href=&quot;http://www.filamentgroup.com/portfolio&quot;&gt;What We've Done&lt;/a&gt;&lt;/li&gt;
		&lt;li&gt;&lt;a href=&quot;http://www.filamentgroup.com/lab&quot;&gt;What We're Thinking&lt;/a&gt;&lt;/li&gt;
		&lt;li&gt;&lt;a href=&quot;http://www.filamentgroup.com/about&quot;&gt;Who We Are&lt;/a&gt;&lt;/li&gt;		
		&lt;li&gt;&lt;a href=&quot;http://www.filamentgroup.com/contact&quot;&gt;Contact Us&lt;/a&gt;&lt;/li&gt;
	&lt;/ul&gt;
&lt;/div&gt;
</code></pre>

<p>We'll assign the class <code>nav-current</code> to the active navigation option; this will come in handy later when we create the custom dropdown menu.</p>

<pre><code>&lt;li <strong>class=&quot;nav-current&quot;</strong>&gt;&lt;a href=&quot;http://www.filamentgroup.com/services&quot;&gt;What We Do&lt;/a&gt;&lt;/li&gt;</code></pre>

<p>To round out our example, we'll add the Filament Group logo and a small block of content. For screen readers we'll provide a "skip navigation" link so that they don't have to navigate through the list on every page.</p>

<pre><code>&lt;a href=&quot;http://www.filamentgroup.com/&quot; id=&quot;logo&quot;&gt;&lt;img src=&quot;fg-logo.gif&quot; alt=&quot;Filament Group, Inc.&quot; /&gt;&lt;/a&gt;

&lt;a href=&quot;#main&quot; class=&quot;skip&quot;&gt;Skip navigation&lt;/a&gt;

&lt;div class=&quot;nav-primary&quot;&gt;
   &lt;h3&gt;Sections:&lt;/h3&gt;
	&lt;ul&gt;
		&lt;li class=&quot;nav-current&quot;&gt;&lt;a href=&quot;http://www.filamentgroup.com/services&quot;&gt;What We Do&lt;/a&gt;&lt;/li&gt;
		&lt;li&gt;&lt;a href=&quot;http://www.filamentgroup.com/portfolio&quot;&gt;What We've Done&lt;/a&gt;&lt;/li&gt;
		&lt;li&gt;&lt;a href=&quot;http://www.filamentgroup.com/lab&quot;&gt;What We're Thinking&lt;/a&gt;&lt;/li&gt;
		&lt;li&gt;&lt;a href=&quot;http://www.filamentgroup.com/about&quot;&gt;Who We Are&lt;/a&gt;&lt;/li&gt;		
		&lt;li&gt;&lt;a href=&quot;http://www.filamentgroup.com/contact&quot;&gt;Contact Us&lt;/a&gt;&lt;/li&gt;
	&lt;/ul&gt;
&lt;/div&gt;

&lt;div class=&quot;content&quot;&gt;
   &lt;p&gt;We offer services from strategy to UI and application design, to accessible front-end code development, and happily work with clients to find the right mix that supports their internal capabilities.&lt;/p&gt;
&lt;/div&gt;
</code></pre>

<p>Before we wrap up the markup, we want to make sure that our page content is sized to fit the screen, so we'll add a viewport <code>meta</code> tag (<a href="https://developer.apple.com/library/safari/#documentation/appleapplications/reference/SafariHTMLRef/Articles/MetaTags.html">how the viewport <code>meta</code> tag works</a>):</p>

<pre><code>&lt;meta name=&quot;viewport&quot; content=&quot;width=device-width, initial-scale=1&quot;&gt;</code></pre>

<p>We now have a legible, usable page to which we can add style and behavior enhancements.</p>

<p><img src="/examples/rwd-nav-patterns/screens/markup.png" alt="Basic markup rendered on a mid-sized screen" /></p>


<h2>Styles for the small screen</h2>

<p class="note">If you're not familiar with using CSS3 media queries to render pages responsively, we highly recommend Ethan Marcotte's definitive article, <a href="http://www.alistapart.com/articles/responsive-web-design/">Responsive Web Design</a>, and <a href="http://www.abookapart.com/products/responsive-web-design">book by the same title</a>.</p>

<p>We'll start with a few basic styles that make the links easier to read and tap on small screens (a block display property and padding, and a font-size that's large enough for finger-based gestures), and a few additional styles to make the list easier to scan (borders between options, and bold text for the active option).  We'll also hide the "Sections" heading (h3), but in a way that keeps it accessible to screen readers.</p>

<pre><code>.nav-primary h3 {
   position: absolute;
   left: -999em;
}
.nav-primary ul {
   border: 1px solid #e6e6e6;
}
.nav-primary li {
   font-size: 1.8em;
   border-bottom: 1px solid #eee;
}
.nav-primary li:last-child {
   border-bottom: 0;
}
.nav-primary a {
   display: block;
   padding: .5em .8em;
   text-decoration: none;
   color: #333;
}
.nav-primary a:hover {
   background-color: #f8f8f8;
}
.nav-primary .nav-current {
   font-weight: bold;
}
</code></pre>

<p>We'll add a few more rules to style the overall page, logo and content blocks, and another rule to make the navigation play nicely with them (clear the logo, and add space before the content). We want the "skip" link to be available to screen readers but hidden from everyone else, so we'll position it off the page.</p>

<pre><code>body {
    font: 62.5%/1.4 helvetica, arial, sans-serif; 
    padding: 2em 1em;
}
#logo {
   float: left;
   margin: 0 0 1em; 
}
.content {
   clear: both;
}
p {
   font-size: 1.8em;
   line-height: 1.4;
   margin: 0 .3em 1em;
}
a.skip {
   position: absolute;
   left: -999em;
}

...

.nav-primary {
   clear: left;
   margin: 0 0 2em;
}
</code></pre>

<p><img src="/examples/rwd-nav-patterns/screens/small-basicCSS.png" alt="Basic styles rendered on a small screen" /></p>

<h2>...and for larger screens, like tablets and desktops</h2>

<p>Our page looks nice at smaller screen widths, but on a larger screen, each option stretches to fill the space and the navigation dominates the page.</p>

<p><img src="/examples/rwd-nav-patterns/screens/med-basicCSS.png" alt="Basic styles rendered on a larger screen; the navigation takes up too much space" /></p>

<p>To fix this, we'll add a couple of rules, scoped within a media query, to display the navigation as a horizontal bar in screens that are 640px wide and larger (640 = full width of the navigation + body padding).</p>

<p>We'll float each navigation option to the left, remove the border between options, and assign a slightly smaller font size.  We'll also float the navigation block itself and the list container so that they fully contain their floated child elements.</p>

<pre><code>@media screen and (min-width: 640px) {
   .nav-primary,
   .nav-primary ul {
      float: left;
   }
   .nav-primary ul {
      float: left;
   }
   .nav-primary li {
      float: left;
      font-size: 1.5em;
      border-bottom: 0;
   }   
}</code></pre>

<p>Much better.</p>

<p><img src="/examples/rwd-nav-patterns/screens/med-mediaquery.png" alt="Navigation rendered as a horizontal bar on screens 640px or wider" /></p>

<p>When the screen is wide enough to fit the logo and nav side-by-side &#8212; 910px, specifically &#8212; we'll float the navigation block to the right.  We arrived at that number by adding the width of the logo (250px) to the width of the navigation list displayed horizontally (640px), plus a little extra margin to account for slight browser rendering differences (20px).</p>

<pre><code>@media screen and (min-width: 910px) {
   .nav-primary {
      float: right;
      clear: none;
   }   
}</code></pre>

<p>Our navigation now assumes one of two forms in response to the screen's size:  a list on smaller screens, or a horizontal bar on larger screens.</p>

<p><img src="/examples/rwd-nav-patterns/screens/mediaquery.png"  alt="Examples showing a list on smaller screens, or a horizontal bar on larger screens" /></p>

<p>As it stands, our navigation looks pretty good on a range of screen sizes &#8212; but there is definitely room for improvement.  On small screens, our navigation list still takes up a good chunk of vertical space, and on larger screens, our horizontal navigation bar wraps when we increase our browser's text size.  Bump up the text a couple of times on a tablet-sized screen and the options wrap to a second line:</p>

<p><img src="/examples/rwd-nav-patterns/screens/text2-options-wrap.png"  alt="Navigation options wrap to a second line when text size is increased" /></p>

<p>And at larger sizes, the entire navigation bar wraps under the logo, creating odd gaps of white space:</p>

<p><img src="/examples/rwd-nav-patterns/screens/text2-nav-wraps.png"  alt="Navigation bar wraps under the logo when text size is increased" /></p>

<p>So we have two issues left to address:</p>

<ul>
<li>transform the navigation into a compact, custom dropdown menu when screen space is limited, and</li>
<li>create a test to determine if navigation options will fit on a single line, or if the entire bar will fit next to the logo on larger screens; if not, show the compact menu.</li>
</ul>

<p>We'll start with menu styles, and then fill in the test logic.</p>

<h2>Styles for a compact menu</h2>

<p>We'll write styles to hide all options by default except for the active option, <code>nav-current</code>, and display the "Sections" heading as a clickable dropdown button positioned to the right.  We'll add another class, <code>expanded</code>, that we'll toggle with JavaScript to show/hide the full list of options.</p>

<p>Note that these styles are all scoped to the class, <code>nav-menu</code>.  Later, our test logic will toggle this class on the <code>body</code> tag.</p>

<pre><code>.nav-menu .nav-primary {
   margin: 0 0 1.5em;
   position: relative;
   overflow: hidden;
}
.nav-menu .nav-primary a {
   padding-right: 3em;
}
.nav-menu .nav-primary h3 {
   position: absolute;
   top: 0;
   left: auto;
   right: 0;
   display: block;
   width: 4em;
   height: 4.5em; 
   background: #ccc url(img/icons.png) no-repeat -205px 45%;
   text-indent: -999em;
   cursor: pointer;
}
.nav-menu .nav-primary.expanded h3 {
   background-position: -169px 45%;
}
.nav-menu .nav-primary li {
   clear: left;
   display: none;
}    
.nav-menu .nav-primary.expanded li,
.nav-menu .nav-primary li.nav-current {
   display: list-item;
} 
.nav-menu .nav-primary li.nav-current {
   border-bottom-width: 0;
}
.nav-menu .nav-primary.expanded li.nav-current {
   border-bottom-width: 1px;
}</code></pre>

<p>Now, when JavaScript is enabled, the menu will take a more compact form:</p>

<p><img src="/examples/rwd-nav-patterns/screens/small-menu.png"  alt="Navigation rendered as a compact menu" /></p>

<p>Next, we'll write a bit of JavaScript to ensure that our navigation bar fits the available space.

<h2>Does the navigation fit?</h2>

<p>We'll bind a custom event, "testfit", to the navigation container.  We'll trigger this event when the page loads, and when the screen changes size or orientation.  (A nice side effect: desktop browsers that support text zooming, like the latest versions of Chrome, Firefox, and Opera, trigger the <code>resize</code> event &#8212; and this test &#8212; when the user increases or decreases text sizing with browser controls or key commands.)</p>

<pre><code>$('.nav-primary')
   // test the menu to see if all items fit horizontally
   .bind('testfit', function(){
      // ...logic goes here...
   }) 
   
   // ...and update the nav on window events
   $(window).bind('load resize orientationchange', function(){   
      $('.nav-primary').trigger('testfit');
   });</code></pre>

<p>When the test passes, we'll add the <code>nav-menu</code> class to the <code>body</code>. One of the following conditions must be met for "testfit" to pass: when the entire nav wraps to a second line under the logo, or when any of the navigation options wrap to a second line.  In both cases, we test for wrapping by comparing top offset values, which can be effected by changes in screen or text size.  When the navigation's top value is greater than the logo's, the navigation has wrapped to the next line; when the last navigation option's top value is greater than the first, it's wrapped. </p>

<p>We'll also remove the <code>nav-menu</code> class from the <code>body</code> to reset the styles before the test is run.</p>

<pre><code>$('.nav-primary')
   // test the menu to see if all items fit horizontally
   .bind('testfit', function(){
      var nav = $(this),
            items = nav.find('a');
      
      $('body').removeClass('nav-menu');                                
      
      // when the nav wraps under the logo, or when options are stacked, display the nav as a menu              
      if ( (nav.offset().top > nav.prev().offset().top) || ($(items[items.length-1]).offset().top > $(items[0]).offset().top) ) {
      
         // show the menu -- add a class for scoping menu styles
         $('body').addClass('nav-menu');
      
      };           
   })
      
   ...</code></pre>

<p>Finally, we'll assign a click event to the heading element to show/hide the menu options.</p>

<pre><code>$('.nav-primary').find('h3')
   .bind('click focus', function(){
      $(this).parent().toggleClass('expanded')
   });</code></pre>

<p>We now have a menu that is responsive to differences in screen size (<a href="/examples/rwd-nav-patterns/">view the demo</a>):</p>

<p><a href="/examples/rwd-nav-patterns/"><img src="/examples/rwd-nav-patterns/screens/menus.png" alt="Examples of the closed menu and with all options visible, sized for the tablet screen, and displayed as a horizontal bar next to the logo" /></a></p>

<p>..and text size:</p>

<p><a href="/examples/rwd-nav-patterns/"><img src="/examples/rwd-nav-patterns/screens/text-zoom.png"  alt="On larger screens, the navigation becomes a compact menu when text size is increased and the nav no longer fits on one line" /></a></p>

<h2>Keep the conversation going</h2>

<p>The pattern discussed here is one possibility for coding a responsive navigation list. We hope to discover more, and will update our <a href="https://github.com/filamentgroup/RWD-Nav-Patterns">RWD-Nav-Patterns git repository</a> as we build additional examples.</p>

<p>This demo code is open source and available for download. Feel free to put it through its paces. If you use it and see room for improvement, please submit a pull request and we'll review it as soon as possible.</p>
<a href=""></a>
      ]]></content>
    </entry>

    <entry>
      <title>W3C Launches Responsive Images Community</title>
      <link rel="alternate" type="text/html" href="http://filamentgroup.com/lab/w3c_responsive_imgs_group/" />
      <id>tag:,2012:/lab/6.137</id>
      <published>2012-02-24T09:20:00Z</published>
      <updated>2012-02-24T17:24:01Z</updated>
      <author>
            <name>Scott</name>
                  </author>

      <category term="announcements"
        scheme="http://filamentgroup.com/lab/tag/announcements/"
        label="announcements" />
      <category term="responsive design"
        scheme="http://filamentgroup.com/lab/tag/responsive_design/"
        label="responsive design" />
      <category term="web standards"
        scheme="http://filamentgroup.com/lab/tag/web_standards/"
        label="web standards" />
      <content type="html"><![CDATA[
       <p class="postData">Posted by Filament Group on 02/24/2012</p>

<dl class="topics">
					<dt>Topics:</dt>
					<dd><a href="http://filamentgroup.com/lab/tag/announcements/" rel="tag">announcements</a></dd><dd><a href="http://filamentgroup.com/lab/tag/responsive_design/" rel="tag">responsive design</a></dd><dd><a href="http://filamentgroup.com/lab/tag/web_standards/" rel="tag">web standards</a></dd>
				</dl>
						<p>Responsible image asset loading has long been a problem in cross-device development, and more recently, in responsive design. While developing the new BostonGlobe.com, we released <a href="http://filamentgroup.com/lab/responsive_images_experimenting_with_context_aware_image_sizing/">an approach to the problem</a> that worked well at the time, but unfortunately proved less optimal as newer browsers' image prefetch "improvements" effectively broke it. Around that time, <a href="http://www.cloudfour.com/responsive-imgs/">consensus gathered</a> that device-detection-based approaches were most viable until we get better tools, and at that point we tended to agree.</p>

<p> Shift ahead a few months, when our own Mat Marquis penned the A List Apart article, <a href="http://alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/">Responsive Images: How they Almost Worked and What We Need</a> providing great background on today's workarounds, and a rough proposal for a markup-based approach moving forward. Hot on the heels of that article, the W3C has formed a <a href="http://www.w3.org/community/respimg/">Responsive Images Community Group</a>, of which Mat is the chair, to continue guiding this idea through to potential standardization.</p>

<p>Filament Group is thrilled to see this idea begin to take shape, and we're doing all we can to help (<em>Scott here even <a href="http://www.w3.org/community/respimg/2012/02/21/a-sample-picture-implementation/">released a functional picture element polyfill</a> to aid in the planning</em>). If you're at all interested in the direction of this feature, feel free to follow, or join, the <strong><a href="http://www.w3.org/community/respimg/">W3C Responsive Images Group</a></strong>. We'll hope to see you there!</p>

					</div>
		
					
<a href=""></a>
      ]]></content>
    </entry>


</feed>