See also: IRC log
<hober> could a googler come collect sam, maciej, & me? we're in the 1875 lobby
<scribe> scribe: chaals
<MikeSmith> Present?
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 angluar.js
OP: Smaug from mozilla
WC: William Chen, firefox
EO: Ted OConnor, Apple
HI: Hayato Ito, work on shadow dom for google and spec it
Justin: Work on polymer
AvK: Anne, work for moz on standards
SW: Sam Weinig, Apple
MS: Mike™ Smith, W3C
LJW: Léonie Watson, Paciello Group.
<annevk> CMN: Chaals, Yandex
CMN: Chaals from Yandex
AE: Arron Eicholz, MS - work on webapps
TL: Travis Leithead - the MS guy
EB: Eric Bryn
<ebryn> *Erik ;)
MG: Mark Giffin, writing web components docs for MDN
WP: Wilson Paige, working with WC on firfox OS
Jan: Founder of compnentn kitchen
<wilsonpage> *wilsonpage
MJS: Maciej, webkit at Apple
<wilsonpage> * waves *
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: Plymer 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
… 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
<rniwa> could someone add a link to the minutes on https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting ?
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.
… 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
… 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
… 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?
… 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.
<rniwa> +q
… 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?
… 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
… 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> ?
… 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.
<sorvell> +q
EB: I think there will be people who want queryselector to poke into shadow roots.
… right or wrong.
<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.
<misko> +q Angular’s point of view
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...
<misko> +q
… 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"
… 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
… 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
… 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.
… 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
… this is good for naive users, you don't want them poking in but, but if you want global reasoning don't use .shadowRoot.
<rniwa> +q
<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
… 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.
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.
… 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
… 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
… 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
… either sperate style isolation from shadow DOM, or make open mode more open
… so people can select through shadows.
<justin> what frameks?
… 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
… 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?
… 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
<taylor> RESOLUTION: Yes on closed and open in v1
<taylor> DG: Default?
<taylor> AR: On the minutes that I object to required, no default
<taylor> RESOLUTION: You have to make a choice
<taylor> RESOLUTION: Clarified: no default, required to decide open or closed
<taylor> DG: Retargeting
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Arron/Aaron/ Succeeded: s/??/Orvell/ Succeeded: s/Savage/Taylor Savage/ Succeeded: s/Russel/Russell/ Succeeded: s/??/"named slots"/ Succeeded: s/Muktiple/Multiple/ Succeeded: s/want/want for event retargetting)/ Succeeded: s/shadow element/shadow pseudo element/ Succeeded: i/DG: Lots of people here/Topic: Introductions Succeeded: s/@@/leakage using seperate script environment/ Succeeded: s/outline/outlined/ Succeeded: s/virtual elements/built-in elements/ Succeeded: s/amber.js/ember.js/ Succeeded: s/@@@/scott/ Succeeded: s/shoo/choo/ Succeeded: s/not as insane as it sounds/a useful thing. I don't care about the default thing./ Succeeded: i/DG: Retarg/Topic: Event retargetting Found Scribe: chaals Inferring ScribeNick: chaals Present: Chaals Léonie Mike™ AnnevK Aaron Travis Hayato Smaug DGlazkov CWilso AlexR SamW Maciej TedOC Domenic Travis_Leithead Agenda: https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting Got date from IRC log name: 24 Apr 2015 Guessing minutes URL: http://www.w3.org/2015/04/24-webapps-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]