- From: Anne van Kesteren <annevk@opera.com>
- Date: Mon, 27 Jul 2009 13:59:47 +0200
- To: "Jonathan Watt" <jwatt@jwatt.org>
- Cc: "Cameron McCormack" <cam@mcc.id.au>, "Jeff Schiller" <codedread@gmail.com>, www-svg <www-svg@w3.org>
On Mon, 27 Jul 2009 13:29:15 +0200, Jonathan Watt <jwatt@jwatt.org> wrote: > It seems to me calling it innerHTML detracts from the author experience > of the language, and for what? So that implementers don't have the burden of > writing a couple of lines of code mapping the new property to their implementation > of innerHTML? Or perhaps it's too much to have the spec say something akin > to "markupContent maps to innerHTML". Isn't author burden supposed to be > put before implementer and spec writer burden? Duplicating functionality to fix a name seems like setting a bad precedent. We're not renaming XMLHttpRequest either even though we easily could. I'd actually argue you increase the burden on authors as they have to learn more APIs, not less. Anyway, my concern is not really with implementors. I'm sure we can manage a few additional attributes here and there. My concern is mostly with the complexity of the Web platform as a whole. Giving a new name to an existing feature (and also keeping the existing feature) just because it's possible is in my opinion not enough additional benefit to warrant doing it. (innerHTML in XML as specified (for sure) and implemented (I think, have not verified) takes the default namespace and such already into account by the way. E.g. if you have an HTML element using prefixes and the default namespace is http://example.org/ elements will be put in that namespace if they do not carry a prefix.) -- Anne van Kesteren http://annevankesteren.nl/
Received on Monday, 27 July 2009 12:00:47 UTC