Re: Some thoughts on DOM 2.0, Simpler

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

We're talking about adding API for non-HTML. What's already better supported on
HTMLElement is of little relevance here.

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

I don't think so. I think it's the presence of the "HTML" in innerHTML that
raises the question of whether its action is less generic and contains some sort
of HTML bias. For someone paying attention to HTML5 development that may or may
not be a question, but the number of web authors out there who are is virtually
zero in the grand scheme of things. To them, not making things counter intuitive
matters IMO.

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

Sure, people will figure lots of things out if they *have* to. But why should
they? Why add unnecessarily to the learning curve and why make the platform
wartier and more unpleasant to work with than it needs to be? It doesn't do
authors any favors.

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

It's "already here" in the sense that it's already in HTML, but it's not
"already here" in other languages like SVG, so it seems like it's not "already
here" in the context in which we are discussing. And I don't think it adds
"complexity", I think it smooths out the user experience and provides more
intuitive API.

Anyway, we're getting into "I think this group of third party people think X,
and you think they think Y". I guess we've both got different experiences of the
"general author".

Jonathan

Received on Monday, 27 July 2009 16:56:07 UTC