Posts in the Tech Category

I’ve been pounding my brain against a problem in Photoshop CS for the last few months—no, not continuously—and I’ve given up.  Now I turn to the PSD experts in the crowd for help.

What I want to do seems simple enough.  The goal here is to have a PNG where the alpha channel coincides precisely with a visible pieces of the image.  In other words, if the visible image is a large black diamond, then I want the alpha channel to be in the same shape and intensity as the diamond.  That way, in IE/Win, there will be a big black diamond.  In other, more capable browsers, there will be a transparent diamond with a white mask, so I can set whatever background color I want.

Here are two images that, I hope, illustrate what I’m aiming to do.  The first image is what IE/Win would render, and the second is a representation of what another browser would render (the gray checkerboard pattern representing the transparent parts of the PNG).

I’ve fiddled with combinations of masks, layers, alpha channels, and more until my head feels ready to explode.  No matter what I do, I can get either an image that’s opaque (read: no alpha channel) in all browsers, or an image with a full alpha channel, where the alpha portion is filled with a light silver-gray in IE/Win.

It seems like there has to be a way to do this, and that someone out there knows what it is.  So how in the name of the sweet Virgin Mary do I get this to work?

Update: I sense that people aren’t getting what I want to do.  What I effectively want to do is take an image of the diamond—a GIF, a TIFF, whatever—and, in turning it into a PNG, add an alpha channel such that the diamond gets “knocked out” in programs that understand the alpha channel.  In those that don’t, like IE/Win, the regular image should just appear, with no alpha-channel effects.  Just the black diamond.

And I want to know how to do it in Photoshop, which is the tool I use.  Telling me how to do it in GIMP would be incredibly useful if I hadn’t thoroughly hated GIMP’s UI, and thus uninstalled it about ten minutes after installing it, back when I did.  (To be fair, it might have been the X11 UI that I hated, but since GIMP was the only X11 application I’ve run… you see where I’m headed with that, I hope.)

• Clearly Impossible? was published on Thursday, September 1st, 2005.
• It was assigned to the Tech and Tools categories.
• There have been forty replies.

This news is a little musty, but Shaun Inman updated CSS-SSC recently.  If you’re using CSS-SSC, you should definitely go grab the update.

“Hey, what’s CSS-SSC?” you exclaim?  Oh, I’m sorry.  It stands for Cascading Style Sheets Server-Side Constants.  Here’s Shaun’s initial example:

@server constants {
    linkColor: #AB6666;
    linkColorHover: #710101;
    }
a { color: linkColor; }
a:hover { color: linkColorHover; }

In other words, you can define your own constants in CSS.  This works because CSS-SSC is a preprocessor—it processes the style sheet before it’s sent to the browser, and turns it into something the browser can handle.  (Put another way, what arrives at the browser is a regular style sheet, with none of the ‘SSC’ information.)  Shaun offers more details in an earlier post.  CSS-SSC requires you to have PHP hanging about, and also to edit some stuff on your server, like .htaccess files.  You’ll also have to be careful about how you name your constants: use the constant name color, for example, and your CSS is going to go to a particularly mangled form of textual hell.

Personally, I’m both enthused and annoyed by CSS-SSC.  I think it’s a great solution: definitely one of the best, lightest-weight, easiest approaches to adding preprocessing to CSS.  I’m seriously considering putting it to use on ALA, in which I jumped through a few grouping hoops in order to get the fonts and colors just the way Jason wanted them.  Dropping back to constants would make life a bit easier—and would also simplify the whole “per-issue coloration” feature.  (Which I already have working, but via a large number of hoops, several of them on fire.)

I’m annoyed because it bothers me that Shaun had to create CSS-SSC in the first place.  There have been occasional requests for constants in CSS.  They get shot down every time.  “Use a preprocessor!” is the cry, and at first glance, CSS-SSC would seem to give credence to that response.  From my point of view, however, CSS should have had constants long ago, and what Shaun has done is proof.

The refusal to add constants as a feature of CSS has always stuck me as highly pointless.  Over the past decade, many people have expressed a need for CSS constants in a number of fora, and it’s a good bet many more have had the need without publicly expressing it.  Adding it to CSS would have done little to increase complexity on the implementor’s side; Shaun’s one-page PHP script (a good deal less when you remove the comments) proves that.  Adding it to CSS would have meant authors could just do it, without having to install anything else first.  Shaun’s made installation about as easy as it gets, but it’s still three or four steps more than should exist—and, for some authors, three or four impossible steps, due to their hosting situation.  And if you aren’t running a local web server, then you can’t test your CSS-SSC-enhanced styles locally; they’ll have to go to a web server first.

Because CSS still lacks, and will apparently continue to lack, a way to define your own constants, I’m really glad Shaun has devised this low-threshold solution.  I just wish that it hadn’t been necessary for him to do so in the first place.

• The Constants Gardener was published on Wednesday, August 31st, 2005.
• It was assigned to the CSS and Standards categories.
• There have been thirty-four replies.

As a followup to my entry about id="tags" causing problems in IE/Win, here are four five test pages for IE/Win:

• IE Keyword Testing (length)
• IE Keyword Testing (item)
• IE Keyword Testing (namedItem)
• IE Keyword Testing (tags)
• IE Keyword Testing (urns)

These are based on Kevin Hamilton’s observation that it’s highly likely the problems are caused by the tags method in IE/Win’s document.all DOM interface.  As he says:

[I]f you have an element with an id=”tags”, then document.all.tags is now a reference to that element, and no longer a method of the document.all object.

Such states would completely shatter any IE DOM scripting that relied on the document.all methods, and at least in the case of tags causes problems like crashing on print (probably because of the aforementioned conflict between the ID value and the DOM method).  The other keywords of concern are chronicled in the test pages listed above.  I’d test IE/Win myself, except I don’t have a printer handy for IE/Win to use, and besides, bug-hunting is best conducted in large groups.

Basically, load up each test page in IE/Win and do anything you can think to do.  Try to print, view source, save a local copy, et cetera, et cetera—the more obscure and offbeat, the better.  Let us know via the comments any problems you run into with said pages (trying to print them is a good first step, since that’s what messed up on tags) and I’ll add notes to each page based on what’s found.

In the meantime, I’m personally going to avoid using any of those words as ID values, and heartily recommend the same to you.

Update: I’ve added a test (for length) to the above list, and have another that’s not on the list due to its unfinished nature.  It’s a test of id="all"; the problem is, I don’t really know how to test it, or if it’s likely to be a problem at all.  Suggestions are welcomed in the comments.  I added some JavaScript links to some of the test pages as a secondary test, but I’m not sure how much good they do, to be honest.  As with suggestions, your feedback is welcome.

For those in search of more background, or trying to find new ways to test possible conflicts, or whatever, feel free to look over Microsoft’s documentation of the “all Collection”.

• Reserved ID Values? was published on Monday, August 29th, 2005.
• It was assigned to the (X)HTML, Browsers, CSS, and DOM categories.
• There have been forty replies.

Here’s a fascinating little tidbit: on some users’ machines, attempts to print out Joe Clark‘s ALA article “Facts and Opinions About PDF Accessibility” would crash Internet Explorer.  The error message mentioned a script error in line 1401: “Object doesn’t support this property or method”.  Funny thing: we weren’t doing any scripting.  The error was actually occurring shdoclc.dll/preview.dlg, which is of course a piece of the operating system.

Jason did some sleuthing and traced the crash to this line of markup:

<h2 id="tags">Tags and structure</h2>

Honestly, that was it.  So Jeffrey renamed the ID to read:

<h2 id="structure">Tags and structure</h2>

So far as we know, no more crashing in Explorer.

Ain’t browsers a slice?

(And yes, we’re aware of the clamor for a print style sheet.  More on this later.)

Update: Marten Veldthuis from Strongpsace points out that 37signals ran into a very similar problem in Backpack.  Details can be found in Jamis Buck‘s June 3rd post ie-is-teh-3v1l.  Spread the word: “tags” is effectively a reserved keyword, even though no such concept exists in (X)HTML.  Use it at your (users’) peril.

• When Printing Kills was published on Friday, August 26th, 2005.
• It was assigned to the (X)HTML, Browsers, and DOM categories.
• There have been forty-six replies.

A List Apart is back in business and sporting a radically new design.  Check it out!  Four columns on the main page?  Yes indeed!

I’m proud to say I had a hand in the redesign process, taking the visual goodness of Jason Santa Maria and turning it into living, breathing XHTML and CSS.  Keeping the pages from going completely crazy in broken browsers was an interesting challenge at times, but overall I think things came together rather nicely.  There may be a few glitches here and there, though we did our best to test widely and often, but if so we’ll handle them as they arise.

It was good fun working with the talented team members in this process, and I especially enjoyed being able to concentrate on what I know—building XHTML and CSS around existing designs—and leave the rest to other people who knew their stuff as well as I know mine.  Due to the strategic partnership between Complex Spiral Consulting and Happy Cog Studios, I look forward to assuming that role more often, and on ever more interesting projects.

Addendum: it seems the DNS change to point to ALA’s new Textdrive home hasn’t made it as far as I’d thought, so I’ll point you to the numeric IP address; that way, you can see it even if your local DNS hasn’t caught up yet.  Sorry for any confusion!

Addendum 2: it’s been long enough that the DNS change should have made it to all the far-flung corners of the net, so I’ve removed the numeric IP addresses.

• A List Apart Returns was published on Tuesday, August 23rd, 2005.
• It was assigned to the Projects and Web categories.
• There have been thirty-two replies.

Remember how, back in July, I ventured across the Atlantic to give two full-day workshops on XHTML and CSS in London?  Well, this November the workshop is crossing the ocean: announcing “Professional CSS XHTML Techniques” this coming November 3rd in Chicago, Illinois.

Ryan Carson, one of the two founders of BD4D, is putting together a heck of a workshop series, as you can see by visiting the Carson Workshops home page.  There you’ll find my workshop listed, as well as seminars from Cal Henderson, Joe Clark, and Molly Holzschlag and Andy Clarke.  So far, they’re all headed to London, but given the past history of Ryan’s efforts, I think it’s a good bet some or all of them will be headed Stateside in the future.

As in London, your registration gets you a copy of the “XHTML / CSS Survival Kit”, a disc containing all kinds of examples, articles, tools, and so forth.  You’ll also get a whole day of high-tempo, practical instruction in CSS-driven design, with plenty of opportunity to pose questions and get answers.  I had a great time in London, and the attendees seemed to have just as good a time.  I’ll be doing an updated version of what I did there, so if you wanted to attend the London event but couldn’t swing the transoceanic airfare—well, here’s your chance to make up for it!

Addendum: you know, I was so excited to tell you that the workshop was going to happen that I completely neglected to mention that registration is already open!  So get yerself on over to the Carson Workshops site, click on through to my seminar, and sign up already!

• Workshopping in Chicago was published on Wednesday, August 10th, 2005.
• It was assigned to the (X)HTML, CSS, and Speaking categories.
• There have been fourteen replies.

Some of you may have tried to comment recently and been hit with a “comments are closed for the time being” error.  That was Gatekeeper, actually, and it was being tripped even by valid responses to the Gatekeeper challenge.  The weird thing is that some people were able to comment, whereas others were not.  I have no idea why this was happening.

The point of this being to say that I’ve updated Gatekeeper to return a more helpful error message, and also believe some changes I made should make gatekeeper less random.  If I’m wrong and you get an error, please use the e-mail link in the error message to send the error to me.  If I’m right and you get no error, then no worries.

If I get a lot of error reports, I’ll hobble or disable Gatekeeper, but I hope it doesn’t come to that.  We’ll see.  In the meantime, my sincere apologies to anyone who got bitten by this bug, and I hope things will be better from here on out.

• Comment Turbulence was published on Saturday, July 30th, 2005.
• It was assigned to the Projects and WordPress categories.
• There have been five replies.

Oh, sure, I build a slide show system specifically because of a bug in Opera 7.5, and despite that I go fairly far out of my way to make sure that Opera will still be able to display the slide show using its unique and groundbreaking feature, OperaShow, and now I’m the bad guy.

A little history: the first version of S5 was meant to recreate what OperaShow did, except do it in other browsers.  That was pretty much it—but as I was fiddling with the JavaScript to make that work, I realized I could build my own navigation menu in the JavaScript.  So I did.  Then, when I tested to see if it worked in Opera, it didn’t.  I tried for a while, but couldn’t make it work.  So I decided to hide the menu from Opera.  Better no feature than a broken feature, and besides, it was the only one so hidden.

When I tossed S5 out to the public, I figured maybe twelve other people in the world would be interested.  It was one of those, “Hey, this is something I hacked together, look how geeky I am!”

And the crowd, against all expectations, went wild.

So the list of things I thought would be interesting to add some day suddenly took on extra weight.  There were people out there who actually wanted to use S5, and wanted things like font scaling and incremental display of slide content.  Furthermore, there were people contributing code to improve the system.  Out of nowhere, a little open source project erupted in the comments of my posts.

In order to keep things from bogging down, I defined a feature list for S5 1.0 and shipped it out.  All along, I made sure that the slide show would fall back to OperaShow in Opera.  To do so, I had to write a routine (called notOperaFix() because it had to fix things for browsers that aren’t Opera) that swapped around the media values for various linked style sheets, among other things.  I also had to define the S5 format so it was compatible with the OperaShow Format specification.  That meant changing some things from my original file format, and in my opinion not always for the better.

Despite a few people telling me to just drop OperaShow and OSF support because it wasn’t worth the effort, I kept those mechanisms in place as we moved to version 1.1.  I figured that since Opera had a slide show system, I’d let people use it.  Besides, any time I created a test copy of S5 that didn’t let Opera drop back to OperaShow, it completely failed to display the slide show.

Now S5 1.1 is out, and it has more features that people asked for—font scaling based on window size changes, incremental display, more keyboard commands, and so on.  Throughout it all, I made sure OperaShow would still work.  And it does.  It doesn’t get the keyboard commands, or the font scaling, or the incremental display.  I did try.  I couldn’t figure it out.

Now, there are those who apparently think that this means I’m a liar when I say S5 is cross-browser.  I admit it—S5 doesn’t work in Mosaic 1.0.  It also quite likely fails in IE5.0/Win.  Actually, I think it fails in IE5/Mac, which is ironic since my starting point for S5 was a rudimentary slide show system written by Tantek Çelik.  But it does not fail in Opera, because it’s quite intentionally designed to be OperaShow compatible.  It isn’t feature-identical, but then, the features in (and version number of) Opera for the Mac usually lag behind Opera for Windows.

Lying about S5’s cross-browser nature?  Giving Opera the cold shoulder?  Utterly wrong on both counts.  I’ve done everything I can to make sure Opera is still at this particular table.  Giving Opera the cold shoulder would have been me saying, “Screw it, I’m not providing a fallback to OperaShow and if Opera users don’t like it, they can install Firefox”.  And I’ll be totally honest: I’m sort of tempted.  I could clean up the markup; cut out some JavaScript gymnastics, including a backflip over a Gecko bug when dynamically changing media types, which I wouldn’t have to do if I weren’t still supporting OperaShow compatibility; and simplify my life.

After all, it’s not like I sprang this on the world.  The last eight beta and release candidate versions of S5 were published here.  Comments and contributions were solicited and welcomed, and many were received.  The state of Opera support has not changed one iota in all that time.  There were several months in which anyone could have stepped up to the plate and contributed fixes for Opera.  Did anyone?  No.

I’d do it myself, except I’m not sure I can.  For example, I just a few hours ago made a copy of the S5 package, unpacked it, and edited the JS file so it did no Opera detection: the scripts all ran on Opera the same as they do for any other browser.  I loaded it into both Opera 7.5 and 8.02 for OS X, which is what I have right now.  You know what happened?  Nothing.  The slide show didn’t happen.  The outline view came up, changed slightly, and then sat there.  And do you know why?  Because Opera defaults to identifying itself as Internet Explorer.

So I fixed that in the preferences, and tried again.  Everything worked just fine except for two things.  One, the browser window had a vertical scroll bar for no apparent reason.  Two, the controls were nowhere to be found, either by hovering over where they’re supposed to be or using the “C” key to toggle them.  I’m not sure why these two things are happening, because the JavaScript console reports nothing amiss.  That has me kind of stuck.

So here’s the deal.  Want S5 to be feature-equivalent in Opera?  Fine.  Take the S5 1.1 package and fix it for Opera—preferably version 6 or later, but I’ll take what I can get.  Liberally comment your code so I know what you did, and why, or else post fixes here.  I promise that, if this is done in such a way as to not degrade behavior in any other browser—because, remember, they don’t have anything like OperaShow on which they can fall back—and so that the code is maintainable, I’ll roll the changes into my version of S5, and release it as 1.1.1 or 1.1o or something.  (The same is true for any other browser, in fact.)

I’ll help out where I can, if anyone has questions about this bit of JS or that bit of CSS in the S5 directory.  Post them here and I’ll do my best to answer.  If I get hit with a bolt of genius and can suddenly fix the problems myself, I’ll do so, but odds are that won’t happen.  It will therefore be up to the community to help out.  This isn’t just me, as the credits page makes clear; S5 has long been a community effort.

Put another, more succinct way: don’t complain, contribute.  It’s more satisfying in the long run, and it’s more constructive.

• Opera and S5 1.1 was published on Friday, July 29th, 2005.
• It was assigned to the S5 and Tools categories.
• There have been seventeen replies.