Re: Some thoughts on DOM 2.0, Simpler

On 7/27/09 1:59 PM, Anne van Kesteren wrote:
> 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.

Fear or setting precedent is a weak reason to reject an individual case.

> 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.

What's there to learn from the user's perspective? "markupCantent does the same
thing as innerHTML, but for general markup". Everyone can grok that in 2 seconds
flat, and its functionality will match their assumptions.

Also consider the case of people learning from other people's code (which is
after all a central feature of "the Web", and why we favor "human readable"
formats so strongly). Someone coming across some SVG manipulating JavaScript
that does svgObject.innerHTML is going to have a lot more questions in their
mind that someone coming across innerMarkup/markupContent (or some other
non-namespace specific looking name). "Huh? Is this HTML or SVG?" "Do I need to
set the namespace if I use this?" "If not, how is the samespace set? From
something further up the tree? Automatic?"

> 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.

The rational I gave was not "just because it's possible", it was "[because it
make for a better] author experience of the language".

To elaborate, it's because I thing it makes a feature of the Web platform easier
to intuitively understand, thereby avoiding stuff that is very unintuitive and
requires you to think and figure out answers to your questions before you can
use it (and avoiding ugly warts in the language that make it unpleasant to work
with compared to proprietary competitors).

> (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.

Yes, I know. That paragraph was me writing from the perspective of a new user
learning the Web platform. Not many people will read and grok the gory details
of the spec, so it's vastly preferable to make things as intuitive as possible
to reduce the learning curve IMO.

> 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.)

Jonathan

Received on Monday, 27 July 2009 16:14:19 UTC