arkitrave log

arkitrave :: log

9/17/2005

The tension between browsers and designers

Filed under:

A couple points in the recent IE Blog IE7 update have gotten me thinking about the tension and interplay between browser makers and web designers. Basically, I believe that browsers for too long have abdicated their responsibility to produce really comprehensive software, giving the entire responsibility for a good user experience to the web designer. There are fundamental flaws in this way of thinking. Let’s start with a bit of history.

HTML essential in the beginning
In the beginning, the browser makers provided all of the “style,” which largely consisted of making (for example) <h1> text large, bold, and Times New Roman. This kind of feature set was necessary for users to make any sense of the HTML markup of the page. Without this “browser style sheet,” web pages would just be endless plain text. This is the brilliance of markup, and it worked for scientific papers and the first company sites. It was necessary to have a reliance on proper markup as a designer, otherwise nobody could make heads or tails of your site.

HTML abandoned
However, it was short-lived. The browsers’ abilities in presentation were sorely lacking in design panache, with bland gray backgrounds, black text, and Berners-Lee/Nielsen link colors. Once the <font> tag was invented and designers figured out how to use shim .gifs and tables for layout, HTML as a markup language went the way of the dodo. Designers soon abandoned HTML altogether, using it as a way to organize and present a page rather than mark up content. The browsers were all too happy to agree, extending HTML until it was virtually meaningless, full of proprietary features that moved HTML away from more than a passing resemblance to a structural language.

HTML returns
After CSS has been around for, what, close to 8 years, we’re seeing a widespread return to the original spirit of HTML. Many designers are beginning to re-grasp what they forgot from 1995, which is that content needs to be marked up properly and then styled. We’re seeing a separation of content, style, and presentation that is great news for the web. We’re at the edge of some really exciting possibilities, and I’d hate for things to get messed up now.

Enter the browser makers
This is a critical point in the interaction between browsers and designers. Let me explain what I mean. One of the things Microsoft is implementing in IE7 is a shrink-to-page feature. This is an example of a browser acting like a piece of software, which is exactly what it should be doing. You could say that this takes control away from the designer, and in a way it does. But, it’s control that we should be willing to relinquish.

Let me use another, probably better example. We’re solving a data problem at work by using an XML file to store data for many similar products, because this particular site doesn’t live on our normal server environment with access to the company-wide content management system. The file consists of images and captions for each product, which for now are displayed on a thumbnail page. To get the captions’ lines to break properly on the sample page I gave her, the developer added <br> tags inside some of the captions.

Of course, this works on the sample page. However, one of the purposes of using the XML file is reuse of the data. I’m probably going to have an order form, and definitely a larger image popup with a caption. So, the <br> tag only works on the thumbnail page. It took quite a bit of convincing to talk her into removing the tags, and the client might still insist on them later.

The problem is that the client isn’t going to like an orphan word on a separate line on the thumbnail page, which could happen without the <br>. But I have no choice. I either formulate my XML for one specific page and font size, which makes it fail when 1) a user resizes text or 2) when the XML is used in another context, or I risk the occasional line break in the wrong place.

What is the solution to this specific problem? A browser which is bright enough to see the orphan, and correct it, wrapping the line one word early. Word processors have done this for years. Why is there no browser that can intelligently end a paragraph?

captions line break comparison

This is just one example of something a browser could do which in some ways takes control away from the designer, but serves the greater good of clean, structural markup. It isn’t something that we’d want as a part of CSS (I don’t think), because it’s just a standard, accepted way of presenting information. If you’re writing poetry, and the breaks are important, that’s where structural markup like <br> tags come in.

I’d love to hear other examples like this. How else can browsers take that extra step of presenting information in ways that keep us from having to use hacks and additional markup? How can the browser be a partner, rather than the extremes of 1) taking all control away or 2) leaving all control to the designer?

9/11/2005

Literally not a label

Filed under:

When building pages that utilize JavaScript which will be implemented into a .NET framework, be sure to tell the developer (or if you’re like me, do it yourself) to use <%asp:literal%> tags rather than <%asp:label%> tags for database-driven content. .NET will automatically add <span> tags to anything inside a label, whereas a literal will be implemented as pure data from whatever data source you are using. The problem is that developers are trained to use the label, rather than the literal, so they won’t do this on their own.

The literal preserves the integrity of your HTML, the label does not. If you’re writing a script that, say, swaps out an image caption in a paragraph, dynamically writing that paragraph’s firstChild node value, you will run into problems if an additional span tag, inserted by .NET, appears inside that paragraph. The script will, of course, find the span tag and identify it, rather than the text node you were going for, as the firstChild.

Don’t let .NET write your code. If you’re a front-end web designer, learn enough about the framework your designs will be implemented in to know how to keep them from being messed up by the backend. I’ve learned my lesson, and was able to help a developer better understand the impact of his code choices on the front end. Now I’ll (hopefully) get asp:literals every time.