Simon Willison's Weblog: contenteditable

Two revolutionary features in Opera 9

2006-06-20T23:42:18+00:00

Wow, if I'm not careful this is going to turn in to a promotional blog for Opera.

So, I've been playing with Opera 9 which came out earlier today (in a dual release for Windows and Mac, which is refreshing). It's an impressive package - it's fast, it renders every page I've throw at it so far, it passes Acid 2, supports Canvas and SVG and has a neat widgets implementation. Performance on Google Maps is a bit sluggish but other than that it's been extremely snappy. The tab screenshot thumbnails are a nice touch.

There are two features however that set it head and shoulders above its competitors in terms of raw utility:

You can browse cached documents offline! I'm not sure when other browsers forgot how to do this but it's been years since I've been able to unplug from the network and still view pages that have been saved in my cache.

In fact, this feature is almost too effective: I had to keep double-checking to make sure my WiFi was definitely turned off. A visual indicator that you are viewing an offline document would be a very useful addition.
You can quit your browser and reopen it to the same state. Other browsers have been slow to cotton on to the fact that my browser state is important data - I frequently leave interesting pages open for days at a time and a browser crash causes me real pain. Safari and Firefox both have extensions that enable this but it's great to see it built in to the core product.

Sadly, Opera doesn't persist partially completed form data (so you'll still lose that half-written blog entry if you weren't smart enough to write it in a text editor and paste it in at the last moment) but it's still a huge improvement over the rest.

As far as I can tell those two features have been in Opera since before the current release, but I'd never noticed them before. Here's hoping other browser manufacturers follow suit.

While the interface is leaps and bounds ahead of Opera 6/7, it still has a few crufty edges: the preferences are hard to navigate, the text in the tab screenshot window comes across as an afterthought, there's a randomly placed recycle bin in the upper right hand corner and it took me a while to find a skin I liked (tango cl). The default behaviour for command-clicking a link is to open a new tab and switch to it; my preference is for opening in the background but I can't work out how to change that option (though shift-command-click does what I want). Overall though it rates extremely well.

As usual, it's worth looking over the detailed changelogs (windows, mac). There are some real gems for scripters; Here's the list in full:

Added support for XSLT 1.0 and the XSLTProcessor constructor.

Added support for XPath 1.0.

Added support for DOM level 2 Style Sheets and associated parts of DOM level 2 CSS.

Implemented designMode for rich text editing.

Added support for the CONTENTEDITABLE attribute and contentEditable property.

Implemented support for canvas, as described in the Web Applications 1.0 draft, as well as the opera-2dgame context.

Added support for Audio, as described in the Web Applications 1.0 draft.

Multiple improvements to XMLHttpRequest support.

Added support for onmousewheel events.

Added support for document.load and document.adoptNode.

Added window.getSelection and associated methods.

Improved handling of offsetTop, offsetLeft, and offsetParent.

Removed support for "javascript:" URLs in CSS.

Pages using certain JavaScript events will reload when visited in history. A knowledge base article is available.

I'm going to use Opera 9 as my default browser for the next week or so to see how well it holds up. I'll report back on the experience later.

Tags: browsers, opera, opera9, contenteditable

Safari 1.3 is out (via Software Update)

2005-04-16T15:51:54+00:00

Safari 1.3 is out (via Software Update)

New features include contenteditable support, XSLT and a major performance improvements.

Tags: safari, xslt, contenteditable

Safari to get contenteditable support

2004-07-03T23:47:13+00:00

Safari to get contenteditable support

Adopts another defacto standard (the last was XMLHttpRequest).

Tags: safari, contenteditable

contentEditable in Mozilla

2002-10-17T13:53:03+00:00

ContentEditable for Mozilla is a hot topic at the moment. The main focus of the debate is this bug on Bugzilla, which gets pretty heated. Blogzilla has a good explanation of the principles behind the disagreement, while Scott Andrew makes an excellent case for copying IE's implementation:

To my knowledge, no W3 working group is discussing how to implement editable content directly in a Web page, so the question remains: do we follow IE's de facto standard, or wait for a standards body to hammer out one?

Tags: mozilla, contenteditable

Browser based rich text editing

2002-09-04T16:56:05+00:00

Scott wants a rich text editor for Mozilla. What's more, he's willing to put his money where his mouth is and organise a fund drive to give developers a real incentive to do a good job.

At Incutio we have a long history of messing around with rich text editors. I wrote an IE DHTML editor (similar to the one used by Radio Userland) least year which is still in use in our flagship CMS. We are currently looking at replacing it with a Flash editor, which will give us both cross platform compatibility and a better level of control over the HTML. Put simply, MSHTML generated code is absolutely revolting. It's made worse by the fact that people can cut and paste from Word, Excel and even other IE windows, preserving the formatting every time. Great for picky users but a nightmare for us web developers who are trying to keep the visual look of a site constant. And you can forget about standards compliance...

With CSS finally at a stage where we can properly start to separate structure from presentation I think WYSIWYG editors are far less relevant today than they were a year ago. XHTML is about semantic markup, with presentational stuff being relegated to the site developer controlled stylesheet (where it rightly belongs). Any page editing tools need to concentrate on helping users mark up content in a meaningful way rather than letting them chose their favourite colours and fonts.

That said, I strongly believe that the Mozilla project should invest considerable effort in browser based editing tools. Web based interfaces are here to stay, and a lot of people spend large chunks of their day creating content in a browser. Rather than relying on wizzy and unstable javascript tricks though I think we should go back to basics and reconsider the textarea. Imagine a textarea element that, when double clicked, spawned a brand new editing environment in a new window with all of the tools of a modern text editor. Or how about the option to spawn Composer (Mozilla's built in HTML editor) with the contents of a textarea, then click a button to have your newly created HTML dumped right back there? I haven't looked at Composer properly so I have no idea how standards compliant it is (or isn't) but it's already built in to the Mozilla suite - why not integrate it with the one part of the browser that needs it the most?

At the end of the day, I suppose anything that enables more people to publish to the web has to be a good thing - especially if it enables more people to make the switch from IE :)

Incidentally, xopus.org have an interesting partial implementation of contentEditable for Mozilla. They have also just released the open source version of their impressive browser based XML editor. One to watch.

Tags: mozilla, contenteditable