Anigozanthos

Google have recently blogged about their Chrome browser extensions. Their extensions are basically nothing more than regular web pages, just smaller, and with a bunch of new APIs to obtain the necessary functionality.

It's very similar to what Palm are doing with their new webOS - applications for the new Palm phone are written using HTML, CSS and Javascript.

I've never been much of a supporter of browser extensions. To me, they just add a lot of complexity and trouble to an already incredibly complicated application.

However, back in 2006 I thought that Opera should somehow make their then-new widgets the basis for extending functionality into the browser chrome. I still think Opera should do something like that.

Leveraging existing web development knowledge makes a lot of sense. I'm not convinced that Google's use of separate processes is really necessary. Just lightweight multi-threading so nothing blocks up.

I just had to write about this CMS I just bumped into: Zimplit. It seems to be very, very new. It also has probably the easiest install of any CMS - just copy two files onto your web server.

The reason it's that easy is simple - most of the complexity is handled via off-site JavaScript. The single PHP file is simply the conduit to access your web site files.

Zimplit needs no database - it creates standard HTML pages. Templating consists of you creating your own HTML file. New pages start off as copies of existing pages. It is really very basic. No blog support, no gallery support.

None of that is what prompted me to write this post, though. No, the reason is that I'm sad. It's the Javascript code that's making me sad. You see, Opera is blocked from the WYSIWYG editing features - only IE and Firefox are supported. And I mean Firefox. Seamonkey and any other non-Firefox Gecko browser is also blocked. So is any Webkit-based browser like Safari and Chrome. BTW, an "IE" browser is any browser that claims support for "document.all".

Yep, it's crappy browser sniffing time again. Anyone who promotes the idea of feature detection instead of browser sniffing would be running around in little circles screaming and pulling their hair out right about now.

There are at least two WYSIWYG editors around that are much better - TinyMCE and FCKeditor. Why the Zimplit guys felt they had to reinvent the wheel and then make such a hash of it I don't know.

Apart from all that, what kills Zimplit for me is the dependency on the off-site JS and images. An international communications glitch would leave me unable to edit my site. Or the company could disappear.

Zimplit has too much going wrong now, and potentially far too much going wrong in the future. One to avoid, I think.

Up until now, I've been using code similar to the following to put SVG images on my web pages:

<!--[if !IE]> <-->
<object type="image/svg+xml" data="foo.svg" width="420" height="360"></object>
<!--> <![endif]-->
<!--[if IE]>
<embed src="foo.svg" width="420" height="360"></embed>
<![endif]-->

The common mood on the 'net at large is that the Adobe SVG Viewer (ASV) (the only way to get IE to display SVGs) is not happy with the standards-compliant object element, but works much better with the embed element. The conditional comments ensure that standards-compliant browsers (including the HTML validator) got the standards-compliant code, while IE and ASV got what they wanted.

The problem with that is that it's clunky and duplicates the src/data, width and height attributes, which makes it easy to mistakenly put different values in the two elements.

A recent project of mine involving a web-enabled microcontroller caused me to revisit the above code. I was running really tight on memory, literally counting bytes to get everything to fit. The above code was a good candidate for trimming a bit of fat.

After some searching and trial-and-error, I found that ASV's problem with the object element was nothing more than the type attribute! The above code reduced to:

<object data="foo.svg" width="420" height="360"></object>

So much shorter, simpler and more maintainable!
This has changed, see below. I tested it to work with IE+ASV, Firefox, Opera and Safari(Windows). It also validates, of course. The only caveat is that the web server must use the correct MIME type ("image/svg+xml"), which it should be doing anyway.

The bytes saved enabled me to polish off the last couple of remaining bugs in my microcontroller project without spending ages scrounging around for fatty code elsewhere - with a whole two bytes to spare!



Edit: Last night I was reviewing this and found it had stopped working in IE and Firefox, but I was too tired to be bothered investigating. However, this morning it's working again! It never stopping working in Opera.

Edit2: I've just found the following that seems to be more reliable:

<object type="image/svg+xml" data="foo.svg" width="420" height="360">
<param name="src" value="foo.svg" />
<a href="foo.svg">Demo SVG</a>
</object>

(The anchor is not required, it's just there as a fallback)

Source of above: http://joliclic.free.fr/html/object-tag/en/object-svg.html

The keyboard's smoking this month!

MYOB is an Australian company that produces a very popular software accounting package, not just for Australia, but around the world.

Although they're currently up to v16 (which I expect I'll be upgrading to soon), yesterday I installed a copy of v15.

The help is made of web pages hosted on the local hard drive. They open in the default browser. My default browser is Opera. The help pages don't work.

First stop is to see what they look like in IE or Firefox. Hmmm, there's some menus there that aren't showing up in Opera? I wonder what they're using? Oh, OpenCube!

OpenCube in the past have created problems for Opera with their poor browser sniffing. That's the case here, with only Opera v7 being detected as "v7"; all other versions of Opera (8 and 9 included) being treated as pre-v7! Thankfully, Opera's browser.js comes to the rescue to trick the script into thinking it's dealing with v7 Opera. That means it will load the Opera 7 support code module. That's funny, Opera says it can't load it?

A quick look at the MYOB help file folder reveals the problem: MYOB have included the menu support files for IE, Netscape 6.x, and Netscape (Mozilla/Firefox), but left out the files for the other browsers OpenCube support: Opera, Konqueror, Escape, and ICE!

Now, MYOB is Windows-only, so no support for Konqueror (Linux) and Escape (set-top box) could be readily excused. ICE is a Java-based browser, rather unlikely to be used, but still... There's no excuse for dropping the Opera files, though! And really, there's no reason for any of the files to be dropped! They're only 58K, the CD wasn't that full, and they're for sure not going to fill any hard drive I've seen recently!

Why would MYOB do such a thing? I don't see any up sides, only down sides? Maybe they've changed things in v16?

Anyway, I searched the 'net and eventually found a random website that happened to host an identical version of the OpenCube menus. I popped the missing support files into the MYOB help folder and the help files sprang to life! Not perfectly, but a whole lot better! i.e. I could use them in Opera.

Why, why, why? ...grumble...