Skip navigation
Help

David Bushell

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.
Original author: 
Stéphanie Walter

  

Responsive Web design has been around for some years now, and it was a hot topic in 2012. Many well-known people such as Brad Frost and Luke Wroblewski have a lot of experience with it and have helped us make huge improvements in the field. But there’s still a whole lot to do.

In this article, we will look at what is currently possible, what will be possible in the future using what are not yet standardized properties (such as CSS Level 4 and HTML5 APIS), and what still needs to be improved. This article is not exhaustive, and we won’t go deep into each technique, but you’ll have enough links and knowledge to explore further by yourself.

The State Of Images In Responsive Web Design

What better aspect of responsive Web design to start off with than images? This has been a major topic for a little while now. It got more and more important with the arrival of all of the high-density screens. By high density, I mean screens with a pixel ratio higher than 2; Apple calls these Retina devices, and Google calls them XHDPI. In responsive Web design, images come with two big related challenges: size and performance.

Most designers like pixel perfection, but “normal”-sized images on high-density devices look pixelated and blurry. Simply serving double-sized images to high-density devices might be tempting, right? But that would create a performance problem. Double-sized images would take more time to load. Users of high-density devices might not have the bandwidth necessary to download those images. Also, depending on which country the user lives in, bandwidth can be pretty costly.

The second problem affects smaller devices: why should a mobile device have to download a 750-pixel image when it only needs a 300-pixel one? And do we have a way to crop images so that small-device users can focus on what is important in them?

Two Markup Solutions: The <picture> Element and The srcset Attribute

A first step in solving the challenge of responsive images is to change the markup of embedded images on an HTML page.

The Responsive Images Community Group supports a proposal for a new, more flexible element, the <picture> element. The concept is to use the now well-known media queries to serve different images to different devices. Thus, smaller devices would get smaller images. It works a bit like the markup for video, but with different images being referred to in the source element.

The code in the proposed specification looks like this :


<picture width="500"  height="500">     
  <source  media="(min-width: 45em)" src="large.jpg">
  <source  media="(min-width: 18em)" src="med.jpg">
  <source  src="small.jpg">
  <img  src="small.jpg" alt="">
  <p>Accessible  text</p>
</picture>

If providing different sources is possible, then we could also imagine providing different crops of an image to focus on what’s important for smaller devices. The W3C’s “Art Direction” use case shows a nice example of what could be done.

Picture element used for artistic direction
(Image: Egor Pasko)

The solution is currently being discussed by the W3C Responsive Images Community Group but is not usable in any browser at the moment as far as we know. A polyfill named Picturefill is available, which does pretty much the same thing. It uses a div and data-attribute syntax for safety’s sake.

A second proposal for responsive images markup was made to the W3C by Apple and is called “The srcset Attribute”; its CSS Level 4 equivalent is image-set(). The purpose of this attribute is to force user agents to select an appropriate resource from a set, rather than fetch the entire set. The HTML syntax for this proposal is based on the <img> tag itself, and the example in the specification looks like this:


<img  alt="The Breakfast Combo" 
  src="banner.jpeg"
  srcset="banner-HD.jpeg  2x, banner-phone.jpeg 100w, banner-phone-HD.jpeg 100w 2x">

As you can see, the syntax is not intuitive at all. The values of the tag consist of comma-separated strings. The values of the attribute are the names or URLs of the various images, the pixel density of the device and the maximum viewport size each is intended for.

In plain English, this is what the snippet above says:

  • The default image is banner.jpeg.
  • Devices that have a pixel ratio higher than 2 should use banner-HD.jpeg.
  • Devices with a maximum viewport size of 100w should use banner-phone.jpeg.
  • Devices with a maximum viewport size of 100w and a pixel ratio higher than 2 should use banner-phone-HD.jpeg.

The first source is the default image if the srcset attribute is not supported. The 2x suffix for banner-HD.jpeg means that this particular image should be used for devices with a pixel ratio higher than 2. The 100w for banner-phone.jpeg represents the minimum viewport size that this image should be used for. Due to its technical complexity, this syntax has not yet been implemented in any browser.

The syntax of the image-set() CSS property works pretty much the same way and enables you to load a particular background image based on the screen’s resolution:


background-image: image-set(  "foo.png" 1x,
  "foo-2x.png"  2x,
  "foo-print.png"  600dpi );

This proposal is still a W3C Editor’s Draft. For now, it works in Safari 6+ and Chrome 21+.

Image Format, Compression, SVG: Changing How We Work With Images on the Web

As you can see, these attempts to find a new markup format for images are still highly experimental. This raises the issue of image formats themselves. Can we devise a responsive solution by changing the way we handle the images themselves?

The first step would be to look at alternative image formats that have a better compression rate. Google, for example, has developed a new image format named WebP, which is 26% smaller than PNG and 25 to 34% smaller than JPEG. The format is supported in Google Chrome, Opera, Yandex, Android and Safari and can be activated in Internet Explorer using the Google Chrome Frame plugin. The main problem with this format is that Firefox does not plan to implement it. Knowing this, widespread use is unlikely for now.

Another idea that is gaining popularity is progressive JPEG images. Progressive JPEG images are, as the name suggests, progressively rendered. The first rendering is blurry, and then the image gets progressively sharper as it renders. Non-progressive JPEG images are rendered from top to bottom. In her article “Progressive JPEGs: A New Best Practice,” Ann Robson argues that progressive JPEGs give the impression of greater speed than baseline JPEGs. A progressive JPEG gives the user a quick general impression of the image before it has fully loaded. This does not solve the technical problems of performance and image size, though, but it does improve the user experience.

Another solution to the problems of performance and image size is to change the compression rate of images. For a long time, we thought that enlarging the compression rate of an image would damage the overall quality of the image. But Daan Jobsis has done extensive research on the subject and has written an article about it, “Retina Revolution.” In his experiments, he tried different image sizes and compression rates and came up with a pretty interesting solution. If you keep the image dimensions twice the displayed ones but also use a higher compression rate, then the image will have a smaller file size than the original, but will still be sharp on both normal and high-density screens. With this technique, Jobsis cut the weight of the image by 75%.

Image compression example
Daan Jobsis’ demonstration of image compression.

Given the headaches of responsive images, the idea of gaining pixel independence from images wherever possible is seducing more and more designers and developers. The SVG format, for example, can be used to create all of the UI elements of a website and will be resolution-independent. The elements will scale well for small devices and won’t be pixellated on high-density devices. Font icons are another growing trend. They involve asigning icon glyphs to certains characters of the font (like the Unicode Private Area ones), giving you the flexibility of fonts. Unfortunately, the solution doesn’t work with pictures, so a viable markup or image format is eagerly expected.

Responsive Layout Challenge: Rearrange And Work With Content Without Touching the HTML?

Let’s face it, the fluid grids made of floats and inline blocks that we use today are a poor patch waiting for a better solution. Working with layout and completely rearranging blocks on the page for mobile without resorting to JavaScript is a nightmare right now. It’s also pretty inflexible. This is particularly significant on websites created with a CMS; the designer can’t change the HTML of every page and every version of the website. So, how can this be improved?

Four CSS3 Layout Solutions That Address the Flexible Layout Problem

The most obvious possible solution is the CSS3 flexible box layout model (or “flexbox”). Its current status is candidate recommendation, and it is supported in most major mobile browsers and desktop browsers (in IE starting from version 10). The model enables you to easily reorder elements on the screen, independent of the HTML. You can also change the box orientation and box flow and distribute space and align according to the context. Below is an example of a layout that could be rearranged for mobile. The syntax would look like this:


.parent {
  display: flex;
  flex-flow: column; /* display items in columns */
}

.children {
  order: 1; /* change order of elements */
}

Flexbox as an example

The article “CSS3 Flexible Box Layout Explained” will give you a deeper understanding of how flexbox works.

Another solution quite close to the flexbox concept of reordering blocks on the page, but with JavaScript, is Relocate.

A second type of layout that is quite usable for responsive design today is the CSS3 multiple-column layout. The module is at the stage of candidate recommendation, and it works pretty well in most browsers, expect for IE 9 and below. The main benefit of this model is that content can flow from one column to another, providing a huge gain in flexibility. In terms of responsiveness, the number of columns can be changed according to the viewport’s size.

Setting the size of the columns and letting the browser calculate the number of columns according to the available space is possible. Also possible is setting the number of columns, with the gaps and rules between them, and letting the browser calculate the width of each column.

CSS3 Multiple Column layout

The syntax looks like this:


.container {
  column-width: 10em ; /* Browser will create 10em columns. Number of columns would depend on available space. */
}

.container {
  columns: 5; /* Browser will create 5 columns. Column size depends on available space. */
  column-gap: 2em;
}

To learn more, read David Walsh’s article “CSS Columns.”

A third CSS3 property that could gain more attention in future is the CSS3 grid layout. This gives designers and developers a flexible grid they can work with to create different layouts. It allows content elements to be displayed in columns and rows without a defined structure. First, you would declare a grid on the container, and then place all child elements in this virtual grid. You could then define a different grid for small devices or change the position of elements in the grid. This allows for enormous flexibility when used with media queries, changes in orientation and so on.

The syntax looks like this (from the 2 April 2013 working draft):


 .parent {
   display: grid; /* declare a grid */
   grid-definition-columns: 1stgridsize  2ndgridsize …;
   grid-definition-rows: 1strowsize  2ndrowsize …;
}

.element {
   grid-column: 1; 
   grid-row: 1
}

.element2 {
   grid-column: 1; 
   grid-row: 3;
}

To set the sizes of columns and rows, you can use various units, as detailed in the specification. To position the various elements, the specification says this: “Each part of the game is positioned between grid lines by referencing the starting grid line and then specifying, if more than one, the number of rows or columns spanned to determine the ending grid line, which establishes bounds for the part.”

The main problem with this property is that it is currently supported only in IE 10. To learn more about this layout, read Rachel Andrew’s “Giving Content Priority With CSS3 Grid Layout.” Also, note that the specification and syntax for grid layouts changed on 2 April 2013. Rachel wrote an update on the syntax, titled “CSS Grid Layout: What Has Changed?

The last layout that might become useful in future if implemented in browsers is the CSS3 template layout. This CSS3 module works by associating an element with a layout “name” and then ordering the elements on an invisible grid. The grid may be fixed or flexible and can be changed according to the viewport’s size.

The syntax looks like this:


.parent {
   display: "ab"
            "cd" /* creating the invisible  grid */
}

.child1 {
   position: a;
}

.child2 {
   position: b;
}

.child3 {
   position: c;
}

.child4 {
   position: d;
} 

This renders as follows:

CSS3 template layout

Unfortunately, browser support for this CSS3 module is currently null. Maybe someday, if designers and developers show enough interest in this specification, some browser vendors might implement it. For the moment, you can test it out with a polyfill.

Viewport-Relative Units and the End of Pixel-Based Layout

Viewport-based percentage lengths — vw, vh, vm, vmin and vmax — are units measured relative to the dimensions of the viewport itself.

One vw unit is equal to 1% of the width of the initial containing block. If the viewport’s width is 320, then 1 vw is 1 × 320/100 = 3.2 pixels.

The vh unit works the same way but is relative to the height of the viewport. So, 50 vh would equal 50% of the height of the document. At this point, you might wonder what the difference is with the percentage unit. While percentage units are relative to the size of the parent element, the vh and vw units will always be relative to the size of the viewport, regardless of the size of their parents.

This gets pretty interesting when you want to, for example, create a content box and make sure that it never extends below the viewport’s height so that the user doesn’t have to scroll to find it. This also enables us to create true 100%-height boxes without having to hack all of the elements’ parents.

The vmin unit is equal to the smaller of vm or vh, and vmax is equal to the larger of vm or vh; so, those units respond perfectly to changes in device orientation, too. Unfortunately, for the moment, those units are not supported in Android’s browser, so you might have to wait a bit before using them in a layout.

A Word on Adaptive Typography

The layout of a website will depend heavily on the content. I cannot conclude a section about the possibilities of responsive layout without addressing typography. CSS3 introduces a font unit that can be pretty handy for responsive typography: the rem unit. While fonts measured in em units have a length relative to their parent, font measured in rem units are relative to the font size of the root element. For a responsive website, you could write some CSS like the following and then change all font sizes simply by changing the font size specified for the html element:


html {
   font-size: 14px;
}

p {
   font-size: 1rem /* this has 14px */
}

@media screen and (max-width:380px) {
   html {
      font-size: 12px; /* make the font smaller for mobile devices */
   }

   p {
      font-size: 1rem /* this now equals 12px */
   }
}

Except for IE 8 and Opera mini, support for rem is pretty good. To learn more about rem units, read Matthew Lettini’s article “In Defense of Rem Units.”

A Better Way To Work Responsively With Other Complex Content

We are slowly getting better at dealing with images and text in responsive layouts, but we still need to find solutions for other, more complex types of content.

Dealing With Forms on a Responsive Website

Generally speaking, dealing with forms, especially long ones, in responsive Web design is quite a challenge! The longer the form, the more complicated it is to adapt to small devices. The physical adaptation is not that hard; most designers will simply put the form’s elements into a single column and stretch the inputs to the full width of the screen. But making forms visually appealing isn’t enough; we have to make them easy to use on mobile, too.

For starters, Luke Wroblewski advises to avoid textual input and instead to rely on checkboxes, radio buttons and select drop-down menus wherever possible. This way, the user has to enter as little information as possible. Another tip is not to make the user press the “Send” button before getting feedback about the content of their submission. On-the-fly error-checking is especially important on mobile, where most forms are longer than the height of the screen. If the user has mistyped in a field and has to send the form to realize it, then chances are they won’t even see where they mistyped.

In the future, the new HTML5 form inputs and attributes will be a great help to us in building better forms, without the need for (much) JavaScript. For instance, you could use the required attribute to give feedback about a particular field on the fly. Unfortunately, support for this on mobile devices is poor right now. The autocomplete attribute could also help to make forms more responsive.

A mobile phone is a personal possession, so we can assume that data such as name and postal address will remain consistent. Using the autocomplete HTML5 attribute, we could prefill such fields so that the user doesn’t have to type all of that information over and over. There is also a whole list of new HTML5 inputs that can be used in the near future to make forms more responsive.

Dates in form elements are a good example of what can be improved with HTML5. We used to rely on JavaScripts to create date-pickers. Those pickers are quite usable on big desktop screens but very hard to use on touch devices. Selecting the right date with a finger is difficult when the touch zones are so small.

Different picker examples
How am I supposed to select a date when my finger is touching three dates at the same time?

A promising solution lies in the new HTML5 input type="date", which sets a string in the format of a date. The HTML5 input type="datetime" sets a string in the format of a date and time. The big advantage of this method is that we let the browser decide which UI to use. This way, the UI is automatically optimized for mobile phones. Here is what an input type="date" looks like on the desktop, on an Android phone and tablet (with the Chrome browser), and on the iPhone and iPad.

Mobile input type=date rendering
Renderings of input type="date" on different mobile devices.

Note that the screenshots were taken in my browser and on the Android phone, so the language automatically adapted to the system language (French). By using native components, you no longer have to adapt the language into different versions of the website.

For now, support for input type="date" on the desktop is absent except in Opera and Chrome. Native Android browsers don’t support it at all, but Chrome for Android does, and so does Safari on iOS. A lot still has to get done in order for us to be able to use this solution on responsive websites. Meanwhile, you could use a polyfill such as Mobiscroll for mobile browsers that don’t support it natively.

Apart from these HTML5 input solutions, attempts have been made to improve other design patterns, such as passwords on mobile and complex input formatting using masks. As you will notice, these are experimental. The perfect responsive form does not exist at the moment; a lot still has to be done in this field.

Dealing With Tables on a Responsive Website

Another content type that gets pretty messy on mobile and responsive websites is tables. Most table are oriented horizontally and present a lot of data at once, so you can see how getting it right on a small screen is pretty hard. HTML tables are fairly flexible — you can use percentages to change the width of the columns — but then the content can quickly become unreadable.

No one has yet found the perfect way to present tables, but some suggestions have been made.

One approach is to hide what could be considered “less important” columns, and provide checkboxes for the user to choose which columns to see. On the desktop, all columns would be shown, while on mobile, the number of columns shown would depend on the screen’s size. The Filament Group explains this approach and demonstrates it in one of its articles. The solution is also used in the table column toggle on jQuery Mobile.

Responsive table examples
Some examples of responsive tables.

A second approach plays with the idea of a scrollable table. You would “pin” a single fixed-size column on the left and then leave a scroll bar on a smaller part of the table to the right. David Bushell implements this idea in an article, using CSS to display all of the content in the <thead> on the left side of the table, leaving the user to scroll through the content on the right. Zurb uses the same idea but in a different way for its plugin. In this case, the headers stay at the top of the table, and the table is duplicated with JavaScript so that only the first column is shown on the left, and all other columns are shown on the right with a scroll bar.

Responsive table overflow example
Two examples of scrollable responsive tables

The big issue with scroll bars and CSS properties such as overflow: auto is that many mobile devices and tablets simply won’t display a visible scroll bar. The right area of the table will be scrollable, but the user will have no visual clue that that’s possible. We have to find some way to indicate that more content lies to the right.

A third approach is to reflow a large table and split up the columns into what essentially looks like list items with headings. This technique is used in the “reflow mode” on jQuery Mobile and was explained by Chris Coyier in his article “Responsive Data Tables.”

Responsive table reflow example
Reflowing a table responsively

Many other techniques exist. Which to use depends heavily on your project. No two projects are the same, so I can only show you how other people have dealt with it. If you come up with a nice solution of your own, please share it with the world in the comments below, on Twitter or elsewhere. We are in this boat together, and tables suck on mobile, really, so let’s improve them together!

Embedding Third-Party Content: The Responsive Iframe Problem

Many websites consist of embedded third-party content: YouTube or Vimeo videos, SlideShare presentations, Facebook applications, Twitter feeds, Google Maps and so on. A lot of those third parties make you use iframes to embed their content. But let’s face it: iframes are a pain to deal with in responsive design. The big problem is that iframes force a fixed width and height directly in your HTML code. Forcing a 100% width on the iframe would work, but then you would lose the ratio of the embedded content. To embed a video or slideshow and preserve the original ratio, you would have to find a workaround.

An HTML and CSS Workaround

Thierry Koblentz has written a good article titled “Creating Intrinsic Ratios for Video,” in which he proposes a way to embed responsive videos using a 16:9 ratio. This solution can be extended to other sorts of iframe content, such as SlideShare presentations and Google Maps. Koblentz wraps the iframe in a container with a class that we can target in CSS. The container makes it possible for the iframe to resize fluidly, even if the iframe has fixed pixel values in the HTML. The code, adapted by Anders M. Andersen, looks like this:


 .embed-container  {
   position: relative;
   padding-bottom: 56.25%; /* 16:9 ratio */
   padding-top: 30px; /* IE 6 workaround*/
   height: 0;
   overflow: hidden;
}

.embed-container iframe,
.embed-container object,
.embed-container embed {
   position: absolute;
   top: 0;
   left: 0;
   width: 100%;
   height: 100%;
}

This will work for all iframes. The only potential problem is that you will have to wrap all of the iframes on your website in a <div class="embed-container"> element. While this would work for developers who have total control over their code or for clients who are reasonably comfortable with HTML, it wouldn’t work for clients who have no technical skill. You could, of course, use some JavaScript to detect iframe elements and automatically embed them in the class. But as you can see, it’s still a major workaround and not a perfect solution.

Dealing With Responsive Video In Future

HTML5 opens a world of possibilities for video — particularly with the video element. The great news is that support for this element is amazingly good for mobile devices! Except for Opera Mini, most major browsers support it. The video element is also pretty flexible. Presenting a responsive video is as simple as this:


video {
   max-width: 100%;
   height: auto;
}

You’re probably asking, “What’s the problem, then?”

The problem is that, even though YouTube or Vimeo may support the video element, you still have to embed videos using the ugly iframe method. And that, my friend, sucks. Until YouTube and Vimeo provide a way to embed videos on websites using the HTML5 video tag, we have to find workarounds to make video embedding work on responsive websites. Chris Coyier created such a workaround as a jQuery plugin called FitVids.js. It uses the first technique mentioned above: creating a wrapper around the iframe to preserve the ratio.

Embedding Google Maps

If you embed a Google Map on your website, the technique described above with the container and CSS will work. But, again, it’s a dirty little hack. Moreover, the map will resize in proportion and might get so tiny that the map loses the focus area that you wanted to show to the user. The Google Maps’ page for mobile says that you can use the static maps API for mobile embedding. Using a static map would indeed make the iframe problems go away. Brad Frost wrote a nice article about, and created a demo of, adaptive maps, which uses this same technique. A JavaScript detects the screen’s size, and then the iframe is replaced by the static map for mobile phones. As you can tell, we again have to resort to a trick to deal with the iframe problem, in the absence of a “native” solution (i.e. from Google).

We Need Better APIs

And now the big question: Is there a better way? The biggest problem with using iframes to embed third-party content responsively is the lack of control over the generated code. Developers and designers are severely dependent on the third party and, by extension, its generated HTML. The number of websites that provide content to other websites is growing quickly. We’ll need much better solutions than iframes to embed this content.

Let’s face it: embedding Facebook’s iframe is a real pain. The lack of control over the CSS can make our work look very sloppy and can even sometimes ruin the design. The Web is a very open place, so perhaps now would be a good time to start thinking about more open APIs! In the future, we will need APIs that are better and simpler to use, so that anyone can embed content flexibly, without relying on unresponsive fixed iframes. Until all of those very big third parties decide to create those APIs, we are stuck with sloppy iframes and will have to resort to tricks to make them workable.

Responsive Navigation: An Overview Of Current Solutions

Another big challenge is what to do with navigation. The more complex and deep the architecture of the website, the more inventive we have to be.

An early attempt to deal with this in a simple way was to convert the navigation into a dropdown menu for small screens. Unfortunately, this was not ideal. First, this solution gets terribly complicated with multiple-level navigation. It can also cause some problems with accessibility. I recommend “Stop Misusing Select Menus” to learn about all of the problems such a technique can create.

Some people, including Brad Frost and Luke Wroblewski, have attempted to solving this problem. Brad Frost compiled some of his techniques on the website This Is Responsive, under the navigation section.

Toggle navigation involves hiding the menu for small devices, displaying only a “menu” link. When the user clicks on it, all of the other links appear as block-level elements below it, pushing the main content below the navigation.

A variant of this, inspired by some native application patterns, is off-canvas navigation. The navigation is hidden beneath a “menu” link or icon. When the user clicks the link, the navigation slides out as a panel from the left or right, pushing the main content over.

Toggle navigation example
Some examples of toggle navigation

The problem with these techniques is that the navigation remains at the top of the screen. In his article “Responsive Navigation: Optimizing for Touch Across Devices,” Luke Wroblewski illustrates which zones are easily accessible for different device types. The top left is the hardest to get to on a mobile device.

Easy touch access for mobile and tablet
Easily accessible screen areas on mobile phones and tablets, according to Luke Wroblewski.

Based on this, Jason Weaver created some demos with navigation at the bottom. One solution is a footer anchor, with navigation put at the bottom of the page for small devices, and a “menu” link that sends users there. It uses the HTML anchor link system.

Many other attempts have been made to solve the navigation problem in responsive Web design. As you can see, there is not yet a perfect solution; it really depends on the project and the depth of the navigation. Fortunately for us, some of the people who have tried to crack this nut have shared their experiences with the community.

Another unsolved issue is what icon to use to tell the user, “Hey! There’s a menu hidden under me. Click me!” Some websites have a plus symbol (+), some have a grid of squares, other have what looks like an unordered list, and some have three lines (aka the burger icon).

Some responsive icons example
To see these icons used on real websites, have a look at “We Need a Standard ‘Show Navigation’ Icon for Responsive Web Design.”

The main problem is figuring out which of these icons would be the most recognizable to the average user. If we all agreed to use one of them, users would be trained to recognize it. The problem is which to choose? I really would like to know which icon you use, so don’t hesitate to share it in the comments below.

Mobile Specificities: “Is The User On A Mobile Device? If So, What Can It Do?”

Mobile and tablet devices are a whole new world, far removed from desktop computers, with their own rules, behaviors and capabilities. We might want to adapt our designs to this new range of capabilities.

Detecting Touch Capabilities With Native JavaScript

Apart from screen size, I bet if you asked what is the main difference between desktop and mobile (including tablets), most people would say touch capability. There is no mouse on a mobile phone (no kidding!), and except for some rare hybrid devices into which you can plug a mouse, you can’t do much with mouse events on a tablet. This means that, depending on the browser, the :hover CSS pseudo-class might not work. Some browsers are clever enough to provide a native fallback for the hover event by translating it into a touch event. Unfortunately, not all browsers are so flexible. Creating a design that doesn’t depend on hidden elements being revealed on :hover events would be wise.

Catching touch events could also be another solution. A W3C working group has started working on a touch event specification. In the future, we will be able to catch events such as touchstart, touchmove and toucheend. We will be able to deal with these events directly in JavaScript without requiring a third-party framework such as Hammer.js or jGestures. But JavaScript is one thing — what about CSS?

CSS Level 4 “Pointer” Media Query

CSS Level 4 specifies a new media query called “pointer”, which can be used to query the presence and accuracy of a pointing device, such as a mouse. The media query takes one of three values:

  • none
    The device does not have any pointing device at all.
  • coarse
    The device has a pointing device with limited accuracy; for example, a mobile phone or tablet with touch capabilities, where the “pointer” would be a finger.
  • fine
    The device has an accurate pointing device, such as a mouse, trackpad or stylus.

Using this media query, we can enlarge buttons and links for touch devices:


@media  (pointer:coarse) {
   input[type="submit"],
       a.button {
       min-width: 30px;
       min-height: 40px;
       background: transparent;
   }
 }

The pointer media query is not yet supported and is merely being proposed. Nevertheless, the potential is huge because it would enable us to detect touch devices via CSS, without the need for a third-party library, such as Modernizr.

CSS Level 4 “Hover” Media Query

The CSS Level 4 specification proposes a new hover media query, which detects whether a device’s primary pointing system can hover. It returns a Boolean: 1 if the device supports hover, 0 if not. Note that it has nothing to do with the :hover pseudo-class.

Using the hover media query, we can enhance an interface to hide certain features for devices that do support hovering. The code would look something like this:


 @media  (hover) {
   .hovercontent { display: none; } /* Hide content only for devices with hover capabilities. */

   .hovercontent:hover { display: block; }    
 }

It can also be used to create dropdown menus on hover; and the fallback for mobile devices is in native CSS, without the need for a feature-detection framework.

CSS Level 4 Luminosity Media Query

Another capability of mobile devices is the luminosity sensor. The CSS Level 4 specification has a media query for luminosity, which gives us access to a device’s light sensors directly in the CSS. Here is how the specification describes it:

“The “luminosity” media feature is used to query about the ambient luminosity in which the device is used, to allow the author to adjust style of the document in response.”

In the future, we will be able to create websites that respond to ambient luminosity. This will greatly improve user experiences. We will be able to detect, for example, exceptionally bright environments using the washed value, adapting the website’s contrast accordingly. The dim value is used for dim environments, such as at nighttime. The normal value is used when the luminosity level does not need any adjustment.

The code would look something like this:


 @media  (luminosity: washed) {
   p { background: white; color: black; font-size: 2em; }
 }

As you can see, CSS Level 4 promises a lot of fun new stuff. If you are curious to see what’s in store, not only mobile-related, then have a look at “Sneak Peek Into the Future: Selectors, Level 4.”

More Mobile Capabilities to Detect Using APIs and JavaScript

Many other things could be detected to make the user experience amazing on a responsive website. For example, we could gain access to the native gyroscope, compass and accelerometer to detect the device’s orientation using the HTML5 DeviceOrientationEvent. Support for DeviceOrientationEvent in Android and iOS browsers is getting better, but the specification is still a draft. Nevertheless, the API look promising. Imagine playing full HTML5 games directly in the browser.

Another API that would be particularly useful for some mobile users is geolocation. The good news is that it’s already well supported. This API enables us to geolocate the user using GPS and to infer their location from network signals such as IP address, RFID, Wi-Fi and Bluetooth MAC addresses. This can be used on some responsive websites to provide users with contextual information. A big restaurant chain could enhance its mobile experience by showing the user the locations of restaurants in their area. The possibilities are endless.

The W3C also proposed a draft for a vibration API. With it, the browser can provide tactile feedback to the user in the form of vibration. This, however, is creeping into the more specific field of Web applications and mobile games in the browser.

Another API that has been highly discussed is the network information API. The possibility of measuring a user’s bandwidth and optimizing accordingly has seduced many developers. We would be able to serve high-quality images to users with high bandwidth and low-quality images to users with low bandwidth. With the bandwidth attribute of the network API, it would be possible to estimate the downloading bandwidth of a user in megabytes per second. The second attribute, metered, is a Boolean that tells us whether the user has a metered connection (such as from a prepaid card). These two attributes are currently accessible only via JavaScript.

Unfortunately, measuring a user’s connection is technically difficult, and a connection could change abruptly. A user could go into a tunnel and lose their connection, or their speed could suddenly drop. So, a magical media query that measures bandwidth looks hypothetical at the moment. Yoav Weiss has written a good article about the problems that such a media query would create and about bandwidth measurement, “Bandwidth Media Queries? We Don’t Need ’Em!

Many other APIs deal with mobile capabilities. If you are interested in learning more, Mozilla has a very detailed list. Most are not yet fully available or standardized, and most are intended more for Web applications than for responsive websites. Nevertheless, it’s a great overview of how large and complex mobile websites could get in future.

Rethinking The Way We And The User Deal With Content

From a technical perspective, there are still a lot of challenges in dealing with content at a global scale. The mobile-first method has been part of the development and design process for a little while now. We could, for example, serve to mobile devices the minimum data that is necessary, and then use JavaScript and AJAX to conditionally load more content and images for desktops and tablets. But to do this, we would also have to rethink how we deal with content and be able to prioritize in order to generate content that is flexible enough and adaptive. A good example of this is the responsive map solution described above: we load an image for mobile, and enhance the experience with a real map for desktops. The more responsive the website, the more complex dealing with content gets. Flexible code can help us to format adaptive content.

One way suggested by some people in the industry is to create responsive sentences by marking up sentences with a lot of spans that have classes, and then displaying certain ones according to screen size. Trimming parts of sentences for small devices is possible with media queries. You can see this technique in action on 37signals’ Signal vs. Noise blog and in Frankie Roberto’s article “Responsive Text.” Even if such technique could be used to enhance small parts of a website, such as the footer slogan, applying it to all of the text on a website is hard to imagine.

This raises an issue in responsive Web design that will become more and more important in future: the importance of meta data and the semantic structure of content. As mentioned, the content on our websites does not only come from in-house writers. If we want to be able to automatically reuse content from other websites, then it has to be well structured and prepared for it. New HTML5 tags such as article and section are a good start to gaining some semantic meaning. The point is to think about and structure content so that a single item (say, a blog post) can be reused and displayed on different devices in different formats.

The big challenge will be to make meta data easily understandable to all of the people who are part of the content creation chain of the website. We’ll have to explain to them how the meta data can be used to prioritize content and be used to programmatically assemble content, while being platform-independent. A huge challenge will be to help them start thinking in terms of reusable blocks, rather than a big chunk of text that they copy and paste from Microsoft Word to their WYSIWYG content management system. We will have to help them understand that content and structure are two separate and independent things, just as when designers had to understand that content (HTML) and presentation (CSS) are best kept separate.

We can’t afford to write content that is oriented towards one only platform anymore. Who knows on which devices our content will be published in six months, or one year? We need to prepare our websites for the unexpected. But to do so, we need better publishing tools, too. Karen McGrane gave a talk on “Adapting Ourselves to Adaptive Content,” with some real example from the publishing industry. She speaks about the process of creating reusable content and introduces the idea of COPE: create once and publish everywhere. We need to build better CMSes, ones that can use and generate meta data to prioritize content. We need to explain to people how the system works and to think in terms of modular reusable content objects, instead of WYSIWYG pages. As McGrane says:

“You might be writing three different versions of that headline; you might be writing two different short summaries and you are attaching a couple of different images to it, different cut sizes, and then you may not be the person who is in charge of deciding what image or what headline gets displayed on that particular platform. That decision will be made by the metadata. It will be made by the business rules. […] Metadata is the new art direction.”

Truncating content for small devices is not a future-proof content strategy. We need CMSes that provide the structure needed to create such reusable content. We need better publishing workflows in CMSes, too. Clunky interfaces scare users, and most people who create content are not particularly comfortable with complicated tools. We will have to provide them with tools that are easy to understand and that help them publish clean, semantic content that is independent of presentation.

Conclusion

As long as this article is, it only scratches the surface. By now, most of Smashing Magazine’s readers understand that responsive Web design is much more than about throwing a bunch of media queries on the page, choosing the right breakpoints and doubling the size of images for those cool new high-density phones. As you can see, the path is long, and we are not there yet. There are still many unsolved issues, and the perfect responsive solution does not exist yet.

Some technical solutions might be discovered in future using some of the new technologies presented here and with the help of the W3C, the WHATWG and organizations such as the Filament Group.

More importantly, we Web designers and developers can help to find even better solutions. People such as Luke Wroblewski and Brad Frost and all of the amazing women and men mentioned in this article are experimenting with a lot of different techniques and solutions. Whether any succeeds or fails, the most important thing is to share what we — as designers, developers, content strategists and members of the Web design community — are doing to try to solve some of the challenges of responsive Web design. After all, we are all in the same boat, trying to make the Web a better place, aren’t we?

(al) (ea)

© Stéphanie Walter for Smashing Magazine, 2013.

0
Your rating: None

The iPad may have started it, but the high resolution screen will soon be the norm. Photo: Ariel Zambelich/Wired.com

The rise of high-resolution screens means that web developers need resolution-independent graphics or images look blurry. For photographs responsive images may be the solution, but for simpler graphics like logos and icons there’s an easy solution that’s been with us for some time — Scalable Vector Graphics or SVG.

A slightly blurry icon or logo on a retina display probably isn’t going to drive your visitors away, but if it’s easy to fix and can potentially save you some bandwidth as well, why not?

Historically, browser support for SVG has not been particularly good, but these days SVG images work just about everywhere, except older versions of IE. Thankfully it isn’t hard to serve up regular old PNG files to older versions of IE while keeping the resolution-independent goodness for everyone else.

Developer David Bushell recently tackled the topic of SVG graphics in a very thorough post titled A Primer to Front-end SVG Hacking. Bushell covers using SVG graphics in image tags, stylesheets, sprites and even the old-school <object> method. He’s also got a great list of external resources, including SVGeezy for IE fallback, the SVG Optimizer for saving on bandwidth and grunticon which converts SVG files to PNG and data URIs for fallback images.

Head on over to Bushell’s site for more details and you can check out some of our previous posts on SVG for even more resources.

0
Your rating: None

A handful of the many screens your responsive designs must handle. Photo: Ariel Zambelich/Wired.com

Building responsive websites can be daunting. After all, instead of just one desktop layout you’re creating at least two, probably three or even four layouts to handle different breakpoints and screen sizes. That means considerably more work, which can feel overwhelming if you don’t have a good plan of attack.

One of the better plans I’ve seen recently comes from developer David Bushell, who recently outlines 5 Tips for Responsive Builds. Among his suggestions there are two standouts, the first being “utilize breakpoint zero.” For Bushell “breakpoint zero” just means “start by writing HTML in a semantic and hierarchical order. Start simple, with no CSS at all and then “apply the basic styles but don’t go beyond the default vertical flow.”

In other words, keep your layout slate blank as long as you can so that when you do start adding layout rules you can spot problems with different breakpoints early and fix them before changing things becomes a major headache.

The other highlight of Bushell’s post is the suggestion that you maintain a CSS pattern library — reusable snippets of CSS you can drop in for quick styling. There are a ton of ways you can do this, whether it’s something formal like SMACSS (pronounced “smacks”), OOCSS, or just taking the time to write a style guide with some sample code. The point isn’t how you do it or which method you use, but that you do it.

Be sure to check out Bushell’s post for more details on these two suggestions as well as the other three ways you can help make your responsive design process a bit smoother.

0
Your rating: None

  

As a Japanese person living in Europe, I’m sometimes asked: “Japanese is a difficult language, isn’t it?” Those asking are often surprised when my answer is a simple: “No, actually, it’s not.”

While it is true (at least to many Westerners) that Japanese is an exotic language, when compared to learning other European languages, it may seem harder because it has has no relation to their own language. But from my own experiences of learning English and German (and also from seeing some European friends learning Japanese), I can say with confidence that learning spoken Japanese is, in fact, not so difficult. The grammar is in many ways simpler than most European languages. Take for example the fact that we don’t have cases, grammatical genders, nor articles. However, reading and writing in Japanese is… well, not so simple.

While discussing typography we most often focus on English language problems, which is only natural considering that the majority of design material is written in English. However, a lot can be gleamed by looking at how other languages are used as part of communication and design — it helps to lend context and a different point of view.

Japanese Scripts

Modern Japanese is written in a mixture of three basic scripts: Kanji — which are Chinese ideographic symbols — as well as Hiragana and Katakana — two phonetic alphabets (syllables). There are a few thousand Kanji characters, while Hiragana and Katakana have 46 each. Although there is a basic rule for when to use which script, there are many exceptions, and what’s worse is that words written in Kanji have often multiple pronunciations, depending on the context or conjunction. This is hard enough for native speaker to get right every time, so I almost feel sorry for those non-natives who are learning to read and write Japanese.

Kanji, Hiragana and Katakana Japanese scripts
From top to bottom: Kanji is mainly used for the lexical elements: nouns, verb stems, adjective stems, and so forth; Hiragana has rounded letter shapes, which are mainly used for the grammatical elements of sentences such as particles, auxiliary verbs, and suffixes of nouns; Katakana has an angular letter shape, which is most often used for foreign words and also for the purpose of emphasis.

Some say that the “tragedy” started when Japan decided to “import” the Chinese writing system, inscribing it into their own language in the 3rd century.

Since Japanese is as different from Chinese as it is to any other language, simply using the Chinese writing system was not sufficient, and a more appropriate way of writing Japanese was sought out. Some Chinese characters began to be used not for their meaning, but purely for their phonetic value. So by the 9th century, Hiragana and Katakana scripts were derived from simplified Chinese characters that were used to write Japanese phonetically.

The story doesn’t end there. As if using three scripts isn’t enough, we write in both horizontal and vertical orientation.

Horizontal? Vertical? The Unique Case Of Japanese Typography

“Vertical or horizontal?” — when setting a piece of text in Japanese, this is a question that Japanese designers constantly need to ask themselves. Being able to use both vertical and horizontal writing orientations is something so normal for us native Japanese speakers that most of us won’t even stop to wonder why this is possible, or even when and how it was first introduced.

The identical piece of text set vertically (right) and horizontally (left).
The identical piece of text set vertically (right) and horizontally (left). When it is set vertically it’s read from top to bottom, as the lines go from right to left; when it is set horizontally, it is read from left to right, like in European languages.

In general, these two writing orientations have a clear usage: vertical for something “Japanese”, “traditional”, “novels and other humanistic writings”; horizontal for “contemporary”, “business documents”, “scientific & foreign language related writings” and so on. When a main text is set horizontally, the binding is on the left-hand side, and pages progress to the right, like books in Latin scripts. Traditional books in vertical setting are the other way around, with the binding at the right hand side, and pages progressing to the left. So when you handle a Japanese book, don’t confuse the front with the back!

A typical page layout of a Japanese paperback novel
A typical page layout of a Japanese paperback novel using a vertical setting. Ogai Mori (1913), “Abe Ichizoku”, Shincyo-bunko.

traditional calligraphy is always done vertically
With its organic flow, characters are often connected and have different heights and widths
Needless to say, traditional calligraphy is always done vertically. With their organic flow, characters are often connected and have different heights and widths — which makes it impossible to disconnect and align them horizontally. Calligraphy by Keiko Shimoda, 2011 (tsukushidesign.com)


Horizontal setting is preferred for scientific texts, mathematical texts and language related books, where words and phrases in foreign scripts and signs are often included, as they are more easily incorporated horizontally. The example (above) is a Japanese-English dictionary. (Pocket Comprehensive English-Japanese / Japanese-English Dictionary, 2000, Obunsha)

Where the efficient use of space is important — namely newspapers and magazines — both orientations are often combined. Although it may appear a bit chaotic, or even random to foreign eyes, these two directions are usually used in a systematic way as a means to indicate different text elements on a page. For instance, a main text is often set in a vertical setting, but headings and captions may be set in a horizontal setting.

A typical newspaper layout
A typical newspaper layout — the main text is vertical but headings, diagrams, tables, and captions are placed horizontally.

The same newspaper as above, but highlighting the vertical text (orange) and the horizontal text
The same newspaper as above, but highlighting the vertical text (orange) and the horizontal text (blue). © The Nikkei (May 8th, 2009)

In a way, it’s comparable to “typographic variants” which are found in Latin typography — in Latin script text one may use bold, italic, or a different font to differentiate things such as pull quotes from the main text, whereas in Japanese we can do this by using a different orientation. Publications which accommodate non-linear or complex text (as opposed to linear text, such as novels) seem to benefit in particular from having these two orientations, which allow the layout to be highly flexible, and also to create strong visual impact.

The extreme cases of “space-efficiency-oriented typography” are informational-heavy pieces of text, such as diagrams and signage — also exploiting the two directional orientations. The Tokyo Metro map (Fig 10) is a good example of this — as you can see, both orientations are used accordingly, so that everything fits best within the limited space.

Tokyo Metro Map.
Tokyo Metro map

Tokyo Metro map with more typography in differing directions.
Tokyo Metro route map. The large type on the top is the station name which is placed horizontally. The name of the metroline may be horizontal, but the name of the stops are placed vertically.

It’s true that in many cases they look quite chaotic and sometimes even aesthetically questionable to eyes that are used to “orderly” design. But it’s easy to appreciate the visual impact and energy they create — they remind you that effective, appealing informational design does not always have to look “neat and tidy”.

Letters from my friends
Letters from my friends: when it comes to handwriting, orientation is up to a personal preference or simply one’s “mood”. But when you are writing a more official letter, or writing to somebody who is much older than you, it’s probably safer to opt for vertical orientation.

What’s Happening On Screen-Based Media?

Since the introduction of horizontal writing in the Japanese language, print-based media and signage have been employing both of these writing orientations effectively, and in ways that complement one another. But what’s been happening to screen-based media? With a few exceptions — such as word-processing machines made exclusively for the Japanese text output, or subtitles for film and TV screens, which tend to use either depending on the background image — horizontal orientation has been the dominant choice.

The prime example of this is the Web: horizontal orientation has been used almost exclusively. For the past 15 years, I have hardly come across a website that uses vertical setting. Mobile phone screens also use a horizontal orientation. I believe this may be due to the relations of hardware, operating systems and user interfaces that have become the norm, all of which have been designed to work with horizontal writing. It feels somewhat awkward to see vertical writing while all the other elements on the screen, such as the menu bar and UI elements, are horizontal.

Needless to say, the technical limitations (the support of a vertical setting by browsers is a fairly recent introduction) have largely contributed to this too. Perhaps underestimated, maybe the biggest factor for not using vertical setting for screen-based media could well be the mental association with horizontal orientation being used for something “modern” and “contemporary”.

The Nihon Keizai Newspaper website.
The Nihon Keizai Newspaper website. Although the printed newspaper employs a vertical setting for the body texts, the web-version uses a horizontal setting.

A Japanese Tea Ceremony website
So far, even with content as Japanese as a tea ceremony, a website will use a horizontal setting. (Accessed Jan. 20th, 2012)

Will Vertical Writing Orientation Die Out?

Will vertical writing orientation die out from screen-based media? Or can it make a comeback, when the technological environment allows us to use vertical settings more easily? Many e-book apps on smart phones and tablets have already started using vertical settings. With its intuitive way of navigating the screen along with the lack of external input devices (and apps being able to have more flexible/responsive layout), vertical writing seems to be incorporated much more comfortably.

I’ve spent some time reading these e-books — and pleasantly surprised at how easy they are to read. Apart from the fact that you need to scroll the screen horizontally, it’s just as comfortable as reading “normal” or horizontally set text. In fact, it’s even better for some types of publications like novels, or Manga. Our association towards this type of content when compared to the vertical setting is pretty strong mdash; it would somehow feel “wrong” to see them set horizontally.

Amazon’s Kindle has yet to support the Japanese language, but apparently they’re on their way to doing so. If they seriously want to attract Japanese readers, it would be unthinkable for them not to support vertical setting.

Soseki Natsume's “Sanshiro”
Soseki Natsume’s “Sanshiro” (1908) e-book on iPhone.

Kotobuki Shiriagari's
Kotobuki Shiriagari’s “OSHIGOTO” (2010) e-book on iPhone.

The situation also seems to be slowly changing on the Web — some interesting attempts have been made in order to familiarize ourselves with Web pages that have vertical setting. One such example is Taketori, which works just like Google translate — you can type in the URL of a Web page you wish to see in vertical setting, and Taketori does it for you. There’s also a piece of software called Kagetaka, which can switch any Web text into a vertical orientation.

Personally, I’m not too sure how well vertical setting will be supported by the users of normal Web pages, unless the way we navigate Web pages is re-developed, or a new type of browser with more innovative UI appears. Even though I complained earlier about the difficulty of the Japanese writing system, I do appreciate its diversity and flexibility, while making use of its three scripts and two orientations allows us to express subtle nuances of content — and we have been benefiting from that for decades.

I thought it would be a shame if we lose these methods of textual articulation in an age of screen-based media. But what has been happening for the last couple of years on touch-screen mobile devices (as well as the Web) can reassure us that both writing orientations may happily co-exist and collaborate on screen in the future, just as they have done off-screen for the last hundred years.

Feel free to share your thoughts in the comments section below.

(jvb) (il)

© Shoko Mugikura for Smashing Magazine, 2012.

0
Your rating: None

  

In this article, we’ll look at Scalable Vector Graphics (SVG), one of the most underused technologies in website development today.

Before diving into an example, let’s consider the state of the Web at present and where it is going. Website design has found new vigor in recent years, with the evolving technique of responsive design. And for good reason: essentially, responsive website design moves us away from the fixed-width pages we’ve grown accustomed to, replacing them with shape-shifting layouts and intelligent reflowing of content. Add to that a thoughtful content strategy and mobile-first approach, and we’re starting to offer an experience that adapts across devices and browsers to suit the user’s context.

When we look at the breadth of Web-enabled devices, responsive design is sure to provide a better user experience. Scrolling horizontally, panning and zooming the viewport have their place in user interface design, but forcing the user to do these things just to navigate a website quickly becomes tedious. Fitting the website to the viewport is about more than just layout: it’s also about resolution. In this article, I’ll demonstrate why SVG is a perfect addition to future-friendly Web development.

Introducing SVG

SVG offers a truly resolution-independent technique for presenting graphics on the Web. SVG is a vector graphics format that uses XML to define basic properties such as paths, shapes, fonts and colors, and more advanced features such as gradients, filters, scripting and animation. Create the file once and use it anywhere, at any scale and resolution.

Consider the use cases: UI and navigation icons, vector-style illustrations, patterns and repeating backgrounds. For all of these, a scalable graphic is the perfect solution from a visual standpoint, and yet fixed-resolution images are still the norm. In the example below, we’ll show you how to expand on a common development technique to take advantage of SVG.

Resolution independence with SVG

A Case Study: CSS Sprites

We all know about the CSS sprites technique. (If you don’t, then have a quick read through Sven Lennartz’ article. And Louis Lazaris points out its pros and cons.) In the example below, we’ll show how seamlessly SVG replaces normal raster images. If this technique is not for you, you can certainly imagine a whole array of similar situations in which to use SVG.

Vector icons play a big role in user interface design. Pictures express concepts with vivid clarity, whereas their textual counterparts might carry ambiguity. In UI design, where space is scarce, a simple illustrated icon could be greatly welcome.

I’ve mocked up the following example:

An icon based UI menu

I’ll be first to admit that this row of icons won’t win any design awards, but it will suffice for the sake of this article! Let’s look at the HTML:

<div class="actions">
   <a class="a-share" href="#">Share</a>
   <a class="a-print" href="#">Print</a>
   <a class="a-tag" href="#">Tag</a>
   <a class="a-delete" href="#">Delete</a>
</div>

I’ve kept the HTML to a minimum for clarity, but in practice you’d probably want to mark it up with an unordered list. And you’ll almost certainly want to replace those hashes with real URLs (even if JavaScript provides the functionality, having a fallback is nice). Let’s look at the CSS:

.actions {
   display: block;
   overflow: auto;
}

.actions a {
   background-image: url('sprite.png');
   background-repeat: no-repeat;
   background-color: #ccc;
   border-radius: 5px;
   display: block;
   float: left;
   color: #444;
   font-size: 16px;
   font-weight: bold;
   line-height: 20px;
   text-decoration: none;
   text-shadow: 0 -1px 2px #fff;
   padding: 10px 20px 10px 40px;
   margin-right: 5px;
}

.a-share  { background-position: 10px 0; }
.a-print  { background-position: 10px -40px; }
.a-tag    { background-position: 10px -80px; }
.a-delete { background-position: 10px -120px; }

Note the fixed-pixel sizing and the PNG background, which we can see below framed in full Photoshop production glory:

A PNG sprite in Photoshop

This implementation of a CSS sprite is basic, and at today’s standard, it’s not good enough! How can we enhance this? First, let’s consider the following issues:

  1. We’ve rasterized the image at a very early stage. Even at full size, icons in which points sit between pixels, such as the one for “Print,” have blurred.
  2. If we zoom in, the image will blur or pixellate even more; there is no additional data to re-render the image at larger sizes.
  3. Everything has a fixed size, which is neither good for responsive design nor good for accessibility, because the browser’s default font size is ignored.

As you’ve probably guessed by now, we’ll show you how SVG solves these problems. But first, let’s reiterate each point thoroughly to understand the issues at large.

1. Rasterization

Devices such as modern smartphones have a very high pixel density; some already surpass the 300 pixels-per-inch (PPI) mark that is assumed to be the limit of the human eye’s ability to distinguish fine details. A pixel has no real-world equivalent in size until it sits on a screen of fixed dimension (say, 3.5 inches diagonally) and fixed resolution (say, 640 × 960 pixels). At this scale, text with a font size of 16 pixels would be incredibly small to the eye. For this reason, devices simply cannot translate 1 CSS pixel unit to 1 device pixel; instead, they double up. Thus, a 16-pixel font size actually takes over 32 pixels when rendered.

The same applies to images; but they are already rasterized, so doubling up the pixels has no benefit. In our example, each icon has been rasterized at around 25 × 25 pixels (the whole sprite being 30 × 160), so they cannot take advantage of the double pixel ratio. One solution is to use CSS media queries to detect the pixel ratio. This is already implemented in Webkit- and Gecko-based browsers.

To improve our example, we can add the following CSS declaration:

@media only screen and (-webkit-min-device-pixel-ratio: 2)  {
   .actions a {
      background-image: url('sprite@2x.png');
      background-size: 30px 160px;
   }
}

The alternate background image supplied in the code above has been saved at 60 × 320 pixels (i.e. double the original dimensions). The background-size property tells CSS to treat it smaller. Significantly, now the device has the additional data to render a better image (if capable).

This solution isn’t bad, but it doesn’t solve the problems we’ll run into in points 2 and 3 below. It also requires that we maintain multiple files of increasing size: a potential burden on bandwidth and a real hassle. For non-vector images, such as photography in JPG format, we can’t do much more than that.

2. Zooming

At their default size, our rasterized icons look acceptable, at least on low-pixel-density screens. However, should the user zoom in on the Web page, these little UI delights will degrade very quickly.

A PNG sprite zoomed in and blurred.

Zooming is a common action when users find a website too small for comfortable viewing. Or, to put it another way, websites that are designed too small are very common. There is really no “perfect” size, because almost everyone has at least some level of visual impairment, since our eyes inevitably deteriorate with age. Secondly, with the rapid increase in touchscreen devices, pinch-to-zoom has become the standard way to enlarge fixed-sized content designed for larger screens (i.e. much of the Web today).

We should develop websites in a way that minimizes the need for user input — that’s where responsive design comes in (see point 3 below) — but zooming is here to stay. There’s simply no way to provide pre-rasterized images for every level of zoom (in theory, an infinite scale). Scalable graphics are the solution, and we’ll show you how to enhance our example. But first, a related word on fixed sizing.

3. Fixed Sizes

Presenting page elements at fixed sizes forces many users to zoom, but it also disables a very useful browser feature. Users can set their preferred font size (the default in browsers is 16 pixels). By sizing everything in pixels, we override this preference. Sizing elements based on this default is much better, so that, if the text is bigger, everything adjusts to match. This essentially mimics the zooming effect but happens without the user having to manually do it on every visit. Ethan Marcotte has written a great article that explains relative font sizes.

Let’s re-implement our sprite example with a solution to these three issues.

A Scalable Implementation

Here is the HTML again. We don’t need to change anything here.

<div class="actions">
   <a class="a-share" href="#">Share</a>
   <a class="a-print" href="#">Print</a>
   <a class="a-tag" href="#">Tag</a>
   <a class="a-delete" href="#">Delete</a>
</div>

The updated CSS is where the magic happens:

body { font-size: 100%; }

.actions {
   display: block;
   overflow: auto;
}

.actions a {
   font-size: 1em;
   line-height: 1.25em;
   padding: 0.625em 1.25em 0.625em 2.5em;
   margin-right: 0.3125em;
   border-radius: 0.3125em;
   background-image: url('sprite.svg');
   -webkit-background-size: 1.875em 10em;
   -o-background-size: 1.875em 10em;
   -moz-background-size: 1.875em 10em;
   background-size: 1.875em 10em;
   /* styles carried over from the original implementation */
   background-repeat: no-repeat;
   background-color: #ccc;
   color: #444;
   display: block;
   float: left;
   text-decoration: none;
   text-shadow: 0 -1px 2px #fff;
}

.actions-em .a-share { background-position: 0.625em 0; }
.actions-em .a-print { background-position: 0.625em -2.5em;  }
.actions-em .a-tag { background-position: 0.625em -5.0em;  }
.actions-em .a-delete { background-position: 0.625em -7.5em;  }

In this version, we’ve made the following changes:

  • The background-image is now an SVG file.
  • All sizes are based on the default of 16 pixels, or 1 em. If the user’s default is larger or smaller, then everything will scale relatively. (If you multiple each em size by 16, you’ll get the number of pixels used in our initial fixed-size example.)
  • The background-size is very important. By setting this in em units, we’re telling the browser to scale the sprite relative to everything else. You’ll notice that 1.875 × 10 em multiplied by 16 becomes 30 × 160 — the base size at which we produced the sprite in pixels.
  • The background-position of each sprited icon is also based on relative units.

Now that we’re using SVG and relative sizes, we have solved the three big issues highlighted above. A scalable graphic can be rasterized on demand to perfectly suit any device resolution and any zoom level. By using relative sizes, we can continue implementing a responsive design, minimizing as much as possible the need for the user to zoom. We’re also respecting the browser’s default font size, and enabling our design to adapt accordingly.

I actually produced the SVG sprite first and the PNG version from that. (I imported the SVG in Photoshop before exporting it as a PNG — Illustrator’s PNG export had very poor rasterization.) Below is the header in my SVG file. Notice the same 30 × 160 initial size.

<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
   width="30px" height="160px" viewBox="0 0 30 160" enable-background="new 0 0 30 160" xml:space="preserve">

You can see that the attributes for width and height are set in pixels (width="30px" height="160px") in the opening svg tag (as generated by Adobe Illustrator). This actually causes it to render early in Firefox, before the graphic has scaled to match the em sizes in background-size. Webkit-based browsers seem to scale the SVG perfectly, regardless. I’ve found that editing the SVG file to use em units in these two attributes fixes any rendering issues in Firefox.

<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
   width="30em" height="160em" viewBox="0 0 30 160" enable-background="new 0 0 30 160" xml:space="preserve">

I don’t know which browser actually implements this scaling correctly, but let it be noted that extra care is needed to ensure cross-browser perfection. Mozilla MDN has an excellent in-depth article, “Scaling of SVG Backgrounds,” which explores more practical examples. For more ideas, see Alex Walker’s article “A Farewell to CSS3 Gradients.”

Here’s a super-close screenshot showing the SVG sprite:

A close-up of a SVG sprite.

The sprite scales beautifully. (Sadly, the same can’t be said for my tacky text-shadow effect.)

It’s best to experience the joys of scalable graphics and relative sizing firsthand. I’ve uploaded a side-by-side live demo demonstrating a combination of all the techniques mentioned above.

Browser Support

At the start of this article, I said that SVG was underused. I believe that has generally been the case due to poor browser support. But things are different now! Browser support for SVG has blossomed over the last year to the point where implementing it is a viable use of development time.

According to the website When Can I Use?, support for SVG across multiple implementations is as follows (I’ve combined support for both CSS’ background-image and HTML’s img source — the most useful attributes):

  • Internet Explorer 9+
  • Firefox 4+
  • Chrome 4+
  • Safari 4+
  • Opera 9.5+

Mobile browser support is also pretty much across the board. If a workable fallback exists for older browsers, then SVG is a very viable solution.

For some of the new additions to Web standards, we can implement them safe in the knowledge that old browsers will simply ignore them and that they aren’t even required. We call this “progressive enhancement”: better browsers get a progressively better experience. SVG is slightly different, because for most practical purposes, it simply replaces other images in CSS backgrounds and HTML elements. The image format — be it SVG, PNG, JPG or GIF — is either supported or it isn’t. We can’t simply follow the practice of progressive enhancement here, because an image failing to render is not an acceptable experience.

Browser Sniffing or Feature Detection?

We could make an educated guess and say that we need to worry only about users of Internet Explorer 6 to 8. In this case, the conditional comments technique for IE-only styles enable us to re-apply a second CSS background-image of a supported format such as PNG, instead of the default SVG background.

Browsing sniffing is always a dangerous game. While Internet Explorer tends to be the main offender, we can never assume it is the only one.

The safer and highly recommended option is to detect SVG support and use it only if it’s found. I suggest using Modernizr if you need to detect multiple features. Modernizr applies a class of svg to your root html element if detected (to which you can apply SVG as a background-image). If you’re using SVG as the source of an image element in HTML, then implementation is a little harder. You’ll have to write more JavaScript to find and replace all sources once support has been established.

The problem with these methods is that the browser will download the fallback image before SVG is detected — the only exception being the conditional comments technique for IE. Users will also likely see a flash of re-styled content when the source image changes. This shouldn’t be the case for long; but at least for now, these problems may be enough to hold you off on SVG usage.

File Size

In our sprite example, the raw SVG file was 2445 bytes. The PNG version was only 1064 bytes, and the double-sized PNG for double-pixel ratio devices was 1932 bytes. On first appearance, the vector file loses on all accounts, but for larger images, the raster version more quickly escalates in size.

SVG files are also human-readable due to being in XML format. They generally comprise a very limited range of characters, which means they can be heavily Gzip-compressed when sent over HTTP. This means that the actual download size is many times smaller than the raw file — easily beyond 30%, probably a lot more. Raster image formats such as PNG and JPG are already compressed to their fullest extent.

Performance

Rendering performance is a concern with SVG, especially on mobile devices, whose hardware is limited. Raster images can be rendered pixel for pixel after decompression and de-encoding. Vector graphics need to be rasterized at a specific resolution every time they’re viewed.

SVG has consistently proved slower than Canvas as a platform for animating vector graphics; but our concern here is basic rendering, not manipulation a thousand times per second, and if that is possible, then simple rendering shouldn’t be a concern. The more intensive SVG features are things like clipping masks and filter effects. These are unnecessary for many practical purposes (like our sprite example), but, if required, the best way to check performance is by testing. A lot of Web development is supported in theory, but in practice results are far from perfect.

Alternative Methods

Hopefully you agree that SVG is extremely useful but not always the ideal solution to resolution independence. Ultimately, the trick is to avoid raster images while maintaining the scalability of visual styles. Below are a few more ideas to think about.

CSS3

You’ve probably already started combining CSS3 properties such as linear-gradient, text-shadow and box-shadow to create more complex styles. Web developer Lea Verou curates a CSS3 pattern gallery that shows off the impressive potential of gradients alone.

CSS3 gradient patterns

In his article “Mobile Web in High Resolution,” Brad Birdsall introduces a technique to maintain pixel perfection for high-resolution displays using the pixel-ratio property.

Then there are pure CSS “icons,” which Faruk Ateş rightly points out as being absolute “madness” — certainly so if you’re using CSS to create a logo! But you could argue the benefits of a small handful of very specific techniques, such as CSS triangles, as demoed by Chris Coyier.

Web Fonts

Dingbat Web fonts and look-a-like Unicode glyphs are two interesting alternatives for vector icons, both with accessibility and semantic challenges. Jon Hicks has a write-up of perhaps the best practice for this. SVG seems a more appropriate technique for icons, but both have an immediate visual impact at high resolutions — and we’ll be paying increasing attention to that in coming years.

Looking Forward

As you can see, SVG usage is very much a possibility, and browser support and performance will only improve in future. What’s important to note from this article is that we really should be building websites that are as resolution-independent as possible.

Consider the “one Web” philosophy and the vast range of devices we use to access it — there is no single user experience. The more we can do to stay device-agnostic, the better. Responsive website design addresses many of these needs and certainly provides many benefits. Using vector graphics may not be as apparent, but its little improvements really do make a difference.

With today’s level of support, many users can experience the beauty of crisp scalable graphics… or perhaps that’s the wrong way to think about it. Most users won’t say “Wow! Kudos on the vectors.” To our dismay, they probably wouldn’t even consider them (and certainly wouldn’t recognize the effort required to craft them). And that’s a good thing; each time we improve the user’s experience, we don’t necessarily need to make a song and dance about it. Letting things continue to grind away under-appreciated is OK. It’s the lack of such things that gets recognized and sniffed at. Raise the user’s expectations in visual aesthetics, and they’ll start to notice the websites that do look shoddy. If you don’t do it, others will.

(al)

© dbushell for Smashing Magazine, 2012.

0
Your rating: None

  

The Web is full of creative and practical resources that we can use to improve our projects. Photography, fonts, music and code are perfect examples. Finding stock objects and existing implementations is often quicker, cheaper and more practical than producing your own.

Whether free or not, these resources normally come with a license to ensure fair use. For professionals, understanding the limitations of a license is critical; with this knowledge, you’d be surprised by what’s available. Understanding copyright and licenses allows us to do what we do best: be creative.

Copyright in Understanding Copyright And Licenses

In this article, we’ll cover the basic principles that govern copyright and licenses. We’ll then explore common licenses in our industry, with examples. We’ll cover the following:

Quick disclaimer: I am not a lawyer! This is not legal advice, only the results of my own research. Please always read the entire license of any resource you use.

Copyright And Licensing

When we create something — let’s say a photograph — we own the copyright, which is our exclusive right as the author to own that work. We control who else can use our work and in what manner. For example, I could allow someone to print my photograph or adapt it in a piece of art. Rather than establishing verbal agreements, I can distribute my work with a license that sets the guidelines for use. The things that are copyrighted are sometimes referred to as “intellectual property.”

Licenses are granted by an authority to allow a usage; in my case, the use and distribution of resources by the copyright owner (i.e. me). I may decide to offer my photograph for free or charge a price; either way, I can include a license to limit usage, and I maintain the copyright. Just because someone pays money doesn’t mean they have full control or rights to what they’re buying. Licenses can dictate the number or uses, the bounds of use and even the length of time until the license expires.

Moreover, under “work for hire,” the employer holds the copyright, not the author or creative; in many cases, this is a company (such as a creative agency) or its client (by contractual agreement). In such cases, the creator retains “moral rights” to their work, including the right of attribution. This is partly why published articles refer to the author, although moral rights can include anonymity.

Copyright laws are incredibly complex, but this should be a good start.

What Is “Fair Use”

“Fair use” is an exception to the exclusive rights held by the copyright owner. It exists in some countries such as the US and UK. Under it, in certain cases, using work without permission is possible. If someone’s usage is defined as fair use, then they don’t need to obtain a license. Essentially, using copyrighted material is a legal right. Examples of fair use might include:

  • Educational purposes, such as teaching and student research;
  • Making commentary and criticism as part of a news report or published article.

There’s a misconception that noncommercial or nonprofit use is always acceptable. It isn’t. Fair use is a legal term and is judged case by case. Always research thoroughly if you think your use of copyrighted material is legal.

What Is “Public Domain”

Work that falls in the “public domain” basically has no copyright owner. You can use, modify and redistribute it to your heart’s content. An author can forfeit their copyright and, thus, put their work in the public domain (although it’s not quite that easy, as we’ll see later). Copyright ownership expires after the author’s death (generally 50 to 70 years after death in most countries).

Legal Jurisdiction

Every country has its own interpretation of copyright law, but there are many agreements between nations. Licenses are enforced under copyright law, which is different than contract law. The distinction here is questionable within certain jurisdictions, each of which applies the law differently.

The Berne Convention (for the Protection of Literary and Artistic Works) was established in 1886 and is an international agreement that governs copyright. It states that each member state must recognize the copyright of work from other countries, and it must extend the same rights to foreign work that it gives to those of its own citizens. It also makes clear a minium standard of protection for copyright owners. To date, 164 countries have signed this agreement.

Licenses can be limited to certain jurisdictions. So, while something may be free in one country, the copyright owner could reserve all rights in other countries.

If you’re reading this, I can guess pretty confidently that you work on the Web and that you are, or will be, purchasing licenses from copyright owners in different countries. These licenses are bound by the laws of those countries, and you must respect them.

We’re getting into political and legal territory here. Remember: if in doubt, get legal advice.

License Terminology

A license can be written from scratch, but most people choose a well-known one. We’ll cover the common licenses that relate to our industry of website design and development, specifically those that allow for free usage — “free,” meaning that no money is required. Generally, licenses that govern paid resources are written individually, but all licenses have commonalities.

There is obviously a fundamental difference between, say, development code and stock photography. So, it should come as no surprise that a range of licenses exist. Each is tailored to the usage. Before we dive into them, let’s go over some common terminology:

  • Copy
    A simple copy of the original work.
  • Modify
    To alter copyrighted work in some way before using it.
  • Derivative work
    The result of modifying copyrighted work to produce new work.
  • Distribute
    The act of giving someone your work under a license.
  • Redistribute
    The act of distributing work and its license after obtaining it under license from the original copyright owner.
  • Share alike
    Permission to distribute derivative work under the same or a similar license.
  • Credit” or “attribution
    The act of identifying the original copyright owner.
  • Copyright notice
    A written phrase or symbol (©) informing of copyright ownership (not necessarily required by law).
  • All rights reserved
    A common copyright notice declaring that no usage rights exist (again, not necessarily required).
  • Warranty
    A written guarantee included with the license (or, usually, not).

With this in mind, let’s start with the creative licenses.

Creative Commons

Lawrence Lessig founded Creative Commons (CC) in 2001 to create a series of easy-to-understand copyright licenses for online creative work. These licenses established the notion of “some rights reserved.”

The Creative Commons license has six variations. It’s really a collection of licenses that cover particular uses. These include whether the licensed work can be used commercially, whether it can be modified, and whether derivative work can be redistributed under the same (or a compatible) license. A Creative Commons license can be restricted to certain jurisdictions or apply internationally.

Creative-commons-license in Understanding Copyright And Licenses

The basic Creative Commons license is CC Attribution. It allows for all copying, modification and redistribution (even commercially), provided that the original author is attributed (with no implication of endorsement). Work under CC Attribution is essentially free to use.

The CC Attribution license can be extended to CC Attribution-ShareAlike. The same rules apply, except that all derivative work must be licensed the same way. This distinction ensures that all resulting work remains free. Wikipedia uses this license for its text.

Here are the four other Creative Commons licenses:

  • CC Attribution-NoDerivs
    Redistribution is allowed, provided that attribution is given and no modifications are made.
  • CC Attribution-NonCommercial
    Everything is allowed with attribution, provided that it is not done commercially.
  • CC Attribution-NonCommercial-ShareAlike
    The same as above, but derivative work must be under the same license.
  • CC Attribution-NonCommercial-NoDerivs
    Redistribution is allowed for noncommercial use and without any modification.

As you can see, the Creative Commons licence has six separate versions, all of which at least require attribution to the copyright owner.

You should attribute by citing the title of the work, the copyright notice, the author’s name and the license name. For example:

This work includes the photo “Photo’s Title,” available under a Creative Commons Attribution license, © Author’s Name.

If the original work includes a copyright notice, it must be left intact. Otherwise, you are free to attribute appropriately. Also, link to the work and license if possible. Informing the author is courteous but not required.

CC0 also exists. It enables copyright owners to waive all of their rights. It’s essentially a way of saying that the work is in the public domain and that there are “no rights reserved.” The concept exists because many jurisdictions don’t have a clear process for putting work in the public domain, and many legal systems actually prohibit the surrendering of lawful rights such as copyright ownership.

The Creative Commons licenses are clear and readable. As mentioned, Wikipedia uses the Attribution-ShareAlike. Flickr makes it easy for users to select one of the CC licenses, and it’s a great source of photography for your projects. You can even search Google for Creative Commons content.

Software Licenses

Written code is copyrighted: you own what you write. Of course, the simplest line of code, like print('Hello World!');, can be rewritten totally independently, without knowledge of the original author, and both parties will own the copyright of their own version (however worthless it may be). But beyond a few lines, code does become valuable, and distributing it with a license is important.

Other intellectual property laws, such as patents, can also protect software. Software patent laws are hotly debated in the US, where they are granted. In many other countries, such as the UK and New Zealand, software cannot be patented. While copyright is a right, patents must be granted.

Software licenses cover the use of programming code. If you’re using a third-party library or elements from an open-source project, your usage must respect the relevant license.

Development licenses generally cover the following points:

  • How the work and modifications of it can be distributed,
  • Whether any derivative work must be made open source,
  • What copyright and other notices are required for redistribution.

Software licenses can be defined as “permissive” or “copyleft.” The latter removes the right to add further license restrictions upon redistribution.

Below is a quick rundown of common software licenses and how they’ve evolved over the decades.

MIT License

The MIT license is perhaps the most open of all. It effectively puts the work in the public domain. It explicitly gives permission, “without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sub license, and/or sell copies of the Software.” The only condition is that the full copyright notice (which declares no warranty or liability) be included. Work released under the MIT license can be used for anything, including commercial and proprietary software.

BSD License

The BSD license is similar to the MIT license.

The original version, published in 1990, had four clauses, the last being an “advertising clause” stating that all promotional material for derivative work had to refer to the original source. This was later removed in 1999 in the “New BSD” or “Modified BSD” license.

What separates the newer three-clause BSD license from the MIT license is a clause stating that the name of the original copyright owner cannot be used to endorse any derivative work without prior permission. This eliminates any doubt about the right to use the person or organization’s name. Whether this clause is even required is debatable, because copyright and trademark laws are separate issues. Even though the MIT license does not declare this, we cannot assume permission of endorsement.

An additional two-clause “FreeBSD” or “Simplified BSD” license exists, which omits this endorsement clause and instead includes a disclaimer to disassociate any views made in derivative work from the original copyright owner. This can be seen as explicitly stating the opposite of an endorsement.

Both the MIT and BSD licenses give us complete freedom to copy, distribute and modify work for any purpose, provided that the original license and copyright notice are included. Derivative work can be released under another license or as proprietary software.

The Apache License

You can see from the BSD example just how difficult it is to word a license. There are so many ambiguities and connections to other laws that getting the point across is nearly impossible. Many more essentially “free” licenses have appeared in an attempt to make such intention clear.

The Apache License is a free software license that does not require the same license of derivative work. This means that code under the license can be used in open, free and proprietary software (like the MIT and BSD licenses).

Apache Logo-screenshot1 in Understanding Copyright And Licenses

It imposes the conditions that in any licensed file, all original copyright, attribution and trademark notices must be preserved. Additionally, with any modified work, a notice of change must be included. Any existing notices of change must also be kept. All of these notices must be distributed in a text file and in the source code or documentation.

This requirement to preserve modification notices makes the Apache license different from the MIT and BSD licenses. It also includes many more legal terms and conditions that (among other purposes) dissolves any liability of the original copyright owner.

The Apache license (version 2) is said to be GPL-compatible, meaning that a project containing code licensed under both must also be licensed under GPL version 3.

GNU General Public License

First written by Richard Stallman in 1989, the General Public License (GPL) is now at version 3 as of 2007. It was founded on the principle that we should be free to use, change, share and share changes to free software. No matter how the software is distributed, it remains free. This concept is called “copyleft.”

The basic principles of the GPL mean that, unlike the MIT, BSD and Apache licenses, work under GPL must remain under this license. GPL code can be sold, but no proprietary software can be derived from it. If you distribute any derivative work, then your source code must be made available under the same license. Essentially, once a work is released under the GPL, it remains GPL and no further restrictions can be applied.

Version 3 of the GPL specifically states that while code under the GPL can be used to implement digital rights management (DRM), using GPL code does not count as effective “protection,” and as such, anyone who breaks it cannot be help accountable under digital rights law.

Where Licenses Are Used

We already know that Wikipedia uses the Creative Commons Attribute-ShareAlike license and that Flickr allows users to choose a Creative Commons license. What else should we know?

Most JavaScript libraries are available under license by nature. jQuery, for example, is available under dual license: either MIT or GPL v2. Other libraries are available under MIT, such as Modernizr (which is also under BSD), Raphaël and Respond.js (also under GPL v2). You can use all of these libraries while reserving rights for your own derivative work, provided that you include the relevant copyright notices for these libraries.

Plug-Ins and Themes

WordPress and Drupal are important ones to note because they’re available only under GPL v2. This means that any derivative work must also be licensed under GPL; and according to the WordPress license page, this includes all plug-ins and themes:

Part of this license outlines requirements for derivative works, such as plugins or themes. Derivatives of WordPress code inherit the GPL license. […] There is some legal grey area regarding what is considered a derivative work, but we feel strongly that plugins and themes are derivative work and thus inherit the GPL license. If you disagree, you might want to consider a non-GPL platform…

Drupal’s licensing FAQ is more specific about this:

The GPL requires that if you make a derivative work of Drupal and distribute it to someone else, you must provide that person with the source code under the terms of the GPL so that they may modify and redistribute it under the terms of the GPL as well. However, you are under no obligation to distribute the code to anyone else. If you do not distribute the code but use it only within your organization, then you are not required to distribute it to anyone at all.

What does this mean? If you’re developing a WordPress or Drupal theme, it must be under GPL. You can distribute your work, should you choose.

If you’re developing a theme for personal use or for a client, you have little to worry about because you are not technically “distributing” it.

Selling themes on the open market is a gray area, because distribution must be under the GPL. The GPL allows you to sell this work, but it also allows others to redistribute and sell it, too; you can’t do much about that. However, theoretically, the only derivative work that falls under GPL is the PHP code; any images, CSS and other content in your project remain yours. On top of that, you are free to charge extra for technical support and so on.

Remember that while WordPress is open source and free under the GPL, it is still copyrighted. You have to respect its chosen license.

Does My Work Need A License?

If you’re publishing content online — be it design work, photography, blog articles, audio or video — then the default is “all rights reserved”. Unless you publish it under a license (or through a Web service that reserves some rights for itself — and most do), then only you hold copyright. That’s great, but what do you gain by giving others permission?

In his article “Pick a License, Any License,” Jeff Atwood highlights the interesting example of developers who publish code on their blogs. Unless the developer states otherwise, no one has permission to use that code in their project. Always consider the benefits of others using and attributing your work: it could be great self-promotion!

It’s worth noting that you do not need to issue a license in order to give permission for someone to use your work. Some areas of the law favor verbal and contractual agreements over copyright.

Additionally, when using services such as Twitter and Flickr, you are probably giving those websites full rights to your work as part of their terms of service. These websites couldn’t operate without your content, but they do take every advantage of reserving full rights over the content you publish. This allows them to develop their service in different ways on the strength of your content.

Take this excerpt from Yahoo’s terms of service, which Flickr uses:

[…] you grant Yahoo! the royalty-free, perpetual, irrevocable, non-exclusive and fully sub-licensable right and license to use, reproduce, modify, adapt, publish, translate, create derivative works from, distribute, perform and display such Content (in whole or part) worldwide and/or to incorporate it in other works in any form, media, or technology now known or later developed […]

That covers just about everything!

While Flickr allows you to upload photos under a Creative Commons license for others to use, you also grant Yahoo permission to do anything it likes with them. I’m not condemning Yahoo for this practice because it’s common to all Web services. I’m just highlight the importance of reading the terms and conditions and understanding where you publish work and what rights you’re giving away.

Final Thoughts

With this information, you should have a strong understanding of how copyright and licenses work, why they exist and what they achieve. Ignorance of copyright — as of any law — is no excuse. By understanding it, we can take advantage of the wealth of creative content across the Web. If you’re publishing work online, consider sharing it under a license. You never know what interesting things people will do with it.

As mentioned, this article is the result of my own research and is not legal advice. You’ll need the latter if you’re unsure about copyright licenses.

Further Reading

(al)

© dbushell for Smashing Magazine, 2011. |
Permalink |
Post a comment |
Smashing Shop |
Smashing Network |
About Us

Post tags: ,

0
Your rating: None