Mark Finkle’s Weblog

Mozilla just opened the new source repository (mozilla-central) meaning the next release features will start landing. David Baron posted about landing new CSS selectors. Robert O’Callahan posted about some kick-ass SVG-based CSS effects used to style HTML. This totally rocks and will help push SVG into more of a leading role on the Web.

Look for more cool features, big and small, to start landing with increasing frequency. Some will help chrome developers while others are focused on web developers.

Last year (wow, that long ago?) I made a simple demo to show Firefox 3 offline capabilities. A lot has changed between then and now. Firefox 3 offline capabilities changed significantly to align better with WHATWG offline specification. The biggest changes involve dropping support for our own <link rel="offline"> mechanism and supporting WHATWG manifests and application cache. The specification gives some details on how it works. There is an MDC article on using offline resources in Firefox 3.

Since so much has changed, I decided to update the demo application. Here is the overview of the application, updated where needed:

A Simple Demo - Task Helper

The application is a simple task list system. The current functionality includes:

• Add tasks - Enter text in field and press ‘Add’
• Complete tasks - Mark completed tasks and press ‘Complete’
• Remove tasks - Mark tasks and press ‘Remove’
• Data is stored as JSON and XHR is used to interact with server (PHP)

Nothing fancy. However, the application is “offline-aware”, meaning:

• Application resources (HTML & JS) are listed in the offline cache manifest. This manifest must be served as “text/cache-manifest” and follow the manifest rules.
• Before interacting with server, online status is checked. If online, use XHR. If offline, use DOMStorage.
• Online/Offline status is monitored using events. When the application switches from offline to online, data is resync’ed with the server.

There is really nothing fancy about the offline stuff either, but putting it all together does make for a neat application. Using the latest Firefox 3 (beta 5 or nightly), you should be able to:

• Use the application while online.
• Go offline using the “Work Offline” menu. The event log should show that the app went offline.
• Continue to use the application while offline.
• Restart browser.
• Switch to offline (or have no network connection).
• Enter URL to app (or use a bookmark).
• Start using app with data from last session.
• Switch to online. The event log should show that the app is back online and has updated the server with any offline changes.

Try it: Task Helper
Source code: todo-offline.zip

Note: The data is stored in a simple, shared JSON file on the server, managed with a simple PHP file and reset every hour. No fancy databases with multiple session support.

Web protocol handlers are a new Firefox 3 feature that gives more power to RIA web applications. Basically, when a user clicks on a link with specific protocol, Firefox can send an HTTP(S) request with the link data to a web application. An easy example is a mailto: link:

<a href="mailto:webmaster@example.com">Web Master</a>

Normally, if a user clicks this link, Firefox (or other browser) will open the default mail application on the user’s machine and start composing an email message. With so many web-based email applications in use today, it only seems natural that some people would want to use a web-based email application to compose the message.

With web protocol handlers, the web application can register the specific protocol it wants to handle. Firefox will then prompt the user to choose which of the registered applications (web or desktop) it should use to handle the action. Any protocol, real or imaginary, can be used - mailto: is only one example, webcal:, tel: and fax: are others. In the case of the mailto: example, the web-based email application could parse the data passed to it from Firefox to get the parameters of the protocol, perform a sign-on (if needed) and display its “compose” UI.

Firefox 3 will ship with some packaged web protocol handlers. For those developers interested in adding protocol support to their web applications, we have an MDC article explaining the details of setting up and using web protocol handlers. Also checkout the compliance test page we use to test the feature. During the process of getting the packaged handlers into Firefox 3, we ran into some common implementation misconceptions:

• Web protocol handlers are not just for mailto:! The system is designed for any protocol.
• Web protocol handlers have no idea about the protocol details. For example, the system does not know that mailto: support to or subject parameters. The system just sends the entire HREF of the link to the registered handler. Be prepared to do the parsing yourself.

Go forth and make web applications rock!

Zoho’s recent blog post about why they used JavaScript and not Flash when building their offline version of Zoho Writer has led to some interesting but somewhat predictable responses [1] & [2]. I could have fallen into a predictable (but not necessarily interesting) response myself, but didn’t. Until I saw Ryan Stewart post the following:

I don’t think it’s an accident that Zoho and Buzzword have such different design goals or that Flex applications generally tend to look more sophisticated than Ajax applications.

That quote (and the post) seem to suggest that AJAX webapps are less usable, less sophisticated and, generally, not as pretty as their Flex counterparts. Likely not Ryan’s intent and I did say “seem to suggest” right? I usually don’t define usability based on how an application looks, but on how productive I am using the application or how easy I can learn the application. Unfortunately, some applications try to get by on looks alone. I try to see the inner beauty.

ActiveState is ready to start rocking the OpenKomodo project. They have everything ready to go:

• The Wiki
• SVN source code repo
• OpenGrok source browser
• Bug tracker

All they need now is YOU! Head over and get involved. You can also start thinking about SnapDragon, the full-featured web development tool integrated with Firefox:

Komodo Snapdragon is an idea, a desire, a mission! Web development with Firefox benefits from excellent developer tools such as Firebug, but it needs more. We invite you to help define the future of Komodo Snapdragon. Join the Open Komodo community today and help shape the future!

Great mission! I look forward to SnapDragon planning and development.

Mozilla endeavors to promote open standards, while at the same time, create a better Web, even if it means using the “other guys” specifications and DOM extensions. Here is a summary of features added to Firefox 3 (Gecko 1.9) that either implement a good open specification or someone else’s DOM extensions - for the betterment of the Web:

WHATWG Web Applications (link)

• Experimental <a ping> support (bug 319368, current spec).
• You can now register web applications as protocol handlers using the navigator.registerProtocolHandler() method.
• Online and offline events are now supported, allowing applications and extensions to detect whether there’s an active Internet connection available or not. See navigator.onLine
• The getElementsByClassName() DOM method is now supported (bug 357450).
• <canvas> element transform() and setTransform() methods support (bug 365886, current spec).
• contentEditable support (current spec).
• Drag and Drop events are now supported (bug 375681). Whoops, not quite yet! (bug 356295)
• Focus management APIs (activeElement & hasFocus) are now supported (bug 337631, current spec).
• Offline resources is in progress (bug 367447 and dependencies, current spec)

Internet Explorer DOM Extensions (link)

• clientTop and clientLeft DOM extensions are now supported.
• elementFromPoint DOM extension is now supported (bug 199692).
• oncut, oncopy onpaste, onbeforecut, onbeforecopy and onbeforepaste DOM event extensions are now supported (bug 280959).
• getClientRects and getBoundingClientRect DOM extensions are now supported (bug 174397).
• The HttpOnly cookie extension attribute is now supported (bug 178993).

Yes, some of the Internet Explorer extensions are also WHATWG specs.

Not Invented Here? Not a problem

Adobe’s Ryan Stewart has a post on the friction between Open Web advocates and “RIA vendors”. I think Ryan does a good job describing the work being done at Adobe (and Microsoft) to become active in a larger ecosystem, namely open source and cross-platform. There are a couple bits I want to respond (emphasis mine):

I think it’s indicative of wider problems between the “open web” and RIA vendors. The basic issue is that everyone’s too combative. I wish more open web people would look at what both Microsoft and Adobe are doing and see that all in all, the RIA solutions are becoming more open, not less. In fact, I’d argue that RIAs have moved the entire web in a more open direction.

I think Ryan’s use of the term “RIA” to indicate a “proprietary vendor plugin” will cause confusion. Rich Internet Applications can be created without the need for proprietary vendor plugins. Also, what Adobe has done around open sourcing parts of their plugin system has been welcomed by everyone. However, there are still large chunks of closed source and encumbered file formats that work against the Open Web.

I’m not sure if RIAs will ever be as fully open as the open web advocates want, but think how far applications in the browser have come (as far as openness) since the days of ActiveX enhancements in IE.

As I have stated, RIAs can be fully open and, as a card carrying Open Web advocate, those make me happy. However, how far have Adobe and Microsoft come from the days of ActiveX vendor plugins? Last time I checked, ActiveX was still the technology of choice for Flash and Silverlight on IE. Honestly, even if Flash and Silverlight were completely open source, the fact they are plugins and not native Web standards will be a stumbling block for many Open Web folks.

They’ve [Flash and Silverlight] pushed the web forward in a way that it seemed the open web groups couldn’t (video, vector graphics, easy cross platform/browser development).

Yes, they have pushed the Web forward, I’ll admit that. The resurgence of SVG and the new <video> & <audio> elements are evidence of that. But then Linux is a platform too, and I suppose that Mozilla could market Firefox as the one, true cross platform Web platform - but we don’t. We encourage choice and competition. We want developers to have choice too and not be locked into a single stack. Let me know when Flash can run a Silverlight application.

Mike Shaver responds in a comment to the post.

Joel’s latest strategy letter is a long-winded diatribe on the current state of browser-based application development. There is some good stuff in there, but some of the metaphors are really stretched and the comparisons between desktop and web-based applications is a bit broken. Joel seems to think that web-based applications should support the same kind of features as desktop applications. This line of thought can only go so far.

For example, cut and paste between applications. I assume Joel wants to copy more than text from edit boxes and selected HTML from the page. No reason this couldn’t be done today (Live Clipboard anyone?) but doing so requires cooperation between the applications in question. The Web platform already supports it. And hey, the same kind of limits occur on desktop applications. Try pasting an Outlook contact into Quicken. On the Web right now, microformats and mashups provide functionality not easily possible in desktop applications.

Joel also brings up lack of UI consistency in web applications. Not so sure about this one. I believe a little bit of consistency goes a long way and many web applications share common UI elements and concepts. Let’s not forget just how consistent desktop applications can be. Microsoft Office seems somewhat consistent with its applications, except for the ribbon is missing from some. Sure, it may not be appropriate in all applications. I’m fine with that - just not overly consistent. And take a look at the UI’s of “web-style” desktop applications and media players and tools like Microsoft Expression (best if viewed with Silverlight). Again, just saying a little consistency goes a long way.

Finally, we get to the “NewSDK” concept. The super-do-it-all framework that all web applications use and Joel compares this to Microsoft Windows and the Windows SDK. Personally, I would be comparing the Web to Windows, not some framework that runs on the Web. Compare that “NewSDK” framework to MFC or WPF. In a followup post, Joel responds to readers who forwarded their version of the “NewSDK” by saying:

Indeed countless people have already emailed me to say that “NewSDK is here, it’s (choose one) Flex Builder, Google Web Toolkit, Java Web Start, Silverlight, JavaFX, Flash, ActionScript, MORFIK, OpenLaszlo, … (many omitted)” Ahem. These are not HERE until your TAXI DRIVER has heard of them, because I assure you he’s heard of Microsoft Windows.

Again, he’s comparing apples to oranges. Ask your TAXI DRVIER if he’s heard of the Internet. And again, I’d use MFC, WinForms, VCL as desktop examples of the “NewSDK” examples listed in the quote. Ask him if he’s heard of WPF.

Here’s another quote that rubbed me the wrong way:

If you’re a web app developer, and you don’t want to support the SDK everybody else is supporting, you’ll increasingly find that people won’t use your web app, because it doesn’t, you know, cut and paste and support address book synchronization and whatever weird new interop features we’ll want in 2010.

The ideas in this quote are exactly NOT what the Web is about. This is anti-Web. Forcing interop by mandating a framework is ridiculous in a place where open standards and formats are embraced. Web development can and is improving, but let’s not try to turn the Web into Windows. Of course, some people already are.

Firefox 3 is expanding its rich WYSIWYG editing capabilities by adding support for the contentEditable attribute. Setting contentEditable to “true” allows you to make parts of a document editable. Firefox already supports using designMode to make an entire document editable. Here is a previous post about using designMode.

Here is an example of using contentEditable to make a simple rich editor in HTML: contenteditable.htm
(NOTE: requires Firefox3.a6+ or a browser that supports contentEditable)

The new contentEditable features support the same API as designMode for interacting with the editable element:

• document.execCommand - Executes the given command.
• document.queryCommandEnabled - Determines whether the given command can be executed on the document in its current state.
• document.queryCommandIndeterm - Determines whether the current selection is in an indetermined state.
• document.queryCommandState - Determines whether the given command has been executed on the current selection.
• document.queryCommandValue - Determines the current value of the document, range, or current selection for the given command.