Anigozanthos

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.

Many congratulations to the WebKit team on the first public release of Safari that passes Acid3 - the first browser to do so!

This is on the same day that Opera announce reaching 100/100 on the Javascript part of Acid3. Congratulations all round!

The Acid tests are great for bragging rights, but it's important to remember that they test only a tiny fraction of the web technology browsers and developers use. Jeff Schiller points out that while Acid3 has some SMIL tests, the Acid3-passing Safari only passes 5 out 116 SVG animation tests. In other words, SVG animation is still probably unusable in Safari.

Opera doesn't pass Acid1, but that hasn't stopped it from passing Acid2, almost passing Acid3, and being a great all-round browser. The current release of Firefox doesn't even pass Acid2, but that doesn't seem to be causing them any problems.

Ian Hickson has expressed surprise that Acid3 was conquered so soon. It make me feel that perhaps Acid3 spent too much time testing little-used corner cases, that while important, aren't the sort of things web developers are really looking for.

The Acid tests provide a nice, high-profile publicity point for browser developers. They're a quick "media bite" for journalists and those not too familiar with web technology. However, I'm not so sure they progress web standards support that much.

I think I'd much rather see more effort put into developing comprehensive test suites for the various standards. Microsoft recently submitted a CSS2 test suite to the W3C. That type of thing seems to me to be a more productive use of developer's time.

I'm hoping the next Acid test (they'll just keep on coming!) will include features that web developers are wanting to use now. That's not saying the existing Acid tests don't already do that, but I'm thinking of things like rounded corners and multi-column support. I know that the specs for those aren't even done yet - that's why they need to be accelerated and tested. A high-profile test that encourages implementation of useful things, but is still capable of being changed in response to developer experience is what's needed IMHO. I don't think we should be waiting for specs to finalize in their own time. Judicious implementation and testing should be able to force things along faster.

Acid3 is still so new it squeaks, but I'm already looking forward to Acid4!

A few days ago I posted IE, XHTML, MathML, and SVG! with instructions for how to set up a web page that could be served as application/xhtml+xml and contain SVG and/or MathML embedded into the XHTML to not just Opera, Firefox and Safari, but to IE as well.

That could have been a bit soon, though.

It seems every one of those mentioned browsers, except for Opera, supports the additional character entities defined in HTML/XHTML beyond those specified in XML. It means things like " " show as " " in Opera, but are the expected non-breaking space in all the others.

I think this has been reported before, but I'm not sure. It's quite disappointing anyway.

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

<object type="image/svg+xml" data="foo.svg" width="420" height="360"></object>
 

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 latest buzz in the web development world is Apple releasing Safari for Windows. It's a beta of their next version 3 browser.

This basically nixes the vague thoughts I'd had about purchasing a Mac mini. Now I can test all major web browsers directly on my PC.

Apple also compare Safari to other browsers, using the iBench 5.0 benchmark (linked there as I had some trouble finding it). I'm thinking about running my own tests, but it requires Windows Server 2000. Even more annoying is that several third-party components require you sign up for spam before you can download them

What I might try to do is create a virtual machine for all this. I'm not interested in absolute timings, just relative times.

The bottom line is that having Safari available to Windows users (and particularly, Windows web developers), can only be a good thing for the web. That's four out of the five major rendering engines (Trident, Gecko, Presto, and now Webkit), leaving just one (KHTML). The good thing about KHTML is that Webkit is based on it anyway, it's much easier to run Konqueror (eg via a Linux Live CD) than running Safari ever was, and many more people use Safari than use Konqueror.

Edit: The debug menu is available too: Edit "C:\Documents and Settings\<your user name>\Application Data\Apple Computer\Safari\Preferences.plist" using Wordpad, and add:

<key>IncludeDebugMenu</key>
<true/>

Edit2: It seems many people are having problems with no text showing. Frequent crashes may also be related. A thread on the Apple support forums indicates it's to do with the number of fonts installed. Also mentioned are some other possible fixes.