16:03:09 <RRSAgent> RRSAgent has joined #webapps
16:03:09 <RRSAgent> logging to http://www.w3.org/2015/04/24-webapps-irc
16:03:57 <chaals> chaals has changed the topic to: Web Components meeting - https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting
16:04:10 <hober> could a googler come collect sam, maciej, & me? we're in the 1875 lobby
16:04:58 <Zakim> Zakim has joined #webapps
16:05:10 <chaals> Meeting: Web apps Web COmponents meeting
16:05:20 <chaals> Agenda: https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting
16:06:39 <chaals> Present+ Chaals, Léonie, Mike™, AnnevK, Arron, Travis, Hayato, Smaug
16:06:54 <LJWatson> LJWatson has joined #webapps
16:07:17 <chaals> Present+ DGlazkov, CWilso
16:07:22 <annevk> annevk has joined #webapps
16:08:01 <chaals> Present+ AlexR
16:09:41 <chaals> agenda+ intros
16:09:50 <chaals> agenda+ agenda bashing
16:10:06 <joannawu> joannawu has joined #webapps
16:10:08 <chaals> agenda+ state of the consensus
16:11:24 <Travis> Travis has joined #webapps
16:13:23 <wchen> wchen has joined #webapps
16:13:56 <arronei> arronei has joined #webapps
16:14:43 <chaals> zakim, agenda?
16:14:43 <Zakim> I see 3 items remaining on the agenda:
16:14:44 <Zakim> 1. intros [from chaals]
16:14:44 <Zakim> 2. agenda bashing [from chaals]
16:14:44 <Zakim> 3. state of the consensus [from chaals]
16:14:56 <aklein> aklein has joined #webapps
16:17:21 <taylor> taylor has joined #webapps
16:17:54 <matthew> matthew has joined #webapps
16:18:20 <kevin_> kevin_ has joined #webapps
16:18:22 <wilsonpage> wilsonpage has joined #webapps
16:20:26 <estellevw> estellevw has joined #webapps
16:22:04 <misko> misko has joined #webapps
16:22:10 <jan> jan has joined #webapps
16:22:46 <chaals> scribe: chaals
16:23:46 <mjs> mjs has joined #webapps
16:24:46 <MikeSmith> s/Arron/Aaron
16:25:30 <chaals> Present+ SamW, Maciej, TedOC
16:26:10 <dglazkov_> dglazkov_ has joined #webapps
16:26:55 <MikeSmith> Present?
16:27:09 <chaals> DG: Lots of people here… that's good.
16:27:56 <chaals> … goal of the meeting is to make sure we move Web Components closer to being interoperable standard (actually shipped…)
16:28:04 <justin> justin has joined #webapps
16:28:09 <chaals> … There are some contentious bits on Shadow DOM, and we aim to resolve that here.
16:28:22 <cdata> cdata has joined #webapps
16:28:41 <chaals> … We need to determine what goes into v1 that we can all live with and ship - and put the rest into a v2
16:28:57 <misko_> misko_ has joined #webapps
16:29:17 <chaals> … I would like to leave here not just feeling happy, but actually going to do work and knowing what it will be.
16:29:51 <misko_> misko_ has joined #webapps
16:30:09 <SteveF> SteveF has joined #webapps
16:30:15 <misko> misko has left #webapps
16:30:22 <chaals> … would like to have champions for the things that we have to do still.
16:30:31 <misko_> misko_ has left #webapps
16:30:44 <misko_> misko_ has joined #webapps
16:31:17 <misko_> misko_ has left #webapps
16:31:35 <misko_> misko_ has joined #webapps
16:32:38 <chaals> … The goal is to get browsers implementing, but we need experts from the rest of the ecosystem to tell us about their experience too.
16:33:34 <chaals> CW: Chris Wilson - mostly here to find the tea… (Googler)
16:33:41 <chaals> RN: Ryosuke Niwa, Apple
16:33:50 <chaals> AB: Alice Boxhall, Google accessibility - chrome
16:34:09 <chaals> Misko: work on angluar.js
16:34:20 <chaals> OP: Smaug from mozilla
16:34:33 <jan> jan has joined #webapps
16:34:35 <chaals> WC: William Chen, firefox
16:34:42 <chaals> EO: Ted OConnor, Apple
16:34:57 <chaals> HI: Hayato Ito, work on shadow dom for google and spec it
16:35:07 <chaals> Justin: Work on polymer
16:35:14 <chaals> AvK: Anne, work for moz on standards
16:35:29 <chaals> SW: Sam Weinig, Apple
16:35:36 <chaals> MS: Mike™ Smith, W3C
16:35:46 <chaals> LJW: Léonie Watson, Paciello Group.
16:35:57 <annevk> CMN: Chaals, Yandex
16:36:00 <chaals> CMN: Chaals from Yandex
16:36:11 <chaals> AE: Arron Eicholz, MS - work on webapps
16:36:20 <chaals> TL: Travis Leithead - the MS guy
16:36:25 <Guest21> Guest21 has joined #webapps
16:36:28 <chaals> EB: Eric Bryn
16:36:37 <ebryn> *Erik ;)
16:36:42 <chaals> MG: Mark Giffin, writing web components docs for MDN
16:36:52 <chaals> WP: Wilson Paige, working with WC on firfox OS
16:37:00 <chaals> Jan: Founder of compnentn kitchen
16:37:00 <wilsonpage> *wilsonpage
16:37:07 <chaals> MJS: Maciej, webkit at Apple
16:37:10 <wilsonpage> * waves *
16:37:21 <chaals> AR: Alex Russel, googler on web platform
16:37:29 <chaals> AK: Adam Klein, V8 at google
16:37:38 <chaals> SM: Scott Miles, work on polymer team
16:37:49 <chaals> TS: Savage, google
16:37:54 <chaals> SA: Steve ?? google
16:37:57 <weinig> weinig has joined #webapps
16:38:16 <darobin> darobin has joined #webapps
16:38:31 <cwilso> s/??/Orvell/
16:38:40 <aboxhall> aboxhall has joined #webapps
16:38:47 <cwilso> s/Savage/Taylor Savage/
16:38:51 <chaals> [polymer team people listening on the phone - we don't let them speak]
16:38:57 <cwilso> s/Russel/Russell/
16:39:06 <dfreedm> here in irc as well
16:39:30 <chaals> agenda?
16:39:37 <chaals> zakim, close item 1
16:39:37 <Zakim> agendum 1, intros, closed
16:39:38 <Zakim> I see 2 items remaining on the agenda; the next one is
16:39:38 <Zakim> 2. agenda bashing [from chaals]
16:39:52 <chaals> Topic: State of consensus and contention
16:40:01 <chaals> zakim, close item 3
16:40:01 <Zakim> agendum 3, state of the consensus, closed
16:40:02 <Zakim> I see 1 item remaining on the agenda:
16:40:02 <Zakim> 2. agenda bashing [from chaals]
16:40:11 <Mark> Mark has joined #webapps
16:40:37 <chaals> DG: Most vendors aside from Google have explained their current position...
16:40:58 <chaals> … would like to figure out how important contentions are - blocker, useful to have, v1 or v2 or…
16:41:01 <misko> https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits
16:41:31 <chaals> -> https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits The collected points of disagreement…
16:41:50 <chaals> Topic: Muktiple shadow roots per element
16:42:39 <chaals> MJS: Apple thinks this should be removed and replaced with something like the ?? proposal. Strongly think this is the case for v1 - better to replace it with something useful or subclassing won't be useful.
16:42:49 <MikeSmith> RRSAgent, make minutes
16:42:49 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/24-webapps-minutes.html MikeSmith
16:42:50 <chaals> … there is a time trade off to replacing it
16:42:54 <dfreedm> s/??/"named slots"/
16:43:07 <Lenville> Lenville has joined #webapps
16:43:16 <MikeSmith> RRSAgent, make logs public
16:43:18 <chaals> AvK: Mozilla probably don't care strongly for v1 - we would like some solution, and the Apple thing might (or not) work for us…
16:43:36 <chaals> DG: So there is an alternative, which is not the same as "let's drop what we have"
16:44:48 <chaals> TL: For multiple shadow roots, should be removed in v1. You can get a lot done just with a single shadow. I like Apple's proposal simplifying the way content is distributed. Seems easier to implement. Maybe not as beautiful, but workable.
16:45:10 <chaals> DG: This has been a big sticking point for the shadow dom spec. I was the one arguing for it.
16:45:33 <chaals> .. I think most usage isn't that good, so I am OK with removing it.
16:46:00 <chaals> … Understand there is a need for something like this - let's take the time to study and come up with a good concrete way to solve this.
16:46:12 <chaals> RESOLUTION: Remove multiple shadow roots
16:46:20 <MikeSmith> RRSAgent, make minutes
16:46:20 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/24-webapps-minutes.html MikeSmith
16:46:33 <chaals> Justin: Want to make sure removal is seperate from what replaces it…
16:46:57 <chaals> HI: SHuld we have a replacement in v1 or wait until v2?
16:47:03 <chaals> DG: I would be OK with no replacement in v1
16:47:10 <chaals> AvK: Agreed, might even be better than way
16:47:31 <chaals> DG: Plymer team walked away from this already?
16:47:35 <MikeSmith> s/Muktiple/Multiple
16:47:44 <chaals> SM: Conceptually yes (haven't implemented that but will)
16:48:00 <chaals> … agree that simplifying this is the right thing, and removing it won't affect polymer.
16:48:16 <chaals> Topic: Default value of "closed shadow tree"
16:48:33 <jan> If it’s helpful, I’m trying to summarize the positions on contentious bits on https://docs.google.com/spreadsheets/d/1hnCoaJTXkfSSHD5spISJ76nqbDcOVNMamgByiz3QWLA/edit#gid=0
16:48:56 <chaals> MJS: The closed flag got added recently - Yay! But behaviour not fully defined yet.
16:49:35 <chaals> … preference order for v1: most prefer having closed and open, default closed. 2nd, require devs to choose one, no default, 3rd choice default to open, strongly against only having open
16:49:54 <chaals> … most importantly closed mode is a good block for making totally isolated components
16:50:13 <chaals> … people felt the medium level is not useful, but to build a full solution this is necessary.
16:50:32 <chaals> agenda+ Jan…'s proposal for named thingo
16:50:38 <chaals> agenda+ closed and open
16:51:04 <chaals> AvK: more important discussion is semantics of closed...
16:51:26 <chaals> AR: Disagree, which is important but we need the discussion. degree of difficulty to make a real closed mode is very high.
16:51:55 <chaals> OP: Moz' opinion is we agree with Apple.
16:52:08 <chaals> … maybe v3 for proper isolation mode.
16:52:17 <chaals> RESOLUTION: There will be a v4
16:53:20 <chaals> TL: Having a closed and open simple mode makes sense. When a component is poen we have what chrome ships today. When closed, i think that means you can't reach it via shadow-root property in JS but if you had a reference already you can reach it.
16:53:39 <chaals> … not sure what that means for how events and styles go across the boundaries. Think we need a closed + isolated model definitely.
16:53:46 <chaals> … not sure we need that and a simple closed model.
16:54:13 <chaals> … because I don't understand implications of closed I think that needs to be decided for v1. Isolated model can wait until later, it is far more complicated.
16:54:30 <chaals> DG: Agree on closed not isolated being needed.
16:54:51 <chaals> … our preference is open by default, We want to do isolated in v2 or v3.
16:55:11 <chaals> … we can live with closed by default if that's the general consensus
16:55:20 <chaals> TL: v1 needs a way to consume the flag or remove it.
16:55:36 <chaals> Topic: Imperative distribution API
16:55:50 <chaals> MJS: We still like this - for complex stuff declarative is going to be pretty tricky.
16:56:18 <chaals> … not necessary for v1. Would like something either like this or named slot proposal - at very least we don't want @@
16:56:31 <chaals> agenda+ details of imperative distribution API, don't make it impossible.
16:56:34 <chaals> AvK: Agree
16:56:47 <chaals> TL: Agree. API can wait for v2
16:56:52 <chaals> DG: Agreed...
16:57:34 <chaals> RESOLUTION: Make sure we can do it - v1 if we get there or v2
16:57:45 <chaals> RN: Don't want to add something that won't work out…
16:58:16 <chaals> Topic: Seperate event retargeting from style composition
16:59:27 <chaals> MJS: Apple wants seperation. Not that strong feelings about default, might be plausible to have retargeting in closed mode, not in open, as default
16:59:57 <chaals> … choice should be addressed, maybe possible to hang this on closed/open, maybe not needed.
17:00:10 <MikeSmith> RRSAgent, make minutes
17:00:10 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/24-webapps-minutes.html MikeSmith
17:00:20 <chaals> … we probably need to offer the choice in v1. If both exist we should decide which will be the default now.
17:00:46 <chaals> AvK: There should be an option, should probably be tied to closed/open - seems simplest and intuitive
17:00:56 <chaals> … definitely v1
17:01:58 <chaals> TL: for retargeting if the goal is for a closed shadow not to allow access the event system has to be strongly isolated from that boundary. not sure if retargeting is sufficient, might need a nested event dispatch inside, and don't carry arbitrary properties through the shadow. If that's what we are talking about you need this for any kind of closed model.
17:02:16 <chaals> … otherwise events poke a hole in that.
17:02:24 <chaals> AvK: only if you have prototypes
17:02:33 <chaals> agenda+ clarify event retargetting...
17:02:49 <chaals> TL: Something like it should be the default for any closed stuff.
17:03:23 <chaals> DG: We don't see the ened to separate these. If you want it that's OK but we haven't seen anyone wanting that in the wild. Would like to discuss use cases, where you might not want it.
17:03:41 <chaals> AvK: There have been requests for it, eg for Ember wanting to reason about state in global app logic
17:03:52 <chaals> DG: eventpath gives you this information already
17:03:59 <chaals> AvK: Mumble mumble…
17:04:10 <chaals> DG: If others want this we can live with that.
17:04:25 <chaals> … But we do want open and event retargetting not to be coupled.
17:04:43 <chaals> EOC: You're fine with closed and retaregetting?
17:04:54 <chaals> DG: Think it is impossible not to do that.
17:05:09 <chaals> AR: Think that comes to the question of what closed really means, part of the semantics discussion.
17:05:18 <chaals> zakim, agenda?
17:05:18 <Zakim> I see 5 items remaining on the agenda:
17:05:19 <Zakim> 2. agenda bashing [from chaals]
17:05:19 <Zakim> 4. Jan…'s proposal for named thingo [from chaals]
17:05:19 <Zakim> 5. closed and open [from chaals]
17:05:20 <Zakim> 6. details of imperative distribution API, don't make it impossible. [from chaals]
17:05:20 <Zakim> 7. clarify event retargetting... [from chaals]
17:05:25 <chaals> zakim, close item 2
17:05:25 <Zakim> agendum 2, agenda bashing, closed
17:05:26 <Zakim> I see 4 items remaining on the agenda; the next one is
17:05:26 <Zakim> 4. Jan…'s proposal for named thingo [from chaals]
17:05:34 <chaals> Topic: Shadow boundary piercing combinators
17:05:44 <chaals> MJS: Bare minimum is they must not work in closed mode
17:06:19 <chaals> … named parts model is a better alternative ven for open mode. Making the style API contract depend on the exact structure is not a great pattern. We won't die on this hill if they are there for open.
17:06:27 <chaals> AvK: Postpone piercing to v2
17:06:37 <chaals> … would like to discuss styling the reprojected nodes and host
17:06:53 <chaals> … would like to discuss this, but feel we haven't got something good on the table
17:06:56 <chaals> agenda+ styling
17:07:40 <chaals> TL: Agree parts model would be good. Peter Linss yesterday helped me realise that if we let web devs style native controls we want to do it via a parts model, so would like to see that consistent with shadow DOM environment
17:07:57 <chaals> … think we can get away without this for v1 - there are some nice ugly hacks to do the job if necessary
17:08:06 <chaals> DG: We think it was a mistake and we want to get rid of it.
17:08:20 <chaals> … see research link in wiki page
17:08:34 <jan> Cheat sheat of browser vendor positions on contentious bits: https://docs.google.com/spreadsheets/d/1hnCoaJTXkfSSHD5spISJ76nqbDcOVNMamgByiz3QWLA/edit#gid=0
17:08:55 <chaals> … turned out to be a big footgun
17:09:15 <chaals> … definitely want to get this out of v1. Want a better styling model, so far it is still not satisfying…
17:09:28 <chaals> rrsagent, draft minutes
17:09:28 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/24-webapps-minutes.html chaals
17:09:53 <chaals> [Jan's summary doc shown]
17:10:58 <chaals> RESOLUTION: remove shadow piercing combinator
17:11:02 <chaals> rrsagent, draft minutes
17:11:02 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/24-webapps-minutes.html chaals
17:11:59 <chaals> Topic: consensu points...
17:12:08 <rniwa> could someone add a link to the minutes on https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting ?
17:12:27 <chaals> HI: We have a shadow element one level of the piercing combinator. Should we remove that too?
17:12:33 <MikeSmith> -> https://docs.google.com/spreadsheets/d/tkXdf761xqo8mM6G-dIomYg/htmlview#gid=0 Cheat sheet of browser vendor positions on contentious bits
17:12:37 <chaals> RESOLUTION: Yes.
17:12:51 <chaals> AvK: We want some kind of event retargetting, right.
17:13:03 <chaals> DG: Pending discussion...
17:13:37 <chaals> RESOLUTION: We need to understand what closed means, and based on that try to figure out event retargetting. (so we're on the way to knowing what we want…)
17:13:54 <chaals> s/want/want for event retargetting)
17:14:27 <hayato> s/shadow element/shadow pseudo element/
17:14:57 <sorvell> sorvell has joined #webapps
17:16:46 <Lenville> Lenville has left #webapps
17:17:55 <rniwa> rniwa has joined #webapps
17:17:59 <botie> botie has joined #webapps
17:18:33 <MikeSmith> botie, inform rniwa https://www.w3.org/wiki/index.php?title=Webapps/WebComponentsApril2015Meeting#Minutes
17:18:33 <botie> will do
17:19:50 <mjs> mjs has joined #webapps
17:20:51 <ebidel> ebidel has joined #webapps
17:21:09 <weinig> weinig has joined #webapps
17:27:03 <chaals> chaals has joined #webapps
17:27:33 <chaals> Chair: DGlazkov, chaals
17:27:52 <LJWatson> LJWatson has joined #webapps
17:29:19 <chaals> Preesnt+ HayatoIto, Rysouke, JanMiskovsky
17:30:04 <chaals> i/DG: Lots of people here/Topic: Introductions
17:30:12 <chaals> rrsagent, draft minutes
17:30:12 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/24-webapps-minutes.html chaals
17:30:31 <rniwa> rniwa has joined #webapps
17:30:31 <botie> rniwa, at 2015-04-24 17:18 UTC, MikeSmith said: https://www.w3.org/wiki/index.php?title=Webapps/WebComponentsApril2015Meeting#Minutes
17:31:07 <chaals> agenda?
17:31:19 <jcraig> jcraig has joined #webapps
17:31:34 <jan> jan has joined #webapps
17:31:59 <chaals> Topic: what does closed *mean*?
17:33:27 <sorvell> sorvell has joined #webapps
17:33:27 <chaals> AvK: So we have open, closed and isolated.
17:33:59 <chaals> …isolated we can defer. closed is one where the outside can't easily reach in, but for example prototyping can give you a way to poke in. I think that is acceptable...
17:34:01 <slightlyoff> q+
17:34:09 <chaals> TL: So the cfreator can grant access that they have?
17:34:14 <mjs> q+
17:34:30 <chaals> AvK: Other scripts can prototype objecst, and if other things use those modified prototypes that's OK
17:34:36 <chaals> q+ HI
17:35:07 <justin> q+ Justin
17:35:18 <chaals> … we decided to defer CSS, you can't reach in this way. For events the idea we had was for the event to internally have private slots where it has the full path. Depending on where you observe it, a public getter would return a filter.
17:35:40 <chaals> if you observe in the main tree the path would be up to the host, but if you observe it in the shadow tree on its way it has the full path and the target is the real target.
17:35:49 <chaals> … once dispatch is finished path would return nothing (empty list)
17:36:01 <chaals> … is there anything else in there? Just events, right?
17:36:05 <Travis> q+ given the holes in the simple closed mode, are folks that want closed still happy with this? What are their expectations?
17:36:09 <chaals> [Styling]
17:36:17 <chaals> AvK: That's awhole can of worms seperate.
17:36:23 <chaals> @@: Simple inheritance?
17:36:30 <Travis> q+
17:36:35 <chaals> AvK; Can we agree on this? Travis wanted something else.
17:36:37 <chaals> q?
17:36:40 <chaals> ack sl
17:36:44 <sorvell> q+ Steve
17:37:19 <chaals> AR: Couple of questions. Hardest: are there extra constraints placed on layout - if intrinsic width inside closed root would make closed item larger is that still possible in a component?
17:37:24 <wanderview> wanderview has joined #webapps
17:37:28 <chaals> … does it preserve natural constraint hierarchy of CSS
17:37:34 <chaals> AvK: Not sure about the question…
17:37:36 <wanderview> wanderview has left #webapps
17:37:44 <chaals> AR: Easier ones - do we have a list of who wants this and why?
17:37:48 <chaals> AvK: We had one...
17:38:12 <chaals> AR: Would be easier to answer the question of how closed closed is (more or less vs isolated) if we know which invariants we want to preserve
17:38:20 <chaals> Justing: Why closed but not isolated?
17:38:32 <chaals> AR: Acknowledge the uses are real but don't understand them yet.
17:38:33 <hober> From June 2011, mjs' 5 kinds of encapsulation: https://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html
17:38:38 <chaals> q?
17:38:54 <chaals> MJS: largley agree with AvK's operational definition.
17:38:55 <chaals> ack m
17:38:58 <hober> See "Why is encapsulation (type 2) important for components?" in that email
17:39:14 <wanderview_> wanderview_ has joined #webapps
17:39:21 <chaals> … goal of closed mode is to present leakage of internal deatils of component to DOM API. Not prevent leakage from sharing a scriptiing environment with host environement
17:39:30 <slightlyoff> I'd like to hear from framework authors on this
17:39:36 <chaals> … useful because 1. You can have a closed mode by rpeventing @@
17:39:45 <chaals> … building block for eventual isolated mode
17:39:59 <chaals> s/@@/leakage using seperate script environment
17:40:22 <chaals> … 2. Environments don't generally let you poe holes - it is a use case for specialised tools but should not be generally recommended.
17:40:39 <slightlyoff> I'm really concerned about this...isn't the redirection of .shadow the same thing as making the shadow root slightly more difficult to work with?
17:40:43 <chaals> … you *should*  be interacting with a closed component through defined interfaces not by poking into the shadow tree directly.
17:41:03 <chaals> … Think I showed how yu can build a closed mode with handwavy details, that isolates things - this is a start.
17:41:08 <chaals> ack next
17:41:13 <jcraig_> jcraig_ has joined #webapps
17:41:58 <mjs> q+ to add that another benefit of closed mode is better explaining the platform
17:42:03 <chaals> HI: speccing closed mode in shaodw so it behaves like virtual elements in blink. e.g. video uses shadow tree as structure. Expect closed should behave like this - don't expose structure to the outside. Shadow DOM isn't meant to provide security - that isn't its goal.
17:42:06 <chaals> ack next
17:42:14 <slightlyoff> this seems like a much taller hurdle than what Maciej just outline; can one get the SD of a <video> via __proto__ swizzling?
17:42:21 <slightlyoff> s/outline/outlined/
17:42:26 <chaals> Justin: value of closed but not isolated - idea that the current mode we have is wide open…
17:42:52 <chaals> … feel like the mode we have satisfies the goals already. By default you don't traverse into the shadow root, you have to go out of your way to even get in there already.
17:43:27 <chaals> … the idea of not attaching the shadow property by default doesn't make a difference, you can still work through it if you want but don't by default.
17:43:29 <rniwa> +q
17:43:41 <hayato> s/virtual elements/built-in elements/
17:43:46 <chaals> … don';t understand the value of a sort-of closed, we are already not encouraging people to poke inside and mess with stuff.
17:44:51 <chaals> AvK: We don't have them yet but for open case I would like that we add APIs that operate on the compose tree so you can query nodes across the whole tree. If you use shadow for organisaing your nodes and can reason globally, also for selection, then the distinction becomes meaningful…
17:45:44 <chaals> Juatin: Big concern is for tools operating in browser context if you want to operate on the whole doc, closed by default becomes really scary - you can't say "I know what I am doing, let me in to do linting, accessibility, etc etc"
17:46:00 <ebryn> sounds like he’s making an argument for open by default?
17:46:01 <chaals> … rationale to prevent people reaching in by accident has potential to shut off a lot of tools
17:46:10 <slightlyoff> so this is the root of it to me: is the argument about the potential difficulty? If so, I think we could make .shadowRoot harder
17:46:13 <chaals> SamW: isn't that already a problem with iframes?
17:46:21 <chaals> Justin: Yes, but they are less frequently used.
17:46:29 <slightlyoff> iframes are origin isolation primitives
17:46:32 <slightlyoff> they are "isolated"
17:46:37 <slightlyoff> they are not a reasonable proxy for this debate
17:46:43 <chaals> … we're talking about a world where pages may have a lot of components in them. Don't want pages with lots of iframes...
17:46:53 <chaals> … making compnents like iframes would be bad.
17:46:55 <chaals> ack next
17:47:37 <ebryn> this appears to be a discussion around continuing to enable global reasoning with open by default -vs- changing that by making shadow  DOM closed by default
17:47:43 <chaals> TL: Iframes are open by default modulo cross-domain security. If we ahve a simple closed model that will set the wrong expectations for dev community - no simple access to shadow DOM, so people will think they are protected, but it is too easy to work around that. So +1 to Justin.
17:48:10 <chaals> … Thinking about isolated model, don't think a sumple closed model is a building block for it. Boundary isn't around shadow DOM but around custom element layer.
17:48:21 <chaals> … so you can isolate custom element without needing shadow DOM.
17:48:36 <slightlyoff> where's the proposal
17:48:37 <slightlyoff> ?
17:48:43 <chaals> … have a proposal for that I sent out early this morning
17:48:45 <chaals> ack next
17:49:09 <Travis> Isolated components: https://github.com/w3c/webcomponents/wiki/Cross-Origin-Custom-Elements:-Concept-and-Proposal
17:49:17 <annevk> annevk has joined #webapps
17:49:18 <slightlyoff> thanks Travis
17:49:43 <chaals> SO: Justin said most of it. THis is a preview of event discussion but not sure there is wide understanfing of what event path it is. There is a correspondence between the shadow root and access to the event path. normal retargetting gives you basic protection - can be removed.
17:50:33 <chaals> … Disallowing people from looking inside is valuable, but. The web has things in global scope that evolved there. We see open as important so you don't shut off people dealing with that.
17:50:59 <ebryn> q+
17:51:15 <chaals> … in same sense as wy we don't like scope-piercing selectors, don't see the value of being able to poke in. Open is the legacy get out of jail for things that don't work well. Hopefully we move to a world where people don't want to poke inside.
17:51:34 <justin> q+ Justin
17:51:40 <chaals> AvK: Event path isn't a special API, it's a normal part of the event and should follow the same rules as target, not being a special poking pole.
17:51:57 <chaals> … first node in event path has to match target.
17:52:17 <chaals> ack next
17:52:18 <Zakim> mjs, you wanted to add that another benefit of closed mode is better explaining the platform
17:53:07 <chaals> MJS: Not sure my point is as good as I thought before… closed mode is a better tool for explaining the platform - no built-in element has an open shadow root, and that's reasonable.
17:53:33 <chaals> … built-in elements with secret structure even built from DOM are in isloated - you can't poke in. ut the isolated mode is built on a closed mode of shadowDOM
17:53:38 <chaals> … not doing something different.
17:54:04 <chaals> … can entertain models of isolated mode seperate from closing DOM layer, but that is how we actually do this for builtins so it seems like a good strawman to do the same for custom elements
17:54:06 <chaals> ack next
17:54:27 <chaals> Present+ Domenic
17:55:06 <chaals> RN: going toearlier point about lack of difference. We are removing shadow abuse, becaus people do that. Problem with exposing shadow root by default is people start abusing it, and learn that as a habit.
17:55:28 <hober> q+
17:55:36 <chaals> … so where tools do need poking, that's where they overide the prototype so they can. People who know that much know how to implement things righter.
17:56:09 <chaals> … fact closed doesn't expose things isn't bad, it's more encouragement not to poke inside as a default way to work. closed lets us have both ways.
17:56:14 <chaals> ack e
17:56:42 <chaals> EB: Been listening. from perspective of amber.js, I would recap this to say we are talking about changes in the programming model.
17:57:25 <dfreedm> s/amber.js/ember.js/
17:57:26 <chaals> … global reasoning vs isolated reasoning. I heard open by default is the current programming model of the web - work in a global environment
17:57:35 <chaals> Justin: that's not the basis for my argument.
17:58:13 <chaals> EB: Discussion is a desire to change the programming model from allowing global reasoning on everything, identifying everything inside to be manipulated - what I think of as open by default...
17:58:32 <chaals> … to something that makes it harder to do that. This is an important decision to make and I think is at odds with the way developers today want to work.
17:58:33 <Domenic_> q+
17:58:39 <chaals> … they will want to pierce shadows.
17:59:10 <chaals> … isolation in my mind is how we get something better than sandboxed iframes. Can bring security use cases, to what could be a nice component model
17:59:39 <chaals> Justin: to reply. My point isn't that we should live in the wild west of global everything - components have scopes.
18:00:03 <chaals> … but our default of open actually satisfies most goals - most stuff doesn't go inside the shadows so by default we already get scoping.
18:00:17 <chaals> … to think closed by default I want to understand the rationale better.
18:00:26 <chaals> … how does it add real value, since it doesn't isolate.
18:00:26 <misko> q+ from Angular’s point of view i think there is a difference between application level component and a Widget component. For us applications component should be open. Even for the Widget components I think the value of testing outweights the value of beign closed.
18:00:43 <sorvell> +q
18:00:48 <chaals> EB: I think there will be people who want queryselector to poke into shadow roots.
18:00:52 <chaals> … right or wrong.
18:00:56 <slightlyoff> q?
18:01:49 <misko> +q From Angular’s point of view we would like open components. The value of testing is high, the value of safety is not that valuable.
18:02:12 <misko> +q Angular’s point of view
18:02:17 <chaals> Justin: To rn, I know by monkey patching you can get back to where we are today but there are a lot of tools that might want to do this - screenreaders finding the active element, building screenshots, reaching the actual anchor page that fired a click event, debuggery...
18:02:24 <misko> +q
18:02:29 <chaals> … how do all these monkey patch in a way they don't step all over each other?
18:02:41 <chaals> … the esacpe hatch is tricky because people ahve to figure out how to cooperate.
18:02:43 <chaals> ack ju
18:03:01 <chaals> AvK: Not sure how tools is an argument if we are going to do isolated
18:03:03 <chaals> ack ho
18:03:04 <SteveF> SteveF has joined #webapps
18:03:26 <chaals> EOC: Open defends against accidental access - lower bar. Isolated is the high bar against everything.
18:03:36 <chaals> … closed mode is meant to defend against "normal access"
18:04:16 <chaals> … there are cases where people want to hack around the closed barrier. Now there is prototype etc, but it looks bad and the feature is that it feels bad to do that. It's about changing what is natural style.
18:04:37 <chaals> … debugging example is a weird one. Web inspectors have more priveliged access than the rest of the platform and that's a good thing.
18:05:01 <jan> jan has joined #webapps
18:05:09 <chaals> Justin: Working on polymer tools. Would love to make them cross browser. But when htey have to use priveliged APIs they are not standard and you have to close that option down.
18:05:33 <ebryn> Sounds like we need to standardize privileged access APIs to build tooling
18:05:37 <chaals> … want to enable more expressivity for people who are not in prveliged contxts
18:05:38 <hober> q?
18:05:38 <chaals> ack next
18:05:41 <slightlyoff> hober; fyi: Google Feedback does not live in a privileded context; it's just JS on a page
18:05:54 <slightlyoff> q+
18:06:14 <chaals> DD: Responding to point about how people will mess with shadow so why do we let them? People don't mess with _stuff even though it is possible, as a rule.
18:06:23 <chaals> … it isn't a security model, but people do feel bad if they do that.
18:06:29 <ebryn> make it ._shadowRoot
18:06:31 <ebryn> YES
18:06:35 <chaals> … maybe we should rename to _shadowRoot
18:07:09 <chaals> … this isn't a security boundary, it's a marker that you're being hacky now.
18:07:17 <chaals> … if you have a case for it, maybe you need it.
18:07:20 <wilsonpage> Localization is also relevant here. Nodes inside the shadow-root can need localized content provided by the document.
18:07:20 <dglazkov> q+
18:07:31 <chaals> … think there is a precedent - so long as it isn't really easy to get across then we are in good shape.
18:07:35 <chaals> ack next
18:08:05 <chaals> SO: +1 to the underscore. To relate polymer user experience - poking insdie hasn't been a problem.
18:08:05 <smaug> q+
18:08:13 <chaals> … it's clear that's naughtyish.
18:08:17 <wilsonpage> +1 to underscore
18:08:23 <weinig> q+
18:08:39 <mjs> q+ to mention default vs semantics
18:08:41 <chaals> … this is good for naive users, you don't want them poking in but, but if you want global reasoning don't use .shadowRoot.
18:08:44 <rniwa> +q
18:08:44 <chaals> ack mis
18:09:14 <ebryn> the problem is you still want things like custom elements and distribution
18:09:22 <ebryn> and to be able to globally reason
18:09:37 <chaals> Misko: on angular I echo the view of Justin, should be open. 2 kinds of components - those that are only for a particular app, and reusable widgets.
18:09:38 <annevk> Are we talking about what the default be or having the option at all?
18:09:39 <ebryn> this is a bridge for existing devs to the new world
18:09:56 <chaals> … From application POV these should be open - debug it, etc.
18:10:20 <chaals> … For reusable components, I would say the value of being able to debug far outwieghs the benefit of it being closed.
18:10:49 <jcraig> jcraig has joined #webapps
18:10:52 <chaals> … if we want to do testing and we can't reach in, I think this won't be good. From a framework point of view closed is little benefit, lot of pain.
18:11:13 <chaals> DG: framework people, what do you prefer - open or closed?
18:12:12 <chaals> Misko: We would prefer open, to allow debugging, that's huge
18:12:26 <chaals> EB: Instance property or something?
18:12:41 <chaals> Misko: In angualr you don't get the DOM for developing, but debugging you want to traverse everything.
18:12:49 <chaals> q?
18:13:01 <Travis> Turns out you can always `delete shadowRoot` to get closed model :)
18:13:35 <mjs> closed mode was about more than one property when we had shadow-piercing combinators
18:13:38 <chaals> EB: Not clear what happens. THere is a component the user is interfacing with. Ember has a component object. Not a DOM node, would love it to be a subclassed HTML element, it has an element property reflecting the shadowRoot of it.
18:14:03 <chaals> … we do composition in light DOM. We would expose shadowRoot as something like element - a public API for the implementor.
18:14:08 <annevk> q+
18:14:47 <chaals> … to app user of component, they will likely never directly reference componentn object, would subclass it to customise or use it from a declarative API in a template.
18:14:56 <chaals> … getting into inheritance vs composition.
18:15:25 <chaals> EB: Not toally obvious what implications of question open/closed but component author would have access. users wouldn't genreally have access to it except using inheritance.
18:15:32 <chaals> … composing being the happy path…
18:15:46 <chaals> … when debugging you will almost certainly expose the component.
18:16:01 <chaals> @@@: Polymer would make it open by default every time.
18:16:24 <chaals> … this is an encapsualtion primitive - good citizens wouldn't see or use the naughtiness. Maybe we are wedged on the colour of the roof.
18:16:31 <hober> q?
18:16:32 <chaals> … you wouldn't see the things inside.
18:16:48 <dglazkov> q-
18:17:00 <chaals> ack next
18:17:12 <chaals> AR: First point, reinforce what scott said.
18:17:14 <chaals> s/@@@/scott
18:17:44 <chaals> …think I can reflect the intent of .shadowRoot as being a speed bump. Made to stop people poking inside if they weren't seriously needing to do so.
18:17:57 <chaals> … We noted frameworks had _stuff that people didn't mess with.
18:18:23 <estellevw> estellevw has joined #webapps
18:18:37 <chaals> … advisory path had real weight in the world, and being fully closed seemed some disatnce away. Design intent is "don't use shadowRoot". closed is .shadowRoot. isolated means stay the %$#&^^ away.
18:18:51 <chaals> … as framework authors, how end users think isn't that open means wide open
18:18:55 <chaals> ack next
18:18:55 <Travis> +1 to slightlyoff
18:19:40 <chaals> OP: re XBL in firefox. There has been an issue that XBL is open and people poke inside. Addons break when they do that. So it would be useful to have closed mode there.
18:19:46 <chaals> mumbler: closed or isolated?
18:19:50 <chaals> OP: Closed
18:19:57 <chaals> EB: are they underscored?
18:20:00 <chaals> OP: No
18:20:09 <Travis> "open" -> "obscured", "closed" -> "closed"?
18:20:09 <chaals> EB: Then you lost the discuouragement effect...
18:20:16 <chaals> ack w
18:20:19 <zenorocha> zenorocha has joined #webapps
18:20:40 <ebryn> If you do not underscore the properties you don’t intend users to use, they will not know you didn’t intend them to use them
18:20:51 <chaals> SW: Question - blink thought shadow piercing combinators were a bad idea. Seems from a naive perspective that would apply to shadowRoot property - so why not?
18:20:55 <ebryn> Users don’t read your docs or understand your philosophy
18:21:09 <ebryn> They read other people’s code and cargo cult it
18:21:15 <chaals> DG: Comparison is interesting and it is a good question.
18:21:33 <chaals> … difference between CSS and DOM - DOM operations are ultimately malleable and user will get their way in the end.
18:22:00 <marcosc> marcosc has joined #webapps
18:22:05 <chaals> … ability of user to reach into shadow was not prevented. Shadow piercing combinator was to have a styling story, but it went wrong. There isn't a  way to do this other than poing into the shadow blocks.
18:22:40 <chaals> … abuse came because every framework is pretty advanced in understanding of component model  Thinking of authors about components is there -CSS still ahs thinking running on the global model.
18:23:17 <chaals> … bootstrap problem is because the framework insists on reasoning globally. shadowRoot wasn't such a problem because the "normal" thinking had already moved on to a componentise world.
18:23:35 <chaals> … data doesn't show the abuse of shadowRoot that we see for shadow piercing, despite the latter being around longer.
18:23:41 <chaals> ack next
18:23:42 <Zakim> mjs, you wanted to mention default vs semantics
18:24:01 <Travis> Point of shadow DOM itself is for style isolation (not DOM element isolation--that already exists), piercing combinator made it too easy to undo style isolation.
18:24:13 <chaals> MJS: Think we started trying to decide what closed mode should be. Wandered into discussion of default.
18:24:28 <chaals> … if we define it we need a default, but let's check in whether the semantics outlined are coherent enough to spec.
18:24:46 <yo3jones> yo3jones has joined #webapps
18:25:12 <chaals> … another thing to think is how frameworks want an openness hook.
18:25:26 <chaals> … there are a couple of levels. If we have both modes, and you can choose, then you can choose.
18:25:48 <chaals> … what might matter more is if others make a different choice - would it be a problem if others choose closed when frameworks shoose open?
18:25:56 <chaals> s/shoo/choo
18:26:15 <chaals> … if it isn't, then maybe we don't worry so much, and we don't *need* to set a default.
18:26:24 <chaals> … But are the semantics clear enough to spec?
18:26:52 <chaals> … I think Anne's outline is a reasonable strating point. Event retergetting is set up, no property pointing in, and no way for CSS to break in.
18:27:15 <chaals> … closed mode would not support shadow piercing combinators because that would be a violation of the basics.
18:27:17 <hober> q- annevk
18:27:26 <chaals> AvK: I wanted to say what Maciej said.
18:27:39 <chaals> … I agree my proposal is not as insane as it sounds.
18:27:57 <chaals> s/not as insane as it sounds/a useful thing. I don't care about the default thing.
18:28:08 <chaals> DD: We need a closed mode to explain HTML.
18:28:14 <chaals> AvK: HTML is isloated.
18:28:21 <chaals> DD: Wher closed is a subset of that it helps.
18:28:26 <chaals> q?
18:29:14 <justin> I'll direct it your way
18:29:15 <mjs> q+ for JS vs DOM
18:29:19 <slightlyoff> +1 to Travis
18:29:19 <chaals> TL: Don't see why isloating the DOM API is more satisfying that isloating the JS API. Web deveopers dont't distinguish these two as different parts of the platform. If you don't guarantee isollation, the barrier of event retargetting and blocking shadow root access isn't that relevant.
18:29:35 <slightlyoff> DOM is just a library for JS; treating it like some special case is creating a bug
18:29:36 <chaals> … prefer complete isolation like HTML elements than having this halfway point.
18:29:49 <Domenic_> +1... I assume closed would be a subset of the whole isolated thing but it would be better to have the whole isolated semantics spelled out
18:29:50 <chaals> … if you want to make closed, delete your shadowRoot propoerty.
18:29:55 <sorvell> q+
18:30:05 <ebryn> +1 to Travis
18:30:17 <chaals> RN: If you want open mode you can just not use shadow DOM? I don't think that;'s viable for frameworks.
18:30:39 <chaals> … there are frameworks that by default are open, and they don't want event retargetting, and want style isolation.
18:30:39 <wilsonpage> +1 Travis
18:30:43 <slightlyoff> q+
18:30:50 <ebryn> +1 rniwa
18:30:51 <chaals> … either sperate style isolation from shadow DOM, or make open mode more open
18:31:03 <chaals> … so people can select through shadows.
18:31:09 <justin> what frameks?
18:31:15 <chaals> … might need to discuss whether open model is the right openness
18:31:17 <slightlyoff> rniwa; can you talk about who wants this?
18:31:23 <chaals> zakim, close the queue
18:31:23 <Zakim> ok, chaals, the speaker queue is closed
18:31:23 <ebryn> we should have a mechanism to utilize custom elements, <template>, and distribution points in a more open mode
18:31:28 <chaals> ack rn
18:31:39 <justin> q+ Justin
18:31:40 <chaals> AvK: Agree with Ryosuke.
18:31:50 <chaals> zakim, open queue]
18:31:50 <Zakim> I don't understand 'open queue]', chaals
18:31:56 <chaals> zakim, open queue
18:31:56 <Zakim> ok, chaals, the speaker queue is open
18:31:59 <shepazu> shepazu has joined #webapps
18:32:00 <chaals> q+ justin
18:32:10 <justin> I don't know of anyone asking for more open outside the "bootstrap problem"
18:32:10 <chaals> zakim, close the queue in 3 minutes
18:32:11 <Zakim> I don't understand 'close the queue in 3 minutes', chaals
18:32:28 <Travis> Zakim wants this discussion to continue.
18:32:47 <chaals> AvK: Doesn't amake sense for event path not to match the target. If you have the open model the event would go over a composed tree and everyone can see that, in closed you get real retargetting…
18:33:10 <rniwa> rniwa has joined #webapps
18:33:19 <chaals> … we might want a mode where seletors operate on the compsed tree, so the boundary is only for compositoin, everything is global.
18:33:30 <chaals> EB: We want that.
18:33:36 <hober> q?
18:33:41 <chaals> ack m
18:33:41 <Zakim> mjs, you wanted to discuss JS vs DOM
18:33:55 <ebryn> it’s how we can migrate our users transparently to these primitives / shadow DOM
18:35:03 <chaals> [straw poll: any consensus on a closed mode? apparently not…]
18:35:41 <chaals> zakim, close queue
18:35:41 <Zakim> ok, chaals, the speaker queue is closed
18:36:05 <chaals> MJS: Travis said DOM and JS aren't separated…
18:36:38 <chaals> … think that is true to some extent but there is a conceptual dividing line. Reaons to have closed AND isolated is because JS is weird. Where you can't monkey-patch everything all the time, closed == isolated
18:37:00 <ebryn> I think the point that you can create closed mode at runtime by deleting the `_shadowRoot` property was a good point
18:37:10 <chaals> … if we want isolated, at least being able to close the APIs is a first step. Then deal with the language problem that is javascript-specific
18:37:23 <Domenic_> Agree, but why do this in stages? Why not come up with a coherent proposal all at once?
18:37:31 <chaals> … you could imagine JS going away, and then isolated would not be relevant.
18:37:43 <chaals> … so makes sense to start with closed then build isolated n that
18:37:45 <chaals> ack next
18:38:15 <ebryn> q+
18:38:46 <chaals> SO: Original question - would framework people consider closed a big obstacle. No, don't think people would use it much, it's OK if it is a stepping stone to isolated. If implementros think it is important, as a happy user of shadowDOM, we want shadow DOM so we don't want to hold it up from shipping on this point.
18:38:49 <chaals> ack sl
18:39:47 <chaals> AR: When we tried to introduce DART we designed a new DOM for it. That was of course an improvement on the actual web and therefore failed.
18:40:03 <chaals> … It is a poor choice to assume you must inherit everything we have today in the future.
18:40:32 <chaals> RESOLUTION: We're not attempting to address the post-javascript web
18:40:55 <chaals> AR: Not sure I understand a "more open open". Nor that there are people clamouring for it especially in v1
18:41:28 <chaals> … people are using current shadowDom.
18:41:41 <chaals> EB: Poeple are using open open mode, 1% who tried shadow DOM are not representative.
18:42:03 <chaals> AR: Shadow came from an open open world, and we are trying to repair some of its worst excesses.
18:42:13 <chaals> AvK: Open open lets people ease towards closed.
18:43:35 <Travis> Present+ Travis_Leithead
18:43:42 <chaals> rrsagent, draft minutes
18:43:42 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/24-webapps-minutes.html chaals
18:55:52 <blazejewicz> blazejewicz has joined #webapps
19:02:04 <jyasskin> jyasskin has joined #webapps
19:05:45 <mjs> mjs has joined #webapps
19:16:56 <SteveF> SteveF has joined #webapps
19:21:05 <jyasskin> jyasskin has joined #webapps
19:21:20 <joannawu> joannawu has joined #webapps
19:32:43 <wilsonpage> wilsonpage has joined #webapps
19:32:45 <philipwalton> philipwalton has joined #webapps
19:53:48 <LJWatson> LJWatson has joined #webapps
19:56:33 <mjs> mjs has joined #webapps
19:58:21 <jan> jan has joined #webapps
19:59:55 <tantek> tantek has joined #webapps
20:00:34 <taylor> DG: Ready to reach decision on open/closed and the default
20:01:01 <taylor> DG: We will have both closed and open mode in v1 - can you live?
20:01:14 <taylor> MJS: Yes
20:02:01 <taylor> TL: Good description: similar to what you get with javascript closures today.
20:02:36 <taylor> TL: I'm in. Yes
20:02:41 <taylor> DG: Yes
20:03:02 <taylor> RESOLUTION: Yes on closed and open in v1
20:04:46 <taylor> DG: Default?
20:05:05 <Travis> Travis has joined #webapps
20:05:16 <taylor> AR: On the minutes that I object to required, no default
20:05:45 <taylor> RESOLUTION: You have to make a choice
20:06:08 <taylor> RESOLUTION: Clarified: no default, required to decide open or closed
20:06:43 <chaals> agenda?
20:06:58 <chaals> zakim, close item 5
20:06:58 <Zakim> agendum 5, closed and open, closed
20:06:59 <Zakim> I see 4 items remaining on the agenda; the next one is
20:06:59 <Zakim> 4. Jan…'s proposal for named thingo [from chaals]
20:07:28 <taylor> DG: Retargeting
20:07:47 <chaals> i/DG: Retarg/Topic: Event retargetting/
20:07:53 <chaals> rrsagent, draft minutes
20:07:53 <RRSAgent> I have made the request to generate http://www.w3.org/2015/04/24-webapps-minutes.html chaals
20:07:58 <taylor> AvK: Proposal: rename path to composedPath. We should not tie it to open/closed but let you choose between retargeting or not in open mode
20:08:51 <chaals> Present+ AliceBoxhall, WilliamChen
20:08:57 <sorvell> sorvell has joined #webapps
20:09:08 <Travis> q+
20:09:13 <markg_> markg_ has joined #webapps
20:09:22 <chaals> zakim, open queue
20:09:22 <Zakim> ok, chaals, the speaker queue is open
20:09:26 <chaals> q+ travis
20:09:32 <chaals> q- justin
20:09:45 <taylor> SM: nervious about keeping the path name but having it return something different
20:09:54 <chaals> Present+ ScottM
20:10:01 <jcraig> jcraig has joined #webapps
20:10:11 <chaals> Present+ ErikBryn
20:10:48 <sorvell> q+
20:11:07 <chaals> Present+ MarkG, SteveOrvell
20:11:31 <taylor> TL: Could we avoid adding a second path property before nailing the first one?
20:11:48 <weinig> weinig has joined #webapps
20:11:56 <taylor> DG: Event delegation is broken for composition
20:12:19 <chaals> Present+ Misko
20:12:27 <taylor> DG: Event delegation = instead of registering event listeners on elements, frameworks listen to everything and have their own event system managing that
20:12:46 <taylor> DG: If path does not include the full composed tree, you can reason where the event came from
20:13:09 <chaals> Present+ WilsonPage
20:13:22 <aklein> q+
20:13:46 <taylor> AvK: We probably need another term that means open but not closed
20:13:57 <chaals> ack tr
20:14:00 <chaals> ack so
20:14:24 <chaals> Present+ AdamKlein
20:14:31 <taylor> SO: Composed path or shadow path is fine. In closed mode you just don't get .shadowRoot or .shadowPath. They can return the same as path
20:15:23 <chaals> ack akl
20:15:58 <taylor> TL: Why would we introduce something that doesn't take into account shadow DOM automatically?
20:16:31 <rniwa> +q
20:16:32 <taylor> AvK: Wouldn't object if we don't introduce it. Want a different name. Path is target to root. If we want to introduce that, which makes sense, we should call that path.
20:17:08 <taylor> AK: Assuming we get composed path, having path or not is not a question that has to do with web components
20:17:10 <chaals> ack rn
20:17:21 <mjs> mjs has joined #webapps
20:17:27 <LJWatson> LJWatson has joined #webapps
20:17:39 <taylor> RN: We don't want to expose the nodes in closed shadow dom?
20:17:41 <taylor> Consensus: No
20:17:55 <taylor> Consensus(clarified): We don't want to expose the nodes in closed roots
20:18:12 <SteveF> SteveF has joined #webapps
20:18:32 <taylor> DG: We can designate AvK to choose the name of this path
20:18:51 <taylor> AvK: I decide "deepPath"
20:18:55 <taylor> DG: Maybe we should designate a new person
20:19:51 <taylor> AvK: Event retargeting is an option in the open case, and defaults to retarget? A switch on the constructor
20:19:59 <justin> q+
20:20:00 <chaals> agenda?
20:20:44 <marcosc> marcosc has joined #webapps
20:20:47 <taylor> JF: Don't know how it makes sense to not retarget on an open root
20:21:12 <dglazkov> RESOLUTION: Event.path is local to shadow tree/document, Event.deepPath is what Event.path spec'd now.
20:21:33 <chaals> [DomenicD shows three possibilities when you can retarget or not, and be open or closed - except we don't allow no retargetting on closed]
20:21:41 <taylor> AvK: Would be OK with not adding the switch
20:22:05 <dglazkov> RESOLUTION: Event.deepPath does not include closed shadow trees
20:22:27 <taylor> SO: Any event delegation case should be solved by deepPath
20:22:49 <dglazkov> RESOLUTION: Event retargeting happens
20:23:19 <dglazkov> Zakim: close item 7
20:23:30 <dglazkov> Zakim, close item 7
20:23:30 <Zakim> agendum 7, clarify event retargetting..., closed
20:23:31 <Zakim> I see 3 items remaining on the agenda; the next one is
20:23:31 <Zakim> 4. Jan…'s proposal for named thingo [from chaals]
20:23:33 <chaals> agenda?
20:24:59 <chaals> Topic: Named slots
20:25:04 <taylor> DG: Let's go on to slots
20:25:50 <chaals> Present+ TaylorSavage
20:25:51 <weinig> weinig has joined #webapps
20:25:52 <taylor> JM: Different from other issues - was just published tuesday. May be premature for people to feel comfortable settling if they haven't had a chance to digest it.
20:25:55 <mjs> mjs has joined #webapps
20:26:39 <taylor> JM: Deals with way component author specifies content for distribution points
20:27:19 <taylor> JM: Aesthetic argument: saw people using selectors in odd ways for this
20:27:57 <taylor> JM: Can't look at instance of a component and tell what it is doing. Like languages that have named arguments vs. just comma-differentiated arguments
20:28:54 <taylor> JM: Makes subclassing easier - overriding by name
20:29:26 <taylor> JM: Summary: rather than having select attribute on content element, would have an attribute that indicates the name for the insertion point..
20:29:59 <taylor> JM: Component instances in the light DOM apply an attribute that designates the named insertion point that they want the element distributed to
20:30:30 <taylor> JM: Elements in light dom without a name would end up in the default insertion point
20:30:41 <taylor> DG: Second part to the proposal - do you think we can discuss in separation?
20:31:07 <sorvell> q+
20:31:17 <taylor> JM: Second part was to indicate desire to see subclassing expressed in the platform
20:31:55 <taylor> JM: Want to achieve separation of concerns, and subclassing is a core feature for that
20:32:02 <misko> q+ slots reverses the role of who is doing the designation. +1
20:32:13 <misko> q+
20:32:21 <taylor> JM: We don't currently specify a way for a subclass to contribute to the base class's tree
20:32:58 <rniwa> +q
20:33:03 <taylor> JM: Seems possible that we might be able to tackle these pieces separately
20:33:10 <taylor> AvK: Would like to tackle separately
20:33:31 <taylor> AvK: Subclassing you propose includes modifying the existing shadow tree in place
20:33:58 <hayato> +q
20:34:05 <taylor> DG: Let's discuss slots on their own merit
20:34:13 <chaals> ack ju
20:34:31 <taylor> JF: Disagree with slot proposal.
20:34:38 <taylor> JF: Important to optimize for end-user of custom elements
20:34:53 <taylor> JF: Right now, developers of CE have choice in how they craft their "light children" API
20:35:13 <taylor> JF: Can look at content slot mechanism as subset of select="[slot-name=...]"
20:35:36 <taylor> JF: Giving authors this power lets them have some choice.
20:35:58 <taylor> JF: We're envisioning a future where we have this marketplace of elements that compete on their merits
20:36:04 <Travis> q+
20:36:12 <ebryn> q+
20:36:44 <taylor> JF: Want to give element author the ability to craft a nice component API.
20:36:49 <chaals> ack so
20:36:51 <jan> q+
20:37:02 <taylor> SO: Hesitant about slot
20:37:14 <taylor> SO: Clearly less expressive. Limited css selector vs. single attribute
20:37:19 <taylor> SO: Not sufficient to explain the platform
20:37:42 <taylor> SO: Predicated on idea that expressiveness is good. This could be democratically decided, rather than forcing it in the platform.
20:38:01 <taylor> SO: Not a complete proposal. Would have to really strongly agree that explicitness is so important that we'd need to flesh it out
20:38:29 <taylor> SO: Using select enables you to do reprojection with different selectors down the tree.
20:39:06 <chaals> ack mis
20:39:11 <hober> q+
20:39:24 <taylor> Misko: In general, like the explicitness of it
20:39:43 <taylor> Misko: Enumerating them gives ability for tools to reason about it
20:39:47 <chaals> ack rn
20:39:51 <chaals> q+ anne
20:39:53 <sorvell> q+ (Scott)
20:40:21 <taylor> RN: We strongly believe that supporting a selector based distribution is wrong
20:40:57 <taylor> RN: In a selector based approach, we have to evaluate the selector each time we distribute a node. The timing of which that happens is not obviously spec'd. We end up having to evaluate each time in order to change it.
20:41:35 <justin> Q+
20:41:38 <justin> q+
20:41:51 <chaals> ack haya
20:41:52 <LJWatson> LJWatson has joined #webapps
20:41:52 <taylor> RN: We strongly feel imperative API is important.
20:42:18 <dglazkov> +q
20:42:30 <taylor> HI: Every browsers has already implemented CSS selector. We can re-use it. If it evolves we can benefit from it.
20:42:35 <justin> the distribution timing isn't any different, is it?
20:42:41 <justin> I didn't see that as part of the proposal
20:42:45 <taylor> HI: It's very efficient. It's only distributing nodes. Don't have to traverse up or down node tree.
20:43:04 <taylor> HI: Disabled support of psuedo-classes, and received lots of complaints from the community
20:43:11 <chaals> ack tr
20:43:19 <taylor> HI: Afraid we will receive lots of complaints if we disable selector-based distribution
20:43:35 <taylor> TL: Support proposal with slots
20:44:15 <taylor> TL: Having to declare your intention to be selected by a shadow dom maybe doesn't seem that important right now, but if we want to enable content distribution from within an isolated environment, the cross-domain untrustable component trying to select stuff from your light dom would be bad
20:44:33 <taylor> TL: Have a much better contract with your component by explicitly naming a slot
20:44:45 <taylor> TL: Would have to not have the select feature in an isolated model
20:44:59 <taylor> JF: Don't default slots challenge that? if you have  default slot, you don't have to explicitly opt-in
20:45:01 <chaals> ack ebr
20:45:07 <taylor> TL: Not familiar with default slot
20:45:44 <taylor> EB: Believe slots is the right approach
20:46:02 <taylor> EB: Want to see death of selector-based programming. Only to be used in style.
20:46:55 <chaals> ack ja
20:47:00 <taylor> EB: Considered imperative API a blocker. Seems clearer how to get here with sots approach.
20:47:23 <taylor> JM: Not excited about the idea at a late date to reopen something. Excited to see Shadow DOM adopted by all browsers.
20:47:43 <justin> We really need to work out how this proposal leads to imperative API, I don't see what it changes
20:48:59 <taylor> JM: History has shown that more flexibility is not always better
20:49:40 <taylor> hober: Point was made that we should democratically let users decide how to do this. Two conventions: css class, or attribute. Both are poor man's slot name
20:49:46 <chrisb> chrisb has joined #webapps
20:49:54 <hober> q-
20:50:01 <taylor> JM: Would be elegant if you could include a slot name as a tag
20:51:34 <taylor> Domenic: Current HTML uses tag name
20:52:10 <joannawu> joannawu has joined #webapps
20:52:13 <chaals> ack ann
20:52:17 <taylor> JM: Have an emerging sense that the use of CSS selectors is not a great fit for how people are trying to use it.
20:52:39 <taylor> AvK: Like the slots proposal in general. Like that it's opinionated and would allow us to expose an API on shadow root or host element to enumerate the slots
20:52:51 <taylor> AvK: Liked Domenic's idea of using the element name instead, because it explains existing elements
20:53:26 <mjs> q+ to talk about tag names
20:53:32 <chaals> ack (sc
20:53:36 <taylor> EB: But you can have more than one of the same CE's
20:53:47 <taylor> SM: Not a fan of slot.
20:54:16 <taylor> SM: In response to explicitness: it's leaking implementation details of my component. Don't want you to know what you're using to insert.
20:54:18 <chaals> q+ jan
20:55:00 <taylor> SM: My element is simply a name, and I give you a contract in how to use it, but not how I achieve it
20:55:38 <chaals> q+ to say you're not forced to expose details, but you may want to, no?
20:55:49 <taylor> SM: Hard to decide in isolation "this is a vocabulary everyone should use"
20:56:14 <taylor> SM: This is why democratization is important.
20:56:39 <taylor> SM: That anything but slot blocks imperative API is a red herring
20:57:00 <taylor> SM: That two patterns, classes or attributes, have emerged is not a bad thing
20:57:05 <chaals> q+ and to ask if there is a need for this in v1… what dies without doing something like this?
20:57:12 <taylor> SM: People have different needs.
20:57:16 <taylor> JM: Why do you use both?
20:57:38 <taylor> SM: I don't presuppose that I want to dictate the answer for eternity - that's the point
20:57:57 <taylor> SM: Would like to let users tell me if that is good or bad
20:58:05 <taylor> SM: Want to see which one is best, not decide for the universe
20:58:12 <chaals> ack ju
20:58:23 <taylor> JF: Re: flexibility to craft your own api
20:58:44 <taylor> JF: Analogy to named arguments of functions - slot is forcing that you have to use the named argument. Very restrictive.
20:59:05 <taylor> JF: You can't look at current set of elements as exemplary of what all elements will look like.
20:59:35 <taylor> JF: Class, attribute, tag name - that all are used demonstrates that people are using the full expressiveness of selectors
21:00:01 <taylor> JF: Seeing people make use of the different options they have. Would counter argument that they're following into a category that we need to codify.
21:00:29 <taylor> JF: Can select on attribute values. "[section=...]"
21:00:41 <taylor> JF: Compound and complex selections - can make API's that evolve in the future
21:00:56 <taylor> JF: With slots, if you pick a name, but want to change that name later, you have to figure out multiple names
21:01:09 <taylor> JF: Should think about elements as API's that can evolve in the future, and need to give them flexibility
21:01:20 <chaals> q-
21:01:23 <taylor> JF: Don't see how the timing changes at all, or how it effects how to do imperative API.
21:01:25 <chaals> q+ to ask if we need this in v1
21:01:43 <taylor> JF: Still have to do style recalc
21:01:56 <taylor> JF: We all want to see imperative API. Timing seems to be toughest part, not how you select nodes.
21:01:58 <chaals> ack dgla
21:02:18 <taylor> DG: Going to stay away from aesthetics debate
21:02:31 <taylor> DG: Don't believe we can in this century definitively declare that one is better than the other
21:02:36 <taylor> DG: Instead, on timing and implementation details
21:02:52 <taylor> DG: From spec perspective, this is a very minor change.
21:02:56 <wilsonpage> q+
21:03:34 <taylor> DG: You will still have the same issue - if you call offset-top you will need to know where it is distributed
21:03:57 <taylor> DG: Because distribution is really fast you might be able to make it synchronous, but this will slow down dom operations. still have timing issue.
21:04:03 <taylor> DG: This is purely an aesthetic debate
21:04:05 <rniwa> +q
21:04:15 <chaals> ack mj
21:04:15 <Zakim> mjs, you wanted to talk about tag names
21:04:20 <taylor> DG: As aesthetic debate, we need to say "can you live with" and proceed from there
21:04:36 <taylor> MJS: Re: tag names as distribution hooks
21:04:38 <chaals> q- later
21:05:06 <taylor> MJS: If you look at HTML elements, in all cases the hook is a tag name that is designed to have a special meaning within the context of a fixed set of other containers
21:05:34 <taylor> MJS: The choice of having your hook be an element name, class name, or attribute name - they all end up pointing to the same thing
21:05:48 <taylor> MJS: Ends up being a superficial choice
21:06:56 <chaals> ack jan
21:07:00 <chaals> ack wil
21:07:24 <taylor> WP: Arguments against are around lack of devs having expressiveness
21:07:41 <taylor> WP: Could Polymer team live with imperative API?
21:08:17 <taylor> SO: If there's lack of expressiveness and imperative gives you the expresiveness, sure. But this seems to be a red herring.
21:08:54 <taylor> RN: Timing is still an issue. Need to decide when imperative API is used.
21:09:19 <taylor> RN: When you insert a node that specifies which slot it belongs to, at that moment we could have a mapping that tells you where it goes right away
21:09:45 <taylor> RN: In current model, any time anything changes, it's ambiguous if that node needs to be distributed
21:10:09 <taylor> MJS: Slots collapses choosing what gets distributed into a simple map
21:10:28 <taylor> MJS: If you add N things and each time need to recompute what gets distributed where, you get N^2
21:10:42 <taylor> DG: The way distribution spec is designed today, it's a tree walk. It's linear.
21:10:57 <marcosc> marcosc has joined #webapps
21:11:39 <taylor> MJW: Selector evaluation can't be reduced to a map lookup
21:11:53 <taylor> AR: These are simple selectors - you can't do descendent selectors.
21:12:14 <marcosc> marcosc has joined #webapps
21:12:15 <taylor> AR: Slots and select are isomorphic to each other (in terms of big O)
21:12:43 <marcosc> marcosc has joined #webapps
21:12:47 <marcosc> marcosc has joined #webapps
21:17:04 <jan> jan has joined #webapps
21:18:47 <taylor> [Break]
21:19:31 <LJWatson> LJWatson has joined #webapps
21:19:41 <wchope> wchope has joined #webapps
21:30:08 <tantek> tantek has joined #webapps
21:31:04 <mjs> mjs has joined #webapps
21:39:41 <LJWatson> LJWatson has joined #webapps
21:44:17 <sorvell> sorvell has joined #webapps
21:53:46 <shepazu> shepazu has joined #webapps
22:01:58 <mjs> mjs has joined #webapps
22:02:04 <jan> jan has joined #webapps
22:03:08 <chaals> agrnda?
22:03:11 <chaals> agenda?
22:03:18 <chaals> s/agrnda?//
22:03:19 <weinig> weinig has joined #webapps
22:03:29 <sorvell> sorvell has joined #webapps
22:03:48 <taylor> Back!
22:04:02 <taylor> DG: Following an exciting discussion on the slots proposal, we have a couple options
22:04:29 <taylor> DG: Would like to separate the issue: is it just aesthetics, or does it really bring concrete perf gains that allow us to do distributions in near-constant time?
22:04:37 <taylor> DG: Which opens up the opportunity for very simple imperative API
22:04:38 <chaals> q+ anne
22:04:42 <chaals> q-
22:04:45 <chaals> q- rn
22:04:53 <taylor> DG: Options:
22:05:05 <taylor> DG: 1. don't do imperative API in v1 and go with content select
22:05:11 <taylor> DG: 2. Don't do imperative API and go with slots
22:05:21 <taylor> DG: 3. Imperative API and one of the other proposals
22:05:26 <sorvell> q+
22:05:33 <taylor> DG: (imperative and declarative as part of v1)
22:05:44 <taylor> DG: Needs to be time to fully put slots proposal through their paces and exercise it mentally
22:06:14 <shepazu> shepazu has joined #webapps
22:06:21 <ebryn> +1 to imperative API as part of v1
22:06:29 <taylor> DG: propose we nominate people to do due diligence and bring it to a concrete proposal
22:06:49 <taylor> DG: s/propose/4/
22:07:11 <taylor> JM: Could do enough design work on imperative API that we have a good answer, but do it later
22:07:30 <taylor> DG: Should be a prerequisite for 1. or 2.
22:07:43 <chaals> ack an
22:07:56 <rniwa> +q
22:07:59 <mjs> q?
22:08:22 <taylor> AvK: If you get hold of a node inside shadow tree and dispatch the event, you can observe on the path what the distribution is
22:08:36 <taylor> AvK: This will very synchronously require you to do this synchronously
22:08:42 <taylor> DG: Yes, this is correct
22:08:48 <chaals> ack sor
22:09:17 <taylor> SO: Want to emphasize that the slot proposal is incomplete. When you just have one name, this is unacceptable for reprojection
22:09:30 <taylor> SO: Slot needs to be studied more and fleshed out
22:09:39 <taylor> RN: Qualify that imperative API is important
22:09:40 <chaals> q+
22:09:46 <chaals> ack rn
22:09:48 <taylor> RN: Another option - no node distribution in v1
22:09:56 <taylor> RN: Worst case scenario
22:10:14 <taylor> RN: Timing of distribution is very important
22:11:07 <taylor> RN: Maybe it is better to focus on imperative API. Then each framework could emulate either syntax to figure out best declarative syntax.
22:11:37 <taylor> CMN: is there anyone that would be happy without any distribution
22:11:41 <taylor> [basically everyone]
22:11:52 <taylor> RESOLUTION: We need distribution of some sort in v1
22:12:08 <taylor> CMN: Is there anyone who can't live with starting at imperative API?
22:12:36 <taylor> CMN: Is there anyone opposed to starting out with an imperative API?
22:12:46 <taylor> [murmuring]
22:12:59 <taylor> CMN: Everyone wants an imperative API. Everyone wants distribution.
22:13:11 <taylor> CMN: Is there anyone that thinks they need to start by figuring out a declarative API?
22:13:33 <taylor> DG: Seems like we have enough difference of opinion in declarative API, the next step is we need to talk about the imperative API
22:13:42 <taylor> SO: We want this thing to ship.
22:13:47 <rniwa> +q
22:13:49 <chaals> q+
22:13:57 <chaals> q- later
22:13:59 <taylor> SO: We have a declarative API, we don't have an imperative API
22:14:25 <hober> q?
22:14:44 <chaals> ack rn
22:14:56 <taylor> RN: Imperative API got shot down because it wasn't compatible with content select
22:15:03 <taylor> RN: From imperative, we can start implementing
22:15:14 <taylor> RN: We can have more evidence from there as to what the right declarative syntax is
22:15:38 <taylor> RN: We need to start from things we can agree on
22:16:08 <taylor> CMN: Who cannot live with select api?
22:16:25 <taylor> CMN: Who cannot live with slots?
22:16:29 <taylor> [some for each]
22:16:46 <taylor> CMN: Need to come back after working on proposals
22:16:49 <shepazu> shepazu has joined #webapps
22:16:53 <taylor> CMN: For now, we're trying to see if we can get to imperative API
22:17:11 <dglazkov> Zakim, agend
22:17:11 <Zakim> I don't understand 'agend', dglazkov
22:17:11 <taylor> CMN: So what does the imperative API look like again?
22:17:13 <dglazkov> Zakim, agenda
22:17:13 <Zakim> I don't understand 'agenda', dglazkov
22:17:25 <chaals> agenda?
22:17:38 <taylor> SM: Curious if the people at the whiteboard could say if imperative API will nerf our performance?
22:17:42 <dglazkov> agenda?
22:17:48 <smaug> rniwa: do you have a link to the old imperative API proposal
22:17:58 <taylor> RN: If API's that call back to JS any time any dom was modified in light dom, not acceptable
22:18:11 <taylor> RN: If we did it at end of microtask, like MO, perf impact is much smaller
22:18:46 <taylor> AvK: The only observable thing is that synchronous layout getters don't work
22:19:21 <taylor> JF: Isn't breaking the habit on layout forcing habits a bandaid we need to rip off at some point?
22:19:34 <dglazkov> q+
22:19:40 <chaals> ack ch
22:19:44 <chaals> ack dg
22:19:45 <taylor> JF: Need to recognize that exploring this path might not be successful
22:20:18 <rniwa> my proposal for imperative API: https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0376.html
22:20:28 <rniwa> +q
22:21:03 <taylor> Domenic: reportValidity, scrollIntoView - isn't it OK if we delay this a microtask
22:21:12 <taylor> DG: No, not ok. This is how developers have been using this.
22:21:44 <chaals> ack rn
22:21:56 <taylor> RN: Link to proposal: https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0376.html
22:22:08 <Travis> Travis has joined #webapps
22:22:22 <taylor> RN: add and remove to content element (names can change), will take new element in a light dom that gets distributed to insertion point
22:22:44 <taylor> RN: Just does exactly one time distribution
22:22:46 <mjs> q?
22:22:50 <mjs> q+
22:22:52 <taylor> RN: You would use mutation observers to update distributed nodes
22:22:53 <sorvell> q+
22:23:00 <taylor> RN: Most primitive API could come up with
22:23:20 <taylor> DG: This would work if we said "If you decide to use this API, you're on your own, you have to figure this out."
22:23:35 <taylor> RN: Drawback - you can't really reorder nodes inside insertion point
22:23:44 <taylor> RN: Need array potentially to add and manipulate from arbitrary points
22:24:08 <taylor> RN: Everything is synchronous
22:24:25 <taylor> AvK: Component author would write mutation observers, they'd have to wait for the MO's to fire before nodes get distributed again
22:24:50 <taylor> RN: Also lifecycle callback in CE about children being changed
22:25:02 <taylor> RN: Maybe could update nodes when we exit C++ code of node being added
22:25:18 <taylor> DG: Reprojection would be done by hand
22:26:00 <taylor> MJS: What's tricky is timing
22:26:23 <taylor> MJS: Hard to tell in abstract whether next microtask is good enough, as opposed to current style resolution timing
22:26:30 <chaals> [straw poll - how many people ok with this idea so far - more, how many terrified so far - some]
22:26:48 <taylor> MJS: Style resolution timing is imprecise too
22:27:16 <taylor> MJS: Might require someone to try implementing it to see if in practice it is bad
22:27:17 <chaals> ack mj
22:27:19 <taylor> DG: Sounds like a task force
22:27:53 <philipwalton> philipwalton has joined #webapps
22:27:54 <taylor> SO: If we have RN's proposal that distribution is synchronous, I would say MO information is not sufficient to do reprojection
22:28:02 <Domenic_> It would be good to have examples of existing use cases to show that this would suffice for them and how it would be coded.
22:28:04 <taylor> SO: Would hope we could add information about distributed nodes changed to MO
22:28:15 <chaals> s/ MO /mutation observer
22:28:23 <chaals> s/to MO/to mutation observer
22:28:30 <taylor> SO: We're opening up the door for: Polymer could create a flush mechanism; all the mutation observers take records
22:29:05 <taylor> SO: not a good signal on way to do redistribution with the information that mutation observers surface currently
22:29:06 <slightlyoff> q?
22:29:11 <slightlyoff> q+
22:29:22 <rniwa> q+
22:29:31 <chaals> ack sor
22:29:33 <chaals> ack sli
22:29:39 <taylor> AR: question of imperative-only seems at odds that there's a large simplification to be had with naming slots
22:29:51 <taylor> AR: degrees of freedom continue to accelerate as you go toward imperative
22:30:10 <taylor> AR: Could look at properties, for example
22:30:21 <taylor> AR: Thinks we should definitely have imperative API's in the platform
22:30:40 <sorvell> q+ Scott
22:30:44 <chaals> [+1 to Alex' concern…]
22:30:49 <taylor> AR: Worries this will hurt inter-framework interoperability quite a lot
22:30:49 <ebryn> +1 to alex
22:30:50 <chaals> ack rn
22:31:13 <taylor> RN: Can add synchronous event or new record to mutation observer.
22:31:28 <Domenic_> q+
22:31:29 <chaals> ack sc
22:31:53 <taylor> SM: First version of Polymer had a lot of asynchronous behaviors - horrible for end-users
22:32:19 <taylor> SM: Nervous about any change where the user doesn't know "can I talk to this node now?" will cause lots of user confusion
22:32:25 <chaals> ack dom
22:32:29 <taylor> SM: Cautionary tale about asynchrony as it impacts end-users
22:32:59 <taylor> Domenic: Would really like to see all of the existing use-cases showing how you would write this. With Polymer elements, for select and option, and details and summary.
22:33:14 <taylor> Domenic: Want to see that it addresses all the use-cases that selectors do and perhaps more complicated things
22:33:32 <taylor> Domenic: a childrenChanged callback would make it nicer, synchronousish
22:33:53 <taylor> Domenic; Should be able to build something at least as powerful as current select API
22:34:15 <taylor> EB: Don' think we should have to do this
22:34:24 <taylor> Domenic: You should be able to build anything with the imperative API
22:34:39 <dglazkov> q+
22:34:40 <taylor> CMN: Agree with Domenic. You may decide it's a bad idea, but it is useful to be able to show you can.
22:35:03 <taylor> CMN: Wondering if we have "champions" in the room?
22:35:09 <taylor> RN: Yes?
22:35:16 <taylor> CMN: I nominate you.
22:35:47 <taylor> RN: [with understanding] Yes
22:36:02 <taylor> EB: Would be happy to be involved in this from a framework author perspective
22:36:10 <chaals> ack dg
22:36:45 <taylor> DG: Need to be working with RN on this - represent strongest opinions from Polymer and existing experiences
22:36:56 <taylor> DG: [Dimitri is singing]
22:37:10 <taylor> CMN: [also singing]
22:37:18 <taylor> AR: Hard to call a new low
22:37:37 <taylor> DG: Want to ask: "what is the timeline of this"
22:37:48 <taylor> DG: Would like to figure this out stat. Should we put a deadline on this?
22:37:58 <taylor> consensus: yes
22:39:07 <taylor> RN: Busy for the next few months
22:39:34 <taylor> MJS: Can carve out time, and DG and EB offered to help
22:40:03 <taylor> EB: Would graciously request that Safari time provide some time for this, given Safari stated that this was a blocker
22:40:30 <taylor> RN: Beginning of July
22:40:40 <taylor> EB: Beginning of July
22:41:08 <chaals> agenda?
22:41:26 <chaals> zakim, close item 4
22:41:26 <Zakim> agendum 4, Jan…'s proposal for named thingo, closed
22:41:27 <Zakim> I see 2 items remaining on the agenda; the next one is
22:41:27 <Zakim> 6. details of imperative distribution API, don't make it impossible. [from chaals]
22:41:30 <chaals> zakim, close item 6
22:41:30 <Zakim> agendum 6, details of imperative distribution API, don't make it impossible., closed
22:41:32 <Zakim> I see 1 item remaining on the agenda:
22:41:32 <Zakim> 8. styling [from chaals]
22:44:12 <wilsonpage> wilsonpage has joined #webapps
22:46:34 <jsbell> jsbell has joined #webapps
22:58:00 <mjs> mjs has joined #webapps
22:58:43 <taylor> [back]
22:59:49 <jan> jan has joined #webapps
23:00:09 <taylor> DG: Next topic is Style
23:00:24 <taylor> AvK: Really need Tab here for some of this
23:00:34 <taylor> AvK: Let's discuss replacement for /deep/
23:00:50 <sorvell> sorvell has joined #webapps
23:01:02 <sorvell> sorvell has joined #webapps
23:01:28 <taylor> SO: Can speak to /deep/ and ::shadow
23:01:41 <taylor> SO: "part" failed - key reason was we couldn't figure out how to target it beyond one level
23:01:53 <taylor> SO: Had to match an element and do part
23:02:12 <taylor> SO: "Up the tree" = nested shadow roots
23:02:56 <taylor> SO: Want a way to turn on CSS - some way to expose styling up the tree to be able to do theming in my complicated structure
23:03:14 <taylor> SO: deep and shadow were bad. leaky of implementation details. bad perf. brittle.
23:03:25 <taylor> SO: Best fit that we think we have right now for cross-scope styling is custom properties
23:03:35 <taylor> SO: They inherit. Inheritance doesn't stop a shadow root boundaries
23:03:47 <taylor> SO: Anywhere down the tree you can intercept this and set it to something different
23:03:57 <taylor> SO: Custom properties are implemented only in FF
23:04:05 <taylor> SO: Practically they can only implement one value in CSS
23:04:28 <taylor> SO: Would need X custom properties for all of the properties an element might want to expose
23:04:44 <taylor> SO: We think custom properties should be implemented, and augmented with "mixin" property
23:04:56 <taylor> SO: This way you can pass down a bag of properties down the tree
23:05:05 <taylor> SO: We think this is the right direction for the browser to go
23:05:08 <ebryn> q+
23:05:11 <mjs> q+
23:05:47 <taylor> AvK: Is it problematic that these are global variables?
23:06:05 <admin> admin has joined #webapps
23:06:10 <taylor> SO: The Scope author has full control over their scope, can remap variables, reset values in my scope
23:06:47 <Domenic_> I think it's this one: https://tabatkins.github.io/specs/css-extend-rule/
23:06:58 <taylor> SO: Could add more control with resetStyleInheritance flag or similar
23:07:31 <ebryn> :root { —myColor: #ccc; }
23:07:55 <ebryn> i think cssnext’s playground does a good job: https://cssnext.github.io/cssnext-playground/
23:08:04 <LJWatson> LJWatson has joined #webapps
23:08:07 <chaals> s/[back]/Topic: Styling
23:08:07 <mjs> q+ to ask why custom properties instead of named parts
23:08:12 <taylor> SO: You document your style API. You have to do this with any proposal.
23:08:22 <rniwa> +q
23:08:29 <taylor> AvK: so if inner tree doesn't want to expose anything, it doesn't have to?
23:08:30 <chaals> ack eb
23:08:31 <taylor> SO: Correct
23:08:44 <taylor> EB: Recently became familiar with this proposal
23:08:51 <taylor> EB: Extremely excited with this proposal.
23:09:04 <taylor> EB: Began implementing a theming engine based on this proposal
23:09:15 <taylor> EB: Hadn't heard of mixin concept - interested in this as well
23:09:19 <hober> q+
23:09:32 <Domenic_> I can present an example of @extend usage
23:09:32 <taylor> EB: This is the solution. I've heard a lot of people complain about the problem of overriding style information in shadow roots.
23:09:40 <Domenic_> I figured out how to use it for the multiple properties thing
23:09:44 <Domenic_> I guess I can just type it here
23:09:54 <taylor> EB: This seems like a very elegant side-channel for propagating this information throughout the component hierarchies
23:10:01 <justin> https://github.com/Polymer/polymer/blob/0.8-preview/PRIMER.md#xscope-styling
23:10:12 <chaals> ack mj
23:10:12 <Zakim> mjs, you wanted to ask why custom properties instead of named parts
23:10:27 <Domenic_>  /* in shadow DOM */ <style> #internal-piece { @extend %my-component-internal-piece; }</style> <div id="internal-piece">...</div>
23:10:30 <taylor> MJS: Why custom properties instead of named parts?
23:10:54 <Domenic_>  /* outside shadow DOM */ %my-component-internal-piece { color: blue; opacity: 0.5; }
23:11:03 <taylor> MJS: Seems more natural to say this-element:toolbar { color: red; }
23:11:12 <taylor> MJS: Then you're not making aliased clones of style properties
23:11:22 <taylor> SO: That's another way to go. From our perspective, it's really close.
23:11:32 <taylor> SO: The huge advantage is now we don't have this huge interaction with the selector engine
23:11:42 <chaals> ack rn
23:11:47 <ebryn> +eb
23:11:49 <ebryn> +q
23:11:50 <taylor> SO: Inheritance is a totally different model that fits better
23:11:50 <justin> q+
23:13:00 <hober> q-
23:13:05 <chaals> q+ domenic
23:13:40 <taylor> RN: How do you specify specific values for a specific custom element that you match with a selector?
23:14:07 <taylor> SO: The basic answer is "You don't exactly" because doing so is selector matching, and we're not using selectors
23:14:14 <taylor> SO: If you have a button, and the button exposes a "button theme"
23:14:29 <taylor> SO: But in your scope you have a specific set of buttons, you have to expose each one as a different name
23:14:43 <taylor> SO: Advantage: we don't have to use complexity of style selector engine, and you don't expose details of the structure
23:15:09 <taylor> RN: How does a component author know what kind of types of buttons you may end up using?
23:15:22 <taylor> SO: Button just needs to expose a way of styling it
23:15:32 <taylor> SO: It's the user of the button that has to style the buttons individually
23:16:02 <chaals> ack ebry
23:16:03 <taylor> MJS: What if there are lots of properties that you want the same way?
23:16:11 <taylor> SO: You can set properties to other properties
23:16:36 <taylor> MJS: Problem: overloading the same property names. My plan is to automatically namespace these with the component's name.
23:16:42 <taylor> s/MJS/EB/
23:17:10 <taylor> EB: I'm enforcing this a the framework level rather than the spec level
23:17:15 <mjs> q+ to ask about var()
23:17:20 <taylor> SO: I'm imagining exactly the same thing
23:17:38 <taylor> SO: We haven't codified this yet in the system, but it's not a bad idea
23:17:42 <Domenic_> https://gist.github.com/domenic/56da9586bb1326a05edb
23:17:45 <mjs> q+ to ask about var() and how you update when your inherited style changes
23:18:02 <taylor> SO: The fact that at each scope you can decide what happens gives you enough hooks
23:18:16 <taylor> EB: Would like to bet heavily on this API. Need to see part proposal.
23:18:22 <mjs> Named Parts proposal: https://lists.w3.org/Archives/Public/www-style/2014Feb/0621.html
23:18:31 <chaals> ack ju
23:18:32 <taylor> EB: Would love to see consensus get built. See alignment with Polymer team on this.
23:18:52 <taylor> JF: What makes this more powerful than parts: don't need to invent blacklist
23:19:19 <taylor> JF: Can expose a property, the value of which I might map to multiple styling points, use in a calculation, etc.
23:19:35 <taylor> JF: You get this power over just parts
23:19:45 <taylor> EB: Is it just me or does the parts proposal align to the named slots concept?
23:19:57 <taylor> consensus: yes
23:20:11 <rniwa> q+
23:20:19 <taylor> EB: Seems clear to me I don't want my users to have to override CSS properties. Don't want them setting color and background color.
23:20:21 <chaals> q+ sam
23:20:29 <taylor> EB: Want to provide higher-level concepts than what CSS itself provides.
23:20:48 <mjs> Is this the actual spec for what people are talking about with custom properties and var()? http://dev.w3.org/csswg/css-variables/
23:20:58 <taylor> AvK: As long as CSS properties are granular enough, you can have a blacklist or whitelist for parts thing
23:21:02 <taylor> EB: I don't want granular
23:21:15 <taylor> SO: You cant have --secondary-color. We can invent that property and have it mean something
23:21:36 <LJWatson> q+ to say that there is an (edge) accessibility case for enabling users to override styles
23:21:39 <taylor> EB: My motivation: I want to be able to define the terminology and vocabulary that the user is using
23:22:07 <taylor> EB: I want my UI library to abstract away the granular, nitty-gritty details and expose them as something simple.
23:22:18 <taylor> EB: Not expose nitty gritty properties and have the user have to infer the API out
23:22:48 <taylor> CMN: So you want to be able to do something like expose the property "theme" and take that information and apply the component to where it ends up?
23:23:04 <hober> q+
23:23:19 <taylor> EB: More of like an implicit thing than an explicit thing. The documentation for your component will have all the attributes and properties that you element has.
23:23:40 <taylor> EB: It will also have a "themeable" section of the things that can be changed by the parent
23:23:43 <taylor> EB: Like a side-channel
23:24:02 <taylor> EB: Don't want to be verbose always - want nice global aspect of CSS without allowing people to globally muck with your styling logic.
23:24:12 <Travis> q+
23:24:19 <taylor> EB: You want people to muck with the styleable or themable properties of your element
23:24:28 <chaals> ack dom
23:24:55 <taylor> Domenic: Check out the gist
23:25:05 <taylor> https://gist.github.com/domenic/56da9586bb1326a05edb
23:25:44 <taylor> Domenic: Custom properties let you customize one thing at a time, mixins let you customize as many things as you want at one time
23:25:59 <taylor> WP: Does mixin api let you whitelist or blacklist properties?
23:26:03 <chaals> q?
23:26:08 <taylor> Domenic: Yes, you could override it.
23:26:10 <chaals> ack mj
23:26:10 <Zakim> mjs, you wanted to ask about var() and to ask about var() and how you update when your inherited style changes
23:26:15 <taylor> EB: Yes. Normal CSS rules apply.
23:26:34 <mjs>  http://dev.w3.org/csswg/css-variables/
23:26:41 <taylor> MJS: I was confused about which part of this proposal is a request for UA to implement things vs. framework implementation
23:27:10 <chaals> s|http://dev.w3.org/csswg/css-variables/|-> http://dev.w3.org/csswg/css-variables/ the custom properties spec…|
23:27:41 <wilsonpage> q+
23:27:49 <wilsonpage> q-
23:27:59 <taylor> MJS: As presented, this thing has similarly equivalent power to named parts
23:28:14 <taylor> MJS: But to do a whitelist of certain properties you need to invent a variable for each thing on your whitelist
23:28:44 <taylor> MJS: With parts people can just use the direct style property
23:28:48 <ebryn> +q
23:28:49 <chaals> q?
23:29:00 <justin> q+
23:29:31 <taylor> SO: We have psuedos for like range - is there a whitelist for that?
23:29:54 <chaals> ack rn
23:29:55 <rniwa> q-
23:29:58 <taylor> MJS: When we allow psudoes for styling parts of elements they can only accept certain properties
23:30:06 <taylor> s/psudoes/psuedos/
23:30:14 <chaals> ack sam
23:30:19 <chaals> q+ ejb
23:30:55 <chaals> q- ejb
23:30:58 <chaals> q+ ebryn
23:31:03 <taylor> SW: Seems like this has a lot of nice properties
23:31:08 <taylor> SW: The ability to take only a part of a thing
23:31:17 <taylor> SW: Seems like there's a nicer abstraction that's available here
23:31:44 <taylor> SW: 2 things you might want to do: a particular property or part of a property is something that you want to change property, or something you might only want the embedder of me to change
23:32:05 <taylor> SW: Have you run in to places where you want the author to be more or less restrictive
23:32:18 <taylor> EB: The second argument to var is a good fallback mechanism to globals
23:32:29 <taylor> EB: var lets you provide the fallback
23:32:43 <taylor> EB: There is potentially some other stuff to be explored - conventional naming mechanisms
23:33:05 <taylor> EB: Perhaps a framework idea: If you name your custom properties in a mechanism --color, perhaps you can assume that they meant to set the color property
23:33:20 <Domenic_> Could we allow color: var(color)?
23:33:24 <taylor> EB: Might have some nice naming conventions for how you can override things so that the user doesn't have to learn what the unique name was
23:33:47 <taylor> EB: That coupled with automatic namespacing with custom element could be the convention to override a specific property
23:33:55 <chaals> ack LJ
23:33:55 <Zakim> LJWatson, you wanted to say that there is an (edge) accessibility case for enabling users to override styles
23:34:00 <ebryn> q-
23:34:11 <Travis> Travis has joined #webapps
23:34:21 <taylor> LJW: Edge case from a11y point of view - when people with low vision want to override styles of a website
23:34:43 <taylor> LJW: How did these proposals let us handle things like keyboard focus visibility, where at the global level it is controlled but needs to move inside component?
23:34:58 <aboxhall> q+ to ask about separation of presentation and behaviour
23:35:12 <hober> q-
23:35:30 <taylor> LJW: You want to be clear where your keyboard focus is. Typically global. Could it be matched up so that keyboard focus could be consistent everywhere?
23:35:33 <mjs> q+ to comment on focus
23:35:42 <taylor> CMN: Perhaps a bad idea would be to whitelist focus
23:35:59 <taylor> MJS: No obviously good way to do it with inheritance model
23:36:15 <taylor> MJS: Plausibly you could imagine with part selector and focus selector you could style particular focus part
23:36:42 <taylor> SO: Using custom properties, at the point you consume the property you would match it against :focus
23:37:00 <taylor> SO: This is not as practical for high-contrast
23:37:17 <taylor> MJS: So if you wanted :hover :focus ... etc. you'd have to invent separate properties for each one?
23:37:25 <taylor> JF: You can apply a whole mixin of properties
23:37:41 <hober> q?
23:37:56 <hober> q+
23:37:58 <mjs> q-
23:38:11 <weinig> weinig has joined #webapps
23:38:26 <taylor> AvK: If it's a useragent thing you could override it
23:38:30 <Travis> q-
23:38:51 <taylor> CMN: Note: We need to figure out these things for a11y
23:39:14 <taylor> SW: What is the new thing in Shadow DOM that raises a problem?
23:39:30 <taylor> CMN: You might be right, it might not be a new problem.
23:40:13 <chaals> ack ju
23:40:18 <chaals> ack abox
23:40:18 <Zakim> aboxhall, you wanted to ask about separation of presentation and behaviour
23:40:37 <taylor> AB: One thing that concerns me is separation of presentation and behavior. Make sure we're keeping this in mind. Whether it shakes out as a best practice pattern.
23:40:50 <taylor> AB: People keep reimplementing button because they can't style it the way they want
23:41:03 <taylor> AB: Make sure we have this on our radar - that we can separate behavior and styling with custom elements
23:41:44 <chaals> ack hob
23:41:53 <taylor> AvK: Domenic is working on this - reimplementing HTML as custom elements
23:42:21 <taylor> EO: CSS variables seems like a good fit for styling focus
23:42:38 <rniwa> q+
23:42:43 <taylor> EO: Would be a mistake to think that CSS mixins are anything beyond a blog post, but variables are very far along
23:42:49 <taylor> EO: Happy to communicate that we want them
23:42:59 <sorvell> q+
23:43:32 <taylor> EO: How are these features helping us explain the platform: multiple shadow root issue with part proposal is a real one. With multiple form controls we have parts, and a way to take bundle of properties without CSS mixins.
23:44:28 <taylor> RN: One problem I can see is if we want isolated components, you can see any variables in original document inside component. We need a mechanism to either whitelist or expose a list of properties you're listening to, and page needs a way to expose a list of components you want to be able to use variables
23:44:40 <chaals> ack rn
23:44:44 <chaals> ack so
23:45:15 <taylor> SO: We feel like we needed shadow piercing because we were blocked on needing to do themeing. We feel unblocked now
23:45:30 <taylor> SO: We don't know how to do isolated scope themeing, but we don't have isolated scopes yet.
23:45:51 <taylor> SO: We have enough capability now to polyfill or shim additional features around it, which can inform v2
23:46:09 <taylor> RN: Can someone write up concrete proposal and set it to mailing list?
23:46:22 <rniwa> s/set/send/
23:46:42 <taylor> Domenic: Summarize: don't think there's much of a proposal other than "here's what we already have, and how we could use them"
23:46:55 <taylor> Domenic: We have a solution for blacklisting, we don't yet have one for whitelisting
23:47:15 <taylor> Domenic: Unresolved issue around non-standard elements in form controls. Do we want to standardize them, or move towards a model where there are standard custom properties
23:47:26 <hober> q?
23:47:53 <taylor> DG: Want to make sure that there's nobody who feels that parts and custom properties proposals are conflicting with eachother
23:48:07 <taylor> MJS: Seems like you could implement both
23:48:18 <taylor> MJS: For isolated mode you probably don't want styles inheriting
23:48:46 <taylor> Domenic: Don't think this is a foregone conclusion - seems reasonable that you might want --slider-thumb-color with the browser
23:49:02 <taylor> MJS: Probably don't want it to inherit arbitrarily predefined properties
23:49:52 <rniwa> q+
23:50:23 <taylor> MJS: Lets say you have secure login component with image for the user to see. Inherit css in that causes it to be hidden.
23:50:46 <taylor> Domenic: Only happens if the component specifically exposes this
23:50:52 <taylor> JS: You inherit only inheritable properties
23:50:59 <taylor> s/JS/JF/
23:51:30 <taylor> SO: inheritance breaks through inheritable properties
23:51:40 <taylor> Domenic: Set of inheritable properties should only be custom properties?
23:52:00 <taylor> RN: If you had a component that respects --property-one
23:52:09 <taylor> RN: Then you add --property-2 to another componnet
23:52:14 <chaals> ack rn
23:52:16 <taylor> s/componnet/component
23:52:33 <taylor> RN: But then the first component author could change the component to use --property-1
23:52:59 <taylor> JF: Conventions around namespacing will be important here. Is it just a semantic property, or are you targeting a specific CSS property on a set of components?
23:53:12 <taylor> JF: Sometimes you want these collisions - you want different themes to share --primary-color
23:53:18 <taylor> JF: Yet to be determines how people do this
23:53:42 <taylor> DG: Really productive meeting!!
23:53:45 <taylor> [applause]
23:53:48 <Domenic_> http://dev.w3.org/csswg/css2/propidx.html has all the properties as of 2.1...
23:54:01 <Domenic_> azimuth is inherited woo
23:54:11 <taylor> DG: Much smaller set of contentious problems - some concrete work items
23:55:38 <taylor> DG: Resolutions:
23:55:44 <taylor> DG: Multiple shadow root - remove
23:56:09 <taylor> DG: Open-closed: Default value - explicitly declared, both open and closed in v1
23:56:21 <taylor> DG: EB and RN will drive proposal for imperative API
23:56:49 <taylor> DG: Event retargeting - swapping out path and the new deepPath
23:57:01 <taylor> DG: Shadow boundary piercing combinators are gone
23:57:14 <taylor> DG: Slot proposal blocked on imperative API resolution
23:58:36 <taylor> DG: Lots of cool ideas on styling, don't see any big problems.
23:58:49 <taylor> EO: Don't see any problems here with custom properties
23:59:00 <taylor> DG: Need action item to talk about :host
23:59:18 <taylor> DG: :host is ability for you as a component to style yourself from the inside