Archive for the ‘Web Basics’ Category

File Under: CSS, Web Basics

Adobe Proposes New Standard for Better Web Typography

Adobe’s proposed text-balance rule (right) versus no balancing (left). Image: Screenshot/Webmonkey.

Adobe is continuing its effort to bring better typography to the web with a new proposal for what the company is calling “Automatic Text Balancing.” If browsers adopt text balancing it could mean the end of typographic unsightliness like widows, orphans and ragged lines, and would go a long way to creating more readable text on the web.

Adobe’s proposal is based on Adobe InDesign’s “Balance Ragged Lines” feature, and works a bit like justifying text except that instead of expanding text with ugly spaces between words, the algorithm would adjust line lengths to “balance” text for easier reading.

Adobe’s Randy Edmunds outlines the basic idea behind automatic text balancing on the company’s Web Platform Blog. Essentially text balancing would mean eliminating widows (single words pushed to a new line), and also automatically presenting text so that it’s even wrapped instead of a long line followed by a shorter line.

Here’s how Edmunds and Adobe see text balance working:

I propose we use a text rendering algorithm that would be applied by browser when asked by the designer to do so to automatically balance text across multiple lines, like so:

h1 {
  text-wrap: balance;

This would make all h1 elements whenever they span more than one line to be automatically rendered such that they have balanced text. As you notice, I only propose an additional value to the existing text-wrap property of CSS.

If accepted by the W3C, Adobe’s text balance proposal would add a new balance value to the proposed CSS text-wrap rule. The text-wrap property was originally part of the CSS 3 spec, but has since been removed and remains in flux.

Adobe has already created a jQuery plugin polyfill that implements the proposed text balance algorithm. You can grab the code from GitHub. There’s also a sample page where you can see the jQuery text balancing in action. (Be sure to resize the window to see the reflow difference between balanced and unbalanced text.) There’s also an ongoing discussion on the CSS WG mailing list if you’d like to dig into the details.

File Under: Visual Design, Web Basics

Create Better, Sharper Web Graphics With SVG

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.

File Under: HTML, HTML5, Web Basics

Skip the Lists for a More Accessible Web

Soupe du jour: tags. Image: clogozm/Flickr

Somewhere far in the web’s primordial past it was decided that the best way to mark up a menu in HTML was to use the unordered list element: <ul>. The vast majority of tutorials – if not all – you’ll ever see for creating navigation menus use the familiar list element structure, nesting links inside <li> tags. Menu plugins for WordPress and other popular publishing systems use lists for menus as well. Even the HTML5 spec uses an unordered list in its <nav> element examples.

There is, as CSS-Tricks’ Chris Coyier writes, “no debate” about how menus should be marked up. But HTML5 adds the <nav> element and there’s also a navigation role in WAI-ARIA so should we still be using lists to mark up menus?

Coyier says no. He’s dropped lists from his <nav> elements and instead uses just links and span tags. Coyier cites a talk by Reinhard Stebner, who is blind, and suggests that with most screen readers the far better solution for menus is to use divs and spans for menus.

Be sure to read through Coyier’s post for some more data on why ditching the list might be a good idea and check out Jim Doran’s write up on Stebner’s original talk, which makes a distinction between accessible and usable. That is, a technically “accessible” site might still be a usability nightmare for some users.

However, as Mozilla’s Chris Heilmann points out in the comments of Coyier’s post, the problems lists cause in some screen readers are really a result of the sorry state of screen readers. “Screen readers are damn slow to update and vary immensely between different versions… I gave up a long time ago calling something accessible or not when it works in Jaws.”

Lists for menus have advantages over the div and span route, like some extra elements for styling and the fact that they render as, well, lists even in the absence of CSS.

What do you think? Are lists for menus a legacy workaround we no longer need in the day and age of <nav> and role="navigation"? Or do they still offer enough advantages to keep using for menus?

For his part Coyier says he’s going to keep building list-free menus. “Until I see some solid research that suggests that’s dumb, I’m sticking to it,” he writes. “As always, the best would be to get more information from real screen reader users like Reinhard.”

File Under: Web Basics, Web Standards

New Community Project Brings Web Accessibility to the Masses

Tim Berners-Lee, W3C Director and inventor of the World Wide Web, once said that “the power of the Web is in its universality…. Access by everyone regardless of disability is an essential aspect.”

Sadly the universal accessibility of the web remains more of a goal than a reality — not because it can’t be done, the tools exist, but because developers often neglect it.

The Accessibility Project is a new effort to help “make web accessibility easier for front end developers to implement.”

The Accessibility Project is relatively new, but already has a ton of great resources — everything from tutorials on how to hide content but still make it accessible to screen readers, to a handy checklist you can use to make sure you’ve covered the accessibility basics before you launch.

There’s also a great collection of links to accessibility resources, tools and tutorials around the web.

The Accessibility Project is very much a community effort, with all of the source code and posts on the site hosted on GitHub. If you’d like to contribute, head on over and read through the contribution guidelines before you fork the project.

File Under: Backend, Identity, Web Basics

We Should Retire Aaron’s Number

Aaron Swartz. Image: Wikimedia Commons.

[Editor’s Note: Coder and activist Aaron Swartz committed suicide Jan. 11, 2013 in New York. He was 26 years old. See Wired’s early coverage for details.]

When a great baseball or basketball player leaves the game they retire his or her number. That means the jersey hangs from the ceiling, or there’s a plaque at the stadium, and no player on the team ever wears that number again.

Babe Ruth’s number, 3, is retired. Michael Jordan’s too (23). Jackie Robinson’s number, 42, is retired for all baseball teams.

On the web, retiring a number would mean the website is permanently registered, and the content is preserved so it lasts as long as the web does. That means the contents of will be there forever. It will never become a porn site, or a landing page, or whatever.

Right now there is no way to do this. Isn’t that strange. We could fix it if we want. The internet is just software. It would be a small but worthwhile hack and could set a precedent for future memorials.

Something to think about!

This post first appeared on Scripting News. Also see the related thread on Hacker News.

Dave Winer, a former researcher at NYU and Harvard, pioneered the development of weblogs, syndication (RSS), podcasting, outlining, and web content management software. A former contributing editor at Wired magazine, Dave won the Wired Tech Renegade award in 2001.
Follow @davewiner on Twitter.