A followup to my last post about unobtrusive fieldsets and legends. Safari and Konquerer are applying the relative positioning just as Opera does. But they had already removed all indent on the legend as Gecko does. This is a problem as both Opera and Safari are under constant developement and have good CSS support. So how do we distinguish between them?

There are some CSS hacks that cause code to be treated differently by these browsers but instead of relying on poor CSS parsing in older browsers (as in most IE5 hacks) they rely on parts of the CSS spec that aren’t supported yet (e.g. the :lang hack). But Opera 9.1 or Safari 2.1 might well support them, rendering the hack useless.

And it’s not a case of one browser being wrong, legend elements are somewhat peculiar and the default implementation of their presentation can legitimately vary between browsers.

So unless anyone knows a good way to feed different styles to Opera and Safari (that doesn’t rely on browser sniffing, either via JavaScript or server side languages) all I can suggest is that you either use the negative left margin method and accept that Opera will indent the legends, or use the relative positioning method and accept that Safari will outdent the legends. The former method is probably less risky but irks me as an Opera user.

Stuff from all over, ‘cos my mind is a bit scatty at the moment.

New blog, (discovered via TMP) Olduvai George, dreadful paleontological pun but wonderful artwork of ancient mammals. And some les ancient ones, like weasels.

Ever since I started working on the VisitLondon.com web site I’ve been annoyed by how many of the pages display in Opera. The main content section of these pages consist of many visual boxes stacked one atop the other. Some of these boxes are div elements and some are table elements, depending on the nature of their contents (and yes I know the whole thing is wrapped up inside both a layout table and some div soup). In Opera the table elements were displaying two pixels wider than they should have been, breaking up the nice column of equal width boxes.

This week I had time to dig into the CSS I discovered the cause. The style rule table {text-align: left;} is the cause. Easy fix, move that text-align rule to the th and td elements. Anyway, the bug is now documented.

And you know what else? Opera 9, technical preview 1. Yep, bug is fixed already. (Also getting close to passing Acid 2, which would be good as it’s all been Mac and Linux browsers so far.)

Oh, and Firefox has a new version out as well.

A relative of a colleague is playing a Cyberman in the new Doctor Who. The same family also contains the man who played the Stormtrooper who banged his head in Star Wars.

And the rest was memes from sites that are down at the moment…

Not a case for Use JavaScript after all, unless Quizilla are so lazy that they can’t implement a trivial fix. This is the bug report I just sent to them:

Currently a click anywhere in your pages causes Opera to open up the main menu. This is particularly annoying when filling out a quiz as selecting an answer to question one causes the main menu to appear and cover the text of question two.

This is causes by a small typo in your HTML.

<sppan style="font-size: larger; font-style: bold;">Main Menu</span>
<span style=”font-size:smaller;”>Click to Expand [v]</span>

Note the <sppan>. This is mucking up the document parse tree and causing Opera to treat the div with the onClick event handler to remain open.

Change that to <span> and the problem will be fixed.

Some people just haven’t ever heard of rudimentary QA.

[update] - and I’ve never heard of proofreading: “causing Opera to treat the div with the onClick event handler to remain open”. Sigh.

[update 2] - Quizilla have fixed the typo and their quizzes are once again safe for Opera users. Result.

Middle Earth Meme

via Sharikkamur

Rohirrim

To which race of Middle Earth do you belong? brought to you by Quizilla

Monty Python Meme

via The Virtual Stoa

G’day, you’re Bruce! You think like a philosopher, especially after you’ve had a few cold ones…Australia RULES!

What Monty Python Sketch Character are you? brought to you by Quizilla

By the way, both these memes are on Quizilla, which has recently been demonstrating an annoying behaviour in Opera (present in 8.02 and 8.50, not tested in the version 9 preview yet) whereby a click anywhere in the page expands the menu on the left. So selecting an option in question one expands the menu and hides the text of question two. This is the sort of thing that User JS can fix, but before I start examing Quizilla’s JavaScript to find the problem, does anyone know if anyone else has already done the work?

Version 8.50 of Opera is out and is totally free. No more ads, no more registration fee, no one-off deals like the birthday deal a little while back, the best web browser is now totally free.

If you really want to pay for it, consider sending me some money because as a registered user of Opera since version 3 I’ve helped to pay for all the development that has led to this point.

Looking over the Technorati redesign as plugged by Eric Meyer (same old stuff – nice CSS but fixed width design, fixed font sizes in IE, breaks with only a couple of font size increases in FireFox, minor validation errors) I saw that the Tags page didn’t display properly in Opera 8.01.

The relative frequency of the tags are indicated via nested <em> elements with a CSS style font-size: 1.03em to produce the increased size.

But Opera screws up and rounds the font sizes down. I’ve written up a description of the bug and submitted a bug report to Opera.

Until Opera and/or Technorati do something about this issue there’s a quick fix that Opera users can apply. As Technorati includes id="technorati" on the <body> tag it’s relatively easy to add
#technorati .heatmap em {font-size: 1.06em !important;}
to a user stylesheet and restore the tag coloud to its full glory. The exact size value needed will vary depending on your particular default and minimum font size values.

Moving away from the Opera bug we’re still left with the larger issue. What’s the best way to (a) mark-up and (b) indicate relative importance in various media.

As far as the mark-up goes HTML doesn’t offer us that many options and <em> is probably the best choice. Things are slightly confused by the presence of <strong> – how does strong emphasis relate to multiple levels of emphasis created via nested <em> elements?

By default browsers don’t change their output for nested <em>s so there’s no way short of viewing the source for the user to see the level of importance. For graphical media increasing the font size is one possibility but even when Opera’s shortcomings are ignored this might break down (consider mobile devices for example). In non-graphical media the font-size is meaningless.

Volume or pitch are options in aural media but don’t make for an easy listening experience (this sort of tag cloud is designed for visual skimming and doesn’t really work the same way when listened to linearly; but if a listener chooses to listen to it they should get the same information as the reader, via some means or other).

The best solution I can think of would be to add title attributes to each tag giving the relative level of importance. So a tag surrounded with four levels of <em>s would have title="Level Four" or something similar.

Whilst not ideal (and maybe tag clouds aren’t such a good idea) this does have the advantage that it brings together mark-up, styling and metadata (the <em> elements, the font-sizing and the titles) to reinforce the same message. The message. Ah, that’s the real problem. The relative popularity of the various tags is the message and the message should be in the data not in anything else. But that means turning the funky tag cloud into a boring table.

Well two of them.

Proof, not that it was needed, that (a) CEOs say stupid things and (b) Opera Software are cool people.

So first day at the new job. No computer for most of the day. Bit of a problem in my line of work.

Anyway the day was enlivened by the news that Adobe has bought Macromedia. I’m very glad it was that way round because of the two I much prefer Adobe - I prefer the user interface on their software and they have a web site that actually works. But what does this merger mean?

For developers and designers it means that sooner or later some of the tools they use will be dropped. The clear favourite to be shown the door is Freehand which simply doesn’t have anywhere near the market share of Illustrater. But how will Fireworks and Image Ready be handled? Fireworks is far more popular than Image Ready but Image Ready is fully integrated with Photoshop which is much more popular, and does a lot more, than Fireworks. GoLive and Dreamweaver is another interesting match up. A product that combines the best of both would be ideal. But at the end of the day I’m not sure this merger will make a huge difference to developers.

For users there’s a potential nightmare on the horizon. Can you imagine a Flash movie embedded in an Acrobat document, or vice versa? The two most widely used (and abused) proprietary formats on the web are now controlled by the same company. Let’s see what happens.

Better news is that Opera 8 is officially released tomorrow.

Barely had I installed Opera 8 beta 2 when Opera 8 beta 3 comes along. Big improvement to the preferences interface. (Though where has the option to have visited links struck through gone? It’s still supported because it still worked when I copied my old profile across but now it seems to require either User CSS or editing a .INI file to implement.)

But the most exciting thing is native support for SVG. That plus support for XMLHttpRequest and voice browsing is making Opera even better than before.

And at the same time leaks indicate that MSIE 7 will fully support transparency in PNGs. What took you guys so long?

This grew out of a discussion regarding .ICO files and CSS on alt.html. Now, I made some mistakes in my off-the-cuff suggestion there (I used [att|=val] rather than the correct (and, annoyingly, CSS3) selector [att^=val]. After switching to the correct selector I realised that, even allowing for the simplification supplied by Toby Inkster, this would be Gecko only for now. But it is a nice trick anyway.

In essence what it does is insert a site’s favicon before any link to that site. As CSS doesn’t parse the value of att() it can’t be done on a generic level (it could be done with JavaScript but raises a number of other issues) but it can be done for sites that you link to frequently.

#content a[href^='http://groups-beta.google'] {
  background-image: url('http://www.google.com/favicon.ico');
  padding-left: 20px; background-repeat: no-repeat;
}

#content a[href^='http://www.imdb.com'] {
  background-image: url('http://www.imdb.com/favicon.ico');
  padding-left: 20px; background-repeat: no-repeat;
}

#content a[href^='http://www.amazon.co.uk'] {
  background-image: url('http://www.amazon.co.uk/favicon.ico');
  padding-left: 20px; background-repeat: no-repeat;
}

#content a[href^='http://en.wikipedia'] {
  background-image: url('http://en.wikipedia.com/favicon.ico');
  padding-left: 20px; background-repeat: no-repeat;
}