Skip to: Navigation | Content | Sidebar | Footer


Full Archives

Who Cares about Semantics Anyway?

May 30

On semantic markup, conveying its usage to those who generally don't need to care, and a reusable markup guide for your enjoyment.

This is how I like to define the term 'semantic markup':

Semantic Markup is the result of using (X)HTML elements for their proper, intended usage.

This is a pretty limited definition, better examples exist, and it's by no means the only viewpoint out there. The terseness is partially the result of HTML being semantically limited to begin with. We don't exactly have a rich vocabulary of element types capable of capturing the meaning and nuance behind every piece of text: We have code, but we don't have caption; We have kbd, but we don't have childlikescrawl; We have emphasis, but we don't have publicationtitle. And so on.

Why care? It's a good question, one I've also asked. If you spend time putting semantic markup into a page, there ought to be a payoff. Unfortunately, the payoff is less than visible. Since CSS is able to make any element look like any other element, you won't see the result in a visual browser. It's only when you load a semantically-rich page in a text-only browser, or in a screenreader (or other alternative access device) when you'll start to understand the benefit of authoring this way. Additionally, various stabs have been made at extracting the semantics from a document and putting them to more general use. See Mark Pilgrim's Million Dollar Markup and Tomas Jogin's Hierarchy.

XML gets us the ability to work around this limitation, of course. By defining new, semantically rich languages, we can add extra meaning to our documents (and while we're at it, create tools to pull that meaning back out later and actually do something useful with it). But that's strictly tangental, considering the utility of HTML here and now. We use HTML for web pages, so the limitations are something we have to think about.

Semantic debates about which element to use in which scenarios are usually quite arbitrary and prone to subjective interpretation. Here's a good example: the address element. The spec has this to say:

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.

Then it goes on to list an example with virtual addresses, in this case URI's to the page author's profiles. Presumably, email addresses would be acceptable in this space, but does that hold true for physical addresses? You may be surprised at how many different individual opinions exist about this, as evidenced by this SimpleQuiz from a year ago.

The ambiguity lies in the fact that the term 'contact information' is undefined in the spec, and therefore it's left to the user's best judgement to fill that in with whatever contact information they deem relevant. So one person's email address is another's street address, which is yet a third's PO box, which is a fourth's airport locker number.

And that's all okay, you know. The spec is loose enough that it provides guidance, but actual usage is going to determine the most relevant and appropriate ways to use the markup in question. Individual preferences will guide deployment of the elements, and if a consensus is ever formed, so be it. Until then, vive la différence. HTML elements are basic constructs, it's up to you to build something with them.

But even this gets tricky when you no longer have control of the semantics of a particular document. What happens when you pass your markup on to a client? Ever worked with a content management system that allows multiple authors to mix and match their own elements for whatever purposes they have in mind? How often do you find them choosing elements based on how they look, rather than what they mean? I see more than a few heads nodding.

"Just educate your clients", you may think. I hope you understand why this doesn't always work. As an analogy, compare and contrast these situations:

  1. You just built a site for a plumbing company, complete with a CMS. You tell them to make sure to use <ol> elements for parts lists, and <h2> elements for product names on their respective pages. 6 months from now, you check the site and find a ton of <br /> elements to separate the list items, and headers in <font size="5"> tags. D'oh.
  2. In exchange for your work on the site, the plumbing company gives you some advice on your kitchen remodeling. They suggest copper pipes for your water lines running through the exterior walls, with a small length of flexible CPVC inside the house. You decide to go all CPVC because it's slightly cheaper. 6 months later, your pipes burst during a particularly cold winter night. D'oh.

In both cases, a little bit of education goes a long way. In both cases, the client needs to take a little initiative of their own to ensure higher quality. In both cases, there will be people looking for shortcuts who simply won't take the advice of the expert.

Simply, you can't assume the client will care unless the task they need to perform is personally relevant to them. Education can only go so far, there has to be motivation. But that doesn't mean it's not worthwhile to try anyway; the site may be delivered to a single person or company, but after that it will be used by a far wider audience who will benefit from proper semantics. That's why it's important to care about semantics, as a web designer/developer, and at least try to convey some of that importance to your client.

To that end, I've recently started work on a rough style guide that I distribute to clients as a part of my completed deliverables. This is a single HTML document, marked up with both examples and descriptions of various elements. It also serves as a palette of sorts, graphically depicting the various elements when rendered in the site's style sheet (assuming the CSS file has been linked.) It's a rough start, and will evolve over time, but it's important enough for the education process (and easy to re-use) that I've been relying on it since I wrote it.

Here it is, the mezzoblue Markup Guide, available in formatted and bare-bones unformatted flavours, with a permanent home in the Downloads section of this site. Feel free to use, edit, and share alike. I'd love to see this expanded and improved upon by all of you, with revisions released under the same CC license.

Permalink › | 51 comments

Security, not Obscurity

May 19

Lesson learned: remove, don't rename.

Don't ever rely on security through obscurity, they say.

You know, they might just be right.

I'm giving TSEP a try to replace the limited Movable Type search box currently driving this site. Not only is it picking up all sorts of old archived files I had completely forgotten about, my heart absolutely sunk as I realized I had turned on PHP parsing just before it ran across an archived file that runs this little snippet of code:

$queryWipe = "DROP TABLE IF EXISTS submissions";
$queryCreate = "CREATE TABLE submissions (
  submissions_id mediumint(8) NOT NULL auto_increment,
  name varchar(48) NOT NULL default '',
  email varchar(40) NOT NULL default '',
  url varchar(128),
  nationality varchar(64),
  cssfile varchar(255),
  zipfile varchar(255),
  title varchar(64),
  windows varchar(255),
  mac varchar(255),
  notes text,
  status tinyint unsigned,
  archived tinyint unsigned,
  date datetime,
  PRIMARY KEY  (submissions_ID)
) TYPE=MyISAM";

require_once ('fetch-mysql-connect.php'); 

$result1 = @mysql_query ($queryWipe);
$result2 = @mysql_query ($queryCreate);

For those unfamiliar with SQL syntax, this sets up the data table for my Zen Garden manager by first erasing whatever exists. Essentially, it resets the database. (For those familiar with SQL syntax, yes I know I could stand for a huge dose of normalization, which is coming, but beside the point right now.)

You have no idea how much of a relief it was to open the file and find I had previously commented out the last two lines as so:

echo "Dangerous! Don't actually RUN this, you idiot.";

// $result1 = @mysql_query ($queryWipe);
// $result2 = @mysql_query ($queryCreate);

Two lessons learned here.

One: always delete the file with sensitive data or code. Don't rename it, don't move it into an ./archive directory (which I had done with this one). Get it right off the server. I was extremely lucky in this case, and you're probably smarter than me with scripts like this anyway, but it'll sure save you the mini-heart attack I just had at the very least, if not prevent actual damage.

Two: backup, backup, backup. I had done so recently, but still. If you haven't figured out how to backup a MySQL database yet, either use phpMyAdmin if you have the option, or this also does the trick provided you have ssh access to your remote server. (Make sure it's all on one line, it's broken here for spacing):

mysqldump -add-drop-table -u {your username} 
  -p {your database name} > {backup filename}.sql

And this restores it (again, all one line):

mysql -u {your username}
   -p {your database name} < {backup filename}.sql

Since I'm the kind of person who always likes a good example to go along with my syntax, here's what that might look like in case you're the same way:

mysqldump -add-drop-table -u dave -p zengarden_manager > zengarden.sql

...Where dave is my username on the mysql server in question, zengarden_manager is the name of the database, and zengarden.sql is the file the database gets backed up to. You'd be prompted for a password after running the command. Make sure your path is currently located in the directory you want the file to end up, or else specify a full path in front of the file, maybe something like so: ~/backups/zengarden.sql

Permalink › | 30 comments

Columns & Grids

May 13

The difficulty of grid systems in web pages, the compromise of columns.

I seem to quite often go back and forth between creating organic layouts with intuitive proportions, and creating a grid that I can hang my various elements on. Lately I've been more interested in the latter. Frequently I've caught myself calculating in my head what 750 divided by 3 minus two 10px margins equals.

One of the larger problems in working with grids in web pages is that you often can't do much about vertical proportions. Often your content is dynamic, so the best you can do is approximate. Throw in any compensation for font scaling, and it's easy to lose any semblance of control over the way a layout expands downward.

So the focus is usually on the horizontal layout, which usually means columns. (Incidentally, if you're ever wondering why fixed layouts are so popular amongst designers, this has a lot to do with it—it's awfully difficult to build any coherent form of grid when you lose control of proportions in both dimensions at once.)

1 Column

1 Column Layout Example

As simple as it gets, the one-column layout has been around since the beginning of the web. 1994 gave us a grey background and black Times in a single column running down a browser window, the most primitive one-column possible (although calling it that is a bit of a stretch. See: an early Yahoo). It has evolved nicely since then, and some recent redesigns are putting it to good use. (See: Garrett Dimon)

2 Columns

2 Column Layout, equal-sized columns

The realm of the blogger. Two columns are utilitarian and perfect for presenting content and further navigation/archives/whatever side-by-side. Popular variations include the fixed sidebar/liquid content area setup (See: Malarkey) and the fixed-width, narrower sidebar/wider content area setup (See: the sadly now-defunct Weightshift).

2 Column Blog Layout

Layouts with 2 columns or more force a choice that a single column doesn't: equally sized columns, or varied widths? Ratios are important, and certain width combinations are more aesthetically pleasing than others. It's pretty hard to go wrong with 1:1 widths (or 1:1:1, or more). It's a little more difficult to choose non-equal sizing because there are no hard rules. You could pick a 5:8 Golden ratio (in a 750 pixel wide layout, translating to roughly 290px and 460px), a 3:4 ratio (320px and 430px), a 1:2 double square (250px and 500px), and so on. (Pleasing rhythmic proportions often share proportions with musical time scales, as you may have noticed.)

3 Columns

3 Column Layout, typical blog dual-sidebar format

Once you add a third column, the options increase. What a third column enables is the possibility of a virtual column, one that is not absolutely defined in the layout, but exists by proxy. Consider this site, for example. On all pages with a sidebar, it appears to be a two-column layout. On the home page, the larger red panels imply the existence of three equal-sized columns. I haven't pushed the possibilities of this third column yet, but this design does allow for it if I ever feel so inclined.

3 Column Layout, overlapping elements

As well, 3 column layouts allow for overlapping elements. Consider the home page of Stopdesign, and how the leftmost two columns are joined by the overlapping featured article. Of course, it's theoretically possible to pull this off with only two columns, but I rarely see it done on the web. A 2 column layout has traditionally meant that the content of each column lives in that column, never to overlap.

4 Columns

4 Column Layout

4 column layouts are where screen size constraints start becoming more obvious. With only so many pixels per column, it rarely makes sense to rely on 4 equal-sized, side-by-side columns on a site. StyleGala redesigned last year to a widescreen format with 4 equal columns; to compensate, a narrower version exists with 3 columns instead.

4 Column Layout, unequally-sized columns

Not to say the columns need to be equally sized. Josh Dura appears to have made a stab toward a smaller-sized 4 column layout, with 3 skinny columns on either side of a larger content area. (Although there's plenty of overlapping going on, so in some places it's 2 columns, in other places it's 3. Whew!)

More Columns

4 columns is hardly the limit though, even within sensible designs that don't push the width requirements too hard. Consider B. Adam Howell's redesign—your screen size determines how many columns you see, up to six. And the entire thing stretches to fill the screen, so it's resolution-independent.

Subtraction.com's 8 Columns

And you knew I was getting to Subtraction eventually, right? Khoi's layout turned heads for more than just its black-and-white sparseness. Subtraction uses an equal-sized 8-column grid, with intelligent overlapping and column arrangement to make it seem quite a bit less.

What's particularly clever about Subtraction is how all elements on the page intentionally fit into the grid. Whether it's the Quick Access panel on the right spanning 2 columns, a content image spanning half the page (4 columns), or a caption sitting in the left-most column, every element on the page has a specific place within the grid and it all meshes wonderfully.

Further Reading

Permalink › | 27 comments

Image Attributes

May 10

Questioning width and height values for images.

Paraphrased, from the inbox:

height and width attributes no longer apply to images, I suspect. How then do my images render? They seem to automatically size. Is it based strictly on their original size, or should I be defining my attributes in my CSS?

Good question. I still set these particular attributes in my HTML, for both historical and practical reasons.

It used to be, before we were building table-less layouts and offloading all presentation to the CSS, that defining an image included things like turning off the border (darn 2px, blue-bordered linked image default!), specifying ALT text, and defining the width and height values. The latter were important because, as a page loaded, the space for an image needed to be set in advance. Without width and height, the image dimensions weren't known until the image was entirely loaded. Small spaces were left for each image by default, but a page would jump around disconcertingly as it resized to fit the images as they loaded. This was particularly annoying given the image slicing and dicing that table-based layout forced, so specifying the dimensions alleviated the problem nicely.

(Interesting side note—Safari 2 seems to have an entirely new way of loading in larger images. [30k or more? I'm not sure what the threshold is, but it applies even to background images defined in CSS. Clear your cache and hit up Stopdesign for an example, see the header image.] Whether they're interlaced or progressive or not [who interlaces images anymore?] it appears that the image is loaded in progressive chunks, which appears to 'slide' in the image. It looks like a Flash transition of an image, starting out squished up at the top, and expanding to fill the regular image dimension. Hard to describe, a little disorienting at first, but neat to see in action once you get used to this new method.)

Now, that's the historical reason which, while in some contexts may still be relevant, generally isn't a trick we need anymore. So why not offload these presentational width and height values to the CSS? I don't believe they belong there.

First of all, there's the practical management issue. If you have a series of images that are all precisely the same dimensions, then defining a single class to control those is easy. If you have a few dozen that come in wildly varying dimensions, setting a unique class for each makes less sense. In many realistic scenarios, you have to account for images you won't know the dimensions of ahead of time. So the CSS route doesn't make sense, given that a) you may have hundreds of images to define separately, and b) you can't define them when they're not known.

Secondly, image dimensions are presentational values, so it might make sense they belong in the CSS... but they're also metadata about the image itself. Very important metadata. I wouldn't go so far as to call them "content", but consider that the size of an image is as important to its final presentation as the colour of the pixels. If you can successfully make an argument for an image being an item of content, surely this metadata is more important than the sometime sacrifice-able presentation CSS affords. (Dimitri Glazkov recently explored the difference between presentational and content images.) So, if the dimensions are specifically bound to the photo, can they peacefully exist in the CSS (which may or may not be present in the final rendering of the page)?

Actually, the question put forth was more direct—why bother specifying attributes at all, whether in HTML or CSS? The image comes with built-in dimensions, the browser will know how to render the image. It seems almost pointless to bother specifying them, since that metadata already exists in another form.

Which seems theoretically true, but for just one little problem—the way the page loads before the image is placed. Since we're talking about content images here, and not the hundreds of tiny GIFs that would previously made up a sliced and diced site, it's a pretty small problem nowadays. Although given the rise of RSS, you may have noticed the same thing I have—the resizing problem is far more obvious when a content image is embedded in a news feed, and the accompanying HTML doesn't include image dimensions. Since RSS aggregators typically display a feed as plain text with minimal decoration, it's more obvious given the sparse surroundings. Specifying image attributes alleviates this, the same as it did in '97.

Ultimately I don't think specifying attributes in CSS is wrong, I just see plenty of reason to continue doing as I've always done on this point.

(Sharp readers will notice that my second argument for keeping image dimensions out of CSS is invalidated by the later conclusion that this data exists elsewhere; however, this still leaves the first, and more relevant point: management is difficult, if not impossible. I'll continue to specify attributes in my HTML unless a really good comment on this article convinces me otherwise.)

Permalink › | 54 comments

An Inevitable Tiger Review

May 2

A running tally of all the cool (and not so cool) new things I find to love/hate in Mac OS X 10.4, otherwise known as Tiger.

Tiger—the latest version of Mac OS X—was released to a lot of fanfare on Friday afternoon, as you're no doubt aware by now since it seems to have garnered an inordinate amount of press. For an insanely comprehensive review of the low-level stuff, turn to ARS Technica. For a look at the smaller changes that affect day-to-day usage, check out John Gruber's running tally.

As a fairly recent Mac convert myself, I hadn't bothered going out of my way to find myself a copy of Panther, the previous upgrade, until a few weeks after its release. This time around, I made sure I was at the front of the line when the boxes went on sale. The store was busy, but not nearly as much as I might have expected. Looks like the Apple stores themselves (of which we have none in Canada yet) had a bigger turnout.

With barely a few days of usage on the new OS, how am I liking it? That's inconclusive for the moment, as I still haven't had any lightning bolt revelations like the way Exposé struck me. I'll need more time than this to really form an opinion. It looks like there's a lot of good new stuff to explore, and of course a few new annoyances to adjust to. I'll keep this list running over the course of this week as I dig further in to my new toy, and add new items as I find them.

System Slowdown

Anecdotally, and based only on a gut feeling, my system feels slower. Many have reported the opposite to be true, so I think I might be an exception. I upgraded my 10.3 install instead of doing an entire re-install, which might be part of the problem. Just prior to the upgrade though, I was rapidly running out of primary drive free space (to the point where I only had a few hundred MB left). I've since cleared off about 5GB, so my virtual memory shouldn't be a bottleneck here, although I'm tempted to assume my drive is quite a bit more fragmented now. If so, I wouldn't be surprised if that alone explained the slowdown. Otherwise it might be time to think about dropping a few widgets off my Dashboard..

Automator

I finally got around to tinkering with the new Automator, and I feel pretty positive about it. It's limited to a series of pre-canned actions for various applications, which currently consist entirely of Apple products. But it's also open to developers adding hooks within their own applications, so that will probably change. I get the feeling it's essentially AppleScript lite, for those who choose not to learn the language. Suits me fine.

Image Dimensions in Column View

Finally, it's no longer necessary to Cmd + 1 to switch to icon view for the sake of getting image dimensions. As long as 'Show Preview Column' is checked in view options (Cmd + J) the preview column contains 'em.

Column View Image Dimensions

Installation

Installation was a snap, as I'd pretty much expect from any major software release right now. After appropriately backing everything up, unplugging the external Firewire drive, and clicking a few dialogue boxes to get things underway then ducking out for a movie, coming back to a freshly Tigerized computer was a nice treat.

Safari 2.0

The new RSS feature seems pretty much useless to me, a happy NetNewsWire user. I don't see much point in reading a site's RSS feed in the browser, when I can simply read the full site. Maybe I'm missing some kind of aggregation feature that lumps all the various feeds together the way a traditional news reader does.

Update: If you haven't already overridden your default RSS button action with a non-Safari aggregator (like I have), apparently creating a bookmark folder of RSS feeds will enable you to view them all together after all.

Credit where it's due though, Safari lets me click on the blue RSS button to subscribe to a feed in my default newsreader, which happens to be NNW. It doesn't lock me into Safari itself, which is smart. Beyond RSS, there's plenty new to see in Safari 2.0. This is the one I expect to dig into much further, but for now I'm quite impressed by the speed improvement.

Minor annoyance: context-sensitive menus on links and images have improved, but the old standbys "Save Image As..." and "Download/Save Linked File As..." are a bit different, saving to the Desktop by default. Pressing Option brings back the old menu items, but still. I categorize my downloaded items as I grab them to avoid a marathon clean-up session later; why discourage that behaviour?

Slideshow

I've never quite gotten the hang of the Photoshop file browser, and iPhoto is way too slow, so this is one of the best new additions for my particular workflow. Ever since switching from Windows XP, I've missed the equivalent functionality of being able to view a folder of images in slideshow format. The Tiger implementation is spectacular, allowing you to quickly alternate between a series of slides and a full-screen view of any particular image.

Here's how you get to it:

Slideshow access button

Here's the full-screen view and controls:

Slideshow full screen view

And here's the slide view, which expands and collapses in a way reminiscent of Exposé:

Slideshow slide view

But read the next point.

Slideshow

What's absolutely appalling is how buried this new functionality is. The only way I've found to get to it is by running a Spotlight search, and browsing through the resulting images that return in your search. This might be acceptable if all I ever did was browse by keyword, but there's a reason I categorize my images into folders. I can't imagine why this hasn't been implemented in the Finder somehow.

Update: Turns out it can be done after all. Too bad it's so buried. This is one area where XP has OS X beat.

Dashboard

Dashboard is mostly (very slick) eye candy, but I could see the potential for a few really well-built widgets becoming staples of my daily computer usage. A fair criticism I've heard is that the Dashboard layer, which exists almost as a virtual second desktop for the various widgets, is too exclusive. There's a demand for the ability to move these widgets out of it and onto the real desktop, and move other applications into it. I may be alone in this, but I wouldn't want these widgets cluttering up my desktop. Having them pulled into view by a tap of F12 is a great way of managing them. But a choice is always nice in cases like this.

The widgets themselves look to be a little weighty, memory-wise. No noticeable slowdown yet, but this will be the first place I look if and when. And how come new widgets I've downloaded don't show up in the control panel thingy at the bottom of the screen?

DVD Install

Tiger comes on a DVD. Apparently you can get CDs by mailing the original disc back to Apple along with a nominal service fee, but it's pretty clear that DVD is the new distribution medium going forward. Fine for my Powerbook, not so great for my older iBook which is still ticking along just fine. It'll be interesting to see how its older OS ages.

Spotlight

I've yet to determine how much Spotlight actually changes things. I'm pretty darn addicted to QuickSilver and its adaptive selection; Spotlight feels a lot slower, and the jumping around as new results filter in is particularly annoying.

My biggest pet peeve so far is that results will appear, then disappear as newer and more relevant results filter in. If you're going to show an item in the results at all, leave it there. Yes, I can pull up the full Spotlight window and hunt down the flash of an item I happened to notice, but the relative speed of the incoming results often means I didn't catch enough of a glimpse to retain the name or location.

My searching so far has consisted of a few half-hearted guesses though, instead of anything concrete. Things that are annoying while there's no goal in mind (the multiple clicks to filter by location, the wild variation of data types) might prove incredibly useful when I'm looking for something in particular. I'll have to get a little more comfortable with Spotlight before I'm using it for tasks like that, so it seems like there might be not so much a learning curve as an adoption curve: I understand how it works, and why I'd need it, but I just haven't felt comfortable enough with it to make it a part of my standard routine yet.

Smart Folders

Smart Folders. Saving search results as a virtual folder is brilliant. My favourite new smart folder: Items within "Bright Creative" Last Modified within Last 3 Days. One-click access to all my most recent working files, it's a thing of beauty.

The menu bar at the top of the screen went glossier, while the blue Apple and Spotlight icons on either side went flatter. In all the pre-release screenshots I've seen, both icons appeared to "cap" either side of the menu bar with a full background colour that was clickable; it looked like a great solution to me. In the final release they simply sit there as roundish icons, while retaining the clickable area. Yawn.

RSS Screensaver

The new RSS screensaver is great. Select a source, and watch the latest realtime headlines swoosh around a swirling blue background. Click on any headline to visit the article. Not entirely practical, but hey, it's a screensaver after all. They're allowed to be cool for the sake of it.

Canadian Fix

Previously, in order to enable easy access to advanced character entry tools like the Keyboard Viewer or Character Palette, it was first necessary to select a keyboard language and enable a flag in your menu bar. Annoying, but livable... unless you happened to be a Canadian english speaker, of whom there are many; selecting the Canadian flag would enable a french keyboard layout. The only way around this was to live with having an American (or Australian) flag in your menu bar all the time. Thankfully, the problem has been fixed in Tiger.

Canadian Flag

Dictionary

A built-in, system-wide dictionary and thesaurus are a Ctrl+click away. Available as a context-sensitive menu, Dashboard widget, and stand-alone app, the vocabulary is large enough to be useful, but the built-in search ironically isn't. Results are exact; don't know how to spell a word? Too bad. dictionary.com still has a place in my workflow for now.

(It was interesting to see Apple didn't bother pulling the punches either. All your favourite dirty words are in there and defined, with pronunciation guides.)

Permalink › | 49 comments