October 2002

10/29/2002 Tuesday

Scott Andrew writes with a solution to the NS4.x crashing when writing to layers that I mentioned yesterday. Apparently writing to an existing layer in NS4.x causes a big memory leak but the same problem is not encountered while doing a document.write() when loading a new document into a layer. This suggests the following solution:

  1. Pointing the src of the layer to a special local page, called "blank.html"
  2. In blank.html, there's an in-body script that calls back to a function in layer's parent (the window)
  3. The function document.writes() the content into the layer (no open() or close())

08:50 permalink

10/28/2002 Monday

I'm working on a DHTML app where I have to update divs with new content. We are supporting NS4.x (don't ask why). As a first attempt at the UI, I am writing content into divs despite the fact that this approach got me into trouble on Nike iD. There, NS4.x would crash rather spectacularly and reliably after a couple seconds. I figure it might have been the number of write operations I was making and the amount of content per write. In this project, there are 3 divs that need updating and the amount of content isn't huge. Well, NS4.x doesn't crash but it does ignore any styles I associate with the new content. Normally, NS4.x will ignore the style information that initially applied to the div and you have to explicitly include it with any new content (like enclosing the content in a <span> with a style attribute with all the styles you need). On the stuff I am working on, this is ok for a bit - the styles are parsed and followed for the first couple writes. But then the browser will ignore them and all subsequent writes after that are also unstyled. To make things more confusing, I can't predict when the styles will stop working. Also, the styles usually stop working on the simplist div before the same thing happens on the more complex divs. I am going to have to follow the scheme I ended up using in Nike iD - build everything at the start and stick with setting visibility and position to mimic writing to the divs.
11:45 permalink

10/22/2002 Tuesday

A recent IE5+ all-CSS-layout project had the standard inverted L layout with the main page content stored in a div with a set width. The homepage has a fair amount of content arranged in boxes and columns. In the center, there are 3 columns where I used float to line them up next to each other:

.campaignBlock {
   float: left;
   width: 168px;
   margin: 0 15px 15px 0;
#lastCampaignBlock {
   margin: 0 0 15px 0;

All the divs corresponding to the columns have the class campaignBlock with the last column having the id lastCampaignBlock (the right margin on the other columns is used to space the columns and isn't needed on the last column). The layout works perfectly in all window sizes but not when you go to print in IE6 and Mozilla. The page width is a fixed 700px while the standard print size is 550-odd pixels wide. The requirement was that the printed version look like the screen version (even if some content is cut off while printing). The issue was that the last column wrapped to a new line even though it's parent div had a set width. Other elements contained in the same parent div did not wrap and went off the page including a section that had float: right. I ended up using the following to reposition the last column:

@media print {
   #lastCampaignBlock {
      voice-family: "\"}\""; /* Tantek */
      voice-family: inherit;
      float: none;
      position: relative;
      top: -130px;
      left: 365px;
   html>body #lastCampaignBlock {
      top: 0px;

The @media print applies the rules only to print. The Tantek hack hides the rest of the #lastCampaignBlock rules from IE5.x and those rules move the column from it's wrapped position to where it should go. In Mozilla, this actually positions it too high and the last selector (html>body #lastCampaignBlock) resets the top property for Mozilla. For more CSS Filters, Pixelpark has an excellent chart of the various ways to hide CSS from different browsers.
10:50 permalink

10/21/2002 Monday

When using a link to execute some Javascript but not actually navigate anywhere, put the Javascript in the onclick event handler instead of using a javascript url and set the href attribute to "#". The last Javascript command in the onclick must be "return false;". Excluding this will cause browsers to follow the link (with a "#" href, it doesn't look like the browser does anything but it is reloading the document) and may not give the Javascript enough time to execute. Probably the most common instance of this is using a link to submit a form (instead of a traditional submit button or <input type="image"> which doesn't allow event handlers in NS4.x).
12:40 permalink

I have decided to learn Flash 6. The fact that I don't know it already might be a bit of a surprise. I shall explain: I had made an abortive attempt to learn Flash about 3-4 years ago with Flash 3. At the time, Flash was a buggy, finicky piece of software with limited functionality stuffed into an ill-fitting metaphor (the one inherited from Director of a stage, timeline, etc). In the industry, it was a designer's tool: those who worked with it were also those who designed for it. It had not reached the maturity where design and functionality had separated into two different responsibilities (as had occured with HTML). Given my non-legendary design skills, it wasn't something that I would be called on to use. At the same time, I was concentrating on DHTML. Where I work, much of what we produce is expected to work cross-browser. Cross-browser DHTML was a rare skill and, because of the flexibility of Javascript, could be used where Flash couldn't (or would have been hopelessly unweldy). But that began to change with Flash 4. First, the additional complexity that could be involved when authoring Flash meant that fewer people could use Flash to it's full abilities. A few designers could be considered Flash designers and the rest stuck with version 3 functionality. Later releases separated Flash designers and developers into two distinct roles. The flexibility of ActionScript combined with native XML support and stuff that HTML just doesn't have like sockets means that Flash can be considered for uses that used to be in the domain of DHTML/DOM applications. Yes, it is still buggy and finicky. And the metaphor is even less helpful now. And the filesizes are bigger than with comparable DHTML applications (though this is mostly a function of the designer's compulsion to use the effects that Flash is know for). But it is now up to the abilities of DHTML. And, more importantly, clients want it. You can argue that DOM/SVG is "better" than Flash, Beta was better than VHS, Intellivision was better than Atari, etc but it doesn't really matter what the better technology is if you want a job and the people offering jobs are looking for Flash because that's what the clients want. Update: I should say that the straw that broke the camel's back was the news that a DHTML project that I worked on (and that is one of my biggest sources of pride) is going to be converted to a Flash GUI.
09:40 permalink

10/16/2002 Wednesday

Back in the olden days, if you worked with the internet, you were a Webmaster. And you were expected to know and do everything related to web projects - information architecture, system analysis, content writing, design, multimedia, frontend coding, backend coding, database administration, legacy integration, content management, maintenance, etc. But that was ok: clientside technology was so primitive that there wasn't much to know, design sucked so you could get away with almost anything, Perl was the only backend language you needed to know, no-one considered putting web interfaces on legacy systems so you didn't need to worry about that, web projects were simple so they didn't need lots of architecting, MySQL could do anything you needed, and multimedia meant RealAudio (Flash didn't exist and Director resulted in huge files and was for CDs). The web advanced very quickly and people began to specialize. For instance, I was once a Webmaster but now I'm a Clientside Developer - I specialize in HTML, CSS, Javascript, and related technologies. I know some Photoshop but couldn't design my way out of a paper bag. I find information architecture interesting and read some IA sites but I am not an expert. I don't have a degree in CompSci so don't know how to do formal system analysis. I know a bit of Perl, PHP, and Java but I wouldn't call myself a backend developer. So what I don't understand are job ads looking for Web Designers who are required to know everything from information architecture to DHTML to SQL and have 3-5 years experience. The days of the Webmaster job description are over. The Web Renaissance Man/Woman is a difficult species to find now (and certainly can't be had for 35K/year). (this rant brought you by this job description)
09:10 permalink