Posts in the CSS Category

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.

• To Hack With It was published on Tuesday, October 18th, 2005.
• It was assigned to the Browsers and CSS categories.
• There have been twenty-four replies.

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.

• IE7 and IE7 was published on Monday, October 17th, 2005.
• It was assigned to the Browsers and CSS categories.
• There have been thirty-six replies.

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!)

• Back On Watch was published on Thursday, September 22nd, 2005.
• It was assigned to the CSS and Redesign categories.
• There have been eleven replies.

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.)

• Speaking Out was published on Wednesday, September 21st, 2005.
• It was assigned to the (X)HTML, CSS, Speaking, and Standards categories.
• There have been five replies.

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.

• ALA’s New Print Styles was published on Tuesday, September 20th, 2005.
• It was assigned to the CSS and Writing categories.
• There have been four replies.

Okay, ALA fans, we’ve deployed a print style sheet on the articles.  I don’t know if I could call it done, but it’s a big step.  Why wasn’t it online sooner?  Say it with me: “browser bugs”.  Just when the convergence of screen CSS handling had me feeling good, I had to go and mess with print styling.  Good feeling’s gone.

At the moment, the print styles seem to work quite well in modern browsers except for Firefox 1.0.6 (which is what I have in OS X).  There, when I call up a print preview, any article is fine until page 4.  Then things go off the rails in short order.  Content disappears, margins go wild, all kinds of fun stuff.  Here, try previewing or printing Nick Usborne’s “Helping Your Visitors: a State of Mind.  Now try it with J. David Eisenberg’s “Validating a Custom DTD” or (somewhat ironically) Ross Howard’s “High-Resolution Image Printing“.  Pages 1-3 are fine for me, but after that, no good.  When you get a nice long article like Joe Clark’s “Facts and Opinion About PDF Accessibility” or (completely ironically) my own “Going To Print“, you’re just asking for trouble.

I tried searching Bugzilla for some report, but my skills over there are not what once they were.  So while I got a bunch of results, I don’t know if any of them described this problem.  Could some kind soul let me know if there is a report on this sort of thing already?  If not, I can submit the report.  I just don’t want to add yet another DUPLICATE to the database.

And hey, if you can work out a solution to the problem, I have a factory-fresh ALA T-shirt all ready to send out—you even get to choose which one you want.  Let me know.

Update: Dan Wilkinson is our winnah!

• When Printing Maims was published on Wednesday, September 14th, 2005.
• It was assigned to the Browsers and CSS categories.
• There have been seventeen replies.

I couldn’t be more proud to announce the launch of An Event Apart.  What is An Event Apart (AEA)?  It’s an all-day seminar, one that moves from city to city, featuring me and Jeffrey Zeldman.  The inaugural event will be held at the Franklin Institute in central Philadelphia, Pennsylvania on Monday, 5 December 2005.  We’ll be taking it to other cities in 2006; keep an eye on the AEA RSS feed for announcements.

Honestly, AEA can be summarized in one sentence: it’s the kind of seminar Jeffrey and I would want to attend.  Hopefully that right there is enough to get you interested, but wait until you hear the details.

• No “intro to X” sessions.  We’re packing the day with as much detail, technical insight, and expert information as possible.  We won’t be taking any time to explain the basics of CSS or XHTML or anything else.  From the first minute to the last, we’re putting the pedal to the metal.
• An intimate look at how Jeffrey and I do what we do.  Most of our material will be drawn from recent projects we’ve done together, such as the web sites for A List Apart, An Event Apart, UNIFEM, and others.  All the nifty tricks, browser hacks, practical compromises and development surprises—they’ll be laid bare for attendees to examine, question, chuckle over, and take back to their own work.
• Going from  comp to complete.  How does one get from a visual comp file to a working XHTML+CSS page?  You’ll find out how we do it as we step through that very process.
• Constant interaction.  This isn’t a rigidly formalized “we talk for 80 minutes and you ask questions for 10 minutes” kind of setup.  Jeffrey and I see it as more of a conversation between us and the attendees.  We’ll probably do most of the talking, and we’ll certainly have all kinds of stuff to talk about, but we’re really looking forward to questions that will take things in a new direction.  We want the attendees to ask tough questions about what we’re showing, and ask us about the tough problems they’ve faced.
• Attendee markover.  For one of the day’s sessions, we’ll take a site submitted by an attendee and give it a markover, turning it into semantic XHTML and CSS without disrupting the visual appearance.  This will make for a great look at practical standards-oriented design for a real-world site.
• Interesting venues.  Jeffrey and I been to a zillion conferences in hotel ballrooms and conference centers, and frankly we’re bored to death with that whole repetitive scene.  So we’re going to aim for places that are a little off the beaten path; venues that have some interest.  As an example, just look at the venue for AEA Philadelphia, the Franklin Institute; it’s one of the most prestigious science museums in the country.

The content of AEA won’t be just markup and CSS, either.  We’re going to talk about how standards-based design speeds up the development process, how we work in a distributed team, and how we approach web design in general.  We’ll share what’s worked for us and what hasn’t, and find out what experiences the attendees have had.

So if you’re in the Philadelphia area, or can reach it fairly easily, I strongly encourage you to take a look at the AEA site—and then ask yourself whether this is an event you can afford to miss.

• An Event Apart Debuts was published on Tuesday, September 6th, 2005.
• It was assigned to the (X)HTML, CSS, Speaking, and Standards categories.
• There have been nineteen replies.

This news is a little musty, but Shaun Inman updated CSS-SSC recently.  If you’re using CSS-SSC, you should definitely go grab the update.

“Hey, what’s CSS-SSC?” you exclaim?  Oh, I’m sorry.  It stands for Cascading Style Sheets Server-Side Constants.  Here’s Shaun’s initial example:

@server constants {
    linkColor: #AB6666;
    linkColorHover: #710101;
    }
a { color: linkColor; }
a:hover { color: linkColorHover; }

In other words, you can define your own constants in CSS.  This works because CSS-SSC is a preprocessor—it processes the style sheet before it’s sent to the browser, and turns it into something the browser can handle.  (Put another way, what arrives at the browser is a regular style sheet, with none of the ‘SSC’ information.)  Shaun offers more details in an earlier post.  CSS-SSC requires you to have PHP hanging about, and also to edit some stuff on your server, like .htaccess files.  You’ll also have to be careful about how you name your constants: use the constant name color, for example, and your CSS is going to go to a particularly mangled form of textual hell.

Personally, I’m both enthused and annoyed by CSS-SSC.  I think it’s a great solution: definitely one of the best, lightest-weight, easiest approaches to adding preprocessing to CSS.  I’m seriously considering putting it to use on ALA, in which I jumped through a few grouping hoops in order to get the fonts and colors just the way Jason wanted them.  Dropping back to constants would make life a bit easier—and would also simplify the whole “per-issue coloration” feature.  (Which I already have working, but via a large number of hoops, several of them on fire.)

I’m annoyed because it bothers me that Shaun had to create CSS-SSC in the first place.  There have been occasional requests for constants in CSS.  They get shot down every time.  “Use a preprocessor!” is the cry, and at first glance, CSS-SSC would seem to give credence to that response.  From my point of view, however, CSS should have had constants long ago, and what Shaun has done is proof.

The refusal to add constants as a feature of CSS has always stuck me as highly pointless.  Over the past decade, many people have expressed a need for CSS constants in a number of fora, and it’s a good bet many more have had the need without publicly expressing it.  Adding it to CSS would have done little to increase complexity on the implementor’s side; Shaun’s one-page PHP script (a good deal less when you remove the comments) proves that.  Adding it to CSS would have meant authors could just do it, without having to install anything else first.  Shaun’s made installation about as easy as it gets, but it’s still three or four steps more than should exist—and, for some authors, three or four impossible steps, due to their hosting situation.  And if you aren’t running a local web server, then you can’t test your CSS-SSC-enhanced styles locally; they’ll have to go to a web server first.

Because CSS still lacks, and will apparently continue to lack, a way to define your own constants, I’m really glad Shaun has devised this low-threshold solution.  I just wish that it hadn’t been necessary for him to do so in the first place.

• The Constants Gardener was published on Wednesday, August 31st, 2005.
• It was assigned to the CSS and Standards categories.
• There have been thirty-four replies.