Posts in the CSS Category

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.

Adam Bosworth recently gave a talk about simplicity in technology, and how it’s far more important to be simple and sloppy than complex and pure.  For the most part I agree with him; my first draft of XFN and FOAF was, basically, “FOAF is complicated.  XFN isn’t.”  While that was a flip way to amuse the reviewers, it also summarizes the core reason I took to XFN when Tantek and Matt explained it to me.  Making things easy is always preferable to making them hard.  As RFC 1925 so correctly states, “In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.”

There are two places where I’d like to take issue with Adam, however.  (And I hope it’s not presumptuous of me to call him “Adam” instead of “Mr. Bosworth”.)

The first is the idea that the Web should never be more complicated than plain old HTML.  Adam says: “I very much doubt that an HTML that had initially shipped as a clean layered set of content (XML, Layout rules – XSLT, and Formatting- CSS) would have had anything like the explosive uptake.”  This is absolutely common sense.  I think it’s also common sense that any truly popular and useful system starts out basic—’primitive’, if you like—and grows in complexity.  The best such systems hide the complexity from the end user.  Automobiles have gone from a few very basic controls (steering, acceleration, braking) to the mobile gadget factories we pilot today.  I still don’t have to know how the engine works to drive one.

So I absolutely agree that HTML caught on because it was simple.  It had to be, because there was nothing to shield us from the system’s innards.  When the popular Web was getting started, I did my best to promote its use by writing a trilogy of HTML tutorials (1, 2, 3).  My entire goal there was to make it easier for anyone to publish their own content.  Want to publish your grandmother’s Apple Pan Dowdy recipe?  More pictures of pets?  Bring ’em on!  They way I figured, if everyone published what they knew, the best information would slowly rise to the top by virtue of gathering more links.  Years later, Google built an empire around the concept of the best information being the most heavily linked.  Ah well, another fortune lost.

Even then, I did take the time to teach well-formed markup because I knew that malformed markup was likely to cause trouble.  This wasn’t an elitist thing, or some sort of far-reaching clairvoyance: at the time, it was possible to break browsers with incorrect nesting of inline elements.  So it only made sense to tell readers, “Hey, if you nest elements, make sure they actually nest instead of just closing them at random.  Otherwise your page might not get displayed.”  Eventually, browsers got more tolerant of sloppy markup, and those kinds of warnings weren’t really needed any longer.

So anyway, here we are ten-plus years later, and we’re still arguing about table layout and XHTML being lower-case and blah blah blah.  In the first place, table-driven layout isn’t simple.  It’s flexible and sloppy, but not simple.  The vast majority of table-layout authors have never touched a tag in their lives.  They’ve just told some tool “do this”, and it did it.  They don’t care how.  They shouldn’t have to care how.  So whether the tool generates 50KB of table-and-spacer markup, or 15KB of semantic markup with another 5KB of CSS, is wholly irrelevant to the user.  As it should be.

It is, however, relevant to those of us who ply the back end of the Web.  I’m not going to go over the arguments now; you probably know them, and know how you feel.  But my feeling has always been that once word processors stopped fighting over file formats, and got on to fighting over ease of use and features while all reading the same formats, that’s when word processing software took off.  I feel the same about the Web.

Now, I’m kind of a fan of CSS.  Have been for a while.  I like it because it lets the design (largely) happen away from the markup, where changes are easier, and it allows all kinds of stuff that HTML layout never managed.  (Two examples right off the top of my head: letter-spacing and border-style.)  I also like JavaScript and the DOM—not because they’re pure, but because they do what they need to do.  Inspired by the work of others, I put all those pieces together recently and created a lightweight slide show system.  It isn’t perfect, and because there are DOM actions it doesn’t always tolerate sloppiness, but it’s pretty simple.  Once editors exist to let people just point, click, and type slides (and I suspect that such editors may exist in the relatively near future), it will be even easier.  And the underlying format will not matter to 95% of its users.  Nor should it.

Anyway, this brings me round to the other thing I wanted to talk about.  Early in the talk, Adam says:

…in one of the unintended ironies of software history, HTML was intended to be used as a way to provide a truly malleable plastic layout language which never would be bound by 2 dimensional limitations, ironic because hordes of CSS fanatics have been trying to bind it with straight jackets ever since, bad mouthing tables and generations of tools have been layering pixel precise 2 dimensional layout on top of it.

First off, I think that Tim Berners-Lee might have a slightly different perspective on what HTML was intended to do, but let’s skip that.  The part I don’t get is the perception that “CSS fanatics have been trying to bind” HTML.  Personally, I’ve been trying to free Web design from the limitations it’s long experienced.  I’ve been working in that direction for years now.  I won’t argue that the job is finished: far from it.  But a big reason I’ve long been an advocate of using CSS is that it loosens the straightjacket, not tightens it.  The work I did within the context of the CSS Working Group was intended to loosen the bonds even further.

Maybe that means I don’t meet Adam’s definition of a “CSS fanatic”, I don’t know.  Maybe I’m not one of the “hordes” of jackbooted geeks, seeking to impose my tyrranical notions on the unwashed.  Either way, this does bring me to the question I want to ask:  where does this perception come from, that CSS is promoted a way to make the Web harder and HTML more difficult?  I’m not trying to belittle the idea by asking; I’m genuinely curious, and a little dismayed.  I know I’ve worked very hard to clearly describe what’s good and bad about CSS, just as I have about table-based design.  I’ve put a lot of effort into helping people who want to learn CSS do so, and explaining to those who ask why I think using CSS is a good idea.  Most of the other CSS advocates I know have done the same.  What is it that we did or didn’t do that got across this idea of inflexibility, or intolerance, or just plain elitism?

Because when you get right down to it, I’m still all in favor of people putting their stuff up for the world to see.  These days, I’m also in favor of making it easier for everyone else to see that stuff, and for tools to collect and analyze that stuff.  Standards make that easier—CSS makes that easier, although not as a standalone savior, but as part of a mosaic.  If someone as well-regarded and experienced as Adam Bosworth doesn’t see that, then I can’t help but feel there’s been a failure to communicate.

• Simplicity Where It Counts was published on Monday, November 22nd, 2004.
• It was assigned to the (X)HTML, CSS, and Standards categories.
• There have been twenty-eight replies.

At long last, I’ve published a new article at Complex Spiral: “Uncollapsing Margins“.  In it, I explore how margin collapsing can lead to weird behaviors, why these behaviors arise, and ways to work around it when you want a different result.  If you’ve ever tried to figure out why a heading’s top margin seems to disappear when it’s the first thing in a div, this article will be of interest.

Oh, and if you were having trouble reaching meyerweb in the last 24 hours, we done got Slashdotted.  They posted an article about S⁵, and the ensuing geek stampede crushed my bandwidth like it was an overripe grape.  An overripe grape run over by a steamroller.  Once the article fell off the Slashdot home page, things got back to normal.

• Uncollapsing Margins was published on Wednesday, November 3rd, 2004.
• It was assigned to the CSS category.
• There have been two replies.

I was recently honored with a request to contribute to Design In-Flight magazine, and so the latest issue contains a piece titled “Stripped Down Style”.  The article is an expanded version of Really Undoing html.css, accompanied by some screen shots and containing a copy of Tantek’s undohtml.css.  The magazine also includes an article from Jon Hicks about his icon design process, focusing on the icons he’s created for NetNewsWire 2; a piece from Keith Robinson on public speaking; a how-to guide for mapping out the structure of your style sheets by Yasuhisa Hasegawa; and a good deal more.

It does cost a few bucks to get a copy the magazine, but they really are a very few—certainly several less than you’d spend on a comparable magazine in print.  You can also get a yearly subscription of four issues for ten bucks.  Having read the first two issues of the magazine, I’m definintely feeling an urge to subscribe.  Editor Andy Arikawa has proven a master at pulling together some great content from interesting authors, and at covering a diverse set of topics.

I must also admit to some amusement at how the title of this issue, “Not Your Father’s CSS”, echoes (most likely coincidentally) the title of my radio show.

• Stripped Down Style was published on Sunday, October 17th, 2004.
• It was assigned to the CSS and Writing categories.
• There have been no replies.

You probably know that I’m a long-time Macintosh user, going back to the days of the single-floppy Mac SE.  At one point, I worked in a computer lab that had a “Changing the world, one person at a time” poster on the wall.  Every single one of my books, articles, and other resources has been written or developed on a Mac.  So you can imagine how thrilled I am to be featured in an Apple Pro article.  Not only can you find out a little bit about how I got into this whole CSS thing, but see a picture of me dropping some fat horns on my listeners.

I’ll put this Pro file on the shelf with being made a comic strip character as “ways to know I’ve really made it”.  But you know what really told me I’d arrived?  Discovering that someone had created a Wikipedia entry about me.  It was a pretty stubby page at the time, but its mere existence was enough to drop my jaw into my lap.  Now I find myself wondering if I should edit my own entry to include a full biography and related links, or if that would in some way be incredibly gauche.  (And asking someone else to do it for me would just be gauche by proxy, which is worse.)

It’s an odd thing to be famous, even when the fame is limited to a specific field of activity.  As a matter of fact, I was recently asked to write an article about the “fame game” and I’m still mulling over how to tackle it.  See, when you get right down to it, being well-known is both a reward and a restraint.  When people look to you, there’s a certain set of expectations that gets imposed upon you, whether you want them or not.  You’re supposed to always be right, always be fair, and always be in agreement with whoever’s looking to you.  None of these things are possible.

Nevertheless, I am where I am because I worked to get here (and was lucky), and I’ve no real complaints about the position I occupy.  All told, it’s not a bad thing.  It isn’t even a good thing.  It just kind of is.

So there’s still the question of what I might write about the “fame game”.  As it was posed to me, the editor was interested in my thoughts on “how influential designers and developers must balance ‘responsibility’ to the community with their own need to say what’s on their mind and use their clout to get good things done”.  In many ways, it’s the classic “how do you feel about being a role model?” question.  I’m not entirely sure I’m qualified to answer the question, although I do have some ideas.  I often wonder what the community thinks, though.

So I’ll throw it out to you lot: in your personal opinion, how should influencers balance community responsibility with personal expression—or does there need to be a balance at all?

• Finding Fame and Fortu—Okay, Just Fame was published on Monday, October 4th, 2004.
• It was assigned to the CSS, Interviews, and Personal categories.
• There have been twenty-two replies.

Having talked about how to completely rip away all brower default styles in Firefox, let’s consider the bare minimum of styles we’d need to make the Web at least moderately readable.  As it turns out, the primary factor in document mangling caused by taking out the browser’s default styles is the loss of any display information.  In the absence of information regarding what kind of box an element should generate, they’re all made to generate inline boxes.  This is roughly equivalent to saying:

* {display: inline !important;}

Speaking of which, feel free to try that some time on a test document, or as an entry in a browser’s user style sheet.  The result should remind you of the no-defaults trick.

So let’s say we back up the browser’s default style sheets (you don’t want to lose them completely, unless you plan to re-install the browser) and then erase everything in html.css.  Having done that, we can restore a great deal of sanity to the Web by placing the following rules into html.css.

@namespace url(http://www.w3.org/1999/xhtml);
  /* set default namespace to HTML */

html, body, p, div, h1, h2, h3, h4, h5, h6,
ul, ol, dl, dt, dd, blockquote, address, pre,
listing, plaintext, xmp, menu, dir, isindex, hr, map,
multicol, center, frameset, marquee {display: block;}

li {display: list-item;}

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

table {display: table;}
caption {display: table-caption;}
tr {display: table-row;}
col {display: table-column;}
colgroup {display: table-column-group;}
tbody {display: table-row-group;}
thead {display: table-header-group;}
tfoot {display: table-footer-group;}
td {display: table-cell;}
th {display: table-cell;}

That rule set will not only cause block-level elements to start generating block boxes again, but it also lets list items be list items, hides the elements we’d like to have vanish, and restores table behavior to table markup.  With those few rules in place, browsing around will be much easier.  It might not be pretty, but it will avoid the extreme wreckage of removing all default styles.

There will still be some notable differences.  For example, paragraphs may now generate a block box, but they aren’t being given margins, so on most sites paragraphs will suddenly not have a “blank line” of separation.  Similarly, heading margins are gone.  Lists don’t have any predefined indentation.  Table cells don’t have default padding, and the “gutter” around page contents has vanished.  Of course, you might see some or all of those things on a site.  If you do, it means that information has been provided by the site’s styles.

In a quick browse of the Web, I found that CNN‘s site was still kind of scrambled by these styles, though certainly not as badly as before.  As an example, a lot of the article sidebars and pictures weren’t floated, which means the float behavior is markup-driven, not CSS-driven.  Why does it matter?  Because in Firefox, align="right" is just a markup hook on which the default style float: right; gets hung.  If that declaration doesn’t appear in the default styles, the markup will have no visible effect.  In other words, no floating.

The home page of The Mozilla Foundation, on the other hand, hung together pretty well, which indicates all of their layout is driven by CSS instead of presentational markup.  This didn’t come as much of a surprise, but it was nice to see.  I was pleased to find that meyerweb’s home page also stayed in decent shape.

So should you add these rules to your style sheets?  Not unless you’re feeling extra-super-mega-paranoid.  The percentage of visitors displaying your site with the default style sheets removed can be safely estimated to very closely approach zero, maybe even touching it.  Besides which, if someone does drop by with all default styles removed, they’ve probably done it on purpose.  If they then send you snarky e-mail about they broke your site that way, feel free to answer them with a polite acknowledgment that they did, indeed, successfully cut their own throat.  It’s not like that’s your problem, any more than you should be bothered that someone “broke” your site with an anarchic user style sheet that suppresses display of lists and paragraphs, or sets all non-replaced elements to use white text on a white background, or whatever.

A more interesting question is whether you should set up a browser to use just those rules as defaults.  I’m giving serious thought to maintaining two copies of Firefox: a normal install, and a development install that’s been hacked to use just the styles I listed before.  It could prove valuable in checking the design assumptions of a work-in-progress, and thus to identify possible weak points in the author styles.  As an example, if I loaded a new design into the development browser and found that lists were completely non-indented, then I’d know I was leaving the list indentation distance up to browser defaults.  At that point, I could decide whether or not that was a good idea.  In some designs, it might be fine, but in others it could be a problem.  Either way, I’d have the chance to consider that question directly, and reach a decision, instead of sailing blindly on, never having thought about it either way.

• Fractionally Restoring html.css was published on Monday, September 20th, 2004.
• It was assigned to the CSS category.
• There have been ten replies.

I was just recently asked if attribute selectors must use quotes around the value.  In other words, are both the following two selectors legal?

a[href="http://www.meyerweb.com"] {font-weight: bold;}
a[href=http://www.complexspiral.com] {font-style: italic;}

“No, they’re optional,” I said with assurance.  And then the doubts started to gnaw at me.  What if they actually weren’t, which might make sense given that you can require the exact match of a space-separated list of attribute values? By this, I mean that if you declare:

div[class="this is a test"] {color: orange;}

…then the selector will match any div element whose class attribute is exactly this is a test, in that order, and with nothing else in the attribute value.  Or so I’ve always been given to understand.  In that case, if you left off the quotes, couldn’t that somehow be confusing to the browser?  Maybe not, but it still bothered me.

So I went digging through CSS2.1, Appendix G and found the grammatical definition of an attribute selector.

attrib
  : '[' S* IDENT S* [ [ '=' | INCLUDES | DASHMATCH ] S*
    [ IDENT | STRING ] S* ]? ']'
  ;

You all understood that, right?  Uh-huh.  Me either.  (This is one of those hostile-to-outsiders posts I mentioned a while back.)

I never liked grammar in school, and I still don’t, but it is sometimes sadly necessary.  So here goes.  When you run down the definitions of the all-caps words (I think those are tokens) you find that IDENT is an identifier, which is sort of a catch-all bin for things like selectors, property names, values, and such.  Fine.  STRING, on the other hand, is a collection of symbols and other fun stuff, again including the non-ASCII range but not the ASCII range.  But then it includes the entirety of Unicode.  I’m not sure how much sense that makes, but whatever.

So the whole point of this is: if quotes around an IDENT are optional, wouldn’t it have made more sense to say this?

attrib
  : '[' S* IDENT S* [ [ '=' | INCLUDES | DASHMATCH ] S*
    [ STRING? IDENT STRING? ] S* ]? ']'
  ;

Or even:

attrib
  : '[' S* IDENT S* [ [ '=' | INCLUDES | DASHMATCH ] S*
    [ '"'? IDENT '"'? ] S* ]? ']'
  ;

It’s the [ IDENT | STRING ] from the original definition that has me befuddled.  It seems like it’s saying you can include an IDENT or a STRING but not both, and since IDENT doesn’t include quotes, that implies that you can either drop in an identifier, or a string with quotes.  Why is this a good idea?  Does it mean that any identifier has to be unquoted?  Does it mean that there’s no practical distinction between a STRING and an IDENT in this situation?  Does it mean that quotes prevent the inclusion of anything useful?  Somebody let me know.

• Grammar Question was published on Saturday, September 18th, 2004.
• It was assigned to the CSS category.
• There have been sixteen 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.