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.
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 ruthsarian@gmail.com. A big thanks to djmaniak777 for tossing me the invite. Thanks!
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.
Cheers!
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?
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.
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.
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.
A year ago I despised blogs. Now I help run a local blog server and am into it up to my neck. WTF?
Due to MT’s need to go 100% commercial, I’ve started looking at alternative blog software. To that end I’ve set up a demo of WordPress here. Lots of upsides, such as being released under GPL. Presently one major downside is the lack of support for multiple blogs within 1 blog instance. Meaning that if I want more than one blog on a box I need to install separate copies of the WordPress software. Perhaps not a really big deal. I could certainly look into writing a script to automate the process at least somewhat.
Maybe edit wp-config.php so that the table name prefix is derrived by the current directory name, rather than having to hard-code that value in. Then, at the very most, an install would be a copy function and that’s it.
Keeping in theme, I’ve got a list of Blogger templates put together by djmaniak777. For anyone with a blogger.com account, you can make use of these templates for your blog.
Now that the basic CSS is down for 2 and 3 column layouts, it’s probably time to try and focus on style rather than CSS. Kind of like my own css Zen Garden.
Just patched up the kernel from a newly discovered bug in many Linux kernels. I then set about running the demo code to see if the server would lock up, but the patch appears to have covered the problem.
It’s interesting to read of the different approaches to patch this bug. Some cater to the bug explicitly while others decide to drop anything that gets to a certain point in the execution of the kernel. Lots of using a shovel to perform delicate surgery types of approaches. But what’s in there right now works, and I can wait the week it will take for an official patch to be finalized.
Another, less critical, patch I had to take care of this morning was a 1px gap bug that A. Scott McCallum e-mailed me about over the weekend. My eyes or my monitor, or a combination of the two, kept me from noticing this until Scott came across it while trying to convert the layout to a left-side main column, right-side navigation column.
The fix was simple enough. The layout had margins set on a couple elements that were expecting a 3 column layout. Dropping the margin by 1px fixed it.
The code in question was in base.css
#innerColumnContainer, #contentColumn
{
margin: 0 -1px;
width: 100%;
}
Originaly that marginw as set to 0 -2px. Changing it to 0 -1px fixes the 1px gap problem with the Skidoo : 2 column layout.
Thanks for pointing that one out Scott!
While doing a little maintenance on this server I noticed the access log was 28 mb in size. This thing has been up only about a month and has virtually nothing on it. There’s no reason we should have that big a log.
So I did some poking around and found that 25 megs were entirely webdav exploit attempts. I wish the kiddies would at least have the decency to check the HTTP headers and see this isn’t an IIS box before chucking that much crap this way.
So I’ve updated the Apache config to trim the log entries for any request which includes “\x90” in the request by not including the actual request in the log entry. This isn’t the cleanest solution, but it works and I’m less concerned about what gets logged than I am the potential for the logs to explode in size if left unchecked. (Yes, that’s a very poor approach to security. Do as I say, not as I do.)
The whole experience got me thinking about what else might be in the access log thus far. Here’s some quick results that you might find interesting. Keeping in mind this server has been online and googlefied only about a month.
weblog$grep -c -i "\.exe" access_log 1377 weblog$grep -c -i "\.dll" access_log 8 weblog$grep -c -i "\default.ida" access_log 665 weblog$grep -c -i "\\x90" access_log 796 weblog$grep -c -i "cmd.exe" access_log 1189 weblog$grep -c -i "root.exe" access_log 188 weblog$grep -c -i "/scripts/" access_log 851 weblog$grep -c -i "bot" access_log 307
Always curious to see who (or what) is hitting this box.
The Forgettable Mister Ruthsarian 
