/irc-logs / w3c / #webapps / 2016-01-25 / end

Options:

# Session Start: Mon Jan 25 00:00:00 2016
# Session Ident: #webapps
# [00:11] * Joins: Florian (~Florian@public.cloak)
# [00:20] * Quits: wilsonpage (~wilsonpage@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
# [00:47] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [00:50] * Joins: marcosc (~marcosc@public.cloak)
# [01:18] * Joins: Florian (~Florian@public.cloak)
# [01:44] * Quits: metasansana (~metasansana@public.cloak) ("Leaving")
# [01:56] * Joins: zcorpan (~zcorpan@public.cloak)
# [02:03] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [02:56] * Joins: zcorpan (~zcorpan@public.cloak)
# [03:04] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [03:57] * Joins: zcorpan (~zcorpan@public.cloak)
# [04:04] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [04:26] * Quits: marcosc (~marcosc@public.cloak) (Client closed connection)
# [04:29] * Joins: marcosc (~marcosc@public.cloak)
# [04:29] * Quits: marcosc (~marcosc@public.cloak) (Client closed connection)
# [04:29] * Joins: marcosc (~marcosc@public.cloak)
# [04:58] * Joins: zcorpan (~zcorpan@public.cloak)
# [05:05] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [05:43] * Quits: marcosc (~marcosc@public.cloak) (Client closed connection)
# [05:59] * Joins: zcorpan (~zcorpan@public.cloak)
# [06:06] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [06:25] * Joins: marcosc (~marcosc@public.cloak)
# [06:32] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
# [06:41] * Joins: marcosc (~marcosc@public.cloak)
# [06:47] * Quits: marcosc (~marcosc@public.cloak) (Client closed connection)
# [06:47] * Joins: marcosc (~marcosc@public.cloak)
# [06:54] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
# [07:00] * Joins: zcorpan (~zcorpan@public.cloak)
# [07:07] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [08:00] * Joins: zcorpan (~zcorpan@public.cloak)
# [08:08] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [08:41] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [08:43] * Joins: zcorpan (~zcorpan@public.cloak)
# [08:50] * Joins: marcosc (~marcosc@public.cloak)
# [08:57] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
# [09:34] * Joins: Florian (~Florian@public.cloak)
# [09:57] * Joins: marcosc (~marcosc@public.cloak)
# [10:31] * Joins: wilsonpage (~wilsonpage@public.cloak)
# [11:11] * wilsonpage is now known as wilsonpage-away
# [11:11] * Quits: wilsonpage-away (~wilsonpage@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
# [11:14] * Joins: wilsonpage (~wilsonpage@public.cloak)
# [11:25] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [11:48] * Joins: Florian (~Florian@public.cloak)
# [11:48] * Joins: Florian_ (~Florian@public.cloak)
# [11:51] * wilsonpage is now known as wilsonpage-away
# [11:52] * Quits: wilsonpage-away (~wilsonpage@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
# [11:55] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [11:56] * Quits: Florian_ (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [12:26] * Joins: wilsonpage (~wilsonpage@public.cloak)
# [12:49] * Joins: Florian (~Florian@public.cloak)
# [12:54] * Joins: dom (dom@public.cloak)
# [13:09] * Quits: marcosc (~marcosc@public.cloak) (Client closed connection)
# [13:09] * Joins: marcosc (~marcosc@public.cloak)
# [13:21] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
# [13:23] * wilsonpage is now known as wilsonpage-away
# [13:26] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [13:34] * Joins: Florian (~Florian@public.cloak)
# [13:54] * wilsonpage-away is now known as wilsonpage
# [14:12] * wilsonpage is now known as wilsonpage-away
# [14:15] * Joins: smaug (~chatzilla@public.cloak)
# [14:16] * Quits: smaug (~chatzilla@public.cloak) ("ChatZilla 0.9.92 [Firefox 46.0a1/20160119030232]")
# [14:26] * Joins: smaug (~chatzilla@public.cloak)
# [14:34] * wilsonpage-away is now known as wilsonpage
# [15:06] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [15:08] * Joins: Florian (~Florian@public.cloak)
# [15:16] * Joins: marcosc (~marcosc@public.cloak)
# [15:24] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
# [16:02] * Joins: rniwa (~textual@public.cloak)
# [16:05] * Joins: rniwa_ (~textual@public.cloak)
# [16:09] * Quits: rniwa (~textual@public.cloak) (Ping timeout: 180 seconds)
# [16:11] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [16:49] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [17:01] * Quits: rniwa_ (~textual@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
# [17:07] * Joins: rniwa (~textual@public.cloak)
# [17:07] <rniwa> hello.
# [17:18] * Joins: marcosc (~marcosc@public.cloak)
# [17:25] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
# [18:10] * Joins: shepazu (schepers@public.cloak)
# [18:14] * Joins: zcorpan (~zcorpan@public.cloak)
# [18:15] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [18:21] * Joins: zcorpan__ (~zcorpan@public.cloak)
# [18:21] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [18:21] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [18:21] * Quits: wilsonpage (~wilsonpage@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
# [18:24] * Joins: wilsonpage (~wilsonpage@public.cloak)
# [18:28] * Quits: zcorpan__ (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [18:28] * Joins: zcorpan (~zcorpan@public.cloak)
# [18:30] * Quits: dom (dom@public.cloak) ("")
# [18:31] <smaug> rniwa: hello. I could follow remotely in the background if the conference call thingie is up and running
# [18:36] <smaug> not that I've ever managed to use webex
# [18:36] <smaug> but there is that phonenumber too, and skype isn't too expensive
# [18:36] <rniwa> yeah, i haven't started the conf yet
# [18:37] <rniwa> since it won't start 'til 10am (27min)
# [18:43] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [18:46] * Joins: Travis (~Travis@public.cloak)
# [18:46] * Quits: wilsonpage (~wilsonpage@public.cloak) (Client closed connection)
# [18:46] * Joins: wilsonpage (~wilsonpage@public.cloak)
# [18:48] * Joins: chaals (~Adium@public.cloak)
# [18:48] * Quits: wilsonpage (~wilsonpage@public.cloak) (Client closed connection)
# [18:51] * chaals changes topic to 'Web Platform f2f meeting - Custom Elements: https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/25janWC.md logged at http://krijnhoetmer.nl/irc-logs/'
# [18:54] * Joins: RRSAgent (rrsagent@public.cloak)
# [18:54] <RRSAgent> logging to http://www.w3.org/2016/01/25-webapps-irc
# [18:58] <chaals> rrsagent, make log public
# [18:58] <RRSAgent> I have made the request, chaals
# [18:58] <chaals> Meeting: Web Platform - custom elements
# [18:58] <chaals> Chair: chaals
# [18:59] <chaals> Present+ PLH, Hober, William_Chen, AnnevK, DGlazkov, AdrianBa, TravisL, ArronEicholz, Léonie, Hayato, Ryosuke
# [19:02] <chaals> agenda?
# [19:02] * Joins: Zakim (zakim@public.cloak)
# [19:02] <chaals> agenda?
# [19:02] * Zakim sees nothing on the agenda
# [19:02] <chaals> agenda+ logistics
# [19:02] * Zakim notes agendum 1 added
# [19:02] <chaals> agenda+ agenda bashing
# [19:02] * Zakim notes agendum 2 added
# [19:03] <chaals> Present+ Jan
# [19:06] * Joins: plh (plehegar@public.cloak)
# [19:06] * Joins: arronei (~arronei@public.cloak)
# [19:06] <smaug> hi
# [19:06] * smaug can hear
# [19:06] <smaug> something
# [19:06] <chaals> Present+ Smaug(remote)
# [19:06] * Joins: wchen (~sid45@public.cloak)
# [19:06] <plh> Present+ Plh
# [19:06] * plh zakim, who is on the phone?
# [19:06] * Zakim Present: Jan, Smaug(remote), Plh
# [19:07] <smaug> chaals: I'll be listening in the background while doing random other stuff.
# [19:07] <rniwa> smaug: can you hear us?
# [19:07] <smaug> not right now
# [19:07] <smaug> I did for awhile
# [19:07] * chaals we muted
# [19:07] <smaug> k
# [19:07] <smaug> yes
# [19:07] <plh> scribeNick: plh
# [19:08] <plh> [introductions]
# [19:08] <plh> Present+ Charles
# [19:08] <plh> Present_ Hayato
# [19:08] <plh> Present+ jan
# [19:08] <plh> Present+ Ryosuke
# [19:08] <chaals> Present+ Antti
# [19:09] * Joins: wilsonpage (~wilsonpage@public.cloak)
# [19:09] <chaals> Present+ Monica
# [19:09] <chaals> Present+ Justin
# [19:09] <plh> rrsagent, make logs public-visible
# [19:09] <RRSAgent> I have made the request, plh
# [19:10] * Joins: kochi2 (~Adium@public.cloak)
# [19:10] * Joins: zcorpan (~zcorpan@public.cloak)
# [19:10] * Quits: kochi2 (~Adium@public.cloak) ("Leaving.")
# [19:11] * Quits: wilsonpage (~wilsonpage@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
# [19:11] * Joins: kochi2 (~Adium@public.cloak)
# [19:12] <kochi2> just joined on webex.
# [19:12] <chaals> Present+ Kochi(Remote)
# [19:12] <plh> Topic: agenda bashing
# [19:12] * Joins: annevk (~sid614@public.cloak)
# [19:12] <chaals> -> https://github.com/w3c/webcomponents/wiki/Custom-Elements:-Contentious-Bits Contentious bits: things for the agenda
# [19:12] * annevk W3C IRC doesn't support TLS yet?
# [19:13] <plh> Travis: looking at contentious bits, we should do: review of constructors, simple name properties, attribute change callback
# [19:13] * plh it does...
# [19:13] <annevk> plh: ah, what are the settings?
# [19:13] * Joins: wilsonpage (~wilsonpage@public.cloak)
# [19:13] <annevk> plh: you might want to update https://www.w3.org/Project/IRC/ then
# [19:14] * plh hum... I'd need to figure out the proper setting
# [19:14] <plh> Travis: [....]
# [19:15] * Joins: justin (~justin@public.cloak)
# [19:15] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [19:16] <plh> dglazkov: we should start with least contentious
# [19:16] <chaals> agenda+ lifecycle callback timing
# [19:16] * Zakim notes agendum 3 added
# [19:16] <chaals> zakim, take up item 3
# [19:16] <Zakim> agendum 3. "lifecycle callback timing" taken up [from chaals]
# [19:16] <plh> Travis: so is it documented yet when to fire a nano task?
# [19:17] <plh> Anne: when IDL returns, but not documented yet
# [19:17] <plh> q?
# [19:17] * Zakim sees no one on the speaker queue
# [19:17] <plh> dglazkov: there is a queue
# [19:14] <plh> Anne: just before the method is called, there would be a nanotask
# [19:15] <plh> Travis: we assume it's introduced when to invoke a method in WebIDL
# [19:15] <plh> Travis: if a nano can queue more work that results in a microtask...
# [19:15] * Joins: jan_miksovsky (~jan_miksovsky@public.cloak)
# [19:16] <plh> Ryosuke: you have a stack of nanotask
# [19:16] <plh> Travis: so sync but delayed after the operation...
# [19:16] * wilsonpage is now known as wilsonpage-away
# [19:16] * wilsonpage-away is now known as wilsonpage
# [19:16] <annevk> s/just before the method is called/just before you return from the method call/
# [19:17] <chaals> ACTION: chaals file issue on WebIDL
# [19:17] * trackbot is creating a new ACTION.
# [19:17] * RRSAgent records action 1
# [19:17] <trackbot> Error creating an ACTION: could not connect to Tracker. Please mail <sysreq@w3.org> with details about what happened.
# [19:17] <plh> [this is resolved]
# [19:17] <chaals> s/issue on WebIDL/issue on WebIDL to get the nanotask flow documented
# [19:17] <chaals> RESOLUTION: We're happy to do it like this
# [19:18] <chaals> Topic: Symbol Name vs String name
# [19:19] <plh> Travis: concern is: what if we move the logic of custom element and put it into mutation observers?
# [19:19] <plh> ... so that you have one API for observing mutations
# [19:19] <plh> ... attach/detach/reparenting should be addressed in mutation observers
# [19:19] <plh> ... in addition to want nanotask timing
# [19:20] <plh> Ryosuke: that would bring queing vs tasking
# [19:20] <chaals> rrsagent, draft minutes
# [19:20] <RRSAgent> I have made the request to generate http://www.w3.org/2016/01/25-webapps-minutes.html chaals
# [19:20] <plh> .... one reason to design this way was that it was easy for mutation observer to step on each other
# [19:20] <plh> ... if you modify something in a mutation observer, you have no idea of the ordering
# [19:21] <plh> ... if we move the logic, we would reintroducing the problem
# [19:21] <plh> Travis: I just want to move the API surface
# [19:21] <plh> .... to make it general purpose
# [19:21] <plh> ... I don't have to create a new API
# [19:21] <chaals> Present- jan, Plh, Charles
# [19:21] <plh> ... just have to take care of the constructor
# [19:22] <plh> Ryosuke: make sense to me
# [19:22] <plh> Travis: I'm saying we should punt on it, but would like to transition
# [19:22] <smaug> one of the reasons for MutionObservers was performance, which is a lot better than with more sync (nanotask-like) MutationEvents.
# [19:22] <plh> Anne: how would we do that?
# [19:22] <smaug> (microtasks give the better performance)
# [19:23] * Domenic_ is stuck in the lobby and sorry to be late...
# [19:23] <plh> [break to bring Domenic]
# [19:23] <annevk> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=23250 Travis
# [19:24] <chaals> Present+ DomenicD
# [19:25] * Joins: monica (~monica@public.cloak)
# [19:26] * Joins: jsbell (~jsbell@public.cloak)
# [19:26] <plh> Ryosuke: some elements affect others only if they are in the document (bese, style)
# [19:26] <Travis> s/saying we should punt/saying we should not punt
# [19:26] <plh> Domenic: detached documents are so rare
# [19:27] <chaals> s/bese/base
# [19:27] <plh> dglazkov&Ryosuke: agreed
# [19:28] <plh> dglazkov: I like the idea of a generic callback
# [19:28] <chaals> s/so rare/so rare that yes, we can leave it as an edge case we don't solve
# [19:28] <plh> Ryosuke: so, if we add the attribute filter, it might be ugly.
# [19:29] <chaals> s/ugly/ugly to have two different was to follow attributes changing
# [19:29] <plh> domenic: making sure they match it's fine, but it's important to have both. eg being notify when creating custom elements
# [19:29] <plh> travis: you can always observe your own attributes, so damage is limited
# [19:29] <chaals> s/always/only
# [19:30] <plh> ryosuke: we have a bunch of other sync events, not sure if it matters
# [19:30] <plh> ... with a microtask ending, you would batch those if lots of elements
# [19:30] <chaals> zakim, who is on the phone?
# [19:30] <Zakim> Present: Smaug(remote), Ryosuke, Antti, Monica, Justin, Kochi(Remote), DomenicD
# [19:32] <plh> ryosuke: range functions will operate on custom elements. nanotask will fire at the end of the range operation
# [19:32] <plh> anne: but that might not involve any IDL
# [19:32] <plh> ... at least, it's not written down
# [19:33] * chaals wonders who is on remote
# [19:34] <plh> Resolved: generic callback need be written down, instead of detach/attach
# [19:34] <rniwa> https://github.com/w3c/webcomponents/issues/362
# [19:35] <plh> Ryosuke: when navigating an iframe, you would fire those callbacks
# [19:36] <plh> Anne: except that script execution is stalled
# [19:36] <plh> Domenic: if had a parent browsing context change callback could do the trick
# [19:37] <plh> Anne: when do we have the more restrictive callback, ie when the doc change
# [19:37] <chaals> s/when/why
# [19:37] <plh> Domenic: very spammy, and not many use cases
# [19:37] <chaals> s/why/when
# [19:37] <chaals> s/when do we/why do we only
# [19:37] <plh> Ryosuke: when you keep inserting substree, it would generate a lot of callbacks
# [19:38] <plh> Anne: so, are shadow tree are in a composed document?
# [19:38] <plh> s/are in/in/
# [19:39] <plh> Ryosuke: ordering is important...
# [19:39] <plh> Ryosuke: when getting a callback, should we have it before invoking callback for subcomponents?
# [19:40] <chaals> 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
# [19:40] <plh> Domenic: use case points to the document
# [19:40] <plh> Ryosuke: but it's important to figure the ordering
# [19:40] * Joins: zcorpan (~zcorpan@public.cloak)
# [19:40] <plh> Ryosuke: top-down order, your subcomponents might not be ready
# [19:41] <plh> Ryosuke: take the layout component. you'll need the subcomponents
# [19:41] <plh> Justin: should components assume they have their subcomponent or get updates
# [19:42] <plh> ... for layout you want to respond as the children are updated
# [19:42] <plh> Justin: we've seen cases when people want to know when children are ready, but it seems the wrong way
# [19:43] <plh> Travis: if you're a tab layout, you'll need at least 2 children
# [19:43] <plh> Justin: I used when you need to setup something up the tree
# [19:43] <plh> Domenic: like when starting to listen to mouse events
# [19:44] <plh> Domenic: bottom-up seem to encourage a bad style
# [19:44] <plh> Justin: yes, I've seen it misused already
# [19:44] <plh> ... I'm partial to encourage to listen to child changes rather than assuming the children are correct
# [19:45] <plh> Domenic: we'll probably top-bottom for constructors so we should do the same
# [19:45] <plh> Ryosuke: agreed
# [19:45] <plh> Jan: some components want to know how they're styled
# [19:45] <plh> ... when do I have style information?
# [19:46] <plh> Ryosuke: sounds like horrible squared problem...
# [19:46] <plh> dglazkov: we should discourage people doing so, but they'll keep doing it :)
# [19:46] <plh> dglazkov: we need to keep looking for answer
# [19:46] <chaals> s/horrible squared problem/it leads to a horrible n-squared algorithm
# [19:46] <plh> Justin: I'd like a style observer
# [19:47] <plh> Travis: combination of mutation observers and style attributes
# [19:47] <plh> Anne: seems weird. there is a term called "in a document" that will return false ina shadow root tree
# [19:47] <plh> ... for those, we have "in a composed document"
# [19:48] <plh> Domenic: we need to change the author facing name or change the spec
# [19:48] <plh> Hayato: "inserted into a document deeply"?
# [19:48] <plh> ... we have to resolve the distribution anyway
# [19:49] <plh> Jan: can we have a name that doesn't have to be precised?
# [19:49] <plh> rrsagent, please generate a name
# [19:49] <RRSAgent> I'm logging. I don't understand 'please generate a name', plh. Try /msg RRSAgent help
# [19:49] <plh> [naming discussion]
# [19:50] * Quits: wilsonpage (~wilsonpage@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
# [19:52] <plh> [naming discussion...]
# [19:52] * Travis insertedAndAttachedToADocumentDeeply
# [19:52] * dglazkov sounds like plh is gently discouraging bikeshedding by regularly sending [naming discussion] into the notes
# [19:52] <plh> Domenic: if you do document.contained, it won't return true in a deep/composed document
# [19:52] <smaug> s/contained/contains/
# [19:53] * chaals deepSixed
# [19:53] <plh> Anne: inserted and removed are fine
# [19:53] <plh> Justin: the fact that we have removed is an argument against a callback using remove
# [19:54] <plh> Justin: node.remove will not always do a remove
# [19:54] <plh> ... if you're a detached case
# [19:54] <chaals> Resolution: We need to find a good colour^name
# [19:54] <plh> Unresolved: someone to come up with a proper name
# [19:55] <plh> [back to symbol names]
# [19:55] <plh> Domenic: let's separate public API from subclass API, but agree it';s not ergonomic
# [19:55] <chaals> Topic: Symbol or String
# [19:56] <plh> Domenic: one design is to hide those on prototypes but it's disruptive
# [19:57] <chaals> s/those on/those by putting them on another object not directly on
# [19:57] <plh> Anne: problem with symbol things is extending
# [19:57] <plh> Domenic: no two symbols are ever equal to each other
# [19:58] <plh> ... with strings, we would be able to change the semantic as easily
# [19:59] <plh> Domenic: there is a cultural opinion against encouraging subclasses, while we're encourage to do so at the moment
# [19:59] <plh> Jan: we're running the risk of conflicts already
# [20:00] * plh looks for a coin
# [20:00] <plh> Domenic: you don't avoid very much by going to symbols
# [20:01] <plh> ted: the day 2 day cost outweight the purity...
# [20:01] <plh> Domenic: so we have to go back to callbacks on everything...
# [20:01] <plh> [general agreement]
# [20:02] <plh> Resolution: no change from current spec.
# [20:08] * Quits: monica (~monica@public.cloak) (Ping timeout: 180 seconds)
# [20:14] * Quits: jan_miksovsky (~jan_miksovsky@public.cloak) (Ping timeout: 180 seconds)
# [20:18] <Travis> scribe: Travis
# [20:18] * Joins: jan_miksovsky (~jan_miksovsky@public.cloak)
# [20:18] <Travis> scribeNick: Travis
# [20:18] <Travis> domenic: We may have exhausted the non-controversial stuff
# [20:19] <Travis> ... callback timing
# [20:19] <Travis> ... parser stops
# [20:19] <Travis> ... fires attribute changed
# [20:19] <Travis> ... children
# [20:19] <Travis> ... then resumes
# [20:19] <Travis> ... seems there's good cause to fire the callbacks as soon as possible.
# [20:20] <Travis> ... will require some deep parser spec engineering :-(
# [20:20] <smaug> even in case of innerHTML ?
# [20:20] <Travis> anne: formalizing document.write? and applying to other elements?
# [20:20] <Travis> rniwa: we should disallow document.write
# [20:21] <esprehn> Not in the case of innerHTML. That allows you to observe the fragment inside the algorithm
# [20:21] <Travis> ... there's a flag for that already.
# [20:21] <Travis> anne: the other problem is dom mutations. If you remove the element, where does the parser resume?
# [20:21] <Travis> Domenic_: we should just disallow document.write.
# [20:22] <Travis> annevk: the parser already follows the stack
# [20:22] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [20:22] <Travis> Domenic_: this is another level of complicated.
# [20:22] <Travis> ... I'm looking for clear-cut places to disallow things.
# [20:23] <Travis> rniwa: in a constructor, script element is created and sync-inserted into document, what then
# [20:23] <Travis> Domenic_: scripts inserted from XHR are disllowed
# [20:23] <Travis> annevk: because those docs have no browsing context.
# [20:23] * Joins: monica (~monica@public.cloak)
# [20:24] <Travis> annevk: with random scripts, you're just nesting a little
# [20:24] * Joins: sicking (~sicking@public.cloak)
# [20:25] <Travis> rniwa: document.open/write only cases of reentrancy?
# [20:25] <Travis> Travis: parser can stop at any time...
# [20:25] <Travis> annevk: all these concerns already apply to script element. We already have syncronicity.
# [20:25] <Travis> Domenic_: I just disallowed in modules because they are 'bad'
# [20:26] <Travis> annevk: Here it doesn't really buy us anything.
# [20:26] <Travis> Domenic_: [describes the order of operations]
# [20:26] <Travis> q?
# [20:26] * Zakim sees no one on the speaker queue
# [20:27] <Travis> smaug: even in places of innerHTML?
# [20:27] <Travis> Domenic_: good point.
# [20:27] <Travis> ... right now the fragment in innerHTML is a spec fiction. This feature would allow that to become observerable.
# [20:27] <Travis> ... alternatives are to wait until nano-task timing.
# [20:28] <Travis> annevk: with innerHTML, parser has to queue the nano-tasks. We then define when to fire these.
# [20:28] <Travis> Domenic_: according to my new order, parser never queues nano-tasks.
# [20:28] <Travis> annevk: Well,they can be syncronous...
# [20:28] <Travis> ... in innerHTML case they get queued as well.
# [20:29] <Travis> rniwa: inside of parser, it would be sync, but in innerHTML it would be nano-task. Is that what is being proposed?
# [20:29] <Travis> Domenic_: well we have upgrades and parsing... we're saying innerHTML is an upgrade case.
# [20:31] <Travis> rniwa: having the parser act two different ways is weird to me.
# [20:31] <Travis> Domenic_: for authors, I could argue that innerHTML and parsing are understood differently.
# [20:31] <Travis> rniwa: As an author now I have to worry about it?
# [20:32] <Travis> Domenic_: The argument is that you code it as if there are no children.
# [20:33] <Travis> Travis: for consistent world view, should we not fire attribute changed if they're already present at constructor time?
# [20:34] <Travis> dglazkov: I can come to terms with innerHTML being treated as an upgrade case.
# [20:35] * Joins: LJWatson (~LJWatson@public.cloak)
# [20:35] <Travis> justin: I see danger that authors will set attributes (default) during parsing expecting to have the parser overwrite them...
# [20:36] <Travis> Domenic_: Forcing innerHTML to have the upgrade world-view will change author expectations.
# [20:36] <Travis> monica: we rely on default attributes (versus user attributes) for aria. Order is important for us.
# [20:36] <Travis> ... we do this on attached.
# [20:37] <Travis> annevk: for aria we should have an internal API. Then you can set defaults and have them be overwritten.
# [20:37] <Travis> ... you'd have some internal slots for that.
# [20:37] <Travis> ... you don't want to have the attributes be the cannonical state.
# [20:38] <Travis> justin: are you referring to how the properties have the 'computed value' whereas the attribute has whatever state was set.
# [20:38] <Travis> ... there are some cases where you do want to write an attribute for the purposes of styling...
# [20:38] <Travis> dglazkov: are we getting close to resolving this?
# [20:39] <Travis> Domenic_: I'm not really comfortable with saying that [it] happens synchronous. TAble for 20 mins, or decide?
# [20:39] <Travis> rniwa: table it.
# [20:39] <Travis> annevk: Folks always deferring to script, depending on upgrades...
# [20:39] <Travis> Domenic_: I don't think the innerHTML case changes this.
# [20:39] <Travis> Domenic_: OK. New topic.
# [20:40] <Travis> ... registerElement or new API name?
# [20:40] <Travis> dglazkov: new name!!!!!
# [20:40] <chaals> RESOLUTION: use defineCustomElement - void…
# [20:40] <justin> travis: talk slower
# [20:40] <Travis> Domenic_: apple did "defineCustomElement"
# [20:40] * Quits: LJWatson (~LJWatson@public.cloak) ("Page closed")
# [20:41] <Travis> rniwa: the name is kinda long, but I like long names.
# [20:41] <Travis> annevk: I'm happy bikeshedding... er with 'defineElement'
# [20:42] * annevk wonders if plh found the TLS settings
# [20:42] <Travis> jan_miksovsky: I like the similarities between defineElement and createElement... they look nice together.
# [20:42] * plh will be back after lunch
# [20:42] <chaals> RESOLUTION: No, actually defineElement seems a great idea
# [20:43] <Travis> Domenic_: single class per element name?
# [20:43] <Travis> rniwa: ins/del use the same interface.
# [20:43] * plh Anne, asking around.
# [20:43] <Travis> justin: Some folks want to be able to use "is" as a mixin
# [20:43] <Travis> ... not only using single class def for multiple elements.
# [20:44] * plh looking at my config, IU use irc.w3.org port 6697
# [20:44] <Travis> justin: I want some sugar (a custom element definition) and apply to other elements in the document.
# [20:45] * Quits: dfreedm (~sid7859@public.cloak) ("Updating details, brb")
# [20:45] * chaals recalls that once W3C had special secure connections for w3c team, running through a different connection…
# [20:45] <Travis> rniwa: If your module only defines the class, then you can leave it up to author's to define the names.
# [20:45] * Quits: annevk (~sid614@public.cloak) ("Updating details, brb")
# [20:45] * Joins: dfreedm (~sid7859@public.cloak)
# [20:45] <Travis> rniwa: If no one objects to mutliple tag names per class...
# [20:45] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [20:45] <esprehn> I object:)
# [20:46] <esprehn> I think it's a bug in the platform that we didn't have class per tag name
# [20:46] <Travis> ... then there is a problem with how the exotic object is created.
# [20:46] <Travis> Domenic_: fixable if you pass tagname through super(tag_name).
# [20:46] * Joins: annevk (~sid614@public.cloak)
# [20:47] <chaals> [PLH steps out]
# [20:47] <Travis> rniwa: Then you have to propogate the usage of tagname (both externally and internally to your class)
# [20:47] <Travis> Domenic_: during parsing you encounter <x-p> how does the parser tell what to do in the class?
# [20:47] <esprehn> Yeah that seems bad, tag name should be read from a static on the class
# [20:48] <Travis> Domenic_: This constrains the first argument to custom element constructor to have the tag name.
# [20:48] <Travis> rniwa: constructor can return whatever it wants!
# [20:48] <Travis> ... we could allow this.
# [20:48] <Travis> ... It would be a known issue.
# [20:48] <Travis> Domenic_: what happens when constructor throws?
# [20:48] <esprehn> static get tagName() { return "x-foo"; } defineElement tears off the getter just like it does for attached and friends
# [20:49] <Travis> rniwa: When it throws, when in parsing, we probably need to create HTMLUnknownElement.
# [20:49] <Travis> 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!
# [20:50] <Travis> annevk: I think you just need to create an HTMLUnknownElement in all these cases.
# [20:50] <esprehn> Hmm... I think if you return something that is not an Element we should abort the process and leave it as an Unknown
# [20:50] <esprehn> Yes
# [20:50] <Travis> justin: back to elements with mutliple tag names... can't you solve this similarly to constructor-call trick.
# [20:50] * chaals checks if esprehn's "yes" means yeah, that makes sense
# [20:50] * chaals where that == what avk said
# [20:50] <esprehn> Yeah, i agree with Anne
# [20:50] <Travis> ... when you call into HTMLElement constructor it has some magic to know what the tag name will be.
# [20:51] <Travis> Travis: So then this becomes implicit and not exposed to web code?
# [20:51] <esprehn> Can it consult the parser state?
# [20:51] <Travis> rniwa: You can call your super constructor multiple times... (via new ...)
# [20:52] <Travis> justin: You have some global state. Showed Eliott, he said...
# [20:52] <Domenic_> https://gist.github.com/domenic/c1566e755c9e14613aa1
# [20:52] <Travis> [lost it]
# [20:52] <esprehn> I think you can just ask the constructor table though
# [20:52] * Quits: jan_miksovsky (~jan_miksovsky@public.cloak) ("Page closed")
# [20:52] * Joins: jan_miksovsky (~jan_miksovsky@public.cloak)
# [20:53] <Travis> Domenic_: [looking at link... hard problem... if a new happens before the super call]
# [20:53] <Travis> justin: given new.target, other state, etc., you might be able to figure it out.
# [20:53] * Joins: bicknellr (~bicknellr@public.cloak)
# [20:53] <Travis> Domenic_: if you call new.target it will have the wrong target (to be sure)
# [20:53] <Travis> ... we can expand a check.
# [20:54] <Travis> justin: you have to check a stack to make sure you haven't re-entered yourself.
# [20:54] <Travis> annevk: What's the problem (summary)?
# [20:54] <esprehn> I need help from the lobby :)
# [20:55] <Travis> rniwa: When super() is called, we need to construct the right element (whatever the parser's trying to create).
# [20:55] <Travis> ... in upgrade, this is really important. The super() call needs to return the right object (you).
# [20:55] * chaals sends help to esprehn
# [20:56] <Travis> ... now when you make a new call to yourself, things get confused.
# [20:56] <Travis> justin: I think you can solve this. With new.target + a stack.
# [20:56] <Travis> rniwa: yes, you can, but ugggg.
# [20:57] <Travis> ... Also, constructor could be inline.
# [20:57] <chaals> [esprehn arrives]
# [20:58] <Travis> 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).
# [20:59] <chaals> Present+ ESprehn
# [20:59] * Joins: LJWatson (~LJWatson@public.cloak)
# [20:59] <Travis> ... problem is that super() call is returning completely random object.
# [20:59] <Travis> esprehn: In ES6, if constructor keeps returning random stuff.
# [21:00] <Travis> Domenic_: super() is short for this = new super().
# [21:00] <Travis> esprehn: new.target is the thing at the bottom of the stack.
# [21:00] <Domenic_> https://gist.github.com/domenic/c1566e755c9e14613aa1#gistcomment-1679615
# [21:00] <Travis> rniwa: what if you call you're own constructor (or another element).
# [21:01] <Travis> Domenic_: Did this fix it?
# [21:01] <Travis> rniwa: The inner call will work, but then it will throw.
# [21:01] * Quits: trackbot (trackbot@public.cloak) (Client closed connection)
# [21:02] <Travis> justin: combined with HTMLUnknownElement, this is what you will get.
# [21:03] * Joins: trackbot (trackbot@public.cloak)
# [21:04] <Travis> justin: You can crazy constructor stuff _after_ super. But if you do it before...
# [21:04] <Travis> rniwa: you're just a bad person.
# [21:04] <Travis> [all agree]
# [21:05] <Travis> rniwa: [discovers the white-board]
# [21:06] <Travis> rniwa: describes case with new element created in first line of a constructor.
# [21:06] <Travis> ... then there's a super call...
# [21:07] <Travis> ... conclusion: we have to disallow both before and after new creations in the constructor.
# [21:07] <Travis> justin: without using a stack.
# [21:07] <dglazkov> https://gist.github.com/dglazkov/72ae5223631c525ba6e7
# [21:08] * Quits: LJWatson (~LJWatson@public.cloak) ("Page closed")
# [21:08] <Travis> justin: we may need another global to manage the 'in UA construction'
# [21:08] <Travis> rniwa: Seems desirable to create some kind of element...
# [21:09] <Travis> justin: Well... maybe you could wait till attached[bikeshed]callback.
# [21:09] <Travis> esprehn: can't we just change ES6 construction/creation?
# [21:10] <Travis> esprehn: I think developers will revolt if we disallow creating new elements in the constructor.
# [21:11] <Travis> annevk: input type password, like input type text/button. There's some precident.
# [21:11] <Travis> rniwa: OK, so we can't throw.
# [21:11] <Travis> ... in output we can check to see if the thing we thought would be created was created, and if not throw.
# [21:12] <Travis> rniwa: Working backwards, reviewing the implications of this change...
# [21:12] <Travis> esprehn: in upgrade case, what happens?
# [21:13] <Travis> esprehn: If we swizzle your prototype and things break, then... what?
# [21:13] <Travis> rniwa: Leave it.
# [21:13] <Travis> Domenic_: and things are half-baked and broken.
# [21:14] <Travis> esprehn: You'd queue an exception to fire up the stack (for onerror)
# [21:15] <Travis> jan_miksovsky: We really want a constructor without a required parameter
# [21:16] * Quits: sicking (~sicking@public.cloak) (sicking)
# [21:16] <Travis> ... how would this problem be different if there was an argument to the constructor?
# [21:16] <Travis> ... all these games to make sure we support a constructor without arguments?
# [21:16] <Travis> Domenic_: no, this is more base than that.
# [21:17] <Travis> [discussions and clarifications]
# [21:17] * chaals wonders if we are ready for lunch…
# [21:18] <Travis> Domenic_: someone who understands these implications better than me should write this up.
# [21:18] <Travis> rniwa: I can do this.
# [21:18] * Joins: marcosc (~marcosc@public.cloak)
# [21:18] <Travis> chaals: break for lunch? yes.
# [21:25] * Quits: marcosc (~marcosc@public.cloak) (Ping timeout: 180 seconds)
# [21:30] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [21:31] * Quits: jan_miksovsky (~jan_miksovsky@public.cloak) (Ping timeout: 180 seconds)
# [21:34] * Quits: monica (~monica@public.cloak) (Ping timeout: 180 seconds)
# [21:39] * Joins: LJWatson (~LJWatson@public.cloak)
# [21:41] * Quits: chaals (~Adium@public.cloak) ("Leaving.")
# [21:45] * Joins: monica (~monica@public.cloak)
# [21:53] * Joins: sicking (~sicking@public.cloak)
# [22:01] * Quits: LJWatson (~LJWatson@public.cloak) (Ping timeout: 180 seconds)
# [22:05] * Joins: jan_miksovsky (~jan_miksovsky@public.cloak)
# [22:07] * Joins: chaals (~Adium@public.cloak)
# [22:07] <adrianba> rrsagent, make minutes
# [22:07] <RRSAgent> I have made the request to generate http://www.w3.org/2016/01/25-webapps-minutes.html adrianba
# [22:07] <adrianba> rrsagent, make logs public
# [22:07] <RRSAgent> I have made the request, adrianba
# [22:08] <chaals> ACTION: rniwa write up what the caller for custom element constructor and HTML element constructor should check
# [22:08] * trackbot is creating a new ACTION.
# [22:08] * RRSAgent records action 2
# [22:08] <trackbot> Error creating an ACTION: could not connect to Tracker. Please mail <sysreq@w3.org> with details about what happened.
# [22:09] * Joins: LJWatson (~LJWatson@public.cloak)
# [22:09] * Joins: arronei (~arronei@public.cloak)
# [22:12] <dglazkov> scribe: dglazkov
# [22:13] <dglazkov> [discussion around timing of callbacks/constructors]
# [22:13] <dglazkov> esprehn: the parser will be special and innerHTML and others will have a nanotask timing
# [22:14] <dglazkov> rniwa: disagree. the problem is that this will be inconsistent
# [22:14] <dglazkov> rniwa: compound operations, editing
# [22:14] <dglazkov> esprehn: run all callbacks sync?
# [22:14] <dglazkov> rniwa: just constructors
# [22:15] <dglazkov> [discussion around where to run sizing code for custom element]
# [22:16] <dglazkov> esprehn: defer all interesting work until it's time to run attach
# [22:16] <dglazkov> rniwa: disagree, you can't just change my opinion by repeating the same thing
# [22:17] <dglazkov> rniwa: I added EventQueueScope and we still sometimes run script during editing
# [22:17] <dglazkov> esprehn: would like to avoid running script during editing, and if they do, treat them as a bug
# [22:18] <dglazkov> domenic_: this is one of our "can not live with" issues
# [22:19] <dglazkov> rniwa: in this case we can't reach the agreement today
# [22:20] <dglazkov> esprehn: this has benefits, right? you have to make it work with both upgrade and non-upgrade, you have a better design
# [22:20] <dglazkov> esprehn: [provides an analogical design decision]
# [22:20] <dglazkov> esprehn: [ ... in android]
# [22:22] <dglazkov> jan_miksovsky: asking clarifying question: am I hearing correctly that esprehn is suggesting I should defer important work until "attached" callback?
# [22:22] <dglazkov> [clarifying discussion]
# [22:22] <dglazkov> hober: probably good to distinguish the discussion between how we want people to write code and how they will actually write code
# [22:23] <dglazkov> jan_miksovsky: may make sense if you change the stakes (throws in the case we don't want people to write code)
# [22:23] <dglazkov> Domenic_: has been my opinion that this does not come up very often
# [22:24] <dglazkov> Domenic_: devs will not see a lot of difference unless they do a lot of work
# [22:25] <dglazkov> esprehn: complaints we see from devs: 1) finishedParsing callback for element; 2) attribute setting during constructor
# [22:25] <dglazkov> annevk: part of the mismatch might be that Blink believes that they can defer everything that happens, and WebKit does not quite believe that.
# [22:26] <dglazkov> Domenic_: Gecko delays some of the mutation events already
# [22:26] <dglazkov> annevk: not all cases
# [22:26] <dglazkov> jan_miksovsky:
# [22:26] <dglazkov> jan_miksovsky: what's the reason for synchronous constructor?
# [22:27] <dglazkov> rniwa: ideally, we want to do everything synchronously
# [22:27] <dglazkov> rniwa: easiest ergonomics, consistent world state, do something -> happens
# [22:28] <dglazkov> rniwa: in some cases it is okay, like attributeChanged
# [22:28] * Joins: cdata (~cdata@public.cloak)
# [22:28] <dglazkov> rniwa: not okay for the cases when the object is being created and constructor is not called
# [22:29] <dglazkov> justin: but this is true for upgrades?
# [22:29] <dglazkov> rniwa: right, this is why we don't like them
# [22:29] <dglazkov> justin: since you already have to assume the upgrade case, why do you need to have sync constructor?
# [22:30] <dglazkov> rniwa: for attributeChanged case, at least you can call a method on an object, but with async constructors you literally don't have the right proto/identity of an object
# [22:31] <dglazkov> [discussion around when this would happen]
# [22:31] <dglazkov> monica: this is why we don't do any important work in created, except for creating a stub shadow tree maybe
# [22:32] * Joins: shepazu_ (schepers@public.cloak)
# [22:32] <dglazkov> annevk: in HTML spec, most of the work happens when an element is inserted or removed. Creating element does nothing most of the time.
# [22:33] <dglazkov> esprehn: another case, innerHTML fragment is spec fiction, and ideally we should not make it be observable
# [22:33] <dglazkov> rniwa: interested in what Mozilla/Microsoft thinks, may help sway
# [22:34] <dglazkov> annevk: if we can prove that we can move all events to nanotask timing. If we did, then we will be convinced. Otherwise, the sync argument stronger
# [22:34] <dglazkov> Travis: nanotask looks like sync
# [22:35] <dglazkov> annevk: no, there are some cases where you can see
# [22:35] <dglazkov> annevk: from the spec perspective it would be better if we did everything deferred
# [22:35] * Quits: shepazu (schepers@public.cloak) (Ping timeout: 180 seconds)
# [22:35] <dglazkov> Travis: in spec, if you clone the tree, do you get 3 callbacks?
# [22:36] <dglazkov> annevk: yes
# [22:36] <dglazkov> Travis: so it's identical to microtask?
# [22:36] <dglazkov> rniwa: no, because is a stack of queues
# [22:36] * Joins: plh (plehegar@public.cloak)
# [22:36] <dglazkov> [discussion]
# [22:37] <dglazkov> esprehn: modeled after auto-release pools
# [22:37] * plh wonders if rniwa or hober can come and fetch him in the lobby
# [22:37] * hober brt
# [22:37] <plh> me thanks!
# [22:37] <dglazkov> jan_miksovsky: what's the right model to prevent component model? If I were to create a boilerplate, what's my general model?
# [22:38] <dglazkov> jan_miksovsky: I don't think I can explain to someone when to do what. As a component author, I am a little confused.
# [22:38] <chaals> [PLH returns]
# [22:38] <dglazkov> jan_miksovsky: "here's a bunch of hooks, use them as you see fit". I would prefer a good boilerplate
# [22:38] <dglazkov> annevk: there are many different models?
# [22:39] <dglazkov> Domenic_: pretty decent consensus on what the boilerplate is
# [22:39] * plh annevk, try port 994 for irc ssl access
# [22:39] <dglazkov> annevk: in img element, you might want to start as early as possible
# [22:39] <dglazkov> esprehn: that might be an anti-pattern
# [22:40] <dglazkov> jan_miksovsky: ask for a tighter range of options
# [22:40] <dglazkov> justin: not sure the sync/async changes this boilerplate
# [22:41] <dglazkov> jan_miksovsky: if no useful work happens in constructor, would this be significant for this discussion?
# [22:41] * Quits: annevk (~sid614@public.cloak) ("Updating details, brb")
# [22:41] <dglazkov> Travis: no one here is saying we should take away the constructor callback, right?
# [22:41] * Joins: annevk (~sid614@public.cloak)
# [22:42] <dglazkov> esprehn: use constructor to set up shape of the object (and stop changing it if you want to run fast)
# [22:42] <dglazkov> esprehn: might not be the same time quantum as the one to look at your attributes and children
# [22:43] <dglazkov> Domenic_: [some proposal about attribute change listening, not clear]
# [22:43] <dglazkov> justin: what's the relationship between attributeChangedCallback and insertedIntoDocumentCallback?
# [22:44] <dglazkov> Domenic_: inserted is called after
# [22:44] <dglazkov> justin: that's okay then
# [22:44] * Quits: jan_miksovsky (~jan_miksovsky@public.cloak) (Ping timeout: 180 seconds)
# [22:44] <dglazkov> justin: [explains how complex elements need a state machine]
# [22:44] <dglazkov> Domenic_: upgrade should call attributeChangedCallback and cal insertedIntoDocumentCallback
# [22:45] <dglazkov> Domenic_: and need to define an order
# [22:45] <dglazkov> annevk, esprehn: call before
# [22:45] <dglazkov> [discussion around order]
# [22:46] <dglazkov> annevk: most good elements should work either way. Script src is different, but should work either way
# [22:47] <rniwa> Here are events that fire synchronously in both WebKit/Blink: v
# [22:47] <rniwa> https://jsfiddle.net/gxwdv5vv/2/
# [22:48] <rniwa> https://jsfiddle.net/h3L8sz2w/2/
# [22:48] * Joins: jan_miksovsky (~jan_miksovsky@public.cloak)
# [22:49] <dglazkov> [looking at what does Edge do]
# [22:49] <dglazkov> [and what Firefox does]
# [22:50] <dglazkov> s/prevent component model/build components
# [22:50] <dglazkov> s/prevent component model/build components/
# [22:51] * Travis I think the third event listener was wrong...
# [22:51] <dglazkov> rniwa: looks like only Blink/WebKit fire these sync
# [22:51] <dglazkov> Travis: focus is sync
# [22:52] <dglazkov> rniwa: so at least one event is fired sync
# [22:52] <dglazkov> Travis: are we still stuck on constructor/nanotask discussion?
# [22:53] <dglazkov> wchen: I don't think we can confidently say that we'll be robust against sync constructor
# [22:53] <dglazkov> annevk: bz says it will be significant amount work
# [22:54] <dglazkov> jan_miksovsky: so your preference would be to be async in non-constructor case
# [22:54] <dglazkov> annevk: yes
# [22:54] <dglazkov> annevk: we are already moving to nanotask timing somewhat
# [22:54] <dglazkov> jan_miksovsky: so that adds up to proposal non-parser async constructor
# [22:54] <dglazkov> jan_miksovsky: Travis?
# [22:54] <dglazkov> Travis: parsing is fine
# [22:55] <dglazkov> Travis: otherwise, thinking of our design, we have a consistent tree model, which matches all changes to the tree
# [22:56] <dglazkov> Travis: [describes how Edge model works]
# [22:56] <dglazkov> Travis: will need archeology
# [22:56] <dglazkov> Domenic_: definitely will need archeology
# [22:56] * Joins: wilsonpage (~wilsonpage@public.cloak)
# [22:56] <dglazkov> wchen: seems like we need it anyway
# [22:56] <dglazkov> rniwa: we should have a comprehensive list of methods/getters/setters
# [22:56] <dglazkov> Travis: that could modify DOM
# [22:57] <dglazkov> rniwa: I am sure browser will have extensions, etc.
# [22:57] <Domenic_> https://code.google.com/p/chromium/codesearch#search/&q=CustomElementCallbacks&sq=package:chromium&type=cs
# [22:57] <dglazkov> Travis: I think it's fine, we can build support for architecture
# [22:57] <dglazkov> Travis: it's probably harder to nanotask than sync
# [22:58] <dglazkov> annevk: you need to make sure it doesn't mess with your state
# [22:58] <dglazkov> Travis: yes, but it's a smaller set
# [22:58] <dglazkov> Travis: we can implement, and dev ergonomics will be better
# [22:58] <dglazkov> Travis: these are all good reasons to go with nanotask
# [22:59] <dglazkov> jan_miksovsky: I heard support from Mozilla and Edge
# [22:59] <dglazkov> wchen: we already have something like this
# [22:59] <dglazkov> rniwa: it seems that there's support, so there's no reason to argue
# [23:00] <dglazkov> RESOLUTION: Nanotask timing for constructor
# [23:00] <dglazkov> [break!]
# [23:01] <monica> unbreak!
# [23:01] <dglazkov> Domenic_: the only issue that was remaining was attribute filter for style attribute
# [23:01] <dglazkov> dglazkov: does anyone not want it
# [23:02] <dglazkov> chaals: put a proposal on IRC
# [23:02] <smaug> ( hmm, ok, skype kicked me out. )
# [23:03] <Domenic_> Attribute filter proposal: at defineElement time, we grab constructor.attributeFilter and convert it to an IDL sequence<DOMString> (i.e. iterate over it and ToString each element). If it's not present, defineElement throws.
# [23:05] <smaug> Domenic_: so how do you get notifications for all the attributes?
# [23:05] * Quits: chaals (~Adium@public.cloak) ("Leaving.")
# [23:05] <smaug> null attributeFilter?
# [23:08] <Domenic_> you can't, I think
# [23:08] <Domenic_> no built-in elements have that
# [23:08] <smaug> ah, true
# [23:12] * Joins: chaals (~Adium@public.cloak)
# [23:18] <rniwa> scribe: rniwa
# [23:19] <rniwa> Domenic_: there is a question of style attribute spamming attributeChanged callbacks
# [23:19] <rniwa> Domenic_: the proposal is to add an attribute filter which is a static property on class
# [23:19] * Joins: marcosc (~marcosc@public.cloak)
# [23:20] <rniwa> Domenic_: It's a mandatory property and it's statically bound at the time of `defineElement` call time
# [23:20] <arronei> class XFoo { static get attributeFilter() { return [ "a", "b" ]; } }
# [23:21] <rniwa> justin: why don't we not invoke attribute callbacks instead
# [23:21] <rniwa> Domenic_: that sounds better
# [23:21] <rniwa> justin: how about prefixing matching
# [23:21] <rniwa> esprehn: some libraries requested. e.g. for on*.
# [23:22] <smaug> (sounds like something not for v1)
# [23:22] <smaug> (that prefix matching )
# [23:22] <rniwa> chaals: the point of this filter is reducing the number of attributes being observed
# [23:22] <chaals> [agree with smaug]
# [23:23] <rniwa> justin: but how about an element that proxies attributes / properties?
# [23:23] <rniwa> esprehn: if we were to add *, I wish it would exclude "style" so that you'd have to write "*+style" in order to receive callbacks for style attribute
# [23:24] <rniwa> dglazkov: for v1, no * and no attribute change callback if it's missing.
# [23:25] * Quits: marcosc (~marcosc@public.cloak) (Client closed connection)
# [23:25] * Joins: marcosc (~marcosc@public.cloak)
# [23:25] <rniwa> jan_miksovsky: there is already mutation observer that can observe all attributes
# [23:26] <rniwa> jan_miksovsky: in MO, you can modify the list of attributes being observed dynamically
# [23:27] <rniwa> Domenic_: for those who think reading the filter value once is weird, both the callback function and the attribute filter values are read once at `defineElement` time
# [23:27] <chaals> rniwa: missing attributeFilter with no callbacks, mutation observer you always get callback… that's weird
# [23:28] <rniwa> Domenic_: what if we renamed it to attributeChangeFilter.
# [23:28] * Quits: kochi2 (~Adium@public.cloak) ("Leaving.")
# [23:29] <rniwa> rniwa: my point was that semantics is different
# [23:30] <rniwa> esprehn: in the case when attribute filter is present, the behavior is the same
# [23:31] <rniwa> annevk: on a different topic, why do we keep the callback at the time of `defineElement`?
# [23:31] <rniwa> annevk: if we had a subclass and called `super()`, it wouldn't be calling something different
# [23:32] <chaals> rniwa: agree, it is weird if DOM has this stuff on the side.
# [23:32] <chaals> esprehn: It's slow to do it like justin wants, working dynamically.
# [23:33] <chaals> DD: You don't get at queue time you do it at call time.
# [23:33] <chaals> esprehn: then we queue stuff we will drop on the floor
# [23:33] <chaals> DD: What if you @@
# [23:33] <chaals> Justin: kind of leaky
# [23:33] <chaals> AvK: If you don't have attributeChange you don't have attributefilter
# [23:33] <chaals> … subclasses will always be slow because when they invoke super thereis a get and call
# [23:34] <chaals> esprehn: no it is at registration time.
# [23:34] <chaals> … you have a bunch of static getters used at definition time
# [23:35] <chaals> Avk: if you have a subclass that invokes super, the call will do a get on the super class, and you will then have the slow stuff to do
# [23:35] <chaals> rniwa: You don't want to queue stuff.
# [23:35] <chaals> justin: guessing for most elements a framework will be there always defining these callbacks
# [23:35] <chaals> DD: I'm a bad person.
# [23:36] <chaals> esprehn: You can write a super.attributeFilter …
# [23:36] <rniwa> rniwa: if we had an attribute filter, you want to create a static internal structure for each custom element
# [23:36] <rniwa> esprehn: ^
# [23:36] <rniwa> esprehn: instead of having to keep querying to the engine.
# [23:37] <rniwa> esprehn: for callbacks, we can still cache the existence of methods
# [23:37] <rniwa> annevk: mostly to determine the shape?
# [23:37] <rniwa> Domenic_: I also like the idea of not being able to change the behavior of class
# [23:38] <rniwa> annevk: we can also do the shape check at runtime
# [23:38] * Joins: kochi2 (~Adium@public.cloak)
# [23:38] <rniwa> annevk: as to whether it has a callback or not
# [23:38] <rniwa> justin: that might lead to even more confusion because author can change function and some changes take into effect and others don
# [23:38] <rniwa> 't
# [23:39] <rniwa> Domenic_: I don't think you should really mess with your class structure after calling `defineElement`
# [23:39] * chaals me.addEventListener('youAreABadPerson'
# [23:40] <rniwa> esprehn: the old design involved passing arguments around and chained it across super calls and that's how the server side stuff works
# [23:40] <rniwa> esprehn: but nobody liked that design
# [23:40] <rniwa> Domenic_: we should throw when an attribute callback is there but no attribute filter is set
# [23:41] <rniwa> ACTION: Domenic_ will write a formal spec for attribute filter
# [23:41] * trackbot is creating a new ACTION.
# [23:41] * RRSAgent records action 3
# [23:41] <trackbot> Error creating an ACTION: could not connect to Tracker. Please mail <sysreq@w3.org> with details about what happened.
# [23:43] <chaals> Topic: is=
# [23:43] <rniwa> hober: I think we kind of agreed not to do it.
# [23:43] * chaals wonders about firing a youAreABadPerson event
# [23:43] <rniwa> justin: Polymer uses "is" and perhaps this is an instance in which the views of Chrome / Polymer are different.
# [23:44] <rniwa> monica: there is a lot of element for which parser treats differently
# [23:44] <Domenic_> (Attribute filter writeup: https://github.com/w3c/webcomponents/issues/367)
# [23:44] <rniwa> monica: for example, td has a special behavior in HTML parser
# [23:45] <rniwa> monica: so unless you can extend an existing element, you can't have parser treat it differently
# [23:45] <rniwa> justin: the most important use case for us is template element
# [23:46] <rniwa> justin: this might be a case in which wrapping with another element might work but we've seen some customers experiencing performance problems due to the sheer number of nodes in the document
# [23:46] <rniwa> Travis: what are those custom elements doing?
# [23:46] <rniwa> Domenic_: what they are is that they want to have these callbacks be involved on elements that already exist
# [23:47] <rniwa> Travis: this feels like the use case of end-of-nano task mutation observer
# [23:47] <rniwa> esprehn: that's not right. they also want to be able to add methods or accessibility features
# [23:47] <rniwa> Travis: and you probably don't want to write everything yourself
# [23:48] <rniwa> Travis: so if you had HTMLAnchorElement defined and extended it, it's still an anchor element browser supports but you're supplementing it with callbacks and methods?
# [23:49] <rniwa> Domenic_: it's important to separate functionality from the particular syntax of is=~.
# [23:49] <rniwa> Domenic_: in theory, this should be also achievable via custom tag name but bz pointed out that this would require a large rewrite of browser engines that check tag names
# [23:49] <rniwa> plh: what happens with selectors?
# [23:49] <rniwa> Travis: I'm still not sold on why you can't wrap it
# [23:50] <rniwa> Travis: is= is like creating a new object to an existing element
# [23:51] <rniwa> esprehn: browser creates an exotic object which is anchor and then browser sticks the prototype into the instance
# [23:51] <rniwa> esprehn: it's just like upgrades
# [23:51] <rniwa> esprehn: the API currently doesn't have any checks for your custom element class not actually inheriting from a subclass of HTMLElement
# [23:52] <rniwa> justin: it seems like there was a consensus to drop this feature in v1, but for Polymer, this goes a long way
# [23:52] <rniwa> monica: templates and lists are big use cases
# [23:52] <rniwa> hober: does component kitchen use it?
# [23:52] <rniwa> jan_miksovsky: no
# [23:53] <monica> (and inputs and buttons and forms, for use cases)
# [23:53] <rniwa> dglazkov: if i were to remove myself from implementation, this whole this is about unveiling things that you can't get out of right now
# [23:53] <rniwa> dglazkov: I want the same behavior parsing as "td" and want the same ARIA role, etc...
# [23:54] <rniwa> annevk: it feels like is= is not the right solution for this
# [23:54] <rniwa> Domenic_: but it would take a really time to resolve all of these problems property
# [23:54] <rniwa> jan_miksovsky: we didn't find not being able to insert a random element inside option, select, etc... haven't been that much of pain
# [23:55] <rniwa> jan_miksovsky: there has been a few cases like defining button without is= with the right style was hard
# [23:55] <rniwa> jan_miksovsky: we have seen it's painful to proxy properties and methods when wrapping elements
# [23:56] <rniwa> jan_miksovsky: syntax of is= seems a bit cranky saying this is one class but then it's another class
# [23:56] <rniwa> Travis: you can't use these elements plainly with createElement
# [23:56] <rniwa> justin: in terms of weirdness, we see tag names as roles
# [23:57] <rniwa> justin: and is= is the actual implementation
# [23:57] <rniwa> justin: there is also a consideration for third party tools that may expect standard HTML tag names
# [23:57] <rniwa> LJWatson: feels like this might be a similar problem as ones encountered in epubs
# [23:58] <rniwa> Domenic_: this isn't a must have but this seems to solve many issues like accessibility
# [23:58] <rniwa> Domenic_: shadow DOM already has restrictions on which element it can attach
# [23:58] <rniwa> chaals: restricting has a nice appeal
# [23:59] <rniwa> annevk: what if you wanted to apply new behaviors on a subset of elements
# [23:59] <rniwa> esprehn: parser also closes head when it hits an element other than one of the three elements
# Session Close: Tue Jan 26 00:00:00 2016

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn