Example of quirks rendering mode

Example of quirks rendering mode

Way back when we were putting square pegs into square holes, everything worked well.  Then one day the keeper of the holes into which the square pegs were placed realized the holes were made incorrectly and were not conforming to specific standards. To remedy this situation and ensure holes and pegs would work far into the future, the keeper made a new set of holes. Unfortunately, the pegs wouldn’t fit, because they, too, were not conforming to the same specific standards. Since these pegs were very popular, by peg standards, the keeper was forced to create a way for the square pegs to fit into the now round holes.

This is a really simple explanation for the existence of “Almost Standards Mode.” In reality, the pegs were web pages and the holes were browsers. In 2002, Netscape was ready to release a new version of their browser which would render HTML more closely to W3C standards. Conforming to standards is good – it ensures more universal access to the web. However, in testing, Netscape discovered sites whose design was based on images inside tables would be utterly broken, and that was a large portion of the web.

Example of standards rendering mode without table border

Example of standards rendering mode without table border

To illustrate how the pages were broken, let’s look at some before and after examples. I’m using screenshots of a page created using tables for layout purposes. I’ve mentioned previously that I have made pages using tables for design, and it’s true. So did most everyone else at the time.

The example page I’m using is similar to a file I used to teach table creation in Dreamweaver 4. The source code has no DOCTYPE defined. This was in 2000, before DOCTYPEs were universal. I have added a 1 pixel border to the table to make it easier to see what’s going on. In actual use, god forbid, this would appear as a seamless picture.

The first image shows the page with without a DOCTYPE specified. With no DOCTYPE specified, the browser automatically renders the page in Quirks mode. This means that non-standards compliant HTML will render properly. The images in the table will be displayed without any white space around them because the table cells automatically shrink to fit the images.

The second image shows the same page with a DOCTYPE of HTML 4.01 STRICT in place, which results in standards-based rendering. Standards-based rendering means that the images will sit on the text baseline by default resulting in white space below the images inside the cells. (You can read a well-supported explanation of that here.) For pages which rely on sliced images butting up against each other to create a seamless picture, this creates an utterly broken page. In the example, you can see there’s a beautiful white line in the middle of the picture. The third image shows the table border displayed again and the white space in each cell.

Example of standards rendering mode

Example of standards rendering mode

Eric Meyer is the hero who saved the day by creating Almost Standards Mode and has a lovely, detailed post about how the new mode came about here. And, this page has a great explanation of how and why to implement the different modes.

So, what’s the upshot of all this? Use round pegs from now on and you’ll not have to worry about it. But, when someone comes to you with an antiquated square peg, you’ll know what to do.


Clearly, I’ve been a reluctant blogger. In order to change my habits, I’ve decided to make a commitment to blog at least once a week for the entirety of 2011. Rather than just thinking about doing it, I’m starting right now.  (Ooh, look at that. It’s my second post today.)

I know it won’t be easy, but it might be fun, inspiring, awesome and wonderful. Therefore I’m promising to make use of The DailyPost, and the community of other bloggers with similiar goals, to help me along the way, including asking for help when I need it and encouraging others when I can.

If you already read my blog, I hope you’ll encourage me with comments and likes, and good will along the way.


Robin Seaman

Biscuits (cookies or bread) on a plate

Who wants a biscuit?

Up until recently, the way a lot of people learned HTML was by checking the source code of a page and seeing how it was written. While this is an excellent way to “get under the hood” and really get your hands dirty in a learning experience, there are some drawbacks.

For example, as with learning the meanings of unfamiliar words from context, there’s always the chance that the true meaning of the word, or, in our case, the actual use of an element, will be misunderstood. That’s especially true if the element wasn’t used correctly in the first place. Many a web page has been written with poor semantics, either out of ignorance of correct tag usage or because of the that’s-the-way-we’ve-always-done-it attitude, and learning how to write HTML from those pages just perpetuates poor semantics.

Why should we be wary of semantics and write semantically correct HTML? Good question. Let’s start with what semantics means. Semantics refers to proper meaning. If you are talking about what you had for snack and tell someone you had a biscuit, you could be talking about a cookie (if you were British) or a type of bread (if you were American). In order to understand the meaning of the word “biscuit” you must know the context, in this case whether the speaker is British or American.

In the realm of HTML, there is only one context (conveyance of information) and everyone who writes HTML understands it. This is, of course, where my analogy starts to break down. So, if everyone understands the context of HTML why are good semantics important? To understand that, we need to go back a bit in time and look at how HTML was first used.

The basic elements of HTML (<p>, <h1>, etc.) format text in specific ways. The  <p> element always starts text on a new line and includes a line break with each use. The <h1> tag formats text as very large and includes a line break. People started using the tags not as ways of identifying the different parts of information, but as formatting elements to get the text to look the way they wanted. Back before CSS, designers even used the <table> element to format a page in a grid, with each cell of the table containing a sliced up piece of the page. With this use of tags, the actual meaning of the element was lost. In other words, semantics be damned.

So back to our question: why are good semantics important? There are several reasons, ranging from accessibility to cost reduction. We’ll explore a few of them here, along with some specific examples of HTML tags and their proper use.

First, accessibility. Enter the text reader. This is a device that allows sight-limited people to browse the web. It reads each page, not by reading the text of the page as we see it, but by reading the tags in the source code to get oriented and then reading the text defined by the tags. As I understand them to work, the text reader looks in the source code for a title (<h1>) to read before reading any other content. If what is defined by the <h1> tag is not actually the title of the content, but instead, something trivial that the page designer wanted to be larger and set apart from the rest of the content, then you can imagine the annoyance and frustration of the user at not being able to parse the information on the page and find what he is looking for.

Let’s look at three examples of HTML tags and how they’re used with proper semantics.


The <blockquote> element defines a block of quoted text. This is useful to a sight-limited user because the text reader reads the tag and the content is defined. As for formatting, the <blockquote> tag starts a new line and indents the content contained in the tag. The tag allows attributes to further identify the content, namely, “cite” and “title”, which make the content that much more relevant to the user. In proper use, the code looks like this:

<blockquote cite=”http://www.famousquotesandauthors.com/authors/f__d__roosevelt_quotes.html” title=”Franklin D. Roosevelt”> “Freedom of conscience, of education, of speech, of assembly are among the very fundamentals of democracy and all of them would be nullified should freedom of the press ever be successfully challenged.”</blockquote>

and the output looks like this (note that the quote itself is indented and when the mouse hovers over the quote, the assigned “title” attribute appears.):

Example of blockquote tag output

Code & Preformatted Text

The <code> element defines computer code and allows the browser to display the code as written rather than render it. This is useful for writing tutorials, etc, and browsers display the content of the <code> tag in the default monospace typeface. One caution, however, is make sure the line length isn’t so long that the line gets cut off or causes a horizontal scroll bar. (The blockquote example isn’t contained in a <code> set because it got cut off.) In proper use it looks like this:

&lt;p&gt;This is an example of the paragraph tag and it contains an example of the &lt;em&gt;emphasis&lt;/em&gt; tag, which displays what’s inside the container in italics.&lt;/p&gt;

and the output looks like this:

example of code tag output

To display computer code with good code formatting, use the the preformatted text tag. The <code> tag set is nested inside the <pre> tag set and forces the browser to retain the spaces and returns written in the source code. Proper use looks like this:

         { font-size: 2em;
           font-family: arial;
           color: orange;
           border: 3px solid red;

and the output looks like this:

example of pre tag output

The designer doesn’t have to deal with any other formatting and the content is properly defined. You’ll notice there’s a difference in how the two examples are displayed. This is due to how WordPress CSS handles the different tags. Both, however, are displayed in fonts other than that of the body copy.

Back to Good Semantics

In the past, these tags have been used to display text as indented, monospaced, or with  the spacing in the source code, not necessarily to define the actual content of the page. Using HTML elements for design defeats the purpose of the tags and renders them useless for content management. In addition, misuse of the tags and not following good semantics practice can lead to code bloat and cost increases.

Modern practice in creating web pages uses HTML to define the content and CSS (cascading style sheets) to format the content. With this ideal, code can be simpler, cleaner, and easier to manage. If HTML is used to handle the display of the content, then every time a change needs to be made to the display someone has to go through the code line by line and make the changes. This can take hours and be very costly.

If the formatting is handled externally by CSS, then it’s an easy change of the whole site. Only one line needs to be changed in order to make all blocks of quoted text render in blue serifed font, as long as the HTML tags have been used properly. Applying that change is as simple as defining <blockquote> in the CSS to be blue and serifed.

So, you can see how practicing good semantics makes the web a friendlier place, both for users and authors. Now, who wants a biscuit?

Neenah Paper Sample Book

Page from a Neenah sample book

Recently, I had the opportunity to attend a Neenah Paper seminar hosted by Blair Digital and Xpedx at green|spaces, and as an added bonus, got to hear more from the rep when he visited one of my design classes. As I stated previously, I love paper. Hearing Barry Clough, from Neenah Paper, gave me the opportunity to learn even more about how it’s made, this time from a mill’s perspective.

Neenah Paper is located in Wisconsin and was started in the 1870’s. Neenah began out as a small mill, but over the years has purchased other paper mills and now commands a large percentage of the market share for printing paper. As technology has changed, the company has introduced many new products to meet the evolving needs of designers and printers.

Acquiring paper samples always brings joy and I now have a growing collection of swatch books to look through for inspiration. As for their usefulness, I never thought about that beyond inspiration and picking the best paper for the project at hand. However, Barry showed us in class how to use them to determine the quality of the paper. He held a piece of copier paper and a page from one of the Neenah swatch books up to a window to compare the formation of the two papers. Formation refers to how evenly distributed the fibers are in the paper. Comparing the copier paper to the Neenah paper showed an even, regular distribution of fibers in the Neenah paper and an uneven, splotchy looking distribution in the copier paper. An even distribution of fibers ensures an even coating of ink. If you’re printing a full-bleed page of a solid color, having an even distribution of paper fibers ensures there will be no splotchy areas where ink (or toner if you’re printing digitally) is thinner than others.

Barry’s visit was entertaining and illuminating and I’m looking forward to more paper seminars in the future.

Team Ninja pitching our Adobe challenge project

Team Ninja pitching our animated ad to the Adobe Challenge judges. Photo credit: Leslie Jensen-Inman

A week ago Saturday I went to Amped in Atlanta. Amped was a hack day following the Web Directions conference, which is something I had never participated in before, and it was the first ever 10-hour hack day. Hack days, traditionally at least 24 hours long, bring together a wide variety of technologically savvy people to quickly solve posed challenges. I wasn’t sure what to expect and, since I had so much homework to finish, I was even considering not going. I’m so glad I went.

Several of my classmates attended, as well, and I decided I wanted to get on a team comprised of people I didn’t know. I figured since I had practically the same skill set as most of my classmates I’d learn more and be better able to put my own skills to use on a different team. So, pushing myself out of my comfort zone, I put my name and phone number on the board under “Have Skills” and set about waiting.

The team that contacted me was wanting to enter the Adobe challenge of creating an animated advertisement promoting open web. (Open web, put succinctly, is using cross-platform technologies to create websites that anyone can use. The sites can be viewed equally well on computers, mobile devices, TVs, etc.) We also worked on two other projects and entered three additional challenges. Those projects involved re-imagining how football games are viewed in the age of internet enabled TVs and creating a PalmOS app for GT students to access the student directory and have instant contact via phone or email from within the app.

I found working under such tight time constraints invigorating and realized that I was able to think more creatively in that atmosphere than I normally do. Of course, part of that was bouncing ideas off of my teammates, who were fantastic to work with.

The hack day also gave me a chance to meet industry gurus and learn a tremendous amount from them. Doug Schepers lent his expertise in SVG to our project – talking with me about ways to prepare the graphics and Ruby about the best ways to implement our plans.

Throughout the day, mini-workshops were held on all of the relevant technologies and topics making the learning environment one of intense collaboration as one team member would attend a session and debrief others on the team. Relly Annett-Baker was on-hand to discuss content strategy and I talked to her a bit about the particular wording on our ad.

Thanks very much to team members Ruby Zheng, Faried Amani, and Oge Nnadi. I had a great time working with you guys. Maybe we can do it again next year. Also thanks to John Allsop and Maxine Sherron from Web Directions for putting on an amazing event and to the sponsors, Adobe, Palm, and PayPal, for making it possible. I’m definitely looking forward to attending again and again.

Wireframe for a website

A hastily drawn wire frame for a fictitious site.

I’ll always be the first to admit that a blank page scares me because there’s no structure on which to start hanging ideas. When designing web sites and web pages, that’s where wireframes are a lifesaver.

In order for content on a site—and on an individual page—to be relevant, easy to consume, and quick to find there needs to be agreement between the designer, the clients, and the site users. Wireframes provide the opportunity to have a dialog between these three entities, albeit usually the site user is in the form of a developed persona.

I’ve used wireframes from the beginning and have never considered creating a website without first sitting down with the client to discuss the needs of the site and how to navigate it.  But, I’ve only used wire frames for the site navigation. Having just read Shades of Gray: Wireframes as Thinking Device by semanticwill, I’ve realized that there’s so much more I can do with wireframes to make the design and implementation process of web site creation easier and more enjoyable. (It’s never fun trying to get somewhere when you have no map and a deadline.)

Wireframes are great for proposed data location on an individual page, which takes into account the relevance of the information and it’s hierarchical position in context with other information elements. Often there’s disagreement on the position of individual elements and wireframes offer a visual perspective that can help answer questions like, Is this where customers expect to see this kind of information? or What is the best place for this type of information?

Like creating thumbnails and roughs when working on a graphic design solution, wireframes allow the designer to try different ideas in order to determine the best information layout. And, clients appreciate seeing the proposed solution rather than listening to a description of it and trying to imagine what it will look like.

With an “updated” tool in my toolbox, I’ll be better able to meet the client’s needs and, just as important, enjoy the process.

I had the opportunity to hear John Allsopp speak today about the future of web design. John is a web evangelist, author, speaker, and teacher of CSS. And, his enthusiasm for the future of the web is contagious.

As I previously wrote, my interest in the web started about 18 years ago, when the web was in it’s infancy. Bad design abounded causing limited access to information and frustration for designers and developers alike.

John took us on a history tour of the web, which sounded a lot like the “we had to walk barefoot uphill – both ways- to school when I was your age” speech a lot of us have heard from our parents as kids. But, in terms of browser capabilities in the 90’s and early ’00’s, that’s certainly how it felt.

Creating functional, good looking sites required lots of graphics that had to be cut and precisely placed to reduce the page loading time. One large graphic might actually be 4 smaller ones. If a link to a graphic was broken, 1/4 of the picture was missing. Animation was limited to GIFs and, really, it was best not to use it at all.

CSS (Cascading Style Sheets) was introduced in 1995 allowing developers to control the look of a site for the whole page instead of element by element.This was a major breakthrough. It’s use expanded with CSS2 in 1998. I started learning CSS2 just before I changed course for parenthood. At the time, I was amazed by what CSS made possible.

After seeing what John demonstrated today, I’m chomping at the bit to learn CSS3. Editable type independent of the user’s computer?!? Wow. GPU generated background gradients?!? Neat. Clean, beautiful animation that adds to the user’s experience?!? Unheard of – until now that is.

Pair CSS3 with HTML5 and the future of the web looks amazing. I’m excited that I no longer have to trudge uphill -both ways- to make great looking websites.

Close up of paper edge showing paper fibers

Photo credit: ChP94 on http://commons.wikimedia.org/

I have had a love affair with paper since I was old enough to scribble on it with crayons. I don’t mean I like paper because I can write on it or draw on it or fold it into some interesting shape. I do like those things, but that’s not why I obsess with paper.

I mean I love paper. I love the feel of it, the smell of it, the amazing variations in texture and color. I love that it’s made from so many different materials – cotton, linen, hemp, wood, rags, and banana leaves – and that each of those papers has a different look, feel, and weight. I’m sure there are more materials paper is made from and I just don’t know about them – yet.

I would go into paper shops just to look at the racks of possibilities and end up buying some kind of paper solely because it looked so neat or felt so luxurious. Then I’d go home and add it to the stack of other possibilities waiting for me. I realized that one of the aspects of paper that I love is that each blank sheet could be anything. While I’m the first to admit that scares the hell out of me when I have to come up with an idea, I still find a blank page without any expectations a beautiful thing.

Unfortunately, if all the paper around has no expectations attached to it, it tends to remain there, unused, taking up space. I realized my mom had a point about my paper obsession when I had to clean out a closet and most of what I took out of it was blank, beautiful paper. If I wasn’t going to do anything with it, she argued, why keep it? Point taken. I stopped myself from going to paper shops or picking up the tablets at conferences, but my love of paper didn’t abate. I just put it on hold.

Now I’m learning about paper from a designer’s perspective, which is very different from a layperson’s. Designer’s actually do things with paper and (yikes!) have expectations of paper. I’m having to conquer my fear of the blank page, although I still prefer some sort of structure on which to begin.

My class visited PaperPlus this week. We got to see first hand what a paper supplier looks like and ask questions about the process of working with a supplier and print shop. The process of speccing a paper for a project and working it into the budget seems daunting right now, but I’m sure by the time I graduate I’ll have a pretty good grasp on it. I do know the first thing to do now, though. Form a good working relationship with a paper supplier.

Densmore Typewriter ad 1896Writing is everywhere – boxes, bottles, billboards, magazines, newspapers, flyers, email,  and websites- to name a few places. There’s one commonality between these disparate forms of writing: they use language. How each form uses language differs greatly and each has different expectations from the reader’s point of view.

Writing in newspapers and magazines is informative, educational, and opinionated depending on which section of the paper, or what kind of magazine, you’re reading. We, as readers, expect newspapers and magazines to have high editorial standards and be written clearly. OK, you got me there. I don’t think Us or People consider their editorial standards much, but I digress. Generally, we read these materials at leisure – over coffee in the morning, waiting in a doctor’s office, or riding on public transit.

From other printed ephemera (boxes, bottles, billboards, flyers, etc.) we decidedly expect less. The copy used on them is primarily for persuading – “Buy XYZ because it’s chock full of vitamins and minerals!” (Gee, I didn’t know foot powder needed vitamins and minerals.) The copy on these sources is written for accessibility and generally has a friendlier approach. These materials are typically read in passing – walking down grocery aisles, driving down freeways, grabbing the flyer off the windshield in the parking lot before tossing it in the back seat.

Websites, while including all genres of printed material, are read differently. We go to a website for information, to answer a question, to complete a task, and in doing so we expect to access that information or perform that task quickly and easily. Anything that gets in the way of our purpose is, at best, annoying, if not downright frustrating.

Across all these disparate forms of writing is an overarching expectation – good grammar. Reading something that’s well written imparts a sense of confidence in the information. If the writer misuses their, they’re, and there can we really trust him to know what he’s talking about? Likewise, if the writer’s writing lazily and using netspeak are you going to respect his opinion or knowledge?

In exploring writing, I came across a blog post on how to write a good first message for an online dating service. The number one rule was “Be Literate.” Messages that used netspeak, had gross misspellings, or bad grammar (or all three!) didn’t get a a response. I can’t agree more. Well written messages, articles, etc. give confidence to the information and, more importantly, eschew obfuscation. (One of my favorite phrases, because it doesn’t follow it’s advice.)

I was first introduced to the world wide web in 1992 by my brother. I found it fascinating and wonderful and compelling and ugly and awesome. And, it was something very few people knew about. I remember when I lived in Chicago, my brother and I would always point out the URLs we saw in ads, usually on the sides of buses, because they were so rare.  That was 1993/1994.

Homepage for Morgan Adams website (2001)

Homepage for Morgan Adams website (2001)

Fast forward a bit, and I had the opportunity to put my fascination to work. I had learned quite a bit about website construction and disliked most of what I saw. (If you’re ever curious about early website “design”, check out the Wayback Machine for some gross examples.) I started creating websites, for pay even, and getting complements on them, which was even better – not that I’m dissing a good pay check, mind you.

What I liked most about my work was making the information accessible. Most people were putting wizzbangs and fugliness on the sites to make them eye-catching, but in turn, rendering them almost useless. My mission was to make clean, simple, useful websites that gave people the information they wanted in the least amount of clicks.

Injury Law page of Morgan Adams website (2001)

Injury Law page of Morgan Adams website (2001)

Fast forward again to today and that’s still my goal. However, I’m playing catch-up because I took some time out to be a stay-at-home parent and the technology passed me by. When I went back to work I was mainly working on internal sites for clients where I was not the developer, but the maintenance tech. So, I can’t wait to find out the answers to questions I’ve wondered about, but not found the answers to, like why was <bold> replaced with <strong>. I know it’s standard now, but haven’t discovered the reasoning behind it.

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 9 other followers