- From: Domenic Denicola <notifications@github.com>
- Date: Mon, 04 Apr 2016 15:06:57 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/186/205517414@github.com>
So, I started on this in a branch: https://rawgit.com/w3c/webcomponents/ce-reactions-idl/spec/custom/index.html#web-idl-customelementreactions (the list of integrations is rather incomplete) Please read the "NOTE" about why we're doing this to make sure I haven't misinterpreted. Here are some problems I foresee, after spending about an hour going through [all of Blink's annotations](https://code.google.com/p/chromium/codesearch#search/&q=CustomElementCallbacks%20file:.*%5C.idl&sq=package:chromium&type=cs): - Blink's [Reflect] (which I assume all other browsers have some variation of) implies their [CustomElementCallbacks]. - I don't want to block this on specifying [Reflect] as an extended attribute. - I could put in a sentence where HTML defines reflection saying "this implies [CustomElementReactions] behavior" or similar. Pretty lame, but maybe the best we're going to get. - However, in Blink some reflected attributes are reflected manually, and still get [CustomElementCallbacks]. Assuming this is the case for other browsers too, it seems like an easy way for things to slip through the cracks and become non-interoperable. - I guess I could go through every single element in HTML and find all the reflected attributes and annotate them with [CustomElementReactions]? Maybe that's not so bad if this is just a prelude to later replacing it with [Reflect] variants? - innerText and outerText don't have a spec, but need these annotations. I guess we could put them in https://rocallahan.github.io/innerText-spec/ and hope people remember that? - Prefixed attributes don't have a spec (e.g. webkitdropzone). - XSLTProcessor doesn't have a spec ([see wiki entry](https://wiki.whatwg.org/wiki/DOM_XSLTProcessor)) - Aren't these supposed to fire on editing operations? The extended attribute doesn't take care of those cases, does it? How would we do it? I kind of want to give up and go back to the "every attribute and every property do this; optimize away unnecessary cases" idea. Are we sure that explicitly annotating everything is the right move? --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/186#issuecomment-205517414
Received on Monday, 4 April 2016 22:07:25 UTC