The Forgettable Mister Ruthsarian

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 ruthsarian@gmail.com. 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.

Cheers!

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 640x480 or even 320x200) 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.

Blogged Down

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.

Patching Things Up

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!

Tangled Web

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.

2/3 Skidoo

Both 2 and 3 column versions of the new skidoo layout are now available.

I've made a minor addition to the CSS on both just now to include a quick fix for the IE italics bug which decided it wanted to still exist.

I tested both 2 and 3 column layouts on Opera 6.03 for Mac and they appear to render fine. I would assume Opera 6 on the PC would render fine as well. The fonts may be a big bigger than other browsers, but perhaps that isn't a big deal.

I also tested the layouts on IE 4 and NS 4. They both display the layouts in a flat file format. All CSS being hidden from these version 4 browsers. I thought that this is the best way to go, at least for now. Perhaps when I get bored I'll spend some time developing a separate CSS to at least get the 2 column working under NS4.

The blog, here, you can see has a new look. I'm just mucking around with it. The effect on the masthead in this column took more effort than it should. I'm already certain I could have done it differently and achieved a more compatible take. But for now it renders as intended in IE6/Win, Opera, Safari, IE5.2/Mac, and Mozilla. IE5/Win get just a standard h1 heading.

Maybe I'll tweak things a bit more as time goes on. For now I just wanted to get away from the stock MT layout.

Oh, and I offer no warranty on all the sub-pages, the archives, etc, as they certainly don't look great because of how the new layout 's CSS is arranged. Again, another for the todo list.

I also added some links in the left-hand column. Some of them I'm sure you've seen before. Others you might not of. Check them out, there's a lot of cool stuff to see.

Cheers!

Looks

Please stand by while I play around with the template for this blog. I haven't tried mucking about with MT templates before so I'm sure to really screw this up.

w00w00

I give you, Skidoo : 3 Columns.

Skidoo is a nonsense name until/unless I come up with something better. I need to name the layouts something better than just "2/3 columns" because there's different variations of each on Ruthsarian Layouts.

This is a complete version of the original test page I added here over the weekend. That test version actually has several bugs in it so don't bother using it.

I'll throw together a 2-column version and put it on the site soon, most likely tomorrow.

djmaniak777 e-mailed me to let me know that he's converted the old 3-column layout for use on blogspot. The older 3 column layout functions great under Netscape 4, whereas the new layout just drops any attempt to keep the layout structure under version 4 browsers. So if you're interested, and have a blogspot account, definately check out djmaniak777's work.

Perhaps I may try to get something working with NS4 for the new approach to the 3 column layout. But a few quickies last night showed it might not be easy and I probably won't get to it for a while, if ever.

This skidoo layout is probably going to get most of my focus for the next few weeks and will certainly become the Ruthsarian layout of choice. However all the current and old layouts will remain up there. At the very least, the early layouts show some different approaches to the same goal and I still think that background color mask approach could be very useful in later, more complex layouts.

Cheers!

Looking Good

The promising layout I mentioned in my previous post is looking good.

I quickly tested it in IE5/Mac, IE5/Win and Safari and it renders exactly as expected under all of them. Opera 7 also has no problems with it.

A quick note to Dave and any other Konq users, I did install Konqueror on my home machine over the weekend and Konqueror seems to render the layout without much problem.

It did bring up a small issue that I may have to target once I get 2 and 3column layouts based off this new design. That problem is fonts. The big problem, at least on the Linux side of things, is that font sizes are very dependent on how the user has setup X. X, the base application used to manage a windowed interface under *nix OSes, has a few different places where a configuration option can have direct influence on how big a 10pt font may render on the user's screen.

What I may end up doing is setting the base font size in pixels within the body selector of the stylesheet and use percentage values throughout the rest of the layout.

I've seen this suggested several times and it seems to work well. Except that IE doesn't resize pixel-sized fonts. This is a problem for users who need assistance in reading a page by increasing the base font size. Moz and Opera don't seem to have any problems resizing a pixel-defined font. It's a real shame because that's the only reason I don't use that approach in every layout I put together.

But perhaps the fix for this is to look at stylesheet switchers and either provide one stylesheet which does not have a base font set in pixels OR provide several stylesheets (or via JavaScript) increase the base font size every time a user clicks a "enlarge font" button.

It's definately a curious problem that I'll probably spend some time focusing on a few weeks from now.

Cheers!

Hmm

This looks promising.

I started out looking through the piefecta layout on PIE which lead me to this layout by Douglas Livingstone.

That layout has all three columns floated from inside a shared block. That shared block (well, a parent of) has side borders with the same width as the left and right columns. Then use negative margins on the side columns and presto, you force them over the borders of the parent block. Those borders act as background colors for the columns.

This is something I had tried about a year back but missed the one crucial step, which is those side columns need to poke by at least 1 pixel into the main column. This allows for an element, inside the same parent block and with its clear attribute set, to clear below all three columns. This forces the parent block, which is responsible for the background column colors, to carry down regardless of which column is taller.

A little pixel manipulation gets borders between all three columns to line up.

Nice.

What's even more nice is the few number of hacks that will be needed to get it to work. I have only tested under Mozilla and IE6 and will try Opera this weekend. IE5 and Mac testing will take place Monday or Tuesday of next week.

This has some really great potential.

NS4 support is probably not going to happen. But the other columns w/background colors layout I'm working on doesn't support NS4 anyways and I feel comfortable with this.

We'll see how this works out next week.

Ah.

The Mozilla fix is in place again. I have to set the position attribute of the bottom color mask to fixed. Doing this causes Mozilla to render the mask without adding to the height of the document. Thus removing the need to scroll the extra space.

Amazingly, this fix works with Safari as well. Nice.

Opera does not like this approach and so I have applied the Owen hack to hide it.

So Mozilla, Safari, and IE5+/Win are rendering the 2col.colors layout exactly as I want. Mozilla being my poison of choice I'm content to leave the layout as is and call it production ready. There are no major defects in the layout. The worst being the 100% tall box that some browsers will get. This does not affect the content or the flow of the document in any way - it's just a nuisance.

But the Safari/Opera bottom padding bug still intrigues me. I would also like to find a hack to get Opera and IE5/Mac working properly.

IE5/Mac almost works with the Mozilla/Safari fix. On documents taller than the viewport, it works perfectly. However on documents shorter than the viewport, the hack is exposed and functions just like Opera's repsonse to the fix.

Perhaps I can find a tweak that fixes both at the same time...

Cleaning up

2col.colors has some new fixes applied to it.

I've gone through the hnav.css file cleaning that up a little bit and focusing hacks on their targeted platform as best I can. A hack for IE6/Win was screwing up the hnav bar in IE5/Win so I had to work some things out to reset/undo the hack in IE5/Win. In doing so I was able to remove a couple other reset hacks for Safari.

I use to use the case-insensitivity of IE5/Win to my advantage when trying to fix IE5/Win without hurting IE6/Win. However, Safari is case insensitive as well. So now I'm using the * html hack which only IE treats as valid. (There is should be no element heigher in the document structure than the html element. But IE seems to think there is.

I have also gone back to using a 100% tall block to cover the area below the footer for short-content pages. This means I had to apply a 100% height to the html and body elements to get Mozilla and Opera 7 working. But this causes problems with IE5/Mac so there's a simple comment hack to block that section of CSS from being applied in IE5/Mac.

I'm now trying to rediscover what the hell I did to get the 100% tall block from not causing extra vertical scrolling under Mozilla. I know it had to do with floating the element, but there must have been something else as well. That'll teach me for not taking more notes!

I still have no idea what I can do to fix the ~1em margin or padding that's appearing at the bottom of the document's column mask layer under Safari (and Opera 7 if you minimize then restore the window). The seem related, but may not be.

This same artifact exists in versions 1 and 2 of this layout. So I can at least be sure it's not related to the content of the page nor a lot of the extra CSS added to accomadate the content. A lot of testing will have to be done to find a solution... if there is one.

That's where things are right now. If I can rediscover the Mozilla fix I may be willing to consider this layout ready for use in the wild. It isn't perfect... but what columned/CSS layout is?

A little less butter, a lot more flavor

The bottom color mask with a height of 100% and a bottom margin of -100% gets IE5+/Win working exactly as I want it to with the 2col.colors layout.

Safari and Opera still exhibit that odd padding funk on the column color mask layer. Not sure what to do there.

Under IE5/Win I'm using the holly hack to get padding to work on the horizontal menu items. However, 1% is started to equal a height bigger than the menu's height and it's creating an unintended visual (d)ef(f)ect.

IE5/Mac picks up on the "hide from everything but IE" hack (using the * html selector) but it doesn't respond to negative margins the way IE/Win does and thus a 100% tall area appears below the content of the page.

In mucking around with Opera/Moz I've set the mask to 10,000 pixels tall. This is because 100% doesn't register since I don't have a 100% height applied to the body element. I'm trying to see if this path leads to a solution, but if not, I can revert back to 100% height on the body element.

And I await the next Uru expansion pack and Myst IV.

Oh, and this blog server had another 1st this past week. Some bot added a spam comment to one of the threads on this blog. So we've done enough to get noticed by the spam kids. Yay.

That's about all for now. Happy June.