404 Script

I updated the 404 script so that the entries in the 404Redirect.txt file can now include an entry to indicate a permanent redirect (301) rather than the temporary redirect used by ASP when you issue a Response.Redirect (302). The update will go public tonight, tomorrow I'll spend some time getting rid of some of the legacy directories on the site.

Home page redesign

I've completed the design work for the new home page. Most of the modifications requested after the first version were minor and so I was able to spend a little time fleshing out the structure that will be used. I'd like to structure the content as simply as possible, using JS and CSS to implement the advanced functionality. I've already got some ideas about what areas should be dynamically generated. The only part that's giving me a little trouble is the two-column link list ("Quick Links"), so I'll need to spend a bit more time on that.

We're meeting tomorrow to go over the design and make our final decisions. Hopefully I can have the new page up in a couple of weeks.

Testing Adobe Illustrator's SVG Output

FM asked me to take a look at creating SVG documents from Adobe Illustrator so that we could determine what needs to be done to make the documents structurally coherent. Here's a brief summary of the information I've gleaned from minor testing (using Illustrator 11.0.0).

• The SVG width and height are defined by the elements contained in the Illustrator document, not the page layout, using a coordinate system similar to the SVG coordinate system.
• Every element that is explicitly named is given an id attribute matching that name. Spaces are converted to underscores. Non-alphanumeric characters are converted to hex-encoded values of the form "_x5F_" (an underscore). Duplicate element names are modified by adding "_#_" where # is a number starting at zero.
  
• Each layer and group is surrounded by a g tag.
• The elements are created bottom-to-top if looking at the Layers palette.
  
• Using the rectangle tool will produce a rect element in the SVG. Fill and stroke on a rectangle are defined on the rect element.
  
• Using the rounded rectangle tool or stylizing a rectangle with rounded corners will produce a path element in the SVG. Fill and stroke on a path are defined on the path element.
  
• Text is rendered as a text element transformed from 0,0 with multiple positioned tspan elements. The tspans appear to be created based on kerning and spacing rather than line wraps.
• Text created using the Type Tool is rendered as an individual object.
• Text created using the Area Type Tool is rendered as a group which contains the object defining the area and the text itself. If the area text is named in Illustrator the SVG group, object, and text are all given the same id.
• Using the Line Segment tool creates a line element in the SVG. Applying a filter style to create an arrowhead creates a group with the original line and a path defining the arrowhead, this renders to SVG as expected. Applying an effect style to a create an arrowhead redraws the line as a path, but when rendered to SVG the line is created as a group containing another group, containing the original line and a path defining the arrowhead.
  

Note: In Illustrator filters and effects affect the object on which they're used differently. Generally filters are non-editable, effects are editable.

Workshop E-mail Reminder

The workshop reminder was sent out Friday, 26 August 2005 at 2:34:16 PM to 2395 recipients.

Scripting: show/hide content script update

I've made some major changes to the show/hide content script. I've been trying to write or rewrite much of the client-side code we use with the ideals of progressive enhancement in mind. The show/hide code pretty much went the opposite direction when I created it, but now I think it's more aligned with the goals of PE. Read on for a quick summary of the changes.

Simpler implementation

I was able to change the implementation process so that only three steps are required:

• Create the show/hide content inside an element or surround the desired content with a div or span. Place an anchor inside the element and give it a class of shContent.
• Attach the script file.
• Attach the default stylesheet. Made any additional style declarations as desired.
  

A complex system of divs and classes is no longer needed to indicate what text is part of the show/hide routine. The script now looks for the anchor and then performs all actions on the container tag. Not only does this simplify implementation, but it also fixes some of the problems I noted in a previous post regarding structure vs. compatibility.

Updated anchor linking

Links coming into a page can now use the show/hide content anchor rather than having to create an extra anchor on the show/hide action link. The script will then determine where the action link is, activate it, then scroll to that position.

The exception being browsers that don't run the code (such as Nav4). These browsers lands at the show/hide content rather than the action link. This is not the preferred action but I think it's acceptable. I'll continue to investigate to see if I can get it to land on the action link.

I also added a "scroll to" action to the script for non-show/hide anchors accessed when first entering a page. This addition was necessary because Firefox jumps to an anchor prior to running the script, causing the page to shift after the final scroll position has been set. This is a problem since the page can shift significantly when more than a few show/hide sections are present on the page.

Bug fixes

Links to other pages with the an anchor matching that of a show/hide content anchor on the current page was broken with the current update. This bug was caused by the removal of the shLink class, which was previously used to determine the action link. I now have the script check the page each link points to in order to determine if a link is supposed to affect the show/hide content display.

CCMS web site logging

A few weeks ago MK asked if we could generate some usage statistics for the CCMS web site. At the time I was unable to find any historical usage logs. After a lot of research and examination of configuration files I had things set up so that the logs were rotated. I checked in on the log files today to discover that there were only a week's worth of logs available. Since there were some logs available, but not the amount that I had expected, I figured something was removing old log files. I did some more investigation, looking mainly at the cron tab. As it turns out the daily cron job was deleting any log file older than seven days. I commented out the offending line and will check tomorrow to make sure everything is working as expected.

IE CSS bug: margins

I was working on the CCMS web site stylesheet to update it with some things I've learned over the past six months, and to make the pages more friendly to Macromedia Contribute, when I ran across an IE bug. If you have an object on a page that's positioned absolute followed by a block-level object the latter object's top margin will not be calculated properly. Actually, it won't be calculated at all ... it's set to zero. Explicit definition of the margin in the stylesheet for the latter object does not solve the problem.

I found a reference to this bug on the Channel9 Wiki page Internet Explorer Support for CSS (look for the bullet "Incorrect Margin Calculations"). No work-arounds are provided.

See the demo code
Tested: IE 6 on Windows XP SP2 (6.0.2900.2180.xpsp_sp2_gdr.050301-1519)

The only work-around I've found so far is to place positioned objects at the bottom of the page. I'll need to analyze the content to determine if this is an appropriate solution, though, since I've been trying to keep the CCMS site more aligned to the web ideal for design (semantic rather than visual). It's possible to get the desired spacing using padding instead of a margin on the affected object, but if we were ever to make modifications to the design that involved background colors or images we'd run into problems.


Update 2005-08-18:
I decided to use a float on the menu to get around the problems I was encountering. This led to another problem, but this time with Firefox. The navigational menu was being positioned further down on the screen than I expected. Turns out I was running into my old friend the margin-collapse rules. Since the first element on the page was set to display: none and the second element set to float: left, it appears the third element was actually interpreted as the first in the flow of the document.

According to the W3C spec:

Two or more adjoining vertical margins of block boxes in the normal flow collapse. The resulting margin width is the maximum of the adjoining margin widths.

The "body" box and the "content" box come under this rule. Since the content box has a 150px top margin, it was collapsing with the body to have a shared 150px margin. Thus, when the top margin was determined for the navigational menu it was based on the assumption of a 150px margin on the body.

See the demo code
Tested: Firefox 1.0.6 on Windows XP SP2
Browser String: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

To work around the problem I gave the body a 1px padding.


Update 2005-08-24:
I've completed the updates to the CCMS stylesheets. I had to scratch some visual updates for Nav4 when I realized they made the site's pages unprintable. In the end, Nav4 continues to use the same bare-bones style as in the previous iteration.

Additionally, I had to scrap any efforts to make the CSS more Contribute-friendly. After extensive testing I've come to the conclusion that Contribute's CSS support in editing mode is almost non-existent. I've recommended an update to Contribute 3, which appears to be much improved in this repect.

2061 Connections mailing

The July/August 2005 issue of 2061 Connections was sent out Tuesday 9 August, 2005, at 2:21 PM EST to 3878 recipients regular subscribers plus an additional 50 for the KSI participants.

Form reset

FM was curious as to why a form would sometimes reset when you left a page and then used the "back" button to return to it. I've noticed this before and assumed it had something to do with cache control headers. I was right. I did a test using both server-generated headers and browser-simulated headers (meta http-equiv). The results:

Server-generated headers:
Two of the response headers had no effect on the form data: Expires and Pragma. The Cache-Control header, however, did have the effect being tested for when the value was no-store. Additionally, IE also shows this effect when the Cache-Control header has a value of no-cache, though no effect was seen in Firefox.

Browser-simulated headers:
The three meta http-equiv tags of interest (expires, pragma no-cache, cache-control no-cache) do not appear to cause the browser to reset a form on returning to a page using the browser history (back/forward). Note: I tried the full complement of options for cache-control with the same result.

Further testing would need to be done to see what the effect is on other browsers (Opera and Safari being of most interest).

During testing I also found that the browsers treat a hard reload ([Shift]+Reload) differently. IE will always completely reload a page and it's headers. Firefox, on the other hand, will reload the page but not update the headers until the browser is closed.

Link Checking

I told MK I would check all the links on the PSL Web site so I could provide a list of those that were broken. I didn't have an application at hand to do the work, but, luckily, finding a link checker is pretty easy these days. I ended up using the first one I found and I like it. It's fast, and provides a streamlined interface (enter the starting URL and receive a spreadsheet-style output of the results).

Speaking of link-checking ... I have a Firefox extension that'll do it for an individual page. Fairly handy, but I'd been having problems with it not working on our web site. The extension uses the HEAD request verb to determine whether a page is present or not (speeds up the check by not having to download all the data). For some reason every SSI page (that would be every HTML page) on the site would return a 403 error. Turns out that the SSI ISAPI plug-in for IIS by default doesn't allow the HEAD verb. I added it to the list of allowed verbs.

There's no reason that I know to disallow that verb, and it can actually affect the performance of spiders, caches, and browsers. I don't pay much attention to performance with our site since we don't get enough traffic to stress the server, but it's be interesting to see if that has any affect.