On 02/19/2013 10:24 PM, Rafael Weinstein wrote:
On Mon, Feb 18, 2013 at 12:06 PM, Jonas Sicking <jo...@sicking.cc
<mailto:jo...@sicking.cc>> wrote:
On Mon, Feb 18, 2013 at 1:48 AM, Anne van Kesteren <ann...@annevk.nl
<mailto:ann...@annevk.nl>> wrote:
> On Sat, Feb 16, 2013 at 5:23 PM, Dimitri Glazkov <dglaz...@google.com
<mailto:dglaz...@google.com>> wrote:
>> We were thinking of adding innerHTML to DocumentFragments anyway...
right, Anne?
>
> Well I thought so, but that plan didn't work out at the end of the day.
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14694#c7
>
> So given that consensus still putting it on ShadowRoot strikes me like
> a bad idea (as I think I've said somewhere in a bug). The same goes
> for various other members of ShadowRoot.
I don't think there's a consensus really. JS authors were very vocal
about needing this ability. Does anyone have a link to the "strong
case against adding explicit API for DF.innerHTML" from Hixie that
that comment refers to?
Unfortunately that comment referred to an IRC discussion that took place last
June on #whatwg.
We do have logs for #whatwg. See the topic of that channel.
IIRC, Hixie's position was that adding more explicit API for innerHTML is a
moral hazard because it encourages an anti-pattern. (Also IIRC), Anne and
Henri both sided with Hixie at the time and the DF.innerHTML got left in a
ditch.
It's also worth pointing out that if it was decided to have innerHTML on DF and
on ShadowRoot, they would likely have subtly different semantics:
-DF.innerHTML would parse exactly the way <template>.innerHTML does (using the
'implied context parsing).
-SR.innerHTML would use its host as the context element and the output would be as if
the input *had been* applied to <host>.innerHTML, then lifted
out and attached to the SR.
(I believe the later currently the case for ShadowRoot).
/ Jonas
