Posts from 2006

If you’re bothered by the fact that you weren’t bothered by a thought you just had, isn’t the thought just bothering you by proxy?

• Botheration was published on Friday, February 17th, 2006.
• It was assigned to the Humor category.
• There have been twenty-four replies.

Thanks to The Wolf‘s pointer to The Other Wolf‘s post, I now bring you “Unfortunately Eric”.

Unfortunately, Eric mentions it, but doesn’t really discuss aa major concern of many…

You mean your misspelling of the word “a”?  I didn’t want to harp on it.

Unfortunately Eric Doesn’t Look Old Enough to Remember MS C 7.0…

Sure I am.  I just don’t want to remember it.

Unfortunately, Eric and Felecia are now against Lisa and the Wildlife preserve.

They started it!

She and Eric had been living with Dan in Hawaii for a while, but unfortunately, Eric had to go back home for a family emergency before we got there.

And that’s how she and Dan ended up together, whereas I ended up on the streets.  Crazy times…

Unfortunately Eric takes several wrong turns on the twisty, identical, unlabeled streets leading to Dog Boys (entirely due to a lack of preparation)…

In my defense, I was totally prepared for Cat Boys.

Unfortunately Eric has not released those precious gems of 415 golden songs, nor the EMB II album, as Eric left the group for other projects…

They weren’t very danceable anyway.

Unfortunately, Eric didn’t receive the letter until after the dance.

Story of my life.

Unfortunately, Eric had a couple of problems.

Your count seems a bit low.

Unfortunately, Eric had an appetite for destruction – which he never had the opportunity to quench…

Eric SMASH!

unfortunately eric is not only drop dead f*cking gorgeous he…

Oh, stop.

Unfortunately, Eric did not live long enough to witness the legend he created.

Aw crap.  Did I drop dead again?

It’ll be interesting to see how long it takes for this post to throw Google’s results out of whack.  (Answer: three days.)

• Unfortunately Eric was published on Thursday, February 9th, 2006.
• It was assigned to the Humor category.
• There have been nineteen replies.

I’d like to share something that will be old news to readers of CSS: The Definitive Guide and all of my other books, but nonetheless needs to be said out loud, in public, for everyone to hear.

The property line-height can accept unitless number values.  You can also give line-height united values, though generally you shouldn’t.  But unitless numbers are just fine for this property.

So what’s the difference?  When you define a united value, like 1em, you’re setting things up to pass along the computed result to any descendants.  For example, suppose the following CSS is applied to a document containing the following markup fragment:

ul {font-size: 15px; line-height: 1em;}
li {font-size: 10px;}
small {font-size: 80%;}

<ul>
  <li>I'm a list item with <small>small text</small>.</li>
</ul>

The ul element has its line-height computed to be 15px because for line-height, em-based values are calculated using the computed font-size of the element itself.  I declared the font-size directly, so we know its computed size in pixels.

(Yes, yes, I know, pixel-sized text is evil and wrong, but it makes explaining how all this works a lot simpler.)

So that computed value of 15px is what’s passed on to the descendent elements.  The li and small elements will inherit a line-height value of 15px.  End of story.  They don’t change it based on their own font sizes; in fact, they don’t change it at all.  They just take that 15px and use it, exactly the same as if I’d said:

ul {font-size: 15px; line-height: 1em;}
li {font-size: 10px; line-height: 15px;}
small {font-size: 80%; line-height: 15px;}

Okay, now suppose I take the em off that line-height value, so that the styles now read:

ul {font-size: 15px; line-height: 1;}
li {font-size: 10px;}
small {font-size: 80%;}

Now what’s passed on is that raw number, which is used by descendent elements as a scaling factor—a multiplier, if you will–and not the computed result.

Thus every element that inherits that value of 1 will take that value and multiply it with their computed font-sizes.  The list item, with its declared font-size: 10px, will have a computed line-height of 10px.  Then it will pass that 1 on to the small element, which will multiply it with its computed font-size.  That’s 8 pixels; therefore, its line-height will also be 8 pixels.

The end result is exactly the same as if I’d written:

ul {font-size: 15px; line-height: 1;}
li {font-size: 10px; line-height: 10px;}
small {font-size: 80%; line-height: 8px;}

That’s a pretty major difference.  This is why it’s always strongly recommended that you use unitless numbers if you’re going to set a line-height on something like the html or body elements, or indeed on any element that is going to have descendant elements.

The fact that the CSS validator has a bug that causes it to generate parse errors on unitless number values for line-height (see report #2307) rather confuses things; we get an occasional jeering e-mail over at A List Apart as a result, since running CSS validation on the site gets an error due to my use of line-height: 1;.  Jeffrey points the correspondents to that bug report, and usually we never hear anything back.

And if anyone reading this feels motivated to fix the validator, please do.  As it says in the bug report, all they really need is a patch for review.  I might do it myself when I have some free time.  That’ll be in, oh, 2009 or so.

Again: the property line-height can accept unitless number values, and they’re a better choice than united values in 99 out of 100 cases anyway.  Okay?  Thank you.

[Addendum 26 Aug 06: Roger Johansson points out a bug in older Gecko browsers relating to unitless line-heights.]

• Unitless line-heights was published on Wednesday, February 8th, 2006.
• It was assigned to the CSS category.
• There have been one hundred thirteen replies.

Registration for AEA Atlanta has been open a week now and one-fifth of the seats are already claimed, so you might want to step up the pressure on your boss.  The early bird deadline won’t be here for another three and a half weeks, but seat availability may not last that long.  (As I’ve mentioned before, it didn’t in Philadelphia.)

Even better, the value of any one of those seats just went up.  How so?  We’ve just announced that we’ll have two (count ’em!) guest speakers joining us: Jason Santa Maria, who delivered one of the highest rated presentations in Philadelphia; and Atlanta native Todd Dominey of Dominey Design, Turner Entertainment, and What Do I Know.

What will they talk about?  You’ll have to come to Atlanta to find out.  Personally, I can’t wait.

• AEA Atlanta Heats Up was published on Monday, February 6th, 2006.
• It was assigned to the Speaking and Standards categories.
• There have been three replies.

So IE7 beta 2 is out.  As you might expect in a beta, it has some things that don’t work as one might hope, whether due to long-standing behaviors or brand new bugs.

I’ve said it before, and I’ll say it again: don’t panic.  Trying to fix a site that’s “broken” in IE7b2 is kind of like deciding to raze your profitable gas station just because you heard car companies are experimenting with hydrogen fuel cells.  When the final version of IE7 comes out, then you can worry about what to do.  Maybe your site won’t be “broken” any more, and you won’t have to do anything.

In the meantime, what you should do is figure out what’s causing the problem you’re seeing in b2, create a very minimal test case that causes the problem, and submit that to Microsoft.  By doing that, you give them a chance to identify the problem and fix it before IE7 goes final… at which time, you won’t have to do anything about your site, because it won’t be broken.

That’s if they fix the bug in question.  They might not; they don’t have infinite time and energy.  But I can absolutely guarantee that they’ll never get around to fixing a bug nobody told them about.

In the CSS world, there are some points of concern, including bugs that are new to IE7b2.  The css-discuss community has started collecting information over on the wiki, and if you have test cases that demonstrate CSS bugs in IE7, you should feel free to add information and links to that page.

Before you do, though, make sure to observe the following (adapted from my post to css-discuss):

1. Make absolutely certain you’re testing IE7 beta 2.  IE7b1, which is available for download on various sites, had no known CSS enhancements.  It did not support CSS2.1 selectors, or fix any bugs on which CSS hacks depend, or just about anything else.  If you test with IE7b1, you’re wasting your time.  Again, be SURE you’re testing with IE7b2.

2. If you’re testing property, value, or behavioral support in IE7, make absolutely certain that your test case uses no hacks, filters, conditional comments, or other measures.  If you’re testing float margin-doubling, for example, but you still have in a CSS hack targeted at IE6, you might get completely spurious results. Make your tests as simple as humanly possible while still showing the problem.

3. If you’re testing support for hacks, filters, or conditional comments in IE7, try to make sure you’re testing using simple effects. For example, here’s how I’d test for IE7 support of a child combinator:

      p {color: red; font-style: italic; font-weight: normal;
         text-transform: none;}
      div>p {color: green;}
      div > p {font-style: normal;}
      #test>p {font-weight: bold;}
      #test > p {text-transform: uppercase;}
   
      <div id="test"><p>Bold uppercase green</p></div>
      <p>Italic normal case red</p>
   

   This approach uses property/value combinations that we all know IE/Win has supported for a long, long time.  If I tried to test with widths and margins and padding, I’d be concerned that a box model bug was sneaking in and making me think there was a selection bug.  With the color-font-text approach, this is far less likely.  (Not non-zero, but close.)

   Similarly, to test arbitrary-element hover, I’d do nothing more exciting than:

       p:hover {color: green; background: cyan;}
   

4. If you find a new bug, as Al Sparber has with the a:hover/@import problem, absolutely document it with a basic test case (as Al did) and feel free to ask others for confirmation.  But remember the previous points when you construct your test case.

The goal of all this isn’t just to make sure Microsoft knows about every CSS bug under the sun, though that certainly wouldn’t hurt.  What I also hope to see happen is that we get an idea of what’s new, what’s broken, and what absolutely must be fixed.  To pick a hypothetical example, suppose it was discovered that in fixing float margin-doubling, IE7 broke clearing behavior.  That would absolutely have to get fixed before IE7 final.  Doing so would be far more critical than, say, adding support for generated content, or even fixed positioning.

Again, don’t panic, but please do help find any bugs or other problems in IE7b2, so that we have a chance of seeing the problems corrected.

Addenda: so just after I posted this, I found out about the IEblog post What’s New for CSS in Beta 2 Preview? and the in-progress MSDN technical note Cascading Style Sheet Compatibility in Internet Explorer 7.  Those might come in handy as a baseline of “here’s what I should see” while you work to find out what you actually see.

• Charting IE7b2 was published on Friday, February 3rd, 2006.
• It was assigned to the Browsers, CSS, and Standards categories.
• There have been thirty-one replies.

Registration for AEA Atlanta is now open, so y’all sign up and come see us, y’hear?  It’ll be both a hoot and a holler.  Shoot, we can all have a Coke together.

Just make sure to sign up before March 3rd, unless you want to miss out on the $50 early bird discount.  If you need to exert a little pressure on your boss to cough up the funds, AEA Philadelphia sold out about two weeks before the early bird deadline.

Just sayin’.

• AEA Atlanta Registration Open was published on Monday, January 30th, 2006.
• It was assigned to the Speaking and Standards categories.
• There have been three replies.

Inspired by some recent conversations and a post by Dave Shea, I’m going to share with you my Sooper-Dooper No-Patent-Pending DIY Anti-Jet-Lag Technique.  I used it in my trips to and from the UK, Japan, and Australia this past year, and I didn’t have jet lag going either direction for any one of those trips.  The technique is so simple, you’ll wonder why you didn’t think of it first.  Unless you did, in which case you can feel all smug.

Here it is: after getting your usual amount of nightly sleep, wake up at your normal time in the target time zone.

All right, maybe it doesn’t sound simple.  What I mean is, figure out what time the day starts at your destination.  Then modify your sleep schedule to synchronize with it before you get there.  So if you always get up at sunrise, arrange things so you sleep your usual time and wake up at the same time the sun is rising at your destination.

I’ll use my trip to Australia for Web Essentials as an example.  Going there, I flew across America to Los Angeles and then had nine hours before my flight across the Pacific.  The United flight from LAX left at 11:15pm, and arrived in Sydney at approximately 7:00am Sydney time.  Perfect: that’s about when I get up anyway.  I need about six hours of sleep in a night, and the flight was 13.5 hours long.  So I kept myself awake for the first half of the flight, and slept for the second.  When we landed Tuesday, I was all ready to go.  Sure, I was tired, but I was completely synched up with Sydney’s time zone. 

Coming back was tougher, because we departed Sydney at 1:30pm and landed in Los Angeles at 11:15am the same day.  Still, I knew what I had to do: wake up around 7:30am Los Angeles time (give or take an hour; I’m not overly picky about the time I wake up).  So I slept only an hour or two the night before leaving, in order to intentionally shorten my waking time during the flight.  Part way through the flight, I went to sleep, and woke up a few hours before landing.  While I was exhausted all that day, I was in step with LA’s time zone.

As I say, I did the same going to and from Japan, and when I went over to London.  Synching to the UK was actually pretty simple, because going there was a seven-hour direct flight that landed at 7:00am.  I just made sure to sleep for as much of the flight as possible.  The return flight was a special case, as it left in the late morning and landed in the early afternoon, Cleveland time.  So I just kept myself awake until my usual bed time, and got a full night’s sleep.  Ta-daaa!  No jet lag.

It is no shame to support this technique with medication; I do it myself, in fact.  Tylenol PM works well for me, as does Ambien.  I do not, however, medicate myself into wakefulness upon arrival.  No melatonin, which never has any effect on me anyway; and no caffeine, which I basically never consume in any form.

If you use this approach, odds are that you’ll be pretty tired on the day you arrive.  Just keep going until whatever time you’d normally go to sleep, and then sleep until your normal wake time (or maybe an hour or two later, if you’re feeling indulgent).  The next day, you’ll be back up to speed and still in synch with the local time.

Admittedly, this does require some forethought and planning, but it works for me every time.

• How to Avoid Jet Lag was published on Sunday, January 29th, 2006.
• It was assigned to the Travel category.
• There have been thirteen replies.

That’s right, folks, it’s on.

An Event Apart.  Atlanta.  April.  Alliterative!

We’ve also given a tiny little peek behind the schedule curtain: Seattle, Chicago, and Los Angeles (not necessarily in that order) will be future AEA stops in 2006.  There may be one or two more in addition to that, but we can’t give away all our secrets, now, can we?  Like the actual dates we’ll be in those cities.  Nope, couldn’t possibly give out those.

Okay, the dates aren’t really secrets.  We just don’t know yet.  Scheduling a road show isn’t an exact science.  There’s a lovely and near-continual juggling act with other travel commitments, venue desirability, and venue availability.  The last thing we’d want is to say we’ll be in City A on Date X, and then have to change it later on.  That’s not simply unprofessional—it’s just plain rude.

Of course, if you’d been subscribed to the AEA RSS feed, you’d already know all this.  In fact, you probably are, and do.  Sorry for the redundancy.  Forget I said anything.

Atlanta!  Be there.  Or, you know, be at one of the future shows.  Either way, we look forward to seeing you!

(P.S.  We know that these are all U.S. cities, and there are many of you in Europe who’d like to have the show come there.  We don’t have any non-U.S. plans yet.  Yet.  One day, maybe, but for now we’re going to stick to the country we know.  It makes calculating taxes a lot simpler, plus there aren’t any awkward customs forms to fill out.)

• AEA: Atlanta Bound was published on Friday, January 27th, 2006.
• It was assigned to the Speaking and Standards categories.
• There have been six replies.