Notes from Custom Elements meeting

Available at

Text version:

                      Web Platform - Custom Elements

25 Jan 2016

    See also: [2]IRC log



           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



           Plh, Travis, dglazkov, rniwa, esprehn, chaals


      * [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


agenda bashing

    <chaals> [15]Contentious bits: things for the agenda


    Travis: looking at contentious bits, we should do: review of
    constructors, simple name properties, attribute change callback
    ... [...]

    dglazkov: we should start with least contentious

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
    ... if a nano can queue more work that results in a

    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


    [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
    ... 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

    <smaug> one of the reasons for MutionObservers was performance,
    which is a lot better than with more sync (nanotask-like)

    Anne: how would we do that?

    <smaug> (microtasks give the better performance)

    [break to bring Domenic]

    <annevk> See
    [17] Travis


    Ryosuke: some elements affect others only if they are in the
    document (base, style)

    Domenic: detached documents are so rare that yes, we can leave
    it as an edge case we don't solve

    dglazkov&Ryosuke: agreed

    dglazkov: I like the idea of a generic callback

    Ryosuke: so, if we add the attribute filter, it might be ugly
    to have two different was to follow attributes changing.

    domenic: making sure they match it's fine, but it's important
    to have both. eg being notify when creating custom elements

    travis: you can only observe your own attributes, so damage is

    ryosuke: we have a bunch of other sync events, not sure if it
    ... with a microtask ending, you would batch those if lots of
    ... 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

    <rniwa> [18]


    Ryosuke: when navigating an iframe, you would fire those

    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

    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

    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
    ... 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
    ... will require some deep parser spec engineering :-(

    <smaug> even in case of innerHTML ?

    anne: formalizing document.write? and applying to other

    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: 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

    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

    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

    justin: are you referring to how the properties have the
    'computed value' whereas the attribute has whatever state was
    ... 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

    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

    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 ....

    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

    <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...



    [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, other state, etc., you might be able
    to figure it out.

    Domenic_: if you call 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

    justin: I think you can solve this. With + 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

    esprehn: In ES6, if constructor keeps returning random stuff.

    Domenic_: super() is short for this = new super().

    esprehn: is the thing at the bottom of the stack.



    rniwa: what if you call you're own constructor (or another

    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
    ... 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
    ... 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.



    justin: we may need another global to manage the 'in UA

    rniwa: Seems desirable to create some kind of element...

    justin: Well... maybe you could wait till

    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

    esprehn: in upgrade case, what happens?
    ... If we swizzle your prototype and things break, then...

    rniwa: Leave it.

    Domenic_: and things are half-baked and broken.

    esprehn: You'd queue an exception to fire up the stack (for

    jan_miksovsky: We really want a constructor without a required
    ... 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


    <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

    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

    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
    ... 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

    rniwa: ideally, we want to do everything synchronously
    ... easiest ergonomics, consistent world state, do something ->
    ... 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

    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


    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

    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

    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
    ... 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]


    <rniwa> [24]


    [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
    ... 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

    Travis: that could modify DOM

    rniwa: I am sure browser will have extensions, etc.



    Travis: I think it's fine, we can build support for
    ... 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

    RESOLUTION: Nanotask timing for constructor


    <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

    <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 /

    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

    jan_miksovsky: there is already mutation observer that can
    observe all attributes
    ... in MO, you can modify the list of attributes being observed

    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

    <chaals> esprehn: It's slow to do it like justin wants, working

    <chaals> DD: You don't get at queue time you do it at call

    <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

    <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



    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

    <Domenic_> (Attribute filter writeup:


    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

    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
    ... 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

    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
    ... 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

    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
    ... 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

    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

    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

    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"


    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

    justin: I want to make sure that everyone understands our use

    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

    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

    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
    ... 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

    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
    ... you can't force people to agree with you in a standards

    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

    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:


    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]


    ^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


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

    ⦠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


Shadow DOM Styling

    <kochi2> #316

    <kochi2> [32]


    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

    ⦠remaining point is bug 316 - how do we handle style

    esprehn: Where in the order it comes?

    ⦠didn't we agree with Tab on this?

    LJW: at the last meeting

    <rniwa> Two test cases:


    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:


    hayato: basically this means current vs new implementation.
    Unless there is a strong objection we should adopt option 2.

    ⦠if the test cases are unacceptable, please object.

    rniwa: proposal is to do option 2?

    ⦠we pass everything except a slotted we don't implement yet.

    [taken offline]


    Domenic_: Make them ES6. Awesome.

    [But it was DMitri's idea]

    esprehn: we want to drop style

    justin: we want the scripts to run

    Domenic_: not in the same doc

    justin: There should be a registry


    rniwa: not sure why mutliple documents need to share the

    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
    [NEW] ACTION: domenic to document stack of queues and ordering
    [recorded in
    [NEW] ACTION: Domenic_ will write a formal spec for attribute
    filter [recorded in
    [NEW] ACTION: jan_M to work with Hayato and spec this out
    [recorded in
    [NEW] ACTION: rniwa write up what the caller for custom element
    constructor and HTML element constructor should check [recorded


Summary of Resolutions

     1. [40]We're happy to do it like this
     2. [41]generic callback need be written down, instead of
     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