Archive for the ‘Browsers’ Category

IE form post bug

Posted on in Browsers, Work, WWW.

Consider the following code:

<form action="whatever" method="POST">
<input type="hidden" name="foo" value="a very long string" />
<input type="checkbox" name="confirm" />
<input type="submit" />
</form>

In Internet Explorer (confirmed in both 6 and 7) submitting this form with the checkbox ticked results in no response from the server. (Submitting it without the checkbox ticked just brings you back to where you started.) No problem at all in Gecko-spawn or Opera.

Anyone seen anything like that before? And better still, got a solution?

Legendary

Posted on in Browsers.

I promised a test case for my latest problem and here it is: Gecko’s stubborn legend.

A few things worth noting:

  1. In reality the yellow background will be a gradiant background image within each box, so I can’t just apply the background to the form.

  2. Opera starts out displaying the upper form as FireFox does. The addition of position: relative (with no top, left, etc.) to the styles for legend magically changes that.

  3. IE7 breaks the * html hack so some further work will be needed to align the legend horizontally without breaking things in any other browser.

  4. Gecko doesn’t seem to apply float or display (except display: none;) to legend elements at all.

Tags:

When good browsers disagree

Posted on in Browsers.

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.

Tags:

Tags, Clouds and Operas

Posted on in Browsers, WWW.

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. 🙁

Tags:

Funky CSS stuff for Gecko browsers

Posted on in Blogs, Browsers.

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;
}
Tags: