See also: IRC log
[introductions]
<chaals> Contentious bits: things for the agenda
Travis: looking at contentious bits, we should do: review of constructors, simple name properties, attribute change callback
... [...]
dglazkov: we should start with least contentious
Travis: so is it documented yet when to fire a nano task?
Anne: when IDL returns, but not documented yet
dglazkov: there is a queue
Anne: just before you return from the method call, there would be a nanotask
Travis: we assume it's introduced when to invoke a method in WebIDL
... if a nano can queue more work that results in a microtask...
Ryosuke: you have a stack of nanotask
Travis: so sync but delayed after the operation...
<chaals> ACTION: chaals file issue on WebIDL to get the nanotask flow documented [recorded in http://www.w3.org/2016/01/25-webapps-minutes.html#action01]
[this is resolved]
RESOLUTION: We're happy to do it like this
Travis: concern is: what if we move the logic of custom element and put it into mutation observers?
... so that you have one API for observing mutations
... attach/detach/reparenting should be addressed in mutation observers
... in addition to want nanotask timing
Ryosuke: that would bring queing vs tasking
... one reason to design this way was that it was easy for mutation observer to step on each other
... if you modify something in a mutation observer, you have no idea of the ordering
... if we move the logic, we would reintroducing the problem
Travis: I just want to move the API surface
... to make it general purpose
... I don't have to create a new API
... just have to take care of the constructor
Ryosuke: make sense to me
Travis: I'm saying we should not punt on it, but would like to transition
<smaug> one of the reasons for MutionObservers was performance, which is a lot better than with more sync (nanotask-like) MutationEvents.
Anne: how would we do that?
<smaug> (microtasks give the better performance)
[break to bring Domenic]
<annevk> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=23250 Travis
Ryosuke: some elements affect others only if they are in the document (base, style)
Domenic: detached documents are so rare that yes, we can leave it as an edge case we don't solve
dglazkov&Ryosuke: agreed
dglazkov: I like the idea of a generic callback
Ryosuke: so, if we add the attribute filter, it might be ugly to have two different was to follow attributes changing.
domenic: making sure they match it's fine, but it's important to have both. eg being notify when creating custom elements
travis: you can only observe your own attributes, so damage is limited
ryosuke: we have a bunch of other sync events, not sure if it matters
... with a microtask ending, you would batch those if lots of elements
... range functions will operate on custom elements. nanotask will fire at the end of the range operation
anne: but that might not involve any IDL
... at least, it's not written down
RESOLUTION: generic callback need be written down, instead of detach/attach
<rniwa> https://github.com/w3c/webcomponents/issues/362
Ryosuke: when navigating an iframe, you would fire those callbacks
Anne: except that script execution is stalled
Domenic: if had a parent browsing context change callback could do the trick
<inserted> Ryosuke: We don't want the author scripts to run when you navigate away from your iframe… which is notified by pageVisibility rather than attached and detached
Anne: why do we only have the more restrictive callback, ie when the doc change
Domenic: very spammy, and not many use cases
Ryosuke: when you keep inserting substree, it would generate a lot of callbacks
Anne: so, are shadow tree in a composed document?
Ryosuke: ordering is important...
... when getting a callback, should we have it before invoking callback for subcomponents?
Domenic: use case points to the document
Ryosuke: but it's important to figure the ordering
... top-down order, your subcomponents might not be ready
... take the layout component. you'll need the subcomponents
Justin: should components assume they have their subcomponent or get updates
... for layout you want to respond as the children are updated
... we've seen cases when people want to know when children are ready, but it seems the wrong way
Travis: if you're a tab layout, you'll need at least 2 children
Justin: I used when you need to setup something up the tree
Domenic: like when starting to listen to mouse events
... bottom-up seem to encourage a bad style
Justin: yes, I've seen it misused already
... I'm partial to encourage to listen to child changes rather than assuming the children are correct
Domenic: we'll probably top-bottom for constructors so we should do the same
Ryosuke: agreed
Jan: some components want to know how they're styled
... when do I have style information?
Ryosuke: sounds like it leads to a horrible n-squared algorithm...
dglazkov: we should discourage people doing so, but they'll keep doing it :)
... we need to keep looking for answer
Justin: I'd like a style observer
Travis: combination of mutation observers and style attributes
Anne: seems weird. there is a term called "in a document" that will return false ina shadow root tree
... for those, we have "in a composed document"
Domenic: we need to change the author facing name or change the spec
Hayato: "inserted into a document deeply"?
... we have to resolve the distribution anyway
Jan: can we have a name that doesn't have to be precised?
[naming discussion]
[naming discussion...]
Domenic: if you do document.contains, it won't return true in a deep/composed document
Anne: inserted and removed are fine
Justin: the fact that we have removed is an argument against a callback using remove
... node.remove will not always do a remove
... if you're a detached case
RESOLUTION: We need to find a good colour^name
Unresolved: someone to come up with a proper name
[back to symbol names]
Domenic: let's separate public API from subclass API, but agree it';s not ergonomic
Domenic: one design is to hide those by putting them on another object not directly on prototypes but it's disruptive
Anne: problem with symbol things is extending
Domenic: no two symbols are ever equal to each other
... with strings, we would be able to change the semantic as easily
... there is a cultural opinion against encouraging subclasses, while we're encourage to do so at the moment
Jan: we're running the risk of conflicts already
Domenic: you don't avoid very much by going to symbols
ted: the day 2 day cost outweight the purity...
Domenic: so we have to go back to callbacks on everything...
[general agreement]
RESOLUTION: no change from current spec.
<Travis> scribe: Travis
<scribe> scribeNick: Travis
domenic: We may have exhausted the non-controversial stuff
... callback timing
... parser stops
... fires attribute changed
... children
... then resumes
... seems there's good cause to fire the callbacks as soon as possible.
... will require some deep parser spec engineering :-(
<smaug> even in case of innerHTML ?
anne: formalizing document.write? and applying to other elements?
rniwa: we should disallow document.write
<esprehn> Not in the case of innerHTML. That allows you to observe the fragment inside the algorithm
rniwa: there's a flag for that already.
anne: the other problem is dom mutations. If you remove the element, where does the parser resume?
Domenic_: we should just disallow document.write.
annevk: the parser already follows the stack
Domenic_: this is another level of complicated.
... I'm looking for clear-cut places to disallow things.
rniwa: in a constructor, script element is created and sync-inserted into document, what then
Domenic_: scripts inserted from XHR are disllowed
annevk: because those docs have no browsing context.
... with random scripts, you're just nesting a little
rniwa: document.open/write only cases of reentrancy?
Travis: parser can stop at any time...
annevk: all these concerns already apply to script element. We already have syncronicity.
Domenic_: I just disallowed in modules because they are 'bad'
annevk: Here it doesn't really buy us anything.
Domenic_: [describes the order of operations]
smaug: even in places of innerHTML?
Domenic_: good point.
... right now the fragment in innerHTML is a spec fiction. This feature would allow that to become observerable.
... alternatives are to wait until nano-task timing.
annevk: with innerHTML, parser has to queue the nano-tasks. We then define when to fire these.
Domenic_: according to my new order, parser never queues nano-tasks.
annevk: Well,they can be syncronous...
... in innerHTML case they get queued as well.
rniwa: inside of parser, it would be sync, but in innerHTML it would be nano-task. Is that what is being proposed?
Domenic_: well we have upgrades and parsing... we're saying innerHTML is an upgrade case.
rniwa: having the parser act two different ways is weird to me.
Domenic_: for authors, I could argue that innerHTML and parsing are understood differently.
rniwa: As an author now I have to worry about it?
Domenic_: The argument is that you code it as if there are no children.
Travis: for consistent world view, should we not fire attribute changed if they're already present at constructor time?
dglazkov: I can come to terms with innerHTML being treated as an upgrade case.
justin: I see danger that authors will set attributes (default) during parsing expecting to have the parser overwrite them...
Domenic_: Forcing innerHTML to have the upgrade world-view will change author expectations.
monica: we rely on default attributes (versus user attributes) for aria. Order is important for us.
... we do this on attached.
annevk: for aria we should have an internal API. Then you can set defaults and have them be overwritten.
... you'd have some internal slots for that.
... you don't want to have the attributes be the cannonical state.
justin: are you referring to how the properties have the 'computed value' whereas the attribute has whatever state was set.
... there are some cases where you do want to write an attribute for the purposes of styling...
dglazkov: are we getting close to resolving this?
Domenic_: I'm not really comfortable with saying that [it] happens synchronous. TAble for 20 mins, or decide?
rniwa: table it.
annevk: Folks always deferring to script, depending on upgrades...
Domenic_: I don't think the innerHTML case changes this.
... OK. New topic.
... registerElement or new API name?
dglazkov: new name!!!!!
RESOLUTION: use defineCustomElement - void…
<justin> travis: talk slower
Domenic_: apple did "defineCustomElement"
rniwa: the name is kinda long, but I like long names.
annevk: I'm happy bikeshedding... er with 'defineElement'
jan_miksovsky: I like the similarities between defineElement and createElement... they look nice together.
RESOLUTION: No, actually defineElement seems a great idea
Domenic_: single class per element name?
rniwa: ins/del use the same interface.
justin: Some folks want to be able to use "is" as a mixin
... not only using single class def for multiple elements.
... I want some sugar (a custom element definition) and apply to other elements in the document.
rniwa: If your module only defines the class, then you can leave it up to author's to define the names.
... If no one objects to mutliple tag names per class...
<esprehn> I object:)
<esprehn> I think it's a bug in the platform that we didn't have class per tag name
rniwa: then there is a problem with how the exotic object is created.
Domenic_: fixable if you pass tagname through super(tag_name).
<chaals> [PLH steps out]
rniwa: Then you have to propogate the usage of tagname (both externally and internally to your class)
Domenic_: during parsing you encounter <x-p> how does the parser tell what to do in the class?
<esprehn> Yeah that seems bad, tag name should be read from a static on the class
Domenic_: This constrains the first argument to custom element constructor to have the tag name.
rniwa: constructor can return whatever it wants!
... we could allow this.
... It would be a known issue.
Domenic_: what happens when constructor throws?
<esprehn> static get tagName() { return "x-foo"; } defineElement tears off the getter just like it does for attached and friends
rniwa: When it throws, when in parsing, we probably need to create HTMLUnknownElement.
... It's OK for custom element constructor to return a text node. Then the parser tries to add a child to it... and .... kaboom!
annevk: I think you just need to create an HTMLUnknownElement in all these cases.
<esprehn> Hmm... I think if you return something that is not an Element we should abort the process and leave it as an Unknown
<esprehn> Yes
justin: back to elements with mutliple tag names... can't you solve this similarly to constructor-call trick.
<esprehn> Yeah, i agree with Anne
justin: when you call into HTMLElement constructor it has some magic to know what the tag name will be.
Travis: So then this becomes implicit and not exposed to web code?
<esprehn> Can it consult the parser state?
rniwa: You can call your super constructor multiple times... (via new ...)
justin: You have some global state. Showed Eliott, he said...
<Domenic_> https://gist.github.com/domenic/c1566e755c9e14613aa1
[lost it]
<esprehn> I think you can just ask the constructor table though
Domenic_: [looking at link... hard problem... if a new happens before the super call]
justin: given new.target, other state, etc., you might be able to figure it out.
Domenic_: if you call new.target it will have the wrong target (to be sure)
... we can expand a check.
justin: you have to check a stack to make sure you haven't re-entered yourself.
annevk: What's the problem (summary)?
<esprehn> I need help from the lobby :)
rniwa: When super() is called, we need to construct the right element (whatever the parser's trying to create).
... in upgrade, this is really important. The super() call needs to return the right object (you).
... now when you make a new call to yourself, things get confused.
justin: I think you can solve this. With new.target + a stack.
rniwa: yes, you can, but ugggg.
... Also, constructor could be inline.
<chaals> [esprehn arrives]
rniwa: There is a point when you can detect this... after you return from the constructor. If during the constructor, you already called a constructor, then you could fail out (bail).
... problem is that super() call is returning completely random object.
esprehn: In ES6, if constructor keeps returning random stuff.
Domenic_: super() is short for this = new super().
esprehn: new.target is the thing at the bottom of the stack.
<Domenic_> https://gist.github.com/domenic/c1566e755c9e14613aa1#gistcomment-1679615
rniwa: what if you call you're own constructor (or another element).
Domenic_: Did this fix it?
rniwa: The inner call will work, but then it will throw.
justin: combined with HTMLUnknownElement, this is what you will get.
... You can crazy constructor stuff _after_ super. But if you do it before...
rniwa: you're just a bad person.
[all agree]
rniwa: [discovers the white-board]
... describes case with new element created in first line of a constructor.
... then there's a super call...
... conclusion: we have to disallow both before and after new creations in the constructor.
justin: without using a stack.
<dglazkov> https://gist.github.com/dglazkov/72ae5223631c525ba6e7
justin: we may need another global to manage the 'in UA construction'
rniwa: Seems desirable to create some kind of element...
justin: Well... maybe you could wait till attached[bikeshed]callback.
esprehn: can't we just change ES6 construction/creation?
... I think developers will revolt if we disallow creating new elements in the constructor.
annevk: input type password, like input type text/button. There's some precident.
rniwa: OK, so we can't throw.
... in output we can check to see if the thing we thought would be created was created, and if not throw.
... Working backwards, reviewing the implications of this change...
esprehn: in upgrade case, what happens?
... If we swizzle your prototype and things break, then... what?
rniwa: Leave it.
Domenic_: and things are half-baked and broken.
esprehn: You'd queue an exception to fire up the stack (for onerror)
jan_miksovsky: We really want a constructor without a required parameter
... how would this problem be different if there was an argument to the constructor?
... all these games to make sure we support a constructor without arguments?
Domenic_: no, this is more base than that.
[discussions and clarifications]
Domenic_: someone who understands these implications better than me should write this up.
rniwa: I can do this.
chaals: break for lunch? yes.
<chaals> ACTION: rniwa write up what the caller for custom element constructor and HTML element constructor should check [recorded in http://www.w3.org/2016/01/25-webapps-minutes.html#action02]
<dglazkov> scribe: dglazkov
[discussion around timing of callbacks/constructors]
esprehn: the parser will be special and innerHTML and others will have a nanotask timing
rniwa: disagree. the problem is that this will be inconsistent
... compound operations, editing
esprehn: run all callbacks sync?
rniwa: just constructors
[discussion around where to run sizing code for custom element]
esprehn: defer all interesting work until it's time to run attach
rniwa: disagree, you can't just change my opinion by repeating the same thing
... I added EventQueueScope and we still sometimes run script during editing
esprehn: would like to avoid running script during editing, and if they do, treat them as a bug
domenic_: this is one of our "can not live with" issues
rniwa: in this case we can't reach the agreement today
esprehn: this has benefits, right? you have to make it work with both upgrade and non-upgrade, you have a better design
... [provides an analogical design decision]
... [ ... in android]
jan_miksovsky: asking clarifying question: am I hearing correctly that esprehn is suggesting I should defer important work until "attached" callback?
[clarifying discussion]
hober: probably good to distinguish the discussion between how we want people to write code and how they will actually write code
jan_miksovsky: may make sense if you change the stakes (throws in the case we don't want people to write code)
Domenic_: has been my opinion that this does not come up very often
... devs will not see a lot of difference unless they do a lot of work
esprehn: complaints we see from devs: 1) finishedParsing callback for element; 2) attribute setting during constructor
annevk: part of the mismatch might be that Blink believes that they can defer everything that happens, and WebKit does not quite believe that.
Domenic_: Gecko delays some of the mutation events already
annevk: not all cases
jan_miksovsky: ... what's the reason for synchronous constructor?
rniwa: ideally, we want to do everything synchronously
... easiest ergonomics, consistent world state, do something -> happens
... in some cases it is okay, like attributeChanged
... not okay for the cases when the object is being created and constructor is not called
justin: but this is true for upgrades?
rniwa: right, this is why we don't like them
justin: since you already have to assume the upgrade case, why do you need to have sync constructor?
rniwa: for attributeChanged case, at least you can call a method on an object, but with async constructors you literally don't have the right proto/identity of an object
[discussion around when this would happen]
monica: this is why we don't do any important work in created, except for creating a stub shadow tree maybe
annevk: in HTML spec, most of the work happens when an element is inserted or removed. Creating element does nothing most of the time.
esprehn: another case, innerHTML fragment is spec fiction, and ideally we should not make it be observable
rniwa: interested in what Mozilla/Microsoft thinks, may help sway
annevk: if we can prove that we can move all events to nanotask timing. If we did, then we will be convinced. Otherwise, the sync argument stronger
Travis: nanotask looks like sync
annevk: no, there are some cases where you can see
... from the spec perspective it would be better if we did everything deferred
Travis: in spec, if you clone the tree, do you get 3 callbacks?
annevk: yes
Travis: so it's identical to microtask?
rniwa: no, because is a stack of queues
[discussion]
esprehn: modeled after auto-release pools
<plh> me thanks!
jan_miksovsky: what's the right model to build components? If I were to create a boilerplate, what's my general model?
... I don't think I can explain to someone when to do what. As a component author, I am a little confused.
<chaals> [PLH returns]
jan_miksovsky: "here's a bunch of hooks, use them as you see fit". I would prefer a good boilerplate
annevk: there are many different models?
Domenic_: pretty decent consensus on what the boilerplate is
annevk: in img element, you might want to start as early as possible
esprehn: that might be an anti-pattern
jan_miksovsky: ask for a tighter range of options
justin: not sure the sync/async changes this boilerplate
jan_miksovsky: if no useful work happens in constructor, would this be significant for this discussion?
Travis: no one here is saying we should take away the constructor callback, right?
esprehn: use constructor to set up shape of the object (and stop changing it if you want to run fast)
... might not be the same time quantum as the one to look at your attributes and children
Domenic_: [some proposal about attribute change listening, not clear]
justin: what's the relationship between attributeChangedCallback and insertedIntoDocumentCallback?
Domenic_: inserted is called after
justin: that's okay then
... [explains how complex elements need a state machine]
Domenic_: upgrade should call attributeChangedCallback and cal insertedIntoDocumentCallback
... and need to define an order
annevk, esprehn: call before
[discussion around order]
annevk: most good elements should work either way. Script src is different, but should work either way
<rniwa> Here are events that fire synchronously in both WebKit/Blink: v
<rniwa> https://jsfiddle.net/gxwdv5vv/2/
<rniwa> https://jsfiddle.net/h3L8sz2w/2/
[looking at what does Edge do]
[and what Firefox does]
s/prevent component model/build components/
rniwa: looks like only Blink/WebKit fire these sync
Travis: focus is sync
rniwa: so at least one event is fired sync
Travis: are we still stuck on constructor/nanotask discussion?
wchen: I don't think we can confidently say that we'll be robust against sync constructor
annevk: bz says it will be significant amount work
jan_miksovsky: so your preference would be to be async in non-constructor case
annevk: yes
... we are already moving to nanotask timing somewhat
jan_miksovsky: so that adds up to proposal non-parser async constructor
... Travis?
Travis: parsing is fine
... otherwise, thinking of our design, we have a consistent tree model, which matches all changes to the tree
... [describes how Edge model works]
... will need archeology
Domenic_: definitely will need archeology
wchen: seems like we need it anyway
rniwa: we should have a comprehensive list of methods/getters/setters
Travis: that could modify DOM
rniwa: I am sure browser will have extensions, etc.
Travis: I think it's fine, we can build support for architecture
... it's probably harder to nanotask than sync
annevk: you need to make sure it doesn't mess with your state
Travis: yes, but it's a smaller set
... we can implement, and dev ergonomics will be better
... these are all good reasons to go with nanotask
jan_miksovsky: I heard support from Mozilla and Edge
wchen: we already have something like this
rniwa: it seems that there's support, so there's no reason to argue
RESOLUTION: Nanotask timing for constructor
[break!]
<monica> unbreak!
Domenic_: the only issue that was remaining was attribute filter for style attribute
dglazkov: does anyone not want it
chaals: put a proposal on IRC
<smaug> ( hmm, ok, skype kicked me out. )
<Domenic_> Attribute filter proposal: at defineElement time, we grab constructor.attributeFilter and convert it to an IDL sequence<DOMString> (i.e. iterate over it and ToString each element). If it's not present, defineElement throws.
<smaug> Domenic_: so how do you get notifications for all the attributes?
<smaug> null attributeFilter?
<Domenic_> you can't, I think
<Domenic_> no built-in elements have that
<smaug> ah, true
<rniwa> scribe: rniwa
Domenic_: there is a question of style attribute spamming attributeChanged callbacks
... the proposal is to add an attribute filter which is a static property on class
... It's a mandatory property and it's statically bound at the time of `defineElement` call time
<arronei> class XFoo { static get attributeFilter() { return [ "a", "b" ]; } }
justin: why don't we not invoke attribute callbacks instead
Domenic_: that sounds better
justin: how about prefixing matching
esprehn: some libraries requested. e.g. for on*.
<smaug> (sounds like something not for v1)
<smaug> (that prefix matching )
chaals: the point of this filter is reducing the number of attributes being observed
<chaals> [agree with smaug]
justin: but how about an element that proxies attributes / properties?
esprehn: if we were to add *, I wish it would exclude "style" so that you'd have to write "*+style" in order to receive callbacks for style attribute
dglazkov: for v1, no * and no attribute change callback if it's missing.
jan_miksovsky: there is already mutation observer that can observe all attributes
... in MO, you can modify the list of attributes being observed dynamically
Domenic_: for those who think reading the filter value once is weird, both the callback function and the attribute filter values are read once at `defineElement` time
<chaals> rniwa: missing attributeFilter with no callbacks, mutation observer you always get callback… that's weird
Domenic_: what if we renamed it to attributeChangeFilter.
rniwa: my point was that semantics is different
esprehn: in the case when attribute filter is present, the behavior is the same
annevk: on a different topic, why do we keep the callback at the time of `defineElement`?
... if we had a subclass and called `super()`, it wouldn't be calling something different
<chaals> rniwa: agree, it is weird if DOM has this stuff on the side.
<chaals> esprehn: It's slow to do it like justin wants, working dynamically.
<chaals> DD: You don't get at queue time you do it at call time.
<chaals> esprehn: then we queue stuff we will drop on the floor
<chaals> DD: What if you @@
<chaals> Justin: kind of leaky
<chaals> AvK: If you don't have attributeChange you don't have attributefilter
<chaals> … subclasses will always be slow because when they invoke super thereis a get and call
<chaals> esprehn: no it is at registration time.
<chaals> … you have a bunch of static getters used at definition time
<chaals> Avk: if you have a subclass that invokes super, the call will do a get on the super class, and you will then have the slow stuff to do
<chaals> rniwa: You don't want to queue stuff.
<chaals> justin: guessing for most elements a framework will be there always defining these callbacks
<chaals> DD: I'm a bad person.
<chaals> esprehn: You can write a super.attributeFilter …
rniwa: if we had an attribute filter, you want to create a static internal structure for each custom element
esprehn: ^
... instead of having to keep querying to the engine.
... for callbacks, we can still cache the existence of methods
annevk: mostly to determine the shape?
Domenic_: I also like the idea of not being able to change the behavior of class
annevk: we can also do the shape check at runtime
... as to whether it has a callback or not
justin: that might lead to even more confusion because author can change function and some changes take into effect and others don
't
Domenic_: I don't think you should really mess with your class structure after calling `defineElement`
esprehn: the old design involved passing arguments around and chained it across super calls and that's how the server side stuff works
... but nobody liked that design
Domenic_: we should throw when an attribute callback is there but no attribute filter is set
<scribe> ACTION: Domenic_ will write a formal spec for attribute filter [recorded in http://www.w3.org/2016/01/25-webapps-minutes.html#action03]
hober: I think we kind of agreed not to do it.
justin: Polymer uses "is" and perhaps this is an instance in which the views of Chrome / Polymer are different.
monica: there is a lot of element for which parser treats differently
<Domenic_> (Attribute filter writeup: https://github.com/w3c/webcomponents/issues/367)
monica: for example, td has a special behavior in HTML parser
... so unless you can extend an existing element, you can't have parser treat it differently
justin: the most important use case for us is template element
... this might be a case in which wrapping with another element might work but we've seen some customers experiencing performance problems due to the sheer number of nodes in the document
Travis: what are those custom elements doing?
Domenic_: what they are is that they want to have these callbacks be involved on elements that already exist
Travis: this feels like the use case of end-of-nano task mutation observer
esprehn: that's not right. they also want to be able to add methods or accessibility features
Travis: and you probably don't want to write everything yourself
... so if you had HTMLAnchorElement defined and extended it, it's still an anchor element browser supports but you're supplementing it with callbacks and methods?
Domenic_: it's important to separate functionality from the particular syntax of is=~.
... in theory, this should be also achievable via custom tag name but bz pointed out that this would require a large rewrite of browser engines that check tag names
plh: what happens with selectors?
Travis: I'm still not sold on why you can't wrap it
... is= is like creating a new object to an existing element
esprehn: browser creates an exotic object which is anchor and then browser sticks the prototype into the instance
... it's just like upgrades
... the API currently doesn't have any checks for your custom element class not actually inheriting from a subclass of HTMLElement
justin: it seems like there was a consensus to drop this feature in v1, but for Polymer, this goes a long way
monica: templates and lists are big use cases
hober: does component kitchen use it?
jan_miksovsky: no
<monica> (and inputs and buttons and forms, for use cases)
dglazkov: if i were to remove myself from implementation, this whole this is about unveiling things that you can't get out of right now
... I want the same behavior parsing as "td" and want the same ARIA role, etc...
annevk: it feels like is= is not the right solution for this
Domenic_: but it would take a really time to resolve all of these problems property
jan_miksovsky: we didn't find not being able to insert a random element inside option, select, etc... haven't been that much of pain
... there has been a few cases like defining button without is= with the right style was hard
... we have seen it's painful to proxy properties and methods when wrapping elements
... syntax of is= seems a bit cranky saying this is one class but then it's another class
Travis: you can't use these elements plainly with createElement
justin: in terms of weirdness, we see tag names as roles
... and is= is the actual implementation
... there is also a consideration for third party tools that may expect standard HTML tag names
LJWatson: feels like this might be a similar problem as ones encountered in epubs
Domenic_: this isn't a must have but this seems to solve many issues like accessibility
... shadow DOM already has restrictions on which element it can attach
chaals: restricting has a nice appeal
annevk: what if you wanted to apply new behaviors on a subset of elements
esprehn: parser also closes head when it hits an element other than one of the three elements
... so there is no way to put things into head with custom elements
... and we need to make the parser behavior different in order to allow this
annevk: we probably don't want to allow that because that would require everyone running scripts all the time
Domenic_: more generic syntax for inheriting from an element will be <super-a extends="a"> instead of <a is="super-a">
but this syntax has all the downsides of having to look up definitions
hober: is= seems like a good feature to think about when we think about what features are missing
... but since removing a feature is impossible, but maybe we should not add this feature now because we may regret later
justin: from API consumer point of view, we used link element (subclassed) and it's a real shame to lose that functionality
... what's the objection from implementor's side?
Travis: it's that it's a bad declarative syntax
chaals: it's ugly; this is what I hear.
... a question I pose counter to hober's point is that perhaps is= will solve many problems for once instead of having to go figure out three different problems separately and come up with a separate solution
... like some things in HTML, we may regret about this feature but it might be cheaper to be sorry later than not having anything that works for years
esprehn: we also find that this is useful for polyfilling
... e.g. dialog element can be polyfilled using lifecycle callbacks to get the timing right which is hard to do today
Domenic_: here's a lot of things you can do with is=
parsing hooks for <template>, <p>, <head>, <table>
accessibility bheavior
some DOM objects such as DOMTokenList
status bar hover (e.g. on a)
default style cascade position
some pseudo class states such as :visited, :disabled, :link, :read-only, etc...
focusable w/o tabindex
hook into preload scanner
hober: I think this is a lost of features some of which we may want or not want
... e.g. we may not want custom elements to override status bar
... pseudo style matching or having accessibility API might be useful
justin: is= attribute is ugly and in many cases you'd use custom tag name
... but it's useful in a few minority cases in which this feature is useful.
... so it's ugly but only in subset of cases
hober: it's weird that author has to use one or another sometimes
monica: but author already knows because there are some things browser wouldn't allow you to do
justin: similar things with link and template.
Travis: this is really about participate in lifecycle/callbacks of native elements
dglazkov: what if all browsers had all these features instead of is=
justin: what worries me is what if we had a set of native features and some of them were not extensible or amendable to support our use case
... for our subclass of link element, we say use <link is=~> so it's never ambiguous as to which syntax you use
annevk: what if instead of is=, we added the capability to add lifecycle callbacks
Domenic_: what if I wanted to add methods and properties
esprehn: what if I wanted one behavior in one a and another in another a
annevk: you don't. you get custom behaviors for all elements
chaals: with custom elements, we can have my-evan-links, my-odd-links, and you can put different ones
... but you can't do that with that kind of global extension
justin: now for our use case, we have to implement our non-standardized attribute
esprehn: this can be very spammy
<Zakim> LJWatson, you wanted to ask whether role= could be used/extended to trigger native behaviour?
LJWatson: I was wondering if we could extend "role" attribute
... what if "role" attribute made element actually linkable instead of only exposing it to AT.
hober, Domenic_ : this might not be backwards compatible because authors put this on some elements in which they don't expect such a behavior
<esprehn> chaals: Asked esprehn to scribe
<chaals> scribe: esprehn
dglazkov: can we summarize all the in person discussions?
justin: we were mainly talking about the (polymer) use cases
... the only way we can see working around losing is is to essentially run the custom elements polyfill in every shadowroot of the document
... and do the upgrading ourselves with mutation observers, with MO timing, etc. it'll be very difficult
Travis: change to as or "with"
"as"
Travis: I found that "with" explains it better
<chaals> esprehn: Other discussion: all this stuff is does is important,but years of work. is= is a really quick way to solve it, and that avoids having authors making piles of broken things while they are waiting for us to get to nirvana
justin: what's the conclusion?
chaals: who opposes?
rniwa: I oppose
<dglazkov> \
<dglazkov> ooops
monica: do you mean in v1 or v2 or ever?
rniwa: what can we agree on and have this feature be available in all browsers?
chaals: what do others think?
Travis: I think it's a compelling feature
wchen: we're neutral
Travis: it layers on top of custom elements, you can have both things
justin: I want to make sure that everyone understands our use cases
rniwa: we understand them
justin: if we get native custom elements without them it'll be very tough for us
Domenic_: just continue using your polyfill?
justin: we can't polyfill it
Domenic_: you can continue using it like you do in other browsers
justin: Firefox doesn't have native shadow dom so we can use a single MO
rniwa: replace attachShadow and add a MO there
Domenic_: if you don't want to work with the browser you have to do hacks
justin: we don't want to have thousands of MO
MO = MutationObserver
chaals: there's a certain amount of support for doing this
rniwa: I think there's a lot of frameworks that could work without this, maybe we can come to consensus in v2 and then add it
justin: I think we've come a little closer on understanding the need for this feature
Travis: decouple it from custom elements?
... we could create a new feature separate from defineElement
chaals: what's the support from chrome for actually doing this?
dglazkov: easy, it's already done
<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/25-webapps-minutes.html#action04]
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/25-webapps-minutes.html#action05]
<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.
… 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]