imedo Development Blog

Skip links are links at the very top of the document with anchors to other parts of the same page, that help people using assistive technologies navigate the page faster. Traditionally, skip links were hidden away for “normal” users. The very first approach was using display: none for these links. But as assistive technology caught up, hidden areas are now hidden to everyone. So other clever techniques appeared for hiding the links from screen-based user agents, but not from, say, screen readers, like using a large negative text-indent. While this technique works fine most of the time, it seems that recent versions of VoiceOver in Safari skip these links in certain situations (particularly in combination with the float, display: block, or position properties), because they are not visible anyways. It is only a matter of time until other screen readers catch up with this, and ignore hidden skip links as well.

Now, an interesting observation is that skip links are not only useful for blind people. They are equally or even more useful for well-sighted people who need to control the browser without a mouse, and therefore exclusively use their keyboard for navigation, tabbing through the elements of the page. So the question is: How do we make skip links useful for blind users as well as users who navigate the page with their keyboards?

Our proposed solution is to show all skip links at the very top of the page, but to save space, stack them on top of each other in a way that only the topmost skip link can be seen at a time. Then, as the user is tabbing through the links, she sees (or hears) the link with focus on top of the other links.

Here is how it’s done. First, the markup:

<div id="skip-links">
  <ul>
    <li><a href="#content" class="first-link">Content</a></li>
    <li><a href="#header">Header</a></li>
    <li><a href="#sidebar">Side bar</a></li>
    <li><a href="#footer">Footer</a></li>
  </ul>
</div>

The CSS for the outermost div looks like this:

#skip-links {
  float: left;    /* if you want things to appear next to the links */
  width: 10em;    /* or bigger, depending on your link texts */
}

Now, the width part is important, otherwise the div gets way to wide.

The list itself has no special properties, except maybe list-style: none, which might as well come from a reset style sheet.

The CSS for the li elements looks as follows:

/* This is only needed for IE < 8 */
#skip-links li {
  float: left;    /* This takes the list item out of the document flow */
  width: 0px;     /* ... to make links appear on top of each other */
}

Note that both the float and width properties are needed for older IEs.

Finally, the CSS code for the a elements is:

#skip-links li a {
  z-index: 0;           /* all links on same z-index */
  position: absolute;   /* so that the z-index property actually works */
  width: 8em;           /* all should have equal width so that the front-most
                           element covers all other elements */

  /* The rest is decorative and can be changed */
  background-color: white;
  padding: 0.2em 0.4em;
  border: 1px dashed rgb(43, 117, 179);
  color: rgb(43, 117, 179);
  text-decoration: none;
}

Lastly, we should make sure that the currently focused element is on top:

#skip-links li a:active, /* To make it work in IE < 8 */
#skip-links li a:focus {
  z-index: 2;
  /* decorative */
  border: 1px solid rgb(43, 117, 179);
}

/* make sure the first link is on top when none have focus */
#skip-links li a.first-link {
  z-index: 1;
}

This is what it looks like, when tabbed through:

To see all of this in action, go to imedo.de, make sure the accessibility bar on top is visible (it should be if you have Javascript turned on and this is your first visit; otherwise, click on “Hilfestellung”) and start tabbing through the page.

[Note: In Safari on Mac OS X, tabbing is done with Alt-Tab. On Firefox, you have to turn on “tabbing through all elements” in System preferences first, pane Keyboard & Mouse. In IE, it should work out of the box simply by pressing the tab key.]

Popularity: 1% [?]

Certainly. But with all the features of new browsers, it would be a shame not to make use of them where appropriate.

For example, Safari and Firefox support setting the style for selected text, like this:

::selection       { color: #eee !important; background-color: #111 !important; }
::-moz-selection  { color: #eee !important; background-color: #111 !important; }

(The above gives selected text a very high contrast, which is a good thing for accessibility reasons.)

Another very fancy thing is using Safari’s CSS 3 animation module for smooth transitions. We are using this for our accessible “Focus mode”, which is designed to help people with ADD. In Focus mode, all content except that under the mouse is faded out. In Safari, there is a smooth transition, in other browsers there is not. The transition is not an essential part of the feature, but it is only one line of CSS, and looks really good:

.layout-element   { -webkit-transition: opacity 0.25s linear; }

Now, these CSS declarations cause the W3C’s CSS validator to choke. Is this a bad thing? Probably not. That is because we as web developers are well aware which CSS properties are part of the standard, and which aren’t, and also which browsers support which, and what bugs they have. That last thing is particularly interesting: even having a perfectly standards conformant CSS does not guarantee anything in terms of rendering.

Also, every known browser simply ignores properties it doesn’t support, usually without any problem whatsoever. So, while the validator is certainly a great tool to spot syntax errors, it is not really practically useful for the validation of CSS properties.

Popularity: 1% [?]

We are proud to announce the immediate availability of the first version of css_doc. It is a tool to extract Javadoc-like documentation from CSS files. It was inspired by the work from the CSSDOC guys, but is NOT a complete implementation of their proposed standard. It is, however, quite similar, so that your existing CSSDOC documentation should probably work with css_doc.

This is the first release, so it is not what one would call “feature-complete”, but it is already quite stable at the moment. This version’s features include:

• File-level documentation for each CSS file in your project.
• Possibility to divide a single file into multiple sections.
• Rule-set-level documentation (a rule set is a set of selectors, separated by commas, together with their CSS properties).
• HTML-Code examples for the usage of your CSS rules are extracted. This is useful for building a style guide.
• Generates selector, section and file index pages.

For an example, please have a look at http://opensource.imedo.de/css_doc/index.html. The documented CSS file can be found here: http://opensource.imedo.de/stylesheets/style.css. I know the design of the css_doc documentation is not pretty, but we will improve on that in a future release.

If you like css_doc and are a Ruby hacker, or if you would like to improve the default design, please fork the project on github and send us a pull request. Of course the code contains lots of tests, but you are also welcome to add more tests, especially if you find bugs.

For installation instructions, please see http://github.com/imedo/css_doc.

Popularity: 1% [?]

There are many people who are already using this technique, but it is so incredibly useful that I thought we need to post it here as well. If you want your website to look good in more than just one browser without resorting to invalid CSS syntax error hacks, you absolutely must take a look at the CSS Browser Selector Javascript. Then, you can write selectors like this:

div.article       { width: 10em; }
.ie6 div.article  { width: 11.26em; }

That causes the article div to have a width of 10em in standard browsers, but a width of 11.26em in IE 6. Not only is the CSS valid all of a sudden, it is also VERY clear and understandable.

Of course, CSS-based browser detection is most useful for the IE family of browsers, which incidentally suffer most from slow Javascript execution times. This is why I propose an optimization that makes browser detection faster for the IEs, and even works without Javascript (which in total should cover about 70 percent of your users). Right after your opening and right before your closing body tags, use conditional comments to select the IE browser version, like this:

<body>
  <!--[if IE 6]><div class="ie ie6 win"><![endif]-->
  <!--[if IE 7]><div class="ie ie7 win"><![endif]-->
  <!--[if IE 8]><div class="ie ie8 win"><![endif]-->

  <!--[if !IE]><!-->
    <!-- Browser detection start script for other browsers, if still needed -->
  <!--<![endif]-->

  Your body content goes here

  <!--[if !IE]><!-->
    <!-- Browser detection end script for other browsers, if still needed -->
  <!--<![endif]-->

  <!--[if IE]></div><![endif]-->
</body>

Popularity: 1% [?]

If you take a look around the web, you will find that most web sites out there have a fixed layout, most commonly with a width of 1000 or so pixels. Notable exceptions are Wikipedia or Google, as well as a lot of application-like web sites, like Google Mail, Yahoo Mail etc.

If you are not using Windows, you already expect a window on your desktop to either be of the correct size, such that all content fits, or to be resizeable. It is always good practice to empower the user to customize the environment as she sees fit, and now we adopted that idea on imedo.de.

But the real motivation for this move was with a certain group of people in mind: those with low screen resolutions. The main use case for displays with low resolutions is for people with an impaired sight. They usually do not have the option to make the browser window larger than, say, 800×600 pixels. So the idea is to show all of the page’s content to them, even when the browser window (scrollbar and window frame included) is only 800 pixels wide. Another goal was to do this without a horizontal scroll bar. The reason behind this is that it is particularly cumbersome to scroll horizontally, and that people with impaired vision may as well have trouble seeing the scroll bar.

The key to a flexible layout is to use percentages for horizontal sizes. That is almost as much there is to it, except for two things:

1. IE < 7 does not support the max-width property. If you want your layout to grow up to a certain width, you can not accomplish that in IE 6 in a valid fashion. It is possible to use non-standard CSS expressions, or to use Javascript to detect window resizing, but both techniques are slow and pretty unstable, so that we decided that IE <= 6 gets a fixed-width layout.

2. You want fancy things like fixed-sized columns and flexible ones. It is well documented how to do that, but there is one technique I want to share with you.

Say you have a vertical list with a couple of items, each of which has a picture on the left, and text on the right. Now, the picture has a fixed size, and you want the picture to have that size regardless of the window width. But the text on the right may grow or shrink in width, like this:

Full width:

Smaller width:

One simple and cross-browser (IE5+, Safari, Opera, Firefox) way to do this is to wrap the picture in a left-floating div, and to wrap the text in a div with the picture’s width plus some space as a left margin, like this:

<ul>
  <li>
    <div class="image">
      <img src="/some/image"/>
    </div>
    <div class="text">
      <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit,
   sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
    </div>
  </li>
</ul>

The CSS to make this happen is as follows:

div.image {
  float: left;
  width: 4em;
}

div.text {
  margin-left 5em;
}

Note that the div.text does NOT declare a width, which causes all browsers to use the maximum width available. Also, do not use any overflow property on the div.text element or any child of it, as this breaks stuff in weird ways in several browsers.

This is a very simple, stable and standards conformant solution for this problem. The nice thing is that you can use it for layout columns as well (although care must be taken for IE <7, as they tend to explode layout boxes when the content gets too large). Also, it is possible to have the fixed column on the right, or to have fixed columns on the left AND the right, and have the middle column fill the remaining space.

Popularity: 1% [?]

As requested here is the presentation for our awesome email plugin:

Slides

Popularity: 1% [?]

For the impatient

Check out the demo application:
http://opensource.imedo.de/htmlmail

Install the plugin:
script/plugin install git://github.com/imedo/awesome_email.git

Learn how to use it below.

Introduction

Have you ever tried sending HTML emails to your users? If you did, you know for sure that it sucks big time: none of the usual ActionView helpers want to work, URL routing is disabled, layouts don’t work, and last but not least, the CSS you wrote for your email simply won’t work in any e-mail client except maybe Apple Mail. To solve all of the above problems, the awesome_email plugin comes to the rescue. Just install it into your vendor/plugins folder, and the rest comes by itself.
If you are interested in what works in which Email client check this link: A guide to css support in Email

What does it do?

There are a few interesting components in awesome_email:

• awesome_email adds layout support to emails. That means that you can use templates for e-mails just like you would with normal Rails Views.
• The HTML Mail’s CSS is automatcally inlined. That means that your designer and/or CSS guy can design the email in a web browser without worrying about how it might look like in excotic email clients. Yes, it works in Outlook, too, and no, it doesn’t work in Outlook 2007 without tweaking. The reason is a “stupid decision from Microsoft about Outlook 2007”, but we’re working on that one.
• ConvertEntities replaces Umlauts and other crazy symbols like ä, Ö etc. with their HTML Entitiy counterparts e.g. ä and so on.
• HelperMethods allow you to dump the content of the CSS file right into a style tag inside the header of your HTML mail.

How to use it

In your Mailer.delivery_xxx methods you can use

1
2

layout    "template_filename"
css       "css_filename"

to define which layout should be used and which css file should be used to create inline styles

CSS inlining

The cummulated style of each DOM element will be set as an style attribute when using css inlining.

Example:

your css file:

1
2
3

#some-id { font-size:2em; }
.some-class { color:red; }

your template:

1
2

<p id="some-id" class="some-class">Hello World!</p>

will result in the following code:

1
2

<p id="some-id" class="some-class" style="color:red; font-size:2em;">Hello World!</p>

Important!

Be sure to follow these simple conventions or otherwise awesome_emails’s magic will fail:

• The layout must be located inside app/views/layouts/{mailer_name}
• If you send mutlipart mails, check out the conventions on how to name your files: http://rails.rubyonrails.com/classes/ActionMailer/Base.html
  • So if you have these files inside of /app/views/{mailer_name}: signup_notification.text.plain.erb, signup_notification.text.html.erb ActionMailer will send a multipart mail with two parts: text/plain and text/html
• Your CSS file must be inside of /public/stylesheets

Dependencies

gems: rails 2.0.2, hpricot, csspool

Getting it, License and Patches

Get the complete source code through http://github.com/imedo/awesome_email. License is MIT. That means that you can do whatever you want with the software, as long as the copyright statement stays intact. Please be a kind open source citizen, and give back your patches and extensions. Just fork the code on Github, and after you’re done, send us a pull request. Thanks for your help!

ToDo

• More test coverage (as usual)
• make it more flexible with view paths
• rails 2.1 compatibility

Popularity: 100% [?]