My website has been updated to the newest version of Python Pages, which is already much more powerful. But because I decided not to be compatible with the older version, web pages need to be ported. So, several pages are not yet available here.

I'm not yet going to list all the new features, but something I'm really proud of is the Content blocks link at the bottom of each web page. When highlight_content_blocks=true has been appended to the query string. My master page adds a filter which can nicely display from which file each generated part in my website comes from.

My website has been merged into the new unicycling-style skin.

Also, the Python Pages engine behind got an upgrade, which will make it easier to define the interface between pages.

JD Davis, a belgian DJ created a very nice video clip with some Kris Holm footage.

Just a quick note: my comment system is working now.
It's for very lightweight use. It doesn't require database access and everything is stored in a Python-page. (This would also allow me to insert executable code in my own comments.

Click continue to try it out.

On Twitter, I had a discussion about XUL with Jo about XUL. In short, XUL is an XML based user interface language where the application logic is usually written in Javascript, similar to DHTML. The great thing about XUL is that all the user controls (like tab pages, ...) feel native, while for instance a tab page control written in XHTML often feels a little more faked. I said "feel", because also XUL isn't native. (it is XML, styled with the chrome stylesheet.)

To me, XUL keeps feeling proprietary, because it's part of the Gecko engine, while every XUL-application could have easily been written with XHTML.

Now, I am wondering. Why didn't the XUL team decide to write the XUL-engine itself in true DHTML. Everyone would like to put things like ]]> into an ordinary XHTML site. Probably for performance or security. If they had a reason for this, then why didn't they write the XUL engine as some kind of plug-in, like Gecko does for SVG. We can embed SVG into XHTML, but we can't embed XUL into XHTML. Personally, I'd rather wish XUL to be the XML namespace for native controls. Not only for stand-alone applications, but also to get native controls (like tab pages, calendar widgets, colour pickers, ...) into web pages. The XHTML/JS clones will never be as good as native controls in OS integration.

So, the problem I have with XUL is that after all, it doesn't do much which would be impossible with XHTML and javascript. Some things may be a little easier, but to me it feels like XUL keeps living on its own small island.

Anyway, I think browsers works far from ideal when it comes down to combining XML technologies. I want to nest different XML namespaces in any arbitrary order and manipulate the whole DOM tree with Javascript. I can already embed SVG into XHTML, but why is there no way to do it the other way? This would allow some great transformations (like rotating, skewing, ...) on HTML pages. XHTML in XUL is already possible (Mozilla Firefox does it in some way.), but also this doesn't work the other way around. For XAML -- the XML markup language for .NET applications -- too, if that could be done, that would be awesome, but unfortunately, combining technologies is not easy.

tag, because the behaviour should become part of the whole XML. And the same applies to