<inserted> scribe: esprehn
<inserted> scribenick: esprehn
esprehn: we think it's easy, without it authors do something really bad to emulate links
chaals: we could sit around and argue consensus, or we could write it up and see what people implement and want to rely on
rniwa: why would you put the link
element in a shadow dom since you can just querySelector
without the parser
... and the <head> problem doesn't apply
... in the case where in the main document you can
querySelector and define all instances of a link
esprehn: when do you upgrade the links in the page?
rniwa: I don't think you can
expect multiple libraries to coordinate
... you have to create your own shadow dom yourself, ... this
is the problem in the current api (as discussed 3 years ago) we
want to have the simplest apis to allow frameworks authors to
decide how they're used
... now you're saying without this API some frameworks have
issues
justin: we think without this there's issues
chaals: my experience is that the
use cases keep coming back and the browsers keep coming back
and saying they dont' want do it. One browser did it (chrome),
one said we think it's compelling (Edge), one said no
(Safari)
... sitting around and discussing if it'll fly is less useful
than going and just doing and writing a separate spec
... if people implement it then it's done, if the don't then it
isn't
... you can't force people to agree with you in a standards
meeting
hober: lets see what happens in implementations
jan_miksovsky: the question I
have is that a component's kids are just as important as its
attributes
... lots of components want to know when they have stuff
... how do components respond to this? is there a callback?
justin: polymer has "effective
children changed" for actual or projected children changed
(shadow dom concept)
... we had customers who needed to know this
rniwa: key question is direct children, or ones projected
hayato: yeah
jan_miksovsky: use cases we have us knowing final distribution changing, they want to know if there's a <slot> and what changes
rniwa: so it's a shadow dom question
esprehn: right since otherwise you can just use MO
rniwa: yeah so talking about any projected stuff is a shadow dom question
hayato: github issue about slotted change event, we think we should support it with a new MO type
rniwa: we need to have either an
event or a MO type
... annevk do you remember?
... want a new record for when a slot changes what's
distributed to it
Travis: is the timing nano or micro?
jan_miksovsky: I don't care, today there's nothing, it's hard and brittle to do today
<kochi2> the issue is: https://github.com/w3c/webcomponents/issues/288
Domenic_: yeah I think making a nicer MO api for this makes sense, with batching so insert/remove pairs don't spam
annevk: MO has childList, and you can do subtree too
Travis: can we use a selector?
rniwa: still expensive, I don't want to do that
jan_miksovsky: need something
like this to be robust
... I don't want something like this to get lost
annevk: can you clarify?
esprehn: this is for slot changing what's distributed
rniwa: you have a custom element with a kid that's a <slot>, slot doesn't generate a box by default, you want to look at the children including the slot to look at the final positions
jan_miksovsky: /does example of a
carousel on the whiteboard
... ex. <my-carousel> and you put <img> in there,
but you can also put <slot> in there, but the
<my-carousel> wants to see all the <img> that go to
the <slot>
... getEffectiveChildren in polymer handles this
rniwa: this doesn't seem like a
DOM concern
... seems more like a box tree concern
esprehn: no if you create a custom video element, you want the slotted <source> things to participate
jan_miksovsky: yeah this is author expectation
rniwa: you want to know when all slotted elements change, doesn't matter if they're invisible or what
Domenic_: isn't this just solved in polymer?
esprehn: at great expense
rniwa: I thought it was only
about boxes, but if you don't think about that and it's just
any of the children changed
... you just want to know when the list of nodes distributed to
a slot, or any child nodes
annevk: composed includes closed shadow trees?
justin: no, it doesn't matter
rniwa: doesn't matter, only see things outside the shadow
jan_miksovsky: I hear there should really be a mutation you observe the slot with, maybe a new flag for MO
annevk: maybe like the composed child list
justin: not really composed, just projected children of the slot have changed
rniwa: want to know when the
assigned nodes changed
... and deep tree as well, reuse the subtree flag
hayato: shouldn't be deep
rniwa: there's one level, which is know the assigned nodes to your slot, and also want to know if any of them, or any of them all the way down
justin: bike shed: maybe "tall" ?
*room laughs*
<chaals> scribe: chaals
esprehn: You're calculating the list already
rniwa: no
<Travis> esprehn and rniwa discuss implementation challenges of maintaining a list for the purposes of mutation observer.
justin: what if you get a simple list, and can ask for the expensive part if you need it.
Jan: just notify when the tree changed, and you can walk it
justin: needs to cover the case that something changed a few levels up in the slotting
esprehn: can you queue a record
that the slots changed and then getDistributedNodes ?
... then the user can call the getComp
rniwa: Yes
esprehn: Seems like we can do this, there is a compromise, need a bug on Mutation Observers
<dglazkov> s/getDistributedNodesuted/getDistributedNodes/
justin: OK that it is microtask timing not nano? There will be effective children that can only be observed at microtask level
dglazkov: microtask is OK
jan_miksovsky: So make a bug for a new mutation observer?
rniwa: Think there is already a GH issue
jan_miksovsky: would tell you the slot that changed, and then you can call getDistributed…
<rniwa> https://github.com/w3c/webcomponents/issues/288
^the relevant issue.
rniwa: someone should come up with a formal spec.
jan_miksovsky: happy to work with
someone to spec it.
... don't want to take the task myself.
<scribe> ACTION: jan_M to work with Hayato and spec this out [recorded in http://www.w3.org/2016/01/26-webapps-minutes.html#action01]
<trackbot> Error creating an ACTION: could not connect to Tracker. Please mail <sysreq@w3.org> with details about what happened.
jan_miksovsky: when do you know your children are done parsing?
[you probably don't know]
[in v1 at least]
rniwa: if you use Mutation Observer, by the time you get it all the children have been upgraded
esprehn: We do upgrading bottom-up in innerHTML
Avk: what if your custom elements load midway through parsing a big document?
esprehn: If the definition hasn't
appeared, you call a and then b you get all a then all b.
... in construction order
rniwa: That seems bad
... good to stick with top-down always
Domenic_: tend to agree
AvK: tree order doesn't catch things not in the tree
esprehn: that's why we keep a seperate list.
rniwa: why?
esprehn: consistent worldview.
AvK; You have createElement, then a custom element not inserted and then later you add it
rniwa: OK
[theWebIsABadWeb event]
rniwa: Think we should be consistent - keep creation order everywhere then.
esprehn: attach/detach are in tree order…
rniwa: you need to spec that way.
esprehn: polymer wanted upgrades
bottom-up so we did that instead.
... and now we ended up all creation order.
RESOLUTION: we remember why we have the spec the way it is.
Rationale: You can't make it work if you don't have creation order, and consistency is good.
<scribe> ACTION: domenic to document stack of queues and ordering [recorded in http://www.w3.org/2016/01/26-webapps-minutes.html#action02]
<trackbot> Error creating an ACTION: could not connect to Tracker. Please mail <sysreq@w3.org> with details about what happened.
<kochi2> #316
<kochi2> https://github.com/w3c/webcomponents/issues/316
Kochi: think this is a problem of
updating order of style comoing from different shadow
trees
... we agree prioriity of rules is tree of tree order of shadow
trees
... remaining point is bug 316 - how do we handle style
attributes
esprehn: Where in the order it
comes?
... didn't we agree with Tab on this?
LJW: at the last meeting
<rniwa> Two test cases: https://github.com/w3c/web-platform-tests/pull/2515
hober: No longer see any disagreement in the issue
[jan_miksovsky leaves]
Kochi in the webplatform tests I put some tests. I implemented to follow the option 2 in the github bug.
scribe: if everyone agrees on that approach, we are good.
<rniwa> Here's the test case: http://w3c-test.org/shadow-dom/styles/shadow-cascade-order.html
hayato: basically this means
current vs new implementation. Unless there is a strong
objection we should adopt option 2.
... if the test cases are unacceptable, please object.
rniwa: proposal is to do option
2?
... we pass everything except a slotted we don't implement
yet.
[taken offline]
Domenic_: Make them ES6. Awesome.
[But it was DMitri's idea]
esprehn: we want to drop style
justin: we want the scripts to run
Domenic_: not in the same doc
justin: There should be a registry
rniwa: not sure why mutliple documents need to share the registry
Domenic_: yeah Eliot doesn't like that either
esprehn: came from a debate about
author expectation
... if imports don't share the same registry it produces
undesirable behaviour - you can't share things across your
imports. The rest of the sharing is consistency that I think is
confusing - you cannot escape the registry.
AvK: if iframe scrdoc and the registry doesn't cross that would be sad
esprehn: It doesn't - thats a different window
rniwa: It would be nice to be able to use a registry, not be stuck with one
dglazkov: should be a v2
esprehn: want to scale bakc- you don't share registry unless you ask for it
Domenic_: should that be in v1 or can we start out with unshared registry all the time
AvK; if you do shared registry you get global pollution
esprehn: there was one registry
for everything. That's not nice - e.g. upgrades run on XHR'ed
stuff.
... so it is on some docs
rniwa: yeah. Which is
confusing.
... my preference is not to do any of this stuff.
... one registry per document
dglazkov: That's OK
... if we get HTML modules we'll need a registry API.
rniwa: if we get a simple registry API we can have one. Until then you cannot have nice things.
Travis: would it reflect structures?
dglazkov: n argument for doing this in v1, if you had register.set you don't need defineElement
RESOLUTION: no sharing of registries in v1.
Thanks scribes, many thanks apple for hosting, [adjourned]
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/break it apart/write it up and see what people implement and want to rely on/ Succeeded: s/getComputed/getDistributedNodes/ FAILED: s/getComputed/getDistributedNodes/ Succeeded: s/getComp/getDistributedNodes/ Succeeded: s/315/316/ Succeeded: i/without it authors/scribe: esprehn Succeeded: i/without it authors/scribenick: esprehn Found Scribe: esprehn Found ScribeNick: esprehn Found Scribe: chaals Inferring ScribeNick: chaals Scribes: esprehn, chaals ScribeNicks: esprehn, chaals Present: Domenic_Denicola Takayoshi_Kochi Leonie_Watson Travis_Leithead AnneVK Arron_Eicholz Chaals Dimitri_Glazkov Elliott_Sprehn Hayato_Ito Ted_OConnor Jan_Miksovsky Justin_Fagnani Ryosuke_Niwa WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 Guessing minutes URL: http://www.w3.org/2016/01/26-webapps-minutes.html People with action items: domenic jan_m WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]