The latest in HTML

No question, HTML5 is big news. It’s the subject of sold-out conferences, mobbed Meetups, and recent best-sellers. It’s even become a catch-all marketing phrase perfectly contoured to shove into presentation slides. But HTML5 better watch its back. There’s yet another promising HTML standard out there. It’s what you’ll want to use on your next project–hip, cool, and wholly cross-browser compatible.

Get ready; here comes HTML 3.2!

Whether you’re looking for a new front-end dev gig, or just trying to freshen up your skills, learning HTML 3.2 in the upcoming months will be crucial. Fortunately, it will probably be a skill you’ll enjoy using once acquired.

When you convert your legacy markup from HTML5 to HTML 3.2, you’ll find some elements familiar to you: <P> and <BODY>, for instance. The biggest task you’ll have is removing all that CSS cruft so you can take advantage of HTML 3.2’s many presentational tags and attributes, such as <FONT> and <CENTER>. You can also replace many lines of CSS rules by using <TABLE>, <TR>, and <TD> for layout (a technique possible in HTML5 as well, but rarely explored).

Other features of HTML 3.2 include the useful <BLINK> and <MARQUEE> tags, though, regrettably, these have poor cross-browser support. You will have to polyfill with JavaScript to assure that all users can access this content.

Attendance at the recent HTML 3.2 Hackathon was small but enthusiatic

If your legacy HTML5 code base is extensive, you might find the job of converting it all by hand a daunting challenge. This is a situation ready-made for a WYSIWYG editor. Software makers have taken notice of the opportunity to jump on the HTML 3.2 bandwagon; you’ll have your pick of user-friendly tools. The most popular choice seems to be Microsoft’s FrontPage. Adobe isn’t far behind with the PageMill application. If you have the Netscape browser installed, you’ll find its built-in Composer product easy to use for your cutting-edge HTML 3.2 project.

True, it can be frustrating sometimes to keep current. Just when you thought you knew the difference between <article> and <section>, along comes an HTML standard which includes neither. Yet think of the compensations–you’re not losing <canvas>, you’re gaining <LAYER>.

Sh*t People Say to Front-end Developers

  1. We really don’t need a designer.
  2. What’s an information architect?
  3. Nobody will be looking at this page with a mobile device.
  4. This style guide from 2002 is still good.
  5. We really don’t need localization.
  6. This Excel spreadsheet is our issue tracker. Works great!
  7. Using Flash would make this so much easier!
  8. HTML5 is too risky and experimental.
  9. What’s a validator?
  10. Browser support? All of them, of course.
  11. We really don’t need a copywriter.
  12. Of course our users will sit through this thirty-second auto-play splash video.
  13. We really don’t need JavaScript testing.
  14. The database guy already did the HTML and CSS, so you just have to add a few tweaks.
  15. Of course our users will submit this twenty-question form before seeing our content.
  16. This will be a short project.

What not to buy in 2011

This is the time of year when the Interwebs are flooded with “what to buy…” consumer guides. In contrast, the things I discuss below are much cheaper, saving you both time and money, because in the end you won’t be shopping for them at all.

(An aside to Web services freelancers: you know, if we stop offering these things, people will stop thinking they can obtain them. Give it a thought.)

What not to buy in 2011

  • Support for IE 6. Freelancers–put a clause in your contracts that requires a $10,000 deposit before you even start up IETester or the like.
  • Meetings requiring developer attendance.
    "Sunday," © Peter Paul Jacques
    Described variously as “toxic,” “a disaster,” and “the biggest productivity killers for programmers,” meetings are relics from the twentieth century which have as much relevance to your technology projects as do carbon paper and stenography.
  • The cost of a stern “butts-in-chairs” policy. Savvy, experienced developers know what conditions make them productive, and these are various. Nobody lists compulsory enclosure in a cube farm among those conditions.
  • Huge office spaces. Since you’re not having meetings, and you’re letting your team co-work or telecommute, you don’t need all that much space anymore.
  • Fake work.
    Fake Work: Why People Are Working Harder than Ever but Accomplishing Less, and How to Fix the Problem

    This should be obvious, but somebody had to write a whole book about it to expose the problem.

  • Expensive conference fees. As Rebecca Murphey noted, the most useful conferences for Web technology seem to be ones organized by and for practitioners, who aren’t always bankrolled by deep-pocketed corporations.
  • Tag soup, nouvelle cuisine style. Regrettably, HTML5 provides just as many opportunities for lousy markup (“<div>-itis,” overuse of class and ID attributes) to the novice and/or the unconcerned, asĀ  did earlier HTML standards.

What’s dropped off your 2011 shopping list?

HTML5 Forms: browsers get jetpacks

Self-identified standardista Estelle Weyl enlivened a recent HTML5 Meetup with her summary of the neat stuff we could use if only everybody used, say, the latest version of Opera.

How many lines of JavaScript have you written to enforce a pattern on user input? To set focus on a certain form element? To mark input required, and bark at the user who doesn’t supply it? How about offering a calendar pop-up for a date picker? Between HTML5 and CSS3, there are new options for markup–no scripting necessary!–which handle these scenarios.

Well, that’s the promise, anyway. It’s nice to hear the future is nigh; it somewhat offsets the discouragement you’ll feel when you obtain the latest statistics on how many Web users continue to use terrible software such as Internet Explorer.


Carefree living post-IE 6

Hearing about nifty HTML5 wonders at present feels a lot like watching those filmstrips about “life in the year 2000 A.D.!” when I was a kid: substitute attributes like “placeholder” and “datetime-local” for “flying cars” and “robot servants” to update to the latest shiny, optimistic vision.

Yet it’s not we shouldn’t use HTML5 forms–we’ll just have to prop them up with JavaScript crutches, until the browsers of Tomorrowland are in common usage.

Note: Estelle’s presentation might be expanded for SXSW 2011.

My First Web Page

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?

In Praise of dl

Consider the task of delivering this:
heading-and-data

It’s a construct you’ll see everywhere on the Web: a text heading in bold type, with perhaps some background styling, and subsidiary text beneath it, often styled a little differently, such as in a lighter font style. The heading and the content beneath it seem to be related; visual design can give more evidence of that relationship with flourishes like the gray border enclosing the text blocks in the example above.

So how is this very ordinary construct expressed in HTML? Sadly, often in the most verbose, inflexible ways possible.

For instance:

<p>
	<strong>
		Heading
	</strong>
</p>
<p>
	Stuff under heading
</p>
<p>
	Stuff under heading
</p>
<p>
	Stuff under heading
</p>

Or:

<div class="heading">
		Heading
</div>
<div class="data">
	Stuff under heading
</div>
<div class="data">
	Stuff under heading
</div>
<div class="data">
	Stuff under heading
</div>

Or even (shudder):

<table>
	<tr>
		<th>
			Heading
		</th>
	</tr>
	<tr>
		<td>
			Stuff under heading
		</td>
	</tr>
	<tr>
		<td>
			Stuff under heading
		</td>
	</tr>
	<tr>
		<td>
			Stuff under heading
		</td>
	</tr>
</table>

Why? There’s an obvious solution in dl, which has been in the HTML specification since, for crying’ out loud, version 2.0. All you need to express this particular data structure are dl, its subsidiary elements, dt and dd, and basic CSS skills.

<dl>
	<dt>
		Heading
	</dt>
	<dd>
		[Stuff under heading-- 
		express each as paragraphs, list items, or other elements]
	</dd>
</dl>

Advantages of this approach include preserving an obvious heading/data relationship between those elements. If there is a situation in which your CSS does not render, user agent defaults will still indicate this relationship. For instance, in Firefox, the content enclosed in dd will have a slight indent from the left margin of dt. In screen readers, the dl will be announced as a definition list, and its numbers of items (dd) reported as well, which helps non-visual users understand where the list begins and ends.

Another advantage is flexibility in styling. There’s nothing intrinically presentational about dl, unlike strong or tr; indeed, you can make the same construct look very different with very simple CSS:

Three ways to style a definition list
Three ways to style a definition list

So why is this marvel of semantic markup so underused? Do we really prefer typing in strong? Is it human nature to take the long way? Has the div Element Marketing Association been extraordinarily successful?

Please tell me why.