Friday, March 6th, 2009
The Road to HTML 5: spellchecking and contentEdible
I am sorry, but I can’t help but write contentEdible for some reason :) Mark Pilgrim has been pushing forward with his series on HTML 5, and recently has a couple of interesting dives:
The feature of the day is spell checking, by which I mean client-side in-browser checking of text in standard <textarea> and <input type=text> elements. Several browsers support this out-of-the-box, including Firefox 2 and 3, Safari 3, Opera 9, and Google Chrome. However, each browser has different defaults of which elements get spell-checked, and only a handful allow the web author to suggest whether browsers should offer checking on a particular element.
In this article:
- A brief history of the
spellcheckattribute - Examples
- Browser support
- Detecting support for the
spellcheckattribute - Conclusion
Welcome back to my semi-regular column, “The Road to HTML 5,” where I’ll try to explain some of the new elements, attributes, and other features in the upcoming HTML 5 specification.
The feature of the day is contentEditable, by which I mean client-side in-browser “rich text” editing. All major browsers support this now, including Firefox 3, Safari 3, Opera 9, Google Chrome, and Internet Explorer (since 5.5). Of course, the devil is in the details.
In this article:
- What is
contentEditable? - How does it work?
- A brief and extremely biased timeline of standardization
- Conclusion
- Further reading
contentEdible? Can you really eat the content? Yummy! I think you mean contentEditable
uhm … I have implemented spell check for IE as well (textarea if you want but inside Ext.JS editor too extending it, for example) but I did not know about this spec … (and obviously IE8 is out of the box, right?)
For those interested, BJSpell is the project name, in Google Code as well.
It’s a bummer that only FF support the spellcheck attribute it’s a good thing to have this in the HTML5 spec so every other browser vendor implements it. It’s pretty stable on textareas but it produces lots of bugs on contentEditable areas. Also there doesn’t seem to be a spec to style the spellchecker underline color. I would have wanted to see this as css properties instead like -spellcheck-enabled: true, -spellcheck-color: red or something.
Oh, if only browsers implemented a default editor. All of the RTEs out there are such disappointments. :(