Posts in the Browsers Category

In a fashion vaguely reminiscent of the process by which weeds keep growing back no matter how you try to rid yourself of them, the question of browser market share has once again been rearing its foul, misshapen head.  Dan kicked off a round of it over at Simplebits, but it’s recently been popping up other places as well.  I heard discussions about market share at SES Chicago, perhaps unsurprisingly, but I’ve also been seeing the question on various mailing lists and other forums.

The only thing more frustrating than the persistent recurrence of this unnecessary question is the inappropriate gravity it seems to acquire in so many minds.

Look, I’ll make this very simple for everyone.  If you’re trying to figure out what browsers to support (or not) in terms of layout consistency on a given site, then the answer is very easy.  Whatever the site’s access logs tell you.  End.  Of.  Story!

For example, the stats for the past few days’ worth of visitors to Complex Spiral Consulting tell me the following:

User Agent	Portion of hits
Firefox	43%
IE6	30.8%
Mozilla	8.8%
Safari	8.6%
Opera	2.4%

(For those who are curious, IE5.5 makes up 0.8% of hits.  Various flavors of IE5.x below IE5.5 total roughly 1.2%, but note that Windows and Mac users are lumped together there.)

Those statistics tell me quite a bit about the people who visit the CSC site, and I can use that information to decide what to do about browser support.  You know what those numbers tell you about which browsers to support (or not) in your designs for sites on which you work?  Absolutely squat.  Anyone who uses those access statistics to make decisions for their own work is a fool, and a misinformed fool at that.

In every design, we have to ask what browsers need to have a consistent experience, which ones can be given a reduced experience, and which ones get no design at all.  The user logs from another site are useless in trying to make this decision.  The “global statistics” from firms like WebSideStory are just as useless in this case.  They may be entirely accurate, but they are also entirely irrelevant when it comes to making design support decisions.  The only stats that matter are the ones that come from the site you’re designing.

In a like manner, I don’t care if you think visitors to your site or some other favorite site of yours are an accurate reflection of the overall Internet population or not: that opinion is similarly irrelevant.  It’s rather like me claiming that the people who come to our annual holiday party are an accurate reflection of partygoers in general.  Maybe they are and maybe they aren’t, but either way I don’t think you should plan your all-night rave to accomodate the kinds of people who drop by our house to have homemade bread and soup and chat about babies, politics, science-fiction movies, and the weather.  And vice versa.

(Do remember that your site’s stats may reflect its current behavior instead of your potential audience.  If your site is already broken past the point of usefulness in Safari, then you’re going to see very low Safari numbers.  Make sure that you’re comparing apples to apples, and only compare the numbers in your access logs for browsers that can already use the site.)

As for the related question of “at what percentage level do I decide a browser isn’t worth bothering about”—well, that’s really up to you, isn’t it?  I certainly can’t tell you when it’s worthwhile to stop worrying about IE5.0, or Netscape 4.7, or Mosaic 1.2.  I know what I think is appropriate for the sites I work on—and the process of finding the answer is different for every site.  It has to be, because every site is different.

Now, if you want to share your user demographics with anyone who wants a peek, hey, have fun with that.  If data exhibitionism is your thing, who am I to judge?  Just don’t pretend that the bits of data you’re exposing to the world are representative of everyone else’s, because I guarantee you that they are not.  As for anyone who happens to glance at your data: I hope they realize the same thing.

• Don’t Care About Market Share was published on Monday, December 20th, 2004.
• It was assigned to the Browsers category.
• There have been forty-one replies.

I just stumbled across a browser bug this evening that I thought you all might like to know about.  So we all know that IE6/Win supports text-align: justify, right?  Wrong.  Sorry, but it’s the truth: IE6 does not fully support text-align: justify.  True, it mostly supports that declaration, but if you apply said declaration to a caption element, guess what?  You get centered, non-justified text instead.  It’s very much as though, in the case of caption elements, IE6 replaces justify with center.

I just thought I’d pass this along in case it might help anyone else avoid some furious head-scratching.  And, I’m sorry to say, I don’t know of a workaround.  If anyone finds one, please leave a comment to that effect.

This is a perfect illustration of how difficult it is to do comprehensive CSS testing.  Every CSS support chart I’ve ever seen has marked down IE6 as supporting justified text; I mean, why wouldn’t they?  It clearly did so… for the specific test cases used to create that support chart.  The odds of a test page including a caption element are pretty vanishingly small, unless of course we’re talking about a test page that includes every single XHTML element in existence.  And to test every element known for every property-value combination… well, I’ve talked about that before.  No need to trample the same ground even flatter.

• Unjustified Caption Text was published on Wednesday, December 8th, 2004.
• It was assigned to the Browsers and CSS categories.
• There have been twelve replies.

While I was in Florida with my family visiting both sets of parents, Tristan Nitot published an article titled “How Microsoft can support CSS2 without breaking the Web“.  In it, Tristan points to a comment made by Gary Schare, Director of Windows Product Management at Microsoft, which was:

We could change the CSS support and many other standards elements within the browser rendering platform. But in doing so, we would also potentially  break a lot of things.

(from Microsoft Windows Exec Talks IE, Firefox)

Tristan then goes on to refute this line of thinking.  Generally speaking, I’m entirely in agreement with him.  (As a disclaimer, Tristan and I worked together as members of the Netscape Standards Evangelism Team, and Tristan asked me for feedback on his article before it was published.)

Here’s the thing: in the Windows world, Explorer already significantly upgraded its standards support four different times.  The most recent such upgrade was called IE6.  That was the version that first added DOCTYPE switching to IE/Win.  At that time, there were a great many changes made to the standards support, nearly every one for the better.  For example, in standards mode, you could no longer throw around unitless numbers and have them interpreted as pixels, because that violated the CSS specification.  You couldn’t set a height or width for an inline non-replaced element, because that too was incorrect.  The interpretation of font-size keywords was changed to reflect the CSS specification instead of the HTML font-sizing regime.  The box model was altered to follow CSS instead of the old IE way.  In short, there was all kinds of stuff in there that would “break a lot of things”.

The Web rather steadfastly declined to be broken.  Oh, sure, there were pages whose layout was altered—not many, thanks to the way DOCTYPE switching was implemented, but they were out there.  Anyone who was relying on the IE/Win way of doing things but used a DOCTYPE that triggered standards mode (say, for example, a HTML 4.01 Transitional DOCTYPE with URI) ended up with a “broken” page.  These problems were fixed by their authors, and that was that.  I remember a number of forum posts about how “IE6 broke my design”, and the posts that helped those authors address the problem.  In the case of old, unmaintained pages, they stayed broken, but odds are that next to nobody cared.  Regardless, it isn’t exactly a point of major concern on any radars I’ve seen in the last three years.

Furthermore, IE6 fixed a number of parsing bugs that existed in previous versions.  One of those was the bug on which Tantek Çelik’s “Box Model Hack” depended.  However, the parsing bug was fixed in both quirks and standards modes, so the BMH utterly failed to work in IE6 no matter what DOCTYPE you used.  That actually did break quite a few layouts, if I remember correctly.  I also remember the day I discovered that they’d fixed the parsing bug in both standards and quirks modes.  I swore at my monitor for a moment, and then actually thought about it.  I realized that the inconvenience of removing a few CSS hacks, or at worst changing to different hacks, was a pittance to pay in comparison to the advances IE6 had made in terms of increased standards support.

So I fixed a few style sheets, tossed a hack out of my mental toolbox, and got on with my life.  I contend that exactly the same thing would happen if a service pack were to add increased standards support to IE.

This is particularly true given that most of what IE should add would be, well, additions.  As in, things that IE doesn’t even try to support now, and so almost nobody uses them.  Think generated content.  Think attribute selectors.  Think fixed positioning.  These are all things that, if they were added to IE, would break almost no pages at all.  In fact, they’d make a small number of pages work better in IE.

For that incredibly small number of pages that would break (for whatever value of “break” you care to name) with improved standards support in IE6, I’m willing to bet that nearly all of them would get fixed right away.  Why?  Because they would be pages maintained by authors who actually want to use standards and care about doing things right.

Now, there is one area where I think the IE team would have to be careful about adding support, and that’s selectors.  A lot of hide-from-IE CSS hacks these days are based on its failure to support the child selector; in fact, I use these a few places in the S⁵ style sheets.  It is possible that adding support for child selectors to IE6 would be more harmful than beneficial.  I say it’s possible because I don’t know.  Nobody does—but Microsoft of all organizations has the ability to find out, and to act accordingly.  They have the funding, the personnel, the skills, and the customer base.  As Tristan said:

In its short, 2 1/2 year life, the Netscape Evangelism team helped  literally thousands of authors and administrators of web sites around the  world to improve their support for the W3C DOM and CSS Standards. If such a  small group with limited resources can help change the web, imagine what  Microsoft could do with its resources if it only tried.

Indeed.

Granted, the net stands still for no one, not even Microsoft.  There have already been, and continue to be, efforts to graft better standards support onto IE despite itself:  projects like PNG transparency fixes, whatever:hover, and IE7 take Microsoft’s proprietary behaviors and use them to make it easier to use open standards.  (I adore the poetry of that.)  The people behind those projects are already doing what Microsoft is apparently afraid to do, and they demonstrate why improving standards does not mean breaking the Web.

There’s one other point to consider.  If IE/Win improved its standards support in any meaningful way, believe me when I say that the news would be shouted from the Web site of every standards advocate in the known universe.  Nobody responsible for standards-oriented pages could avoid hearing about it.  Any problems would be quickly explained, and adjustments made.  Life would not only go on, but be better for developers and designers.

To sum up: the “more standards will break stuff” argument just doesn’t fly any more.  Microsoft can figure out what to do that won’t break pages, and there’s a ton of things that are new-to-IE, the implementation of which will no more break pages than did the image toolbar.  In cases that might cause breakage, Microsoft can determine—with community help, if they were to ask for it—how to minimize breakage while maximizing benefit.  To claim that possible Web page breakage prevents Microsoft from increasing standards support makes about as much sense as to claim that possible program breakage prevents them from ever changing or improving their operating system.

Despite this, I don’t have  much hope that we’ll see any improvements before Longhorn debuts.  I think that’s a shame, because I remember when the IE team was gung-ho about standards.  There were a number of very smart people who understood why standards were important, and were committed to doing their best to support standards in IE—not just on the Macintosh, but for Windows as well.

I do hope for Microsoft’s sake that those days return.  Because the Web continues to move, and if they just stand there promising that everything will be better in Longhorn, they may well find themselves left behind.

• Unbreaking the Web was published on Wednesday, December 1st, 2004.
• It was assigned to the Browsers, CSS, and Standards categories.
• There have been forty replies.

Since a few people asked for it, I’ve created a test file that reproduces the Internet Explorer freeze reported yesterday.  You can find it with the title “Internet Explorer Freezes — BEWARE!“.  If you follow that link with a non-IE browser, you should see a static copy of the “Ten Things To Do…” post, with two differences:

1. I stripped off the theme stylesheet so the masthead graphic isn’t shown.
2. I inserted a warning/explanatory comment near the top of the document.

Under the hood, the main difference is that the style sheets are all embedded in the document, so if you’re so inclined you can download that single page to your hard drive and fiddle with it to your heart’s content.  If anyone can narrow down this problem to a very minimal test case, I’d love to see it.  Refer back to “When Browsers Attack!” for notes on what I discovered.  There may well be more to the story, but if so, I didn’t find it.

I’ll reiterate the warning, in case it somehow wasn’t clear enough: iif you load this document in IE/Win, the odds are very, very, very high that it will freeze Internet Explorer, necessitating a force-quit of the application.  It may also crash Windows.  If you don’t want those sorts of things to happen to you, then don’t load the document.  Clear?  Good.

• Freezer Case was published on Friday, September 17th, 2004.
• It was assigned to the Browsers and CSS categories.
• There have been twenty-three replies.

Remember my recently posted conversation with Molly?  Boy, am I ever feelin’ that today.  In spades.

Some of you have noticed earlier today that things were presentationally unstable.  Depending on when you dropped by, you would have seen raw document presentation with no author styles at all, or some chunks of the site’s usual styles but not others, or all of the usual styles with a few oddities thrown on top for good measure.  For a few hours, during which I had to attend to something else, the site was fine except that in IE/Win, the main content column was quite a bit wider than usual, and some bits of content were visually exceeding the edges of the design box.  All that was happening because I was turning styles on and off in an attempt to stop freezing Internet Explorer for Windows.

Freezing?  Oh, yes.  As in locking it up so that people had to use the Task Manager to force-quit the process.  There were probably a few reboots out there as well; there were at least a couple here in Casa de Meyer.  Ordinarily, I’d apologize.  Not this time.  If you want an apology, try finding the person or persons responsible for IE’s CSS handling, and demand an apology from them.  I’m not taking the rap for this.

To set the stage, let me back up a couple of days.  As I passed by Kat’s office, she called out, “Hey, how come my browser keeps getting screwed up?”

“Because it’s Explorer,” I said.  “Next question?”

“Ha ha.  Seriously, every time I try to view your ‘ten things to do in Cleveland‘ post, the computer crashes.  I think there’s something wrong with it.”

Grumbling, I wandered over to her computer.  Sure enough, the browser was completely frozen.  She’d already called up the Task Manager and was forcing the browser to quit.  She said it was the third time she’d had to do it.  As I watched, the screen went blank, then drew the desktop color and stopped.  The cursor appeared as an hourglass, and refused to change or even move.

Once the system had gone through a hard reboot, I fired up Netscape 7 and loaded up meyerweb.  I surfed around to various posts.  No problems at all.  I then launched IE and loaded up the home page.  No problem.  I went to the offending post.  Instant freeze.

After a few more invocations of the Fatal Freeze, I wandered out of her office again, muttering about Explorer and Windows and pondering the possibility that her computer had been infected with some kind of virus, malware, or other nastiness.  But then, the next day, I got some e-mail reporting similar problems.  Then Ian Firth managed to get a comment in about the problem on the post “Really Undoing html.css“, even though others were getting the Fatal Freeze on that very post.  And he mentioned that it was happening in both IE and FeedDemon—which meant it was something in IE’s rendering engine, since FeedDemon just wraps itself around the engine.  A similar report cropped up in the FeedDemon forums this morning, where it was mentioned that a similar problem had already been seen in the post “Standards Savings“.  (Not that anybody had actually bothered to tell me, but hey, whatever.)

So I fired up VirtualPC this morning and tested the problem for myself.  And sure enough, I was very quickly the latest resident of Lockup City.  So I started narrowing down the cause.  I’ll spare you all the nasty details (and foul language) of my bug hunt, and cut to the chase: the lockup was happening on entry pages where the post content included an element that used left padding.  Blockquotes and lists were the prime triggers.  There wasn’t an absolute 100% guarantee of trouble, but it was close.  I could avoid the freeze by commenting out a single declaration in my main style sheet:

#main {
  margin: 0 15em 0 0;
  /* padding: 3em 4em 3em 4em; */
  border-right: 1px solid #AAA;
  background: #FFF;
  min-height: 30em;
}

That’s why the content was running rampant earlier today.  I had to leave that line commented out for a few hours.  But I knew that couldn’t be the real cause, because it didn’t cause freezes on the home page, or even on monthly or daily archive pages.  The freeze only happened on an individual entry page where there was a padding-indented element inside the content column.  Thus, the source was most likely to lie in style sheet that’s applied only to post pages.

So I started digging through my entry style sheet until I narrowed the problem down to this line:

.prev-next {margin: 0; padding: 0.25em 1% 0; 
  float: left; width: 98%;}

If I commented it out, and uncommented the padding declaration from before, there were no problems.  So the culprit lay somewhere in the .prev-next rule.  Anyone want to guess at the cause?  Go ahead.

Oh, all right, I’ll tell you.  It was float: left;.  As soon as I removed that declaration, the IE6 freezing problem just melted away.  So if you’ve encountered freezes while trying to view entry pages in the past, you shouldn’t any more.  (If you do, please comment on this entry with the exact browser and OS you’re using.)

The original point of the float statement was to get the unordered list to wrap around the floated list items within it, since floated elements wrap around floated descendants (for more details, see my article “Containing Floats“).  Since that was apparently a recipe for disaster, I modified the rule to read:

.prev-next {margin: 0; padding: 0.25em 1% 0; 
  width: 98%; height: 1em;}

It isn’t exactly the same as what I was doing before, but the result is close enough for now.

What else might I have done?  Well, in all honesty, I thought seriously about leaving things status quo and letting IE users go hang.  I don’t cater to potential crash bugs in NN4, for example; why should I make an exception for another browser?  But as I always knew I would, I grumbled a bit and then made an accommodation for IE.  I may one day restore the float for more modern browsers and use some sort of hack to hide it from IE/Win, but for now I’ll leave things be.

What’s odd to me is that the styles involved in triggering this problem have been in place literally for months.  If this was a problem, it should have arisen before now.  Yet the first I heard of this freeze bug was two days ago, and then all of a sudden I was hearing about it from multiple sources.  If I’d been updating my CSS, that would be understandable, but I wasn’t.  So what happened?  Did the installed Explorer population just get spontaneously and collectively buggier over the weekend, or what?  Is there a subtle worm running around adding bugs to IE’s rendering engine?  I’m really at a loss here.

As to why that particular combination of styles would cause IE to freeze up, I’m completely at a loss.  Not a clue in the world.

While I was mucking around in the CSS anyway, I decided to see if I could fix the rendering error in IE/Win that made the sidebar hang out over the vertical separator.  I did, so far as I can tell.  The problem there was the “Exploration” box and the styles I’d applied to it.  Apparently, if you set a form element to width: 95%; margin-left 5%; and then set a text input within that form to width: 100%;, it all adds up to something like 120%, or something.  So I did a little bit of a hack to hide the input element’s width value from IE/Win.  The input box won’t be as wide for IE/Win users, but as far as I’m concerned that’s an acceptable loss.

I hope your morning was substantially less frustrating than mine.

• When Browsers Attack! was published on Thursday, September 16th, 2004.
• It was assigned to the Browsers and CSS categories.
• There have been fifty-four replies.

There’s an aspect of document presentation most of us don’t consider: the browser defaults.  If you take an HTML or XHTML document—for the purposes of this exercise, assume it contains no presentational markup—and load it up in a Web browser with no CSS applied, there will still be some presentational effects.  A level-one heading, for example, is usually boldfaced and a good deal larger than other text, thus leading to the old stereotype of headings being “big and ugly”; the pre element typically honors whitespace and uses a monospace font; a paragraph is separated from other elements by a “blank line”; and so on.  From a CSS point of view, all this happens because the browser has built-in styles.

Tantek recently wrote about his creation of a file called undohtml.css, whose sole purpose is to strip away some of the default browser styles applied to common elements.  By resetting all headings to the same size, for example, he avoids the inconsistencies of heading sizes across browsers and brings everything to a common baseline.  If a different size is desired, the author has to do it manually.  (He should probably zero out the margins on headings as well, as those too tend to be inconsistent across browsers.)  He also zeroes out their margins, using a separate rule that I overlooked when I first posted.  Apologies to Tantek for my initial claim that he didn’t take that step.

Of course, Tantek isn’t really removing all the default styles, but (so far) just those that have given him the most trouble.  When it comes to Gecko-based browsers like Firefox and Mozilla, however, you can completely eliminate all built-in styles.  These browsers use a series of style sheets to control the presentation of documents, forms, MathML markup, and so on.  In OS X, you can find most of these style sheets by showing the package contents of the browser’s application file and navigating to Contents > MacOS > res.  On just about any other OS, it’s even easier; just search your hard drive for html.css and open the directory that contains that file.

If you look in html.css, you’ll find all of the styles that make what we think of as “unstyled” documents act the way they do.  Consider, for example:

area, base, basefont, head, meta, script, style, title,
noembed, noscript, param {
   display: none;
}

That rule is why the head element and all its contents don’t appear in your browser (as well as all those other “invisible” elements).  From a CSS standpoint, there’s nothing special about those elements as compared to others like div or ul.  The fact that they’re traditionally “invisible” is irrelevant—but with that one rule, the tradition is preserved.  You can always override the rule, of course; try style {display: block;} on a test document that contains an embedded style sheet and load it up in Firefox/Mozilla.  It isn’t magic.  It’s just a change from the usual way that documents are presented.  (See this test document for an example.)

There’s also:

/* nested lists have no top/bottom margins */
ul ul,   ul ol,   ul dir,   ul menu,   ul dl,
ol ul,   ol ol,   ol dir,   ol menu,   ol dl,
dir ul,  dir ol,  dir dir,  dir menu,  dir dl,
menu ul, menu ol, menu dir, menu menu, menu dl,
dl ul,   dl ol,   dl dir,   dl menu,   dl dl {
  margin-top: 0;
  margin-bottom: 0;
}

So in order to remove the top and bottom margins from nested lists, which is a traditional behavior of HTML browsers, that rule needs to be in the default style sheet.  Remove it, and nested lists would have top and bottom margins thanks to another rule in the style sheet:

ul, menu, dir {
  display: block;
  list-style-type: disc;
  margin: 1em 0;
  -moz-padding-start: 40px;
  -moz-counter-reset: -html-counter 0;
}

That rule not only sets the usual margins and such, but also includes some Mozilla-proprietary properties that help lists act in accordance with our expectations.  There are certain aspects of traditional presentation that aren’t (yet) fully describable using CSS, so the Mozilla folks have had to add properties.  In accordance with CSS2.1, section 4.1.2, these proprietary extensions are marked with a vendor prefix; here, it’s -moz-.  So any property or value you see starting with that string is a proprietary extension.  (For the record, I have no objection to extensions so long as they’re clearly marked as such; it’s the “silent” extensions that bug me.)

There is more to the presentation story than just html.css.  In the same directory, you can find quirk.css, which is applied instead of html.css when the browser is in “quirks” mode.  Another style sheet, viewsource.css, affects the presentation of any view source window.  All the nifty color-coding happens as a result of that style sheet, which is applied to automatically-generated markup that underlies the actual source you see.

So how do you completely strip out the default styles for an (X)HTML document?  Quit the browser application and rename the file html.css to something like html222.css.  Do the same for quirk.css.  Now re-launch the browser and find out just how much you’ve been taking for granted.  Feel free to browse around the Web and see what happens on various sites, but you’ll have to type blind, because the address bar won’t show any text.  You can still drag HTML documents on your hard drive into the window and see what happens.  If a document has any CSS applied to it, then the browser will use it.  It just won’t have any of the default styles available, so you’ll be applying your styles on top of nothing, instead of the usual foundation of expected presentation.

So what exactly is the point of all this?  As it turns out, I believe there are four:

1. By studying html.css, beginning CSS users can compare the rules to the “unstyled” presentation of documents, and thus get a much better idea of how CSS works.
2. By removing the default styles, you can come to a much greater realization of how much presentation is taken for granted, and how much there is to be dealt with when creating a new design.
3. On a related note, note that the absolute bare minimum presentation of a document is to render all elements with inline boxes, and to show every scrap of content available.  Even something as basic as making a paragraph generate a block box is a style effect.
4. It helps us to realize that what we often think of as the “special handling” of HTML is anything but: in Firefox/Mozilla, HTML documents are just a case of some markup that happens to have some pre-defined CSS applied to it.  Granted, the proprietary extensions needed to keep things in line with expectations are a case of special handling, and those tell us one of two things:
   • CSS still has a long way to go before it can be called a full-fledged layout tool, since it can’t fully recreate traditional HTML layout.
   • Old-school HTML layout was so totally wack, it’s no surprise that it’s hard to describe even with a tool like CSS at your disposal.
   I’ll leave it to the reader to decide which of those two they prefer.  Or, heck, choose both.  It isn’t as though they’re mutually exclusive.

Have fun fiddling with or completely removing the built-in styles!  Just remember: modifications like those described are made at your own risk, I’m not responsible if you do this and your hard drive vaporizes, no warranty is expressed or implied, not a flying toy, blah blah blah.

• Really Undoing html.css was published on Wednesday, September 15th, 2004.
• It was assigned to the Browsers and CSS categories.
• There have been sixty-six replies.

Excerpt from an IM session this afternoon:

Eric Meyer: Browsers– can’t live with ’em, can’t kill their developers.

Molly Holzschlag: well one could …

Eric Meyer: Okay, but not legally.

Molly Holzschlag: justifiable homicide?

Eric Meyer: Juries are notoriously unsympathetic to technical explanations.

Molly Holzschlag: you have a point

• Scenes From An iChat Window was published on Tuesday, September 14th, 2004.
• It was assigned to the Browsers and Humor categories.
• There have been four replies.

Thanks to a post over at Simon’s weblog, I discovered that the Mozilla 1.8a3 readme file tells us of some interesting CSS-related developments:

   
• Users can now disable CSS via Use Style > None or a global preference (bug 32372.)
   
• Mozilla now supports a at-rule for matching on site/document URL. Among other things, this makes site-specific user style rules possible (bug 238099.)
   
• Preliminary support for CSS columns has been checked in to Mozilla bug 251162.)

The middle of the three is what Simon wrote about, and it’s indeed very cool.  CSS signatures would never have been necessary if browsers had always supported per-site styles.  I’m not entirely thrilled about the syntax, but it’s a good start.  And for those who are wondering how I could support a non-standard extension, I’ve never been against them as long as they were clearly marked as such.  Microsoft’s extensions (behavior, filter, the scrollbar stuff) weren’t, which inevitably led to confusion.  The Mozilla stuff is marked in such a way that you can tell it’s an extension, and in a way that won’t conflict with future CSS.

I’m happy to see that Mozilla will finally let users easily disable CSS.  For those who need the text view, say because they have poor vision, it will be a welcome feature.  For those who want to quickly check the document’s unstyled rendering, it will be similarly useful.

But I’m most intrigued by the addition of “preliminary” support for CSS columns.  This would allow you to declare that a given element’s content should be flowed into columns, complete with auto-balanced heights and everything.  For example, if you wanted a list flowed into two columns, you could declare:

ul {-moz-column-count: 2;}

That would split the contents of every undordered list into two halves, filling the first column with the first half of the list and the second column with the second half.  Thoroughly awesome.  See the CSS multi-column layout module for more details, although I don’t know how much Mozilla actually supports at this juncture.

Update: it turns out that column support isn’t present in Mozilla 1.8a3, contrary to the release notes.  I’ve been told that it will be present in 1.8a4.

• Of Site Styles and CSS Columns was published on Wednesday, August 18th, 2004.
• It was assigned to the Browsers and CSS categories.
• There have been two replies.