Slashdot Mirror

"On the morning of August 15, 2000, three hikers in wheelchairs, two hikers on crutches, and their 20-member support crew of family, friends, and volunteers set out on what would become an historic hike to prove the naysayers wrong. ... The hike, organized by Northeast Passage, a University of New Hampshire-based outdoor recreation program for individuals with disabilities, received national attention and front-page coverage in The New York Times (August 17,2000).

The 12-hour ascent up the mountain trail-which critics said individuals with disabilities would never use-began through mud and over slippery boulders, thick roots, and narrow bridges. In addition to ropes, spare wheels, tents, and sleeping bags, the hikers devised a variety of techniques. For example, two metal rickshaw poles were added to the front of wheelchairs, thus enabling two people to lift the front casters over rocks and boulders."

The key question: "a local television reporter asked- 'Why people in wheelchairs could drag themselves up the trail and not drag themselves up the steps to the hut'"

I've ranted about this before.

Not everyone will have these fonts; not for a long time, anyways. Browsers will then instead use the default sans serif font (Helvetica or Arial typically). Pages viewed in Arial or Helvetica that were intended for Calibri will, at least, not look good and, at worst, be completely unreadable.

Why?

Calibri (which is the one font in the group certain to become the choice of future web developers) has a different size than, say, Arial. A 1em or 12pt or 14px tall Calibri character is going to actually be smaller than the same sized Arial character. The reason is due to the design of the font and the font's leading.

A page set at 100% (default) font size that looks good in Calibri will look oversized in Arial or Helvetica. Furthermore any sort of soft-alignments between texts or text and other page elements will break. For example the content you expect to appear "above the fold" or appear shorter than an image you've got aligned to the right will now be pushed below the fold or below the height of the image, creating an page layout for someone using a stock browser.

Let's take a shot in the dark here. Now these fonts are installed as part of Office 2007. They're part of Vista. They're not part of XP unless you either have Office 2007 or the 2007 compatibility pack installed. Let's say 5% of all internet browsing computers are Vista and 75% are XP. How many of those 75% have Office 2007 or the compatibility pack (which isn't automatically downloaded via windows update, requiring the user go and download it). I think a more than fair value is that 25% of those 75% have Office 2007 or the compatibility pack installed. That equals out to about 25% of all computer users have Calibri support right now. If you design with Calibri you're ignoring 75% of your user base.

In 3-5 years that number, I believe, will drastically increase to the point where the majority will support Calibri. But not now. So don't design with it.

The CSS/rendering engine they've been using since IE4 is still around. They keep patching it with every release to try and bring it up to spec. However the underlying reason for all the layout bugs still remain.

It's called hasLayout and it's created many problems over the years. It's still there in IE7 and there are new bugs relating to hasLayout in IE7 as demonstrated here.

The best multi column html/css layout that I know of...source ordered even:

http://webhost.bridgew.edu/etribou/layouts/skidoo_ too/

A quick look at the underlying HTML structure and what I'd do differently.

Key thing to remember to think about informational structure, not visual structure (that's the job of CSS) when authoring HTML documents. It's a bit obvious visual structure was definately on the mind as the new HTML for the site was constructed.

In a well structured HTML document, you're not going to see many BR tags. It's not something you do on purpose, it's just a product of good HTML. BR tags are more for visual separation and not content separation. There are a lot of BR tags, many of which really aren't needed.

You've got heading tags inside list elements. This isn't wrong, but it's a sign that something usually isn't right. In this case, the H2 used for the "main" link under "sections" in the left column. Heading tags should at least follow some kind of hierarchical structure. If anything, an h3, not an h2 tag should be used. But really, no heading tag at all, just a STRONG tag with a class applied to the containing LI element to set the background color is how it should be.

DIV elements containing a single block element. Best examples of this are heading elements wrapped by a DIV element. There's no need for this from a data structure perspective. The class(es) and/or ids applied to the containing DIV should be directly applied to the heading tag. By wrapping a heading with a DIV element you're only bloating the page with needless markup. If this is being done for visual structure purposes, you need to rethink your approach (workarounds will be available, just spend a moment to figure it out.)

Text in paragraph form not being contained in a P tag. The P tag provides more than just visual structure, and should be used heavily over multiple BR tags. In this case, the text in the "indexhead" class DIV element at the top of the page ("meta moderated... the next story...") is wrapped by a DIV and not a P tag. Use a P tag, it's a block element and can take the class assignment placed on the DIV. It'll also add some whitespace (which you can control) to get that text off the green bar below it.

The "storylinks" DIV class should be inside the "articles" DIV class elements. This way the "storylinks" content is directly associated with its story in the markup, rather than having to make assumptions that the "storylinks" DIV elements immediately follow the "article" DIV element that they relate to.

Interesting use of lists for the "read more ... X of Y comments" portion. I'm not sure lists are the correct way to proceed here.

I would use dictionary lists for the entire page of articles. The DT element would be the article title, the DD would contain the summary and extra information. This provides nice structure to the information and makes it much easier to group information together. Whether or not this is proper use of dictionary lists is debatable (but I'm for expanding the use of DL/DT/DD elements outside of boring, literal dictionary entries; taking a more liberal view on their use).

And one quick tip for helping with formatting of HTML source. When you need two elements next to each other (no whitespace between) here's a 'cute' way to do it,

    <li>
        content goes here
    </ul
    ><ul>
        content goes here
    </ul

And so on... this is valid HTML and allows you to throw in linebreaks and tabs to keep the source clean and easy to use. I like to use this a lot because some browsers (Opera,IE) get very crazy about whitespace where none is assumed to exist.

Those are my immediate bits of advice.

You can read some of my wild rantings on this sort of thing here (ready blog entries from bottom up if you want them to make sense). And here is my attempt and showing what can be done while trying to use as little extra markup as possible and still doing an "interesting" layout.

A quick look at the underlying HTML structure and what I'd do differently.

Key thing to remember to think about informational structure, not visual structure (that's the job of CSS) when authoring HTML documents. It's a bit obvious visual structure was definately on the mind as the new HTML for the site was constructed.

In a well structured HTML document, you're not going to see many BR tags. It's not something you do on purpose, it's just a product of good HTML. BR tags are more for visual separation and not content separation. There are a lot of BR tags, many of which really aren't needed.

You've got heading tags inside list elements. This isn't wrong, but it's a sign that something usually isn't right. In this case, the H2 used for the "main" link under "sections" in the left column. Heading tags should at least follow some kind of hierarchical structure. If anything, an h3, not an h2 tag should be used. But really, no heading tag at all, just a STRONG tag with a class applied to the containing LI element to set the background color is how it should be.

DIV elements containing a single block element. Best examples of this are heading elements wrapped by a DIV element. There's no need for this from a data structure perspective. The class(es) and/or ids applied to the containing DIV should be directly applied to the heading tag. By wrapping a heading with a DIV element you're only bloating the page with needless markup. If this is being done for visual structure purposes, you need to rethink your approach (workarounds will be available, just spend a moment to figure it out.)

Text in paragraph form not being contained in a P tag. The P tag provides more than just visual structure, and should be used heavily over multiple BR tags. In this case, the text in the "indexhead" class DIV element at the top of the page ("meta moderated... the next story...") is wrapped by a DIV and not a P tag. Use a P tag, it's a block element and can take the class assignment placed on the DIV. It'll also add some whitespace (which you can control) to get that text off the green bar below it.

The "storylinks" DIV class should be inside the "articles" DIV class elements. This way the "storylinks" content is directly associated with its story in the markup, rather than having to make assumptions that the "storylinks" DIV elements immediately follow the "article" DIV element that they relate to.

Interesting use of lists for the "read more ... X of Y comments" portion. I'm not sure lists are the correct way to proceed here.

I would use dictionary lists for the entire page of articles. The DT element would be the article title, the DD would contain the summary and extra information. This provides nice structure to the information and makes it much easier to group information together. Whether or not this is proper use of dictionary lists is debatable (but I'm for expanding the use of DL/DT/DD elements outside of boring, literal dictionary entries; taking a more liberal view on their use).

And one quick tip for helping with formatting of HTML source. When you need two elements next to each other (no whitespace between) here's a 'cute' way to do it,

    <li>
        content goes here
    </ul
    ><ul>
        content goes here
    </ul

And so on... this is valid HTML and allows you to throw in linebreaks and tabs to keep the source clean and easy to use. I like to use this a lot because some browsers (Opera,IE) get very crazy about whitespace where none is assumed to exist.

Those are my immediate bits of advice.

You can read some of my wild rantings on this sort of thing here (ready blog entries from bottom up if you want them to make sense). And here is my attempt and showing what can be done while trying to use as little extra markup as possible and still doing an "interesting" layout.

http://www.csszengarden.com/ http://www.alvit.de/handbook/ http://www.wpdfd.com/editorial/basics/index.html http://www.w3.org/TR/REC-CSS2/ http://css.maxdesign.com.au/listamatic/ http://www.cssvault.com/ http://glish.com/css/home.asp http://webhost.bridgew.edu/etribou/layouts/index.h tml http://www.positioniseverything.net/ http://www.stylegala.com/