Posts from June 2003

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.

Just some fair warning: meyerweb may be sporadically offline over the weekend, as my hosting provider (the incomparable gang at The Opal Group) switches locations, upgrades services, and that sort of thing.  So if you drop by and don’t get a response, try again later.  In the meantime, go for a walk, plant a tree, or scratch a puppy behind the ear.  They really love that.

It’s already the last third of June, and what I want to know is this:  how did so much of the year disappear so quickly?

• Now You See Me… was published on Thursday, June 19th, 2003.
• It was assigned to the General category.
• 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.

The presentation and example files from TODCON MX in Las Vegas last week are now available via the Talks page.  Thanks and apologies to those who waited; it took me a lot longer than it should have to get these online.

• TODCON MX Talks Available was published on Monday, June 16th, 2003.
• It was assigned to the Speaking category.
• There have been no replies.

I would have posted about this yesterday, but frankly it was too depressing.  As others have noted, Internet Explorer for Macintosh is, effectively, done.  There will not be another major version: I’ll never get to write about CSS support in IE6/Mac, because there won’t be one.  As I said on Webdesign-L yesterday, and Zeldman quoted in part, I said:

[The IE/Mac team] was truly committed to the best standards support they could muster while working for a corporation that did not always share their ideals.  I wish everyone on the IE/Mac team the best of luck in their future projects, whatever they may be.  They not only paved the way for many of the things we now take for granted, but they fought the good fight, fought it hard, and in many respects they emerged victorious.  It’s tough to imagine a better legacy than that.

I was a beta tester for IE5/Mac, and it’s long been a favorite of mine.  There may be some personal bias stemming from the fact that I know bug reports and suggestions of mine are reflected in the final product, but the wider truth is that it was a groundbreaking browser.  I know DOM scripters find it annoying and substandard, but for those of us on the content-authoring side, it was rarely the worst of our troubles.

Others will analyze this development in light of the recent Microsoft/AOL settlement, the cessation of IE/Win as a standalone product, and so on.  I’m not really interested in all that right now.  Instead, I’d like to take a moment to run down a list of innovations and features that IE5/Mac introduced back in 2000:

• DOCTYPE switching—some would call this a bug, but in my view they’re missing the bigger picture.  DOCTYPE switching was the first mechanism that allowed authors to decide whether their document rendering should look to the past, or to the future.  It permitted browsers to fix bugs in standards support, instead of forever enshrining them for the sake of “backward compatibility.”  This quickly spread to Mozilla, and eventually made its way into Opera and IE/Win.
• Display resolution setting—there’s a preference dialog where you can set your monitor’s PPI value, literally by holding up a ruler to the screen and using a slider to match the ruler.  Some Windows display drivers had this before, but IE/Mac was the first major browser to build the feature into the browser itself.
• Text Zoom—don’t like a site’s font size?  Override it with a simple keyboard combination, scaling all the text up or down, depending on what you need.  Mozilla quickly followed suit and Opera introduced Page Zoom, arguably a better solution.
• Excellent CSS1 support—it’s easy to forget how revolutionary a reasonably complete and bug-free implementation of CSS1 really was.  Yes, there are some bugs, as with anything.  It’s still better than IE6/Win’s CSS1 support.
• Decent (if limited) CSS2 support—not quite as robust as the CSS1 support, IE5/Mac still made good forays into CSS2.  Remember the browser was shipped about two years after CSS2 went final, which means it was being written maybe a year after CSS2.  That may sound weak, but consider that in addition to fixing all its CSS1 bugs and finishing off CSS1 support, the team found the resources to look at CSS2 and take a stab at doing it right.  That’s pretty impressive, what with them also having to do all the other stuff a browser has to support besides CSS.
• XML source tree view—if you load up an XML file, you get a “pretty-printed” view of the document and its source, with collapsible element views.  Mozilla got this ability only recently, and I’ve always guessed that IE6’s similar ability only exists because IE5/Mac gave them an example to follow.
• Full PNG support—including alpha channels and gamma adjustment.  Sure, it was years after PNG was published, but who else was doing it at the time?  Even today, people are still signing petitions to get Microsoft to do the same for IE/Win.
• Customizable toolbar—you could define your own toolbar buttons, create PNGs (with alpha) to represent the buttons, and customize your browser.  It isn’t quite “skins” but it was still pretty darned cool.  Oh, and the toolbar configuration data was stored in XML.
• Page holder—eventually Mozilla came along with the sidebar, into which almost anything can be installed.  IE5/Mac was doing it long before, albeit with a somewhat different feature set.

There was more, I’m sure, but that was all that came to mind.  When it shipped in 2000, IE5/Mac had a feature set that would be respectable if the browser were released today.  I’d always hoped that one day it would be followed up with a similarly impressive new version.  Sadly, not so.

Just to add an extra layer of melancholy to the whole thing, when Tantek says he found out from folks pointing it out to him, I was one of those folks.  It’s at once difficult and all too easy to believe that the man who created such a good layout engine, and put in so much effort to improve the Web, found out about the end of his own project from friends and the press.

• Hail and Farewell was published on Saturday, June 14th, 2003.
• It was assigned to the Browsers and Standards categories.
• There have been no replies.

Thanks to the power of the Internet, I am now less annoyed at XSLT.  Chriztian Steinmeier wrote to suggest I try xml:space, something I hadn’t previously come across.  So the template now looks like this:

<xsl:template match="/archive" xml:space="preserve">
<div id="thoughts">
<h3>
<span>Thoughts From Eric</span>
</h3>
<xsl:apply-templates select="//entry" />
</div>
</xsl:template>

Ah, much better!  On the other hand, I discovered when I applied xml:space to another portion of my XSLT, it broke an xsl:choose structure.  I had to split one template up into three to sneak around that particular limitation, which some would say is a strength of the technology, since it forced me to further modularize my template.

If I’d been sufficiently determined to avoid splitting up that particular template, I could have used an idea sent in by Hugo Lopes.  He wrote to suggest that I could use custom-defined entities, like so:

<!DOCTYPE stylesheet [
<!ENTITY sp "<xsl:text> </xsl:text>">
<!ENTITY cr "<xsl:text>
</xsl:text>">
]>
<xsl:template match="/archive">
<div id="thoughts">&cr;
<h3>&sp;<span>Thoughts From Eric</span>&sp;</h3>&cr;
<xsl:apply-templates select="//entry" />&cr;
</div>
</xsl:template>

It’s a lot less ugly than what I had yesterday, I’ll agree, but in this particular situation xml:space is a better route for me to take.  Still, it’s an interesting solution to the problem, and a technique I’ll definitely keep in mind for future XSLT projects.  Thanks to Hugo and Chriztian for the help!

• Transformed Transforms was published on Friday, June 13th, 2003.
• It was assigned to the XSLT category.
• There have been no replies.

Three days ago, in the process of finishing up the transition to the new design(s), I discovered a new reason to dislike XSLT—and it’s not exactly like I was lacking for reasons to do so before that.  So what aroused my ire this time around?  Whitespace.  Suppose you have the following XSLT template:

<xsl:template match="/archive">
<div id="thoughts">
<h3>
<span>Thoughts From Eric</span>
</h3>
<xsl:apply-templates select="//entry" />
</div>
</xsl:template>

Further suppose you want to preserve those whitespace returns in and around the elements, in order to keep the resulting HTML clean and readable without being forced to indent all the elements.  You can very easily force source indentation with xsl:output, but if you indent elements then you indent everything, including inline elements, and that drives me crazy.  In addition, having the whitespace avoids strange layout bugs in certain Web browsers that shall remain nameless, but are not IE/Win, surprisingly enough.

There is, so far as I could discover, only one way to ensure that whitespace is preserved in the HTML output.  It isn’t xsl:preserve-space, which will only preserve the whitespace found in the source XML.  No, apparently the answer is to use xsl:text as follows:

<xsl:template match="/archive">
<div id="thoughts">
<xsl:text>
</xsl:text>
<h3>
<xsl:text>
</xsl:text>
<span>Thoughts From Eric</span>
<xsl:text>
</xsl:text>
</h3>
<xsl:text>
</xsl:text>
<xsl:apply-templates select="//entry" />
<xsl:text>
</xsl:text>
</div>
</xsl:template>

God, that’s ugly.  Really ugly.  Much uglier than XSLT’s inherently verbose clumsiness in template handling, which is what made me dislike it in the first place.  If there’s a better way to do what I did above, someone please let me know so I can share it with everyone else and feel a little less annoyed.  Thanks.

Don’t misunderstand: I really like what XSLT can do.  It’s just the syntax and what I find to be thoroughly weird limitations (such as the above) that I abhor.

• XSLTorture was published on Thursday, June 12th, 2003.
• It was assigned to the XSLT category.
• There have been no replies.