A few days ago I wrote about a difficult goal of having a pleasantly looking submit button that is also as accessible as possible. I also had a simple demo that almost worked, but not quite.

I played with it a bit more and actually got it working as far as I imagined I could. You can see the result here (just change the size of fonts).

What I did is set base font size in all browsers to a known value as described by Richard . It isn’t really necessary to use 62.5%, but it does reset initial size to 10 pixels, which is a value that is easy to work with.

Then I just set height of an image button to its real size, but using em’s instead of pixels. In my case that’s 25 px or 2.5 em’s. I also set font-size of input button to 1 em, which for some reason is needed in browsers other than Safari, to enforce 10px size for fonts and 25px height for the button.

That’s it. Button is now resizable and has its original size by default.

Solution, which is entirely CSS based, is not perfect and I don’t believe it will ever be. Or at least not using incarnations of XHTML and CSS that we have now.

As can be clearly seen on the demo, it all comes down to a choice between better legibility of scaled type=submit buttons and more flexible design of type=image buttons.

I imagine I could do better with multiple sizes of an image for each button and using javascript swapping, but it wouldn’t work where javascript is missing and multiple images would significantly add to production costs.

Personally, I think web sites should have a design readable for vast majority of its readers even without text scaling and this trick can be good enough for the rest. However, at the same time I don’t expect to use it often.

We’ve slept only a few hours today, to wake up early and drive in awful rain to Koper. Tim Bray was speaking at OOoCon 2005 and I didn’t want to miss it.

I wasn’t disappointed. He’s an excellent speaker and even though I can’t say I’m a dedicated user of any office suite, I found his talk very engaging and thought provoking.

As every WordPress user knows, blogging interfaces can be rather underwhelming. And WordPress is just an example, as the same can be said about most of them. But users are certainly not getting help from current versions of suites. Sad state of Blogger plugin for Word only exemplifies that.

Therefore OpenOffice of the future should recognize the rising popularity of blogs, wikis and personal voice on the web and do for them what yesterdays suites did for business communication (forgetting downsides for a moment). Making personal publishing less painful and more flexible.

If I understood Tim correctly, he wants to go even beyond that and imagines a world where OpenDocument is a sort of an HTML of tomorrow. Meaning it’s an open container for our data, that would get used by a different applications in myriad of ways, but would never lock our data in.

I’ve been looking at Atom and its publishing protocol lately and just thinking about it and about Tim’s talk, makes my head go dizzy from all the possibilities.

Update: You can also find video and audio of keynote and other talks here .

Sometimes, I really am an idiot. A couple of years ago I was involved in development of a front-end Zope application for a major Slovenian ISP with more than 100 000 users. No matter what we did, Zope just wasn’t fast. In fact it was so slow, it was soon abandoned for one more suitable solution.

The failure of our project was largely my fault, because I haven’t made sure Zope was a good fit for what we wanted. I learned a lot, but it also left a bitter aftertaste and a question, why are people using it?

The obvious answer is of course, because it DOES fit their needs. It’s just that they are not building a site or an application that needs to handle few hundred simultaneous requests. They handle a few at most, so Zope or Plone or what-have-you is more than speedy enough and it’s their features that count.

It really took me awhile to grasp this and it only became really clear this week, after reading a little Plone benchmark and having a discussion with Sebastjan about slowness of Slovenian sites.

On a positive note, we generate pages in less than 6 ms now and can reduce it even further, if needed.