Semantic markup in the RI

Topics: Web Guidance v-Next (not WCSF)
Jan 16, 2010 at 7:25 PM

The quality of the markup in the RI has improved a lot with the redesign. There are a few spots where I think it could be improved a bit more though. Considering this is an example of a public-facing site, getting the markup as semantic and accessible as possible is worthwhile.

(These comments are based on the 1/15 drop)

Overall

- Is there reasoning behind choosing XHTML Strict? The pages I checked don't validate XHTML Strict. I think XHTML Transitional or even going ahead to HTML5 would be better doctypes for this.  All but the DataView attributes validate under those two doctypes on the pages I tested (and that can be fixed). Valid markup isn't necessarily something to be dogmatic about in practice, but it's best not to tell the browser that the document is structured one way and then throw something else at it when you can easily avoid that.

- Don't use <b>. Use <strong> instead. <b> is basically like <font>.

- Reduce markup nesting that isn't necessary. There shouldn't be text content directly inside block element like <div>, but it's fine inside inline elements like <li> and <dd>. Burying the test within additional <span>s inside those inline elements isn't necessary or desirable.

- It appears that the album art is being displayed as a CSS background image on a <div> or <li> in several views. Those should be discrete <img>s (with good alt text like "[SongName] Album Cover"). Generally, you should only use a CSS background image if there's no way to achieve the same result with HTML.

/Search

- I think a <ul> or <dl> would be more appropriate than <span> and <p>s for the name, artist, album, and genre.

- In the paging, I don't think there should be a working <a> pointing at the currently displayed page. Screen readers and search engine bots won't necessarily understand that the disabledLink and selectedPage classes indicate that following the link is not useful.

/Songs/Show

- Great to see the definition lists on this page.

- Within that songDetails <dl>, the <dd>s don't need their content wrapped in spans. E.g. instead of <dd><span id="Artist">...</span></dd>, use <dd id="Artist">...</dd>

- <b>Reviews:</b> should be <strong>Reviews:</strong>

- Is there a particular reason for not using an <input type="image" /> for the delete review buttons? I'm not aware of anything gained by the background image on a regular submits there. Since they have no values set, it's currently not clear what those inputs do unless you see them rendered.

TopSongs

- Each <li> in the #TopSongs <ul> should probably contain another <ul> or a <dl>, not <p>s.

- No need to wrap the single <a> within a <p>.

/Library

- Same as in other areas, the content of <li>s in the .songs <ul> could be structured better. Those <p>s would be better as an <ul> or <dl>. No need to nest the <a> within another element.

- It appears that the .songs <ul> is nested within a superfluous <div>.

/Profile

- The user's photo/avatar shouldn't be a background image on #editProfile, but an <img>.

- After talking up the <dl> so much elsewhere, I hate to say it, but those form elements shouldn't be nested inside a <dl>. The <label for> alone is correct. I'd suggest something simple like this example for the form's markup.


Good stuff overall though, compared to earlier versions. Don't take any of my suggestions as overly critical. It's great to see appropriate attention given to the quality of the markup.

Coordinator
Jan 20, 2010 at 3:55 PM

I'll assume the lack of discussion on thread to mean that everyone agrees with Dave's (Encosia's) comments. I'll go and add these items to our sprint backlog. Thanks Dave!

Jan 20, 2010 at 4:38 PM

I agree with everything that Encosia has said. I would only add that a benefit of background images over <input type="image" /> is CSS sprites, i.e. the use of the background position CSS property. That said, I'm not aware of a background image implementation that works in Opera.

Coordinator
Jan 21, 2010 at 8:39 PM
Edited Jan 21, 2010 at 8:40 PM

Thanks for the feedback. Regarding the image button for search and for delete review, we are going with the following markup:

<button id="Search" type="submit" class="searchButton" title="Search">Search</button>

And the CSS will be:

#SearchBar

button.searchButton {
  
width:18px;
  height: 18px;
  margin: 0;
  padding: 0;
  border: 0;
  background: transparent url(../images/skin-01/ico-search.jpg) no-repeat center top;
  text-indent: -1000em;
  cursor: pointer; /* hand-shaped cursor */
  cursor: hand; /* for IE 5.x */
}

What do you think of this? I believe it keeps the semantics correctly, works with or without CSS (which is good for accessibility).
I took this approach from this site: http://www.ampsoft.net/webdesign-l/image-button.html

Thanks,
Julian Dominguez
http://blogs.southworks.net/jdominguez

Jan 22, 2010 at 2:09 AM

My preference would be:

<input type="image" src="../images/skin-01/ico-search.jpg" alt="Search" width="18" height="18" />
 
Is there a particular reason for using the CSS image replacement instead?

Coordinator
Jan 25, 2010 at 11:21 PM

Well, that could be done and it works, the only issue is that that input will try to submit its own values (the X & Y position where the image was clicked), and because this is submits a GET request, these values will end up in the querystring, and you'll see the URL with something like http://server/Search?query=a&x=0&y=0.

Not a big deal, but it pollutes the URL a little bit :)

On the other hand, my (subjective) opinion is that a button is more semantically correct, so if you don't have any styling (i.e. disabling CSS/bots/etc), it makes sense that this image would not be shown, as it is also part of the "style" of the application. This image could also be replaced by a different skin/CSS without modifying the markup (not that you will do that all the time/ever in all your apps, but serves to prove that this image is really styling other than data in the HTML).

What do you think?

Jan 26, 2010 at 1:20 AM

That's a good point about the GET request and messy URLs.  I hadn't considered that, and think you're right to avoid it.