Two Banjos At Once: The Blog

Living with standards compliance

My First Web Page

September 21, 2009

Tags: , , , , , ,

Some digging in a dusty file box the other day yielded no fewer than three floppy disks. What wisdom might these ancient tablets convey? Fortunately, there was at least one device in the house which still had a floppy drive. Result: mostly disappointment. The files were either first drafts of things I’d sent off to magazine editors in the late 1990s, or grouchy letters to my landlords of the same era. However, there was, archived with apparent pride, my first effort as a Web developer.

Step into the WABAC Machine. The year is 1997. I was the admin assistant for a team of software engineers. I was also something of a mascot; if the guys (yup, all guys, except for me) had a noncritical technical task they thought I could handle with a little instruction, they threw it to me, because I guess I looked really grateful to be doing something besides ordering lunch and taking the abusive phone calls of the company CEO. The most enduring instructions they gave me was how to use FTP, IrfanView, and NotePad to develop the team Web site. Of course, these tools seemed insufficient once I made a few changes–I wanted colors! Silly typefaces! Dizzying background images! And HTML seemed so hard to learn…

I remember downloading a lot of trial versions of the trendy WYSIWYG software of the time: an early version of Frontpage (which had me puzzling over these things called “stylesheets”), Adobe PageMill, and the editor which came with Netscape Gold. The one I used the most seemed to be NetObjects Fusion, which I notice is still available. It was a big, handholding, friendly giant of a program; it set everything into tables and FONT tags, and we were buddies. I felt masterful.

Nobody I worked with was a Web professional–no designers, no information architects, no UI devs. Creating Killer Web Sites had only just been published, Web Pages That Suck was treated mostly as a humorous diversion, and even Jakob Nielsen was as yet rather obscure to the average person making a Web page. It was in this Wild West environment that I devised this:
My First Web Page

I’ll enhance that retro atmosphere with a sample of its markup:

<HTML>
<HEAD>
   <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
   <META NAME="GENERATOR" CONTENT="Mozilla/4.03 [en] (WinNT; I) [Netscape]">
   <META HTTP-EQUIV="Page-Enter" CONTENT="revealTrans(Duration=1,Transition=6)">
   <TITLE>ES Home Page</TITLE>
</HEAD>
<BODY BACKGROUND="amoeba.jpg">

<CENTER>
<H1>
<FONT FACE="Wide Latin"><FONT SIZE=+4>Engineering Services</FONT></FONT></H1></CENTER>

<CENTER><IMG SRC="grey_dots.gif" ALT="grey_dots.gif (6699 bytes)" HEIGHT=47 WIDTH=890></CENTER>

<CENTER><FONT FACE="HELVETICA"> </FONT></CENTER>

<UL>
<LI>
<FONT FACE="HELVETICA"><FONT SIZE=+2><A HREF="[...]">ES
Quote Status</A></FONT></FONT></LI>

<LI>
<FONT FACE="HELVETICA"><FONT SIZE=+2><A HREF="[...]">Current
ES Status Report</A></FONT></FONT></LI>

Yeah, go on. Snort, carp, whatever. But this is how we did things then, back when browsers “innovated” with crap like BLINK and MARQUEE. A year later I was back to using text editors–haven’t touched a WYSIWYG since. Just a year later I was using CSS and disdaining FONT, and a year after that I was riding the dot-com boom as it crested. So it’s worth examining your old work product, if only to swell with pride over how far you’ve come since then.

What was your first Web page like?

A visit with HTML 5

September 9, 2009

Tags: , , ,

Now that HTML 5 has been declared victorious over XHTML 2, the last six to eight weeks have yielded a bouquet of tutorials, introductions, cheatsheets, and blog postings about it. I guess we’re so excited about anything new in markup we’ll even cheer a draft proposal. I can’t excuse myself from the mob, having joined it on a recent project for a future-minded client who encouraged me to take up the fashion for <!DOCTYPE html>.

On first and even second glances, the HTML 5 element list seems conservative, not much of a change. There are the intriguing new tags like <canvas>, but with limited cross-browser support. <menu>returns from, what, HTML 3.2?, but this time dressed up as a way to group form inputs (easy to confuse with how we’ve been using <fieldset>). Other elements, such as <header>, <footer>, and <section>, are good substitutions for the over-worked <div>, which lingers in HTML 5 for your block element needs. <article> is interesting–it’s supposed to enclose “standalone” content. <nav> is easy to type and remember.

However, some of these tags seem to presume usage in rather old-fashioned situations. For instance, which of the navigational blocks on your application screen will you exalt with <nav>? No fair using it more than once–it’s supposed to designate your primary navigation. And which of your content blocks are <section>s and which are <aside>s, especially if the user can rearrange them?

Where HTML 5 seems more ambitious, seems to pose more of a learning curve, is on attributes and APIs. Form elements seems especially enriched in this specification. I didn’t use any of these on this project, but I’m eager to try them when the browser support is sufficient. Many of the proposals will remove tedious DHTML chores, if ever supported; for instance, this block will replace all those unordered lists distorted by CSS and JavaScript into popup menus:

<menu type="popup">
    <command  label="Check messages" icon="messages.gif"/>
    <command  label="Logout" icon="logout.gif"/>
</menu>

By now I expect you’re asking, “But what about IE?”

Yeah, what about that? Hmmm.

I was blessed to have a client who’d discarded concern for IE 6. Problem solved, you think?

Not at all. IE 7 ignored even the most basic HTML 5 tags–even <section> proved uncharismatic. To the rescue, JavaScript; more specifically, the “HTML5 Shiv” (love the name, which captures the mood of destructive exasperation IE inspires) script popularized by John Resig and Remy Sharp.

Overall, it was an enjoyable stroll through HTML 5′s more accessible areas. Maybe XHTML 2 would’ve been a more thrilling excursion, but I’m content. Shiv or not, it looks to be sunny ahead.

5 Ways to Style dl

June 17, 2009

Tags: , , ,

Recently I lamented the rare usage of the supremely useful directory list, dl. The directory list is a pretty common data structure: one heading, followed by one or more related subsidiary data. It’s appropriate for more situations than it’s used for, probably because so many developers fixate on markup’s visual design rather than its information design. Browser defaults for dl obscure its versatility:

Firefox default for dl

Firefox default for dl

But there are so many occasions for which dl is the obvious data structure, once groomed by applicable CSS styling. As end users adopt standards-compliant browsers with better support for CSS 2+, styling dl into recognizable data structures becomes nearly fun, and will tempt you to try the ridiculous.

For instance, dl adapts readily to become the container for a recipe:

dl as recipe

dl as recipe

The CSS for achieving this assumes that you’re using one of those newfangled browsers with excellent support for CSS 2+:


dd {
display: inline;
margin: 0 .25em 0 0;
}
dd:before { content: " First, "; }
dd:after { content: ".  "; }
dd+dd:before { content: "Then, "; }
dd+dd+dd:before { content: "Finally, "; }

There’s a similar mechanism for forming dl into a citation:

dl as citation

dl as citation

CSS:


dt { font-weight: 700; }
dt:after { content: ":"; }
dt, dt:after, dd { display: inline; }
dd { margin: 0; }
dd:after { content: ","; padding-right: .25em; }
dl dd:last-child:after { content: "."; }

dl is, semantically, a good choice for an accordion menu, with a CSS :hover or JavaScript event attached to dt:

accordion, collapsed

accordion, collapsed

accordion, active

accordion, active

CSS:


dt {
font-weight: 700;
}
dt:after { content: "\203A"; padding-left: .25em;}
dd { margin-left: 0; visibility: hidden;}

dl:hover dt:after { content: "\2026"; }

dl:hover dd { visibility: visible; }

And then are ways to style dl which, yes, test the capabilities of CSS, but are just plain dumb. If, for instance, you feel compelled to style dl as a table or as a bulleted list, you should question why you’re using this particular markup, and not table or ul:

dl as table

dl as table

Picture 2

dl as bulleted list

The CSS for these stunts:


dl { display: table; }
dt {
display: table-caption;
font-weight: 700;
margin: 0;
text-align: center;
}

dd {
border: 1px solid #eee;
display:table-cell;
margin: 0;
padding: .25em;
}


dd {
display: list-item;
list-style: disc;
}

Versatility, it’s a burden.

Review: JavaScript Performance Rocks!

May 24, 2009

Tags: , ,

by Thomas Fuchs and Amy Hoy

by Thomas Fuchs and Amy Hoy

Title:  JavaScript Performance Rocks!
Authors: Thomas Fuchs and Amy Hoy


Pros:
  • Concise, easy-to-follow advice with good examples
  • Some overlap with other treatments of the same subject, such as posts on Ajaxian or the Steve Souders books, which reinforces the learning
  • Download includes the DOM Monster bookmarklet, which assesses a given page for conformance with the book’s recommended techniques
Cons:
  • Casual,  breezy tone in the prose which is hard to tolerate for very long
  • Idiosyncratic landscape format for page layout; difficult to read onscreen, terrible for printing out

JavaScript Performance Rocks! is yet another indicator of front-end development’s new status as something worth improving.  The authors examine where the scripting on a Web application interface frustrates or thwarts the user, and offer techniques either to speed up JavaScript rendering by various browsers, or to manage the user’s perception of that speed.  Some of the techniques will seem familiar if you have read much about JavaScript performance in the last two or three years–the greatest benefit this book gives you is having all that lore in one place, with justifications if you need to supply them when you use these on a project.

As of this writing, JavaScript Performance Rocks! is in beta.  When you purchase the download, you are assured of updates, which is necessary because some sections  remain incomplete.  I’m skeptical the final version will improve what I consider real problems with this book, which are in its prose and visual styling.   Both, I assume, are the results of the authors’ vision of delivering a technical book which would be fresh, hip, and not too serious.  Unfortunately, the youthful lingo wears–imagine having a hipster, like, totally, goin’ on about, you know, JavaScript? and you might experience the same impatience too many pages of this will give you.

More problematic is the book’s visual design.  I’ve looked several times at the landscape-oriented pages, trying to understand why they aren’t given the conventional portrait format.  I think the intention is that each page’s content falls “above the fold,” and the reader won’t need to scroll down to read it entirely.  However, on my monitor, this perfect layout only arrives when I reduce the page size in Acrobat Reader to 75%, which also reduces the fonts below my preferred level.   In any case, thinking of alternate presentations for this material is a needless distraction from it.

Included in your download of the beta is the marvelous DOM Monster utility.  If your questions about JavaScript performance concern an application you have already built, the DOM Monster gives you an easily comprehended diagnosis: where do you have too much whitespace?  Where are there empty nodes?  Do you have too many links to scripts and stylesheets?  I won’t be surprised to see this bookmarklet sold as its own product, given its immediate usefulness, but I’d be dismayed if developers used it without reading the accompanying text.  For, whatever its flaws, JavaScript Performance Rocks! comes highly recommended.  Like, all, hella recommended.  By me.

Powered by WordPress