SV_MEETING_TITLE -- 05 Mar 2018

W3C Web Components f2f meeting

<Domenic> kochi: it requires approval to join, but seems to be working otherwise

<scribe> scribe: chaals

agenda bashing

s/Agenda Bashing/Introductions/

<kochi> Takayoshi(kochi) Kochi, GOogle

<pmdartus> Pierre-Marie, Salesforce

<diervo> Diego, Salesforce

<robwormald> Rob Wormald, Google (Angular)

agenda-bashing

AVK: Would like to go through issues marked needs implementor interest, or needs consensus, but would like to wait for Patrick.

JF: are we going to throw stuff up unconf style?

[yep. now]

<MikeSmit1> https://github.com/w3c/webcomponents/issues/713#issue-275960655

JF: CSS Shadow :part, :theme

RW: We want to give a short presentation on template instantiation.

TW: Declarative Shadow DOM

RN: HTML modules, scoped custom element registries

DV: Accessibility Object Model

RN: Have some questions on how components integrate... *think* we have some good answers.

DD: Custom Element form integration. tkent is driving that and is "around" if we need him.

TS: Doesn't this extend past custom to Shadow DOM?

DD: Anne thinks so, I don't...

<fergal> I've set the temperature to max. It seems to have stopped the A/C fan. Let me know if you get too hot!

JF: If we have time, declarative custom elements
... Do we want to talk about tying the specs together and how it might look in 5 years...?

AvK: If we timebox it seems fine

DV: Talk about CSS tokens and :state as part of constructable stylesheets?

RN: :state pseudo-class

AvK: Is an open issue

<Domenic> annevk: join https://hangouts.google.com/hangouts/_/google.com/kochi

<robwormald> https://g.co/present/google.com/kochi

<robwormald> i think works

<annevk> https://github.com/w3c/webcomponents/issues?q=is%3Aopen+is%3Aissue+label%3A%22needs+consensus%22

open issues neeing consensus

<annevk> https://github.com/w3c/webcomponents/issues?q=is%3Aopen+is%3Aissue+label%3A%22needs+consensus%22+sort%3Acreated-asc

iframe, history API

OP: We agreed to try something a couple of years ago. We need to rewrite the session history API to something sane anyway. How to map shadow iframes in that.

<kochi> https://github.com/w3c/webcomponents/issues/184

OP: think we need a separate history for them.
... we agree we need something, spec'ing it properly is hard.

RN: Hard bit is ther need to be fixups when shadow root is removed. So if you have an iframe in one that navigates, and then remove the root, the aggregate history has to remove the stuff in the middle.

OP: We do that in Gecko
... for iframes but not shadow iframes. They are different and should not show up in the top-level history.

RN: Yep, the problem is when two shadow iframes exist and one navigates.

OP: And the current session history spec doesn't match reality.

AvK: The leak is that shadows can affect each other.

OP: Yeah. Which is major.

RN: You want to be able to navigate sanely...

AvK: So how motivated are implementors to fix this?

[embarassed laughter]

OP: We do need to fix this somehow.

DD: It would help if we had some Web Platform Tests.

AvK: We know browers are similar, but not similar to the spec.

RN: So we need to fix the session history anyway, and then we can try to figure out this bit.

DD: So next step is tests to show how to fix the basic session history spec.

Fergal: is it agreed the browsers are doing the *right* thing?

[more embarassed laughter...]

RN: Changing the implementations a lot is unlikely

DV: We would be happy to help with tests, given a bit of guidance.

Callback for form data: will be a separate topic.

Lightweight styles: separate topic

<kochi> https://github.com/w3c/webcomponents/issues/479

.activePath ...

JF: Activepath is supposed to replace path to active element.

HI: This is a feature from Polymer. Current active element is not enough for their use cases.

AvK: .activeelement won't return anything from inside a shadow tree.

RW: you need to do a bunch of work to get into the thing that is focused.

RN: So what is the use case for this?

RW: Trying to manage focus traversal across complex components. You need to know the deepest active element - which is where the user's focus actually is.

AvK: If you manage focus on a page including components, you run into this.
... that's incompatible with having closed shadows.

RN: deepPath on event does this, right?
... so why can't this just be done by frameworks that need it?

TOC: Where some shadows are open you're fine, it's only where it is closed that there is any pain.

JF: It's feasible to do it, it is just an ergonomic issue. Some of it is shadows can point to distributed nodes.

DD: So we should fix activeElement not to point to distributed nodes, then find something else that does that.

RW: Use case is "find the thing that is currently focused on the page".

RN: Where you come from global, you don't see the shadow root.

DD: Think the underlying concern is the definition of activeElement is weird. Do we want to fix it?

Avk: We haven't defined focus properly. If we fix that we might have a base

DD: In shadow there is focus, but needs to be a tighter definition.

RN: Gave feedback on the issue, don't think we need to add the API

<Domenic> Current activeElement definition: http://w3c.github.io/webcomponents/spec/shadow/#active-element

TOC: In general the area needs work but don't think we need to change semantics

AvK: This is also old, and seems not to have been followed up recently, maybe we can close it?

DD: It's ok if activeEleemnt retargets into a shadow?

RN: Yep.

TW: You need to traverse the tree to find out what is active

DD: currently uses retargeting on focuused element. So if that is something distributed, it can point outside the shadow.

AvK: Like docment.activeElement would return with a single shadow.

RN: Figuring out which node in your tree, when you are given something outside the tree, is hard.

JF: You can work around this, but thinking of an element that only wants to manage its own tab order, if it doesn't check that activeElement is inside it then you start to make a mess.

RN: Changing this seems a bit risky, and not sure we can change the behaviour, We could add a new thing. A generic API that says what node mmatches in your tree would be feasible.

AvK: So we should close this, and if needed get a new issue

RN: We need to be conscious in the future of what this does.

HI: sometimes, people complain that we need a new API, so they get a slot inside the shadow tree. Want to know the exact location in the shadow tree of the focused element.
... object to changing the activeElement - if the use case is strong enough we should provide a new API

RESOLUTION: We would prefer a new API to changing .activeElement

Unexpected upgrade timing...

AvK: If the custom element comes first, does the script see it in an upgraded state or not?
... we could make it happen by flushing CE queue before executing the script.

DD: Makes the spec ugly, but seems like a good thing to make it work

Avk: RN said there were other cases...

RN: any event that is not script-triggered, there could be queues open at that point.

DD: They should be emptied by then.

AvK: e.g. user pastes custom elements?

RN: Yeah. User press enter, and you clone/insert elements, if any are custom, there are things pending, ...

AvK: So user presses enter, we fire keypress, are the upgrades done?

RN: Press enter. editing command starts, and then deleting an iframe makes a mess. Because editing.
... it is a very edge case. But I ran into that edge.

AvK: A test (or lots) would be nice...

TOC: Inclined not to change the spec. Current behaviour is reasonably well-defined and reasonably explainable.

AvK: Script execution in document fragments isn't.

RN: We cannot guarantee in some edge cases that custom elements are upgraded in time. If we change this, but not every edge case, we might leave authors in a mess.

AvK: If we change this, we would make it before we enter JS engine we empty the custom element stack. It is a big change, and weird either way.

TOC: I prefer the behaviour resulting from making the change, but not sure that the cost of the change is justified.

AvK: prepare to run a script, ... whenever you go into the JS engine it would empty the CE queue.

DD: And update stack to account for push/pop is no longer symmetric.

RN: Mutation events will need clearing the stack. And even better - we skip mutation events by checking if things are listening. So whenever there is an opportunity to fire those, we have to do the work.

[a general lack of love for Mutation Events]

TOC: A component in current browsers and after this change is going to make a mess - I would have to do the work both ways...

DD: For a while...

RN: Can we even spec "do the upgrade => empty the queue"?
... What if an extension observes stuff with mutation events?

AvK: That seems more dangerous.

TOC: Current behaviour is not ideal...

RN: I am increasingly inclined to stay away from this.

JF: The example isn't far-fetched...

AvK: We can make that work...

RN: Whenever you use custom elements you cannot be sure they have been upgraded.

[are there cases outside editing where this happens? RN sure there are...]

DD: Hitting a </script> you run microtask checkpiint in the parser. That makes me feel better about making this change.

AvK: Before the microtask, where do things fit in? Do we empty the queue before or after the script executes.
... empty custom element queue, empty promise queue, then run the script...
... so if you append a script element you empty the microtask queue. that would be a change (matching what happens in the parser).
... seems a little risky.

RN: But documentfragment behaving differently from the parser is not nice.
... This change is very hairy...

JF: When you appends script, when is microtask check?

AvK: never...

TW: So authors cannot control the upgrade of an element...

DD: We have another proposal for manual upgrading, maybe that is the solution.

JF: You manually upgrade, and then you force microtask check, and then insert.

TS: What about inside a shadow root?

DD: Same.
... so you want my "enqueueMicrotask" ...
... Clean solutions are "do nothing", or "say we want the world super-clean before running a script element". That would mean emptying all the queues before executing a script. Not crazy...

RN: Not crazy, but a scary change.

DD: Would mean inserting script makes a synch microtask check.
... Yuk.

AvK: not in *my* example :P

JF: Is there a reason not to offer a function that flushes the microtask queue?
... other use cases: lots of elements render on a microtask. Sometimes you need to wait for all that to finish.
... currently you have to thread promises up the tree, which is expensive.

DD: If you give people an afterMicrotask, they will want afterAfterMicrotask ...

RN: If you expect things to be done and then schedule more work in microtasks, you will have a bad time. Use a promise or something...

JF: Would like an API for nodes to say "I am waiting on asynch stuff"...

RN: Better approach is to require an event, and wait for it.
... maybe when we get to :state that might be useful too.

DD: Manual upgrade is off the agenda because we are just waiting on me to actually write the spec.

RESOLUTION: No change.

[And we feel bad about that but the alternatives are worse]

Fullscreenchange

RN: issue is fullscreen event only fires on document level, not good when it comes from inside a shadow.

AvK: The host neets to match :fullscreen, exposed outside shadow.

RN: If you are fullscreen you need to know which node in your shadow is fullscreen. We only fire on document, so you only get the host.

DD: So this is about fullscreenElement, not the event?

AvK: The event is problematic where you already have something fullscreen - but then there is no event.

RN: Given lots of shadows, each fullscreenable, you have a lot of listeners.

DD: But that's the same with no shadows.

RN: So I suggest we fire the event on the element that got fullscreen and make it bubble.
... think we don't fire on document because fullscreenerror doesn't have a target.
... It is better to have listeners on thousands of nodes than thousands of listeners on a node

DD: Not sure this should be a shadow-specific solution.

AvK: Compat? Maybe that isn't a big problem.

RN: We already have a webkit-prefixed one like this.

AvK: OK...

HI: Sounds good to me...

RESOLUTION: We do what Ryosuke says...

Attribute names conflicting with built-in names

TS: Came from a discussion in React. We have never been discouraged from using any attribute name we want. SHould we discourage that?

DD: We have to do compat analysis introducing global attributes. It is fine for autonomous elements, but for customised built-ins, use data-

RN: Making recommendations on names guaranteed to be safe - e.g. have a dash and there are only a handful of possible clashes (data-* and the half dozen legacy cases)

JF: This is also an issue for frameworks.

RN: Think it is useful to say this clearly to authors, helps everyone avoid each others' toes in the future.

AvK: Should we stop allowing names without a dash?

DD: global attributes always require compat analysis

TOC: That is true, but it would be good to say "even so, use a '-' in something"

RN: Why not just apply the same to attribute names that we did for element?

Avk: Or we declare that we will always use something that people can avoid.

TS: I am happy to run the risk...
... as an author

TW: [nods]

TOC: Not worried about an author maintaining their work. Worried about something that becomes a legacy system - they should use best practice.

RN: We have a painful compat bug with MediaWiki, because compat analysis isn't reliable enough to be our primary strategy.

<MikeSmith> https://github.com/whatwg/html/issues/2271#issuecomment-273716582

<MikeSmith> https://github.com/whatwg/html/issues/2271#issue-201312087

[discussion of whether people are going to change if the validator flags an error on dashless attribute names]

MS: We could do this - we have to do it for attributes not inside custom elements.
... never heard a complaint about not getting a warning for bad attribute names.
... If we err on the side of emitting an error, there are ways to filter those out easily.
... I would like to optimise for getting fewer bug reports on the validator. The problem with using data- is you start to get conflicts on that.
... so we get people namespacing data-, but data-name- doesn't seem like a huge level of pain to me.

DD: We should instead invent custom attributes, and then you could find them because they would be registered.

RESOLUTION: Consensus is hard, let's do lunch.

After lunch...

AvK: Let's do a show of hands on issues needing implementor interest.

Lunch. Break for 1 hour.

<annevk> Needs implementer interest, oldest first: https://github.com/w3c/webcomponents/issues?q=is%3Aopen+is%3Aissue+label%3A%22needs+implementer+interest%22+sort%3Acreated-asc

"Define should take a template"

RN: We are interested

JF: seems like a sub-issue of declarative custom elements.

RESOLUTION: There is interest, but in the situation where we get declarative custom elements.

"ARIA custom API"

RN: This is the AoM issue?

DD: yes.
... We should close this and move it to AoM.

RESOLUTION: We will hold this as our tracking issue, but we need to do this with AOM people

"Callback for {clone,import}Node"

DD: Remember thinking "yeah we should probably do this"...

RN: Don't understand the proposal

DD: There is an old element, new element, you can transfer data between them.

RN: There is a longstanding inconsistency in browser behaviour

JF: If we added the callback, would we recommend copying the variables?

RN: canvas doesn't copy its backend. Input clones most of its data.

TOC: The platform is pretty inconsistent in this

DD: Anything tied to a public state - content attribute - has to be cloned.

RN: Why *does* input have this weird value thing? Seems like an anti-pattern and we should not encourage people to copy that.

TOC: So all future things are consistent with canvas.

DD: Script elements - if we did it today would cloning mean you rerun it?

PK: We weren't interested in this, and don't see anyone else.

RW: When you write a component you can figure it out.

RESOLUTION: Close this - we don't have, or want, partiy with mistakes we made in some native elements.

"Better custom event support"

AvK: Mozilla are not interested

DD: in the future when decorators exist, would be nice if the browser provided nice builtins. Until then, not really...

AvK: This is about event handlers really.

RN: Sure
... but we could do this without decorators.

DD: Yes, and reflectors...

TOC: If the answer is "with decorators you will be able to do this even more easily", we can close this now.

DD: Maybe we will revisit in the future...

<inserted> JF: Think we should avoid API-induced properties, because they break static analysis

RESOLUTION: Close for now. We might revisit it later...

"child(dis)connectedCallback"

<Domenic> Check out my code https://github.com/jsdom/jsdom/blob/master/lib/jsdom/living/helpers/create-event-accessor.js

AvK: We keep dismissing this...

JF: It is cumbersome to do this as an author

RW: You need a bunch of mutation observers

RN: This keeps coming back. Maybe we should look at it...
... but it is expensive.

AvK: How much demand is there?

JF: You see it when you have wrappers.

RN: This would be useful when we have imperative slotting.
... we shouldn't solve tis without that. So close it and discuss as part of imperative slotting. Which is hard to figure out.

HI: The hard bit is how do imperative and declarative bits interact.

DV: We would like to have imperative slotting - so to explore it.

RN: Right. But we need to find an API that will work.

TW: That is why we need to deal with declarative shadow DOM.

DD: Think we should have and imperative way to do both shadow DOM and slotting, nor a declarative way

JF: What's the reluctance about?

RN: Performance

JF: But if people need it, they will implement in script. Which will have the same problems, right?

TS: I can live with this staying in libraries

PK: Seems like this would be great, but until then it's not a priority

DV: problem of injecting components in libraries there is a problem because there is no imperative slotting.

RESOLUTION: Might be nice but we don't know how to do it and it isn't a priority

"Retrieve local name"?

RN: We are interested

AvK: We would be OK.

DD: I recall being skeptical.

JF: This is on the CE registry?

DD: There was no use case except working around React not using constructors

TS: It isn't just React.

AvK: There are various use cases in duplicates.

RN: The issue is libraries supporting Web Components, not component authors themselves.

DD: Skeptical, but Anne's points in the thread are reasonably compelling...

RN: This has a lot of dups, and is a small thing...

AvK: If we make this a general thing we need to have it more general than just custom elements.

[argument over whether this is custom elements only, or built-in elements too]

RESOLUTION: There is some interest, but we need to figure out an API shape to agree on.

"Base URLs of shadow root"

AvK: This is a lot of work, and doesn't quite solve the problem.
... scripts will run in the document's scope. So that will make a mess.

JF: Ties to scoped CE registry. Give the element creation APIs to shadow root.
... We talked about this in context of HTML modules. Document fragments don't have a base url...

DD: That doesn't change that this won't fix the script problem. So do we still want to solve it?

JF: Yes.

[RW nodding]

DD: If you do the resolution, then yes.

RN: Think we can solve most issues here, but then we open up a pandora's box.

TOC: You need consistency..

AvK: Do we solve this through service workers?

DD: But service workers don't work on first run.

AvK: If origin policy succeeds we can solve that ...

RN: I would like to solve this as part of HTML imports.

RESOLUTION: We might solve this as part of HTML modules, but not for now

"Prototypes need to define callbacks as no-ops"

RN: you can't call super.whatever.callback

JF: We write a lot of reusable mixins. They don't know if you have a method to call, so have to check

JM: While cumbersome we find mixins have to be defensive anyway.

TW: [nods]

DD: If we put these there, reading code would lead to bad ideas.

RESOLUTION: No interest. Javascript optional chain would solve it.

"Custom void / self-closing elements"

RESOLUTION: No

DD: Self-closing should be a property of tag name - white list e.g. by including "!" in tag name

"Nested lists"

RN: There is a fair bit of feedback from people wanting this....

TOC: Would prefer to say no, but maybe we should look at this.

RN: Could use Domenic's proposal for "!"

AvK: If we change XML parser to be forgiving, we could do this there.

[does this have a benefit that justifies the cost?]

TOC: This is not a *huge* risk...

HI: We could do this I think, not a lot of concern
... when you get the spec right.

AvK: Henri is probably opposed...

PK: This seems plausible...

AvK: If you ship, we will probably align.

RESOLUTION: Interest but nervousness about dealing with the parser...

JF: Similar to getting rid of foster-parenting inside templates...

RN: That is a harder change to make.

"Allow custom elements in any namespace"

TOC: Probably a good idea

JF: SVG is the huge usecase.
... to write SVG components

[what happens when SVG meets shadow roots?]

RN: Probably a good idea to do this
... "mild interest"

HI: I cannot imagine the complexity here, so cannot say yet.

AvK: We would have to redefine constructor...

PK: We are unlikely to want to do this.

RESOLUTION: There is mild interest and opposition.

"HTML Modules" - dedicated topic already

"Imperative upgrades"

DD: We should do it.

RN: Agree. We need a concrete algorithm...

RESOLUTION: We want to spec this.

"Element registry" - dedicated agenda topic

"Bulk updates"

JM: We were looking for a way to update a lot of elements at once. Letting people create data to describe the updates they want.
... wrote up a proposal, here it is.

RN: Think there is a problem with JS attributes in custom elements, there are different usage patterns in the wild and we should think about how to support them better.
... I don't use attributes, myself, to avoid serialsing stuff as string. It is an awkward pattern

TS: It is so easy to pass structures in objects.

JM: That was the motivator for the proposal.

JF: frameworks want domchagelist but implementors not so much.
... how do you take a buld update description and apply it without jank...

JM: Different approaches to DOM seem odd - I can manipulate classes, apply a dictionary to them, but setAttribute is different. Rationalising this would be nice...

RN: There are many framework authors, would be nice to share how they work and how we can solve the use cases. I don't think we support you well on this yet.

JF: Wanted a lot of DOM APIs to be maps and sets.

AvK: That gets messy fast.

JM: This might be better as a broader effort of looking at what pain points frameworks meet.
... should we do this in that context tomorrow?
... so close this, and then schedule time to look at how frameworks can better provide input.

RESOLUTION: close this, discuss batching things as part of pain points for frameworks

"interface/class based selector"

DD: Seems impossible to implement
... implementing :hover, etc, seems to deal with some of the use cases.

AvK: Don't have much interest in this.

RN: Ditto

PK: Don't get to the level of caring.

RESOLUTION: Not really.

"named slots, slot attribute requirement"

RN: This is imperative API

HI: This can happen, wondering how to combine imperative and declarative world.

AvK: Everyone wants to do imperative if we figure out how to solve it well. Is anyone intersted based on localName?

HI: Given a good imperative API, I don't want another declarative one.

RN: We are interested, Google doesn't want it, let's kill it...

RESOLUTION: No, we want to figure out imperative API

"has='' attribute"

AvK: JS doesn't have mixins yet, which is why we didn't want to do this. If we got that, we could use it.

TW: You cannot do customised built-ins really...

RN: You want a new global attribute for behaviours - this is a dup of that suggestion

JF: People thought they could use is= from their custom elements, but no. This would let them achieve that.

RN: Yes. Which makes it the same thing as custom attributes.

<tomalec> https://github.com/matthewp/custom-attributes

RESOLUTION: We won't adopt this proposal. JS mixins might help, custom attributes is an idea hoping for a spec and implementor interest

":hover, :active, etc for custom elements"

covered by :state

break: 15 minutes

Pseudo-classes

https://github.com/w3c/webcomponents/issues/738

DD: I found three ways to do this. The last one is the nicest.

<rniwa> The proposal is at https://github.com/w3c/webcomponents/issues/738#issuecomment-367459656

DD: this would be the first DOMTokenList not connected to an attribute.

AvK: Need refactoring?

DD: Not in the spec, but implementations will.

JF: We tend to use attributes now so the host can do host-styling. They don't need to be exposed externally.
... wonder if the level of visibility should be the same for both states

DD: Internal state you don't want to expose for styling purposes.

JM: expanding component with a custom state?

RN: date picker, with some intermediate private state.

AvK: Private state seems like a parallel structure.

DD: you could have wrapper elements

AvK: Yup

RN: Is there a need to put the state on a shadow root?

JF: Performance - don't create things you don't need.

DD: Are there examples with simple elements need private state?

JM: Do we need private state in v1? We want something better than classes at least.

RN: Not sure there is a performance impact- cost of extra elements is marginal.

TW: Do developers need to create a shadow root to consistently expose a state?

JF: element.states is internal, shadow.states is internal. We should be consistent in adding ways to do this.

AvK: We cannot explain existing pseudos that way.

DD: Feels like styles, AOM, ...

AvK: Form controls...

DD: Everything starts with "shadow root is the way we are going", but then we want to make it easy whether there is one or not

RN: Better to optimise browser than adding a new API.

JM: All the interesting cases we already have a shadow root

JF: You need it as a hook for your styles.

[DD scribbles proposed code onscreen... to be added in later]

RN: you add things in the constructor?

@@: can you use private classes?

DD: Yes but then you cannot call it

AvK: There are ways to make this work. Is it the way we want to go, or do we say Shadow provides encapsulation.

DD: We can say "do it for shadow, later we will figure it out". Need to figure out for builtins.

RN: Don't think this addresses private state in component. Do we want to allow that? Should we add an API for it?

JF: You would need a different selector to select internal state.

DD: Sounds like we should try and do this for now, and then a separate question of should we do private state?

RN, PK: Yep.

OP: element.attach states, pass a dictionary? private or open

DD: If you can access it through CSS it isn't that private?

OP: anyone can read it, but others cannot change them

JF: Yeah, something similar.

RN: We had a similar discussion on AOM, we didn't want to have 20 different objects to attach and manage.

JF: New APIs on shadow root so they are exposed to the ancestors, or to ensure encapsulation?
... this question is important and would be good to be consistent.

DD: Styles in the shadow tree are sort of a precedent.

RN: states is not something exposed on host. Trees expose public API outside - explose list of slots, ...
... state is a public API of host.

DV: We have a lot of components, and we want to have styling that does not leak outside. Some have no children.

JF: To set style on state of children, you should use classes, right?

RN: Can elements override builtin states like :disabled, :active

DD: I don't want :hover to be messed with, but :disabled I do...

RN: Disabled might be special

DD: You should not be able to override :defined

AvK: Think we should do magic on the side^W^W^W^Wbuiltins separately

DD: We have states on the host, and we could have a different "privateStates" there too.

AvK: How do private states work for selectors.

RN: You do :root

JF: but then you don't need a separate name for private states

AvK: So where do you match the state?

DD: Reflect from shadowroot onto the host?

AvK: yeah...

RN: We would need some spec work to handle private state

TOC: I would like to deal with public stuff first, and then deal with private state

JF: Every time I hear that it is for private state.
... they use reflected attributes in the meantime but don't want to.

JM: Reflecting is ugly, but I don't think the existence of the state being visible is a big limitation.

DD: Dialog and details broke with long-standing tradition that user actions should not change attributes.
... is that the new style?

AvK: Forms has a reset.

DD: Details has close() that removes the @open
... should people use that pattern, or this new state thing?

AvK: Think you want to have states...

DD: Why not make disabled attribute work??

AvK: so you control whether you are disabled.

DD: So, we do the public thing, on shadowRoot.

[bikeshedding...]

DD: should we be less verbose than :state(foo)

JF: Like that. Matches :part()

JM: Would love to be able to see custom states in dev tools...

[bikeshedding on nice things like this for dev tools, and where they might be implemented]

JM: Tooling support can make it nicer to work with custom elements.

DD: Where do we do this?

AvK: Could be done in DOM.

RESOLUTION: We want :state() pseudo matched on host, with public API on shadow root. We want private states, but later.

scoped custom elements

DD: [ mutters darkly and laughs menacingly ]

JF: [couple of slides]
... you can use lexical scope in a framework to get a definition, call it what you want, and decide what definition you render.
... trying to offer this for custom elements. slide 2 import registry from common module, define your element on that registry, then custom element can render the element by tagname without colliding with another definition of the tagname.

[this is issue 716]

scribe: [sl.3] you get a tree, look up a registration in the tree.
... [sl.4] attaching a shadow allows you to specify a registry with a new option
... [sl.5/6] scopes for element creation.
... innerHTML etc also get scope, so element needs to remember where it was created.

AvK: If you move the element it keeps its scope?

JF: Yes.
... that's a question...
... my proposal is yes [sl.7/8]

RN: Why keep scope?

JF: for simplicity. Do you look up innerHTML in the tree? If you have a scope it stays having it, seems simpler. Would defer to implementors...

RN: That seems way more complicated to implement. Afraid we would leak all the shadow roots we ever create.

JF: Or keep reference to registry

OP: That makes more sense.
... shadowroot.registry.createEleement

RN: Is there a use case where appendCHild wants to keep scope?

JF: Don't think there is even much use case to move an element from shadowroot to scope. This is just defining what happens

RN: We should match what we do in iframe

JF: Sure. Don't think this is a common enough feature to matter

DD: Don't think it matters so much...
... scope can be associated with position in tree, or element. And same for iframe.

AvK: We move scope when you move from iframe...

DD: Ah, OK

JF: What if you do weird things? Define element in parent registry, create element in child, define element name in child.
... think you never downgrade.

AvK: Can you register an interface multiple times?

JF: You would need to create trivial per-registry subclasses to put in multiple registries. You cannot have same constructor, can have same tag name.

DD: Why not?

JM: Where a library exposes a class, I register that as foo, some other script registers it as bar somewhere else.

JF: What scope do you get when you call new X...

DD: What localname does it get?

AvK: We already need to define that.
... should only work in the global registry.

JF: Seems unfortunate.

RN: module is shared across multiple modules. Or if you have two modules doing that...

JF: You can make subclass to do it. Automatically...

AvK: Think it is better if you can always register

RN: We could do something make last registry gets re-used.
... constructor bit looks tricky

AvK: would be nice if we could write CSS to match these...

TW: will trivial subclass break getting name by constructor?

JF: Yeah...

RN: In theory you could make some magic to get that
... Would not like it if this requires that child registry needs dynamic reference to parent registry

DD: That makes global registry useless for the shadow root from then.

RN: Yep.

PM: We load components on demand, defined in a database. Cannot define them all in advance.

P-M: We have global components, local sets of defaults to include by default, and bunch of components to lazy-load.
... Using hierarchy, we can define Xlocal-lazy and run into issues.

TW: You don't want Xglobal lazy, you want the registry at the beginning to be lazy.

DV: It's versioning. Can we have a low-level API give a hook to resolve a class and decide where to do that?

JF: Think these are seperable ideas.
... imagine registering is with a promise.
... that's lazy. Then generic function, and any custom element name calls a function to load the class.
... Could add this separate to scoping

RN: So wyy does registry need to dynamically update parent registries. If a tree of trees gets into a mess, it becomes unwieldy...

DD: inheritance heirarchy here is separate from teh DOM. Or you could do it based on position in DOM, but makes not inheriting harder.

RN: Want inheritannce to be boolean, and based on location

JF: Sure, I didn't go that way because I thought it might be slower but don't mind.

P-M: if you move an element, does it upgrade?

JM: Do we need something deeper than custom and global? Do you need inheritance?

JF: Some of this is for large uncoordinated application. Registry tree looks like node mudules tree, conflicts leads to multiple branches.

AvK: Sounds like there is interest, needs to be made more complete.

JF: Think this is one of the last major complaints we have had.

AvK: Think this will help with HTML modules, too.

RN: Is it more important to have a single constructor in multiple registration, or be able to call new(blah)

RW: bigger use case is registering two different classes to the same name.

JF: Is autosubclassing crazy?

JM: Feels weird.

<kochi> Tonight's dinner venue is: https://tabelog.com/tokyo/A1307/A130701/13028566/

<kochi> Starting 18:30.

<kochi> We'll walk to there.

<kochi> After tomorrow's sessions, there is a community event of web developers about template instantiation https://web-study.connpass.com/event/80198/

<kochi> If you are interested, feel free to join there, the venue is this building, but on a different floor.

<rniwa> https://public.etherpad-mozilla.org/p/web_components_agenda

Accessibility / AOM

RN: We had the idea to create an accessibleNode exposed on element / shadowroot. So shadow.role = ...
... there was a pushback to creating a parallel tree. So we plan to add aria-prefixed attributes on shadowroot (or elements)
... and they all lived happily ever after.

AvK: is there a convenience API?

RN: There are defaults. If you write a custom today, you have to set the aria- attribute on a host element, exposed to the outside world.
... no good becausee you want the author to be able to set that in the component.

JM: For children, you have to set aria stuff in the light DOM e.g. to note there are some enabled.
... that goes away?

RN: properties like aria-describedBy can come from shadowroot.ariaDescribedBy
... the referennce can cross shadow boundary.

DV: Reference ids would not cross boundaries - is that no longer the case?
... you have label in button internally, from outside I want to add a describedby.

RN: Don't think you can do that.

DV: Our team raises that as a big problem. We have a proposal, but that we don't like it. We were thinking of reaching out to the parent...

RN: You can pass an element object for the describedBy. we need to provide a reverse reference, but it doesn't exist today.
... violates layering...

DV: OK, we will follow up on AOM

AvK: builtins are a bit special still.

TOC: Yes. That's OK

<diervo> Here is the link

<diervo> https://github.com/WICG/aom/issues/107

<diervo> for the issue about describeby

AvK: There is no proposal for custom elements to get default roles and states/props, before we get AOM sorted.

RN: First we need AOM.

AvK: OK, so we can close #159.

CMN: What is the use case for pointing into one?

TW: A customised label element, acting as a label for a normal form control.

RN: We would need to add an API that makes this work, but we could do it.
... Might be worth filing a separate issue.

DV: Are you settled on naming convention yet?

RN: We don't have accessibleNode anymore, it will be a bunch of properties like ariaThing ...

DV: We want to help on the spec. What is the default value, ...

DD: You need to define these better.

RN: Think we are prototyping this right now.

<Domenic> diervo: https://github.com/w3c/aria/issues/691#issuecomment-367878962

<diervo> thanks!

Form integration

TK: wrote API for form participation...

<rniwa> tkent's proposal: https://docs.google.com/document/d/1JO8puctCSpW-ZYGU8lF-h4FWRIDQNDVexzHoOQ2iQmY/edit?usp=sharing

TK: one API for arbitrary object participating in forms, and an element-specific API. The reasons is we cannot provide API to be used easily in HTMLFormElement

<kochi> Issue is https://github.com/w3c/webcomponents/issues/187

TK: should we support non-element participants?

TOC: Yes

DD: Why?

[tkent gives example]

TK: reason is to avoid using <input type="hidden">

TOC: It lets you pass along information without having to use input type=hidden more nicely.

DD: Not worried about children. It collects associated elements

TOC: This collects participants, which is a superset.

JF: Wouldn't this make multipart formdata easier? You don't need to bounce stuff through a file input.

RN: When a non-trivial app wants to submit stuff, they change based on server state. So now you mess with dummy and dynamic hidden elements.

DD: I don't hate this, but I really like API proposal B.

TK: I think we need both A and B.

JM: Can you do this just with events?

AvK: If we expose the object anyway, why not just hang it off submit event?

JF: How do participants get the event?

AvK: Listeners

TOC: If you are adding at submit, what about validity?

AvK: For non-elements you already didn't get that.

PK: I like it.

AvK: think participants adds a layer of complexity, and this avoids it.

PK: what happens if you submit, to the formData

AvK: regenerated each time the event fires

DD: note that submit event is not fired by submit().

AvK: But changing that might be easier than building a whole parallel API

DD: Where do you put the validity marker if you are invalid?

RN: customValidity needs a hook to show where the message gets rendered.

DD: Event-based sounds likely, some people still have some reservations.
... what I like about proposal B is the custom-element joins various kinds of elements. You need an element to do that...

TK: [proposal B]

TOC: Really like proposal B, and want both of these things.

DD: Why participate? You can send the data along with the formdata.

RN: One thing I dislike in B is not wanting to ivoke the callback when checking validity.

TK: I had this too. think setCustomValidity is enough.

CMN: reviewing what is getting submitted is the use case for knowing what participates...

DD: Inspect formdata

CMN: But how do you know that you are inspecting the data that gets submitted?

JF: If we want to report that an element has certain qualities, should this be like AOM.

AvK: That's why I thought about shadowroot. And this doesn't provide encapsulation - someone can invoke your callbacks

DD: You can delete them.

RN: All the callbacks are not called when CEReactions happen.
... seems to address use cases, but feel like we need to differentiate these from other things at CEReactions or it is confusing.

DD: Name of callback says when it happens. Roughly...

JM: Not sure I would find formResetCallback all that confusing...

RN: Sure. But not sure this is a path we want to take - especially without thinking about this approach... because this is a new thing we're doing.

AvK: With shadowroot you can require immutable name at creation

RN: Yes, but ditto with custom element creation.
... So how do the elements associate themselves with a form? Using name attributes (another proposal) needs an optin

DD: Opt in is implement one of these callbacks.

AvK: form attribute won't work...

TOC: like the problem we solve in the AOM

DD: Doesn't pierce shadow ...

TOC: Could be made to work

JF: If you make a form, participants should be in the light DOM

AvK: Doesn't work with tables. The reason for having form elements

RN: custom elements want to get properties that form builtins also have. validity, ...

DD: Move them up...

AvK: But that will break stuff

RN: Or force extending HTMLFormElement

JF: Requiring a different base class would force libraries to vend mixins.

DD: It is a pretty popular pattern in some communities. We cuould put mixins into the platform and be done.

JF: My proposal is sugar for a subclass factory

RN: If this turns into mixin, you should be able to create and object and make it submittable...

DD: We are mixing in validity methods and properties.

AvK: It is only designed for elements.

DD: Propose that we try to spec this, and test it, and see if it works.

RN: This is a tricky area, because different browers handle stuff differently.
... I would prefer having data submission specified first.

TS: How do you prevent submission if there are no validity callbacks?

AvK: Hope nobody invokes submit.

DD: Unless you have beforeSubmit

RN: Validation check is a can of worms.

AvK: if we do the beforesubmit then everything can be prototyped on top of that.

DD: label works in proposal B

OP: When do we call these?

DD: we move setcustomvalidity on the HTMLElement

AvK: The event thing is very easy, and can be done fast. The other one has some questions of shape and stuff...

DD: Let's do both. form{data,reset}callback are new, if you have any of them you get added to stuff, and we don't do validity or .form yet.

RN: Setting custom validity message must explain where the message is shown relative to the element.

RESOLUTION: expose beforeSubmit and formdata is low hanging fruit.

We have a consensus of Domenic on also implmenting and specifying proposal B...

AvK: Is there an existing formdata, what do we do with that?

DD: So you can delete things from formdata.

RN: When you have beforeSubmit you recreate the formdata...
... the ugly thing about beforeSubmit is when there are timing competitions...

[adjourned]

[Except for dinner - thank you Google for hosting]

- DRAFT -

SV_MEETING_TITLE

05 Mar 2018

Attendees

Contents