W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2014

Re: DOM: innerSmartHTML proposal

From: Sander Spies <sandermail@gmail.com>
Date: Wed, 2 Jul 2014 19:07:09 +0200
Message-ID: <CAOOPGD0mv8NyPzM5fT114vZMqrV53z4iQCn7fe+Oa0B-Ztpgtg@mail.gmail.com>
To: Sebastian Zartner <sebastianzartner@gmail.com>
Cc: David Bruant <bruant.d@gmail.com>, www-dom@w3.org
Sorry, but this seems to mix things too much. I would prefer to do it
separately from innerHTML. Perhaps node.mergeInnerHTML(htmlString) is a
better idea?
Op 2 jul. 2014 14:10 schreef "Sebastian Zartner" <sebastianzartner@gmail.com
>:

> On 2 July 2014 13:41, Sander Spies <sandermail@gmail.com> wrote:
>
>> Hi David,
>>
>> Thanks for answering.
>>
>>
>>  On Wed, Jul 2, 2014 at 12:03 PM, David Bruant <bruant.d@gmail.com>
>> wrote:
>>
>>>  Hi,
>>>
>>> What is the use case that motivates this change?
>>> Is there a particular example that would significantly benefit from this
>>> change?
>>>
>>>
>> Imagine you want to change classes, add some attributes, add new DOM
>> nodes and remove several old ones, all at the same time. With
>> 'innerSmartHTML' you could see the new state of the DOM at once, it's
>> basically right there in front of you and you don't need to read through
>> all the DOM modifications to understand what is really happening. Also,
>> your existing event listeners are still there.
>>
>
> A concrete use case for this could be the options to expand and highlight
> changes in Firebug's HTML panel. Firebug allows to expand the structure
> within it's HTML panel and highlight the changed parts. For content
> inserted via innerHTML it can't distinguish whether only parts within the
> assigned HTML have changed and therefore collapses the whole tree.
>
> See also this thread on stackoverflow:
>
> http://stackoverflow.com/questions/24299555/firebug-collapsing-the-whole-tree
>
> Firebug uses a Mutation Observer for this purpose, which would be expected
> to only trigger for the real changes in this case instead of all children
> of an element being replaced by new ones.
>
> Furthermore I'd suggest another syntax for this:
> Make 'innerHTML' an object and add a function to it for assigning. The
> syntax would then look like this:
>
> innerHTML.set(htmlString, onlyApplyDifferences)
>
> where 'htmlString' is the string to be set containing the HTML content and
> 'methodForApplying' either 'onlyApplyDifferences' a boolean value
> specifying whether the string should be applied normally (replacing all
> inner HTML) or smartly by only applying the changes.
> For backwards compatibility innerHTML would have a setter, which applies
> the HTML the normal way, i.e. innerHTML = '<p>foo</p>' would still work
> like now.
>
> Sebastian
>
Received on Wednesday, 2 July 2014 17:07:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:23 UTC