Posts in the CSS Category

Adam Kalsey shares a method for rounding corners that has minimal HTML impact.  I explored the same basic concept (along with several others) in Project 10 of Eric Meyer on CSS, although in my case I used it to provide rounded corners between two differently-sized sections of a document; sort of the visual inverse of what Adam demonstrates, but using the same fundamental techniques.

It’s always interesting to see ideas emerge in different places, mutate, evolve, advance, and generally act like they have a life of their own.  Did somebody say “meme?”

The thing is, of course, that we’d be better off not having to hack in bits of HTML just to get these effects.  CSS3 offers proposals for corner-rounding properties, and that’s a good step forward.  One can also use XBL to dynamically insert the needed bits and style them, without having to clutter up the source document.  Here’s my XBL-based recreation of Adam’s demonstration.  Now here’s a variant employing more complex corner and border effects.  And then there’s blockquote styling with great big background quotation marks and rounding of some corners.

The above examples will only work fully in Gecko-based browsers (as of today, anyway), but what’s interesting to note is that they don’t look bad in non-Gecko browsers.  Take the blockquote example, for one.  In a Gecko browser, you get all the eye candy.  In a non-Gecko browser you get a visually distinct blockquote with less eye candy.  It still looks pretty good, or at least not bad; it could probably use some padding, but these aren’t polished examples.  The document structure is clean, and semantically appropriate.  What’s not to like?  This seems like another aspect of the concept of graceful flexibility—or, if you prefer, progressive enhancement—and one worth further investigation.

• Rounding A Corner was published on Friday, July 25th, 2003.
• It was assigned to the CSS category.
• There have been no replies.

I don’t think I mentioned this before, but there’s an aural-CSS supporter besides Emacspeak out there.  It’s called Fonix SpeakThis, and while its aural CSS support is pretty limited, it does exist.  (A tip of the hat to The Literary Moose, by the way, for passing along the information.)  I find the existence of another aural-CSS browser, however limited, to be interesting in light of the aural style sheets appendix of CSS2.1, which says in part:

We expect that in a future level of CSS there will be new properties and values defined for speech output. Therefore CSS 2.1 reserves the ‘speech’ media type… but does not yet define which properties do or do not apply to it.  The properties in this appendix apply to a media type ‘aural’, that was introduced in CSS2. The type ‘aural’ is now deprecated.

In other words, aural is a dead end, and speech will be used in the future.  At some point.  Really.

Fans of complexspiral‘s visual groove might also appreciate Atlantis, which looks a whole lot more professional.  As is to be expected.

Raffi Krikorian raises some long-term problems arising from URL-shortening services that are worth pondering.  It isn’t the case that absolutely everything has to be preserved for all time, but how many links would suddenly break if a popular shortening service disappeared?  I already don’t like such services because they hide the ultimate destination, which robs me of an important piece of information in my quest to decide whether or not I should follow a given link.  How many times have you seen a post that says, basically, “This is interesting!” followed by a shortened link?  It could be a political story from the BBC, a collection of Battlestar: Galactica fan fiction, the official site of the Malaysian legislature, or an outrageously disgusting fringe-porn site.  How can you tell?  By following the link.  It’s like Web roulette.  Place your bets!

I guess it’s also true that shortening services irk me because they should be utterly unnecessary.  In the first place, there’s almost no excuse for URLs to be so long that they need some kind of shortening service.  Okay, maybe mapping programs have some excuse, but that’s about it.  The kind of enormous cryptic URLs that most database-driven sites generate is just sloppy and wrong.  In the second place, as for putting URLs in e-mail and newsposts, you can contain the URL in angle brackets—<http://like.this/>—and any client worth running will understand that the whole string is a single URL, and ignore any line-wrapping that might occur within the brackets.  If your program can’t handle that, especially if it tries to interpret the bracketed text as an HTML tag, then it’s time to get another one.

Incidentally, the title of today’s entry is a hand-shortened form of “Speech, Shells, and Shortening.”  Which is better?  Granted, it’s kind of cool having an entry title that sounds like a door on Star Trek, but it isn’t what I’d call particularly useful for determining the contents of the entry before you actually read it.  See what I mean?

• SpShSh was published on Wednesday, July 23rd, 2003.
• It was assigned to the CSS and Tech categories.
• There have been no replies.

Apparently I’m a desirable emigrant.  In response to yesterday’s comment-in-passing that Kat and I had been kicking around the idea of moving to another country, I’ve had three people write encouraging me to emigrate to Canada, and one other person recommend the United Kingdom.  The Canada people actually make a pretty good case, since apparently there’s a plan afoot for Canada to make the Turks and Caicos Islands their eleventh province.  That sounds pretty sweet, even if I would have to spend the whole year encased in zinc oxide.

Personally, I’ve always liked Toronto as a city.  Their weather isn’t significantly different than what we experience here in Cleveland, plus I know a number of very cool folks who already live there.  I can’t comment on places in the UK, since I’ve never actually been there (although I hope to fix that within the next year or so).  For the record, the country we had in mind was Norway.  I also gave some thought to the Bahamas, but then we’re back to the prospect of me resembling a lobster on a semi-continual basis.

There’ve been a whole lot of XHTML-and-CSS redesigns announced in the past ten days, and I’ve been remiss in pointing them out.  Here’s a list of the ones I noticed: The Open Championship, Quark, Message Digital Design Ltd., Phish.com, Lawrence, Kansas Weather, Adaptive Path, and Inc.com.  There were some others, I think, but the URLs seem to have escaped me.

On that last one, Dan talks a bit about the particulars of the Inc. redesign, and Doug points out that the markup size reduction for Inc.com’s redesign was just about the same as that for the redesigns of Adaptive Path and Wired News.  I’ll add that it’s very close to the markup size reduction seen when ESPN.com redesigned.  So yes, Doug’s absolutely right: there’s a trend here.  Old-school table-and-spacer designs can be visually recreated using lean, structural markup and CSS, and the process cuts page size by about half.  Some sites will see less savings, but some will see more.  As an example, my off-the-cuff guess (having peeked at the source of a typical page) is that eBay could drop its page weight by 66% or so.  They could probably reduce their annual outgoing bandwidth by several petabytes.  Tell you what, eBay: I’ll show you how to do it and do it right, and you can pay me five percent of your savings over the next five years.  Deal?

• Moving and Shaping was published on Friday, July 18th, 2003.
• It was assigned to the CSS and Personal categories.
• There have been no replies.

Chris Hester wrote earlier to point out the CSS2 Test Suite’s main page was completely unreadable in Internet Explorer 6 if you had the “Text Size” set to “Smaller.”  This was news to me; I’d set my text to “Medium” the day I installed IE6 and never looked back.  So I went to the page, changed my text size, and winced.

The problem’s since been worked around, but to see the problem as well as read about the trigger and the solution, try this testcase.  Note that if you’re using IE6 and your browser is set to “Smaller” the testcase will start out completely unreadable.  Set it to “Medium” first and then go to the page and follow the directions.

The flaws in IE6 continue to amaze me, and now we’re stuck with it for another three years, minimum.  Great, just great.

Dave Hyatt recently made some observations about standards-support charts (starting with Standards Charts and continuing into three posts the next day).  I agree with most of what he has to say, actually.  Charts like the “master grid” are by their nature coarse.  They can do no better than provide support information for whichever tests the chart author happened to run.  In presenting an overview and comparison of CSS support, for example, depth-of-implementation testing is sacrificed.  It has to be.  The CSS support charts I published on Web Review for years, and now on DevEdge, are basically the work of one person: me.  I wrote most of what became the W3C’s CSS1 Test Suite in the creation of the original charts, back in late 1996 and early 1997.  Back then, it was easier—bugs were more obvious, and all implementations were shallow.  The charts could afford to be as shallow.

Now, thanks to years of experience, implementations are getting much, much better, and the bugs harder to find.  To fully test modern CSS implementations requires a far more complex set of tests than I could author in a lifetime of evenings (which is when I wrote the tests and the charts).  To be really comprehensive, you’d need to test every property and value combination on every element in HTML (or a markup language of similar complexity), which I think was once calculated to run into a few trillion combinations.  It’s a lot harder to create tests, to run tests, and to chart results than it used to be.  This fact was driven home to me recently as I worked on (finally!) updating the CSS charts.  For the tests I have at hand, most browsers score perfectly, or close to it.  I know that’s not true: every browser has bugs in its CSS support, some worse than others (*cough*WinIE*cough*).

(Aside: I feel either amused or gratified that there’s support for the concept of penalizing browsers for having bugs, a concept I used in compiling the “CSS leader board,” back in the day.  “Full” support earned a point, partial support got half a point, no support got zero, and a bug lost you half a point.  It was a touch crude, perhaps, but it worked.)

But I only have so many hours in every day, the same as anyone else.  It’s not reasonable to expect one or even five people to meet this challenge.  The only way to handle it is to find a moderately large crowd of CSS experts, all of whom trust the others completely, and distribute deep-test creation among them.  In a few months, they may have gotten far enough to run browsers through their tests.  A month or so after that, they could start compiling results, and eventually publish them.  But even assuming all of that data could be collected and presented, how useful would it really be to the Web community?  One of the keys to the original CSS support charts’ success was that they were easy to comprehend: their very shallowness made them useful.  Authors don’t have time for much more.

Implementors have different needs, of course.  If those needs are strong enough, they’re going to need to fund positions (and I do mean more than one) to coordinate the work necessary to fulfill their needs.  The money could come out of the Quality Assurance budget, even.  In any case, if standards support testing is a serious problem, then we’ll need a serious commitment to address it.  Who’s going to step up to the plate?

• Testing for Flaws was published on Tuesday, June 24th, 2003.
• It was assigned to the Browsers, CSS, and Standards categories.
• There have been no replies.

I’ve been trying to catch up on e-mail.  Astonishingly, after only a couple of days of sustained effort, I’ve managed to get to the point where I’m only two weeks behind on my Inbox!  This is to a large degree because I’ve been sending out terse responses, for the most part, and pointing people to css-discuss in case they need more help.  Out of the 300 – 400 messages that arrive every day, once I strip away the listserv traffic and ditch the spam, I’m generally left with anywhere from three to twenty pieces of mail sitting in my Inbox.  The average is somewhere just below ten.

So if you’re thinking about asking me for help with understanding CSS, my best advice is to go join css-discuss.  As much as I love to help people out, you’re more likely to get much quicker and more complete answers from the community than from me, especially this summer, which is shaping up to be one of the busiest of my life.

As if in answer to all of my past grumblings about XSLT being all icky and bloated and clumsy, Simon brings word of the Parsimonious XML Shorthand Language (or PXSL, pronounced “pixel”).  This language basically turns XML syntax inside out, introduces indentation sensitivity, and ends up with a smaller and much less cluttered language.  Consider this example, which I nicked straight from the PXSL documentation:

<xsl:template match="/">
  <xsl:for-each select="//*/@src|//*/@href">
    <xsl:value-of select="."/>
    <xsl:text>&#10;</xsl:text>
  </xsl:for-each>
</xsl:template>

Here’s the PXSL version:

template /
  for-each //*/@src|//*/@href
    value-of .
    text <<&#10;>>

Okay, maybe not as compact as I would like, but it’s still a lot better than the XSLT version.  True, it still has to use XPath, so the line-noise quotient isn’t as close to zero as it should be, and it won’t do anything about the template-nesting rules XSLT imposes for no apparent reason.  It is also true PXSL is dependent on indentation and that never makes me happy, being a veteran of BASIC (where there was no indentation), PASCAL (where it didn’t matter), and HTML (ditto).  If I were programming Python already, I probably wouldn’t bat an eye, but guess why I’m not programming in Python?

The fascinating part to me is that, if you dig far enough into the document (which isn’t actually all that long), PXSL was originally designed “to reduce the verbosity of XSLT stylesheets.”  Ay-men, brother!  I do have to wonder about its whitespace handling, though.  Fortunately, when I’m ready to learn more I can find out about it via the PXSL Community site, which employs both XHTML and CSS for layout, including a styled unordered list to set up the navigation.  Most excellent.

What a great way to start a week!

• Reduced to Efficiency was published on Monday, June 23rd, 2003.
• It was assigned to the CSS and XSLT categories.
• There have been no replies.

Ever have the feeling that you’ve seen a site somewhere before?  It happens to me on occasion, and this morning e-mail hit my Inbox pointing me to the Web site for The Clasby Family, which looks darned familiar.  In case something changes, here’s a screenshot of the site, and a shot of a similar one.  Actually, all but one of its themes look really familiar for some odd reason.

How did I find out about this?  Someone e-mailed me to mention that the designer for clasbylife.com had posted a forum question about Opera’s rendering of the themes.  I read the post and was amused to find it was the exact same problem I hit back in February, and explained the situation in some detail in a site post.  So it turns out the source of the problematic styles is also the source of the explanation.  Funny!

For the record, I’m not really upset by this, although it would have been nice if I’d been asked about the use of the images, since some of them are my original works (those in “Natural” in particular).  One really good way to learn CSS-driven design is to snag a local copy of someone else’s design and take it apart.  Then put it back together in your own way.  clasbylife.com seems to have that underway, with a new theme that looks to be a mutation of “Natural.”  If grabbing a copy of something I’ve done help a designer understand CSS a little better, then I’ll be the last to complain.  More power to you.  Feel free to use them yourself, as long as they’re used for non-profit or educational purposes.  No charging other people for my designs, though!  I really have to get around to explicitly branding these things with a Creative Commons license so it’s all clear.

Anyway, as the new stylesheets note in fairly obvious comments, some of the images I use belong to me, whereas some came from other sources.  That won’t stop people from copying them, but at least I’m providing fair warning (and credit).

• Mirror Life was published on Tuesday, June 17th, 2003.
• It was assigned to the CSS category.
• There have been no replies.

Yesterday, Jeffrey Zeldman was nice enough to point people toward meyerweb’s redesign, and also to say some kind words about yours truly that he’ll probably regret some day.  I know I have already, because when goofy rendering errors were reported in IE6/Win, I kind of felt obligated to do something about them instead of just shrugging and saying, “Eh, not my problem.”  Curse you, El Jefe!  I shall be revenged!

Two days ago, I got an e-mail message that had me falling out of my chair, I was laughing so hard, and I simply can’t resist sharing it with you.  I’ve edited the text a bit for clarity, and the name has been removed to protect—well, the guilty, really.  In a legal sense, I mean.

I’ve spent some time reading and working with several CSS books….  and I have to tell you that Eric Meyer on CSS is the best…. if I want to know how to do something and refer to the pile of books near my left hand, it is the one that most easily produces the answer.

It has one other great advantage over all the others as well:  it is by far the best book to roll a joint on.  Shape, size, thickness, glossiness, flexibility, and color are all excellent and [far] ahead of the competition.

It’s amazing how a well designed book serves all purposes.

Well.  Glad I could help out.

A day or two before that fascinating bit of e-mail arrived, I was standing in clothing store located in a brand-new shopping mall just recently built a couple of miles from our house, when the following lyrics came over the store speakers:

Don’t it always seem to go That you don’t know what you’ve got till it’s gone? They paved paradise and put up a parking lot.

…and I thought to myself, “Is someone trying to be ironic?”

• We Live To Serve was published on Wednesday, June 11th, 2003.
• It was assigned to the Books, CSS, Humor, Redesign, and Writing categories.
• There have been no replies.

Yep, I finally did what I’ve hinted at for some time now and updated the site design.  Behold: Eos.  It’s sort of an in-joke, one that I would expect exactly four other people to get straightaway, along with perhaps a few others who happened to see the pictures.  Checking the styles might help those who are really curious to unravel the mystery, but trust me, it’s not really that interesting if you weren’t there in the first place.

So anyway… the new design is based around positioning, as opposed to the old one, which was based on floats.  The underlying structure of the site has barely change, with one exception.  The navigation/presentation portion of the pages is now found at the end of the document, instead of the beginning.  This seems more accessible to me.  If you want to see what the raw, unstyled page looks like, pick the theme “void(style);” from the menu.

Note that not every theme is guaranteed to work in your browser.  I stuck to the CSS standards as much as possible, and I did do cross-browser testing.  This uncovered some weird whitespace-sensitive bugs in some browsers.  It also showed that not every technique works well in all browsers.  I’m open to hearing about workarounds for broken displays in browsers, should you find them, so long as they’re based on standard CSS and don’t break the display in too many other browsers.

A few other notes:

• Unlike the old design, the new themes are intended to have notably distinct layout approaches.  Almost all of them put the sidebar on the right, but that’s just because I prefer righthand navigation.  With the old themes, each one was basically a different set of colors and backgrounds for the same layout.  This time, I wanted to be a little more original.  I’d credit the CSS Zen Garden with prompting this, but I’ve been slowly working at this change since last fall.
• The cookies that store the theme name and base text size (if you change it) changed their names to be a little more verbose.  You can of course deny said cookies; the site will be completely navigable without them.  The theme switcher won’t work, that’s all.
• Only one of the themes uses pixel-sized text: “Classic MW.”  Since the theme is intended to reproduce the old design as closely as possible, I figured I’d leave its 11px baseline text.  You can always override it with text-zoom features, or else on the advanced setup page, like before.
• Some themes use ems or percentages to set the body element’s text size to be smaller than the user’s default.  I did this to prevent the sans-serif fonts employed in those themes from looking stupidly big in default browser installs.  If you object to this approach, then pick a theme that doesn’t override text size—the default theme, “Eos,” is one of these—or set your preferred base text size on the advanced setup page.  Or both.
• When switching from one theme to another, you may run afoul of bugs in various browsers that let styles leak from one theme to another.  If you see a totally horked display, reload the page to see if that fixes it.
• Although I was tempted, I didn’t end up using any PNGs to create the translucency effects in various themes.  I didn’t use background-attachment: fixed, either.  It was a lot more challenging to figure out ways to let IE/Win users see the translucent effects with scrolling backgrounds and regular old JPEGs.  I may write a tutorial on how I managed this, but anyone who can’t wait is free to tear into my CSS and figure it out for themselves.  And to copy the technique, if they so desire.
• Despite it not being the default theme, I think my favorite is Aware.  The name is not necessarily the English word meaning “having knowledge or cognizance,” but is instead a Japanese word meaning “the sense of poignant beauty arising from an ephemeral thing.”  Since I think the latter is only possible with the former, I find this to be a wonderful intersection of cross-linguistic meaning.  Thus you can take the title to mean whichever of the definitions appeals to you most.  For me, it changes back and forth over time.

There may be adjustments to the themes in the future as I find techniques I like better, or as I fix up oddities in and add extra visual frosting to the more experimental themes (like “Matrix”).  Meanwhile, please feel free to share and enjoy.

• Eos Rising was published on Tuesday, June 10th, 2003.
• It was assigned to the CSS and Redesign categories.
• There have been no replies.