Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

On Wed, May 9, 2012 at 1:32 PM, Rafael Weinstein <rafaelw@google.com> wrote:
> On Wed, May 9, 2012 at 12:51 PM, Ian Hickson <ian@hixie.ch> wrote:
>> On Wed, 9 May 2012, Jonas Sicking wrote:
>>>
>>> I think having to provide a context every wherewhere you want to
>>> parse HTML is creating very bad developer ergonomics.
>>
>> You wouldn't have to provide it everywhere. The vast majority of the time,
>> the default "body" context is fine.
>
> But the whole point of DocumentFragment.innerHTML is that you'd need
> to inspect the markup in order to know the context fragment. <body>
> may be fine 98%, but the use cases that motivated this feature need to
> know 100% of the time if it needs to be something else.
>
>>
>>
>>> I think the proposals here, and the fact that jQuery has implemented
>>> context-free HTML parsing, proves that it is technically possible.
>>
>> I don't think look-ahead and magically determining the parse mode from a
>> preparse of the string is really a sane solution. It doesn't handle all
>> cases (e.g. it doesn't handle the <style> example I gave), and it results
>> in very weird results ("very bad developer ergonomics") for cases like
>> "1GB of text followed by <caption>" vs "1GB of text followed by <coption>"
>> (where the former loses the text and the latter does not).

BTW, This does not appear to be the case in webkit, gecko or IE8.

t = document.createElement('table');

neither of

t.innerHTML = 'foo<caption>bar</caption>'
t.innerHTML = 'foo<coption>bar</coption>

discard foo.

>
> For me, both of these examples fall squarely in the "I can live with
> that" bucket. I'll try again to persuade everyone that we not let
> perfect be the enemy of good. =-)
>
>>
>> --
>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 9 May 2012 20:54:56 UTC