Re: Some thoughts on DOM 2.0, Simpler

On Mon, 27 Jul 2009 18:10:08 +0200, Jonathan Watt <jwatt@jwatt.org> wrote:
> On 7/27/09 1:59 PM, Anne van Kesteren wrote:
>> 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.

Fair enough. I just do not consider renaming things to be worth the added complexity.


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

Except that innerHTML also works for general markup and is better supported most of the time.


> 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?"

Most of the questions here apply to a hypothetical markupContent too.


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

I don't think it will be that much better. If authors want to do markup insertion via strings they'll figure out easily enough that innerHTML is the answer and that it also works for SVG and MathML. Just like SVG and MathML work fine in HTML. (By that time, anyway :-))


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

I agree that would be nice, but innerHTML is already here and adding complexity to make the platform look easier seems like the wrong way to go about things. Actually keeping it simple seems a better strategy to me.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Monday, 27 July 2009 16:25:04 UTC