Horizontal Lifestyle

Right. Let’s see if I can get this to work right. Fist you’ll need to load up a copy of IE for yourself and visit this page (if you’re not already using it).

Horizontal menus. You’ve seen them in Tank! but they weren’t quite right. So as part of this dropmenu system I’m working on, I’m including support for horizontal menus (to some extent anyways. can’t see why you’d want horizontal menus below the top level).

Compatible menus at that.

This led me on quite a journey these past two days.

First thing to realize is that those horizontal menu items have to float. They have to. Otherwise you can’t pull off a dropdown menu properly across all (or as many as possible) platforms. (Although I suppose display:table-cell might help with that a bit…) But anyways, if I’m floating, I’ll have to clear things at some point. Otherwise content that should appear below the menu will appear either on top of it or to the side of it.

Basic Markup

Here’s what the basic markup looks like:

<ul
  ><li><a href="">Menu Item 1</a></li
  ><li><a href="">Menu Item 1</a></li
  ><li><a href="">Menu Item 1</a></li
  ><li class="clear"></li
></ul>

A bit funny with how the closing tags are. PUrpose is to remove all whitespace between LI elements. Otherwise IE puts whitespace between the elements on screen. That may be desirable for you, but it isn’t for me.

The last LI is a clearing element. The idea here is that all the LI elements float left and the last one clears it all out. This keeps everything neatly contained witin the UL element and requires no wrapping DIV element.

A Cute Idea

Let me start with something I tried late in my experiments. An idea that seems quite cute and I think has some merit if given the right circumstances. I was having problems getting the clearing element to work properly in all browsers. And then I set the width on the UL element to 100% to trigger IE/Win’s hasLayout property. This had a curious side-effect in other browsers. Because the UL element was now 100% the width of the browser, there was no space on either side where text could wrap around (as is the normal procedure for a floating element that is around text). So the text dropped down below the horizontal list.

Now I would have thought that the margin on the P element that immediately followed the list was responsible for that. But even if that were the case, the text should still have started to the right of the right-most menu item. But for some reason it didn’t, even in FireFox, Safari and Opera.

So it may be there’s a case to contain all your floating elements within a block element and set its width to 100% you’ll find things forced down.

I don’t know. I didn’t investigate this completely because I quickly found that it created a horizontal scrollbar in IE/Mac and that was something I didn’t want to deal with. So I abandoned it.

The Art of Clearing

So, you see my HTML up above, yes? And you see that LI element with the class property set to clear. That is a clearing element. It has one purpose, to force itself below all previous floating elements. That way anything following the clearing element will also be below all previously floating elements.

But it’s ugly, from a purist’s standpoint. It’s redundant markup. It provides no meaning and serves no informational purpose.

So for the last few years people have been trying to come up with new and exciting ways to clear without redundant markup.

One of them is quite simple, fairly compatbile, and a joy for CSS developers. That is overflow:auto;. You set that rule to a block element containing floating elements and it’ll trigger the containing block element to size itself to contain it’s floating children. It’s very simple and very nice, especially when compared to the alternative.

But there is a problem with using this in my particular case. I’m creating dropdown menus. Elements are absolutely positioned and hidden, then set to appear when a mouse hovers over a given element. Because it’s absolutely positioned it’s removed from the flow of the document. This means it’s parent element has no clue nor any care how big it is or where it is located on screen. So when I apply overflow: auto; to my UL element … it works! That is until you mouse over an element that has a dropdown menu attached to it. Then the fun begins. You get scrollbars! Scrollbars for your UL element. Those dropdownmenus? They’re there.. but you can’t really see them unless you move the scroll bars. But if you move the scrollbars you take your mouse off the element containing the dropdown and so it disappears.

Not very usable.

Although it is a very fun way to annoy people.

So that’s out.

Tried and Trued

So that clearing element then. .clear { float:none; clear:left; } should do the trick and we’re on our way, right.

No. If it were, I’d have published the menu system by now and I wouldn’t be bothering you with this long and rather dull (unless you’re a CSS junkie… I’m sorry)

Here’s the thing. Netscape 7 and early editions of FireFox had this bug where they wouldn’t recognize an element that had no content. So an empty LI like in the example way up top wouldn’t clear. The way I get around this is by applying 1px of padding to the bottom of the element. Now Netscape 7 comes ’round and all is well. Throw in a -1px top margin to compensate for the 1px of space you’ve added to the layout with the padding and nobody is the wiser about our Netscape 7 clear hack.

That is.. unless you want to apply a border or in any other way utilize the parent UL element for visual styling. For example a border. Something like what you see just beneath the masthead in skidoo. That was done using a DIV containing the UL element, so all this 1px nonsense wouldn’t really matter.

With this 1px bit you’re adding 1px worth of space below your menu items. So the border on the bottom of the UL element is going to show to your users a 1px gap between it and the menu items.

And try as I might, use every trick in the book, I can’t hide that nasty little 1px reminder of my ugly, coarse Netscape 7 hack.

Getting Stingy With HTML

Oh sure, wrap it in a DIV, solve all our problems. But I’d rather not. The name of the game, folks, is thin markup. Don’t do more than is absolutely necessary. One of the nice, shiny promises that was touted when CSS was coming into mainstream was that webpages would no longer suffer from messy markup. All the redundant nonsense we adopted during the table-hazed 90s would be gone. A window in a smoky house opened by our friend, Mr. CSS.

(Sorry. Practicing for that theoretical book and all.)

But that was all rubbish.

With IE 5 and Nescape 6 we started going DIV crazy. Why wrap it in 1 DIV when you can wrap it in 4 and put a round corner image in the background of each?!

Welcome the new style, same as the old style.

I’m as much guilty as the next man or woman. Still am, really. Hard habit to kick.

But I’m trying. And with all future work I’d like to be a bit more tight and thin with my markup. So just wrapping this up in a DIV just won’t do. I’ve got a perfectly good block element in that UL element. I don’t need a DIV. I just need to figure out how to use it.

And so…

Here’s the result.

I’m having PIE.

The :after pseudoclass has proven to be very reliable in all modern browsers (save IE). And where IE fails I can easily compensate by triggering the UL element to have layout.

For horizontal menus I can do it many ways, be it floating the UL itself (in which case I will need a clearing element, thus redundant markup) or I set the width to 100%. But IE/Mac hates 100% width! Yep, so I use a backslash hack to apply display: inline-block and that gets IE/Mac all warm and fuzzy.

Vertical menus already have a set width (be it static like 6ems or dynamic like 100%, so I don’t really need to worry here) so they already have hasLayout triggered.

So then, how are those menus coming?

Pretty well. I think I’m close. I’ve got them working in every major platform. I’ve even got IE/Mac 5.0 working. I think most of the big issues are just about ironed out. It’s the little things now that I’m on.

For example, it seems that you need to list your classes (if you assign multiple classes to one element) in order of precedence. Otherwise IE/Mac gets a bit confused.

Also I still have some minor rendering bug in IE. It draws the borders on the UL element of the dropdown menus when the menu shouldn’t be on screen at all. It only does this after I’ve viewed that menu at least once and will go away if that menu isn’t showing before I leave focus of the parent menu. It’s quite odd and could be resolved by simply not drawing borders on the parent UL at all. But then I have to use negative margins on the LI elements to overlap borders and things can get a bit muddy there… well you start to see what I mean. The little details.

I also want to add some additional functionality that lets you set where and how menus pop and drop based on the class you assign. So a right aligned horizontal menu might have dropdown menus that drop to the left, not the right, of the menu item; like what you see in Tank!.

But things look good.

I wanted to include a bit about a really odd behavior in IE I found but I’ll save that for a later post.

IE7 CSS Fixes Not All Bad

In case you weren’t aware of it already, in IE 7 the * html hack to target CSS to only IE browsers no longer works. This means any rules assigned to a selector that begins with * html will not be applied by IE7.

This is going to annoy a lot of people (such as myself) who rely on these hacks.

However I found a positive experience that comes from this change I thought I’d share.

I’m working on a new CSS-based dropdown menu system (as you know by now). And to get IE6 and earlier working with this system I had to employ the suckerfish method. This is because IE6 and earlier do not support the :hover pseudoclass. Well IE7 does support the :hover pseudoclass and running the suckerfish script under IE7 starts to make things goofy. So as a result, I had to update the script to not execute under IE7 and later.

But here’s the thing.

All the CSS applied to sfhover class is defined using the * html hack. This means, in actuality, I don’t have to go and modify the suckerfish code at all. I can let it continue to execute under IE7 and nothing bad happens. The only drawback is that you add needless overhead to processes the mouseover and mouseout events in IE7.

Now some of you might start to think “ah hah! maybe we can use the sfhover class for something else in IE7. since we’re running it anyway for IE6.” But no, you’d be wrong.

Why?

Because the goal is to get as far away from javascript as possible. We simply have no choice with IE6 and earlier. We have to work around the browser’s limitations.

The potential is there that if a bug does crop up in the final release of IE7 that requires us to utilize the opportunity, so be it. But it isn’t something we should bother taking advantage of unless absolutely necessary. Otherwise we’re just locking ourselves into javascript for the foreseeable future.

IE7 Hack?

While working on the new dropdown menu system I’ve come across something interesting.

I need to float LI elements but doing so triggers rendering bugs in Opera. So I set about finding a CSS hack to hide CSS from IE7. Of course IE7 has a lot of its parsing bugs fixed.

But then I found this one:

ul.menu[class] li

And here’s the thing. In previous versions of IE it would ignore the selector completely. In IE7 it appears to ignore everything after [class] meaning the CSS is applied to ul.menu and not ul.menu li.

Of course IE7 is still beta and this parsing bug might be fixed sooner than later. Thing is.. this hack actually works well for what I’m doing (unsetting the float property which isn’t set to begin with on the ul.menu element, meaning unsetting it with float: none; doesn’t do anything for IE.

Dropdowns And Floats

But first, what if I put together a forums system for Ruthsarian-related stuffs? It’s something that’s been on the back burner for a while but I got an e-mail suggesting it and that got me thinking a bit more about it. Any interest there?

I intend to get the latest copy of WordPress installed on this server and give it another go. If all goes well, I’ll probalby move to that platform and ditch MT.

Now…

Dropdowns

It looks like the secret to CSS-based dropdown menus is to float everything. There are a lot of rendering bugs in IE that only go away when I start to float things. Rendering bugs that have existed since IE 5.0 are still there in IE 7. IE 7, however, now implements the :hover pseudoclass, meaning there’s a light at the end of the tunnel. There will be a day when JavaScript will not be needed to create dropdown menus that can be used by the majority of the web user base.

But IE7 still has problems. There are new bugs with the old dropdown system I used (as seen in Tank!). IE7 doesn’t like it at all. This is why it’s taking so long to get a new system put together. I’m trying to get something that works with IE7 and previous versions of IE. Opera and FireFox and Safari have no problems with the basic stuff I’ve done in the past. It’s really just IE that’s causing problems. Problems that, it seems, can be solved by using floats.

Floats

Here’s the deal. All the lists that pop-up are absolutely positioned. This means I don’t really have to bother with any sort of clearing element at the end of the item list that pops up. This is nice. It means I don’t have to worry about getting into the business of clearing.

What’s the problem with clearing?

Well, the purists believe that web pages should not contain extra markup that provides no meaning to the document. So an empty DIV being used to clear things out is considered bad form. Still, I use this method quite a lot and it appears to be the solution recommended by the w3.

W3 be damned, the purists want to be rid of that extra markup. I tend to agree too, even if I don’t practice what I preach. As a result, there have been severalh different methods developed to clear floats without the use of extra markup.

But those methods are either very specific to the application (for example, the overflow:auto clips the menus that pop to show only that bit which appears in the root menu.. ick) or are very hacky and will break in IE7 anyways (such as the P.I.E. method).

But guess what? The tried and true W3 supported method still works. Which is why, for now, this is the way I think all web developers will want to go. It’s the most compatible and the least likely to break in future/obscure browser platforms.

Now you can be clever and do this without extra markup. If you have an element that will follow your menu, an element you know will always be there, you can apply a clear:both; to that element. But this really isn’t possible in something like a skidoo layout where a clear is used to get the #outerColumnContainer element to hold all 3 columns (thus allowing for the borders on that element to carry the full height of the page and minic side-colum background colors). In that instance an empty, clearing element must be put to use. But the overflow:auto; clearing hack might apply there (I haven’t tried it yet, and won’t use it on any existing layouts, but only future layouts where applicable).

The point I want to make to you is that you shouldn’t be afraid to use an empty element to clear things out. It requires no hacks, is w3 approved, and is the most compatible solution out there.

In a world where us web developers have to balance compatibility with proper page design, this is probably the best solution.

So You’ve Got Something?

No. Not yet. I am working on my new menu system but I don’t have anything to offer up yet. Just passing along notes on my experience thus far.

A Book?

I’m going to write a book. A web design book. Or at least that’s the plan. I don’t have any book deal, I’m not pursuing one either. I’m looking to do a proper, self-published book. A friend passed along a magazine article that gave instructions on how to get a book published and up on Amazon.com for under a thousand bucks. Plus I’ve always wanted my own ISBN number.

The math works out that if you can seel about 100 or so copies of the book, the thing pays for itself and everything after is cake. But I’m less about the money and more about the experience. Besides, it seems everyone with a copy of FrontPage is publishing web design books these days. I might as well add more clutter to that field.

But I plan on doing it differently in that it will contain about half design philosophy and half actual examples. It won’t be a CSS book. It will be a web design book. The philosophy half will essentially be an rehash of what I wrote in my Web of Information series (read that from bottom-top… blogs aren’t made for this kind of writing).

The hope is that the philosophy half of the book will still be relevant 10 years from now, whereas the examples half will probably be irrelevant at that point.

But this is just in the “oh, what a nifty idea” stage. And I’m joining the mass of about 4 billion people out there who have that nifty idea. The trick is to actually do it. We’ll see.

Grailings

By way of another article I poked my head around the One True Layout article. I’ve seen a lot more references to this one article over this past weekend so I wanted to give this a second, more thorough read. The equal height bit especially.

The way the equal height trick works is that each column or block is wrapped with a container that has overflow:hidden; set. Then the block has some incredibly huge value of bottom padding. Negative bottom margins then remove that padding from the flow of the document so that the tallest column doesn’t create a 30,000px tall document. The result is that each column appears to be equal height. In reality the three columns have different heights, but they’re very very tall and are being clipped to give the appearence of being equal height.

This has one immediate advantage that is going to eventually coax me to actually use this hack. It makes adding gutterspace between elements relatively simple. I’ve tried this using the skidoo approach to this in the nausicaa layout but the markup and CSS hackery was just a bit much for me to consider releasing a “production quality” version of the layout.

Relatively

Relative positioning and negative margins together are becoming the key techniques in the “latest, hot” CSS-based layouts that are out there (the previously mentioned articles being no exception). This approach removes the need for some extra bits of markup that were otherwise utilized to generate source-ordered layouts.

The support across browsing platforms appears to be pretty good too.

Let’s say you’ve got 3 columns and you want the middle column first in your source. You float all 3 columns left. Then add some space to the left of your middle column, either via margins or by shifting the element right X number of units via the left rule in relative positioning. Then take what is to be your left column and move it over the now open area to the left of the middle column via either negative margins or relative positioning.

It seems to work pretty well.

Something Interesting

So I took this method to the minimalist markup ideology and came up with something that might be interesting. It’s quite compatible too. I threw in a couple hacks to get NN4 working with it (yes.. Netscape 4) but IE 5 seems to be pulling the left column just a little too far to the left. Not sure why.

And adding gutterspace inside each column won’t happen unless you introduce extra markup (wrap the content of each column with another DIV and apply padding to that). You could play a bit a trickery and set the side columns to 19% width instead of 20% and compensate all the negative margins and relative positioning values appropriately to get some gutterspace.

This example is only using percent values to specify widths. This is because it’s the only way to get very compatible with the different browsing platforms out there.

The approach is promising. But right now most of what’s out there requires a lot of hacks and breaks under IE 5 and other (somewhat modern) browsers. So the compatibility isn’t there… yet.

IE 7 Phishing Filter

Just an update to a previous post. Sam Spade commented that IE 7′s phishing filter doesn’t sent the full content of the URL, as outlined in this article over at Microsoft.

An important thing to note about the Phishing Filter check is that the information sent to Microsoft is limited to just the web address of the web site. Information associated with the web site address that could contain personal or sensitive information such as search terms you may have entered is removed before the address information is sent to Microsoft.

Another important point to remember is that the URL is transmitted using SSL (Secure Socket Layer) encryption. This is the same encryption used by banks, financial institutions and other organizations to protect their users’ data.

I wanted to test this myself so I setup a packet capturing application and submitted this blog using a URL that contained extra bits of potentially important, private information at the end of the URL.

But as is stated in the quote above, the entire transaction takes place over SSL. So all I could see was my machine talking with 64.54.225.125 which is one of many IPs owned by Microsoft.

If I could decipher the transaction I suspect that what I would see is a url like:

http://username:pass@weblog.bridgew.edu/ruthsarian/index.html?secret=password&ssn=personal

is submitted to Microsoft as:

http://weblog.bridgew.edu/ruthsarian/index.html

but I can’t be certain. Is this a problem? In most cases, probably not. What might worry me is that if the full URL (sans CGI query string and username/password) might still contain information. For example, how does Microsoft know where the URL ends and the query string begins? Usually you can go by the question mark (?) if there is one. But there’s also the ability to use forward slashes to separate URL and query string. So something like:

http://weblog.bridgew.edu/ruthsarian/post/username/password/id/ might be itnerpreted as a full URL and not a URL up to the “ruthsarian” part where everything after that is the query string.

And it wouldn’t be an intentional bug on MS’s part, it’s just that some web applications intentionally try to obfuscate the query string from the path to the requested page. But it’s over SSL, so only you and Microsoft would know what got through, if anything.

Still, I’ll be keeping my phishing filter off.

Negative Margins On ALA – 2

Having taken the night to hash over in my head the “holy grail” ALA article I’ve decided I missed or understated the key point of the article.

It’s minimalist markup.

The ALA article layout is doing a 3-column, source-ordered layout with 3 less DIV containers than skidoo too. Now at least 1, but really 2 of those DIVs are there for visual purposes only (adding in a border, padding, etc…) but the fact remains it is heavier on extra markup.

I’ve toyed with minimai markup before and think I might have to take another go at it.

One thing I run into is trying to (ab)use the body element by having it play the role of page wrapper doesn’t really work. IE5 and earlier put the scroll bars for the page on the INSIDE of any borders added to the body element. This means a 200px right border on the body element puts the vertical scrollbar 200 pixels from the right edge of the screen. Now I can see some interesting, experimental uses for doing something like that, but for the layout strucutre I want that simply won’t do.

So I’ll need to toy around a bit. I’ll post anything I put together.