Claws, fangs, fur...

Good points:

• installs without needing Admin privileges (increased computer security)
  
• seems to start up fast
  
• allows to set chrome language apart from preferred web site language
  
• some redraw problems with the rendering of embedded media
  
• javascript parsing seems pretty fast
  
• has developer tools like Opera's Dragonfly
  
• loads faster than Apple Safari though both use the same rendering engine (WebKit)
  

Bad points:

• installs and activates an updater service without asking (decreased computer security)
  
• completely ignores the colour scheme specified in the operating system by the user (especially problematic for people with bad eyesight like me)
  
• in the options dialogue: partially takes on the user colour scheme (good) and partially uses its own scheme (bad) which results in completely unreadable texts (black text on black background) (unusable)
  
• detected my location or my OS language, and automatically selected the local language as the preferred language
  
• page rendering is provided by AppleWebKit (Safari)... the fact that Google failed to publish a Linux version is inexplicable, since WebKit itself is meant for a Unix variant...
  
• WebKit has some issues with respecting the user's colour scheme settings
  
• WebKit has some issues with recognising HTML5 elements like the audio element, and does not recognise Vorbis nor Theora sources on my system
  
• Complete failure to include accessibility options, as opposed to every competitive browser
  
• No warning for mismatched security certificates
  

Conclusion: Google's Chrome is a knock-off of Apple's Safari, with a faster shell.

For those interested in the technology behind the new layout engine of the OmegaJunior.Net (which, entirely uncoincidentally, is my personal web site), here's a bit of disclosure.

The layout engine is a single PHP file that accepts an article name as its only parameter. The article name matches a folder name. If no such folder exists, a 404 message will be presented to the browser.

If such a folder does exist, the layout engine looks for a couple of files, named exactly the same in each folder. This is similar to reading fields in a database record... without the database.

For each file that is found, a layout is generated. The title file is echoed into the page title, the description file is echoed into the page description. The body file is parsed using a BBCode parser borrowed from someone else: that allows for a rather basic mark-up, which suffices for most of my needs. The links file is parsed as an ULHTMLElement, containing a list of hyperlinks. The rest is static text in the layout engine.

The layout engine is extremely simple. The data storage is extremely simple. The CSS is extremely simple. Using the BBCode in the article's body is extremely simple. The impact however, is extremely high.

It's quite a bit of work to update the entire site, seeing how many articles I've published thus far. And though it is a lot... it remains easy.

I'm a professional CMS implementor. I've seen a couple of CMS-es and a couple of internet forum and discussion board systems. Of course, those systems sport a user administration, version control, article workflow and moderation, caching mechanisms... but mine is an extremely fast, easy to use layout engine, coupled to an extremely easy to use storage and update system.

KISS (Keep It Simple, Stupid) will be my motto for now.

With KISS, I can ignore the site's layout engine, and concentrate on the contents of the articles, which most of the time is not so simple.

Just to see whether I could make sense of the specification-in-progress, I decided to create HTML5-versions of several of the pages in my website, including its homepage. Conclusion: it's feasable, but I'm sure less experienced web authors could use a "Web Authors' Guide to HTML5" (yup, this counts as prior art ).

I proceeded to testing how web browsers by various manufacturors displayed that HTML5-page. The results:

• Opera 9.27: pass
  
• Safari 3.1: pass
  
• Firefox 3 (latest nightly build): pass
  
• Firefox 2: fail
  
• Internet Explorer 7: fail
  

Haven't tried it in MSIE8 yet... I'm part of the feedback program but I didn't want to risk having that beta application wreaking havoc on my system.

Now what's interesting about that list?

Wait, what? Opera 9.27? Does it know HTML5? It may have some basic understanding but I doubt Opera implemented the entire spec... if only because the spec is being developed as we speak. So how can it pass this test? And how is it that Firefox 2 and Microsoft's excuse for a browser fail?

My best guess: it's because of the way browsers handle unknown elements.

Huh?

Point in case: HTML5 has a SECTION element. With it, an author can divide just about any part of the body in, you guessed it, sections. How should such a section be rendered? Should it be a block? A table row? A floating square? The specification doesn't say... it leaves that directive to CSS.

So what should a browser do, when running into an element it doesn't recognise? It could simply ignore the element... but none of the current major browsers chose that option. Bravely, they try their best at displaying it anyway.

With one major difference:

where some browsers (Opera 9, Safari 3, Firefox 3) display the unknown element and apply CSS and javascript rules to that element as provided by the author, some others (Internet Explorer 7, Firefox 2) display the unknown element bare, meaning without CSS and / or without javascript.

Why? Is it a strategic management decision? Is it developer short-sightedness? Is it a technical difficulty? And if so, in what part of the browser? In the HTML-parser, or in the CSS-parser, or in the javascript parser? In all 3? Somewhere else?

It can't be a technical difficulty. After all, all of the tested browsers can handle XML and do render CSS on XML documents... and XML by definition is riddled with unknown elements.

It shouldn't be a CSS-parser problem, as the CSS that I wrote isn't all that difficult and does work when applied to known elements.

It shouldn't be an HTML-parser problem, as all of the tested browsers are well-adept at handling TAG SOUP, especially Internet Explorer (yay, history!).

So that leaves... that leaves a browser trying to render TAG SOUP using standards-compliant render-mode for a doctype that has no DTD where one is expected. It is one thing to have NO doctype, as is the case with many XML documents. It is quite another, to have a document that claims to have a doctype and then breaks the rules by providing neither a public nor a system identifier... which is normal for HTML5, but not for HTML4 nor the XHTMLs.

So unless a browser is instructed to handle such cases, it will behave in unexpected ways. If anything, the fact that both Internet Explorer 7 and Firefox 2 do display the unknown elements shows that the developers did expect some unexpected authoring and made sure their browsers wouldn't crash, which is quite commendable. That makes the fail largely a strategic management decision.

Conclusion: Microsoft's flagship browser and Firefox 2 don't necessarily fail at HTML5... they simply fail at handling unrecognised doctypes altogether.

There are multiple ways to create circular charts and diagrams. Usually, a chart is created by a server application, and served as an image to be included in a web page. This has all the usual advantages.

But what if the data for creating a chart / diagram isn't on the server? With all the new AJAX- and other javascript based web applications, the data might live in the client's computer only... it'd be downright silly to send these to the server if the only objective is to have a chart created. (Silly for obvious reasons: speed, bandwidth, server load, security, etc.)

So... if the data exists in the client, why not generate the charts in the client too?

Because browsers don't do graphics.

Sure, they can display graphics, and create new image objects too... but they aren't meant to be a drawing canvas. Any web application allowing such is either based on a plug-in, or an approximation of a drawing application.

Ah, you say, what's wrong with the java, flash, and active-x based plug-ins that allow us to draw up charts and diagrams? Surely they can work with data from the client?

Few things are wrong with those... except for the fact that they are plug-ins. How many browsers do you know that support SVG natively? Microsoft's flagship browser doesn't... instead it offers Microsoft's own variety of xml drawing, supported by no other browser. This means that authors are forced to continue catering to various browser and / or plug-in vendors.

No, thank you.

And some of you may even know that HTML5 will house the CANVAS element, for easy drawing purposes, including circles... however the few implementations I've seen don't work together yet.

Thus I came up with JCC: a method to create circular charts and diagrams using a few images of a disc, a bit of CSS and a bit of unobtrusive javascript.

Currently the methods are able to showcase the technology, but don't allow for real integration with data, yet. That will be the next step.

Examples include:
- 2 circle diagrams
- 3 Venn diagrams

Please note that Venn diagram programming is a specialty I have yet to master. As such, the method showcased is merely an example, ready to be improved by those in the field of programming Venn diagrams.

Also note that the examples in their current state work on 3 browsers:
- Opera 9 and newer (possibly including Opera Mini and Opera Mobile)
- Safari 3 and newer (and thus all kinds of KHTML browsers)
- Firefox 2, 3 beta and newer (and thus all kinds of Gecko browsers)

Thus far only Internet Explorer 6 fails to render the diagrams correctly, due to margin inconsistencies and lack of 24-bit Alpha Transparancy. Internet Explorer 7 does manage to render the diagrams, but miscalculates the image placement. Some tweaking may be needed.

Of course it doesn't stop here. What about pie charts? What about animated discs? What about hyperlinks on each section of a chart? Plenty of room to improve, I'd say.

Link: Javascript Charting

As soon as the HTML5 CANVAS element is implemented in mainstream browsers, JCC will be a thing of the past... but in the mean time: game on!

Death to document.write()!

Why should we kill the trustful document.write()? It's been around for ages and serves good purpose in lots of web sites!

It's because Google Maps and other web sites continue to use document.write() in XHTML pages, where it is harmful to the web pages and destroys functionality. Google Maps also uses it in their examples, teaching new script adepts wrong techniques. (Outlined in this other article.)

(By the way: the problem is not in the XHTML... nor is it in using document.write() in application/xhtml+xml, as in that mime type the browser simply refuses to execute it. No, the problem is in text/html, where it bloody well overwrites the current document. Wyciwyg...)

There is a different way.

The document.createElement() function (javascript, DOM 1) can create a script element. (Of course, once created and identified, we can reuse the same script element over and over again.) Using element.setAttribute() we can assign a script source. Then we append the new script to the document and we're set.

Here's the code, which I succesfully applied in a different page on my site, including a call-back inside the external script... resulting in a complete and utter annihilation of AJAX-need.

if ((document)&&(document.createElement)) {
 var theNewScript = document.createElement('script');
 if ((theNewScript)&&(theNewScript.setAttribute)) {
  theNewScript.setAttribute('id','myNewScript');
  theNewScript.setAttribute('type','text/javascript');
  theNewScript.setAttribute('src','http://domain/dir/script.js');
 }
 if (document.body.appendChild) {
  document.body.appendChild(theNewScript);
 } else if (document.documentElement.appendChild) {
  document.documentElement.appendChild(theNewScript);
 } else if (document.appendChild) {
  document.appendChild(theNewScript);
 }
}

Oh yeah. The script you inject this way, should not contain any document.write() statements itself... In application/xhtml+xml they won't work, and in text/html they may overwrite the entire document... I created a test case for this specific issue:
http://www.omegajunior.net/code/javascriptinjection.php

Happy coding!