Notes from Custom Elements meeting from Philippe Le Hegaret on 2016-01-26 (public-webapps@w3.org from January to March 2016)

From: Philippe Le Hegaret <plh@w3.org>
Date: Tue, 26 Jan 2016 06:06:45 -0800
To: WebApps WG <public-webapps@w3.org>
Message-ID: <56A77D75.7010902@w3.org>

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

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]

Received on Tuesday, 26 January 2016 14:06:55 UTC