Posts in the CSS Category

This morning I got word in my RSS feeds that Google has launched what they call “customized search engines” through Google Co-Op.  As a test, I created a CSS search engine.  Go ahead, try it out.

       

There are two ways to configure a custom search engine.  One is to search the whole web but emphasize the sites you list.  The other is to search only the sites you list.  While the second might seem to be overly restrictive, the first doesn’t really seem very useful, at least for a CSS search engine.  When I compared the “CSS search” to “Web search” results, they really didn’t differ all that much—in some cases, having the same ten results on the first page, but in a slightly different order.  On occasion, the “Web search” ordering was actually more useful.

So I set up the CSS search to be restricted to the sites I listed, which I thought seemed relatively useful.  Only whenever I run the search from meyerweb instead of within Google, I get the “whole Web” search instead of the “only my sites search”, which either means I’m doing something wrong or I’m just too early an adopter.  Hopefully it’ll work as intended for you.  (Update: it seems to be working as intended now.)

Anyway, I’m not about to pretend that the six sites I included constitute the entirety of sites with useful CSS information.  Thus, I’ve set up the CSS search to be open to any volunteers.  If you have a Google Co-Op account (which I think is just any old Google developer account, such as you might have created for Google Maps) or want to create one, you can add sites to the ‘approved’ list without any say-so on my part.  Though I do have the power to boot sites that aren’t relevant, or too far out of date, or that look at me cross-eyed, or whatever.  To do so, I think you click the “Edit this seach engine” link on my CSS Search home page and then click on “Collaboration” to volunteer.  Or you might be able to go directly there.  I have to accept volunteers, so kindly be patient if it takes me a day or three.  And I’m going to simply reject any anonymous volunteers—sorry if that’s you.

For those that don’t have or want a Google account, feel free to suggest sites in the comments here.  In terms of getting them actually added, you’ll be at the mercy of my free time; but then again, so am I.

• CSS Search was published on Tuesday, October 24th, 2006.
• It was assigned to the CSS category.
• There have been twenty-six replies.

A couple of weeks back, I was hanging out in a New York hotel lobby with Tantek, who was either working on his AEA slides or enhancing the overall usefulness of the web in his spare time; I’m not sure which.  On the far wall, a plasma display ran CNN continually, softly, offering up such choice crawl text as “N. Korea Missile Test Fallout”.  One of the stories running was about alleged plagiarism on the part of Ann Coulter.

We got into a brief discussion over whether such people should be rebutted or ignored.  Tantek took the former position, whereas I took the latter.  My stance is probably a holdover from my long years of Usenet and mailing-list participation, where one of my most iron-clad rules is “Don’t feed the trolls”.  Better they starve for lack of attention, that’s how I see it.  Perhaps this is a defensible strategy in the “real world”, and perhaps not, but I will freely admit that it’s one of my default behaviors.

Thus, my first instinct was to completely ignore John Dvorak’s screed about CSS.  Mr. Dvorak is an admitted troll, and so my default tendency is to simply ignore him.  But “troll” is, in my world, an alternate spelling for “fool”, and as Winston Churchill reminded us, one of the great lessons of life is to know that even fools are sometimes right.

So is Mr. Dvorak right?  Not in what he has to say, no, but there is still something there worth hearing.

It turns out that none of his complaints about CSS are really valid, even when you consider only the ones that have a factual basis.  Sure, he can complain about the cascade being confusing, but that’s like criticizing Windows because of all those stupid windows that open up everywhere and get in the way of the desktop wallpaper.  It’s an inherent feature of the system: either accept it and move on, or reject it and walk away, but don’t waste your time complaining about it.  The best part, of course, is where he blames CSS for inconsistent browser implementations, which is rather like criticizing Microsoft because Windows doesn’t run properly on a computer whose processor isn’t compatible with Intel’s architecture.

But step back and let your eyesight blur a bit, and the shape of a worthwhile point begins to emerge.  The closest Mr. Dvorak gets to expressing it, possibly by accident, is this sentence: “Can someone explain to me exactly what kind of ‘standard’ CSS is, anyway?”

I could do so, of course, as could most of you, but that’s not the issue.  What we’re seeing here is the initial reaction of a CSS newbie, not too different from many others when they first begin to style, and all brought closer to home by the high-profile nature of the newbie.  (Whatever you may think of Mr. Dvorak, he has prominence in the industry.)  CSS is not as hard as some make it out to be, but it isn’t easy as cake, either.

A good part of that problem is the natural expectation that all browsers should act the same.  It’s a strange thing to expect if you’ve been in the field long enough, since browsers have never really been consistent on anything, from HTML error handling to PNG support.  But someone who’s coming in fresh is almost certainly going to expect that if they do things a certain way, the result just works.  Why would one expect anything less?

That’s why the Web Standards Project was founded, of course; and its existence, history, and current efforts put paid to Mr. Dvorak’s assertion that nothing is being done.  As I’ve said, none of his individual points are on target.  What his outburst does is remind us of the problem to which so many have grown numb, and which we still—for all the progress that has been made—face on a daily basis.  Consequently, it reminds us to keep advocating for greater consistency between browsers, to praise the efforts of browser makers in that direction, and to help them correct their course when they move in the wrong direction—and to do so constructively, not destructively.  For while we may gain insights from the rantings of trolls, we should never be so foolish as to adopt their tactics.

• Dvoraked was published on Wednesday, July 26th, 2006.
• It was assigned to the CSS and Standards categories.
• There have been fifty-one replies.

I’ll get back to the whole IE7 thing in a day or three.  Sorry to start the conversation and then go silent, but I’ve recently learned two things.

1. The week after announcing a new event over at An Event Apart (like, say, AEA Chicago) is always very busy as registrations come in, people contact us with questions, posts have to be written, and so on.
2. The week before an event (like, say, AEA Atlanta) is always very busy with travel preparations, double-checking of arrangements, last-minute tweaks to talks, and so on.

So of course we’d set things up to have both happen the same week.  With another conference on my schedule for the end of the same week as AEA Atlanta.

Anyway, as I say, I’ll get back to the blogging Real Soon Now.  In the meantime, I have two new appearances to announce (in chronological order).

1. 27-28 April 2006 – Iceweb 2006 – Reykjavik, Iceland

   I’ll be presenting “The One True Layout?”, which will be a detailed look at the pros and cons of techniques debuted in Alex Robinson’s article.  A bunch of other big names will be there as well, despite which I got top billing on the site’s speaker list.  Ha!  Take that, Mr. Dave “I’m Too Sexy For The Web” Shea!

2. 12 May 2006 – Carson Workshops – London, England

   This will be an updated version of the full-day seminar “Professional CSS XHTML Techniques”.  Seating on these is quite limited, so you might want to register early and often.  Or at least early.

That’s it for now.  I hope to be back soon.

• Still Here was published on Saturday, April 8th, 2006.
• It was assigned to the (X)HTML, CSS, and Speaking categories.
• There have been two 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.

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.

In “Bar Graphs With Style“, I took a set of nested lists and some divs and turned them into a vertical bar graph using CSS.  Jan Brašna pointed out that the actual information I was presenting would probably be better represented as a table instead of nested lists.  I don’t think there’s anything wrong with using the lists, but I do agree with him that a table might be a better base represention of the data.  Maybe you agree.  If so, then here you go: CSS Vertical Bar Graphs using a table as the markup basis.

The demo works fine in Safari, and in Firefox I got it to work by explicitly setting the table element to display: block (when I left it as display: table, the bars were badly misplaced).  In IE/Win, everything’s fine except for the actual placement of the bars; they’re fine as a group but way out of place.  I think the IE/Win problem is a simple refusal to give a table element dimensions when all of its descendants have been positioned, no matter what display value it’s given.  Perhaps some intrepid soul can figure out a way to defeat this. [Update: some intrepid soul did, and the demo has been updated; it now works in IE/Win as well as most other browsers.]

(I considered the idea of positioning all the bars with top instead of bottom, thus sidestepping the table-sizing problem, but that would mean a different way to place the ‘ticks’ and in the end it was different enough from what I’d done that I just couldn’t be bothered.  Feel free to run with the idea, though, or come up with a better one.)

I must admit that when I first assembled this table-based chart demo, it was with some trepidation.  From a CSS point of view, of course, it doesn’t matter what elements you position, nor how: a td is no different than a div or any other element.  Historical browser behavior, though, has been to put table markup into its own special category and treat it as being extra-special—as witness IE/Win’s handling of the original demo.  I was honestly afraid that, in overriding the display values for table elements (by positioning them), I’d crash a browser.  So far, no crashes, but proceed at your own risk!

• Tables to Bar Graphs was published on Wednesday, December 21st, 2005.
• It was assigned to the CSS and Projects categories.
• There have been twenty-two replies.

A lot of the time, when I’m sharing a technique or effect I’ve devised, I’ll say something like “I doubt I’m the first to think of this…” or “it may not be original, but it’s original to me…”.  This might strike some as an annoying quirk, some sort of pseudo-modesty that I should either embrace fully or just drop already.

However, I do it because I know it’s true.  Even some of the most radical experiments I’ve published, like those on css/edge, were prefigured or anticipated by others.  I didn’t steal anyone’s ideas, of course.  Every one of those demos was an original creation born of my knowledge and thinking.  They just weren’t necessarily the very first instance of those techniques ever published anywhere.  Other ideas, like Universal Child Replacement, were devised before I hit upon them but were never documented.

I bring this up because the door swings both ways: from time to time, I see someone else publish a technique or idea that I’d had but never documented.  A recent case in point was the appearance of “CSS for Bar Graphs” at Apples to Oranges, which showed a vertical bar graph created out of CSS and a list.  I’d done something very, very similar almost three months before the AtO article’s publication date while creating an invoice-tracking system for myself, and never gotten around to publishing an example.

This almost certainly means that they and I were creating basically the same thing at the same time.  Who got the idea first?  Who cares?  It’s a nifty idea no matter who thought it up.  Plus it’s a near-certainty that somebody else did it long before three months ago, and never got around to documenting it.

I often wonder how many really cool techniques and ideas are lost simply because the inventors don’t have the time or energy to publish them.

Since my approach varies a bit from AtO’s, I’ve put up a css/edge demonstration for people to poke.  The major difference is, I think, my use of empty divs to create the horizontal strata instead of a background image.  This let me have strata that were scaled to the figures being output.  For example, if the strata are increments of $10,000 and the highest bar is $55,055, then I can write out enough “bar divs” to make the top of the chart $60,000.  If the tallest bar only goes to $38,522, then I can stop at $40,000.

This also meant calculating and writing out the bars’ heights as inline styles.  What you see in the markup of my demo is the end result of all that back-end calculation.  There are doubtless better ways to go about creating the strata and setting the bar heights, most obviously using DOM scripting to write in said bar divs instead of dirtying up the XHTML with them.  The same would be true for the inline heights of the bars themselves, which could be dropped in favor of dynamic setting.  Heck, you could even make it so the chart could be zoomed in or out.

Someone else can do the necessary scripting if they like; I’m content to get the example out there, however late to the party I may be.  The more such examples there are, the better.

Followup: Tables to Bar Graphs, in which the same chart is created out of a table instead of nested lists.

• Bar Graphs With Style was published on Tuesday, December 20th, 2005.
• It was assigned to the CSS, Projects, and Standards categories.
• There have been thirty replies.

Tim Bray, that dashing man-about-town, recently sang the praises of Adium, a multi-service chat client for OS X.  I’d tried it a while back, and been only marginally impressed.  At the time, its presentational inflexibility was too annoying for me to take it seriously.  Okay, yes: it was a damn sight better than Messenger for OS X, which is the only reason I even kept it on my hard drive.  But I hardly ever log onto MSN any more, as everyone I know is on AIM.  So I’d stuck with iChat AV.

Still, Tim’s word is always gold (or at least high-grade palladium) with me, and he said the magic words (“highly skinnable”), so I downloaded the latest copy and poked around for a bit.

Boy howdy!  Adium has definitely come a long, long way since last I visited.  You can change the appearance of your chat sessions (with “message themes”), the dock icons, the contact list, and much more.  Since none of the default message themes really did it for me, I went looking for others.  There are quite a few available at the Adium Xtras site, but none of them were really what I wanted either.  In iChat, I cranked the graphic frippery down to zero so that the chat sessions were as compact as possible, but I still had the text look nice.  If I could recreate that in Adium, it would make the migration much, much simpler.

So I dug into the package contents of a promising message theme… and found out that themes are based on nothing more than XHTML and CSS.

Seriously.  The entirety of an Adium chat window is an XHTML document that’s being dynamically updated via DOM scripting—all of it pumped through WebKit, of course.  In creating a message theme, you define what markup will be used, and write CSS to style it.  You can even define variants on your theme by writing additional style sheets.

So with some quick hacking, I not only radically improved the markup generated during a chat (the markup I saw in the packages I downloaded was, um, sub-optimal), but I basically replicated my old iChat theme with some simple CSS.  And then I created some variants that slightly modify it in various ways, mostly to prove that I could.

I’m now wondering if I could write and attach JavaScript that would make chat sessions even more interactive, more robust.  (Update: Phil says yes.)  Click on a line to copy the whole line to the clipboard, say, or dynamically change the in-session presentation by hitting a button.  Adium may block that kind of thing, but if not, then it’s a chat client extensible beyond anything I’ve so far imagined.

And given how much I love to tinker with my software, that’s like waving a bulging suitcase of money in front of a senator.

Granted, there are some things I’d like to change.  For example, the markup you define in a theme is not used in saving the chat log.  In a log, you just get some basic markup with a case of classitis and very, very poor semantics.  It would be a lot cooler if you could define the log markup (or the log just used the markup you generate during a chat session) and the CSS to present it.

A chat log is also something that, it seems to me, cries out for a microformat.  The markup I’m using for my theme is also a first effort in that direction, recycling some other microformats’ concepts (I stole a bit from hCalendar and am planning to graft in some hCard as well) and setting up some basics.  If I can take this far enough, I might consider pushing to upgrade the markup Adium generates in its logs.  They’re dropping a lot of information on the floor when they write out the logs, and I think that’s a shame.

But then, I can make the effort to fix that and actually have a chance of it paying dividends.  The joys of open source, you know?

I’ll still use iChat AV for videoconferences, which are an essential tool for family cohesiveness when I’m on the road, as well as to keep close to my father down in Florida.  For text, though—which accounts for at least 90% of my instant messaging activity—Adium is my new chat buddy.

• Adium: Chatting With Style was published on Monday, December 19th, 2005.
• It was assigned to the CSS, Microformats, and Standards categories.
• There have been forty replies.