This Wednesday is the First Annual CSS Naked Day when web sites should be displayed in their naked glory, bare of all stylesheets. Unless the author has anything to hide (such as, gasp, non-semantic HTML perhaps?).
Very True Things will be a very naked thing on the 5th. (At least the main version of the site will be, the Live Journal mirror will still be fully clothed).
Via a newsgroup post:
A stylesheet used on a MicroSoft web site: http://connect.microsoft.com/Styles/GeneralStyles.css. And just in case they edit it, the first few lines read -
/* fix for the IE 1px-off margin error */ * html .StupidIEMarginHack { margin-right: 1px; } * html .StupidIEWidthHack { width: 100%; }
Even MicroSoft’s own web developers are fed up with IE’s CSS shortcomings.
cheerfulThe browser with the rather unwieldy name of Internet Explorer 7: Beta 2 Preview - released on March 20th is, as the name hints, here and the usual suspects are talking about it.
This release is feature locked as far as site rendering is concerned. So time to start checking your CSS, etc. I’m happy to see that the problems with the book covers in the side bar are fixed, and as conditional comments are also working now I can hide the covers from older IE versions and show them to IE7. (But remember, if you have multiple copies of IE installed they will all use the version number of the ‘main’ copy. So check your conditional comments are working on separate test machines or use browser cam.)
One bug that’s still outstanding is that links with display:block in some case only respond to mouse hovers and clicks on the text and in other cases respond to hovers and clicks anywhere in the block. I think the deciding factor is float related but I need to create some test cases to check. Unless anyone can point me towards someone who’s already done the work?
optimisticI’ve added a couple of plugins to the blog to display music and books that I’m enjoying at the moment. Over there, on the sidebar, down a bit, below the categories and links. (Scrobbles and Now Reading plugins created by Rob Miller.)
Depending on which browser you use you may notice one of two things - FireFox users will notice that both of the new sections suffer from the random single-pixel transparent lines that crop up here and there on the sidebar. Still no clue what causes this. [Update] - FireFox 1.5 fixes this problem, I must update my home version.
And IE users won’t see any cover pics for the books. That’s ‘cos, even in IE7b2, the display was totally screwed up. Too late on a Sunday to dissect the CSS (and let’s face it with IE there’s not much chance of a happy ending anyway), so I gave up and applied an IE only stylesheet to hide the images. Blah. [Update] - Mac IE doesn’t use conditional comments and hence shows the images, incorrectly, but really, Mac IE?
[Update] - As Paul points out in the comments Safari is inserting a large chunk of empty space under each book. According to browser cam this happens in Safari 1.2, 1.3 and 2.0 but not in Konqueror 4.3.
Opera 9, Tech Preview 2 is out and that’s what I call an interesting change log. Liking a lot of things - thumbnail previews when mousing over a tab; user interface exposure to whole bunch of stuff only previously available via .ini files; Widgets; BitTorrent…
One line of the change log did catch my eye: Several changes to the default margin and padding of legends and fieldsets.
This ties in directly to my suggestions on how to create Cross-browser unobtrusive fieldsets and legends and seems to screw Opera by making it apply both the Gecko and the IE/Safari solutions. So the legend is thrown out to the left. The best solution now would seem to be a basic line of code for Opera and Gecko, a negative margin for IE hidden behind a hack, and let Safari do whatever it wants. But more testing is needed.
I’ve also downloaded, via BitTorrent, a slightly naughty copy of Internet Explorer 7, Beta 2. Unlike Opera I’m not happy about installing a Microsoft beta product on my home PC, and as it’s not really a legit copy I’m also wary of installing it at work. I wonder what IT would say if I asked to install cracked beta software on a machine?
However, it does have a whole bunch of CSS improvments and changes (and no doubt some new bugs as well) and I’d like to get a head start of investigating what we’re going to need to change when IE7 goes public (I wouldn’t actually change one single line of code before then because the final release may differ from the beta). And of course, I bet IE7’s CSS changes will impact on my fieldsets and legends experiment as well. Still, better bumpy progress than stagnation.
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.
I was tidying up some web pages (Goodbye single column table, hello unordered list; goodbye multiple level one headings, hello heading hierarchy) when I came across a heading followed by a group of checkboxes. Looks like a fieldset with a legend, I thought, but the page design really wouldn’t be helped by the default presentation of these elements in most browsers. So how make to make these elements completely unobtrusive?
(more…)
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…
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. 
I finally got Internet Explorer to behave properly with respect to the sidebar. By taking all the width properties off the individual blocks and adding instead adding the width to a new surrounding <div>, suddenly IE stops screwing up the first link in every list and sub-list. This means I can get rid of all the <!--[if IE ]><li></li><![endif]–> hacks. Yippee.
Now I just need to work out how to get rid of those annoying single pixel gaps in Gecko.
