Two types of images

As designers, we realize that there are two ‘types’ of images. Those which we reference in our style sheets which in turn inject imagery into a document, and those referenced within the markup itself.

Each type of image carries with it a specific purpose and value. At the most basic level, the fundamental difference between the two types of images is meaning. Images referenced in markup should contribute to that document in some meaningful way. Images included via stylesheets, however, should not carry with them any informational value.

I think it’s sometimes easy to forget that, even as you become a seasoned developer. The biggest issue I’ve noticed with myself, which in turn sparked my recent focus on the subject, was the arbitrary inclusion of image replacement when it wasn’t completely necessary.

Images versus image replacement

Image replacement is a technique near and dear to the hearts of many. Countless articles have been published on the subject, and it seems to be an applicable conversation to have on a fairly consistent basis. I myself have tried to add some value to the conversation by publishing a few pieces on the subject over the past couple years. Some of which include:

• Typography in Headings: sIFR? Image Replacement?
• My Latest Take on Image Replacement

Looking back on those articles, I realize that I was still a bit overzealous when writing them. I think it’s part of every developers growing process to take new techniques under his or her wing after it is first learned, and run for the end zone with it. Image replacement is one of those techniques. When we first learn that our style is completely separate from our structure, every image becomes stylistic. We want to remove everything from the document and focus on keeping our markup and lean as possible. It turns out that for many, we optimize to a fault.

As of late, I’ve been questioning image replacement itself. By definition, when we use image replacement, we’re effectively injecting a meaningful image into the style layer of a document, all the while using various techniques to ensure the original content provided from markup is hidden from view. Through this process, we make it very difficult for assistive technologies to properly recognize the content as valuable.

Looking at Monday By Noon today, we can see that not only was I overzealous with image replacement, but also itching to use an image sprite as well. I can add those two items to the list of reasons I’d like to redesign!

Taking a step back and looking at the big picture, we can see that:

1. Our markup is (mostly) solid, as we often need to include a possibly unnecessary class/id to act as a hook for our CSS
2. We’re abstracting a meaningful image
3. We’re attempting to inject that meaningful image through CSS
4. We force our original content out of sight by way of properties designed to obscure existing data

We do all of this, yet HTML has provided us with an element dedicated to taking care of everything in one fell swoop. I’ve come to realize that img is an underused, undervalued element by many developers.

Remembering to use img properly

HTML provides us with the img element. Not only can we include our meaningful images (i.e. headings) within the markup as intended, we can provide directly applicable alternate content (alt attribute and longdesc attribute) directly within the original document. It is by far the best way to gracefully degrade for imageless browsing, and abundantly more straightforward than any of the various image replacement techniques available to us.

We can’t forget the reasons we’ve tried and tested image replacement techniques, however. Modern Web design is far and beyond more complicated than HTML and CSS can support alone. We’re using the tools to their fullest potential, and then some. We have to get creative sometimes, and image replacement originated from a need.

My personal focus for the past few projects has been to get back to basics and use images in their original intention, and I must say that documents feel more stable, more structured. I like that I’m not obscuring information in any way, instead using the gifts HTML gave us to provide a seamless experience.

This approach has really only come into play for me when it comes to headings, more specifically static headings. Dynamic headings are a different subject entirely, something that deserves an entire article. The biggest hurdle with headings, however, is to make sure they blend with the surrounding environment. Make sure you’re using the Matte when saving a transparent GIF for Web, it will make your life that much easier:

Setting the matte on a transparent GIF will help you to match the edges of text to the background over which you’re laying the image. You’re probably wondering why we don’t use PNGs instead. I won’t get in to details but it starts with an I, ends with a 6, and has an E in there somewhere. Enough said on that topic.

Using images directly within headings can be an effective way to retain document structure for assistive technologies and search engine friendliness. Your heading markup can look something like:

<h1><img src="images/companyname.gif" alt="Company Name" /></h1>

Google should much prefer something like the above as opposed to an obscure image replacement technique. The information is blatantly available, and there is no overlapping meaning when it comes to the separation of structure and style, right?

In conclusion

I hope this throwback topic helps you to analyze how you’ve been using images in your designs as of late. Perhaps you, as I did, needed a quick refresher on the overall document as opposed to overusing a particular technique when it may not be needed.

Advertise here with BSA

So it’s been made clear to me that these folks don’t like CSS frameworks and don’t think they should be used (except, in some cases, for rapid prototyping). What’s not clear to me is why they feel this way. So, I’m asking publicly, and hoping these folks will show up here to give me their answers: What is it about CSS frameworks that bothers you?

I think that’s a completely valid question to ask, and with it being asked by someone whom is heard by many, he was sure to get many answers. Within hours, the comments came pouring in from many designers and developers, each giving a personal reaction to their experience with CSS frameworks. There were also some notes included which may have strayed from the articles main topic of CSS frameworks, and I’m going to stray from commenting on that issue because it wouldn’t be fitting for this post.

The general problems with CSS frameworks

I was really happy to see how much of a reaction Mr. Croft’s article received. While many people simply can’t understand why there is so much talk on a seemingly tiny subject, personally I’m glad to see it. I’m glad to see that there is something which can come under debate and be well argued by both sides. That’s not something you often find when it comes to modern Web design among intelligent, professional designers and developers.

While reading through the comments, the consensus from those who choose not to work with a CSS framework was nothing that has not been said before. Some people find a CSS framework limiting to their process or design methods, and others mentioned problems that tie into any framework. Learning to the framework instead of the technology itself, for example. While it was great that people were responding to the article, Mr. Croft mentioned that after 30 comments, his question was still not directly answered.

That got me thinking, even though I had taken a minute to leave my thoughts, I thought I did answer his question in the best way I could. I mentioned why I personally wouldn’t use a CSS framework at this point and time, moreover included a bit of detail regarding why I wouldn’t recommend the use to a fellow developer quite yet. Other comments shared similar thoughts, while others completely opposite, but there was really no direct answer quite yet. This trend continued throughout the comment thread and really got me thinking.

Could the question be answered? I tried myself to come up with a definitive answer(s) why I’m not quite ready to adopt the use of a CSS framework, but found a rebuttal at least once in the comment thread alone. I then tried to put myself in the shoes of a developer who chooses to actively use a CSS framework and defend my camp from that angle. The same result occurred. It seems for many of the arguments either for or against CSS frameworks have a related counter-argument, which could be the reason this debate has been circular for so long.

At the end of the day, what is a CSS framework?

After reading both the original post by Mr. Croft, and then his Follow up on CSS frameworks (and each comment posted in reply), I’ve come to the conclusion that the majority, including myself, have associated the phrase ‘CSS framework’ with blueprintcss. That’s the first problem with the CSS framework debate as a whole. Mr. Croft pointed out that many people who opposed the use of a CSS framework (blueprintcss to be more accurate) were actually using one.

Mr. Croft mentioned that the definition he has had in his mind from the start has been:

… a set of tools, libraries, conventions, and best practices that attempt to abstract routine tasks into generic modules that can be reused. The goal here is to allow the designer or developer to focus on tasks that are unique to a given project, rather than reinventing the wheel each time around. Generally speaking, this is the approach taken by the aforementioned JavaScript and web application frameworks. To be clear, we’re not necessarily talking about something that is built, packaged, and released to the public. Rather, a framework may be solely for you or your team.

From this definition alone, it approaches silly to mention that [many] designers and developers aren’t doing such a thing already. I know I’ve said more than once that I use a preexisting set of folders and (sometimes empty) documents when starting a new project. While it is nothing compared to the level of blueprintcss, it is a reset style sheet, as well as a folder structure to save me a few minutes at the start of each project. At first, due to plain simplicity, it hardly occurred that such a system could be considered a framework, but I think that’s exactly the type of thing Mr. Croft is so diligently trying to defend.

We’re all on the same team

Many of the comments in response to the articles posted by Mr. Croft were a question why a topic such as this is debated so much. I can sympathize with that question, but at the same time, I’ve done my fair share discussing the topic because I find it interesting. There were many people on one side of the fence, seemingly just as many on the other, and a third group of people in the next field chatting about something completely different.

I’m glad Mr. Croft sparked what may act as the last great discussion surrounding CSS frameworks at this level of maturity. While I don’t see the debate dying out any time soon, I think these two articles, paired with their comments, are a great collection of thoughts after the initial introduction of blueprintcss (which put CSS frameworks on the map).

If you haven’t had the pleasure of doing so, take a few minutes soon and read over the articles and comments. Take some time to think about whether or not something as particular as blueprintcss or something as general as a reset style sheet is going to help you. The great thing is, designers and developers have reached a level where we can really begin to think about helping ourselves as much as possible. At the end of the day, we’re all on the same team, working for the same goal. Everyone has a different way of doing things, time and experience will certainly put any questions to bed. As the title of this piece explains, I think what has been said about CSS frameworks is quite comprehensive for this stage of maturity, but I’m more than willing to discuss the idea at any time.

Advertise here with BSA

I can absolutely see the benefit to a CSS framework in that regard, and I think that’s where my sensational title of a couple weeks ago skewed the tone of the entire article. Some readers (understandably) felt that I saw absolutely no worth in a project such as a CSS framework. That’s not the case, entirely. I simply see some issues that could be counteractive, and those issues can [usually] be applied to nearly any framework in existence.

Frameworks are a fantastic idea, fantastic, but I’m sure we can all agree that there is an extremely high potential for ‘learning the framework’ as opposed to learning the language itself. This is a major issue to keep in mind, especially with something like CSS. One of the other issues I’ve got with the implementation of a CSS framework is semantics.

Semantics and CSS? Applicable?

The resulting discussion surrounding the release of Blueprint itself has been utterly fantastic. Many great minds have left opinions on the release. The pros, the cons, the ridiculousness surrounding the reaction of such a release. I’ve tried to read as much as I can of this conversation, and some interesting ideas and thoughts have come up.

One of the more interesting points brought up was that surrounding the semantics of class and id names. While I feel that semantic value can be given to a class or id, other developers thought it was simply ridiculous, that they are there to act [more-or-less] as hooks for CSS and JavaScript. Others felt that the classes and ids used in Blueprint are applicable because values such as .prepend-8, .pull-2, and .span-22 were spot on in their use.

My stance is the following: if a class or id can be given a more descriptive value, why not? While some developers feel that it is the markup which needs to be semantic, I can see a value in trying to create more semantic classes and ids. Microformats are a prime example. Microformats may not use values which are initially obvious to their meaning, but their objective is such. Microformats use classes in an effort to better define data in a semantic way. Why not try to carry this over to the rest of your document?

From what I can gather, it seems as though some developers feel that trying to create a semantic class or id is just silly. What do you think? Is a class little more than a hook for CSS to apply some style?

Are semantics applicable with only an associated meaning?

Microformats make sense to those who have worked with them before. Each class has a meaning because there is a large set of documentation to back it up. Without that documentation, would the class still be semantic? This same issue carries over to Blueprint. At first glance, the classes used are awkward and seemingly meaningless — until you read the documentation. Is it at that point they obtain semantic value?

I think to those who have come to accept and use Blueprint on their projects, there is a resounding yes. This concept (and reaction) is closely related to Microformats; some people agree, others don’t. If you’re familiar with the framework, Blueprint has attempted to keep class names partially semantic.

So, what’s the problem?

While the classes within Blueprint attempt to retain semantics when taking the entire framework into consideration, it does so only to provide meaning for the visual elements involved. It is literally impossible for Blueprint to take into account the actual information presented. I think this is where the issues regarding semantics come into play.

Is there a divide when taking into consideration the semantics of (X)HTML versus the semantics of classes? Are they one in the same? (X)HTML has a set of defined tags, each of which inherits a meaning. CSS is different entirely, allowing the author to define much of which comprises a completed stylesheet. It is up to the author to understand a meaning applied to any class or id he chooses. Can semantics still be applied? In my opinion, yes they can. When I’ve got a project in front of me, I’ll try to best define the provided information using meaningful classes and ids not only to help me remain more organized, but also in an attempt to help others on my team get up to speed quickly when working with my markup and style.

I’m really quite curious to hear how others feel about this ‘situation’. Are semantics completely inapplicable when it comes to CSS? Do you feel as though trying to create semantic classes is simply overzealous? Without the structured definition and documentation of (X)HTML to back it up, is CSS better left to be implemented on a ‘what works’ basis? Are semantic names that only describe visual orientation as meaningful as valuable as those which describe the informational meaning? Do you feel this topic is just beating a dead horse? Please, provide your opinion.

Advertise here with BSA

Destroying aesthetics with each update

Personally, I think content management systems are an extremely effective way to increase functionality and organization of websites large and small. They come in extremely handy when providing a website as a product for a client, allowing updates to be made at any time without the assistance of the site developer. While all intentions can be positive, sometimes a gorgeous product can be all but destroyed upon delivery when it comes to creating or modifying site content. With each update, a well thought out design can be further altered from original intention, reflecting poorly on the site aesthetics. There are a number of ways for clients to make updates in various CMSs, but which is best?

WYSIWYG

First and foremost is WYSIWYG content editing. This option, to me, seems most appropriate for people who have no experience with (X)HTML and are looking for the easiest way to make updates to their content. It is probably the most attractive option for clients as it bridges a gap between the copy they’re editing on the back end and the copy displayed on the front end.

I’ve got a bit of a personal gripe with WYSIWYG editing, not only when it comes to any particular CMS, but in general as well (when it comes to the Web). While there are benefits to this form of editing, they all lay with the particular user actually making the edits to the content.

Most of the time, the markup which results from WYSIWYG editing is far from semantic, and often gives the editor far too much control over how various elements appear. All of a sudden, copy can be filled with long strings of bold, underlined, and italicized text simply because the icons are there to click. Awkward font colors and sizes are suddenly used throughout the website, and greatly degrade the overall look and feel the original design worked to establish. What is the best way to handle something like this?

Markdown & Textile

Plain text and readable editing systems have become a very popular way to give the ability to edit content while attempting to retain a semantic and valid document structure. While the resulting interaction is (more or less) easy to read and decipher, it still requires a bit of a learning curve to undertake. There is a certain breed of client that would be willing to put forth the effort to learn a tool such as Markdown or Textile in order to manage the content of their website. To be completely honest, I would have to say the majority of clients I’ve directly worked with would greatly prefer a WYSIWYG editor. As a developer, however, I’d definitely prefer a plain text editing system simply because of the comfort in knowing the resulting markup will be valid and (mostly) conform to the styles established in the site design.

BBCode

Another system implemented in some of the wide range of CMSs is that of BBCode, a markup language originally established for use in forums. BBCode shares a bit of raw (X)HTML and Markdown/Textile in that plain language is used, but proper tags must be maintained in order to obtain your intended results. While this form of editing has more-or-less stuck to forum installations, it’s another method to consider.

WYSIWYM

There are many ways to implement a system of editing in a CMS, each with their pros and cons. By far, the most attractive solution I’ve come across to date is WYSIWYM editing. The idea is a healthy blend between WYSIWYG to help make ‘the sale’ to the client, while including the importance of each element used. Styles can be directly applied in order to assist the editor visualize how published copy will appear, but proper attention is also given toward the markup involved.

At first glance, this system seems to seek the happy medium between client and developer approval. While the idea is fairly young (to me at least), and the flagship editor, WYMeditor is still in it’s infancy, I think this direction could bring some extremely positive results.

Conclusion

Content management systems try to cut the middle man out of site maintenance for site owners, but is it acceptable to completely stray from the way things work? Is hiding the markup that makes the Web work the right thing to do? Something about that doesn’t sit well with me completely. Playing devil’s advocate, does HTML belong only in the hands of developers? I think this is a bit of a gray area, but I’d love to hear what many of you think.

All in all my personal favorite of this bunch is WYSIWYM editing. Having the benefits of a visual depiction as well as maintaining semantic value seem like the ideal situation to me. The trouble we face is the fact that our clients can not be expected to understand (or care about) the semantic Web, accessibility, or the intention behind our designs. Which system of editing does your CMS of choice employ? Have you had past projects lose aesthetic appeal as a result of giving editors too much freedom with editing? What do you feel is the most effective system of editing, both for the client as well as the semantic, accessible Web?

Advertise here with BSA

To me, keeping graceful degradation in mind while developing will aim to leave you with a functioning document no matter the circumstances. Progressive enhancement on the other hand, is a level of functionality present only if the reader has the needed technology readily available. While it may seem that both are nearly identical, to me graceful degradation seems to be more passive in nature when comparing it to progressive enhancement, which is a more active. Progressively enhancing a document gives the ability to make alterations where applicable in an effort to make a document that much more useful, while graceful degradation is more of a fall back plan.

Separation of structure, style & behavior

At the root of Web standards comes the idea of keeping the structure, style, and behavior of a document separated by making use of (X)HTML, CSS, and JavaScript, respectively. While only a partial explanation of the idea behind Web standards, the separation is the basis for best practices and accepted techniques. By keeping these three facets separate, you’re able to produce work with a caliber of maintainability and organization that otherwise goes unmatched.

While keeping structure, style, and behavior apart is a generally accepted practice by professionals and amateurs alike, we’re constantly faced with solutions that blend the technologies together. There are many applications JavaScript which constantly make use of element.style or a comparable snippet which directly adjusts the rendered style of an element (or group of elements). Lots of developers don’t see any issue with something like this because your end product is the desired change. In my opinion, it’s easier for a designer to forget that the style and behavior of a document are being mixed simply due to the syntax of the JavaScript. It is less apparent the style is directly being manipulated.

When looking at this circumstance in more detail, it becomes apparent that directly editing the style of an element via JavaScript can be juxtaposed to using a set of font tags to set some text apart. In my opinion, a better way to handle something like this is to provide the element with a class as opposed to directly altering the rendered style. This way, the only edit made using the DOM is an element’s class, which is styled within the style sheet.

A more interesting situation

While directly changing the style of an element can be easily resolved, there are many circumstances which make a solution much more complicated. The combination of (X)HTML and CSS gives designers and developers a fantastic tool set to create amazing, accessible, standard websites. While many great things can be done with markup and style alone, there are many times a design needs to be brought to the next level. Whether it be a client request or an unforeseen hurdle during a design phase, there are certain times that (X)HTML and CSS aren’t going to provide everything needed by you as the designer or developer.

It is in those situations where JavaScript comes into play. As many pieces of JavaScript directly manipulate the style of an element, but the core purpose of using JavaScript is directly manipulating the structure of a document. Long ago this was accomplished using ugly instances of document.write, but that practice has been replaced by interaction with the DOM. DOM scripting is a much more effective way to use JavaScript in an effort to control the behavior of your document.

Using the DOM to prepare for your CSS

While many fantastic techniques have come from progressive enhancement through DOM scripting, there is an area of DOM scripting which I’ve become partially weary about implementing. This gray area comes about when JavaScript is used to manipulate the DOM for the sole purpose of achieving an effect otherwise unattainable using semantic (X)HTML and CSS. While the resulting markup is more than likely valid, after the application of JavaScript, it is bloated from additional nodes needed to achieve a desired effect.

I’m timid about using scripts such as these due to the fact that it seems as though you’re using the document behavior to alter the document structure for the sole purpose of styling the document differently. It is a bit of a gray area to me because while the structure, style, and behavior are still maintained separately, the resulting markup is bloated and has lost semantic value at the cost of adding a design element that is not otherwise possible.

Going back to the original dilemma of a project requirement, however, solving the issue using a solution such as this seems more favorable than including the bloat in the markup from the start. There has been an ongoing discussion regarding whether or not it’s required to provide valid and semantic markup when manipulating the DOM. In my opinion it goes without question that the integrity of a document should be maintained regardless. Simply because (many) search engines do not process JavaScript, you’re not given the liberty to do with the DOM what you please. Expanding upon that, just as important is maintaining semantic markup when manipulating the DOM. This is where things become shaky as far as my stance is concerned.

On one hand you are striving to include a design element keeping best practices in mind, but on the other hand your resulting markup (after interacting with the DOM) is anything but ideal. At this point, what is the solution? Is it better to neglect the issue as a whole and work with what you’ve got? Is a bit of code bloat while DOM scripting an issue that needs serious consideration?

Some time ago I was browsing the threads of a forum with a particular discussion being centered around proper markup used to create accessible forms. I took a minute to provide my opinion, which, at the time seemed to me like the best solution. The technique was using as little markup as possible in an effort to avoid code bloat, something I was working very hard to do in all cases. Shortly after, two developers whom I hold in high regard, offered their opinion on the matter explaining the faults in my suggestion and offering their own. The developers were Jonathan Snook and Kyle Neath, two people with opinions I greatly respect and use their writing to expand my own knowledge. Their solution called for a bit of extra markup, but the additions made sense in the overall structure of the document in consideration. Point being; not all additional markup can be labeled as bloat.

Some questions I’d like to discuss

I’ve got some questions for the community as a whole as a response to an issue such as this. First and foremost: do you feel this is an issue at all? Is it simply making effective use of accepted technologies to achieve results not otherwise possible? Is using the DOM to generate bloated documents for the purpose of more elaborate style taking things to an unacceptable level? As designers, should we only be allowed to work with the tools we’re given and leave design elements limited to what can be done with (X)HTML and CSS alone? What other opinions do you have on the matter?

Advertise here with BSA

Limitations range greatly from one CMS to another, some have embraced Web standards and produce semantically rich and valid markup, while others have put standards on the back burner. One issue I’ve had some reoccurring trouble with in the past is the combination of a CMS with managed images that are part of the design as opposed to having informational value. To be more clear, sometimes a client will request to have control over a piece of stock imagery represented on any number of pages. This becomes an issue because traditionally, when images are uploaded in context, they’re treated as having informational value and included using an img tag with a descriptive alt attribute.

So what’s the problem with inline images?

There’s nothing at all wrong with inline images — as long as it is applicable that they be represented in the markup as an inline image. When images are included in the markup, they should have informational value. Images with the sole purpose of adding to the design can be better included via your style sheet as to preserve the separation of style and content.

Inline images definitely have their place on the Web, but it is a far different position than images used for the site design purposes only. Those images should be included via the associated style sheets, defined either by hand, or through the theme management of the CMS. Keeping that in mind, there can be a time when images that should be defined using CSS are instead included via the CMS front end.

What can be done about the situation?

The trouble with trying to give a client control over design-oriented images is when it comes to referencing the dynamic content. With inline images, it’s easy in that the image URL can be pulled from the back end and used in any way you please. It becomes a bit harder when a style sheet needs to be updated with a change in URL. I’ve read an article or two about using PHP (or any other server side language) to generate style sheets on the fly, but including PHP echos in CSS doesn’t sit well with me. It also restricts that style sheet to the language in which it has been written, therefore forcing an otherwise unnecessary update should the style sheet be written strictly in CSS.

Another way to go about things would be to have the CMS handle a number of style sheets the can be, as was an original intention, cascaded upon one another. These files could be generated, taking into consideration any images that are managed via the CMS, and then included with the site CSS.

A more abstract method that could be possible is using a static URL in your style sheet that references the dynamic image, but instead of updating the URL, the CMS will update the image file itself. Effectively the URL remains the same, but the target image itself can be updated by the client via the CMS.

What’s this got to do with inline styles?

While any of the above can be considered a solution, not everybody has open access to the inner workings of their CMS. Sometimes you’re literally stuck with an image URL and that’s all you get. At this point, is it better to include the image as a background-image via inline CSS? Is it acceptable to ignore document semantics and include the image inline?

In my personal opinion, I think I’d opt to go with using inline CSS and a background-image as opposed to sacrificing semantics. While inline CSS is considered difficult to manage, in this case the CMS is doing the management for you. While the end result isn’t completely ideal, I have to consider it more appropriate than using an inline image.

Is this an issue you’ve ever had to worry about before? Do you really consider it an issue at all?

Advertise here with BSA

Moving on, Google is using tables to mark up their driving directions provided via Google maps, but in my opinion, there’s a much better way.

There is actually quite a bit of information provided in simple driving directions. For the purposes of this article, I’d just like to focus on the directions themselves, as opposed to the content offered before and after, as well as the maps that are (usually) included.

Driving directions at their core

At the very least, when providing driving directions, you’re compiling an ordered lists of steps that need to be followed in order to navigate from point A to point B.

<ol class="driving-directions">
  <li>Head southeast on Crossgates Mall Rd - 0.2 mi</li>
  <li>Turn left onto the Washington Ave Ext E ramp
    to I-90 Thruway/I-87 - 407 ft</li>
  <li>Merge onto Washington Ave Ext - 0.9 mi</li>
  <li>Continue on Washington Ave - 3.9 mi</li>
  <li>Turn right at Robin St. - 417 ft></li>
</ol>

While a single ordered list could be considered acceptable, there is quite a bit more information provided that has semantic value. For instance, in each step of the ordered list, there is detail given as to what actions should be taken, as well as a measure of distance. To me, this is a good place to include a definition list. It seems fitting to mark up this pair of data using a definition list as you’re relating both the action and the distance traveled. The distance traveled is a direct result of the action being taken so a definition list would work well.

<ol class="driving-directions">
  <li><dl><dt>Head southeast on Crossgates Mall Rd</dt>
    <dd>0.2 mi</dd></dl></li>
  <li><dl><dt>Turn left onto the Washington Ave Ext E ramp
    to I-90 Thruway/I-87</dt>
    <dd>407 ft</dd></dl></li>
  <li><dl><dt>Merge onto Washington Ave Ext</dt>
    <dd>0.9 mi</dd></dl></li>
  <li><dl><dt>Continue on Washington Ave</dt>
    <dd>3.9 mi</dd></dl></li>
  <li><dl><dt>Turn right at Robin St.</dt>
    <dd>417 ft</dd></dl></li>
</ol>

To me, using a combination of an ordered list as well as integrating a definition list results is a much more semantically rich set of driving directions.

A quick note about address

From time to time, I’ll come upon some markup that uses address incorrectly. address is defined as:

The address element may be used by authors to supply contact information for a document or a major part of a document such as a form. This element often appears at the beginning or end of a document.

Without reading the definition, I can understand why some people may assume that address is used to mark up a segment of data that represents any address, but in reality, it is used to distinguish how to contact those responsible for the document. It isn’t applicable to use the address tag to mark up the street address of each step here.

What about imagery in driving directions?

Many times, driving directions include images which help to classify what information each instruction is providing. There may be an arrow indicating which direction to turn, an interstate sign, or something like a traffic light to indicate a future encounter. How should these images be included? In my opinion, this is one of the times where semantic image use should be looked into. Taking a step back and thinking about it, these images are unique in that they aren’t part of the site design. They’re in place to convey pieces of information to the reader. Making the adjustments to our example:

<ol class="driving-directions">
  <li><dl>
    <dt>Head southeast on Crossgates Mall Rd</dt>
    <dd>0.2 mi</dd></dl></li>
  <li><dl>
    <dt><img src="images/turn-left.jpg" alt="Image signaling
    a left turn" />Turn left onto the Washington Ave Ext E ramp
    to I-90 Thruway/I-87</dt>
    <dd>407 ft</dd></dl></li>
  <li><dl>
    <dt>Merge onto Washington Ave Ext</dt>
    <dd>0.9 mi</dd></dl></li>
  <li><dl>
    <dt>Continue on Washington Ave</dt>
    <dd>3.9 mi</dd></dl></li>
  <li><dl>
    <dt><img src="images/turn-right.jpg" alt="Image signaling a
    right turn" />Turn right at Robin St.</dt>
    <dd>417 ft</dd></dl></li>
</ol>

Alternatively, it would be argued that the dt provides the instruction and the image is merely redundant. I think that is the decision of the developer, but I do feel it is more applicable to include these ‘helper’ images in this way as opposed to being a background-image to the dt. What do you think? Should an element be classed and provided a background-image as opposed to including the image inline? What other ideas do you have to improve the example?

Advertise here with BSA

When browsing around the Web lately, I’ve been excited to read that many other developers seem to feel the same way as me. A new discussion has been brewing among Web developers on the topic of POSH. This recent revival seemed to at least partially stem from an article written by Jeremy Keith entitled POSH Patterns. POSH (Plain Old Semantic HTML) has the potential of becoming a buzzword much like “Ajax” and “Web 2.0″, but to me, this buzzword stands out from the rest. Should POSH catch on in the same way, it would benefit not only each and every developer who researches it, but any website they work on as well. It is, by nature, difficult to abuse or misuse.

I’d like to start doing my part in spreading the word about POSH in starting a sporadic series of articles on the subject, much like the ‘Improving your Process‘ series. In the articles I’ll take a real world example that will hopefully be found useful by developers at some point in their career. I’m also hoping that the articles will spark some lively conversation in both agreement and opposition to anything I bring up. I don’t want the articles to be looked at as the final word in the least, I’d just like to offer my opinions and be completely open to any and all reactions.

The first article in this series, had I thought of it at the time, would have to be my questioning of calendar semantics, an article in which I ask which is more appropriate for marking up a calendar: a table or a list? There were some great comments in response to that article and I hope a similar situation results from those upcoming in the series.

Applying POSH to restaurant menus

The first official article in this series is going to take a close look at how you could mark up a menu for a client running a restaurant. When you think about a menu, most of the time the name of the dish is offered, as well as a description and of course, a price. When you break down what needs to be marked up, we’re given the ability to analyze how elements can be used in cooperation with semantic HTML.

There are a number of ways you could mark up a restaurant menu, the most simple that comes to mind is a group of headings and paragraphs which hold the dish name and description/price, respectively. That’s not the worst way to go about things, but there is something better that can be done. Definition lists seem like a perfect way to handle marking up a restaurant menu.

Definition lists are, in my opinion, underrated

Definition lists are something I find myself using all the time since discovering their usefulness. If you take a look at a project you’re currently working on, there’s a good possibility a list you’re using could be considered a definition list. Definition lists are not strictly limited to terms and their definitions. Definition lists are used to list items that consist of two parts: a term and a description. There are many times that a list of items consists of two parts that are directly related.

Beyond their semantic usefulness, definition lists are quite a blessing when it comes to styling them. The elements are structured in a way which allows you to achieve a very organized and tidy look without bloating your markup. If you aren’t currently making use of definition lists on a fairly consistent basis, I’d highly recommend it where applicable.

Applying a definition list to a menu

When marking up a restaurant menu, I would include the dish name as a dt element, and then the description and price as separate dd elements. To me this makes sense because both the description and price are directly related to the dish title. Keeping POSH in mind helps us to also provide meaningful class names for the elements by applying class="price" and class="description" to each dd not only to distinguish a difference between the two, but will also help out with styling the list.

<dl>
  <dt>A Sample Dish Du Jour</dt>
  <dd class="price">$8.99</dd>
  <dd class="description"><p>Lorem ipsum dolor sit amet,
    consectetuer adipiscing elit. Morbi suscipit urna placerat
    turpis. Vivamus id sapien eu augue pellentesque tincidunt.
    Proin vel ante aliquet pede congue porta.</p></dd>
</dl>

There are also some items on a menu that may not have either a price listed (if the prices are noted elsewhere) or a description (for something like the soup du jour). Those items can simply be left out, and the associated class will help to keep your styles in tact.

Other elements required by a restaurant menu

Not everything included in a restaurant menu can be marked up using a single definition list. In actuality, multiple definition lists, headings, and other lists will be needed to effectively mark up an entire menu. The different menu sections can be included in their own div including their own heading, as well as class to help distinguish a lunch menu from a dinner menu for example.

Going further, every list in a menu won’t always be a definition list. There is often a need for an unordered list for one reason or another in a restaurant menu. What counts is that each section is taken into consideration and ends up using what makes the most semantic sense. There will also more than likely be an appropriate place to use an address element, providing any location details or phone numbers for the restaurant.

I’ve attempted to be mildly general in taking restaurant menus into consideration. It’s very likely that there will be more to take into consideration when actually implementing a menu, but hopefully this article has set the wheels in motion as far as a thought track is considered. Have you had to implement a menu online before? What markup did you use? Do you agree that a definition list is the way to go from here on out? Or do you think I’m completely wrong and feel that there’s a better way? What other opinions do you have on the matter?

Advertise here with BSA

To this day, I try to read as much as I possibly can about design and development, and I’m always seeing new and improved ways of doing things. Not because it’s using the latest trend on the Web, but because it makes more semantic sense, or is more accessible. In the long run, that is what’s important.

Developing the standard, semantic, and accessible Web is an ever changing process. As time moves on, there are better and more effective methods of presenting information (and design). I’m constantly looking at past projects, realizing there are aspects that need to be updated as there are better ways to do certain things. It could be a single document element, or an entire range of things that spread site-wide. The point I’m trying to make is that when it comes to Web development, it’s impossible to know everything, and it’s important to want to keep learning.

My Development Begins with the Markup

I quickly learned that it’s much more time effective to separate the development of a website into parts; markup and style. When starting work on a new project, I’ll usually receive an approved mock from a designer. My first step is an attempt to envision the overall structure of the document. I’ll first pick out the overall structural elements that need to be put in place. From there I’ll pick out such things as divisions, lists, paragraphs, headings, and definition lists, as those are the most common elements I end up working with. This process of envisioning the document structure doesn’t take long, but proves to be extremely valuable.

Take, for example, a page of Google search results:

A Google SERP isn’t the most involved design, but I think it gives good insight as to what I’m talking about when I say that I try to visualize the structural elements of a design mock before I begin writing markup. Usually now when I’m faced with a mock, it’s hard not to think about what elements would be best to structure the end design.

Ideally, when a new project is started, I like setting up the site during the time the designers are working on mock approval. Although it doesn’t happen with every project, it helps when it does. The site design should not distract your markup from being semantic. Having a working version of the website put together with no style is comparable to viewing the end product in a text-based browser, as the style doesn’t visually structure the content and you’re browsing naked documents. More often than not, if I’m able to mark up the site before a mock is approved, I’ll have to go back and add some structural divisions or make some other adjustments, but they’re usually minimal.

I will always suggest writing your markup first, as it will allow you to give more focus to the semantic value of each element. It will help you to keep your code organized and clean, which in turn helps keep control of validation errors. You’re able to limit your markup to an acceptable minimum and put everything in a logical order, as opposed to moving elements around in order to compensate for your CSS.

Producing the images needed for the design

Once I have the markup complete, I will begin to think about the design. The first step for me is gathering all of the images that when put together, will form the design in its entirety. This step has become easier as I put together more websites in that I’m able to think about images as a background-image, visualizing their repetition where applicable. Experience will also provide you with knowledge about specific cases where one technique will work out significantly better than another. I realize that’s a very big generalization, but it’s hard to get much more specific as every design is completely different than the last. The process becomes increasingly easy with each project as you pick up your own tricks along the way.

I try to have a naming convention as far as images are concerned. That way, when it comes to referencing them in my CSS, I can easily tell which image belongs where. I usually give background images a ‘bg_’ prefix followed by a meaningful identifier. Navigation images can also be prefixed with ‘nav_’. There are also other project-specific cases where a prefix can come in handy. Another technique I’m a big fan of is working with are CSS sprites, which are easily identified if you use a descriptive filename. They help keep image file counts down, and limit the number of requests that need to be made on a page load. I choose to use file prefixes as it keeps them more organized not only for active use, but also when viewing them in a file browser or FTP client.

Now it’s time to apply the CSS

After all of that is done, now is when I apply the style to my markup. I have been writing CSS in the same style for quite some time now, but I’m always open for new tips on writing better CSS. It is at this time markup elements are given their class and id names, and the markup is styled according to the design mock.

As I style the document, I’m constantly looking for repetitious properties and values in order to keep my style sheet streamlined and as light as possible. I’ll also keep a close eye on known pitfalls I’ve run into in the past, such as trying to avoid the cross browser box model issues. I write as much style as possible before checking things out in a browser, as it slows down the overall process. It’s more difficult to do as you’re defining the visual structure, but there are many times you can style an element with no need to double check yourself in a browser.

Cross browser testing

After I’m satisfied with the markup and CSS, I begin a barrage of browser testing. My browser of choice for development is Firefox, so the mere fact the document was under constant using that browser, it goes without further testing. I’ll then move on to IE6, and using conditional comments, I’ll put together a separate style sheet containing all the fixes IE6 needs. This process is repeated for IE7, which still definitely has it’s share of quirks that need to be handled.

Beyond Internet Explorer, I will also test in the latest version of Opera, and then move on to Konqueror, as it uses the KHTML rendering engine, which is as close as I can get to Safari within my Linux install. I’ll always take a final step to test in a legitimate install of Safari in OS X as well, but testing in Konqueror does help expose some pitfalls before having to move to a different machine for testing.

Putting together a print version of the document

After all the above has been done, one of the last steps I perform is preparing the document for print using CSS. There is a lot you can do to make sure that the printed version of a document is presented in a way that proves useful as hard copy. Again, many times conditional comments are used to ensure the print version renders correctly in Internet Explorer.

Last, but absolutely not least, the website is put through the validation paces. I have a constant eye on my markup and style validation, but always run them through the official tests provided by the W3C. Automated accessibility tests including Section 508 and WCAG are also performed to ensure I didn’t overlook anything. There are often other steps involved with the development of an entire website, but perhaps me explaining my methods can offer some insight into my Web design/development process. Writing this article was inspired by Jonathan Snook’s chronicle of his design process. I love reading articles like that, and thought I’d offer a version of my own as well.

Advertise here with BSA

When first researching the specifications published by the W3C, there were certain times where a light went off, and one more piece seemed to fit together. Many times, it was when I would read about one of the many HTML elements and it would just make sense. As I became more and more involved with markup, it became apparent how great (X)HTML can be when used properly. From time to time I will review the specification, re-examine the details, and analyze how I’ve been using a particular tag in practice. Two such tags that I recently reviewed are the acronym and abbr tags.

Acronym or Abbreviation?

The acronym and abbr tags are not only a completely great tool for your readers, they also provide another way for you to include some search engine friendly keywords into your document. According to the W3C Spec, acronym and abbr are considered phrase elements. Phrase elements add structural information to text fragments. More specifically:

ABBR

Indicates an abbreviated form (e.g., WWW, HTTP, URI, Mass., etc.).

ACRONYM

Indicates an acronym (e.g., WAC, radar, etc.).

The ABBR and ACRONYM elements allow authors to clearly indicate occurrences of abbreviations and acronyms. Western languages make extensive use of acronyms such as “GmbH”, “NATO”, and “F.B.I.”, as well as abbreviations like “M.”, “Inc.”, “et al.”, “etc.” … Marking up these constructs provides useful information to user agents and tools such as spell checkers, speech synthesizers, translation systems and search-engine indexers.

The first time I read the above definition, I was still a bit perplexed as to when each should be used. The specification goes on to say:

The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression.

The definition has now grouped the two tags into one and made it a bit more confusing as to what criteria a string should meet before it is classified as either acronym or abbr.

Note that abbreviations and acronyms often have idiosyncratic pronunciations. For example, while “IRS” and “BBC” are typically pronounced letter by letter, “NATO” and “UNESCO” are pronounced phonetically. Still other abbreviated forms (e.g., “URI” and “SQL”) are spelled out by some people and pronounced as words by other people. When necessary, authors should use style sheets to specify the pronunciation of an abbreviated form.

What separates abbr and acronym

From reading the documentation, we can gather that abbr and acronym are very similar in nature, but on the other hand, they’re different. The specification leaves this issue open for interpretation and many people have their own views.

I tend to side with those that decipher the difference in the actual pronunciation of the phrase. An acronym is a set of letters that can be pronounced as a single word (e.g., NATO pronounced “NAY-TOE”) whereas an abbreviation is pronounced one letter at a time (e.g., CSS pronounced “SEE ESS ESS”).

Is there a need for both acronym and abbr?

There are many people that feel that acronym will be deprecated in future versions of XHTML. Personally, I don’t have a strong opinion on whether or not we’ll be able to use acronym in the future, but given the gray nature of the definition itself, I wouldn’t rule out it’s deprecation.

Beyond the semantics of the tags themselves, there are, of course, browser inconsistencies to deal with as well. From a semantic point of view, browser support could be pushed aside in favor of semantic value. On the other hand, having stylistic control over abbreviated phrases or acronyms can be a strong benefit for the design and usability of a document.

Advertise here with BSA