Rachael L. Moore's web design blog covers her thoughts on current web design projects and web design industry news. Rachael may also write about graphic design, web design, search engines, local Tallahassee art/design events, as well as other design-related topics.

XHTML Forms: ID and NAME: 01/26/09

I've just found a little quirk/problem with form inputs and ID attribute in Firefox 3. While creating on some forms at work and I started to observe some very weird behavior in radios and checkboxes.

Historically, before the ID attribute became popular (and important with increased use of CSS), you'd use the "name" attribute for things like form inputs, anchors, etc. Then "name" started to be deprecated in favor of "id."

Unfortunately, browsers have held onto "name" and often won't really function properly without the "name" attribute present (for sending data from forms, manipulating forms with javascript, and functioning page jumps).

The common advice for the last few years has been "use both." Confusingly, the "name" attribute is acceptable on form input fields, even in an XHTML document.

Notice my phrasing--as it turns out, it's actually not confusing. "Name" wasn't ever deprecated on form inputs or form selects. I'd just fallen into a very bad habit for a combination of several reasons.

For more, visit the overview at XHTML/HTML Forms - Using name and id.

Accessible Menu Technique: 07/20/07

This technique was explained by BigBison of International Web Developers Network in the thread hiding link text completely in opera and ie. I love it so much that I wanted to document it here.

View a very simple demonstration of the accessible image-replacement CSS menu technique.

The idea of this menu is to create a simple, semantic menu using an unordered list. Each list item should contain an "empty" span tag. That span tag is then turned into a block-level element using a stylesheet. Your image/button is applied to that span tag as a background. Absolute positioning is then used to make the span tag "cover up" the simple text link.

The benefits of this are many. Your menu can be used before the images load--good for slower connections. Search engines like plain text links more and will follow them. Individuals using alternative browsers or browser configurations (mobile users, users with disabilities) will also find your menu more accessible. My example here is simple, but it's the best of both worlds. You can have your fancy buttons and your plain text links at the same time.

Another note here that was new to me was making the normal, hover, and visited buttons all one image. Background positioning (instead of background image swapping) is then used to show the button's state. This improves performance in several ways--you have to manage fewer files, you will avoid that flash of an unloaded hover image, and your overall file sizes will be reduced.

This menu builds on a popular technique--using lists. What is a menu, after all, but a list of pages, links, and/or places to go? The list has some semantic relevance to the menu and it's a sensible format for your menu in a plain-text browser. We all know what a list looks like--each <li> is automatically moved to the next line. The first part of this technique, which will be familiar to many CSS fans, is to place all the <li>'s on a single row. We do that by using the float property. Using li { display:block; float:left; } we explicitly declare that <li> is a block-level floating element. Floating can be tricky because, like absolute positioning, a floated element is taken out of the normal document "flow." Unlike absolutely positioned elements, however, floated elements can be cleared--all it takes is some experimentation to get used to floats.

Normally the <a> element is also made a block element as well. That allows us to define a height, width, background, border, etc. as well as make use of pseudo-classes on our 'buttons' in a way that IE will understand. In this case, we are also going to set the <a> element's position to "relative." We will also place an "empty" (as in, nothing between the two tags) <span> tag inside our <a> element.

Once we add the empty <span> tag, we have an empty inline element within our block. Using our stylesheet, we will make the <span> element a block-level element and set it to the same height/width of the <a> element around it. We will also apply our button as a background to the <span> element. Making the position of <span> absolute at top:0 and left:0 will cause the background of <span> to completely overlap the plain-text link.

Below is the code:

Technique learned on IWDN, developed by member BigBison. <!-- XHTML Unordered List -->

    <div id="amenu">
            <li class="home">
                <a href="index.html">
            <li class="blog">
                <a href="blog.html">
            <li class="contact">
                <a href="contact.html">
/* Image Replacment - Accessible Menu */

    /* Your custom styling for the menu container. */

div#amenu ul, div#amenu ul li, div#amenu ul li a, div#amenu ul li a span{
    /* Necessary default styles. */
    /* Only change height and text-align if desired. */
    /* Add any desired margins, padding, or borders to elements below individually. */

div#amenu ul li, div#amenu ul li a, div#amenu ul li a span{
    /* You can use variable widths by using individual classes. */
    /* Or make each button the same width here. */

div#amenu ul{
    /* Your custom styling. */

    div#amenu ul li{
        /* Creates a horizontal line of items from the unordered list. */

        div#amenu ul li a{
            /* Only change color, font, text, and (maybe) overflow properties. */
            font:bold 10pt "century gothic", sans-serif;

        div#amenu ul li a span{
            /* Important: Causes the span element's background to overlap the plain-text link. */

            /* Change your desired colors. */
            /* Using one background image and changing its position (rather than multiple images) improves performance. */
            /* Ensure that your plain text menu's font colors and styles and background colors harken to your image menu. */
            /* Accessibility guidelines recommend that you suggest a state change with more than just color, however, so keep that in mind. */
            div#amenu ul li a:visited{
            div#amenu a:visited span{
                background-position:center bottom;

            div#amenu ul li a:hover{
            div#amenu a:hover span{
                background-position:center top;

            div#amenu ul li a:active{
            div#amenu a:active span{
                background-position:center bottom;

        /* Set your individual image menu buttons here. */
        li.home a span{
            background:url(amenu_home.jpg) center center no-repeat;
        } a span{
            background:url(amenu_blog.jpg) center center no-repeat;
        } a span{
            background:url(amenu_contact.jpg) center center no-repeat;

Syndication--Atom: 04/23/07

As promised, there is now an Atom feed available. If you subscribe, you will be notified of updates, events, blog posts, and new images in the Portfolio.

I ended up being somewhat fonder of Atom than of RSS. Primarily because of the reasoning driving its development.

However, I did find it a bit more difficult to find examples of Atom feeds; it didn't help that, in a fit of single-mindedness, I selectively ignored Wikipedia's links. If you're wondering, I feel that Atom's examples were the most straightforward and helpful; and also looks helpful in retrospect. I also read through the HTML 'specification' several times.

I had a severe gripe about the need for UUIDs, up until I read's atom:id treatise and learned about tag URIs. Here's hoping I understood how to build tag URIs correctly! It wasn't that I disagreed with the concept of permanent, unique ids, I just didn't want to have to add UUIDs to my database. You could call that "laziness", but I'm happier with the tag alternative.

My other issue was using a complete date/time in atom:updated. Again, it's not that I disagreed with the recommendation, exactly. It was more because my database doesn't store times for my additions and updates--for several reasons.

For example, in the Portfolio I only store the date I added the image. First, I don't have or remember exact dates for older images, let alone times! Second, I didn't add that field to the database until after I'd already launched the site. I'm bad. Finally, I also have a personal preference: I honestly do not care what the exact time was, and I don't want to have to manage times. So I cheated on that one; the times are all fake. I'll probably improve on that in the future.

<?xml version="1.0" encoding="UTF-8" ?>

  <feed xmlns="">

  <title type="text">
  Virtual Revolution
  <subtitle type="text">
  VR Updates Feed

  <link rel="alternate" href=""
  type="text/html" />
  <link rel="self" href="" />

    Rachael Moore

  Copyright Rachael L. Moore 2007


    VR Post: Syndication--RSS
    <link rel="alternate" href="" />
    <content type="text">
    If you take a look at the address bar of your browser, you may notice something new. I have added an RSS 2.0 feed of updates to the site. If you subscribe, you will be notified of updates: relevant events, blog posts, and new images in the Portfolio. ...

    VR Portfolio: Eyrie 2007
    <link rel="alternate" href="" />
    <content src=""
    type="image/jpeg" />
    Eyrie 2007 layout and design.

  • All red elements are required.
  • All orange elements are should be used or are required under certain circumstances.
    • <link rel="self" href="URL"> should be used under <feed>. This isn't "required", according to what I've read, but the feed validator really likes it.
    • The <author> element is required, but you have two options--either place it in each entry or generally specify it for the entire feed.
    • <summary> is required if <content> contains an src="URL" attribute or is encoded in Base64.
  • All purple elements are recommended.
    • Under <entry>, <link> can contain a permanent link.
    • Other <link> elements can be used.
    • Other <name> is recommended in favor of <email>.
  • All blue elements are optional.
    • <icon> should have a 1:1 ratio.
    • <logo> should have a 2:1 ratio.
  • In gray, the dates for atom:updated link to additional information in the specification.
    • The date should be in the format YYYY-MM-DD.
    • The time should be 24-hour in the format HH:MM:SS.
    • The letter "T" should separate the date and time.
    • A positive or negative time offset in the format -HH:MM
    • Or the letter "Z" (denoting UTC time) should be used.
    • Example: 2007-04-23T09:28:35-05:00
  • Also in gray, the unique ids used follow the Tag URI specification.

Syndication--RSS: 04/19/07

If you take a look at the address bar of your browser, you may notice something new. I have added an RSS 2.0 feed of updates to the site. If you subscribe, you will be notified of updates: relevant events, blog posts, and new images in the Portfolio.

Currently the feed resembles the Recent Updates list on the main page of the site. I am considering enclosing images in the feed, when appropriate, as well as (part of) the text of blog posts. Keep your eye out for these and other improvements in the future.

I chose RSS 2.0 after being assured by my reading that most RSS Readers supported several formats.

To be perfectly honest, I see very little to choose from between RSS 1.0 and RSS 2.0. I did a cursory comparison, and I liked the options in RSS 2.0. But I can't discount the the influence of RSS 2.0 being the tutorial on W3 Schools.

I find that a little strange, considering that they say, "RSS 1.0 is the only version that was developed using the W3C RDF standard." It seems to me that being based on the RDF standard would be a good thing. But, then, they also remind me of the obvious truth, "There is no official standard for RSS." What a mess.

However, since I'm generating the feed dynamically, I may add an RSS 1.0 and Atom feed--just for fun. Maybe once I use them all, I'll have more of an opinion.

Eyrie Release: 04/17/07

The Eyrie release reception was tonight.

I donated some of my artwork as raffle prizes: the Laissez Faire v4 photograph manipulation, the Wired photograph manipulation, and the Metro photograph manipulation. I framed those 3 and also raffled an additional Laissez Faire print unframed.

I realized after the work was done and I saw it being released that it's something I'll consider doing again next year. It's a stressful undertaking, but it's also rewarding when you finally get to see everything in print.

I consider myself primarily a web designer, not a graphic designer. There's a lot of argument about what the difference is and whether that's the right perspective to have. Regardless, I am glad for the experience with print graphic design. It's a whole different world.

Blog Introduction: 04/12/07

This is my first blog post. I'll be writing about the internet, web design, graphic design, and web development issues pretty much exclusively here.

I've got a sort of article in mind about columns from a design perspective. Expect to see that in the near future if all goes well.