SV_MEETING_TITLE -- 17 Sep 2019

<annevk> Scribe: Travis

Introductions

<scribe> Scribe: jan

<Travis> :)

<Travis> jan: There was a q from apple; wanted to see an example of :part being used in practice....

annevk: Mozilla has implemented a subset of ::part

rniwa: i think the contention was on forwarding

fergal_daly: the declarative syntax is the spec is what’s agreed
... the declarative map had agreement

tess: moving on to custom states

<rakina> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/custom-states-and-state-pseudo-class.md

rakina: curently we’re proposing just custom states, no built-in pseudo-classes

<tomalec> Rakina, could you please use the mic?

annevk: is there syntax incompatibility

fergal_daly: the same issue applies to part
... you can specify a ::part you can’t select in CSS

rniwa: should this be a thing for custom elements or shadow roots?
... ... would it be possible to have a custom element without shadow root that has a state?

annevk: if we had ElementInternals before we had attachShadow, we would have put attachShadow on ElementInternals
... so now we have this disconnect, and each time we have to decide where to put the API (ElementInternals or shadow root(
... for new things, we should prefer using ElementInternals instead of shadow root

rniwa: do we allow pseudo-classes on a ::part?

diervo: we opened a bug

fergal_daly: yes, they don’t all work, but most of them do
... Tab said it should work
... I think he said he updated the spec

<diervo> https://github.com/w3c/csswg-drafts/issues/3510

chrishtr: I think having custom states was the #1 request on top of parts

<annevk> https://drafts.csswg.org/selectors/#pseudo-element-states

chrishtr: Is SalesForce using ::part

diervo: we will once there’s agreement that it will be implemented
... is ::part going to be the way to style new things (e.g., toast(
... it’s hard to do static analysis to determine the API for a component
... it can be problematic if you can do anything you want to a ::part
... while parts work well for built-in components, we’re concerned we’ll have to forward all the parts
... we’re looking at ways to control what people using parts can do.
... E.g., we think themes gives too much power
... We’re fine with parts, but we’re still looking for a better solution to propose

<Travis> jan: as far as static analysis...

<Travis> .. for parts, I proposed a way to ask an element for what its parts are?

<Travis> .. is there a similar thing for states?

<Travis> .. can an element expose its states programmatically?

<Travis> .. would be interesting to expose a public/custom states to see what the full set of states are.

<Travis> rakina: Sure, it's doable.

<Travis> annevk: you can implement this yourself?

<Travis> .. so far we haven't done that.

<Travis> jan: I think its useful to anticipate cases... (we offer reflection in the process already)

<Travis> .. these are generally good practice, rather then expect the component author to expose

<Travis> hober: its an internal fact that the component is in the state...

<Travis> jan: This proposal is about the public state... by adding to state's internal, you explicitly say "I want the outside world to key off of this state"

<Travis> .. private state is tracked differently...

<Travis> .. so this proposal is only about public states... why add it here and *not* want someone to know about it.

<Travis> rniwa: too early to judge what the right thing to do here?

<Travis> .. if other libraries are trying to add then we can make changes.

<Travis> .. for static analysis, it doesn't help to expose JS aPI--it needs to be declarative.

<Travis> .. hard to say what the right API is for the use case.

<Travis> .. bottom line: too early.

<Travis> fergal_daly: you just set a state; there's no list of values

<Travis> .. in Chromium, there's nothing that tracks all the parts; takes a tree walk to figure it out

<Travis> diervo: we would restrict the use of parts to be explicit, so we try to be explicit...

<Travis> .. we would probably disable that anyway.

smaug: if you are in multiple states, how to you select that

rniwa: is it :state(foo):state(bar) or :state(foo bar)

fergal_daly: the question is whether you want to do AND or OR

rniwa: Let’s not create a new OR

fergal_daly: So the proposal now only allows a single state

annevk: Yes

rakina: Yes

fergal_daly: Tab updates the ::part spec, specifically to get the OR effect

<smaug> https://github.com/w3c/csswg-drafts/issues/3502

tess: Maybe we should drop that

rniwa: What does that mean, especially for ::part

fergal_daly: I’ll ask Tab why he did that

annevk: I think for ::part, a single part can consist of multiple parts in a single value
... Example, if you want to select an active tab, you’d want ::part(tab active)
... I think that’s a leftover from before we had custom states

fergal_daly: I’ll ask Tab to remove that
... You said we wouldn’t put this on non custom elements?
... If we *did* allow this, then several of the existing pseudo-classes could be done as states
... If you allow this on built-in elements, then you’d eliminate the need to introduce new pseudo-classes

rniwa: It’s good to keep custom states and built-in pseudo-classes in separate namespaces to avoid future name conflicts

hober: any more comments on the proposal?

annevk: spec it and test it

rniwa: what’s the question in spec about —foo?

tab: the reasons ::part can take multiple args is because parts are supposed to be equivalent to classes

annevk: but I think now that we have custom state, we don’t need that

tab: if we’re definitely pursuing state, then we could drop support for selecting multiple parts in ::part

hober: part is more like element names than class names

tab: the reason why I’m uncomfortable with dropping this, without this syntax, there’s no way to select something that has two part names — that lets you select both
... given that people use multiple classes all the time (.foo.bar), I think it suggests we’ll want this for parts

rniwa: we could add it later

tab: the cost is low to support this

annevk: I think I’m somewhat convinced to keep this

rniwa: calendar example: in a calendar grid, you might want to reference days in various ways: by day of week, by week number, weekend/weekday
... you might want to have a single element that acts as multiple parts
... but you probably only need to select an element as a single part at a time

fergal_daly: holiday example: you want style calendar days that are holidays, and days that are holidays-on-a-weekend

<heycam> RRSAgent: pointer

https://github.com/w3c/webcomponents/issues/738#issuecomment-486897992

<annevk> emilio: https://github.com/w3c/webcomponents/issues/826

<diervo> scribe:

<diervo> scribe: diervo

emilio: we didn't implement forwarding because we were unclear

fergal_daly: it was consensus on the syntax

rniwa: the syntax might have to change due to the multiple part selector

fergal_daly: Wouldn't that work anyway?

riosuker: You can't define a forward as a singlely named part

rniwa: Jus because it works doesn't mean its suficient
... maybe we should be able to forward a multiple part as one

hober: I can see how coalescing forwarded parts might be useful

tab: we could add grammar but it will make things more complicated

rniwa: we should have parity ergonomics for multiple part syntax multiple forward syntax

tab: the syntax seems easy to introduce
... the mental model for forwards was meant to be similar as desctructuring

hober: seems like a super set and that seems fine

annevk: seems like a reasonable addition

rniwa: today gecko supports only parts without multiple parts and forwarding

delegate focus

rakina: Focus navigation today uses sequencial focus navigation which has certain constraints
... the javascript focus method will only look at the tabIndex and that might not be sufficient
... we want to change the focus delegation for hosts that have delegate focus, for cases when we call focus method of by clicking it

<rakina> https://github.com/w3c/webcomponents/issues/830

rakina: but we want to keep the semantics
... of the old behavior

rniwa: any concerns?

ekashida: we would love to have an api for now what can be focus

Domenic: the problem is that those apis are platform specific which is tricky

Emilio: Also the problem is that some of the focusability depends on the styles (it might need force style updates)

Domenic: not sure if we should design this API, but is worth discuss it

rniwa: Would people care about what element get focus?
... First click focusable

ekashida: As per the for overriding the default, nobody has asked for that

<rakina> https://github.com/whatwg/html/pull/4731#issuecomment-529324420

Domenic: Consensus on what gets focus by default focus for click and programatic

Emilio: depending on where the rule comes from (from inside the shadow or outside the sahdow) how would that work?

rniwa: we might want to do :focus on the host for style the whole component

Emilio: :host:focus-within
... focus within will match

rniwa: we should match :focus
... for the outside

annevk: Does css has good ways to describe context?

Emilio: The input of selector matching is a list of trees

annevk: how the spec will work?

hober: within the shadow rom the host selector we want to be able to focus within so that the coponents can know, and in the outside focus within shouldnt match or doesn't matter

tab: we will have to do some magic but seems doable in spec

aboxhall: I have some arguments against it

Emilio: if you have a global focus rule, even though that its a button focus inside

elisa: Im worry about the focus ring due to interactivity

Domenic: Focus visible will only show it in the inner thing

aboxhall: The thing that has focus is the thing that will take key stroke

Domenic: it seems to be an implementation detail

rniwa: this is very confusing
... the :focus match is orghogonal to the focus-ring

fergal_daly: from the outside a component is one thing, but the reality is that is not
... what about iframes?

rniwa: frames get really wonky

Domenic: I think the mental model seems the same

Bocupp: is the active element from which the host exists, and inside has its own focus

<annevk> data:text/html,<style>iframe { border:1px solid blue } :focus { border:1px solid red }</style><iframe srcdoc="<input>"></iframe>

<Domenic> lol iframes are specifically excluded from :focus despite being in the focus chain

<Domenic> > For the purposes of the CSS :focus pseudo-class, an element has the focus when its top-level browsing context has the system focus, it is not itself a browsing context container, and it is one of the elements listed in the focus chain of the currently focused area of the top-level browsing context.

tab: what is focus-visible can be some sort of part?
... in general we dont want to expose the fact that there is a shadow-root, however parts explcitly exposes the fact that we are in a shadow
... mayb we can auto surface it as deeply as necesary

hober: Im concerned about that part
... parts are explicit, focus might not

<annevk> Domenic: I wonder how that ended up being a thing

<Domenic> annevk: I wonder if it was done for reasons similar to aboxhall_'s reasoning.

hober: encapsulation concerns make sense, but piercing the encapsulation in this case might be needed.
... example about photoshop

<chrishall> note: the projector laptop is complaining about low battery.

hober: if the component wants to do specific focus rings, does the component needs to be smart about it?

tab: yes

rniwa: I don't think we ever going to do a piercing shadow boundary

Emilio: I agree with rniwa
... we have a consistent focus for the DOM, CSS should behave similarly

tab: auto piercing its controversial yes, but it might be justified maybe

hober: is there a particular isssue for this?

rniwa: we should file an issue on the css spec and or html

Domenic: they have spec really well the focusability

rniwa: I think aboxhall concerns are with focus-ring

The consensus in the room is that the focus should always match shadow-host focus-visible rule. We will file an issue on CSS and HTML to track the focus-ring

s/elsa/aboxhall/g

<annevk> scribe: annevk

scoped custom element registries

hober: who did this?

diervo: nothing has changed since the last time, Justin isn't here

Mason: Justin wanted this on the agenda, but he isn't here
... he has an action item to make a concrete proposal
... not sure what we should discuss beyond that

hober: he still has that action item and we're all excited about seeing that move forward

constructable style sheets

Domenic: I have an idea on how to fix arrays

<emilio> github: https://github.com/WICG/construct-stylesheets/issues/45

hober: is there an issue against IDL?

Domenic: yes, it's kinda long

<Domenic> https://github.com/heycam/webidl/issues/796

emilio: I may have opinions

Tab: if we do something in IDL, typed OM will use it

emilio: I was thinking about style sheet manipulation APIs

Domenic: concretely the IDL proposal adds (see issue)

rniwa: would we change something?

Domenic: only new things
... it would mostly have more behavior, but would not have item()

emilio: can you feature-detect?

Domenic: Object.isFrozen()

rniwa: it's not great that we keep inventing new ways of doing things
... promises/callbacks, ways to do arrays
... why?

Domenic: that's why we tried to use FrozenArray

emilio: if I were to design it from scratch I'd add methods to ShadowRoot

rniwa: StyleSheetList

Domenic: options
... 1) we can do something specific for our use case per emilio's suggestion
... 2) or we can do something based on array in IDL

rniwa: why do we have constructable style sheets?

Tab: they want to load them via their object graph, reuse them more easily

emilio/Tab: with <style> elements we can do copy-on-write

rniwa: performance indeed can't be the reason

BoCupp: there is some cost when there's many elements as elements are more costly than pointers

annevk: is there data?

Domenic: there is for Chrome

Tab: there were issues raised with the shape of the adoptedStyleSheets API
... so the question is if this new approach seems reasonable

rniwa: I then raised the question why we are doing this?

emilio: ergonomics of the approach seem fine, not convinced by perf as style sheet infra for shadow roots is much more expensive

[Everyone to review the IDL array proposal.]

untrusted components

<diervo> https://docs.google.com/presentation/d/1sMl7UGepGjfliY2gbrORip_nD0LcQx2O_oWeroCrW-s/edit?usp=sharing

[Not minuting presentation.]

[A lot of discussion on isolated components, which end up being at least as complex as <iframe> and probably more so.]

Stacking UI

<emilio> ScribeNick: emilio

diervo: So we have a lot of issues implementing modals / dialogs in web-components
... we want to effectively build something like <dialog>
... there are a lot of unexposed primitives
... which would be nice to expose
... I think google is doing something with the std-components
... where they'd need something like it
... but right now it's pretty hard to build a dialog, specially if it's scoped to a particular region of the page
... would there be interest in exposed the primitive APIs?

Domenic: yes, but we should learn from other systems
... What API do Windows / Android / iOS do to expose dialogs
... I don't think we should do it on isolation
... there's an issue on Github that I'll drop on the minutes

fergal_daly: It doesn't seem particularly to webcomponents right?

<Domenic> https://github.com/whatwg/html/issues/4633

fergal_daly: only with html, not with custom elements or such

diervo: I think it's worse with web components, we couldn't work around it
... without web components we could just put it on the root?

rniwa: is the reason you want to build your own because <dialog> is not everywhere? Or due to limitations of <dialog>? If so, which ones?
... also which problems are you running into concretely?

diervo: accessibility, inert, etc...
... focus, etc, we'd have to add all of the tags and such
... stacking with transforms

emilio: so the issue is that transform creates a cb for fixed-pos elements right?

diervo: right, even if we're position: fixed it gets contained inside the transformed element

rniwa: so the ancestor transforms get applied?

emilio: not only that, it's contained entirely, creates a CB for fixed pos stuff

jan: We saw that coming up in practice when building a menu

rniwa: so how does dialog deal with this?

chrishtr: <dialog> goes into the top layer

rniwa: right, so it hosts itself to the root of the render tree?

chrishtr: right

jan: We've seen components that are trying doing <dialog>-like thing

rniwa: that's cool, what's the problems with <dialog>

diervo: there's no close button on dialog for example

Domenic: you need to add your own
... in my experience <dialog> is very tailored for dialog-like things, it doesn't work for right-click menus, etc.
... spec used to say you got tab trapping for all dialogs, but it wasn't implemented so we took it out
... but it's unclear how that'd work for right-click menus
... in general I don't think <dialog> was well designed, and we could improve it but there's only one impl

rniwa: I think someone should come up with a list of the concrete problems to see what the solutions are

diervo: and we need to do research as Domenic said

Domenic: Yeah the first is research for what the use-cases are: tooltips, right-click menus, etc...
... and then see how other platforms solve it

jan: Also which capabilities do they have in different platforms: stacking, tab-trapping, ...

rniwa: what's needed for each solution could be done in parallel, but yeah

<aboxhall_> slide-in menus too

rniwa: we need a list of everything that needs to be done, and the problems
... and then come up with solutions for each of those

Default focus behaviors for custom-elements

rakina: proposal is for custom-elements to be able to show the default focus behavior as builtin-elements
... so that we could follow the default focus behavior for <button>, <option>, ...
... the need for this is to be able to do custom checkboxes and such
... setting tabindex is not enough, because it can override the user of the custom element itself
... but also tabindex doesn't let you represent all the kind of focusabilities (click, tab, ...)
... proposal is to add something to ElementInternals
... the shape of the API is not final, example uses a css-selector kind of thing
... there are other alternatives listed

[lists alternatives]

Domenic: would love to get feedback on the direction
... do people agree that we should solve the problem?

[general agreement]

hober: I like the high-level category example
... we should just define these categories in HTML
... and the custom element just defines which category

rniwa: concern with the current proposal is that the author is responsible with mapping how it maps
... for example buttons are not tab-navigatable by default
... now some author uses button for a checkbox and would mismatch
... the fundamental issue is that each browser has different behavior for builtin elements
... and is easy to have the same issue with custom element

Domenic: are you aligned or opposed to hober's proposal?

rniwa: agreed

hober: I think the indirection of having the high-level description to avoid confusion

Domenic: I think it'd be useful to avoid authors breaking platform conventions

jan: how would it behave? Are there lower-level pieces?

Domenic: there are but they'd be hard to expose without breaking platform conventions

jan: It's a bit hard to say whether we should expose the low-level bits or not

hober: I think the lower-level bits are a mess, "in mac do X, in windows do Y, ..."

jan: It'd be useful to describe them so that author s

Domenic: we can give you a flat enumerated lists of the combinations that makes sense

jan: to be clear I agree with the proposal
... but there could be a lower-level bit that would be easier for devs to reason about

hober: we shouldn't require an spec update every time a new platform with different focus conventions gets added

Domenic: I don't know if we have a full list of categories

<aboxhall_> https://github.com/w3c/webcomponents/issues/762#issuecomment-488873615

Domenic: there's a list in the issue
... we should make sure that it covers all UAs and such, we may need to expand them
... we should do that and then come back

hober: is there existing terms we could use?

Domenic: I suspect not

rniwa: aria comes to mind
... we may want to use that

hober: I was just thinking of not making new names

imperative shadow distribution api

fergal_daly: this is something I worked on for a while back, started using it in some internal modules
... so we want to know what's the feeling for this
... because we find it pretty useful

[describes API]

fergal_daly: proposal is to allow only direct host children, rniwa wanted any descendant
... are you still opposed to the api without descendants rniwa?

rniwa: yes, nothing has changed

<pmdartus> https://github.com/whatwg/html/issues/3534

<fergal_daly> https://github.com/whatwg/html/issues/3534

fergal_daly: there are some arguments that make stuff tricky with descendants in the issue, like if you slot an ancestor in one slot and a descendant in another slot?
... how would the flat tree look like?

rniwa: the descendant would not appear as a child of the ancestor, only of the slot

fergal_daly: the other question is perf
... assigning depends on light tree order, which is slow

rniwa: may be useful to make assignment respect ordering

fergal_daly: I wonder if checking that it's an ancestor would be a perf issue

rniwa: well it's a bit more expensive than just a parent check but

pmdartus: What is the use case for nested descendants?

fergal_daly: you may have multiple bodies on a tabs or something, but maybe it could be solved via styling, rniwa do you know of other strong use case?

rniwa: not off the top of my head

fergal_daly: I don't have a strong argument for allowing arbitrary descendants

hober: my recollection is that part of the idea of the imperative api was to do custom interesting slotting algorithms
... basically enabling people to do slotting in interesting ways

fergal_daly: what drives us right now is not that but making stuff unobservable to the author
... this is why we care about the API

emilio: in Gecko we definitely have tree traversal optimizations that rely on only the children of shadow trees, if you allow arbitrary descendants those go away

smaug: can we start with the children-only (throwing otherwise) and extend the API?

rniwa: I thought there were some issues that prevented extensibility

fergal_daly: the other issue is ordering the slot elements

<rniwa> https://github.com/whatwg/html/issues/3534#issuecomment-371437030

fergal_daly: imperative makes that simple if we allow it to define the order

rniwa: there was an issue mixing manual slotting and declarative slotting with nested shadow roots?

fergal_daly: there is an issue with that but right now you set the mode on attachShadow
... so the proposal right now disallows that
... the proposal right now uses the light tree order but I think allowing the imperative to define the order would be useful

rniwa: I think that'd be extensible

smaug: how do you modify assignedNodes?
... it's a nodelist so you can't modify it

fergal_daly: you'd copy it and reassign, but it's not ergonomic

rniwa: seems like another mutable array

[everyone points to Domenic's webidl proposal]

[discussion about what assign being confusing about deleting all]

rniwa: should we rename it to assignAll or replaceAssignment or something?

jan: Can we make assignedNodes a settable property?

rniwa: but it's a method that already exists

jan: sorry, never mind

hober: so consensus is to move forward with the imperative api only allowing to slot direct children in a way that would allow future extension
... and throwing in the case arbitrary descendants and such

jan: Is there a way to manually manage one slot but put the remaining stuff in some other slot?
... would that be possible to do? I'd be uncomfortable leaving it up to the developer to do that
... also nested slots?

emilio: you just assign the slot, it just works

rniwa: right, in v1 there's only one tree, no redistribution happening

jan: It'd be useful to have an example of how to do that

fergal_daly: you may not use the slot attribute at all...

emilio: hold on, so to implement a default slot you need a mutation observer and such right?

rniwa: yes

fergal_daly: there's also slot change events, do we need those when we're assigning manually?

rniwa: you need that with nested shadow trees

fergal_daly: do you?

rniwa: yeah, if the parent shadow root has a slot you need to know that your flat tree changed even indirectly

jan: would we get slot changes for the outer thing only?

rniwa: the way it works right now is we fire it on the innermost slot

[whiteboard time]

fergal_daly: my motivation was to get rid of slotchange events because they're expensive sometimes

annevk: we could not dispatch it in the case there's no nested shadow root

emilio: that'd be really confusing

annevk: you could optimize where there's no event listeners

hober: early break?

[agreement]

end

<diervo> scribe: diervo

AOM

<aboxhall_> https://github.com/whatwg/html/pull/3917

annevk: AOM still uses frozen arrays?

aboxhall_: yes

Domenic: We could potentually use the new IDL for arrays

aboxhall_: id refs dont work across shadow boundaries

[describing api]

<aboxhall_> https://github.com/WICG/aom/blob/gh-pages/explainer.md#reflecting-element-references

aboxhall_: we don't let you assign something from a deep shadow room to a shallow shadow root, but we do allow it the opposite way (ant not much controversy here)

annevk: from a shadow tree you can have an element in the light tree but not the other way around

??: there is no issues exposing this to assistive technologies

rniwa: it shouldn't affect it

<zcorpan> (light tree = normal DOM tree, not inside shadow)

rniwa: historicaly, because shadow root encapsulation, we allow insdide things outside but not the other way around.
... if you have any aria active descendent or any other attribute, it could reference something in the ancestry tree.

<aboxhall_> https://github.com/WICG/aom/blob/gh-pages/explainer.md#use-case-2-setting-relationship-properties-without-needing-to-use-idrefs has a concrete example

Joshue108 bidirectionality

annevk: what happens on remove? does it update?

aboxhall_: the association holds

annvek: you can point to something is not in the tree

dot-miniscule: I think that is not a candidate to associate the element, it must be in hte DOM to be set

annvk: Is it a problem that can point to an element that is not in the DOM?

aboxhall_: I think on balance is probably not an issue, if you try that to compute some properties, at that point we can check: would this endup in the accesibiliyt tree?

annevk: label should not be able to point to something is not in the tree

aboxhall_: what would happen?

annevk: the label could be in the tree but not the thing it references to

Domenic: What about idrefs?

annevk: when you remove the node, is no longer connected

rniwa: in a form you have an id attribute no longer points to that element

Domenic: the idl attribute still gives the reference to the same element

rniwa: if that element happens to be the same id

annevk: we have the inverse, we have labels
... adding removeing labels work

zcorpan: that seems to make things mroe bittle beacuse their association will disapear

hober: do I have to redo the association? I woulnd't have to in the old system
... if we are going to offer a better api, it should be better otherwise will be in troubles

smaug: would this cause an issue on webkit?

rniwa: having a node in a document that references another node as a reference is might not be implementable
... we could figure out some magic, but will be very hard
... its different case from iframes

hober: I'm more concern about adoption than anything else

??: you could use any internal reference from an implmenetation point of view

zcorpan: if we take the label-by for instance there is other way that you can make things out of the accesibility tree
... it can be in the DOM and still be ignore

??: nothing of this change this proposal because it can already happen

aboxhall_: this is an analogy
... we could put a document method to know that is happening

zcorpan: we could do it when we break the asscociation

aboxhall_: do we want to allow setting elements as references which have never been added to the dom?

zcorpan: the answer should be yes

aboxhall_: to we allow returning that node as the value
... if I do elemenet.activeDecentant = neverAddedNode?
... if you set it to a disconected element, do you get it back?

rniwa: I don't think we should allow it, a disconnected now would do anything

aboxhall_: its usefu to know it will resume

rniwa: I just don't think we should create an API where its easy to do the wrong thing

zcorpan: if you are writting an api that builds a compoennt and you want to setup the asscoaition but hte component is not in the tree yet, the user of the component should have to maintain the association

rniwa: why you don't have a tree?

zcorpan: you might not know

annevk: you can setup your association upfront

zcorpan: the component might be a component at the top level, a light element

??: you could do this by setting up a list, which neither is in the dom

aboxhall_: you are not prevented to do it today

rniwa: its nonsensical to express a relationship where the things are not in the tree
... I disagree

jan_: what are the problems?
... seems that its useful to express this relationships

annevk: There is not precedent for this api shape

jan_: for me this api feels more elegant
... seems that is a natural result

annevk: how do we deal with ta node beign remove and inserted
... you still need to act on mutations

rniwa: we can't expose the node inside the shadow tree

Domenic: we could solve it as an implmentation detail
... you have a pointer that is a reference element and before returning it you do a bunch of checks

annevk: how would that work?
... a refers to b, people looking at a gets null because its inside the shadow

Domenic: I don't follow
... as far as the browser is concern there is no reference

annevk: would still be an association

Domenic: no
... we can either null things out as they cross boundaries

aboxhall_: or we do nothing
... treat it the same (violate encapsulation)

rniwa: we can't expose it

hober: when we do remove or add, things don't break you need to redo the work seems like a compromise

aboxhall_: im ok with that

rniwa: we might need to do it at insertion time or we might get into weird behaviour
... if we do the violation at computation time, we could reference things in different tree, which creates circular dependencies

hober: [trying to rephrase rniwa]

rniwa: if you have a node that references some ancestor, and then that node gets move in another shadow tree, and then that nove moves to other shadow tree it could create a cycle

hober: we could do cycle detection at insertion time

rniwa: if we do it at the time of insertion, we could invalidation all the references

hober: so you preserve the refernce, but you lost the ability to move thing around and keep them working
... the case of existing id attributes they still work

rniwa: but do we care?
... I dont think we can make this better that id refs because its a string

hober: this will be more brittle
... do we understand where we are?
... seems that there is no consensus?

zcorpan: an example - this feature doesn't need shadow root, you can use it with normal elements
... if you have a table and you want to do associaation with headers adn cells
... and there is not reasons why you wouldn't want to do the association prior
... with this apis this should work

annevk: the equivalency its weird
... in some cases

rniwa: seems that the insertion compromise might be good enough
... so you woulnd't have the crazy implementation complexity

aboxhall_: so whats the summary?

rniwa: do the validation when a node that references other node is inserted

hober: by default we will get a lot of invalidations if things are in order

rniwa: probably we need to speial case

chrishall: this discussion is to avoid the current concern of leaking and circular referneces
... and encapsulation

<chrishall> chrishall

rniwa: the fact that you can move elements you can get into circular dependencies

chrishall: instead of invalidating a insert time we invalidate at computation time, when we try to follow the link

annevk: you always get the object so you have to validate the object

rniwa: [describing a complicated counter example]

annevk: what is the problem exactly?

chrishall: seems that still not a cycle
... do we need to remove the relationship entirely?

rniwa: there is no other api where that node refernece exists

annevk: maybe shadowroot?

rniwa: yeah but that is intrisic to the shadow

Domenic: slots are also like this

annevk: the idea of validate something on the get is somewhat common IMO

hober: where do we want to pay the cost?
... if w edo the vaidation on the get is more expesive
... on insert is a user cost

annevk: in user land that looks like a lot of problems
... no weak references is hight level apis
... please!

[debate about weak references brwoser implemnetation]

annvek: are we saying that even if is disconected is null?

aboxhall_: tree as in document?

hober: can people file some issue about the alternatives?

<zcorpan_> (elements can be exposed to js after references have been removed if there's an event listener and it can still get events :) )

close

Is the AOM a suitable interim architecture for more than Web Components, for example XR type applications?

AOM architecture

Joshue108: there is a lack of semantics in other technologies from an accesibility perspective, how to address it?

rniwa: how that relates to web components?

Joshue108: beacuse the AOM was primarily defined for Web COmponents

aboxhall_: there were also other use cases
... the usre input events for example is orthogonal, also virtual nodes,

??: historically the conversation have develop in parallel

Joshue108: from the aom as it stands, is ti a suitable architecture?

rniwa: not sure if this is the right forum

close

AOM web components

[summarizing previous invariants and consensus]

<Domenic> https://html.spec.whatwg.org/multipage/forms.html#dom-lfe-labels see the example

rniwa: insertion of computation would have the same restrictions

chrishall: if you validate in insertation you are required teh author to inser them in teh right order

rniwa: I think yes

zcorpan_: seems like a tradeoff between cost for implementation vs. cost for web develoeprs

rniwa: its the complexity of memory management

aboxhall_: Im not clear of the behaviour rniwa wnats
... what the validation rules

hober: [describing an example]

rniwa: wheneve either node (reference, or referencee) at that point you run invalidation - which was pointed early will not work

aboxhall_: why are we discussing the behaviour instead of what the user sees

chrishall: I think we all agree that reference should survive add and remove

<tomalec> diervo: If we drop the reference integrity constraint, would that solve all the problems?

zcorpan_: seems that we need to figure out if this is implementaable

rniwa: In terms of requirements that web develoeprs care about, you should be able to setup referecnes for your elements before you insert them to the tree

zcorpan_: if you have an element referenced and you remove it and put it back it should work
... then implementation have other requirements like not break encapsulation or not have circular dependnecies
... and the order shouldn't matter
... it needs to be implementabe

<annevk> annevk: perhaps cross-document needs to work due to HTML modules, if you import elements, set up relationships, then insert

hober: this requirement seems like a low bar

aboxhall_: Im unclear what it means to be invalid

rniwa: if an element A references an element B if and only if A and B are in the same document and B is a shadow including ancestry
... if B is in another shadow tree that is not in the document thats bad too
... we can't reference two fully disconected trees

close

<pmdartus> scribe: pmdartus

Mitigate FOUC on CE

Domenic: [present slides https://docs.google.com/presentation/d/1C3tzhdhB9wIOcJQv-PSzJE9kKhvVNU61Py1fYN2_5z0]
... 2 problems: content that is not styled during the first render, invisible content that is visible before the script loads
... option 1: use the :not(:defined) selector
... option 2: use classic script to block the rendering
... introduce a new syntax to block the HTML parser when processing a certain element
... associating a module with a set of elements it defines
... challenges is it possible to actually block the parsing?

annevk: Since there are discrepancies between implementations, can we add a hit to not paint until DOMContentLoaded

fergal_daly: Maybe we should annotate the markup to not paint certain content

kouhei: There is a primitive when to paint, we need a primitive to tell not to paint. Maybe we should combine them?

annevk: What should we block?

rniwa: In the current model, because a script an implement the parser, with this proposal the script can't influence the parser the browser can do preamptive work.

annevk: Why not blocking the rendering at all?

Domenic: Because it prevents interaction with what have been already rendered
... All the proposal are similar to font-display: fallback, ...
... How does framework authors are currently solving this issue?

jan: I would like to come up at a page level with a strategy on how to resolve unknown custom elements

diervo: Would a customer accept that an entire page gets slower?

Domenic: This really targets components that need to be present at first load.

??: Does display locking helps with this use case?

Domenic: Yes it's related

fergal_daly: There is maybe a distinction between some component like toggles and container components
... visible vs. invisible components

diervo: The element attributes can contains multiple tag names

Domenic: Yeah it's possible

rniwa: It's interesting that there is no blocking behaviors for module scripts

Domenic: Good feedback, need more investigation. Will come back with a concrete proposal.

JSON modules

danclark: Implemented behind experimental flag in Chromium
... Any concern with this proposal? Any interest from other implementers?

hober: There is no difference between JSON and JS import in terms of syntax. This is pretty insecure.

Domenic: It's done in NodeJS

rniwa: It's not because Node implements it that we should do it
... We have avoided this issue so far. A script tag will never parse some CSS file, while here we rely only on the mime-type because it may be incorrect (server misconfiguration)

annevk: img element already support multiple mime-types

hoder: we want that the importer to provide a signal to know what is the expected module type.

annevk: Can we use the import map to store this information?

Domenic: This is far fetched, import map is only used to remap URL.

rniwa: this is a problem for all module types. Same issue with CSS module.

fergal_daly: Imagine an API returning weather data, it would be bad if it loaded some JS instead.

annevk: having an opt-in is not great because dev will not opt-in.

Domenic: We should use CSP to block the request

kouhei: 2 problems: we don't have an integrity mechanism, importing a JSON from an API we don't have control hover and some day the API goes rogue and start returning JS instead of JSON

Domenic: Let's fix the CSPs instead of inviting some new blocking mechanism

hober: an opt-in is not great, I would rather let the developers opt-out

annevk: We will need some a new CSP primitive

pmdartus: Why not using prefix or a suffix?

rniwa: Yes it would solve the issue

Domenic: TC39 recommend not messing up with the string and use an out-of-band signal

annevk: We have done CORS XHRs to have by default safe communication with cross domains, but this proposal is not secure by design.

Domenic: I don't understand why this is a security issue.

??: It's good feedback, we will come back with a new proposal.

- DRAFT -

SV_MEETING_TITLE

17 Sep 2019

Attendees

Contents

Introductions

delegate focus

scoped custom element registries

constructable style sheets

untrusted components

Stacking UI

Default focus behaviors for custom-elements

imperative shadow distribution api

end

AOM

close

Is the AOM a suitable interim architecture for more than Web Components, for example XR type applications?

AOM architecture

close

AOM web components

close

Mitigate FOUC on CE

JSON modules

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output