Cricalix.Net » Browsers

Browser Caching of Doom (Doom I Say!)

cricalix — Wed, 28 Feb 2007 12:39:51 +0000

I think I’ve ranted (mildly) about this before.

I hate web browsers – different ones will render markup differently, requiring hacks to get around the borked behaviour. However, that has nothing on what Firefox just did to me for about an hour. Load a page in my development environment. Everything looks right. Click on one of the links that performs an action, sets a message in the session, and hands back to the code to render the message and update the page. That works. Click refresh – the message should go away (and the exact same code on other pages has always worked). The message doesn’t go away.

Check the contents of the session – the message area is emptied, which is correct, so there’s no content to be displayed. Hold down Shift and click reload. Message is still there. Check the server side cache of the template – the message isn’t there. View source, the message is there. The only thing that’s changed since I was last testing this code was a Firefox update.

Set Firefox’s cache to 0, and the problem goes away.

I hate web browsers.

EVE Online’s browser…

cricalix — Mon, 12 Feb 2007 18:58:41 +0000

Calling the In-Game Browser in EVE Online a browser seems to be pushing the definition of the word. I’m playing with some code that makes use of option lists, and option groups inside of those lists. Every browser from about Netscape 4 supports option groups (and before that based on memory of some screenshots) – they let you take a big long list of items, and apply some kind of logical grouping so that the group header can’t be selected, but items under the header are indented slightly and selectable.

EVE’s browser, on the other hand, discards any notion of option groups. This annoys me, because I spent about 2 minutes thinking of an elegant way to convert some SQL table output into option group lists. I could have used those 2 minutes for something else. Perhaps, one day, CCP will add just a bit more HTML compliance to their browser code. Maybe. I hope.

IE hates HTTPS’d SWF

cricalix — Tue, 20 Jun 2006 14:44:57 +0000

Technology is a wonderful thing.

Web browsers are technology.

Web browsers are not always wonderful things.

IE + HTTPS + SWF + ‘Pragma: no-cache‘ + ‘codebase=http‘ == Bork bork bork. No graphs load.
Talk about seriously brain-dead, but at least it wasn’t as silly as the Eolas patent.

In the end, due to the SWF library we use to generate graphs, I had to use ob_start(); $chart->export(); header(‘Pragma: IE-Die-Die-Die’); ob_end_flush();

Blech.

XHTML and IE. A marriage not made in heaven.

cricalix — Thu, 09 Jun 2005 09:28:21 +0000

I’m currently going through all of the web interface code for the $dayjob product, and validating it against the W3 XHTML validator (as all my pages are XHTML 1.0 Strict). I’ve been wondering for a while why IE has been rendering the pages in quirks mode, but it wasn’t until today that I found the link to the W3 article on XHTML declarations. Removing the ‘offending’ xml tag, and IE is now starting to render pages a bit more accurately. It still has bugs, but unfortunately I expect that. If it were up to me, I’d can all IE support on our site, but a major client uses nothing but IE, so I have to deal with the bundle of horse dung that is IE.

Our entire interface now validates as XHTML 1.0 Strict, and even 1.1 Strict, which is quite nice. Doubt my boss will want to show the icon anywhere, but it’s nice to know that a browser that understands the spec will hopefully render everything correctly. Also managed to squash a bug I didn’t know existed, which is also nice.

Rendering differences (hopefully moot!)

cricalix — Tue, 01 Mar 2005 08:17:31 +0000

$dayjob involves writing web interfaces to databases. As such, I get to experience the wonderful world of browser rendering differences quite a bit. Those of you who do web work with CSS know all too well the pain that Internet Explorer can inflict on a developer. The one that suprised me today though, is how differently Firefox and Konqueror render the top part of this blog (let alone other parts).

Firefox

Konqueror

I think Firefox has done a better job on the rendering (ignore the underline on the 42, that’s just having always underline links enabled) – the Konqueror render looks very rough in comparison. So the background job today is to find out why Konqueror looks so horrible.