See also: IRC log
DG: Lots of people here... that's good.
... goal of the meeting is to make sure we move Web Components closer to being interoperable standard (actually shipped...)
... There are some contentious bits on Shadow DOM, and we aim to resolve that here.
... We need to determine what goes into v1 that we can all live with and ship - and put the rest into a v2
... I would like to leave here not just feeling happy, but actually going to do work and knowing what it will be.
... would like to have champions for the things that we have to do still.
... The goal is to get browsers implementing, but we need experts from the rest of the ecosystem to tell us about their experience too.
CW: Chris Wilson - mostly here to find the tea... (Googler)
RN: Ryosuke Niwa, Apple
AB: Alice Boxhall, Google accessibility - chrome
Misko: work on angular.js
OP: Smaug from mozilla
WC: William Chen, firefox
EO: Ted O'Connor, Apple
HI: Hayato Ito, work on shadow dom for google and spec it
Justin: Work on polymer
AvK: Anne, work for Mozilla on standards
SW: Sam Weinig, Apple
MS: Mike™ Smith, W3C
LJW: Léonie Watson, Paciello Group.
CMN: Chaals from Yandex
AE: Arron Eichols, MS - work on webapps
TL: Travis Leithead - the MS guy
EB: Erik Bryn
MG: Mark Giffin, writing web components docs for MDN
WP: Wilson Page, working with Web Components on firefox OS
Jan: Founder of component kitchen
MJS: Maciej, webkit at Apple
AR: Alex Russell, googler on web platform
AK: Adam Klein, V8 at google
SM: Scott Miles, work on polymer team
TS: Taylor Savage, google
SA: Steve Orvell google
[polymer team people listening on the phone - we don't let them speak]
<dfreedm> here in irc as well
DG: Most vendors aside from Google have explained their current position...
... would like to figure out how important contentions are - blocker, useful to have, v1 or v2 or...
<misko> https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits
-> https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits The collected points of disagreement...
MJS: Apple thinks this should be removed and replaced with something like the "named slots" proposal. Strongly think this is the case for v1 - better to replace it with something useful or subclassing won't be useful.
... there is a time trade off to replacing it
AvK: Mozilla probably don't care strongly for v1 - we would like some solution, and the Apple thing might (or not) work for us...
DG: So there is an alternative, which is not the same as "let's drop what we have"
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.
DG: This has been a big sticking point for the shadow dom spec. I was the one arguing for it.
... I think most usage isn't that good, so I am OK with removing it.
... 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.
RESOLUTION: Remove multiple shadow roots
Justin: Want to make sure removal is seperate from what replaces it...
HI: SHuld we have a replacement in v1 or wait until v2?
DG: I would be OK with no replacement in v1
AvK: Agreed, might even be better than way
DG: Polymer team walked away from this already?
SM: Conceptually yes (haven't implemented that but will)
... agree that simplifying this is the right thing, and removing it won't affect polymer.
<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
MJS: The closed flag got added recently - Yay! But behaviour not fully defined yet.
... 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
... most importantly closed mode is a good block for making totally isolated components
... people felt the medium level is not useful, but to build a full solution this is necessary.
AvK: more important discussion is semantics of closed...
AR: Disagree, which is important but we need the discussion. degree of difficulty to make a real closed mode is very high.
OP: Moz' opinion is we agree with Apple.
... maybe v3 for proper isolation mode.
RESOLUTION: There will be a v4
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.
... not sure what that means for how events and styles go across the boundaries. Think we need a closed + isolated model definitely.
... not sure we need that and a simple closed model.
... 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.
DG: Agree on closed not isolated being needed.
... our preference is open by default, We want to do isolated in v2 or v3.
... we can live with closed by default if that's the general consensus
TL: v1 needs a way to consume the flag or remove it.
MJS: We still like this - for complex stuff declarative is going to be pretty tricky.
... not necessary for v1. Would like something either like this or named slot proposal - at very least we don't want @@
AvK: Agree
TL: Agree. API can wait for v2
DG: Agreed...
RESOLUTION: Make sure we can do it - v1 if we get there or v2
RN: Don't want to add something that won't work out...
MJS: Apple wants seperation. Not that strong feelings about default, might be plausible to have retargeting in closed mode, not in open, as default
... choice should be addressed, maybe possible to hang this on closed/open, maybe not needed.
... we probably need to offer the choice in v1. If both exist we should decide which will be the default now.
AvK: There should be an option, should probably be tied to closed/open - seems simplest and intuitive
... definitely v1
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.
... otherwise events poke a hole in that.
AvK: only if you have prototypes
TL: Something like it should be the default for any closed stuff.
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.
AvK: There have been requests for it, eg for Ember wanting to reason about state in global app logic
DG: eventpath gives you this information already
AvK: Mumble mumble...
DG: If others want this we can live with that.
... But we do want open and event retargetting not to be coupled.
EOC: You're fine with closed and retaregetting?
DG: Think it is impossible not to do that.
AR: Think that comes to the question of what closed really means, part of the semantics discussion.
MJS: Bare minimum is they must not work in closed mode
... 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.
AvK: Postpone piercing to v2
... would like to discuss styling the reprojected nodes and host
... would like to discuss this, but feel we haven't got something good on the table
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
... think we can get away without this for v1 - there are some nice ugly hacks to do the job if necessary
DG: We think it was a mistake and we want to get rid of it.
... see research link in wiki page
<jan> Cheat sheat of browser vendor positions on contentious bits: https://docs.google.com/spreadsheets/d/1hnCoaJTXkfSSHD5spISJ76nqbDcOVNMamgByiz3QWLA/edit#gid=0
DG: turned out to be a big footgun
... definitely want to get this out of v1. Want a better styling model, so far it is still not satisfying...
[Jan's summary doc shown]
RESOLUTION: remove shadow piercing combinator
HI: We have a shadow pseudo element one level of the piercing combinator. Should we remove that too?
<MikeSmith> Cheat sheet of browser vendor positions on contentious bits
RESOLUTION: Yes.
AvK: We want some kind of event retargetting, right.
DG: Pending discussion...
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 for event retargetting)...)
<MikeSmith> botie, inform rniwa https://www.w3.org/wiki/index.php?title=Webapps/WebComponentsApril2015Meeting#Minutes
<botie> will do
Preesnt+ HayatoIto, Rysouke, JanMiskovsky
<botie> rniwa, at 2015-04-24 17:18 UTC, MikeSmith said: https://www.w3.org/wiki/index.php?title=Webapps/WebComponentsApril2015Meeting#Minutes
AvK: So we have open, closed and isolated.
... 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...
TL: So the cfreator can grant access that they have?
AvK: Other scripts can prototype objecst, and if other things use those modified prototypes that's OK
... 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.
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.
scribe: once dispatch is finished path would return nothing (empty list)
... is there anything else in there? Just events, right?
[Styling]
AvK: That's awhole can of worms seperate.
@@: Simple inheritance?
AvK; Can we agree on this? Travis wanted something else.
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?
... does it preserve natural constraint hierarchy of CSS
AvK: Not sure about the question...
AR: Easier ones - do we have a list of who wants this and why?
AvK: We had one...
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
Justing: Why closed but not isolated?
AR: Acknowledge the uses are real but don't understand them yet.
<hober> From June 2011, mjs' 5 kinds of encapsulation: https://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html
MJS: largley agree with AvK's operational definition.
<hober> See "Why is encapsulation (type 2) important for components?" in that email
MJS: 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
<slightlyoff> I'd like to hear from framework authors on this
MJS: useful because 1. You can have a closed mode by rpeventing leakage using seperate script environment
... building block for eventual isolated mode
... 2. Environments don't generally let you poe holes - it is a use case for specialised tools but should not be generally recommended.
<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?
MJS: you *should* be interacting with a closed component through defined interfaces not by poking into the shadow tree directly.
... Think I showed how yu can build a closed mode with handwavy details, that isolates things - this is a start.
HI: speccing closed mode in shaodw so it behaves like built-in 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.
<slightlyoff> this seems like a much taller hurdle than what Maciej just outlined; can one get the SD of a <video> via __proto__ swizzling?
Justin: value of closed but not isolated - idea that the current mode we have is wide open...
... 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.
... 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.
Justin: don';t understand the value of a sort-of closed, we are already not encouraging people to poke inside and mess with stuff.
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...
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"
<ebryn> sounds like he's making an argument for open by default?
Juatin: rationale to prevent people reaching in by accident has potential to shut off a lot of tools
<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
SamW: isn't that already a problem with iframes?
Justin: Yes, but they are less frequently used.
<slightlyoff> iframes are origin isolation primitives
<slightlyoff> they are "isolated"
<slightlyoff> they are not a reasonable proxy for this debate
Justin: we're talking about a world where pages may have a lot of components in them. Don't want pages with lots of iframes...
... making compnents like iframes would be bad.
<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
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.
... 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.
... so you can isolate custom element without needing shadow DOM.
<slightlyoff> where's the proposal
<slightlyoff> ?
TL: have a proposal for that I sent out early this morning
<Travis> Isolated components: https://github.com/w3c/webcomponents/wiki/Cross-Origin-Custom-Elements:-Concept-and-Proposal
<slightlyoff> thanks Travis
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.
... 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.
... 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.
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.
... first node in event path has to match target.
<Zakim> mjs, you wanted to add that another benefit of closed mode is better explaining the platform
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.
... 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
... not doing something different.
... 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
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.
... 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.
... 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.
EB: Been listening. from perspective of ember.js, I would recap this to say we are talking about changes in the programming model.
... global reasoning vs isolated reasoning. I heard open by default is the current programming model of the web - work in a global environment
Justin: that's not the basis for my argument.
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...
... 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.
... they will want to pierce shadows.
... 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
Justin: to reply. My point isn't that we should live in the wild west of global everything - components have scopes.
... but our default of open actually satisfies most goals - most stuff doesn't go inside the shadows so by default we already get scoping.
... to think closed by default I want to understand the rationale better.
... how does it add real value, since it doesn't isolate.
EB: I think there will be people who want queryselector to poke into shadow roots.
... right or wrong.
<misko> 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.
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...
Justin: how do all these monkey patch in a way they don't step all over each other?
... the esacpe hatch is tricky because people ahve to figure out how to cooperate.
AvK: Not sure how tools is an argument if we are going to do isolated
EOC: Open defends against accidental access - lower bar. Isolated is the high bar against everything.
<scribe> ... closed mode is meant to defend against "normal access"
UNKNOWN_SPEAKER: 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.
... debugging example is a weird one. Web inspectors have more priveliged access than the rest of the platform and that's a good thing.
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.
<ebryn> Sounds like we need to standardize privileged access APIs to build tooling
Justin: want to enable more expressivity for people who are not in prveliged contxts
<slightlyoff> hober; fyi: Google Feedback does not live in a privileded context; it's just JS on a page
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.
... it isn't a security model, but people do feel bad if they do that.
<ebryn> make it ._shadowRoot
<ebryn> YES
DD: maybe we should rename to _shadowRoot
... this isn't a security boundary, it's a marker that you're being hacky now.
... if you have a case for it, maybe you need it.
<wilsonpage> Localization is also relevant here. Nodes inside the shadow-root can need localized content provided by the document.
DD: think there is a precedent - so long as it isn't really easy to get across then we are in good shape.
SO: +1 to the underscore. To relate polymer user experience - poking insdie hasn't been a problem.
... it's clear that's naughtyish.
<wilsonpage> +1 to underscore
SO: this is good for naive users, you don't want them poking in but, but if you want global reasoning don't use .shadowRoot.
<ebryn> the problem is you still want things like custom elements and distribution
<ebryn> and to be able to globally reason
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.
<annevk> Are we talking about what the default be or having the option at all?
<ebryn> this is a bridge for existing devs to the new world
Misko: From application POV these should be open - debug it, etc.
... For reusable components, I would say the value of being able to debug far outwieghs the benefit of it being closed.
... 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.
DG: framework people, what do you prefer - open or closed?
Misko: We would prefer open, to allow debugging, that's huge
EB: Instance property or something?
Misko: In angualr you don't get the DOM for developing, but debugging you want to traverse everything.
<Travis> Turns out you can always `delete shadowRoot` to get closed model :)
<mjs> closed mode was about more than one property when we had shadow-piercing combinators
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.
... we do composition in light DOM. We would expose shadowRoot as something like element - a public API for the implementor.
... 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.
... getting into inheritance vs composition.
... 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.
... composing being the happy path...
... when debugging you will almost certainly expose the component.
scott: Polymer would make it open by default every time.
... this is an encapsualtion primitive - good citizens wouldn't see or use the naughtiness. Maybe we are wedged on the colour of the roof.
... you wouldn't see the things inside.
AR: First point, reinforce what scott said.
... 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.
... We noted frameworks had _stuff that people didn't mess with.
... 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.
... as framework authors, how end users think isn't that open means wide open
<Travis> +1 to slightlyoff
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.
mumbler: closed or isolated?
OP: Closed
EB: are they underscored?
OP: No
<Travis> "open" -> "obscured", "closed" -> "closed"?
EB: Then you lost the discuouragement effect...
<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
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?
<ebryn> Users don't read your docs or understand your philosophy
<ebryn> They read other people's code and cargo cult it
DG: Comparison is interesting and it is a good question.
... difference between CSS and DOM - DOM operations are ultimately malleable and user will get their way in the end.
... 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.
... 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.
... 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.
... data doesn't show the abuse of shadowRoot that we see for shadow piercing, despite the latter being around longer.
<Zakim> mjs, you wanted to mention default vs semantics
<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.
MJS: Think we started trying to decide what closed mode should be. Wandered into discussion of default.
... if we define it we need a default, but let's check in whether the semantics outlined are coherent enough to spec.
... another thing to think is how frameworks want an openness hook.
... there are a couple of levels. If we have both modes, and you can choose, then you can choose.
... what might matter more is if others make a different choice - would it be a problem if others choose closed when frameworks choose open?
... if it isn't, then maybe we don't worry so much, and we don't *need* to set a default.
... But are the semantics clear enough to spec?
... 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.
<scribe> ... closed mode would not support shadow piercing combinators because that would be a violation of the basics.
AvK: I wanted to say what Maciej said.
... I agree my proposal is a useful thing. I don't care about the default thing..
DD: We need a closed mode to explain HTML.
AvK: HTML is isloated.
DD: Wher closed is a subset of that it helps.
<justin> I'll direct it your way
<slightlyoff> +1 to Travis
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.
<slightlyoff> DOM is just a library for JS; treating it like some special case is creating a bug
TL: prefer complete isolation like HTML elements than having this halfway point.
<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
TL: if you want to make closed, delete your shadowRoot propoerty.
<ebryn> +1 to Travis
RN: If you want open mode you can just not use shadow DOM? I don't think that;'s viable for frameworks.
... there are frameworks that by default are open, and they don't want event retargetting, and want style isolation.
<wilsonpage> +1 Travis
<ebryn> +1 rniwa
RN: either sperate style isolation from shadow DOM, or make open mode more open
... so people can select through shadows.
<justin> what frameks?
RN: might need to discuss whether open model is the right openness
<slightlyoff> rniwa; can you talk about who wants this?
<ebryn> we should have a mechanism to utilize custom elements, <template>, and distribution points in a more open mode
AvK: Agree with Ryosuke.
<justin> I don't know of anyone asking for more open outside the "bootstrap problem"
<Travis> Zakim wants this discussion to continue.
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...
... we might want a mode where seletors operate on the compsed tree, so the boundary is only for compositoin, everything is global.
EB: We want that.
<Zakim> mjs, you wanted to discuss JS vs DOM
<ebryn> it's how we can migrate our users transparently to these primitives / shadow DOM
[straw poll: any consensus on a closed mode? apparently not...]
MJS: Travis said DOM and JS aren't separated...
... 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
<ebryn> I think the point that you can create closed mode at runtime by deleting the `_shadowRoot` property was a good point
MJS: 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
<Domenic_> Agree, but why do this in stages? Why not come up with a coherent proposal all at once?
MJS: you could imagine JS going away, and then isolated would not be relevant.
... so makes sense to start with closed then build isolated n that
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.
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.
... It is a poor choice to assume you must inherit everything we have today in the future.
RESOLUTION: We're not attempting to address the post-javascript web
AR: Not sure I understand a "more open open". Nor that there are people clamouring for it especially in v1
... people are using current shadowDom.
EB: Poeple are using open open mode, 1% who tried shadow DOM are not representative.
AR: Shadow came from an open open world, and we are trying to repair some of its worst excesses.
AvK: Open open lets people ease towards closed.
<taylor> DG: Ready to reach decision on open/closed and the default
<taylor> DG: We will have both closed and open mode in v1 - can you live?
<taylor> MJS: Yes
<taylor> TL: Good description: similar to what you get with javascript closures today.
<taylor> TL: I'm in. Yes
<taylor> DG: Yes
RESOLUTION: Yes on closed and open in v1
<taylor> DG: Default?
<taylor> AR: On the minutes that I object to required, no default
RESOLUTION: You have to make a choice
RESOLUTION: Clarified: no default, required to decide open or closed
<taylor> DG: Retargeting
<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
<taylor> SM: nervious about keeping the path name but having it return something different
<taylor> TL: Could we avoid adding a second path property before nailing the first one?
<taylor> DG: Event delegation is broken for composition
<taylor> ... Event delegation = instead of registering event listeners on elements, frameworks listen to everything and have their own event system managing that
<taylor> ... If path does not include the full composed tree, you can reason where the event came from
<taylor> AvK: We probably need another term that means open but not closed
<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
<taylor> TL: Why would we introduce something that doesn't take into account shadow DOM automatically?
<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.
<taylor> ... Assuming we get composed path, having path or not is not a question that has to do with web components
<taylor> RN: We don't want to expose the nodes in closed shadow dom?
<taylor> Consensus: No
<taylor> Consensus(clarified): We don't want to expose the nodes in closed roots
<taylor> DG: We can designate AvK to choose the name of this path
<taylor> AvK: I decide "deepPath"
<taylor> DG: Maybe we should designate a new person
<taylor> AvK: Event retargeting is an option in the open case, and defaults to retarget? A switch on the constructor
<taylor> JF: Don't know how it makes sense to not retarget on an open root
RESOLUTION: Event.path is local to shadow tree/document, Event.deepPath is what Event.path spec'd now.
[DomenicD shows three possibilities when you can retarget or not, and be open or closed - except we don't allow no retargetting on closed]
<taylor> AvK: Would be OK with not adding the switch
RESOLUTION: Event.deepPath does not include closed shadow trees
<taylor> SO: Any event delegation case should be solved by deepPath
RESOLUTION: Event retargeting happens
<dglazkov> Zakim: close item 7
<taylor> DG: Let's go on to slots
<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.
<taylor> ... Deals with way component author specifies content for distribution points
<taylor> ... Aesthetic argument: saw people using selectors in odd ways for this
<taylor> ... 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
<taylor> ... Makes subclassing easier - overriding by name
<taylor> ... Summary: rather than having select attribute on content element, would have an attribute that indicates the name for the insertion point..
<taylor> ... Component instances in the light DOM apply an attribute that designates the named insertion point that they want the element distributed to
<taylor> ... Elements in light dom without a name would end up in the default insertion point
<taylor> DG: Second part to the proposal - do you think we can discuss in separation?
<taylor> JM: Second part was to indicate desire to see subclassing expressed in the platform
<taylor> ... Want to achieve separation of concerns, and subclassing is a core feature for that
<taylor> ... We don't currently specify a way for a subclass to contribute to the base class's tree
<taylor> ... Seems possible that we might be able to tackle these pieces separately
<taylor> AvK: Would like to tackle separately
<taylor> ... Subclassing you propose includes modifying the existing shadow tree in place
<taylor> DG: Let's discuss slots on their own merit
<taylor> JF: Disagree with slot proposal.
<taylor> ... Important to optimize for end-user of custom elements
<taylor> ... Right now, developers of CE have choice in how they craft their "light children" API
<taylor> ... Can look at content slot mechanism as subset of select="[slot-name=...]"
<taylor> ... Giving authors this power lets them have some choice.
<taylor> ... We're envisioning a future where we have this marketplace of elements that compete on their merits
<taylor> ... Want to give element author the ability to craft a nice component API.
<taylor> SO: Hesitant about slot
<taylor> ... Clearly less expressive. Limited css selector vs. single attribute
<taylor> ... Not sufficient to explain the platform
<taylor> ... Predicated on idea that expressiveness is good. This could be democratically decided, rather than forcing it in the platform.
<taylor> ... Not a complete proposal. Would have to really strongly agree that explicitness is so important that we'd need to flesh it out
<taylor> ... Using select enables you to do reprojection with different selectors down the tree.
<taylor> Misko: In general, like the explicitness of it
<taylor> ... Enumerating them gives ability for tools to reason about it
<taylor> RN: We strongly believe that supporting a selector based distribution is wrong
<taylor> ... 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.
<taylor> RN: We strongly feel imperative API is important.
<taylor> HI: Every browsers has already implemented CSS selector. We can re-use it. If it evolves we can benefit from it.
<justin> the distribution timing isn't any different, is it?
<justin> I didn't see that as part of the proposal
<taylor> HI: It's very efficient. It's only distributing nodes. Don't have to traverse up or down node tree.
<taylor> ... Disabled support of psuedo-classes, and received lots of complaints from the community
<taylor> ... Afraid we will receive lots of complaints if we disable selector-based distribution
<taylor> TL: Support proposal with slots
<taylor> ... 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
<taylor> ... Have a much better contract with your component by explicitly naming a slot
<taylor> ... Would have to not have the select feature in an isolated model
<taylor> JF: Don't default slots challenge that? if you have default slot, you don't have to explicitly opt-in
<taylor> TL: Not familiar with default slot
<taylor> EB: Believe slots is the right approach
<taylor> ... Want to see death of selector-based programming. Only to be used in style.
<taylor> ... Considered imperative API a blocker. Seems clearer how to get here with sots approach.
<taylor> JM: Not excited about the idea at a late date to reopen something. Excited to see Shadow DOM adopted by all browsers.
<justin> We really need to work out how this proposal leads to imperative API, I don't see what it changes
<taylor> JM: History has shown that more flexibility is not always better
<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
<taylor> ... Would be elegant if you could include a slot name as a tag
<taylor> Domenic: Current HTML uses tag name
<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.
<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
<taylor> ... Liked Domenic's idea of using the element name instead, because it explains existing elements
ack (sc
<taylor> EB: But you can have more than one of the same CE's
<taylor> SM: Not a fan of slot.
<taylor> ... In response to explicitness: it's leaking implementation details of my component. Don't want you to know what you're using to insert.
<taylor> ... My element is simply a name, and I give you a contract in how to use it, but not how I achieve it
<taylor> ... Hard to decide in isolation "this is a vocabulary everyone should use"
<taylor> ... This is why democratization is important.
<taylor> ... That anything but slot blocks imperative API is a red herring
<taylor> ... That two patterns, classes or attributes, have emerged is not a bad thing
<taylor> ... People have different needs.
<taylor> JM: Why do you use both?
<taylor> SM: I don't presuppose that I want to dictate the answer for eternity - that's the point
<taylor> ... Would like to let users tell me if that is good or bad
<taylor> ... Want to see which one is best, not decide for the universe
<taylor> JF: Re: flexibility to craft your own api
<taylor> ... Analogy to named arguments of functions - slot is forcing that you have to use the named argument. Very restrictive.
<taylor> ... You can't look at current set of elements as exemplary of what all elements will look like.
<taylor> ... Class, attribute, tag name - that all are used demonstrates that people are using the full expressiveness of selectors
<taylor> ... 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.
<taylor> ... Can select on attribute values. "[section=...]"
<taylor> ... Compound and complex selections - can make API's that evolve in the future
<taylor> ... With slots, if you pick a name, but want to change that name later, you have to figure out multiple names
<taylor> ... Should think about elements as API's that can evolve in the future, and need to give them flexibility
<taylor> ... Don't see how the timing changes at all, or how it effects how to do imperative API.
<taylor> ... Still have to do style recalc
<taylor> ... We all want to see imperative API. Timing seems to be toughest part, not how you select nodes.
<taylor> DG: Going to stay away from aesthetics debate
<taylor> ... Don't believe we can in this century definitively declare that one is better than the other
<taylor> ... Instead, on timing and implementation details
<taylor> ... From spec perspective, this is a very minor change.
<taylor> ... You will still have the same issue - if you call offset-top you will need to know where it is distributed
<taylor> ... Because distribution is really fast you might be able to make it synchronous, but this will slow down dom operations. still have timing issue.
<taylor> ... This is purely an aesthetic debate
<Zakim> mjs, you wanted to talk about tag names
<taylor> DG: As aesthetic debate, we need to say "can you live with" and proceed from there
<taylor> MJS: Re: tag names as distribution hooks
<taylor> ... 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
<taylor> ... The choice of having your hook be an element name, class name, or attribute name - they all end up pointing to the same thing
<taylor> ... Ends up being a superficial choice
<taylor> WP: Arguments against are around lack of devs having expressiveness
<taylor> ... Could Polymer team live with imperative API?
<taylor> SO: If there's lack of expressiveness and imperative gives you the expresiveness, sure. But this seems to be a red herring.
<taylor> RN: Timing is still an issue. Need to decide when imperative API is used.
<taylor> ... 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
<taylor> ... In current model, any time anything changes, it's ambiguous if that node needs to be distributed
<taylor> MJS: Slots collapses choosing what gets distributed into a simple map
<taylor> ... If you add N things and each time need to recompute what gets distributed where, you get N^2
<taylor> DG: The way distribution spec is designed today, it's a tree walk. It's linear.
<taylor> MJW: Selector evaluation can't be reduced to a map lookup
<taylor> AR: These are simple selectors - you can't do descendent selectors.
<taylor> ... Slots and select are isomorphic to each other (in terms of big O)
<taylor> [Break]
<taylor> Back!
<taylor> DG: Following an exciting discussion on the slots proposal, we have a couple options
<taylor> ... 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?
<taylor> ... Which opens up the opportunity for very simple imperative API
<taylor> ... Options:
<taylor> ... 1. don't do imperative API in v1 and go with content select
<taylor> ... 2. Don't do imperative API and go with slots
<taylor> ... 3. Imperative API and one of the other proposals
<taylor> ... (imperative and declarative as part of v1)
<taylor> ... Needs to be time to fully put slots proposal through their paces and exercise it mentally
<ebryn> +1 to imperative API as part of v1
<taylor> DG: 4. We nominate people to do due diligence and bring it to a concrete proposal
<taylor> JM: Could do enough design work on imperative API that we have a good answer, but do it later
<taylor> DG: Should be a prerequisite for 1. or 2.
<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
<taylor> ... This will very synchronously require you to do this synchronously
<taylor> DG: Yes, this is correct
<taylor> SO: Want to emphasize that the slot proposal is incomplete. When you just have one name, this is unacceptable for reprojection
<taylor> ... Slot needs to be studied more and fleshed out
<taylor> RN: Qualify that imperative API is important
<taylor> ... Another option - no node distribution in v1
<taylor> ... Worst case scenario
<taylor> ... Timing of distribution is very important
<taylor> ... Maybe it is better to focus on imperative API. Then each framework could emulate either syntax to figure out best declarative syntax.
<taylor> CMN: is there anyone that would be happy without any distribution
<taylor> [basically everyone]
RESOLUTION: We need distribution of some sort in v1
<taylor> CMN: Is there anyone who can't live with starting at imperative API?
<taylor> ... Is there anyone opposed to starting out with an imperative API?
<taylor> [murmuring]
<taylor> CMN: Everyone wants an imperative API. Everyone wants distribution.
<taylor> ... Is there anyone that thinks they need to start by figuring out a declarative API? [nobody]
<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
<taylor> SO: We want this thing to ship.
<taylor> SO: We have a declarative API, we don't have an imperative API
<taylor> RN: Imperative API got shot down because it wasn't compatible with content select
<taylor> ... From imperative, we can start implementing
<taylor> ... We can have more evidence from there as to what the right declarative syntax is
<taylor> ... We need to start from things we can agree on
<taylor> CMN: Who cannot live with select api?
<taylor> ... Who cannot live with slots?
<taylor> [some for each]
<taylor> CMN: Need to come back after working on proposals
<taylor> CMN: For now, we're trying to see if we can get to imperative API
<taylor> CMN: So what does the imperative API look like again?
<taylor> SM: Curious if the people at the whiteboard could say if imperative API will nerf our performance?
<smaug> rniwa do you have a link to the old imperative API proposal
<taylor> RN: If API's that call back to JS any time any dom was modified in light dom, not acceptable
<taylor> ... If we did it at end of microtask, like MO, perf impact is much smaller
<taylor> AvK: The only observable thing is that synchronous layout getters don't work
<taylor> JF: Isn't breaking the habit on layout forcing habits a bandaid we need to rip off at some point?
<taylor> JF: Need to recognize that exploring this path might not be successful
<rniwa> my proposal for imperative API: https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0376.html
<taylor> Domenic: reportValidity, scrollIntoView - isn't it OK if we delay this a microtask
<taylor> DG: No, not ok. This is how developers have been using this.
<taylor> RN: Link to proposal: https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0376.html
<taylor> ... add and remove to content element (names can change), will take new element in a light dom that gets distributed to insertion point
<taylor> ... Just does exactly one time distribution
<taylor> ... You would use mutation observers to update distributed nodes
<taylor> ... Most primitive API could come up with
<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."
<taylor> RN: Drawback - you can't really reorder nodes inside insertion point
<taylor> ... Need array potentially to add and manipulate from arbitrary points
<taylor> ... Everything is synchronous
<taylor> AvK: Component author would write mutation observers, they'd have to wait for the MO's to fire before nodes get distributed again
<taylor> RN: Also lifecycle callback in CE about children being changed
<taylor> ... Maybe could update nodes when we exit C++ code of node being added
<taylor> DG: Reprojection would be done by hand
<taylor> MJS: What's tricky is timing
<taylor> ... Hard to tell in abstract whether next microtask is good enough, as opposed to current style resolution timing
[straw poll - how many people ok with this idea so far - more, how many terrified so far - some]
<taylor> MJS: Style resolution timing is imprecise too
<taylor> ... Might require someone to try implementing it to see if in practice it is bad
<taylor> DG: Sounds like a task force
<taylor> SO: If we have RN's proposal that distribution is synchronous, I would saymutation observerinformation is not sufficient to do reprojection
<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.
<taylor> SO: Would hope we could add information about distributed nodes changed to mutation observer
<taylor> ... We're opening up the door for: Polymer could create a flush mechanism; all the mutation observers take records
<taylor> ... not a good signal on way to do redistribution with the information that mutation observers surface currently
<taylor> AR: question of imperative-only seems at odds that there's a large simplification to be had with naming slots
<taylor> ... degrees of freedom continue to accelerate as you go toward imperative
<taylor> ... Could look at properties, for example
<taylor> ... Thinks we should definitely have imperative API's in the platform
[+1 to Alex' concern...]
<taylor> AR: Worries this will hurt inter-framework interoperability quite a lot
<ebryn> +1 to alex
<taylor> RN: Can add synchronous event or new record to mutation observer.
<taylor> SM: First version of Polymer had a lot of asynchronous behaviors - horrible for end-users
<taylor> ... Nervous about any change where the user doesn't know "can I talk to this node now?" will cause lots of user confusion
<taylor> ... Cautionary tale about asynchrony as it impacts end-users
<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.
<taylor> ... Want to see that it addresses all the use-cases that selectors do and perhaps more complicated things
<taylor> ... a childrenChanged callback would make it nicer, synchronousish
<taylor> ... Should be able to build something at least as powerful as current select API
<taylor> EB: Don' think we should have to do this
<taylor> Domenic: You should be able to build anything with the imperative API
<taylor> CMN: Agree with Domenic. You may decide it's a bad idea, but it is useful to be able to show you can.
<taylor> CMN: Wondering if we have "champions" in the room?
<taylor> RN: Yes?
<taylor> CMN: I nominate you.
<taylor> RN: [with understanding] Yes
<taylor> EB: Would be happy to be involved in this from a framework author perspective
<taylor> DG: Need to be working with RN on this - represent strongest opinions from Polymer and existing experiences
<taylor> DG: [Dimitri is singing]
<taylor> CMN: [also singing]
<taylor> AR: Hard to call a new low
<taylor> DG: Want to ask: "what is the timeline of this"
<taylor> ... Would like to figure this out stat. Should we put a deadline on this?
<taylor> consensus: yes
<taylor> RN: Busy for the next few months
<taylor> MJS: Can carve out time, and DG and EB offered to help
<taylor> EB: Would graciously request that Safari time provide some time for this, given Safari stated that this was a blocker
<taylor> RN: Beginning of July
<taylor> EB: Beginning of July
<taylor> DG: Next topic is Style
<taylor> AvK: Really need Tab here for some of this
<taylor> ... Let's discuss replacement for /deep/
<taylor> SO: Can speak to /deep/ and ::shadow
<taylor> ... "part" failed - key reason was we couldn't figure out how to target it beyond one level
<taylor> ... Had to match an element and do part
<taylor> ... "Up the tree" = nested shadow roots
<taylor> ... 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
<taylor> ... deep and shadow were bad. leaky of implementation details. bad perf. brittle.
<taylor> ... Best fit that we think we have right now for cross-scope styling is custom properties
<taylor> ... They inherit. Inheritance doesn't stop a shadow root boundaries
<taylor> ... Anywhere down the tree you can intercept this and set it to something different
<taylor> ... Custom properties are implemented only in FF
<taylor> ... Practically they can only implement one value in CSS
<taylor> ... Would need X custom properties for all of the properties an element might want to expose
<taylor> ... We think custom properties should be implemented, and augmented with "mixin" property
<taylor> ... This way you can pass down a bag of properties down the tree
<taylor> ... We think this is the right direction for the browser to go
<taylor> AvK: Is it problematic that these are global variables?
<taylor> SO: The Scope author has full control over their scope, can remap variables, reset values in my scope
<Domenic_> I think it's this one: https://tabatkins.github.io/specs/css-extend-rule/
<taylor> SO: Could add more control with resetStyleInheritance flag or similar
<ebryn> :root { —myColor: #ccc; }
<ebryn> i think cssnext's playground does a good job: https://cssnext.github.io/cssnext-playground/
<taylor> SO: You document your style API. You have to do this with any proposal.
<taylor> AvK: so if inner tree doesn't want to expose anything, it doesn't have to?
<taylor> SO: Correct
<taylor> EB: Recently became familiar with this proposal
<taylor> ... Extremely excited with this proposal.
<taylor> ... Began implementing a theming engine based on this proposal
<taylor> ... Hadn't heard of mixin concept - interested in this as well
<Domenic_> I can present an example of @extend usage
<taylor> EB: This is the solution. I've heard a lot of people complain about the problem of overriding style information in shadow roots.
<Domenic_> I figured out how to use it for the multiple properties thing
<Domenic_> I guess I can just type it here
<taylor> EB: This seems like a very elegant side-channel for propagating this information throughout the component hierarchies
<justin> https://github.com/Polymer/polymer/blob/0.8-preview/PRIMER.md#xscope-styling
<Zakim> mjs, you wanted to ask why custom properties instead of named parts
<Domenic_> /* in shadow DOM */ <style> #internal-piece { @extend %my-component-internal-piece; }</style> <div id="internal-piece">...</div>
<taylor> MJS: Why custom properties instead of named parts?
<Domenic_> /* outside shadow DOM */ %my-component-internal-piece { color: blue; opacity: 0.5; }
<taylor> MJS: Seems more natural to say this-element:toolbar { color: red; }
<taylor> ... Then you're not making aliased clones of style properties
<taylor> SO: That's another way to go. From our perspective, it's really close.
<taylor> ... The huge advantage is now we don't have this huge interaction with the selector engine
<taylor> SO: Inheritance is a totally different model that fits better
<taylor> RN: How do you specify specific values for a specific custom element that you match with a selector?
<taylor> SO: The basic answer is "You don't exactly" because doing so is selector matching, and we're not using selectors
<taylor> ... If you have a button, and the button exposes a "button theme"
<taylor> ... But in your scope you have a specific set of buttons, you have to expose each one as a different name
<taylor> ... Advantage: we don't have to use complexity of style selector engine, and you don't expose details of the structure
<taylor> RN: How does a component author know what kind of types of buttons you may end up using?
<taylor> SO: Button just needs to expose a way of styling it
<taylor> ... It's the user of the button that has to style the buttons individually
<taylor> MJS: What if there are lots of properties that you want the same way?
<taylor> SO: You can set properties to other properties
<taylor> EB: Problem: overloading the same property names. My plan is to automatically namespace these with the component's name.
<taylor> EB: I'm enforcing this a the framework level rather than the spec level
<taylor> ... I'm imagining exactly the same thing
<taylor> ... We haven't codified this yet in the system, but it's not a bad idea
<Domenic_> https://gist.github.com/domenic/56da9586bb1326a05edb
<taylor> ... The fact that at each scope you can decide what happens gives you enough hooks
<taylor> EB: Would like to bet heavily on this API. Need to see part proposal.
<mjs> Named Parts proposal: https://lists.w3.org/Archives/Public/www-style/2014Feb/0621.html
<taylor> ... Would love to see consensus get built. See alignment with Polymer team on this.
<taylor> JF: What makes this more powerful than parts: don't need to invent blacklist
<taylor> ... Can expose a property, the value of which I might map to multiple styling points, use in a calculation, etc.
<taylor> ... You get this power over just parts
<taylor> EB: Is it just me or does the parts proposal align to the named slots concept?
<taylor> consensus: yes
<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.
<taylor> EB: Want to provide higher-level concepts than what CSS itself provides.
<mjs> Is this the actual spec for what people are talking about with custom properties and var()? http://dev.w3.org/csswg/css-variables/
<taylor> AvK: As long as CSS properties are granular enough, you can have a blacklist or whitelist for parts thing
<taylor> EB: I don't want granular
<taylor> SO: You cant have --secondary-color. We can invent that property and have it mean something
<taylor> EB: My motivation: I want to be able to define the terminology and vocabulary that the user is using
<taylor> ... I want my UI library to abstract away the granular, nitty-gritty details and expose them as something simple.
<taylor> ... Not expose nitty gritty properties and have the user have to infer the API out
<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?
<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.
<taylor> ... It will also have a "themeable" section of the things that can be changed by the parent
<taylor> ... Like a side-channel
<taylor> ... Don't want to be verbose always - want nice global aspect of CSS without allowing people to globally muck with your styling logic.
<taylor> ... You want people to muck with the styleable or themable properties of your element
<taylor> Domenic: Check out the gist
<taylor> https://gist.github.com/domenic/56da9586bb1326a05edb
<taylor> ... Custom properties let you customize one thing at a time, mixins let you customize as many things as you want at one time
<taylor> WP: Does mixin api let you whitelist or blacklist properties?
<taylor> Domenic: Yes, you could override it.
<Zakim> mjs, you wanted to ask about var() and to ask about var() and how you update when your inherited style changes
<taylor> EB: Yes. Normal CSS rules apply.
<mjs> the custom properties spec
<taylor> MJS: I was confused about which part of this proposal is a request for UA to implement things vs. framework implementation
<taylor> ... As presented, this thing has similarly equivalent power to named parts
<taylor> ... But to do a whitelist of certain properties you need to invent a variable for each thing on your whitelist
<taylor> ... With parts people can just use the direct style property
<taylor> SO: We have psuedos for like range - is there a whitelist for that?
<taylor> MJS: When we allow psuedos for styling parts of elements they can only accept certain properties
<taylor> SW: Seems like this has a lot of nice properties
<taylor> ... The ability to take only a part of a thing
<taylor> ... Seems like there's a nicer abstraction that's available here
<taylor> ... 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
<taylor> ... Have you run in to places where you want the author to be more or less restrictive
<taylor> EB: The second argument to var is a good fallback mechanism to globals
<taylor> ... var lets you provide the fallback
<taylor> ... There is potentially some other stuff to be explored - conventional naming mechanisms
<taylor> ... 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
<Domenic_> Could we allow color: var(color)?
<taylor> ... 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
<taylor> ... That coupled with automatic namespacing with custom element could be the convention to override a specific property
<Zakim> LJWatson, you wanted to say that there is an (edge) accessibility case for enabling users to override styles
<taylor> LJW: Edge case from a11y point of view - when people with low vision want to override styles of a website
<taylor> ... 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?
<taylor> ... 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?
<taylor> CMN: Perhaps a simplistic idea would be to whitelist focus
<taylor> MJS: No obviously good way to do it with inheritance model
<taylor> ... Plausibly you could imagine with part selector and focus selector you could style particular focus part
<taylor> SO: Using custom properties, at the point you consume the property you would match it against :focus
<taylor> ... This is not as practical for high-contrast
<taylor> MJS: So if you wanted :hover :focus ... etc. you'd have to invent separate properties for each one?
<taylor> JF: You can apply a whole mixin of properties
<taylor> AvK: If it's a useragent thing you could override it
<taylor> CMN: Note: We need to figure out these things for a11y
<taylor> SW: What is the new thing in Shadow DOM that raises a problem?
<taylor> CMN: You might be right, it might not be a new problem.
<Zakim> aboxhall, you wanted to ask about separation of presentation and behaviour
<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.
<taylor> ... People keep reimplementing button because they can't style it the way they want
<taylor> ... Make sure we have this on our radar - that we can separate behavior and styling with custom elements
<taylor> AvK: Domenic is working on this - reimplementing HTML as custom elements
<taylor> EO: CSS variables seems like a good fit for styling focus
<taylor> EO: Would be a mistake to think that CSS mixins are anything beyond a blog post, but variables are very far along
<taylor> ... Happy to communicate that we want them
<taylor> ... 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.
<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
<taylor> SO: We feel like we needed shadow piercing because we were blocked on needing to do themeing. We feel unblocked now
<taylor> ... We don't know how to do isolated scope themeing, but we don't have isolated scopes yet.
<taylor> ... We have enough capability now to polyfill or shim additional features around it, which can inform v2
<taylor> RN: Can someone write up concrete proposal and send it to mailing list?
<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"
<taylor> ... We have a solution for blacklisting, we don't yet have one for whitelisting
<taylor> ... 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
<taylor> DG: Want to make sure that there's nobody who feels that parts and custom properties proposals are conflicting with eachother
<taylor> MJS: Seems like you could implement both
<taylor> ... For isolated mode you probably don't want styles inheriting
<taylor> Domenic: Don't think this is a foregone conclusion - seems reasonable that you might want --slider-thumb-color with the browser
<taylor> MJS: Probably don't want it to inherit arbitrarily predefined properties
<taylor> ... Lets say you have secure login component with image for the user to see. Inherit css in that causes it to be hidden.
<taylor> Domenic: Only happens if the component specifically exposes this
<taylor> JF: You inherit only inheritable properties
<taylor> SO: inheritance breaks through inheritable properties
<taylor> Domenic: Set of inheritable properties should only be custom properties?
<taylor> RN: If you had a component that respects --property-one
<taylor> ... Then you add --property-2 to another component
<taylor> ... But then the first component author could change the component to use --property-1
<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?
<taylor> ... Sometimes you want these collisions - you want different themes to share --primary-color
<taylor> ... Yet to be determines how people do this
<taylor> DG: Really productive meeting!!
<taylor> [applause]
<Domenic_> http://dev.w3.org/csswg/css2/propidx.html has all the properties as of 2.1...
<Domenic_> azimuth is inherited woo
<taylor> DG: Much smaller set of contentious problems - some concrete work items
<taylor> DG: Resolutions:
<taylor> ... Multiple shadow root - remove
<taylor> ... Open-closed: Default value - explicitly declared, both open and closed in v1
<taylor> ... EB and RN will drive proposal for imperative API
<taylor> ... Event retargeting - swapping out path and the new deepPath
<taylor> ... Shadow boundary piercing combinators are gone
<taylor> ... Slot proposal blocked on imperative API resolution
<taylor> ... Lots of cool ideas on styling, don't see any big problems.
<taylor> EO: Don't see any problems here with custom properties
<taylor> DG: Need action item to talk about :host
<taylor> ... :host is ability for you as a component to style yourself from the inside
<taylor> EB: Re; event path - if you're going to turn something on that isn't configurable, want confirmation that you have all the original information
<taylor> ... Simplest thing for my perspective is to include the original event object
<taylor> ... Would prefer non-mutated version of the original event object
<taylor> AR: Seems very sugar-y
<taylor> EB: Purely theoretical.
<taylor> AI(EB): Find out if this is a real problem.
<taylor> DG: Thanks everybody for coming!
<taylor> ... If you're not tired you're amazing
<taylor> ... Let's meet again some time.
<taylor> AvK: Meeting in July again might be good, if proposal is good
<taylor> DG: Let's plan for something. Good idea.
<taylor> ... Plan same thing for Custom Elements
<aklein> Also should plan some sort of Custom Elements thing
<taylor> Thanks everyone!
<taylor> -- Fin --
[Thanks to Taylor for scribing, Dmitry for getting this together, Chris for logistics...]