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

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

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:33:28 UTC