dot dot dot

So how is it that this paragraph has a 1px dotted border under Moz but IE doesn’t do the dotted border? Instead IE users see a dashed border.

But when I increase the border size to 2 pixels, IE suddenly finds its way in created a dotted border? Awfully silly.

But that’s how things are I guess.

Imagine That

The background images demo has been updated to work with IE5/Mac and a fix was added for IE5.0.

IE5/Mac wasn’t showing the background images because I was using single quotes to encapsulate the URL strings in the bgImages stylesheet. Changing to double-quotes got IE5/Mac working like a charm.

IE5.0 wasn’t displayin the background image of the center column. In actuality, it was. The problem was that the #contentColumn block had a background color set in the v4 stylesheet. Setting this to transparent in the bgImages stylesheet fixed the problem and IE5.0/Win works like a charm.

As an aside, the misc. demos available on the skidoo layout site (with the exception of the headings demo) do not work under NN4 (and probably IE4). I will probably take a closer look at this sometime this week.

Last but not least, I now have a Gmail account. Thus my new e-mail address, and point of contact, is A big thanks to djmaniak777 for tossing me the invite. Thanks!

Marginally Working

Gunther brought up the idea of using the side columns as an area to place marginal notes. He gave me a link to this page as an example.

Okay. Seemed easy enough. Hah! Not at all. I’ve already written at length about the problems I’ve encountered within the layout itself. So go check out the layout and see for yourself.

Another option Gunther brought up was using background images for the side columns. That one was much easier to do, and I went a bit further than adding background images to just the side columns. But, in the end, I think the background images demo will be helpful to people using the layout.


EM and EMs

Gunther P., who got me going on the NN4/IE4 3-column support on skidoo, has brought up an interesting point that I wanted to toss out for your consumption.

The left and right columns in the skidoo layout have their widths defined in pixels. Gunther suggests defining them in EMs. That way, as the user alters the base font size, the columns would increase (or decrease) in width as well. (1em = the width of the letter ‘m’ of the currect character set… this ties anything sized in ems to the base font size of the layout.)

I can see some big pluses with this, most notably being on users on hand-held devices which have a very small base-font size. A 200px wide box might be the width of the entire screen on a PDA. If set at, say, 16em, then perhaps that box takes up only a small portion of the screen size, and the layout scales better.

This approach also solves the IE issue brought up by another person in which long words in the left-hand column can cause layout breaks in IE if the base font size is set to larger or largest.

The only downside I can see right now is that users who have a large base font size, and are using a small screen resolution (think 640×480 or even 320×200) may wind up in a position where the left-hand column is wider than the width of the screen. In a different layout this would be fine because the content column would just wrap below the left-hand nav area. With skidoo you have the area for the left-hand column space reserved via a border (or margin) that spans the full height of the content columns. The result is that the main (and right hand) columns would appear offscreen. The user would either have to horizontally scroll to see the content, or the content may be completely unavailable.

I dunno. There are so many extremes one can find to break any layout. At what point do you allow yourself to ignore them?

Source Order

This is a side-topic that’s come up with the recent updates to the skidoo layout. To achieve NN4/IE4 compatibility, I’ve had to move the right-column to appear second in the source (after the first column, before the third column).

Source ordering of columns is a topic that doesn’t seem to get covered a lot, but perhaps it’s something that should be more closely looked at.

Why should we even care about source ordering? The only people this will affect are text-based browsers, old browsers, and browsers that can’t handle CSS (primarily PDAs and other small-screen devices). There’s also another group of users that this is important to, screen readers, primarily used by those who have poor sight or are blind.

Those users make up maybe 1-3% of your user base, leaning more torwards the low end of that scale. So is such a small user base worth supporting? That is a topic for another discussion. For now let’s move forward with the thinking that, yes, we need to support these users (or at least make the effort).

So we need to look at source ordering.

Is it desirable to have the content appear first (among the 3 columns… masthead and hnav blocks will still appear before this content)?

I don’t know. That’s your decision. When I look at the way I would use the left and right columns, I see them acting, primarily, as navigational elements. In that case, I think they should appear before the main column.

Take the scenario: a user visits the homepage, looking to get to a sub-section of your website. Do you want to force them to page down through the content of your homepage just to get to the navigational elements that get them into the sub-sections? Or, do you provide that first, and keep the user from having to page through all that content?

But what about on those lower-level pages? The user is after content, not the navigational elements. So do you use an entirely separate HTML structure for those sub-pages? That seems a bit much. It’d require maintaining a completely separate set of stylesheets and layout template.

Instead, we could add an extra link to that hnav section, a link that lets users skip the navigational content and go straight to the content of the page. That link would be hidden from CSS-based browsers (by setting display:none). This gives users an option to jump straight to the content while still allowing the user to access the navigational content without having to scroll through the content.

(Conversely, you could add an element that jumps past the content to the navigational stuff… maybe that’s a personal preference, but I like it set up the way it currently is.)

So. What if you don’t use those columns for navigation? That third column is especially enticing to be used for something other than navigation, such as an index of articles on a blog. Maybe you add a skip link in hnav to jump to the third column’s content and at the top of the third column, a skip link to the content.

But in your implementation, in your content structure, it may not make logical sense to have that third column content come before the first column.

Well with skidoo you can do this, you can edit the HTML to move the third column to appear after the content. The only problem will be NN4 and IE4 support breaks. So you’d have to remove the v4.css link and NN4/IE4 users get a flat/plain text version of the document.

But what about getting that left-column to appear after the content? If you find a need to do this… hah, you’re on your own. I haven’t worked that out yet. Maybe I should.

bleh. i’m losing my train of thought. i’ve tried writing this post 3 or 4 times over the past week. this is probably the best i’ll get for now.

I’m really inrested in what you think. Who cares about source ordering, and what do you think? Should that content column come first? Is there a market or need for that? Please feel free to post your thoughts.

New for Skidoo

Made some big updates to the skidoo layout. NN4 and IE4 now display the layout in 3-columns. NN4 seems to hang if you stop browsing the layout for more than a couple minutes. I don’t get it. To remove version 4 browser support, just remove the LINK to v4.css and you’re all set. From that point on version 4 users will see the plain/flat text page.

I also added (finally) a print.css to handle formatting of the page when it’s printed. Really simple, it just removes the side columns and hnav, printing out the masthead and main column content in black text on a white background. Styling things to your own liking should be easy enough to do.

There’s more info about the updates in the change log.

What's New w/Skidoo

Did a bit of an update to the skidoo layout. I was getting tired of updating two sets of CSS when I had to update something for the skidoo layout. And to convert the 3 column layout to a 2 column layout takes all of 2 or 3 lines of CSS. So I moved everything into the same folder so both the 2 and 3 column layouts pull their CSS from the same source. And I added a couple new stylesheets to show how it can be done.

I’ve also added in a lot of new demos. I plan to keep adding to the demo list with different color themes and some other bits as time moves on.

Right now I’ve got a problem with the layout in IE. It seems that if you shrink the width of the window too much, the right-hand column gets kicked below the content column. I want to do some tests to see if I can find a fix for that. If anyone has any suggestions, I’d love to hear from you.

On the server side of things I’ve started playing with snort. I’ve got a database setup that receives alerts from snort and then acid parses the logs and generates some stats and graphs that I can use to easily monitor traffic hitting our network.

Well, at least port 80 traffic. This server is behind a couple firewalls and I don’t have any remote sensors outside of the firewall. So it’s pretty much just port 80 traffic that I see. But it’s always good to see just what kind of attacks are hitting our web servers. It’s nothing big, mostly old-school unicode exploits with a dash of other misc. IIS exploits thrown in. It’s still interesting stuff.