Posts in the CSS Category

Multi-Unit Any-Order Columns

Published 19 years, 2 weeks past

During last week’s workshop in Chicago, I was asked to discuss Alex Robinson’s One True Layout.  This presented a bit of a challenge, since the article and its contents are rather new.  While I’ve read through it all and grasped the main points, I wasn’t entirely sure I grasped the nuances.  For that matter, I’m still not entirely certain that I do.  And I tend to be wary of speaking about things I don’t fully understand.  Still, the audience was interested, so I took the plunge, figuring that I could stick to the bits I knew relatively well.

The Any Order Columns seem straightforward enough, once you get that it’s using margins to shift elements around.  The Equal Height Columns aren’t really, perhaps more properly being called “Extremely Tall But Clipped Columns”, but they simulate the job well enough to count.  And then there is the case of Vertical Grids, which I’m still pondering.

But as an illustration of why I say I’m not sure I grasp all the nuances, it was literally while presenting on this topic during the workshop that I hit on an extension of Any Order Columns (AOC) that allows for AOC to be used with columns of mixed width measures.  It came in response to a question about that very thing.  I’d been showing how to do AOC with columns sized with consistent units, like all with percentage widths or all with pixel widths.  But, an attendee asked, what if you wanted to have one column with an em width and another with percentages?

Say, for example, you wanted the first and second blocks (to use the terminology from Alex’s examples) to be the center and right columns, respectively, and the third block as the leftmost column.  Furthermore, suppose you want the left column to be 10em wide, the center column 40em wide with 1em ‘gutters’, and the right column to be 200 pixels wide.  I’m using pixels because it’s a commonly-used unit, but if it makes you feel better, assume there are Flickr images there or something similar in that column.

All right.  So we have to move the third block leftwards by 40em of center width, 2em of gutters, 10em of the space it will occupy, and 200 pixels of the rightmost column—the second block.  That’s 52em + 200px, which is exactly the sort of thing CSS doesn’t allow for a variety of reasons, some more reasonable than others.  IE/Win allows expressions, but only with a proprietary value syntax that nobody else supports.  And it potentially could be done with JavaScript, which would require pulling some font-size information in order to compute various em widths.

Or… we could relatively position a float, using the float’s margin to handle one of the measures, and the relative positioning to handle the other.  So you start like this:

#block3 {float: left; margin-left: -200px;}

That will get the third block to sit right on top of the second.  That’s taken care of the 200 pixels, but what about getting it the rest of the way?  Add the following:

#block3 {float: left; margin-left: -200px;
  position: relative; left: -52em;}

This puts the third block right where we want it.

There’s one exception: IE5/Mac, which doesn’t pay attention to the relative positioning when the element’s been floated.  So far as I’ve been able to discern, this is the one reduction of browser support from Alex’s original AOC.

With a little bit of math, you can make this work so long as the elements to the left of the shifted column use no more than three different units in their sizing.  To handle two types of units, you could do something like this:

#block1, #block2, #block3 {float: left;}
#block1 {width: 35em; padding: 0 20px; margin-left: 9em;}
#block2 {width: 12em; padding: 0 15px 1em 5px;}
#block3 {width: 8em; padding: 0 0.5em;
   margin-left: -60px; position: relative; left: -56em;}

(code example with browser workarounds)

This approach would permit the ability to drop in pixel-sized decorations, like separators or drop shadows or whatever, while preserving em-width column contents in order to scale with font sizes.

Now suppose you have a mixture of all three unit types, which is a case I didn’t tackle in the workshop.  I might even have said it wasn’t possible to handle, but if I did say that, I was wrong.  With the addition of a negative right margin on the second column, we can handle all three units, as seen here:

#block1, #block2, #block3 {float: left;}
#block1 {width: 50%; margin-left: 11em; margin-right: 1em;}
#block2 {width: 200px; margin-right: -200px;}
#block3 {width: 10em; margin-left: -50%;
  position: relative; left: -12em;}

(code example with browser workarounds)

Note that I’m not saying that you’d necessarily want to mix fixed-width columns with fluid-width columns.  Doing so is a potentially volatile mix when using CSS-driven design, and this technique doesn’t make it any more or less volatile.  If you want to do it, though, this is a powerful approach.

In the examples to which I pointed, I came across some intermittent appearances of the double-margin float bug in IE5.5/Win, though oddly not in IE6/Win.  I didn’t try to work around these inconsistencies beyond using the display: inline hack from Alex’s original examples, but I’m sure they’re surmountable.  It’s probably as good a case as any for using conditional comments to serve up fixes to pre-IE6 versions of IE/Win.

You may have noticed that, if the browser window is reduced in width, the columns start dropping in the two-unit example.  That’s something that could likely be handled with a sufficiently wide container, although doing that risks the dread horizontal scrollbar.  You’d get the same scrollbar with either older CSS layout approaches or with table-driven design, though.

I suspect there are even more combinations and nuances to be found in the AOC technique, and still more in the column and grid ideas Alex has laid out.  Hopefully I’ve made a good start here.  For any omissions or inaccuracies there may have been in my Chicago presentation, I hope the attendees and organizers will accept my apologies.


Layout Revolution

Published 19 years, 3 weeks past

Recently, Alex Robinson published an article titled “In Search of the One True Layout“, and it basically turns the conventional wisdom about what CSS layouts can and can’t accomplish on its ear.

One of the article’s primary aims is nothing less than enabling multi-column layout using no extra markup (beyond a div to enclose each column’s content) and allowing the columns to be in any document source order.  Impossible?  No.  It appears to have done just that in all current browsers, and several non-current browsers as well.

Assuming this technique stands up over time, and I see little to no reason why it would not, this is a truly major development (and that’s an understatement).  There is a problem in recent versions of Gecko-based browsers which you can read about in Bugzilla entry 312777.  The problem has been fixed in very recent builds, but the question is whether or not the fix will make it into Firefox 1.5.  In comment 40 of that entry, one of the engineers indicates that having web developers put in their thoughts on the importance of this fix would be welcome.

Now, we don’t want to create a stampede here.  However, if you have a Bugzilla account and your assessment of the importance of the bug varies from the comments posted, or you have something new to add to the comments, then by all means contribute.

Getting back to Alex’s article, it also tackles the desire for equal-height columns in a tableless design environment.  Then, just to pile it on, Alex knocks out a way to create vertical grids without tables.  Later on, he ties it all together into one neat, shiny package.

So that’s basically killing three long-standing frustrations of standards-oriented design with one stone.  Any one of them is notable in its own right; put the three together, and I’m pretty much emerald green with envy over here.  It might just be time for me to consider hanging up my spurs, folks, ’cause it looks like there’s a new sheriff in town.  And he’s packin’.


Selling Out Again

Published 19 years, 1 month past

I noticed this morning, after the power finally came back on, that the graphic next to the information on the Carson Workshops home page about the CSS/XHTML workshop I’m doing in a couple of weeks has a “LAST FEW” banner over it, so it looks like those seats are going fast as well.  If you were interested in that one but hadn’t yet gotten around to registering, now might be a good time.


To Hack With It

Published 19 years, 1 month past

To follow up on what I said recently, there’s another major reason to remain un-stressed about the impending release of IE7 and the use of CSS hacks.  If you read over the list of things that have been fixed, they read like a who’s who of CSS hacks—and a who’s who of the reasons we use most CSS hacks in the first place.

How is that the ticket to a stress-free existence?  I’ll give you an example.  One IE bug I deal with a lot is the doubled-margin float bug.  So I’ll write something like this:


#main {float: left; width: 30em; margin-left: 150px;}
* html #main {margin-left: 75px;}

I’ve halved the margin value in the “IE/Win only” line, which is the second one; that’s the CSS hack part of the duo.  By taking this approach, the layout is consistent between IE/Win and every other modern browser out there.

Okay, so here comes IE7, which the team says has a fixed CSS parser so the Tan hack (which is what I used) isn’t recognized.  That means IE7 completely skips the second line, the one with the hack.  But IE7 has also fixed the double-margin bug on floats.  So the hack rule is completely ignored by IE7, and it acts like other browsers when reading the first.  It’s like it was Firefox or something.  Meanwhile, any IE6 users out there get a consistent experience thanks to the Tan hack line, which it still recognizes.

So why aren’t I proclaiming that there’s absolutely nothing to worry about, as opposed to declaring my intent to stand pat?  Because the promised fixes are just that: promises.  I have no doubt as to the IE team’s deep desire to get these fixes shipped.  They may, however, find themselves overruled by other factors on one or more fixes.  Perhaps a given fix breaks the layout of eBay, or interacts badly with a particular version of Windows.  Simply put, forces beyond their control might lead to a shipping browser that doesn’t fix everything they want to fix.

That’s a big part of why I said I wasn’t going to make any moves until we have a working release in hand.  There’s absolutely no sense in rewriting all our style sheets to remove hacks—at least, there’s no sense right now.  We’d be trying to author against a moving, distant, and phantom target.  That’s a recipe for frustration.

In general, if the planned fixes do come through, then as far as site breakage, the advent of IE7 will be practically a non-event in the standards-oriented design community.  Assuming those  fixes are released, we’ll honestly have next to nothing to do.  Yes, there will be examples here and there of sites doing funky stuff and experiencing problems, as with Slashdot.  Those problem sites will be identified and fixed one way or another—maybe new hacks, maybe conditional comments, maybe reformulations of markup and CSS.  The same basic thing happened when IE6 came out, and I suspect we’ll have less upheaval with IE7 than with IE6—and IE6 was pretty small stuff, site-breakage-wise.

Note that I suspect.  I don’t know.  Nobody can know until the IE team releases a version with the fixes included.  When that happens, then we’ll start figuring out which way to jump.  Or I will, at any rate.  If anyone out there wants to do a little pointless panicking ahead of time, well, be my guest.


IE7 and IE7

Published 19 years, 1 month past

As noted on the WaSP site, the IE team is asking developers to clean up their CSS hacks because they’re causing sites to break in IE7 builds.

I have to admit that this call elicited an arid little chuckle from me, because it’s a case of chickens coming home to more than one roost.  There’s the fact that bugs in older versions of IE led us to use hacks, and so they’re making life harder for the IE team.  And then there’s the fact that the use of hacks is an inherently risky and fragile process, so the release of IE7 will make life harder for those who used them.  No smug self-superiority should be read into that second point, by the way: I quite firmly include myself in that crowd.

So—now what?  Personally, I’m not going to make a move until an IE7 beta with new CSS behavior is released.  Why change hacks just to have to hack more?  Put another way, if the ground is going to start shifting, there isn’t much sense in trying to guess how.  Wait until it does, and then adjust your footing.

Still, it might pay to consider ways to cope once the ground shifts.  This leads to something I’ve been pondering for a bit, and now’s a good time to bring it up.  When IE7 (the browser) comes out, it will make IE7 (the script) even more useful than it is now.

Here’s why: all the stuff that IE7 (the script) does, IE7 (the browser) is supposed to do as well.  That is to say, the script can bring IE6 up to par with IE7 the day IE7 is released.  See where I’m headed with this?  Instead of being chained to the fat tail of IE6 installs while being unable to use parser hacks in IE7, we can clear away the hacks and have IE6 and IE7 act basically the same.

They will of course not act exactly the same, and yes, there are drawbacks.  IE6 users will have to download the extra script, and those with JavaScript disabled will have problems.  Not every site will be able to accept those costs—but I’d wager the vast majority will.

In the main, it will be a lot less painful to clear out the hacks with IE7 (the script) available than without it.  A lot.

Oh, and before people start exhorting the use of conditional comments instead, it’s still too soon to know how good an idea that might be.  Doubtless they’ll come into play, but exactly how is completely unpredictable until we know what IE7 actually does.  Perhaps we’ll start using conditionals around the call to IE7 (the script).  Perhaps not.  Time will tell.

As I said before, it’s too soon to know which hacks to clear away or how to rework our code, but thanks to Dean Edwards’ efforts, I’m feeling a distinct lack of stress over the impending shifts.


Back On Watch

Published 19 years, 2 months past

After an extended hiatus, the Redesign Watch is back.  I’m celebrating its return with eight new entries, including the very recently announced HTML+CSS reworking of Slashdot.  I wonder how their work compares to the third-party job that Daniel Frommelt did a couple of years ago.

Since only the most recent five redesigns are shown on the home page, you’ll have to dig into the archive if you want to see all the new stuff—from Everything Tori on forward—or you could just subscribe to the RSS 2.0 feed.  You can find it and other meyerweb feeds on the Feeds page.  (Go figure!)


Speaking Out

Published 19 years, 2 months past

Just a reminder to all of you in the Chicago, IL area that I’ll be talking about XHTML, CSS, and that sort of thing on Thursday, 4 3 November 2005.  I’ll be talking all day long, or close to it, as I delve into details, rebuild a design or two, and answer questions from the attendees.  If you’re interested, check out the Carson Workshops site for more information on this and other workshops.

If you’re in Philadelphia, of course, you’ll want to check out An Event Apart, where Mr. Zeldman and I will trade off talking all day.  Seats have been selling pretty briskly, so if you’re interested, you might want to register soon.

I’d encourage all you Strayans to register for WE05, except it’s completely sold out.  The same is very nearly true of UI10, from what I’m told.  Things are definitely picking up on the events circuit!

Which is a good thing for me… after all, how else am I going to reach Gold Elite status?  (I wonder if I get an energy sword for that.)


ALA’s New Print Styles

Published 19 years, 2 months past

You asked for it, you begged for it, you demanded it: A List Apart is sporting a working print style sheet for the articles.  Want to know more about it?  Read “ALA’s New Print Styles“, my new article over at ALA.

Believe it or not, that’s only my second ALA article ever, and the first one was the classic “Going To Print“.  Maybe one of these days I should write an ALA article that doesn’t involve ink on dead trees.

Of course, if I stick to the interval established by my first two ALA articles, the next one won’t appear until 2008 early 2009… so I guess I have some time to think about it.


Browse the Archive

Earlier Entries

Later Entries