On Mon, Feb 18, 2013 at 12:06 PM, Jonas Sicking <jonas@sicking.cc> wrote: > On Mon, Feb 18, 2013 at 1:48 AM, Anne van Kesteren <annevk@annevk.nl> > wrote: > > On Sat, Feb 16, 2013 at 5:23 PM, Dimitri Glazkov <dglazkov@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. 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 > >
Received on Tuesday, 19 February 2013 20:25:26 UTC