17:14:16 RRSAgent has joined #webapps 17:14:16 logging to http://www.w3.org/2015/07/21-webapps-irc 17:14:22 Zakim has joined #webapps 17:14:32 aboxhall has joined #webapps 17:14:42 chaals has changed the topic to: #webapps f2f meeting - Web Components https://www.w3.org/wiki/Webapps/WebComponentsJuly2015Meeting 17:15:13 Meeting: Web components f2f, July 2015 17:15:18 -> https://www.w3.org/wiki/Webapps/WebComponentsJuly2015Meeting agenda 17:15:21 scribe: chaals 17:17:11 cdata has joined #webapps 17:18:22 DD: We have the contentious bits wiki and position papers. Think we should start with the key question - do we run author code during {*} 17:18:36 … Google says no, this is mutation events without eough value to do. 17:18:45 … want to call the hook you provide, instead of vice versa. 17:20:25 Present: Annevk, DomC, Chaals, Léonie, AliceB, AlexR, Hayato, DomD, MarkG, WChen, Samw, othermaci-J, TOC, ScottM, Sorvall, AKlein, Dglazkov, BinHu, Travis, Arron 17:20:41 AvK: Question - has Apple figured out processing model for cloning? 17:20:52 … think the parsing I can see, but cloning not so much. 17:21:19 MJS: Tricky thing is the stuff that invoke cloning. 3 technically interesting things that might invoke a constructor: parsing, cloning, directly creating by name. 17:21:42 … not sure if createElement gets invoked, so may not be such an issue but it wasn't mentioned and seems distinct. 17:22:28 … tricky Q: what might do cloning in middle of a complex operation and need to be done defensively. Seems like editing code is likely to be trickiest. Ryosuke pointed out that for technical correctness editing has to be prepared for event to be dispatched synchronously in the middle of somewhere. 17:22:32 jlklein has joined #webapps 17:23:00 … edge cases but hard to track. E.g. using delelte you might have to synchronously dispatch blur, so you need to be prepared anyway. Which makes this a difference of degree not kind. 17:23:23 s/delelte/delete on a focused thing/ 17:23:37 Travis: Mutation events are necessary for advanced editors, even though we don't like them. 17:24:00 mjs: Not like mutation events will go tomorrow, but in webkit we defer them to the end of the editing operation for enhanced not-quite-so-crazy 17:24:05 … wouldn't work here. 17:24:28 sorvell has joined #webapps 17:24:40 … Do have Jonas' almost-synchronous proposal, might be a variant of that. But where you're creating new elements, coding defensively is probably feasible and less than mutations. 17:24:57 DomD: The world *should* be nice... 17:25:12 DomD: Other interesting case is where there sin't afailure mode - in the document, what do we do? 17:25:40 mjs: When constructor throws? Throwing isn't useful we need *A* behaviour for that but doesn't need to be pretty, pick whatever is easy to implement. 17:25:44 not available on Webex today? 17:25:51 AvK: No guarantee the constructor constructs an element anyway. 17:26:06 [apparently no webex] 17:26:18 annevk has joined #webapps 17:26:24 [5: Webex request denied] 17:26:37 arronei has joined #webapps 17:26:44 AK: 2 things - being defensive and the need to specify what happens, and editing right now isn't specified. 17:27:04 LJWatson has joined #webapps 17:27:41 any other options for us folks from India to connect to? 17:27:44 mjs: Think the likely common case for reasonable elements is they don't do crazy things in construction. So for normal interop, don't know if it will be common to edit things with custom elements in the middle. A custom element that mutates random other things is crazy, so it is important not to crash, but it's an edge case. 17:27:54 AK: Want to specify this beyond "don't crash". 17:28:05 AvK: In DOM need to define what happens for ranges. could be rethrow. 17:28:11 TL: Could define mutation events in there for me 17:28:20 AvK: Considered it, but people still want to remove them. 17:28:23 markg has joined #webapps 17:28:29 TL: Can mjs talk about insert/remove? 17:28:40 dglazkov__ has joined #webapps 17:28:48 DomD: The other part is that this makes algorithms obervable. 17:29:05 … that nails down semantics not currently required. 17:29:32 MJS: Mutation events create some of this, because you need to get the things in the same order. Don't think the phenomenon is new... 17:29:45 DomD: Yes, it is a question of degree. 17:29:55 … you wouldn't have complete freedom. 17:30:05 SamW: That's what happens when you expose lower level. 17:30:17 TL: ECMAScript proxy opened up this issue. ggood or bad? 17:30:30 AK: Been problematic, opened up interop issues. 17:30:51 MJS: If you go into DOM operations, there aren't interesting degrees of implementation freedom that synchronous constructors would rule out. 17:31:01 … reomve/insert that don't create elements… 17:31:04 justin has joined #webapps 17:31:15 AvK: There might be cases with ranges where you have to throw earlier or later, but minor details. 17:31:26 DomD: images getting laoded and cached before throwing. 17:31:41 AvK: User agents can optimise those things. All of network is a bit racy. 17:32:05 DomD: exaplins what happens with img loading. 17:32:25 … document.write is fun. 17:32:38 AvK: Evil. same as using it to write a script element. 17:33:03 … HTML parser needs checks. We know when we hit the end of a script, but not for a new-tag, when it is safe to synchronise. 17:33:26 DomD: So, Yes we run author code. Yes, but later, when speced. What do we do in themeantime? 17:33:49 … like we did with imperative distribution API. We need someone to go spec it. 17:34:20 MJS: We're thinking of replacement not necessarily addition. Having constructor and creative callback at the same time will be confusing. Don't think we want two warts here. 17:34:36 DomD: Default calls element.created. If you override it, then it doesn't get called. 17:34:42 MJS: That's different ... 17:34:48 DD, AR: Not really. 17:34:56 MJS: Gets called at a different time 17:35:05 DD: Yes, synch constructor comes at a different time. 17:35:23 MJS: Created callaback can be implemented on top of synchronous constructors. maybe we're done. 17:35:31 DD: when that is specced... 17:35:59 AvK: Does anyone have time to figure out the processing model and write patches for the spec? 17:36:36 MJS: If we got around to implementing and it hadn't been specced, we would try to do that. Don't have someone available off-hand to get it perfect now, but could get a first draft. Step 0 is figure out what results in element creation ... 17:36:49 AvK: The things you said. Parser, doc.createEl, cloning. 17:37:05 MJS: But the next level up - wat calls those. Those are where you need defensiveness. 17:37:28 … so where we need to spec. Does anyone have data on what things invoke those operations? 17:37:50 DC: In blinnk we have audio metadata that does that… 17:37:56 MJS: Is that enforced, or an annotation? 17:38:05 DC: Annotation that makes teh system drain the callback queue. 17:38:42 … could be enforced but isn't. Not useful to find all things that can do this because we have bugs where we should have applied it but didn't. E.g. named attribute getter on el.style 17:38:49 … we could get these things. 17:39:06 [explore - doesn't create elements] 17:39:13 DC: We could find this out. 17:39:44 AvK: I feel like it isn't a long list. createElem, innerHTML, rangeAPI, fragments, and editing is built on top to use those. Don't think there are more things for cloning. 17:40:08 DC: My experience is there is always one more, but falls in those - normally in editing. 17:40:19 TL: If you can hadnle rage, you can handle all the cases... 17:40:24 s/rage/range/ 17:40:42 MJS: Editing is more complex than ranges because it mixes them up, so need to be super-paranoid. 17:40:48 AvK: Range can do that already. 17:41:24 MJS: What if we say custom element constructors are not allowed to change DOM except their own shadow - if they do, the operation that invoked it completely throws. 17:41:32 TL: They will cloneNode the template. 17:41:55 DC: Nice idea, finding the boundary is tricky. Ther limit says there are no modifications, ... 17:42:26 DG: sounds like we talk about a lot of cost to spec this - what is the benefit of it. Compare to other proposals and weight costs/benefits. 17:42:47 MJS: Could list up pros/cons on the whiteboard. 17:43:25 https://etherpad.mozilla.org/customelements 17:43:45 weinig has joined #webapps 17:44:01 s|https://etherpad.mozilla.org/customelements|-> https://etherpad.mozilla.org/customelements pros and cons of proposals 17:44:25 rrsagent, draft minutes 17:44:25 I have made the request to generate http://www.w3.org/2015/07/21-webapps-minutes.html chaals 17:44:53 rrsagent, make logs public 17:45:27 jyasskin has joined #webapps 17:46:52 [discussions of what people like as structures… being noted into the etherPad] 17:47:07 Travis has joined #webapps 17:48:15 ebidel has joined #webapps 17:50:59 [There is a microtask checkpoint before entering a script element] 17:51:27 MJS: If you have multiple callacks, they can look at each other and see things in a half-constructed state. 17:51:45 … if you are being initialised, your peers might not be completed. 17:52:29 TL: There is a way around the observability. If you go to grab unupgraded element you preempt. 17:52:34 MJS: That cycles… 17:53:09 MJS: We tried that idea, but no. 17:53:57 SM: polymer has learned we have to be defensive, this might happen. 17:54:18 MJS: So things are created from outside in. You know your parents 17:54:34 smaug has joined #webapps 17:54:56 MJS: So the state of the DOM is unpredictable. 17:55:28 SO: Not sure why that is more objectionable than what we were talking about earlier, where there are things you shouldn't do with constructor. Seems like either way there are DOM manipulations that don't make sense. 17:55:45 MJS: Different kind of problem… 17:56:18 … there we have deterministic behaviour, here we may be dependent on network behaviour providing non-determinism. 17:56:51 DomD: Hol the presses on network behaviour, thought we eliminated that with the HTML parser. 17:57:37 MJS: Boundaries between data chunks to parse then return to the loop cannot be set, because you don't know what you are getting next. 17:58:01 DD: So if we allow throwing depending on the timing we lose "parser will end up producing the same DOM" 17:58:08 fjh has joined #webapps 17:58:08 AvK: There are random things you could do still. 17:58:30 SO: so non-deterministic state is observable in callback 17:58:42 … potentially, restrictions around it could be specced to fix this. 17:58:47 MJS: Not sure that is possible 17:58:58 SM: Is it clear that the domain of problems are different? 17:59:19 MJS: Don't see how to make created callback work and rule out non-determinism introduced by network variation. 17:59:44 SM: We disallow looking at children - we want an explicit platform signal. 18:00:06 DD: What if we take cycle detection, but instead of upgrading if you inspect it, we sust throw. 18:00:46 SM: We live in the world mjs describes. But don't think we cannot live there. 18:02:48 SW: Our constructors do litt.e Nothing, or set up shadow roots. Don't load... 18:03:01 kschaaf has joined #webapps 18:03:43 … New image calls a constructor, then sets a src. Can happen in sequence... 18:03:59 … you can do setAttribute in the constructor, but we don't in our native implementation. 18:04:05 DG: Would say that in guidance too 18:04:27 MJS: Elements setting attributes is an anti-pattern… 18:04:51 … parameters can be handled outsied the construction. 18:05:07 SM: Is there another lifecycle, like childrenComplete, where we can get deterministic behaviour? 18:05:30 MJS: Only when you are created and nothing has been inserted yet. 18:06:12 … after setting parser-created attributes we have something, and when a child is inserted. 18:06:25 … or when you are inserted/removed from a doc / DOM subtree. 18:06:30 SM: We need that too. 18:07:28 … you can lazily construct as you add things 18:07:55 AvK: HTML requires callbacks for endtag in some cases. 18:08:06 SW: Constructor sets state that is needed. 18:08:38 MJS: input without a type attrivbute set has to have something, but when it gets a type it varies wildly. 18:12:25 SM: Polymer iterates over attributes 18:12:31 DC: Maybe that is wrong... 18:15:53 arronei_ has joined #webapps 18:16:24 MJS You could try to return to event loop when creating the element, but can't go there in the middle of an operation. 18:16:46 robdodson has joined #webapps 18:17:02 DG: So cons on both cases - constructor is complex to spec, createdCallback is that network non-determinism is going to create exciting times. 18:17:23 … does not match ES6 a concern? 18:17:35 AvK: TC39 might want to use constructors. 18:17:52 DD: Not so sure taht is a worry. 18:19:06 MJS: When prototype swizzling happens, something complex goes on. Some think that is a feature, others a bug. 18:19:25 s/goes on/goes on if you only get the propotypes later/ 18:20:25 TOC: worth pointing out that the costs are paid differently - network determinism is paid by authors, complexity of spec is paid by browser developers and specheads (who deserve all the pain they get) 18:21:18 SM: So we *can't get anything deterministic based on callback? 18:21:27 DC: Can be done… 18:21:38 … complexity is when we are running authordefined script. 18:22:48 MJS: You could get down to "if done by parser we drop down to event loop, but if you're in middle of a DOM operation you don't get callback until it's all done" 18:23:03 DD: That removes the network non-determinism 18:23:25 AK: Won't be trivial to add the restrictions 18:25:18 MJS: If you clone subtree with custom element in it you're into a hairy spot of when to do that. And template element encourages doing that. 18:26:53 DG: View upgrades and constructors as sort of the same problem - because in callback world the solution is the same. 18:27:04 … so weighing of the balance applies in the upgrade world. 18:27:23 … sunch constructors means authors need to be sure their definition is loaded before the parser runs. 18:28:32 [possible compromise is to support both appraoches.] 18:29:51 SO: We're looking at either an authoring anti-pattern or a performance anti-pattern … 18:31:00 [discussion of what DomD proposed and what it means] 18:31:24 s/means/means - is it bimodal?] 18:32:27 We're discussing https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Parser-Created-Constructors.md 18:33:59 DC: find and replace things is tricky - you can't always find them. 18:34:22 MJS: So to support upgrade, you might not be able to find everything to upgrade. 18:34:45 … maybe you could make it an explicit behaviour when you register an element. 18:35:24 … to keep a reference to it. 18:36:08 … this could be non-deterministically bad. 18:37:15 DC/TL: proxies is worse than proto-swizzling for JS engine, for speed. 18:37:37 [Do we know about author experience of proxies? Probably not really] 18:38:37 DG: Protoswizzling is actually very common in developer-land 18:39:29 SM: We get lots of problems with non-determinism, have zero bug reports from protoswizzling 18:39:38 rictic has joined #webapps 18:39:53 emmanuel has joined #webapps 18:40:00 DG: This is how people to custom-elements-lite today. 18:40:30 SO: WOuld want to consider less-good upgrades before just dumping them. 18:40:47 MJS: What if it were replacement model, and you need to reget a new wrapper? 18:41:06 AR: we tried this with becomes. Footguns were pretty bad. 18:41:43 … eg in loading process you enhance your document, and then later they get replaced. Surprisingly. 18:42:28 MJS: libraries were fine with protoswizzling? 18:42:36 AR: Largely because they add event handlers 18:43:04 DG: leads to spamming of mutation observers 18:43:09 AR: Problem in the wild. 18:44:45 atotic has joined #webapps 18:45:05 alex has joined #webapps 18:45:18 hello 18:45:35 MJS: Can we have a model that allows upgrade, isn't non-deterministic, and doesn't suck? 18:46:01 … (topic for after lunch) 18:46:15 atotic_ has joined #webapps 18:49:39 [lunch] 18:49:42 rrsagent, draft minutes 18:49:42 I have made the request to generate http://www.w3.org/2015/07/21-webapps-minutes.html chaals 18:50:01 plh has joined #webapps 18:50:12 based on the notes, looks like no new magical great solutions for the issue. 18:50:18 yet 18:50:45 smaug has joined #webapps 18:52:44 Quick question, I have been on the webex for about an hour now to join the meeting today but the line was silent the entire time 18:53:01 was that by design? 18:53:37 are you proactively blocking folks from attending remotely? 18:54:04 no biggie if so, just don't want to hang on the line any longer if that is the case 18:57:12 /me waves hello 19:12:43 I have made the request to generate http://www.w3.org/2015/07/21-webapps-minutes.html Yves 19:17:04 Zakim has left #webapps 19:19:32 fjh has joined #webapps 19:26:42 fjh has joined #webapps 19:28:03 hgl has joined #webapps 19:55:33 Lachy has joined #webapps 19:57:01 weinig has joined #webapps 19:58:48 LJWatson has joined #webapps 20:02:08 arronei has joined #webapps 20:05:41 annevk has joined #webapps 20:05:56 mjs has joined #webapps 20:05:58 chaals has joined #webapps 20:06:13 https://docs.google.com/document/d/1KSwKrTU2d0uJCf55tV-jur_0sYxCNMuM7Dl3vqb0bu4/edit?usp=sharing 20:06:51 -> https://docs.google.com/document/d/1KSwKrTU2d0uJCf55tV-jur_0sYxCNMuM7Dl3vqb0bu4/edit?usp=sharing continuation of the minutes, being taken by Domenic Cooney 20:08:14 rniwa has joined #webapps 20:08:26 Present+ Ryosuke 20:08:35 [Ryosuke joins, Alex is out] 20:11:48 [Alex has not been taken out, because he is back] 20:14:35 oh, etherpad 20:18:58 ojan has joined #webapps 20:33:37 ebidel has joined #webapps 20:33:45 fjh has joined #webapps 20:38:03 ebidel has joined #webapps 21:11:26 rumors of my death (etc. etc.) 21:13:47 chrisb has joined #webapps 21:22:38 atotic_ has joined #webapps 21:27:03 weinig has joined #webapps 21:32:29 sicking has joined #webapps 21:35:17 LJWatson has joined #webapps 21:38:34 dka has joined #webapps 21:48:18 rniwa has joined #webapps 21:51:10 alex has joined #webapps 21:52:41 rrsagent, draft minutes 21:52:41 I have made the request to generate http://www.w3.org/2015/07/21-webapps-minutes.html chaals 21:53:34 chaals has changed the topic to: #webapps f2f meeting - Web Components notes going in https://docs.google.com/document/d/1KSwKrTU2d0uJCf55tV-jur_0sYxCNMuM7Dl3vqb0bu4/edit?pli=1 21:54:02 marcosc has joined #webapps 21:55:09 RRSAgent, make logs public 21:57:16 fjh has joined #webapps 21:58:10 early minutes were in http://www.w3.org/2015/07/21-webapps-minutes.html (until the googlers started scribing) 22:00:41 fjh has joined #webapps 22:05:08 s|http://www.w3.org/2015/07/21-webapps-minutes.html|http://www.w3.org/2015/07/21-webapps-minutes.html| 22:05:09 alex has joined #webapps 22:05:22 Alex, can you hear anything? 22:05:55 (minutes from the morning session are available from http://w3.org/2015/07/21-webapps-minutes.html%7Chttp://www.w3.org/2015/07/21-webapps-minutes.html%7C 22:06:19 aargh. I mean http://w3.org/2015/07/20-webapps-minutes.html 22:07:45 chaals, I'm on webex dialout and I can hear a bit but it's quite faint 22:08:03 (not complaining; I'm following the minutes) 22:08:30 whoever just spoke for a second there just 20 seconds ago I could hear quite well 22:08:45 but I can't hear maciej so well 22:09:06 or whoever was talking just now, responding to maciej 22:09:10 Yeah, he is across the room from Dominic Cooney's mobile :( 22:09:16 I hear Anne very well right now 22:10:04 anyway, the webex is working, roughly 22:16:00 Thanks chaals for getting the audio on. I am following some the transscript as well 22:16:42 its all good 22:21:09 which engines actually support which Mutation Events? 22:22:04 (blur happens when it is safe to dispatch events in Gecko) 22:22:24 and beforeunload too 22:22:32 scriptrunners effectively 22:23:01 As of Chrome 18, mutuation events were supported per this post http://stackoverflow.com/questions/10966864/whats-the-state-of-cross-browser-support-for-dom-mutation-observers 22:24:03 which mutation events? 22:24:13 Chrome has never supported them all 22:25:12 yeah, WebKit and Blink don't run for modifications to attributes 22:26:28 ok, so DOMNodeInserted/Removed have been supported, and those are somewhat relevant here 22:28:43 thanks chaals 22:29:06 smaug: those are "scoped" events in WebKit/Blink and sometimes get delayed to dispatch 22:29:24 smaug: but they're still fired synchronously in most cases. 22:32:38 fjh has joined #webapps 22:39:43 smaug: do you happen to know why Firefox might not want to run createdCallbacks/JS element constructors during parsing (synchronously, as the elements are created)? 22:44:31 during parsing? 22:45:13 I don't see parsing being an issue, at least nowhere near as tricky issue as cloneNode(true) 22:46:26 jsbell has joined #webapps 22:52:11 smaug: hmm, are scriptrunners safe from the perspective of not having mutation events and removing all those checks? 22:53:27 smaug: cause I thought scriptrunners ran at certain times that were not necessarily safe 22:56:22 annevk: scriptrunners run when it is safe to run scripts 22:56:31 Topic: other outstanding issues 22:56:52 RN: Are we going to keep consistent state between parser construction stage and createElement stage. 22:56:53 smaug: "safe in Gecko" 22:57:13 … to keep that consistent we need to do the sizzling dance, or fire events synchronously everywhere. 22:57:13 smaug: it's not clear whether it's safe from a specification perspective without seeing a definition 22:57:32 smaug: I thought they ran in some cases that I did not anticipate and would destroy e.g. the DOM Standard 22:58:05 mjs: need more fleshed-out versions of the proposals. 22:58:18 … feel responsibility to write up more details of the proposals I made. 22:58:18 annevk: oh, that is possible 22:58:29 … maybe there are others 22:58:38 smaug: there you go :-) 22:59:01 DD: Can we spend 10 minutes on that? If I were tasked with fleshing that out, 'd like to come back and ask about it. 22:59:22 RN: Second thing - determinism is easier than some other things. 22:59:28 AK: For upgrading? 22:59:38 RN: Yes. we can come up with something 22:59:59 … seems we agreed we want to support upgrades. 23:00:09 … preserve wrapper identity seem to keep that property. 23:00:10 annevk: well, DOM spec doesn't deal with mutations at all, so many range operations are somewhat broken 23:00:28 … don't know if mutation observers is the biggest problem here. 23:00:42 AvK: Yeah it is trivial. 23:00:56 RN: Another question is if e want to have a created/ready callback at all. 23:01:05 smaug: in a world without mutation events they're not 23:01:17 smaug: but in a world with near-synchronous blur they are 23:01:22 DD: Innovation with super hack convinces me that anything you can do with the callback can be done with constructor, including making all the same issues. 23:01:36 SM: Still possible to create an element but not attach it. 23:01:51 DD: Or we have if (notInitialised) initialise(); 23:02:02 AK: If I call a callback on a thing I created… 23:02:08 annevk: DOMNodeRemoved is not-near-sync, but sync. 23:02:11 MJS: attaching the prototype can be done by the engine 23:02:36 … either do optional init because tehre is no guarantee, or the engine wraps to make sure it happens. Then you are creating a proxy in effect. 23:02:46 … so just do that. 23:02:50 smaug: yes, in a world with mutation events the DOM Standard is broken 23:03:03 [you need something] 23:03:11 smaug: and in a world where blur fires synchronously it is too 23:03:29 well, blur isn't sync 23:03:30 RN: There is the question of is= attribute 23:03:39 it is near-sync, in Gecko at least 23:03:49 smaug: if it's from a scriptrunner that fires while doing range operations it breaks the DOM Standard 23:03:54 DG: And identifying synchronous timing and whether we can achieve that. Someone should experiement with it. If we can do it then it sounds awesome. 23:04:04 oh, right 23:04:06 smaug: and afaik it does 23:04:06 s/smaug:/smaug,/G 23:04:19 DG: Think we can experiment with this... 23:04:29 RN: Some questions for first items require the answer to that. 23:04:34 … otherwise requirements change. 23:04:52 AK: So if we are leaning to synchronous is OK, we should make a system that assumes that and see what happens. 23:05:07 DG: We could e.g. turn off microtasks and feed it to the fuzzer and see what happens. 23:05:38 AvK: Gecko breaks range operations with the blur thing. There is stuff DOM doesn't handle for blur. 23:06:02 MJS: Looks like gecko won't invoke blur if the currently focused thing is removed. 23:06:08 RN: Seems like a bug. 23:06:12 AvK: Huh. 23:06:30 DC: On general spec question of timing, can edge share tests on their model of DOM mutations? 23:06:43 TL: Yep.. put some notes into the issue I raised on this. 23:06:53 ACTION: AvK fix DOM 23:06:54 Error finding 'AvK'. You can review and register nicknames at . 23:07:01 ACTION: Anne to fix DOM 23:07:02 Error finding 'Anne'. You can review and register nicknames at . 23:07:51 DD: Could propose doing deterministic upgrading wthout a dance, ending in one of two states, and see what that looks like. I am willing to do that. 23:08:19 RN: There is another one deterministic with the dance. Maciej gets to expand on that. 23:08:47 TL: I'll flesh out the states proposal. 23:08:56 AE: I'll do the work and travis can take the credit. 23:09:05 Travis has joined #webapps 23:09:18 DG: If we get new proposals, that is good too. 23:09:25 Topic: is= 23:10:13 MJS: kill it with fire. Or defer it to v2. 23:10:24 … inheriting from arbitrary builtins seems to make things supercomplicated. 23:10:42 … attempts to be a solution to give accessibility fallback but won't work because it is too simplistic. 23:10:50 harrisjb has joined #webapps 23:11:00 … If you implement a custom with complex internal structure, browser knows role/state 23:11:10 … with a custom binding, you don't know what the binding is. 23:11:27 AB: You can use labels, put it in forms... 23:11:43 MJS: Maybe not. If it doesn't respect the behaviour of the underlying builtin. 23:12:30 CM: did some playing around in the context of playing with ARIA roles 23:12:39 .. some hacking in WebKit 23:13:05 ... examples were input type=date and sliders 23:13:11 ... (colorful language) 23:13:22 ... if you do that and expose those roles as states 23:13:40 ... ARIA and role/state in WebKit did match 23:13:51 ... so it seemed like you would in fact get the right behavior 23:14:21 ... native element already has all the right events and fires events 23:14:32 ... custom element does need to pick up the event 23:14:40 ... but does not have to build things from scratch 23:14:47 ... when you extend, you get a bunch of things for free 23:14:56 ... and they actually do work 23:15:42 ... so for elements more complex than button, it does seem to be actually very easy to give developers a simple way of extending that works 23:16:13 AVK: is this a good idea for v1 23:16:26 AR: we pinned a lot of hopes and dreams for is= 23:16:43 AR: in an attempt to frame lifecycle methods (or mixin) 23:16:53 AR: We have pinned a lot of hope on is= because it lets you inherit behaviour. What is happening hwre is an explicit attempt to take lifecycle methods or mixins, synthesise events, and create the behaviours you want to have applied. 23:17:08 … using is= doesn't give you that power to implement it yourself. 23:17:11 (Aside: this JSFiddle shows different behavior between Firefox and Chrome/Safari: http://jsfiddle.net/4ocLxx9b/ ) 23:17:44 … so if you want to customise, you end up inextensible. The instinct to do what is= does is right, points at the system where it is too closed - how do I get the behaviour from the elements and expose them. 23:17:53 … not sure is= gets us to where we want to go. 23:18:00 Avk: Don't think is= gets us there. 23:18:30 MJS: Think the value is to make new things that are not just tweaked existing ones. You need to expose the primitives required to be a form element, such as having a label, participating in form submission. 23:18:39 AvK: need something like a trait system. 23:18:48 AR: Don't think we eed traits. we need mixins 23:19:04 (the JSFiddle also seemingly shows Gecko not firing a blur element at all when the focused element is removed from the DOM!) 23:19:11 (blur event I mean) 23:19:28 AvK: Sure. 23:19:44 AR: We can create those mixins and define what it means to mix them in to your classes, and could. 23:19:57 SM: People want to adda little bit to a select, but not recreate it from the ground up. 23:20:07 AB: Yes, see the 2 use cases and am excited about both halves. 23:20:23 … there are tons of people making simple elements with trivial tweaks. 23:20:36 AvK: Ideally for that we have subclassing. 23:20:46 SM: templates is another example. 23:20:57 … agree with what you are saying, but how long will it take. 23:21:05 AvK: Need someone to do the work to figure it out. 23:21:24 … doesn't seem feasible to get agreement on is= 23:21:38 TL: is= is very underspecified 23:21:51 DD: Problem isn't is=, it is the behaviour of the DOM elements when you use it. 23:22:00 AvK: Thought is= itself is simple. 23:22:03 DC: Yes. 23:22:10 … ust makes it a custom element. 23:22:20 SO: Didn't we rule out being able to specify shadows on these things? 23:22:53 … say I want a super-date thing. Bad thing is if I did that but it couldn't be accessible but got used. If I could mix in the accessibility, that would be awesome. 23:23:00 RN: What do people want to add to elements. 23:23:24 SO: I ahve a date input control that I want to handle specifically. One tiny change, convenient to add that. To have to go ove the whole of the rest of the datepicker is a pain. 23:23:38 TL: That';s what prototypes are for 23:23:44 [but you don't get a bunch of pieces] 23:23:55 SM: You mean DOM is complete and perfect? 23:24:16 AvK: If we figure out custom elements, working out how to get lifecycle callbacks for normal elements will exist. 23:24:28 … that's sort of what you want without the indirection thing. 23:24:39 SM: We have 5 different kinds of template. Some are repeats, some aren't. 23:24:43 AvK: You want subclassing. 23:25:00 SM: Sure. How do we get there? is= looks like a quick way to get a lot of that. 23:25:13 RN: We'll be stuck with this for ages. If it is easy, what'sth issue? 23:25:39 DC: Impleennted it and it is ~1% more complexity. You need a sgnal from the parser if it changes, and that's it. 23:25:50 TL: No complexity in selectors implementation? 23:25:58 DC: What would you imagine? I touched nothing. 23:26:13 TL: Envisaged a lot of work in cascade model, to introduce tagname alias. 23:26:22 DD: Doesn't match the tagname selector. 23:26:31 MG: You can't have a custom tagname anymore. 23:27:30 CM: If you have a bunch of mixins, properties shared across many input types, if you had those bits 23:27:51 ... and knew what they were, you could say that when you say is=date, this is what happens 23:28:04 ... does it worth for me to do this work? 23:28:18 SM: seems like you flipped on the head? 23:28:35 CM: not sticking to specific syntax 23:28:50 ... for example, moon in a circle, input type on a lunar circle 23:28:57 ... want to get as much of the date picker as a I can 23:29:12 ... more complicated example: mixing slider and date picker 23:29:27 ... need someone to do this 23:29:45 TL: just use composition rather than inheritance? 23:29:54 CM: not sure, maybe this needs to be researched 23:30:09 CM ... especially mixing two quite different things 23:30:32 RN: Hardest parrt of accessibilty - if author attaches shadow dom with stuff - how to link it to UI things in the underlying element. We need something to make that linkage. 23:31:05 AB: today that is expressed in aria in the shadow DOM 23:32:03 CM: there are two different ways of doing things, one is being used widely (ARIA) 23:32:26 AB: One reason is to subclass a date element to show your datepicker, but on mobile use platform native one. 23:32:37 RN: That's not possible if the JS doesn't see the shadow DOM. 23:32:57 … we can't just not run the JS to get the native thing, in the user agent. 23:33:18 MJS: If you send input is= then it either works or not. 23:33:34 AB: In my scenario, I ahve JS that removes the custom bit if I'm on a mobile. 23:33:55 SM: To do the complicated things today you need to do custom things. 23:34:12 MJS: so why do is= on a form control? 23:34:44 SM: We don't use is= to cahnge things, but to do progressive enhancements to native elements, like inputs that fire a commit event on blur... 23:35:03 … templates. We have 5 kinds in polymer. contents are inert. so it is useful to use them. 23:35:14 … otherwise you would need templates inside things that gets nasty. 23:35:24 … there are values, and relative to the cost, seems good. 23:35:35 RN: Sounds like use case is more mixin than custom. 23:35:49 … don't want a brand new element, you want to add features to an existing element. 23:35:57 SM: Right and that comes out of this machinery at low cost. 23:36:16 MJS: If itis desirable to have the new event added, you would want it without decorating every control... 23:36:29 SM: That's a judgement call. Whenever you want more behaviour, you start from an object you want. 23:36:35 MJS you can't is= two things. 23:37:05 CM: there are separate different behaviors 23:37:19 CM: I am taking an AI to write this up and come back 23:37:32 MJS: You can't alter rendering of forms, so is= doesn't sound like the right thing. 23:38:33 DC: I implemented is=, what I heard go past was a bit of crazy talk. Lots of constituencies want bits of stuff. The idea that you go away and spec things, you have to bite off what you are interested in. You could spec what makes video elements video-y. 23:38:40 … that's the appeal of is= 23:39:07 AB: When was decision made to not allow replacing shadow DOM? That's not implemented in chrome 23:39:16 DC: think it varies by element type. 23:39:22 MG: In gecko? 23:39:32 AvK: We don't expose anything to the web so not a problem. 23:39:43 Topic: deterministic upgrade with no dance. 23:40:09 DD: If we took DG's proposal, and said "we can use constructor". I think everyone would have been happy. So we can do that... 23:40:25 s/DG/other Dmitry/ 23:40:44 s/other Dmitry/Dmitry Lomov's/ 23:40:48 … take something, can upgrade, synchronously call it, can use constructor at createdcallback time 23:41:11 … somewhat similar to current spec but photoshops it until it looks nice. 23:41:20 MJS: Does it solve determinism problem? 23:41:26 DD: Nope, we didn't care. 23:41:34 SO: Reduces it to one of two states. 23:41:43 DD: Either you are upgrading, or not. 23:42:05 RN: Whether we do the dance is an orthogonal issue we can add in or not. 23:42:37 DD: think I can deliver a proposal that you will be happy with... 23:43:03 [so how impotant is the determinism issue…] 23:43:36 MJS: Seems we have figured out how to use constructors anyway, and guarantee not more than 2 states. What we do with lifecycle might impact how we judge the relative importance. 23:44:25 Topic: Other topics 23:44:48 MJS: Review shadow DOM? what is the timing of lifecycle events. Can we do the shadow review? 23:44:53 Topic: Shadow redux 23:45:30 DG: Looked at distribution API, done some testing to understand what happens, and there was a discussion about slots proposal. 23:45:56 … I think we came to agree that slots is a good proposal, started trying to spec out behaviour, looks fairly sane. 23:46:03 AvK: Different from current distribution system? 23:46:18 DG: Yes. You can specify the algorithm synchronously. 23:46:47 … inst4ad of top-down distribution there is a breakdown into stuff that happens on mutation that may affect where things go, synchronously. 23:46:59 … when you make a change you run an operation. 23:47:21 … Second algorithm is looking at the slot and unrolling teh things that are packed into it. Only called when you are treating compose tree. 23:47:38 -> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Slots-Proposal.md slots proposal 23:47:45 … First one alters state. 23:47:54 … second one is read-only, no alteration. 23:48:03 … so style computation concerns don't cause state change. 23:48:47 RN: Think nice thing about this approach is that when you modify the node you just lookup if t belongs to an immediate shadow ancestor. 23:49:07 … then you can add and remove from the list. Then you go render. 23:49:38 … if an item is insertion point then you go through and that's all you have to do. eliminates need for distribution pull. 23:50:10 AvK: How do events work? they operate on compose 23:50:21 DG: Tey don't trigger distribution, just the read-only unroll. 23:50:32 s/Tey/They/ 23:50:57 … This is interesting because the slotting algorithm is local to the subtree. That's super-important. The old algorithm couldn't work that way. 23:51:37 RN: Old world had recursive talking to things around you, that we don't need to do any more. 23:51:57 arronei has joined #webapps 23:52:15 … keeps it simple. 23:52:44 HI: @@@ not related to event path. In such case, distribution is not local, but global. 23:52:57 … So proposal doesn't give benefit. 23:53:03 AvK: @@@@ 23:53:26 DG: mutation that causes a change doesn't alter state in computing. 23:53:47 HI: New algo has 2 paths - one is only local, but most of API including event path depends on global world. 23:54:08 … There is no such a mutation. We should resolve these in terms of global. 23:54:47 RN: Old algorith required global insertion because we didn't know where nodes would land until we did that. I the new approach you only consider each shadow subtree to figure out the next point. Don't have to resolve complete document, can step through as necessary. 23:55:06 DG: THink we are in good shape to finish this up and be done with v1. 23:55:19 MJS: hook for entereing closed mode is in spec, but it isn't defined in teh spec. 23:55:22 HI: Yes, it is done. 23:55:33 AvK: renamiing shadowroot raised some new ideas on that. 23:55:44 MJS: Maybe I should read the spec. [crazy talk!!] 23:55:57 HI: only remaining issue is API surface for closing shadow 23:56:06 … attach shadow… 23:56:24 AvK: Does it AB or XY? Difference matters to the state object proposal. 23:56:40 DD: Would oove to have the underpinnings modeled but we can do attachShadow now and explain its underpinnings later. 23:56:52 AvK: So have one with no arguments now, make that happen later. 23:57:01 DD: If you want to manually attach it, do. 23:57:05 https://github.com/w3c/webcomponents/issues/129 23:57:08 DG: THink attachShadow is fine. 23:57:34 AvK: If we can resolve it is attachShadow that's cool for now and we can strat implenenting and enable. 23:57:54 RN: issue 89 on github is about event targeting. I tthought we agreed we wanted it to be optional. 23:58:01 [there is no agreement that there was agreement] 23:58:55 AvK: DeepPath seems like a hack. 23:59:00 … why not all the other bits? 23:59:29 RN: Github issue for the path thing? 23:59:41 AvK: Think PathTHingy was going to be deepPath. 23:59:48 [yes. it was.] 23:59:54 HI: Done in the spec.