17:51:39 RRSAgent has joined #webapps 17:51:39 logging to http://www.w3.org/2016/01/25-webapps-irc 17:54:47 rrsagent, make log public 17:55:01 Meeting: Web Platform - custom elements 17:55:05 Chair: chaals 17:56:15 Present+ PLH, Hober, William_Chen, AnnevK, DGlazkov, AdrianBa, TravisL, ArronEicholz, Léonie, Hayato, Ryosuke 17:58:44 agenda? 17:58:53 Zakim has joined #webapps 17:58:56 agenda? 17:59:01 agenda+ logistics 17:59:08 agenda+ agenda bashing 18:00:05 Present+ Jan 18:02:53 plh has joined #webapps 18:02:53 arronei has joined #webapps 18:02:57 hi 18:03:08 something 18:03:16 Present+ Smaug(remote) 18:03:19 wchen has joined #webapps 18:03:31 Present+ Plh 18:03:45 chaals: I'll be listening in the background while doing random other stuff. 18:03:51 smaug: can you hear us? 18:03:57 not right now 18:04:02 I did for awhile 18:04:06 k 18:04:09 yes 18:04:37 scribeNick: plh 18:04:46 [introductions] 18:05:00 Present+ Charles 18:05:04 Present_ Hayato 18:05:08 Present+ jan 18:05:12 Present+ Ryosuke 18:05:30 Present+ Antti 18:05:46 wilsonpage has joined #webapps 18:06:14 Present+ Monica 18:06:18 Present+ Justin 18:06:29 rrsagent, make logs public-visible 18:07:07 kochi2 has joined #webapps 18:07:15 zcorpan has joined #webapps 18:08:15 kochi2 has joined #webapps 18:08:46 just joined on webex. 18:08:57 Present+ Kochi(Remote) 18:09:08 Topic: agenda bashing 18:09:30 annevk has joined #webapps 18:09:41 -> https://github.com/w3c/webcomponents/wiki/Custom-Elements:-Contentious-Bits Contentious bits: things for the agenda 18:09:50 Travis: looking at contentious bits, we should do: review of constructors, simple name properties, attribute change callback 18:10:08 plh: ah, what are the settings? 18:10:09 wilsonpage has joined #webapps 18:10:18 plh: you might want to update https://www.w3.org/Project/IRC/ then 18:11:19 Travis: [....] 18:11:58 justin has joined #webapps 18:12:58 dglazkov: we should start with least contentious 18:13:05 agenda+ lifecycle callback timing 18:13:37 zakim, take up item 3 18:13:37 agendum 3. "lifecycle callback timing" taken up [from chaals] 18:13:39 Travis: so is it documented yet when to fire a nano task? 18:13:50 Anne: when IDL returns, but not documented yet 18:14:00 q? 18:14:10 dglazkov: there is a queue 18:14:37 Anne: just before the method is called, there would be a nanotask 18:15:00 Travis: we assume it's introduced when to invoke a method in WebIDL 18:15:39 Travis: if a nano can queue more work that results in a microtask... 18:15:47 jan_miksovsky has joined #webapps 18:16:02 Ryosuke: you have a stack of nanotask 18:16:18 Travis: so sync but delayed after the operation... 18:16:46 s/just before the method is called/just before you return from the method call/ 18:17:00 ACTION: chaals file issue on WebIDL 18:17:00 Error creating an ACTION: could not connect to Tracker. Please mail with details about what happened. 18:17:48 [this is resolved] 18:17:50 s/issue on WebIDL/issue on WebIDL to get the nanotask flow documented 18:17:58 RESOLUTION: We're happy to do it like this 18:18:08 Topic: Symbol Name vs String name 18:19:05 Travis: concern is: what if we move the logic of custom element and put it into mutation observers? 18:19:19 ... so that you have one API for observing mutations 18:19:35 ... attach/detach/reparenting should be addressed in mutation observers 18:19:44 ... in addition to want nanotask timing 18:20:04 Ryosuke: that would bring queing vs tasking 18:20:10 rrsagent, draft minutes 18:20:10 I have made the request to generate http://www.w3.org/2016/01/25-webapps-minutes.html chaals 18:20:32 .... one reason to design this way was that it was easy for mutation observer to step on each other 18:20:54 ... if you modify something in a mutation observer, you have no idea of the ordering 18:21:06 ... if we move the logic, we would reintroducing the problem 18:21:20 Travis: I just want to move the API surface 18:21:34 .... to make it general purpose 18:21:45 ... I don't have to create a new API 18:21:47 Present- jan, Plh, Charles 18:21:58 ... just have to take care of the constructor 18:22:05 Ryosuke: make sense to me 18:22:18 Travis: I'm saying we should punt on it, but would like to transition 18:22:21 one of the reasons for MutionObservers was performance, which is a lot better than with more sync (nanotask-like) MutationEvents. 18:22:33 Anne: how would we do that? 18:22:50 (microtasks give the better performance) 18:23:56 [break to bring Domenic] 18:24:00 See https://www.w3.org/Bugs/Public/show_bug.cgi?id=23250 Travis 18:24:04 Present+ DomenicD 18:25:19 monica has joined #webapps 18:26:28 jsbell has joined #webapps 18:26:30 Ryosuke: some elements affect others only if they are in the document (bese, style) 18:26:33 s/saying we should punt/saying we should not punt 18:27:00 Domenic: detached documents are so rare 18:27:07 s/bese/base 18:27:54 dglazkov&Ryosuke: agreed 18:28:05 dglazkov: I like the idea of a generic callback 18:28:14 s/so rare/so rare that yes, we can leave it as an edge case we don't solve 18:28:38 Ryosuke: so, if we add the attribute filter, it might be ugly. 18:29:11 s/ugly/ugly to have two different was to follow attributes changing 18:29:23 domenic: making sure they match it's fine, but it's important to have both. eg being notify when creating custom elements 18:29:45 travis: you can always observe your own attributes, so damage is limited 18:29:54 s/always/only 18:30:03 ryosuke: we have a bunch of other sync events, not sure if it matters 18:30:40 ... with a microtask ending, you would batch those if lots of elements 18:31:02 zakim, who is on the phone? 18:31:02 Present: Smaug(remote), Ryosuke, Antti, Monica, Justin, Kochi(Remote), DomenicD 18:32:19 ryosuke: range functions will operate on custom elements. nanotask will fire at the end of the range operation 18:32:34 anne: but that might not involve any IDL 18:32:50 ... at least, it's not written down 18:34:20 Resolved: generic callback need be written down, instead of detach/attach 18:34:31 https://github.com/w3c/webcomponents/issues/362 18:35:54 Ryosuke: when navigating an iframe, you would fire those callbacks 18:36:07 Anne: except that script execution is stalled 18:36:45 Domenic: if had a parent browsing context change callback could do the trick 18:37:19 Anne: when do we have the more restrictive callback, ie when the doc change 18:37:29 s/when/why 18:37:31 Domenic: very spammy, and not many use cases 18:37:37 s/why/when 18:37:46 s/when do we/why do we only 18:38:00 Ryosuke: when you keep inserting substree, it would generate a lot of callbacks 18:38:12 Anne: so, are shadow tree are in a composed document? 18:38:20 s/are in/in/ 18:39:19 Ryosuke: ordering is important... 18:39:49 Ryosuke: when getting a callback, should we have it before invoking callback for subcomponents? 18:40:13 i/Anne: why do we/Ryosuke: We don't want the author scripts to run when you navigate away from your iframe… which is notified by pageVisibility rather than attached and detached 18:40:13 Domenic: use case points to the document 18:40:27 Ryosuke: but it's important to figure the ordering 18:40:51 zcorpan has joined #webapps 18:40:56 Ryosuke: top-down order, your subcomponents might not be ready 18:41:28 Ryosuke: take the layout component. you'll need the subcomponents 18:41:56 Justin: should components assume they have their subcomponent or get updates 18:42:10 ... for layout you want to respond as the children are updated 18:42:44 Justin: we've seen cases when people want to know when children are ready, but it seems the wrong way 18:43:11 Travis: if you're a tab layout, you'll need at least 2 children 18:43:33 Justin: I used when you need to setup something up the tree 18:44:02 Domenic: like when starting to listen to mouse events 18:44:18 Domenic: bottom-up seem to encourage a bad style 18:44:31 Justin: yes, I've seen it misused already 18:44:55 ... I'm partial to encourage to listen to child changes rather than assuming the children are correct 18:45:19 Domenic: we'll probably top-bottom for constructors so we should do the same 18:45:21 Ryosuke: agreed 18:45:40 Jan: some components want to know how they're styled 18:45:51 ... when do I have style information? 18:46:06 Ryosuke: sounds like horrible squared problem... 18:46:29 dglazkov: we should discourage people doing so, but they'll keep doing it :) 18:46:43 dglazkov: we need to keep looking for answer 18:46:49 s/horrible squared problem/it leads to a horrible n-squared algorithm 18:46:51 Justin: I'd like a style observer 18:47:13 Travis: combination of mutation observers and style attributes 18:47:49 Anne: seems weird. there is a term called "in a document" that will return false ina shadow root tree 18:47:59 ... for those, we have "in a composed document" 18:48:26 Domenic: we need to change the author facing name or change the spec 18:48:45 Hayato: "inserted into a document deeply"? 18:48:58 ... we have to resolve the distribution anyway 18:49:19 Jan: can we have a name that doesn't have to be precised? 18:49:36 rrsagent, please generate a name 18:49:36 I'm logging. I don't understand 'please generate a name', plh. Try /msg RRSAgent help 18:50:02 [naming discussion] 18:52:14 [naming discussion...] 18:52:48 Domenic: if you do document.contained, it won't return true in a deep/composed document 18:53:03 s/contained/contains/ 18:53:15 Anne: inserted and removed are fine 18:53:53 Justin: the fact that we have removed is an argument against a callback using remove 18:54:18 Justin: node.remove will not always do a remove 18:54:28 ... if you're a detached case 18:54:51 Resolution: We need to find a good colour^name 18:54:55 Unresolved: someone to come up with a proper name 18:55:28 [back to symbol names] 18:55:53 Domenic: let's separate public API from subclass API, but agree it';s not ergonomic 18:55:57 Topic: Symbol or String 18:56:48 Domenic: one design is to hide those on prototypes but it's disruptive 18:57:10 s/those on/those by putting them on another object not directly on 18:57:19 Anne: problem with symbol things is extending 18:58:01 Domenic: no two symbols are ever equal to each other 18:58:21 ... with strings, we would be able to change the semantic as easily 18:59:19 Domenic: there is a cultural opinion against encouraging subclasses, while we're encourage to do so at the moment 18:59:50 Jan: we're running the risk of conflicts already 19:01:06 Domenic: you don't avoid very much by going to symbols 19:01:26 ted: the day 2 day cost outweight the purity... 19:01:38 Domenic: so we have to go back to callbacks on everything... 19:01:58 [general agreement] 19:02:13 Resolution: no change from current spec. 19:18:33 scribe: Travis 19:18:36 jan_miksovsky has joined #webapps 19:18:38 scribeNick: Travis 19:19:04 domenic: We may have exhausted the non-controversial stuff 19:19:16 ... callback timing 19:19:23 ... parser stops 19:19:29 ... fires attribute changed 19:19:42 ... children 19:19:44 ... then resumes 19:20:03 ... seems there's good cause to fire the callbacks as soon as possible. 19:20:30 ... will require some deep parser spec engineering :-( 19:20:30 even in case of innerHTML ? 19:20:52 anne: formalizing document.write? and applying to other elements? 19:21:04 rniwa: we should disallow document.write 19:21:18 Not in the case of innerHTML. That allows you to observe the fragment inside the algorithm 19:21:19 ... there's a flag for that already. 19:21:33 anne: the other problem is dom mutations. If you remove the element, where does the parser resume? 19:21:47 Domenic_: we should just disallow document.write. 19:22:30 annevk: the parser already follows the stack 19:22:40 Domenic_: this is another level of complicated. 19:22:54 ... I'm looking for clear-cut places to disallow things. 19:23:18 rniwa: in a constructor, script element is created and sync-inserted into document, what then 19:23:34 Domenic_: scripts inserted from XHR are disllowed 19:23:50 annevk: because those docs have no browsing context. 19:23:53 monica has joined #webapps 19:24:18 annevk: with random scripts, you're just nesting a little 19:25:04 sicking has joined #webapps 19:25:10 rniwa: document.open/write only cases of reentrancy? 19:25:22 Travis: parser can stop at any time... 19:26:01 annevk: all these concerns already apply to script element. We already have syncronicity. 19:26:10 Domenic_: I just disallowed in modules because they are 'bad' 19:26:24 annevk: Here it doesn't really buy us anything. 19:26:43 Domenic_: [describes the order of operations] 19:27:01 q? 19:27:17 smaug: even in places of innerHTML? 19:27:26 Domenic_: good point. 19:27:44 ... right now the fragment in innerHTML is a spec fiction. This feature would allow that to become observerable. 19:27:58 ... alternatives are to wait until nano-task timing. 19:28:14 annevk: with innerHTML, parser has to queue the nano-tasks. We then define when to fire these. 19:28:32 Domenic_: according to my new order, parser never queues nano-tasks. 19:28:41 annevk: Well,they can be syncronous... 19:28:55 ... in innerHTML case they get queued as well. 19:29:35 rniwa: inside of parser, it would be sync, but in innerHTML it would be nano-task. Is that what is being proposed? 19:29:54 Domenic_: well we have upgrades and parsing... we're saying innerHTML is an upgrade case. 19:31:17 rniwa: having the parser act two different ways is weird to me. 19:31:49 Domenic_: for authors, I could argue that innerHTML and parsing are understood differently. 19:32:01 rniwa: As an author now I have to worry about it? 19:32:12 Domenic_: The argument is that you code it as if there are no children. 19:33:53 Travis: for consistent world view, should we not fire attribute changed if they're already present at constructor time? 19:34:49 dglazkov: I can come to terms with innerHTML being treated as an upgrade case. 19:35:30 LJWatson has joined #webapps 19:35:46 justin: I see danger that authors will set attributes (default) during parsing expecting to have the parser overwrite them... 19:36:16 Domenic_: Forcing innerHTML to have the upgrade world-view will change author expectations. 19:36:41 monica: we rely on default attributes (versus user attributes) for aria. Order is important for us. 19:36:47 ... we do this on attached. 19:37:18 annevk: for aria we should have an internal API. Then you can set defaults and have them be overwritten. 19:37:26 ... you'd have some internal slots for that. 19:37:44 ... you don't want to have the attributes be the cannonical state. 19:38:19 justin: are you referring to how the properties have the 'computed value' whereas the attribute has whatever state was set. 19:38:51 ... there are some cases where you do want to write an attribute for the purposes of styling... 19:39:01 dglazkov: are we getting close to resolving this? 19:39:28 Domenic_: I'm not really comfortable with saying that [it] happens synchronous. TAble for 20 mins, or decide? 19:39:32 rniwa: table it. 19:39:47 annevk: Folks always deferring to script, depending on upgrades... 19:40:00 Domenic_: I don't think the innerHTML case changes this. 19:40:05 Domenic_: OK. New topic. 19:40:13 ... registerElement or new API name? 19:40:18 dglazkov: new name!!!!! 19:40:37 RESOLUTION: use defineCustomElement - void… 19:40:41 travis: talk slower 19:40:43 Domenic_: apple did "defineCustomElement" 19:41:16 rniwa: the name is kinda long, but I like long names. 19:41:27 annevk: I'm happy bikeshedding... er with 'defineElement' 19:42:34 jan_miksovsky: I like the similarities between defineElement and createElement... they look nice together. 19:43:10 RESOLUTION: No, actually defineElement seems a great idea 19:43:20 Domenic_: single class per element name? 19:43:32 rniwa: ins/del use the same interface. 19:43:49 justin: Some folks want to be able to use "is" as a mixin 19:44:13 ... not only using single class def for multiple elements. 19:44:51 justin: I want some sugar (a custom element definition) and apply to other elements in the document. 19:45:24 rniwa: If your module only defines the class, then you can leave it up to author's to define the names. 19:45:36 dfreedm has joined #webapps 19:45:49 rniwa: If no one objects to mutliple tag names per class... 19:46:05 I object:) 19:46:26 I think it's a bug in the platform that we didn't have class per tag name 19:46:31 ... then there is a problem with how the exotic object is created. 19:46:43 Domenic_: fixable if you pass tagname through super(tag_name). 19:46:47 annevk has joined #webapps 19:47:18 [PLH steps out] 19:47:27 rniwa: Then you have to propogate the usage of tagname (both externally and internally to your class) 19:48:01 Domenic_: during parsing you encounter how does the parser tell what to do in the class? 19:48:06 Yeah that seems bad, tag name should be read from a static on the class 19:48:25 Domenic_: This constrains the first argument to custom element constructor to have the tag name. 19:48:38 rniwa: constructor can return whatever it wants! 19:48:42 ... we could allow this. 19:48:50 ... It would be a known issue. 19:48:56 Domenic_: what happens when constructor throws? 19:48:56 static get tagName() { return "x-foo"; } defineElement tears off the getter just like it does for attached and friends 19:49:32 rniwa: When it throws, when in parsing, we probably need to create HTMLUnknownElement. 19:50:02 rniwa: It's OK for custom element constructor to return a text node. Then the parser tries to add a child to it... and .... kaboom! 19:50:16 annevk: I think you just need to create an HTMLUnknownElement in all these cases. 19:50:19 Hmm... I think if you return something that is not an Element we should abort the process and leave it as an Unknown 19:50:22 Yes 19:50:37 justin: back to elements with mutliple tag names... can't you solve this similarly to constructor-call trick. 19:51:03 Yeah, i agree with Anne 19:51:03 ... when you call into HTMLElement constructor it has some magic to know what the tag name will be. 19:51:33 Travis: So then this becomes implicit and not exposed to web code? 19:51:53 Can it consult the parser state? 19:51:54 rniwa: You can call your super constructor multiple times... (via new ...) 19:52:26 justin: You have some global state. Showed Eliott, he said... 19:52:34 https://gist.github.com/domenic/c1566e755c9e14613aa1 19:52:36 [lost it] 19:52:50 I think you can just ask the constructor table though 19:53:05 jan_miksovsky has joined #webapps 19:53:24 Domenic_: [looking at link... hard problem... if a new happens before the super call] 19:53:50 justin: given new.target, other state, etc., you might be able to figure it out. 19:53:54 bicknellr has joined #webapps 19:54:04 Domenic_: if you call new.target it will have the wrong target (to be sure) 19:54:14 ... we can expand a check. 19:54:29 justin: you have to check a stack to make sure you haven't re-entered yourself. 19:54:57 annevk: What's the problem (summary)? 19:55:04 I need help from the lobby :) 19:55:19 rniwa: When super() is called, we need to construct the right element (whatever the parser's trying to create). 19:55:35 ... in upgrade, this is really important. The super() call needs to return the right object (you). 19:56:45 ... now when you make a new call to yourself, things get confused. 19:57:02 justin: I think you can solve this. With new.target + a stack. 19:57:09 rniwa: yes, you can, but ugggg. 19:57:25 ... Also, constructor could be inline. 19:58:08 [esprehn arrives] 19:59:14 rniwa: There is a point when you can detect this... after you return from the constructor. If during the constructor, you already called a constructor, then you could fail out (bail). 19:59:30 Present+ ESprehn 19:59:34 LJWatson has joined #webapps 19:59:36 ... problem is that super() call is returning completely random object. 20:00:07 esprehn: In ES6, if constructor keeps returning random stuff. 20:00:25 Domenic_: super() is short for this = new super(). 20:00:45 esprehn: new.target is the thing at the bottom of the stack. 20:00:50 https://gist.github.com/domenic/c1566e755c9e14613aa1#gistcomment-1679615 20:01:01 rniwa: what if you call you're own constructor (or another element). 20:01:23 Domenic_: Did this fix it? 20:02:04 rniwa: The inner call will work, but then it will throw. 20:03:02 justin: combined with HTMLUnknownElement, this is what you will get. 20:03:26 trackbot has joined #webapps 20:04:33 justin: You can crazy constructor stuff _after_ super. But if you do it before... 20:04:38 rniwa: you're just a bad person. 20:04:41 [all agree] 20:05:35 rniwa: [discovers the white-board] 20:06:41 rniwa: describes case with new element created in first line of a constructor. 20:06:50 ... then there's a super call... 20:07:53 ... conclusion: we have to disallow both before and after new creations in the constructor. 20:08:10 justin: without using a stack. 20:08:11 https://gist.github.com/dglazkov/72ae5223631c525ba6e7 20:08:26 justin: we may need another global to manage the 'in UA construction' 20:08:55 rniwa: Seems desirable to create some kind of element... 20:09:35 justin: Well... maybe you could wait till attached[bikeshed]callback. 20:09:58 esprehn: can't we just change ES6 construction/creation? 20:10:20 esprehn: I think developers will revolt if we disallow creating new elements in the constructor. 20:11:22 annevk: input type password, like input type text/button. There's some precident. 20:11:28 rniwa: OK, so we can't throw. 20:12:05 ... in output we can check to see if the thing we thought would be created was created, and if not throw. 20:12:27 rniwa: Working backwards, reviewing the implications of this change... 20:12:58 esprehn: in upgrade case, what happens? 20:13:51 esprehn: If we swizzle your prototype and things break, then... what? 20:13:57 rniwa: Leave it. 20:14:08 Domenic_: and things are half-baked and broken. 20:14:58 esprehn: You'd queue an exception to fire up the stack (for onerror) 20:16:11 jan_miksovsky: We really want a constructor without a required parameter 20:16:29 ... how would this problem be different if there was an argument to the constructor? 20:16:46 ... all these games to make sure we support a constructor without arguments? 20:16:52 Domenic_: no, this is more base than that. 20:18:04 [discussions and clarifications] 20:18:31 Domenic_: someone who understands these implications better than me should write this up. 20:18:35 rniwa: I can do this. 20:18:49 marcosc has joined #webapps 20:19:06 chaals: break for lunch? yes. 20:40:14 LJWatson has joined #webapps 20:45:56 monica has joined #webapps 20:53:58 sicking has joined #webapps 21:05:56 jan_miksovsky has joined #webapps 21:07:35 chaals has joined #webapps 21:08:03 rrsagent, make minutes 21:08:03 I have made the request to generate http://www.w3.org/2016/01/25-webapps-minutes.html adrianba 21:08:18 rrsagent, make logs public 21:08:54 ACTION: rniwa write up what the caller for custom element constructor and HTML element constructor should check 21:08:54 Error creating an ACTION: could not connect to Tracker. Please mail with details about what happened. 21:09:35 LJWatson has joined #webapps 21:09:53 arronei has joined #webapps 21:13:24 scribe: dglazkov 21:13:52 [discussion around timing of callbacks/constructors] 21:14:21 esprehn: the parser will be special and innerHTML and others will have a nanotask timing 21:14:40 rniwa: disagree. the problem is that this will be inconsistent 21:15:08 rniwa: compound operations, editing 21:15:21 esprehn: run all callbacks sync? 21:15:25 rniwa: just constructors 21:15:48 [discussion around where to run sizing code for custom element] 21:16:31 esprehn: defer all interesting work until it's time to run attach 21:16:56 rniwa: disagree, you can't just change my opinion by repeating the same thing 21:17:36 rniwa: I added EventQueueScope and we still sometimes run script during editing 21:18:12 esprehn: would like to avoid running script during editing, and if they do, treat them as a bug 21:18:34 domenic_: this is one of our "can not live with" issues 21:19:41 rniwa: in this case we can't reach the agreement today 21:20:28 esprehn: this has benefits, right? you have to make it work with both upgrade and non-upgrade, you have a better design 21:20:56 esprehn: [provides an analogical design decision] 21:21:13 esprehn: [ ... in android] 21:22:34 jan_miksovsky: asking clarifying question: am I hearing correctly that esprehn is suggesting I should defer important work until "attached" callback? 21:22:44 [clarifying discussion] 21:23:26 hober: probably good to distinguish the discussion between how we want people to write code and how they will actually write code 21:23:54 jan_miksovsky: may make sense if you change the stakes (throws in the case we don't want people to write code) 21:24:15 Domenic_: has been my opinion that this does not come up very often 21:24:43 Domenic_: devs will not see a lot of difference unless they do a lot of work 21:25:29