meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Archive: August 2007

Magnificent Chicago

Good Night, Chicago

Chicago, Chicago.  It was my sweet home Chicago for all of a year, and admittedly that was back around the national bicentennial, but I still enjoy my visits.  I’ve just learned to accept that the traffic jams are omnipresent, and to chill accordingly.

We drove in on Friday afternoon and left Wednesday morning, tired but content. As I knew would be the case, the folks who came to AEA Chicago were filled to the brim with awesome.  We had a great time röcking out, groovin’ to the tunes, filling Fadó, wondering about Shreddies exchanges, and savoring the lunches.  I’ve gotten my pictures onto Flickr in what is, for me, close to record time, and added them to the show’s photo pool.  All with geocoding, natch.  Gotta geocode.

If you want to know what other people thought of it, Jeffrey‘s got some links—perhaps understandably, Brain Freeze’s post is one of my favorites—and Technorati will be happy to point you to what everyone’s saying.  I can tell you what I thought, though: fantastic.  I can’t wait to do it again!

Contrived Conflicts

CSS Sculptor got a very nice write-up from King Z over at The Daily Report, for which I thank him profusely.  I think he’s pegged the tool pretty well in terms of its intent and target audience(s).

What mystified me was the turn the comments took: suddenly they went from giggling over the splashimation and exhortations to port Sculptor to other environments (Coda got several mentions) to an multi-party argument over which was better, Sculptor or Project VII‘s CSS Layout Magic.

Um, why?

As Al Sparber, creator of Magic, stated quite accurately, “They are two very different tools conceived in very different ways”—nothing to add to that, really.  But even if we were to imagine a world where they were very similar tools that operated in very similar ways, I still don’t see why it would have to be a “battle” situation.  It’s not like our world is so small that there’s only room for one of any given thing.

I mean, take a step back and look at the wider development landscape.  There are a whole bunch of web development environments out there (Dreamweaver, Expression, Coda, Firefox with extensions, etc.).  All of them serve the community, each in its own way.  Each is used by a community of people, many of whom gather to help each other improve their skills.  Why try to create conflict between those communities?  What useful purpose could that possibly serve?  We’d be as well served to start a Mac vs. Windows vs. Linux debate.  Which is to say, not at all.

And so it is with the artificial conflict that so mystifies me, that of Sculptor vs. Magic.  Project VII has very loyal customers, and rightly so: they put out great stuff.  I hope that we’ll also have loyal customers, because that will mean we also created something great.  (Obviously, I already think we did, but then I would, wouldn’t I?)  It seems kind of obvious to me that these two communities have way more in common than they do differences.  My usual reaction on encountering someone who’s a huge fan of a web site or a piece of software is to smile and nod knowingly, like we’re part of a secret club or something.  Because in a sense, we are.  We get fired up by the same kinds of things.  We’re our kind of people.

I admit this is veering dangerously close to plaintive “can’t we all just get along?” territory, but c’mon, folks.  There’s already more than enough tension and conflict in the world.  Let’s try not to add to it, yeah?  Now everybody throw the hörns!  Seriously, throw ‘em, and put in a little “ROCK!” just for me.  You’ll be amazed at how much better you feel.

CSS Sculptor Released

I alluded yesterday to “backstage work”.  One of the things going on back there was my work with the folks at WebAssist to create a tool that allows both novice and experienced web developers to create and alter CSS-driven layouts.

The end result is Eric Meyer’s CSS Sculptor (v1.0.0), a Dreamweaver extension that gives the user tons of options and outputs pretty darned clean markup and CSS.  (Even if you’ve no interest at all in Dreamweaver tools, you should still follow that link.  How many chances are you going to have to see me throw the mëtäl hörns?)

Well you might wonder how much code I contributed to this software.  Well, okay, none.  What I did contribute was guidance on the interface and its organization; on what options to present, and how; on ways to handle things like print styles and the print CSS options; and on the CSS and markup that results, including the optional explanatory comments in the CSS.

One of the primary goals with this project was to create a tool that would expose as much CSS as possible to users without overwhelming them, and that would actually teach by dint of showing all the options.  One of the things we heard a lot in the beta test was users saying things like, “Oh, so that’s what that CSS thingy does! I’d always wondered.”  Which was exactly what we’d hoped to hear, along with “Hey, I’ve never heard of this CSS property before!”.  (We heard that one too.)

There are some things I expect will be improved in future releases, like shorthand value minimization—the simplest example of that being a condensation of 0 0 0 0 down to just plain 0.  We discussed including that feature but decided to postpone it for a variety of reasons, not least of which was working out the logic required to figure out when to minimize, which isn’t as simple a problem as you might first think.  There were a few other things we didn’t get in the initial release; such is the way of software.  We’ve got a list of potential features, of course, and are looking forward to hearing what users suggest.

As for what features did make it in, there’s a fairly large list, so it’s probably best to check out the Features page or take the product tour—with video commentary starring, you guessed it, yours truly.  So if you’ve ever wanted to see me greenscreened over screenshots and being intermittently goofy, then at long last your prayers have been answered!  (Or will be, once we get the load problems resolved.)

What makes this whole thing an especially interesting experience for me is that, for the first time in my life, I’m participating in an affiliate program.  Basically, what I earn from sales of CSS Sculptor depends on affiliate fees earned by referral links like this one here (and also earlier in the post).  That might sound like a rip-off, but it has the potential to be quite the opposite.  The affiliate cut is literally an order of magnitude greater than any reasonable per-unit royalty would be.

This compensation scheme (as they say in the UK) is actually an experiment on both sides: WebAssist has never really worked with an outside individual on a product like this, and so they honestly don’t know if the affiliate approach will pay better than a per-unit royalty, or worse.  So we’re going to try it out and see what happens.  Fortunately, I’m in a position that I feel I can afford to experiment like this, allowing both myself and WebAssist to find out what works best in the long run.

Thus, if you’re planning to buy CSS Sculptor or know someone who is, I’d be grateful if you either clicked through one of the links hereabouts or linked to the product using my affiliate URL.  I’ll have a link in the sidebar in the near future as well.  The sidebar’s due for an overhaul anyhow.

So that’s one of the things that’s claimed my time over the last few months, and I’m pretty excited that it’s seeing the light of release.  I’m even more excited about finding out what people think could be better about it so that we can improve what’s already a pretty darned nifty tool.  If I do say so myself.

San Francisco Schedule

Amongst all the travel, there’s been a metric ton of backstage work going on.  This is generally true of me these days, which is why posting has fallen off in 2007.  Unfortunately, it’s meant that I’ve been lax about keeping you folks up to date on what I’m up to—and also to keep you informed about An Event Apart, which is what accounts for most of that backstage work.

For example: last week, we announced publication of the complete schedule for AEA San Francisco, which will be 4-5 October 2007, and I didn’t say a word here.  I should have; honestly, it’s amazing.  I already want to see it.

I know, I say that every time, but it’s always true.  One of the things that makes me proudest about AEA, and that makes me continue to work hard on AEA, is that it fulfills one of the core requirements Jeffrey and I set out: to create the kind of event we’d want to attend.  I’m not satisfied with an AEA show unless I can look at it—and I mean all of it, from the schedule to all the organizational details that aren’t always obvious—and say, “I would pay money out of my own pocket to see this show”.

And so far, I’ve always been satisfied.

So we end the 2007 series with another great lineup and incredible set of talks in San Francisco, and it makes me proud all over again.  I hope you can be there to see it.

Running on :empty

While kicking around some ideas at the CSS workshop I led in London, I ran into some interesting problems with :empty.  If you’re not up on what that one does, it’s a way of selecting elements that have no children, including text.  To quote the formal definition:

The :empty pseudo-class represents an element that has no children at all. In terms of the DOM, only element nodes and text nodes (including CDATA nodes and entity references) whose data has a non-zero length must be considered as affecting emptiness; comments, PIs, and other nodes must not affect whether an element is considered empty or not.

So kindly consider:

*:empty {
   padding: 0.25em;
   outline: 1px dashed red;
   background: yellow;
}

We (re)discovered something very strange right there in the workshop: given the preceding rule, Firefox applies it to the body element—which is, quite clearly, not empty.  You can check out the fun on my bare *:empty test page.  From there, we realized that if you prepend a body to the selector, yielding body *:empty, the problem vanishes, as you might expect.

As it turns out, this is a known bug in Gecko.  It’s been known for about 18 months, in fact.  So that’s why I was confused by Firefox’s behavior.

The other problem is that :empty in Firefox matches img elements, whether or not they cause an image to successfully load.  You can see this happen on the same test page.  While it’s true that img is an empty element, it’s still bringing in content, so from a common-sense point of view it seems that :empty ought not to match.

In re-reading the description from the specification, though, I can’t justify my common-sense interpretation—an img element has neither element nodes nor text nodes, so far as I’m aware.  The same is true for form inputs, even text inputs that have pre-filled value text; but not for textareas that have pre-filled content text.  But then br elements should also be selected by this rule, and they apparently don’t get matched at all, as the test page shows.  Bwuh?

Well, maybe it’s a bug.  What concerns me here is that the definition of :empty basically requires that things like images and inputs always be selected, which strikes me as kind of useless.  After all, if I wanted to select all images, I’d write img into my selector; ditto input for inputs.

My thinking is that the description should change to state that application of :empty is restricted to non-replaced elements.  Alternatively, it could be redefined to only apply non-replaced elements and to empty replaced elements that don’t either cause something to load or have values associated with them.

Which seems a better solution to you, and why?  Or, if you see a better approach than either of those, what is it?

Come Tuesday

Some news for folks in London (UK) and Cleveland (US).  If you don’t fit either of those descriptions, well, I don’t know what I can do.

For those of you in or near London, I’ll be at a Geekminidinner the evening of Tuesday, 14 August 2007, which you can read a bit more about over here.  (Apparently, I need to print out an article I wrote a while back and staple it to Ian‘s forehead.)  Come on ’round and join us!

About four and a half hours after that starts, I’ll be missing (in both senses of the word) the Cleveland area Web Standards/Web Design Meetup.  Once left for dead, this group has come roaring back thanks to the tireless efforts of a COBOL dude who is much less scary than his profile photo would seem to indicate.  He does run the Ubuntu Satanic Edition, but I’m sure that’s just a coincidence.  Seriously, he’s a great guy.  I have never once heard him say “SATAN!” in a deep growly voice, no matter how many times I ask.

The point being, 18 people have already said they’ll be at the Meetup, and you should absolutely add yourself to that list.  Assuming you will actually be there, of course.

As for London, I don’t know how many will be there, but probably not as many as the Cleveland gathering.  Hey, it’s okay, folks.  Don’t feel down about it.  Not everyone can be as cool as Cleveland.  We’ll do our best to have a good time regardless.

The Veteran’s Charge

“This page best viewed in…”

If that phrase doesn’t provoke a shudder of horror and loathing, it should.  It’s the battle cry of the Browser Wars, those terrible and ultimately futile years at the end of the last milennium.  It’s the rallying cry of those who would take the open ubiquity of the web and fragment it into a collection of gated communities, where entrance to each is predicated on running a specific browser.

“Your browser is not compatible and must be upgraded…”

All too often, because developers are too fearful or prideful or just plain lazy, they put up unnecessary barriers to entrance.  They prevent people from using their sites based on choice of browser.  Of course there are situations where the experience will be different—nobody expects Netscape 4 users to be able to see all 2007′s pretty CSS effects, just like table-based sites look beyond bizarre in Mosaic.  That’s no excuse for sites that intentionally lock users out just because their choice of browser doesn’t line up with the developer’s expectations.  It’s regressive, short-sighted, and just plain unprofessional.

“This site is for iPhone users only.”

STOP IT.  Stop it right now.

The fact that optimizing pages for an iPhone makes the development of such specialized pages attractive in no way excuses lockout of other users.  I might be willing to entertain the argument if the iPhone’s browser were some specialized non-web contraption.  It’s not.  It’s a full-fledged XHTML+CSS+DOM browser that happens to lag a bit in some implementation areas and won’t run some plugins.

Besides, if you’ve developed a version of your site (or application or whatever) that works well on the iPhone, then why in the name of Tim Berners-Lee would you deny other people that optimized experience?  You might find that they prefer to interact with the site that way no matter what platform they’re using.  You might find that you don’t need a separate iPhone version after all.  The iPhoned version might be the only version you need.

Designers will argue that pages optimized for the iPhone screen will look bad on a desktop browser.  Maybe, and maybe not, but stop preventing your users from making that decision for themselves.  Nobody says you have to convert your whole site to be iPhoney.  But your lockout of non-iPhone users is worse than rude.  It’s stupid.

We finally learned, after much sweat and a fair number of tears, that “best viewed in” is a fool’s errand.  Are we so eager to rush back into that morass and fight the war all over again?

Please.  Just stop.

August 2007
SMTWTFS
July September
 1234
567891011
12131415161718
19202122232425
262728293031  

Archives

Feeds

Extras