Blogzilla characterizes the discussion in Mozilla bug 97284 as a war of Standards vs “But IE Does It”. They misunderstood the thinking behind my comments in that bug and missed what I believe is another point of view. Here’s a hint that I don’t believe in doing things just because IE does it.
The fact is that IE currently has far better support for editable content than Mozilla. I’d really like to see Mozilla have similar capabilities. In cases such as this where Mozilla is playing catch-up to IE and implementing similar, identical, or better capabilities, it often makes sense to use the same syntax as IE. Mozilla has done this in the past (see innerHTML, offsetHeight, offsetWidth). InnerHTML is a particularly interesting example. You could get the same information through the DOM, but it was convoluted, poorly understood, and developers were already familiar with the convenience of innerHTML.
The argument is often made that Mozilla should only implement the “magic” standards defined by outside standards organizations. I see little difference between a standard that is defined by the W3C and one defined by a company, such as Netscape or Microsoft. Implementing a Microsoft-defined standard could be more beneficial than a W3 standard because more sites would be impacted. In the end, I don’t care too much how the standard became a standard as long as we can agree on it and our browsers support it.
As a historical note, the early versions of HTML suffered from a problem typical of standards organizations: they were slow to be defined. This led to innovation and browser-specific extensions and the browser war. The initial versions of IE implemented the Netscape extensions as part of standard behavior. If I’m remembering correctly, HTML 3 was a mishmash where the W3 agreed to simply release a “standard” that matched the extensions in use at the time. They realized that if they waited too long they’d be irrelevant.
Standards organizations can define standards that look good on paper, but are difficult or impossible to implement. Companies that have implementation experience and take that expertise to the standards groups are quite valuable. This means that the companies need to be experimenting and implementing before the standard is defined. The -moz CSS extensions provide some of this and reasonably protect against attributes that are expected to be standardized but which are not fully defined (zoom is an example here).
In the case of editable content, which has been available since IE5.5, Mozilla has some options:
- Wait for the standard (and I fully expect there will be one—see the first comment of the bug) but be penalized by waiting.
- Implement a Mozilla-specific format and place additional burdens on web developers to convert their pages.
- Implement the IE-defined contentEditable attribute and be immediately able to use a number of existing web pages (For a preview see Xopus or Bitflux or other TTW WYSIWYG editors).
Rereading the bug’s comments, I see less flame war, and many people being pragmatic about this. Note that a Netscape developer logged the bug and agreed with the suggestion to use the IE syntax way back in comment 10, long before my comment 150. I like that. The more similar the browsers are, the better for everyone. Isn’t that the point of standards?
Update: Scott Andrew LePera makes similar comments about the Microsoft-defined contentEditable standard. He says “Kudos to the Mozilla engineers for making the right choice: mirror the IE implementation and prevent further fragmentation of the technologies. If and when the W3 catches up, the decision will already have been made. Them’s the breaks.”