Available at
https://www.w3.org/2016/01/25-webapps-minutes.html
Text version:
Web Platform - Custom Elements
25 Jan 2016
See also: [2]IRC log
[2] http://www.w3.org/2016/01/25-webapps-irc
Attendees
Present
Domenic_Denicola, Takayoshi_Kochi, Léonie_Watson,
Travis_Leithead, AnneVK, Arron_Eicholz, Chaals,
Dimitri_Glazkov, Elliott_Sprehn, Hayato_Ito,
Ted_OConnor, Jan_Miksovsky, Justin_Fagnani,
Ryosuke_Niwa, Plh, Monica, Antti, Smaug, William_Chen
Regrets
Chair
chaals
Scribe
Plh, Travis, dglazkov, rniwa, esprehn, chaals
Contents
* [3]Topics
1. [4]agenda bashing
2. [5]lifecycle callback timing
3. [6]Symbol Name vs String name
4. [7]Symbol or String
5. [8]is=
6. [9]upgrade is top-down, right?
7. [10]Shadow DOM Styling
8. [11]Imports
9. [12]registry
* [13]Summary of Action Items
* [14]Summary of Resolutions
__________________________________________________________
[introductions]
agenda bashing
<chaals> [15]Contentious bits: things for the agenda
[15]
https://github.com/w3c/webcomponents/wiki/Custom-Elements:-Contentious-Bits
Travis: looking at contentious bits, we should do: review of
constructors, simple name properties, attribute change callback
... [...]
dglazkov: we should start with least contentious
lifecycle callback timing
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
[16]http://www.w3.org/2016/01/25-webapps-minutes.html#action01]
[16] http://www.w3.org/2016/01/25-webapps-minutes.html#action01]
[this is resolved]
RESOLUTION: We're happy to do it like this
Symbol Name vs String name
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
[17]https://www.w3.org/Bugs/Public/show_bug.cgi?id=23250 Travis
[17] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23250
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> [18]https://github.com/w3c/webcomponents/issues/362
[18] 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
Symbol or String
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_>
[19]https://gist.github.com/domenic/c1566e755c9e14613aa1
[19] 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_>
[20]https://gist.github.com/domenic/c1566e755c9e14613aa1#gistco
mment-1679615
[20]
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>
[21]https://gist.github.com/dglazkov/72ae5223631c525ba6e7
[21] 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
[22]http://www.w3.org/2016/01/25-webapps-minutes.html#action02]
[22] 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> [23]https://jsfiddle.net/gxwdv5vv/2/
[23] https://jsfiddle.net/gxwdv5vv/2/
<rniwa> [24]https://jsfiddle.net/h3L8sz2w/2/
[24] 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.
<Domenic_>
[25]https://code.google.com/p/chromium/codesearch#search/&q=Cus
tomElementCallbacks&sq=package:chromium&type=cs
[25]
https://code.google.com/p/chromium/codesearch#search/&q=CustomElementCallbacks&sq=package:chromium&type=cs
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
[26]http://www.w3.org/2016/01/25-webapps-minutes.html#action03]
[26] http://www.w3.org/2016/01/25-webapps-minutes.html#action03]
is=
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:
[27]https://github.com/w3c/webcomponents/issues/367)
[27] 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:
[28]https://github.com/w3c/webcomponents/issues/288
[28] 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> [29]https://github.com/w3c/webcomponents/issues/288
[29] 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
[30]http://www.w3.org/2016/01/25-webapps-minutes.html#action04]
[30] http://www.w3.org/2016/01/25-webapps-minutes.html#action04]
upgrade is top-down, right?
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
[31]http://www.w3.org/2016/01/25-webapps-minutes.html#action05]
[31] http://www.w3.org/2016/01/25-webapps-minutes.html#action05]
Shadow DOM Styling
<kochi2> #316
<kochi2> [32]https://github.com/w3c/webcomponents/issues/316
[32] 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:
[33]https://github.com/w3c/web-platform-tests/pull/2515
[33] 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:
[34]http://w3c-test.org/shadow-dom/styles/shadow-cascade-order.
html
[34] 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]
Imports
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
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]
Summary of Action Items
[NEW] ACTION: chaals file issue on WebIDL to get the nanotask
flow documented [recorded in
[35]http://www.w3.org/2016/01/25-webapps-minutes.html#action01]
[NEW] ACTION: domenic to document stack of queues and ordering
[recorded in
[36]http://www.w3.org/2016/01/25-webapps-minutes.html#action05]
[NEW] ACTION: Domenic_ will write a formal spec for attribute
filter [recorded in
[37]http://www.w3.org/2016/01/25-webapps-minutes.html#action03]
[NEW] ACTION: jan_M to work with Hayato and spec this out
[recorded in
[38]http://www.w3.org/2016/01/25-webapps-minutes.html#action04]
[NEW] ACTION: rniwa write up what the caller for custom element
constructor and HTML element constructor should check [recorded
in
[39]http://www.w3.org/2016/01/25-webapps-minutes.html#action02]
[35] http://www.w3.org/2016/01/25-webapps-minutes.html#action01
[36] http://www.w3.org/2016/01/25-webapps-minutes.html#action05
[37] http://www.w3.org/2016/01/25-webapps-minutes.html#action03
[38] http://www.w3.org/2016/01/25-webapps-minutes.html#action04
[39] http://www.w3.org/2016/01/25-webapps-minutes.html#action02
Summary of Resolutions
1. [40]We're happy to do it like this
2. [41]generic callback need be written down, instead of
detach/attach
3. [42]We need to find a good colour^name
4. [43]no change from current spec.
5. [44]use defineCustomElement - voidâ¦
6. [45]No, actually defineElement seems a great idea
7. [46]Nanotask timing for constructor
8. [47]we remember why we have the spec the way it is.
9. [48]no sharing of registries in v1.
[End of minutes]
