Wednesday, July 18, 2012

My Print Styles Article in .net Magazine

The Summer 2012 (#231) issue of .net Magazine has my tutorial on making print styles for your site. Not only did I get four pages, the article got a mention on the front cover (small though it is) and my photo in the contributors section.

If you've spent much time here or following me on Twitter, then you know I have written plenty about the lack of print styles on modern sites, particularly those claiming to use responsive techniques. I figured it was about time I showed some techniques to make it happen and hopefully demonstrate how dreadfully simple print styles are to do.

While my article is clearly the stand-out piece in the magazine, and totally worth getting just for my work, there is some other stuff in this issue that might interest you:

Creating flexible layouts that will work on any device and any screen size is the next big challenge for CSS. In this month's issue Peter Gasston takes us on a tour of some well-implemented properties you can use now as well as the exciting proposed properties we could be using in the future.

There's also a guide to creating or updating your online portfolio from Gary Marshall, an interview with Elliot Jay Stocks and tutorials on HTML5's Drag and Drop API and building a basic responsive site with CSS. Here are some more highlights:

  • Build smoother JavaScript apps
  • Make your website printable
  • Make your sites load faster
  • The pro's guide to Adobe Edge
  • Build an ecommerce store
  • Using PHP Data Objects

By the way, in case you want to read up on some of my prior discussions about print styles, here's a handy list of links for you:

Update, March 5, 2013

My print CSS article has appeared on the .net Magazine web site, though the web site excludes the sidebars on Print Shame and QR codes in print layouts.

Update, June 28, 2014

After Net Magazine was subsumed by Creative Bloq, all the addresses for old articles were broken (once the articles were finally added). I have fixed the links above to reflect the new addresses.

Monday, July 16, 2012

It's OK to Use Tables

Image of Baby Boomerangutuang.
Baby Boomerangutuang, one of the Tick's students.

If you cut your teeth building for the web in the 90s and even into the 00s, then you probably learned to lay out your HTML pages using tables. As CSS support and techniques have caught up, tabled layouts have mostly gone the way of the font element.

There seems to be such a strong backlash against tables, however, that many developers won't even use them when it is both semantically and structurally appropriate — such as marking up tabular data.

The W3C HTML5 draft specification has a pretty simple way to qualify if a table is appropriate:

The table element represents data with more than one dimension, in the form of a table.

To explain it another way, if you are representing columns and rows of data then you probably should be using a table. If you find you are using images or other elements, then you are likely doing it wrong.

In addition, representing tabular data using other elements means you may be preventing users of assistive software, who already have experience reading tables, from being able to access the information in the same way.

Examples of the two methods I see most frequently to incorrectly mark up tables follow.

Tables As Images

These screen shots show how each table appeared when viewed on an iPad and on an Android Evo using Opera. Click/tap for larger images.

In February .net Magazine posted an article, Deliver video seamlessly to desktop and mobile devices, which included two tables of browser and video codec support. These two tables were not marked up using a table, however.

Instead the tables were presented as images with no useful alt text. While the article used an HTML5 figure, there was nothing to present the contents of the tables as plain text.

The problem was exacerbated by the fact that when the page was viewed on mobile devices, the automatic down-sampling of the .net Magazine CMS (I am assuming here) for the mobile version of the article resulted in images that were completely illegible. A traditional HTML table would not have suffered from that problem.

I figured I was on to something when my tweet drew some comments, though I don't agree that it's just bad alt text:

To .net Magazine and the author's credit, the images were replaced on both the main site and the mobile site within about 18 days of me mentioning it (which you can follow in the comments).

Tables As Any Other Element

This screen shot shows the event schedule when viewed in a desktop browser. Click/tap for a larger image.

I suspect some tables are put together using other HTML elements just to show off that the developer can do it. After all, If developers were thinking about the structural and semantic meaning of the content, then they surely wouldn't use div and spans to mark up tabular data.

The web site for a two day responsive web design workshop, Build Responsively, includes a schedule on its Columbus event page. This schedule includes a column of times and a column of sessions. Each column has a heading and the rows have alternating background styles. In every visual sense, it's a table of data.

Semantically and structurally, however, that's not how it's coded (which I discovered when I attempted to print the page). It's a series of divs and spans inside an ordered list (I have also seen this done with definition lists). The first bullet even has the class "heading," which is probably a good clue that this entire list could be a table and that "heading" could be a th.

This code block shows the event schedule HTML for context:

      <ol>
        <li class="heading">
          <div class="time">Time</div>
          <div class="session">Session</div>
        </li>

        <li>
          <div class="time">
            <time datetime="2012-07-09 08:00">8:00AM</time> - <time datetime="2012-07-09 09:00">9:00AM</time>
          </div>
          <span class="session">Registration, Coffee</span>
        </li>

        <li>
          <div class="time">
            <time datetime="2012-07-09 09:00">9:00AM</time> - <time datetime="2012-07-09 09:40">9:40AM</time>
          </div>
          <span class="session">Responsive Web Design, 101</span>
        </li>

        <li>
          <div class="time">
            <time datetime="2012-07-09 09:45">9:45AM</time> - <time datetime="2012-07-09 11:15">11:15AM</time>
          </div>
          <span class="session">Responsive Planning &amp; Design</span>
        </li>

        <li>
          <div class="time">
            <time datetime="2012-07-09 11:30">11:30AM</time> - <time datetime="2012-07-09 12:00">Noon</time>
          </div>
          <span class="session">Getting a Good Start</span>
        </li>

        <li>
          <div class="time">
            <time datetime="2012-07-09 12:00">Noon</time> - <time datetime="2012-07-09 13:00">1:00PM</time>
          </div>
          <span class="session">Lunch (provided)</span>
        </li>

        <li>
          <div class="time">
            <time datetime="2012-07-09 13:15">1:15PM</time> - <time datetime="2012-07-09 17:00">5:00PM</time>
          </div>
          <span class="session">Afternoon Session, The Nitty Gritty</span>
        </li>

        <li>
          <div class="time">
            <time datetime="2012-07-09 17:30">5:30PM</time> - <time datetime="2012-07-09 22:00">?</time>
          </div>
          <span class="session">Opening Night Party, Sponsored by GitHub!</span>
        </li>
      </ol>

You can see this site featured on PrintShame.

What You Can Do

With all the push for hand-crafted HTML and CSS and the strong desire to show off what developers can do using HTML5 and assorted tricks, take a look at any grids you find yourself marking up. If you find you have columns of data, rows of data, headings for rows or columns, or are using any CSS table display properties, then you just might need to use a table instead.

Update: January 3, 2012

The article HTML5 caption element and headings explains that with HTML5's acceptance of headings in captions on tables, it's now possible for your data tables to fit into the heading navigation when accessed via a screen reader.

Update: April 12, 2013

LĂ©onie Watson has put together a quick overview on how to make your data tables accessible over at .net Magazine.

Update: October 21, 2013

Another example of doing it wrong, found in the wild:

Friday, July 6, 2012

Codepen Has Handy Sharing Tools for Devs

Codepen logoThere are plenty of online resources for playing around with code right in the browser, no server of your own needed, that you can then share with others. I have dabbled in them on and off but Codepen's recent entrance has a couple additional features that I have found handy.

Bookmarklet

Screen shot of Codepen bookmarklet in use on a web page. Codepen has a bookmarklet which will find blocks of code on a page and, when clicked, queue them up to drop into a new project (or "pen"). In this example image you can see the code blocks on the page are highlighted and a box is anchored at the bottom of the viewport showing me what's been selected of what type (HTML, CSS, JS) and an option to jump right to the Codepen interface.

I tested this on my site (using The evolt.org Logo Using Only CSS2 and CSS3) and it recognized the HTML and CSS blocks of code for what they are. The HTML in my example has hidden characters inserted to prevent a bug from manifesting (thanks to a combination of how I coded the templates, the XML framework, XSLT transforms, and HTML rendering), so I had to manually clean that. The CSS came over just fine although for some reason it did not seem to apply properly until I manually pasted it in. Either way, I was able to start playing with the code almost immediately.

For all those tutorials on the web, this is a handy way to immediately grab and play with the code samples. Once I have sufficiently munged the code enough I can then share it using the URL Codepen provides or the embed feature I outline below.

Saving your project with a name and details is a little tricky and you'll want to be logged into Codepen beforehand (you can use your GitHub account for Codepen). Once you get past those two points you're pretty much good to go.

Codepen has a YouTube tutorial to walk you through the bookmarklet process:

Embed Code

Screen shot of Codepen project screen. Now that I've pulled code from a tutorial and messed around a bit (I didn't mess around with it, but let's say I did) I can write my own tutorial and embed the code directly into the page.

This is handy for people whose platform of choice makes it difficult to embed escaped code examples, who don't care to go through all the hassle of styling code for colors, or who just want readers to be able to interact with the code and mess around with it on their own.

The only real caveat is that it embeds on the HTML portion of your project. If the call to the Codepen JS file fails for some reason (which formats the display and creates the CSS and JavaScript boxes), users can at least see the HTML, but the CSS and JavaScript isn't included.

Using the Codepen project I created from my tutorial, I just pressed the "share" button and was presented with HTML to embed directly into my page. The results:

<p id="evolt">
<a href="http://evolt.org">evolt.org</a><br>
<a href="http://lists.evolt.org">lists.evolt.org</a><br>
<a href="http://browsers.evolt.org">browsers.evolt.org</a>
</p>

Related

Thursday, July 5, 2012

Let's Treat Old Browser Users Better

It's not hard to stumble across diatribes against IE6 (and 7 and 8) users across forums peopled by web developers. As a web developer there is no denying that my desire to play with the new and shiny is hampered by my need to support users on older browsers and systems. But do we have to be such jerks about it?

If you don't think we're jerks, I have examples in some of my posts:

How We Misbehave

The posts above are primarily about short-sighted developers (all of us) blaming IE6 (for the most part, but other old browsers as well) for their development woes. We often release that frustration on users — specifically users of those browsers.

We tell those users their browser isn't good enough. We tell them they'll have to pay more to use the site. We tell them the site is much cooler in a modern browser. We intentionally exclude them and then fail to report on their traffic (making it easy to continue to marginalize them). We do all sorts of things to the users of those browsers.

Who Are These Trapped Users?

We need to consider that most users on older browsers aren't there by choice. They are trapped.

Some are trapped because they don't know any better. They are part of the world that uses a computer rarely and the web is a painful necessity for some things they used to be able to do with a phone, a walk, or a piece of mail. These people are not evil. They are our parents, grandparents, aunts and uncles, brothers and sisters (probably not our kids). They may work in a field where they never need to touch a computer. They may hate or fear computers for very valid reasons.

They may be disabled in some fashion and rely on accessibility features or devices that they cannot afford to upgrade or are otherwise not available to them. They may have very old hardware, be using a library computer, or stuck in some internet cafe in a forgotten part of the world.

Some of them may be very smart, very interested in science and technology, very much able to run cognitive circles around all of us, and still use an old browser:

(That's out of 206,000 visitors, and only 3,000 of those IE6 users represent China.)

Some users are trapped in a corporate environment where they are not allowed to upgrade. Even with Microsoft's push to start to auto-update IE, corporate IT departments are still allowed to override it. These users may have no sway with IT. IT itself may be playing it safe to avoid lawsuits and compliance issues, some may not have the budget to re-write internal corporate tools. Those employees are users who trapped.

What We Should Do

Let's not treat users of IE6 (and other old browsers) like they are deviants or criminals. Let's instead treat them like people who are trapped and need our help.

Let's not require them to pay more, jump through extra hoops, or fail to see what the rest of us see. Let's not talk down to them, treat them like idiots, or tell them they should just do something they cannot do.

Take a look at your sites in an old browser (today that's IE6, years ago it was Netscape Navigator 4, tomorrow it might be the default Android browser). See if you are being a jerk to your users with poorly-worded messaging, intentional blocks, or imposed "taxes." When you stumble across these transgressions in projects to which you contribute on GitHub and elsewhere, fix them and maybe even explain why.

If nothing more, make the web and its development practices nicer to the future you who may very well be trapped on an old browser someday.

Update: July 10, 2012

There is a nice (both in tone and quality) article at Smashing Magazine today titled Dear Web User: Please Upgrade Your Browser. It assumes a reader is not afraid of computers and has at least some control over his/her environment (so it's useless for, say, my parents) and explains reasons to upgrade/cross-grade while providing links to other browsers.

Tuesday, July 3, 2012

Changes to jQuery Browser Support

jQuery logo.Currently, up to and including the jQuery 1.9 release (not out yet, but coming), jQuery actively supports the following browsers:

  • Internet Explorer 6+
  • Firefox: Current -1 version
  • Safari: Current -1 version
  • Opera: Current -1 version
  • Chrome: Current -1 version

According to jQuery's browser support page, any problem [in these browsers] should be considered and reported as a bug in jQuery.

As the jQuery team announced in its blog post, jQuery Core: Version 1.9 and Beyond, the 2.0 release (slated for early 2013) will drop support for Internet Explorer versions 6, 7 and 8. The 1.9 release will continue to support IE 6/7/8 and will even see parallel (to 2.0) development and bug fixes. There is even a code sample of conditional logic so developers can prompt browsers to load the appropriate jQuery library (based on IE browser, or not).

Readers have gotten a bit confused on this point, so much so that the jQuery team wrote a follow-up piece on Sunday, jQuery 1.9 and 2.0 — TL;DR Edition.

My concerns are two-fold. First, many web developers won't take the time to pay attention to the parallel track for 1.9 and 2.0 and may implement the new version as soon as it is available, penalizing users trapped on old versions of IE. Second, many web developers don't seem to know their sites' user base and may make ill-informed decisions to move up to the latest release (perhaps intentionally so), thereby penalizing users trapped on old versions of IE.

Looking at SitePoint's latest details on browser trends (Browser Trends July 2012: IE9 Strikes Back), and bearing in mind that every site on the web will likely have different numbers, we can see that IE 6/7/8 make up a combined 15.75% of users. In-your-head math tells you that for a site with a million users, that means 157,500 users will run into problems today if the site were upgraded to jQuery 2.0.

The browser numbers will likely change by early 2013, but perhaps not by much. If Microsoft's new forced updates work (The Skinny on IE's Update Policy) then this may all be a moot point.

Either way, site developers will still need to be smart enough to pay attention to their site statistics and respect those users who are trapped in a browser, instead of either forgetting about them or intentionally penalizing them.

As for why jQuery is making these changes, I understand both sides. Removing the bloat from the libraries by dropping IE 6/7/8 support should slim the files and reduce processing overhead. That's good for all non-IE users. The other side is nicely summed up in this tweet:

Monday, July 2, 2012

Social Media Day 2012 in Buffalo #smdayBUF

This past Saturday marked the third Mashable-sponsored Social Media Day here in Buffalo. While the last two years have been unofficial (much like the day itself), this year the City of Buffalo declared June 30, 2012 as Social Media Day (the year on the proclamation makes me think this is a one-off). At my last count, 17 other cities and three other states also declared June 30 as Social Media Day (as reported by Mashable).

The event in Buffalo this year was heavily sponsored and included free giveaways, contests, real-time video streaming, and plenty of food and drink specials. The description from the event announcement:

  • Take the Social Challenge and win the grand prize!!!
  • Get your photo taken on the AT&T Red Carpet
  • Network and find out who is really behind those Twitter handles
  • Find out what companies are hiring and who really GETS social media in Buffalo
  • Learn about the basics or wax poetic with the experts--everyone is welcome
  • Have a great time with drink specials provided by Lobby Bar at Statler City: $2.50 domestic beers and well drinks as well as appetizers on hand
  • See who's tweeting about you on the Twitter wall--#smdaybuf
  • Feel good by knowing your ticket donation is going to Computers For Children

Social Media ClubThis year's event was organized by the Buffalo chapter of Social Media Club. The Buffalo chapter is less than two years old and has many of the members that helped organize the event the last two years, plus many newcomers.

While the venue was full all day long, the nice weather on a pre-4th of July Saturday afternoon probably hampered attendance a bit, as noted by the Social Media Club Buffalo Chapter president:

If you were not there then you can catch up with some of the activity by viewing the Twitter stream, tagged with #smdayBUF. There were many photos throughout the evening, and as some of the albums start to show up I will link them here. If you have one you want linked, please pass it along. This includes any video or news coverage.

Photo of pint glass and food from the event.

Photos, Videos, Press

Previous Events

Choice Tweets