The state of in-browser WYSIWYG is somewhere between pitiful and mind-numbingly painful. Opera and Safari have pulled themselves up by the bootstraps and soon all the major browsers will be at the same level of awful, more or less. This area of DHTML doesn't get much love from browser vendors in part because only the heartiest souls ever venture into these deep, shark-infested waters so there aren't many people clamoring for fixes to the underlying capabilities. Everyone sane just picks up the Dojo Editor, TinyMCE, or one of the other good editing packages that are available.
Since recently delving back into the Dojo editor for the 0.9 release I've been chewing on the problem some more, and I think the solution is fairly simple in terms of the APIs which toolkit authors should expect of browser vendors. The goals of editing generally boil down to:
- Allow users to apply formatting to stuff they have
- Let users add new stuff
- Allow users to undo stuff they did
- Serialize the stuff users have done and, optionally, the undo stack
The current contentEditable/designMode systems fail in the undo case because (particularly on IE) it's not possible to denote what is and isn't an "action" that the user is doing, nor can you be informed by the browser when it pickles off a new state to the undo stack. This means that the undo stack captures things which aren't changes in your editing area and may appear to be "broken" by UI feedback that you provide to users in other ways.
Since it's not really reasonable to expect that browsers will remove
contentEditable, here are my proposed APi additions to it which would allow any sane editing UI to ditch the entire command structure which can slowly fade into the background over time.
editableElement.openUndoTransaction(callbackHandler): starts an undo transaction, implicitly closing any previously opened transactions. All subsequent DOM manipulation to elements which are children of this element will be considered part of the transaction and normal browser-delimited undo transaction creation is suspended until the transaction is closed. The optional callback handler is fired when the user cycles back this far in the undo stack from some future state.
editableElement.closeUndoTransaction(): ends a manual undo transaction. Implicitly called by openUndoTransaction. Closing the transaction has the effect of pushing the current DOM state (or whatever differential representation the browser may use internally) onto the browser's undo stack for this editable element. When an undo transaction is closed, browsers may resume automated generation of undo states on the stack intermingled with the manually added states.
- Support for non-standard DOM positioning properties of range objects as outlined in MSDN
These APIs added to elements with
contentEditable set will allow us to use regular-old DOM methods of manipulating user selections and adding complex content from user input without fighting for control of the undo stack or inventing our own (which has so many problems that I don't want to begin to address them). Additionally, this method of manipulation will allow toolkit authors to deliver editors which operate on the semantics of the markup more easily.
Note that we suppose the current uneven level of Range and DOM APIs will persist over time, and some things may get easier over time in conjunction with these APIs as those problems are slowly alleviated. Additionally, interaction with the global undo stack for the browser is as-yet unspecified. I'm inclined to suggest that unless the editable element has focus, undo should not affect it but my unfamiliarity with the implementation of the global undo stacks in browsers may nix that and require a broader solution. There may also need to be methods for ignoring a particular set of DOM operations (say, from event handlers) to prevent browsers from taking snapshots at bad times, but I think we can ignore that for now.
Lastly, there is probably room for an API to register interest in any undo operation and to push things onto the browser's undo stack for non-editing elements, but this API solves the problem where it is most accute today.
I wrote this post well ahead of the release of IE 7, and I've been holding back on writing a follow up until things seemed reasonably settled. A year and a half since that post, and almost a year since IE 7 hit the streets, I fear things are more settled than anyone would like.
The "worst case scenario" that I've described to folks in private for a long time is that IE 7 is the end of the line. The last hurrah. The final gasp of life in Trident's creaking limbs. IE 7 could either signal the beginning of a renewed commitment to the web by Microsoft, or it could be the minimum MSFT can get away with to prevent customer mutiny. To assuage the latter scenario, I've directly and firmly asked every member of the IE team I've talked to since then to outline in public Microsoft's commitment to new versions of IE. We need to see timelines, feature targets, and distribution plans for those releases as well. This might seem like putting the cart before the horse but I think it's not too much to ask. In fact, it might even be the minimum the web development community should expect.
To contrast the IE commitment to a better future with Mozilla's, it's instructive to look at the roadmaps for each. Brendan Eich has an entire blog dedicated to communicating outward about the features that we can expect from the web as delivered by Firefox (and the platform behind it). The IE Team's blog is eerily silent on the future of what is still the most important browser on the internet. We're reduced to getting information from third parties and conference talks. The features planned for Firefox 3 are impressive and the work is being done in the open, meaning it's easy to have confidence that not only will Mozilla ship what they say they will, it'll be here when they say it will. Same goes for the excellent work the Safari team has been doing. Even Opera keeps its community on fire by shipping regular updates, showing tech previews at conferences, and blogging about the progress being made on many fronts. If the IE team is holed up working on something stonkingly good, they certainly aren't doing themselves any favors by not telling us about it. The result of their radio silence isn't mystery, it's distrust. Deep, divisive, troubling distrust of the kind you can only get when folks who break up stop talking altogether. The problem is that IE still has half of my DVDs and my friends keep telling me it's just using me. Not a great way to rebuild a relationship.
Part of the distrust springs for what wasn't in IE 7.
We did get some good things, of course. The tireless vendor-focused work of Molly Holzschlag and other (relative) pragmatists in the standards community helped get a lot of the most egregious issues fixed. But for as important as those fixes where, they were important in a historical context. They helped enable better versions of what we started to develop with in 1998.
When I caught up with Ted Leung at OSCON this year, we had a long discussion about "RIA's" in general, but in talking with him it became clear to me how little of what we (rich app developers) needed was delivered by IE 7. Of the 10 items on my off-the-cuff list, only gzip issues and memory allocation have been substantively addressed. And quite frankly, it was a reserved list; it only included things that might have been hard but shouldn't require fundamental architectural changes. Progress has been made on memory leakage, but we're still finding new leak patterns that need guarding against.
And then there are the regressions. On my list from last year was VML, and far from fixing its performance IE 7 broke critical VML functionality. Yes, yes, VML is old, bad, silly tech, but then so is the rest of what we've got to work with out here on the open web. Microsoft has subsequently released Silverlight which we're using to hack around some of VML's liabilities for limited situations, but we might as well be using Flash or Java at that point. Silverlight has nearly zero market penetration and it's yet another "draw in a little box" solution which isn't Open Web tech. Yawn. The IE team also removed the only WYSIWYG infrastructure that was worth a damn in their browser. The only reason web developers didn't raise holy hell over this is probably that every other browser is worse than even the IE fallback position.
Judging IE's progress feels like making excuses for a rotten kid with absentee parents: at some point explanations cease to matter and the behavior itself needs to be addressed. I'm not giving up on IE's potential, but it's harder and harder to trust that the baby steps taken with IE 7 are going to solidify into a pattern of real progress when we've gone a year without any real communication from Microsoft as to what's next.
I'm pretty sure the IE team isn't sitting still. Chris Wilson is heading up the HTML 5 working group and there's reports of some real progress there. HTML 5 is the most important web spec under consideration anywhere so this is truly good news. But it hasn't yet been accompanied by the kinds of communication that allow us to trust MSFT as a custodian of the web's future.
Getting IE 7 and watching it ramp up among IE's installed base has been good, but it's only half the answer. The web needs to know, unequivocally, when we can expect more information about IE.Next, what OSes it will target, and what standards, improvements, and major fixes are on the roadmap even if they slip. Without that much honesty, this relationship probably won't get off the ground again.
Last week we released Dojo 0.9, and while we're excited at how well it performs, how easy it is to use, etc. but the proof is in the apps. In particular, Plaxo Pulse, AOL's TinyBuddy (app here) and the new Bloglines beta are all 0.9 based and the experience really shows it. They're all "data stream" apps, things you fire up and then leave open or spend lots of time in, and they're amazingly useable, responsive, and useful. If you haven't tried them out, now's the time to give them a whirl and get a feel for how 0.9 is helping real apps rock.
SitePen is hiring.
To be honest, SitePen is usually hiring, so why the blog post? Because I'm hiring for a SitePen R&D Associate. This isn't your average programming job. Not only will all the work from this new position be released as Open Source software,it's a self-directed research job. Combined with SitePen's completely-virtual structure, you can work on what you feel is important and live wherever you want.
Read on for the full description:
R&D Associate (title negotiable)
SitePen is a fast-growing services company with deep roots in Open Source web software and an ongoing commitment to give back to the Open Web. The problems we solve for clients sit at the intersection of Computer Science and Interaction Design while cutting across a wide variety of problem domains. As an R&amp;D Associate at SitePen you'll be responsible for investigating and developing solutions to the thorniest problems in real-world web application development and since everything you do will be Open Source, your impact will be both meaningful and lasting.
Some topics currently of interest to SitePen include:
<li>web framework scalability</li>
<li>ES3/ES4 implementations across VMs</li>
<li>publish/subscribe messaging and scalability</li>
<li>web-based interaction design/analysis tools</li>
<li>Open Data portability and metadata normalization</li>
<li>browser-based data visualization</li>
But those are just the problems that keep us awake at night. What we're <em>really</em> interested in is hearing about how you'd like to make a difference in the evolution of the web. At SitePen, you'll have the freedom to pursue your interests and a mandate to work with broader communities to make your ideas reality.
<li>contributor to at least one Open Source project (active committers preferred)</li>
<li>fluent in one functional or scripting language (C experience a plus)</li>
<li>must be able to author technical papers</li>
<li>must be comfortable presenting and defending work to groups of various sizes</li>
<li>permanant legal right to work in the United States</li>
<h3>How To Apply</h3>
Send a plain-text email to "firstname.lastname@example.org" with the subject line "R&amp;D Associate Application". In the body of the email, please explain why you think you'd be good for the job, what research interests you would like to pursue, and if you have one, a link to your website/blog. Please include links to your Open Source involvement and note major contributions (planning, design, features implemented, research contributed, UI/UX/IxD, etc.). Also, either include a link to an online resume or attach one in plain-text or PDF format.
There is no deadline for application, but the earlier you apply the better your odds.
<li>Senior Engineer grade pay</li>
<li>Comprehensive health insurance</li>
<li>All work product Open Source</li>
<b>Location:</b> anywhere you damn well please. SitePen is an entirely virtual organization.
<b>Travel:</b>10-25% travel, depending on personal choices regarding conferences and symposiums. Presenting papers and speaking on your work is encouraged.
<b>Job Type:</b> Full Time
<b>Reports To:</b> Director of R&amp;D (Alex Russell)
Uniquely for an R&D job, there are no minimum education requirements. We only care how effectively you can advance the state of the art on the Open Web. If that sounds like a calling you can get behind, I'd love to hear from you.
Scott Beale's Paradise Lost party was outstanding. Jennifer and I have kind of "dropped out" of the Web2.0 scene for lots of very obvious reasons, but every now and again it's wonderful to see everyone. Folks were bummed about the lack of the planned fire displays (darned city permitting!), but the Photo Boof was awesome.