<annevk> Scribe: Travis
<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
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
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
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.]
<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.]
<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
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
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]
<diervo> scribe: diervo
<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 :) )
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
[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
<pmdartus> scribe: pmdartus
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.
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.
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/ou./out/ Succeeded: s/we don't allow customers to use parts/we would restrict the use of parts to be explicit/ Succeeded: s/ryosuke/rniwa/ Succeeded: s/elisa/aboxhall/ Succeeded: s/elisa/aboxhall/ Succeeded: s/elsa/aboxhall/ FAILED: s/elsa/aboxhall/g Succeeded: s/??/pmdartus/ Succeeded: s/Arrys/arrays/ Succeeded: s/??:/Joshue108/ Succeeded: s/dot-miniscule/dot-miniscule/ Succeeded: s/dot-minisculw/dot-miniscule/ Succeeded: s/annvk/annevk/ Succeeded: s/??/zcorpan/ Succeeded: s/a suitable/a suitable model/ Succeeded: s/??/chrishall/ Succeeded: s/hoder/hober/ Present: Tomek Wytrębowicz chrishtr rniwa diervo Travis hober annevk Domenic bkardell_ zcorpan_ Joshue108 pmdartus Boaz_ zcorpan Found Scribe: Travis Inferring ScribeNick: Travis WARNING: No scribe lines found matching previous ScribeNick pattern: <emilio> ... Found Scribe: jan Inferring ScribeNick: jan Found Scribe: Found Scribe: diervo Inferring ScribeNick: diervo Found Scribe: annevk Inferring ScribeNick: annevk Found ScribeNick: emilio Found Scribe: diervo Inferring ScribeNick: diervo Found Scribe: pmdartus Inferring ScribeNick: pmdartus Scribes: Travis, jan, , diervo, annevk, pmdartus ScribeNicks: emilio, Travis, jan, diervo, annevk, pmdartus WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]