Re: Some thoughts on DOM 2.0, Simpler

Also, I had a question to implementors:

Are there performance benefits to having two methods (one to write and
one to read markup) rather than having a read-write attribute or are
they compiled by the browser down to the same thing?

Thanks,
Jeff

On Mon, Jul 27, 2009 at 10:16 AM, Jeff Schiller<codedread@gmail.com> wrote:
> I'm a little unfamiliar with this so please bear with me.  I'm
> actually one of those people that learned things the DOM way...
>
> Personally I want something like this so I can more easily create
> markup, so I'm more likely to set the value of innerHTML than to get
> it.
>
> Since people are already familiar with document.write(), what about
> adding Element.write() which operates the same way as innerHTML but
> for more than just HTMLElements?  Maybe this is confusing as write()
> gives the impression that you're re-writing the entire markup of the
> element and not just its innards (children).
>
>  A similar function Element.read() could be added to get the text
> representation of the node, maybe?  Same potential confusion I
> suppose.
>
> I note that document.write() is not allowed for XML documents, I don't
> remember the reason can someone clarify?
>
> Regards,
> Jeff
>
> On Mon, Jul 27, 2009 at 6:59 AM, Anne van Kesteren<annevk@opera.com> 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. 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 15:26:34 UTC