00:09:07 <RRSAgent> RRSAgent has joined #components
00:09:07 <RRSAgent> logging to https://www.w3.org/2019/09/17-components-irc
00:09:10 <Zakim> Zakim has joined #components
00:09:20 <annevk> Scribe: Travis
00:09:41 <annevk> Topic: Introductions
00:10:33 <rniwa> rniwa has joined #components
00:10:39 <fergal_daly> fergal_daly has joined #components
00:10:39 <rakina> rakina has joined #components
00:10:55 <masonfreed> masonfreed has joined #components
00:11:00 <Travis> Scribe: jan
00:11:12 <Travis> :)
00:12:26 <Travis> jan: There was a q from apple; wanted to see an example of :part being used in practice....
00:13:03 <tomalec> present+ Tomek Wytrębowicz
00:13:17 <chrishtr> present+
00:13:33 <rniwa> present+
00:13:43 <diervo> present+
00:13:57 <jan> jan has joined #components
00:13:59 <Travis> present+
00:14:08 <jan> annevk: Mozilla has implemented a subset of ::part
00:14:29 <jan> rniwa: i think the contention was on forwarding
00:15:02 <jan> fergal_daly: the declarative syntax is the spec is what’s agreed
00:15:13 <jan> fergal_daly: the declarative map had agreement
00:16:05 <John_dai> John_dai has joined #components
00:16:22 <jan> tess: moving on to custom states
00:16:26 <rakina> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/custom-states-and-state-pseudo-class.md
00:17:17 <jan> rakina: curently we’re proposing just custom states, no built-in pseudo-classes
00:19:33 <tomalec> Rakina, could you please use the mic?
00:19:56 <jan> annevk: is there syntax incompatibility
00:20:37 <jan> fergal_daly: the same issue applies to part
00:20:45 <jan> ... you can specify a ::part you can’t select in CSS
00:21:26 <jan> rniwa: should this be a thing for custom elements or shadow roots?
00:21:42 <jan> rniwa: ... would it be possible to have a custom element without shadow root that has a state?
00:22:06 <jan> annevk: if we had ElementInternals before we had attachShadow, we would have put attachShadow on ElementInternals
00:22:35 <jan> annevk: so now we have this disconnect, and each time we have to decide where to put the API (ElementInternals or shadow root(
00:23:30 <jan> annevk: for new things, we should prefer using ElementInternals instead of shadow root
00:24:18 <jan> rniwa: do we allow pseudo-classes on a ::part?
00:24:26 <jan> diervo: we opened a bug
00:24:46 <jan> fergal_daly: yes, they don’t all work, but most of them do
00:24:49 <ekashida> ekashida has joined #components
00:25:13 <jan> fergal_daly: Tab said it should work
00:25:20 <jan> fergal_daly: I think he said he updated the spec
00:25:22 <diervo> https://github.com/w3c/csswg-drafts/issues/3510
00:26:23 <jan> chrishtr: I think having custom states was the #1 request on top of parts
00:26:44 <hober> hober has joined #components
00:26:49 <annevk> https://drafts.csswg.org/selectors/#pseudo-element-states
00:26:52 <hober> present+
00:27:04 <annevk> present+
00:27:04 <jan> chrishtr: Is SalesForce using ::part
00:27:17 <jan> diervo: we will once there’s agreement that it will be implemented
00:27:39 <jan> diervo: is ::part going to be the way to style new things (e.g., toast(
00:28:12 <jan> diervo: it’s hard to do static analysis to determine the API for a component
00:28:24 <jan> diervo: it can be problematic if you can do anything you want to a ::part
00:28:48 <jan> diervo: while parts work well for built-in components, we’re concerned we’ll have to forward all the parts
00:30:08 <jan> diervo: we’re looking at ways to control what people using parts can do.
00:30:15 <jan> diervo: E.g., we think themes gives too much power
00:32:15 <jan> diervo: We’re fine with parts, but we’re still looking for a better solution to propose
00:32:31 <Travis> jan: as far as static analysis...
00:32:45 <Travis> .. for parts, I proposed a way to ask an element for what its parts are?
00:32:54 <Travis> .. is there a similar thing for states?
00:33:04 <hiroshige> hiroshige has joined #components
00:33:07 <Travis> .. can an element expose its states programmatically?
00:33:30 <Travis> .. would be interesting to expose a public/custom states to see what the full set of states are.
00:33:43 <Travis> rakina: Sure, it's doable.
00:33:51 <Travis> annevk: you can implement this yourself?
00:33:58 <Travis> .. so far we haven't done that.
00:34:19 <Travis> jan: I think its useful to anticipate cases... (we offer reflection in the process already)
00:34:30 <Travis> .. these are generally good practice, rather then expect the component author to expose
00:34:51 <Travis> hober: its an internal fact that the component is in the state...
00:35:40 <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"
00:35:49 <Travis> .. private state is tracked differently...
00:36:12 <whsieh> whsieh has joined #components
00:36:13 <Travis> .. so this proposal is only about public states... why add it here and *not* want someone to know about it.
00:36:22 <Travis> rniwa: too early to judge what the right thing to do here?
00:36:37 <Travis> .. if other libraries are trying to add then we can make changes.
00:37:10 <Travis> .. for static analysis, it doesn't help to expose JS aPI--it needs to be declarative.
00:37:22 <Travis> .. hard to say what the right API is for the use case.
00:37:31 <Travis> .. bottom line: too early.
00:37:47 <Travis> fergal_daly: you just set a state; there's no list of values
00:38:07 <Travis> .. in Chromium, there's nothing that tracks all the parts; takes a tree walk to figure it ou.
00:38:16 <Travis> s/ou./out
00:38:49 <Travis> diervo: we don't allow customers to use parts, so we try to be explicit...
00:39:01 <Travis> .. we would probably disable that anyway.
00:40:04 <jan> smaug: if you are in multiple states, how to you select that
00:40:20 <jan> rniwa: is it :state(foo):state(bar) or :state(foo bar)
00:40:38 <jan> fergal_daly: the question is whether you want to do AND or OR
00:40:48 <jan> rniwa: Let’s not create a new OR
00:41:05 <jan> fergal_daly: So the proposal now only allows a single state
00:41:10 <jan> annevk: Yes
00:41:29 <jan> rakina: Yes
00:41:45 <jan> fergal_daly: Tab updates the ::part spec, specifically to get the OR effect
00:41:52 <smaug> https://github.com/w3c/csswg-drafts/issues/3502
00:41:59 <jan> tess: Maybe we should drop that
00:42:03 <diervo> s/we don't allow customers to use parts/we would restrict the use of parts to be explicit
00:42:10 <jan> rniwa: What does that mean, especially for ::part
00:42:18 <jan> fergal_daly: I’ll ask Tab why he did that
00:42:38 <jan> annevk: I think for ::part, a single part can consist of multiple parts in a single value
00:43:18 <jan> ... Example, if you want to select an active tab, you’d want ::part(tab active)
00:43:49 <Domenic> present+
00:43:51 <jan> annevk: I think that’s a leftover from before we had custom states
00:43:59 <jan> fergal_daly: I’ll ask Tab to remove that
00:44:23 <jan> fergal_daly: You said we wouldn’t put this on non custom elements?
00:44:52 <jan> ... If we *did* allow this, then several of the existing pseudo-classes could be done as states
00:45:14 <jan> ... If you allow this on built-in elements, then you’d eliminate the need to introduce new pseudo-classes
00:46:36 <jan> rniwa: It’s good to keep custom states and built-in pseudo-classes in separate namespaces to avoid future name conflicts
00:48:22 <jan> hober: any more comments on the proposal?
00:48:28 <jan> annevk: spec it and test it
00:48:59 <jan> rniwa: what’s the question in spec about —foo?
00:50:09 <jan> tab: the reasons ::part can take multiple args is because parts are supposed to be equivalent to classes
00:50:30 <jan> annevk: but I think now that we have custom state, we don’t need that
00:51:42 <jan> tab: if we’re definitely pursuing state, then we could drop support for selecting multiple parts in ::part
00:52:07 <jan> hober: part is more like element names than class names
00:54:29 <jan> 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
00:55:13 <jan> ... given that people use multiple classes all the time (.foo.bar), I think it suggests we’ll want this for parts
00:55:17 <jan> rniwa: we could add it later
00:56:13 <jan> tab: the cost is low to support this
00:56:49 <jan> annevk: I think I’m somewhat convinced to keep this
00:58:08 <jan> 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
00:58:37 <jan> rniwa: you might want to have a single element that acts as multiple parts
00:59:01 <jan> ... but you probably only need to select an element as a single part at a time
00:59:37 <meredithl> meredithl has joined #components
00:59:37 <jan> fergal_daly: holiday example: you want style calendar days that are holidays, and days that are holidays-on-a-weekend
01:05:40 <xiaoqian> xiaoqian has joined #components
01:06:19 <xiaoqian> RRSAgent, make minutes
01:06:19 <RRSAgent> I have made the request to generate https://www.w3.org/2019/09/17-components-minutes.html xiaoqian
01:06:21 <heycam> heycam has joined #components
01:06:35 <heycam> RRSAgent: pointer
01:06:35 <RRSAgent> See https://www.w3.org/2019/09/17-components-irc#T01-06-35
01:12:25 <JohnRiv> JohnRiv has joined #components
01:18:28 <jan> jan has joined #components
01:18:38 <jan> https://github.com/w3c/webcomponents/issues/738#issuecomment-486897992
01:19:20 <emilio> emilio has joined #components
01:20:02 <annevk> emilio: https://github.com/w3c/webcomponents/issues/826
01:20:29 <chrishall> chrishall has joined #components
01:21:05 <diervo> diervo has joined #components
01:21:10 <diervo> scribe:
01:21:22 <ekashida> ekashida has joined #components
01:21:22 <diervo> scribe: diervo
01:21:33 <diervo> emilio: we didn't implement forwarding because we were unclear
01:21:42 <rniwa> rniwa has joined #components
01:21:45 <danclark> danclark has joined #components
01:21:49 <diervo> fergal_daly: it was consensus on the syntax
01:22:01 <jacksteinberg> jacksteinberg has joined #components
01:22:23 <diervo> ryosuke: the syntax might have to change due to the multiple part selector
01:22:42 <diervo> fergal_daly: Wouldn't that work anyway?
01:23:17 <diervo> riosuker: You can't define a forward as a singlely named part
01:23:19 <pmdartus> s/ryosuke/rniwa
01:23:42 <jan> jan has joined #components
01:25:08 <diervo> rniwa: Jus because it works doesn't mean its suficient
01:25:28 <diervo> rniwa: maybe we should be able to forward a multiple part as one
01:27:12 <diervo> hober: I can see how coalescing forwarded parts might be useful
01:28:22 <diervo> tab: we could add grammar but it will make things more complicated
01:29:23 <diervo> rniwa: we should have parity ergonomics for multiple part syntax multiple forward syntax
01:31:13 <diervo> tab: the syntax seems easy to introduce
01:31:59 <diervo> tab: the mental model for forwards was meant to be similar as desctructuring
01:32:09 <diervo> hober: seems like a super set and that seems fine
01:33:28 <diervo> annevk: seems like a reasonable addition
01:33:56 <diervo> rniwa: today gecko supports only parts without multiple parts and forwarding
01:35:09 <jan> jan has joined #components
01:35:28 <diervo> topic: delegate focus
01:36:17 <diervo> rakina: Focus navigation today uses sequencial focus navigation which has certain constraints
01:37:09 <diervo> rakina: the javascript focus method will only look at the tabIndex and that might not be sufficient
01:37:28 <diervo> rakina: we want to change the focus delegation for hosts that have delegate focus, for cases when we call focus method of by clicking it
01:37:36 <rakina> https://github.com/w3c/webcomponents/issues/830
01:37:43 <jan> jan has joined #components
01:37:48 <diervo> rakina: but we want to keep the semantics
01:37:58 <diervo> rakina: of the old behavior
01:39:31 <diervo> rniwa: any concerns?
01:39:46 <diervo> ekashida: we would love to have an api for now what can be focus
01:40:10 <diervo> Domenic: the problem is that those apis are platform specific which is tricky
01:40:47 <diervo> Emilio: Also the problem is that some of the focusability depends on the styles (it might need force style updates)
01:41:05 <diervo> Domenic: not sure if we should design this API, but is worth discuss it
01:41:30 <diervo> rniwa: Would people care about what element get focus?
01:41:50 <whsieh> whsieh has joined #components
01:41:52 <diervo> rniwa: First click focusable
01:42:19 <diervo> ekashida: As per the for overriding the default, nobody has asked for that
01:42:38 <rakina> https://github.com/whatwg/html/pull/4731#issuecomment-529324420
01:42:46 <diervo> Domenic: Consensus on what gets focus by default focus for click and programatic
01:43:15 <dot-miniscule> dot-miniscule has joined #components
01:43:28 <sanketj> sanketj has joined #components
01:43:31 <masonfreed> masonfreed has joined #components
01:45:08 <diervo> Emilio: depending on where the rule comes from (from inside the shadow or outside the sahdow) how would that work?
01:45:56 <diervo> rniwa: we might want to do :focus on the host for style the whole component
01:46:04 <diervo> Emilio: :host:focus-within
01:46:25 <diervo> Emilio: focus within will match
01:46:34 <diervo> rniwa: we should match :focus
01:46:40 <diervo> rniwa: for the outside
01:46:56 <diervo> annevk: Does css has good ways to describe context?
01:47:10 <diervo> Emilio: The input of selector matching is a list of trees
01:47:45 <diervo> annevk: how the spec will work?
01:48:53 <diervo> 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
01:49:15 <diervo> tab: we will have to do some magic but seems doable in spec
01:51:32 <diervo> elsa: I have some arguments against it
01:52:39 <diervo> Emilio: if you have a global focus rule, even though that its a button focus inside
01:53:07 <diervo> elisa: Im worry about the focus ring due to interactivity
01:53:36 <diervo> Domenic: Focus visible will only show it in the inner thing
01:54:08 <diervo> elisa: The thing that has focus is the thing that will take key stroke
01:54:35 <diervo> Domenic: it seems to be an implementation detail
01:55:57 <diervo> rniwa: this is very confusing
01:56:16 <diervo> rniwa: the :focus match is orghogonal to the focus-ring
01:56:42 <diervo> fergal_daly: from the outside a component is one thing, but the reality is that is not
01:57:09 <diervo> fergal_daly: what about iframes?
01:57:37 <diervo> rniwa: frames get really wonky
01:57:50 <diervo> Domenic: I think the mental model seems the same
01:58:22 <diervo> Bocupp: is the active element from which the host exists, and inside has its own focus
01:58:44 <annevk> data:text/html,<style>iframe { border:1px solid blue } :focus { border:1px solid red }</style><iframe srcdoc="<input>"></iframe>
01:58:47 <Domenic> lol iframes are specifically excluded from :focus despite being in the focus chain
01:59:11 <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.
01:59:13 <diervo> tab: what is focus-visible can be some sort of part?
01:59:54 <ekashida> ekashida has joined #components
01:59:55 <diervo> tab: 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
02:00:04 <diervo> tab: mayb we can auto surface it as deeply as necesary
02:00:13 <diervo> hober: Im concerned about that part
02:00:42 <diervo> hober: parts are explicit, focus might not
02:00:44 <annevk> Domenic: I wonder how that ended up being a thing
02:01:05 <Domenic> annevk: I wonder if it was done for reasons similar to aboxhall_'s reasoning.
02:01:17 <diervo> hober: encapsulation concerns make sense, but piercing the encapsulation in this case might be needed.
02:01:33 <diervo> hober: example about photoshop
02:02:00 <chrishall> note: the projector laptop is complaining about low battery.
02:02:38 <diervo> hober: if the component wants to do specific focus rings, does the component needs to be smart about it?
02:02:40 <diervo> tab: yes
02:02:55 <diervo> rniwa: I don't think we ever going to do a piercing shadow boundary
02:03:07 <diervo> Emilio: I agree with rniwa
02:03:40 <diervo> Emilio: we have a consistent focus for the DOM, CSS should behave similarly
02:03:58 <diervo> tab: auto piercing its controversial yes, but it might be justified maybe
02:04:21 <diervo> hober: is there a particular isssue for this?
02:04:57 <diervo> rniwa: we should file an issue on the css spec and or html
02:05:15 <diervo> Domenic: they have spec really well the focusability
02:05:49 <diervo> rniwa: I think elisa concerns are with focus-ring
02:07:18 <diervo> 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
02:08:01 <tomalec> s/elisa/aboxhall
02:08:10 <diervo> s/elisa/aboxhall
02:08:46 <tomalec> s/elsa/aboxhall
02:10:38 <tomalec_> tomalec_ has joined #components
02:10:45 <diervo> s/elsa/aboxhall/g
02:15:12 <hiroshige> hiroshige has joined #components
02:16:21 <rniwa> rniwa has joined #components
02:17:53 <annevk> scribe: annevk
02:18:03 <annevk> Topic: scoped custom element registries
02:18:18 <annevk> hober: who did this?
02:18:44 <annevk> diervo: nothing has changed since the last time, Justin isn't here
02:18:58 <annevk> Mason: Justin wanted this on the agenda, but he isn't here
02:19:09 <annevk> Mason: he has an action item to make a concrete proposal
02:19:16 <annevk> Mason: not sure what we should discuss beyond that
02:19:29 <annevk> hober: he still has that action item and we're all excited about seeing that move forward
02:19:48 <annevk> topic: constructable style sheets
02:20:14 <annevk> Domenic: I have an idea on how to fix arrays
02:20:16 <emilio> github: https://github.com/WICG/construct-stylesheets/issues/45
02:20:19 <masonfreed> masonfreed has joined #components
02:20:20 <annevk> hober: is there an issue against IDL?
02:20:24 <annevk> Domenic: yes, it's kinda long
02:20:34 <jan> jan has joined #components
02:20:34 <Domenic> https://github.com/heycam/webidl/issues/796
02:20:52 <annevk> emilio: I may have opinions
02:21:12 <annevk> Tab: if we do something in IDL, typed OM will use it
02:21:25 <annevk> emilio: I was thinking about style sheet manipulation APIs
02:21:43 <annevk> Domenic: concretely the IDL proposal adds (see issue)
02:21:50 <jan> jan has joined #components
02:21:55 <annevk> rniwa: would we change something?
02:21:58 <annevk> Domenic: only new things
02:22:21 <annevk> Domenic: it would mostly have more behavior, but would not have item()
02:22:45 <annevk> emilio: can you feature-detect?
02:22:50 <annevk> Domenic: Object.isFrozen()
02:23:04 <annevk> rniwa: it's not great that we keep inventing new ways of doing things
02:23:13 <annevk> rniwa: promises/callbacks, ways to do arrays
02:23:17 <annevk> rniwa: why?
02:23:26 <annevk> Domenic: that's why we tried to use FrozenArray
02:23:55 <annevk> emilio: if I were to design it from scratch I'd add methods to ShadowRoot
02:24:26 <annevk> rniwa: StyleSheetList
02:25:11 <annevk> Domenic: options
02:25:30 <annevk> Domenic: 1) we can do something specific for our use case per emilio's suggestion
02:25:39 <annevk> Domenic: 2) or we can do something based on array in IDL
02:26:26 <xiaoqian> xiaoqian has joined #components
02:27:39 <annevk> rniwa: why do we have constructable style sheets?
02:27:59 <annevk> Tab: they want to load them via their object graph, reuse them more easily
02:28:37 <annevk> emilio/Tab: with <style> elements we can do copy-on-write
02:29:03 <kouhei> kouhei has joined #components
02:30:00 <annevk> rniwa: performance indeed can't be the reason
02:31:37 <annevk> BoCupp: there is some cost when there's many elements as elements are more costly than pointers
02:31:43 <annevk> annevk: is there data?
02:31:46 <annevk> Domenic: there is for Chrome
02:35:05 <annevk> Tab: there were issues raised with the shape of the adoptedStyleSheets API
02:35:16 <annevk> Tab: so the question is if this new approach seems reasonable
02:35:38 <annevk> rniwa: I then raised the question why we are doing this?
02:35:40 <hayato> hayato has joined #components
02:38:56 <annevk> emilio: ergonomics of the approach seem fine, not convinced by perf as style sheet infra for shadow roots is much more expensive
02:40:04 <annevk> [Everyone to review the IDL array proposal.]
02:40:21 <annevk> Topic: untrusted components
02:40:37 <diervo> https://docs.google.com/presentation/d/1sMl7UGepGjfliY2gbrORip_nD0LcQx2O_oWeroCrW-s/edit?usp=sharing
02:40:48 <annevk> [Not minuting presentation.]
02:43:21 <xiaoqian> xiaoqian has joined #components
02:55:59 <Zakim> Zakim has left #components
03:00:31 <annevk> [A lot of discussion on isolated components, which end up being at least as complex as <iframe> and probably more so.]
03:59:16 <JohnRiv> JohnRiv has joined #components
04:02:30 <rniwa> rniwa has joined #components
04:02:31 <pmdartus> pmdartus has joined #components
04:03:41 <whsieh> whsieh has joined #components
04:08:23 <whsieh> whsieh has left #components
04:08:23 <emilio> topic: Stacking UI
04:08:30 <emilio> ScribeNick: emilio
04:08:43 <whsieh> whsieh has joined #components
04:08:54 <jan> jan has joined #components
04:08:56 <masonfreed> masonfreed has joined #components
04:08:58 <diervo> diervo has joined #components
04:09:04 <rakina> rakina has joined #components
04:09:15 <emilio> diervo: So we have a lot of issues implementing modals / dialogs in web-components
04:09:21 <danclark> danclark has joined #components
04:09:26 <emilio> ... we want to effectively build something like <dialog>
04:09:36 <emilio> ... there are a lot of unexposed primitives
04:09:45 <emilio> ... which would be nice to expose
04:10:01 <emilio> ... I think google is doing something with the std-components
04:10:13 <emilio> ... where they'd need something like it
04:10:29 <emilio> ... but right now it's pretty hard to build a dialog, specially if it's scoped to a particular region of the page
04:10:42 <emilio> ... would there be interest in exposed the primitive APIs?
04:10:50 <emilio> Domenic: yes, but we should learn from other systems
04:11:07 <emilio> ... What API do Windows / Android / iOS do to expose dialogs
04:11:14 <emilio> ... I don't think we should do it on isolation
04:11:29 <emilio> ... there's an issue on Github that I'll drop on the minutes
04:11:41 <emilio> fergal_daly: It doesn't seem particularly to webcomponents right?
04:11:50 <Domenic> https://github.com/whatwg/html/issues/4633
04:11:56 <emilio> ... only with html, not with custom elements or such
04:12:18 <emilio> diervo: I think it's worse with web components, we couldn't work around it
04:12:23 <ekashida> ekashida has joined #components
04:12:36 <emilio> ... without web components we could just put it on the root?
04:12:58 <emilio> 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?
04:13:13 <emilio> ... also which problems are you running into concretely?
04:13:34 <emilio> diervo: accessibility, inert, etc...
04:14:06 <emilio> ... focus, etc, we'd have to add all of the tags and such
04:14:10 <emilio> ... stacking with transforms
04:14:59 <emilio> emilio: so the issue is that transform creates a cb for fixed-pos elements right?
04:15:44 <jacksteinberg> jacksteinberg has joined #components
04:16:16 <emilio> diervo: right, even if we're position: fixed it gets contained inside the transformed element
04:16:27 <kouhei> kouhei has joined #components
04:16:33 <emilio> rniwa: so the ancestor transforms get applied?
04:16:34 <kurosawa> kurosawa has joined #components
04:16:49 <emilio> emilio: not only that, it's contained entirely, creates a CB for fixed pos stuff
04:17:16 <emilio> jan: We saw that coming up in practice when building a menu
04:17:29 <emilio> rniwa: so how does dialog deal with this?
04:17:38 <emilio> chrishtr: <dialog> goes into the top layer
04:17:48 <emilio> rniwa: right, so it hosts itself to the root of the render tree?
04:17:52 <emilio> chrishtr: right
04:18:12 <emilio> jan: We've seen components that are trying doing <dialog>-like thing
04:18:29 <emilio> rniwa: that's cool, what's the problems with <dialog>
04:18:32 <emilio> ?
04:18:41 <emilio> diervo: there's no close button on dialog for example
04:18:47 <emilio> Domenic: you need to add your own
04:19:15 <emilio> ... in my experience <dialog> is very tailored for dialog-like things, it doesn't work for right-click menus, etc.
04:19:40 <emilio> ... spec used to say you got tab trapping for all dialogs, but it wasn't implemented so we took it out
04:19:48 <emilio> ... but it's unclear how that'd work for right-click menus
04:20:13 <emilio> ... in general I don't think <dialog> was well designed, and we could improve it but there's only one impl
04:20:13 <bkardell_> bkardell_ has joined #components
04:20:36 <emilio> rniwa: I think someone should come up with a list of the concrete problems to see what the solutions are
04:20:38 <bkardell_> present+
04:20:49 <emilio> diervo: and we need to do research as Domenic said
04:21:08 <emilio> Domenic: Yeah the first is research for what the use-cases are: tooltips, right-click menus, etc...
04:21:16 <emilio> ... and then see how other platforms solve it
04:21:35 <emilio> jan: Also which capabilities do they have in different platforms: stacking, tab-trapping, ...
04:21:49 <emilio> rniwa: what's needed for each solution could be done in parallel, but yeah
04:21:53 <aboxhall_> slide-in menus too
04:22:14 <emilio> ... we need a list of everything that needs to be done, and the problems
04:22:24 <emilio> ... and then come up with solutions for each of those
04:22:31 <emilio> topic: Default focus behaviors for custom-elements
04:22:53 <sanketj> sanketj has joined #components
04:22:59 <emilio> rakina: proposal is for custom-elements to be able to show the default focus behavior as builtin-elements
04:23:10 <emilio> ... so that we could follow the default focus behavior for <button>, <option>, ...
04:23:31 <emilio> ... the need for this is to be able to do custom checkboxes and such
04:23:49 <emilio> ... setting tabindex is not enough, because it can override the user of the custom element itself
04:24:08 <emilio> ... but also tabindex doesn't let you represent all the kind of focusabilities (click, tab, ...)
04:24:19 <emilio> ... proposal is to add something to ElementInternals
04:24:40 <sanketj> sanketj has joined #components
04:24:45 <emilio> ... the shape of the API is not final, example uses a css-selector kind of thing
04:25:02 <emilio> ... there are other alternatives listed
04:25:22 <emilio> [lists alternatives]
04:25:39 <emilio> Domenic: would love to get feedback on the direction
04:25:48 <emilio> ... do people agree that we should solve the problem?
04:25:52 <emilio> [general agreement]
04:26:08 <emilio> hober: I like the high-level category example
04:26:18 <emilio> ... we should just define these categories in HTML
04:26:29 <emilio> ... and the custom element just defines which category
04:27:13 <emilio> rniwa: concern with the current proposal is that the author is responsible with mapping how it maps
04:27:27 <emilio> ... for example buttons are not tab-navigatable by default
04:27:48 <emilio> ... now some author uses button for a checkbox and would mismatch
04:28:27 <emilio> ... the fundamental issue is that each browser has different behavior for builtin elements
04:28:58 <emilio> ... and is easy to have the same issue with custom element
04:29:11 <emilio> Domenic: are you aligned or opposed to hober's proposal?
04:29:19 <emilio> rniwa: agreed
04:30:31 <emilio> hober: I think the indirection of having the high-level description to avoid confusion
04:30:52 <emilio> Domenic: I think it'd be useful to avoid authors breaking platform conventions
04:31:08 <emilio> jan: how would it behave? Are there lower-level pieces?
04:31:21 <emilio> Domenic: there are but they'd be hard to expose without breaking platform conventions
04:31:53 <emilio> jan: It's a bit hard to say whether we should expose the low-level bits or not
04:32:08 <emilio> hober: I think the lower-level bits are a mess, "in mac do X, in windows do Y, ..."
04:32:28 <emilio> jan: It'd be useful to describe them so that author s
04:32:40 <emilio> Domenic: we can give you a flat enumerated lists of the combinations that makes sense
04:32:52 <emilio> jan: to be clear I agree with the proposal
04:33:23 <emilio> jan: but there could be a lower-level bit that would be easier for devs to reason about
04:33:40 <emilio> hober: we shouldn't require an spec update every time a new platform with different focus conventions gets added
04:33:54 <emilio> Domenic: I don't know if we have a full list of categories
04:33:58 <aboxhall_> https://github.com/w3c/webcomponents/issues/762#issuecomment-488873615
04:34:00 <jan> jan has joined #components
04:34:00 <emilio> ... there's a list in the issue
04:34:25 <emilio> ... we should make sure that it covers all UAs and such, we may need to expand them
04:34:31 <emilio> ... we should do that and then come back
04:34:37 <emilio> hober: is there existing terms we could use?
04:34:43 <emilio> Domenic: I suspect not
04:34:56 <emilio> rniwa: aria comes to mind
04:35:14 <emilio> ... we may want to use that
04:35:31 <emilio> hober: I was just thinking of not making new names
04:36:38 <emilio> topic: imperative shadow distribution api
04:36:57 <emilio> fergal_daly: this is something I worked on for a while back, started using it in some internal modules
04:37:06 <emilio> ... so we want to know what's the feeling for this
04:37:14 <emilio> ... because we find it pretty useful
04:37:25 <emilio> [describes API]
04:38:18 <emilio> fergal_daly: proposal is to allow only direct host children, rniwa wanted any descendant
04:38:40 <emilio> ... are you still opposed to the api without descendants rniwa?
04:38:49 <emilio> rniwa: yes, nothing has changed
04:38:55 <pmdartus> https://github.com/whatwg/html/issues/3534
04:39:00 <jan> jan has joined #components
04:39:01 <fergal_daly> https://github.com/whatwg/html/issues/3534
04:39:21 <emilio> 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?
04:39:44 <emilio> ... how would the flat tree look like?
04:40:22 <emilio> rniwa: the descendant would not appear as a child of the ancestor, only of the slot
04:40:28 <emilio> fergal_daly: the other question is perf
04:40:41 <emilio> ... assigning depends on light tree order, which is slow
04:40:54 <emilio> rniwa: may be useful to make assignment respect ordering
04:41:13 <emilio> fergal_daly: I wonder if checking that it's an ancestor would be a perf issue
04:41:55 <emilio> rniwa: well it's a bit more expensive than just a parent check but
04:42:15 <emilio> ??: What is the use case for nested descendants?
04:42:47 <emilio> 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?
04:42:57 <emilio> rniwa: not off the top of my head
04:43:10 <emilio> fergal_daly: I don't have a strong argument for allowing arbitrary descendants
04:43:31 <emilio> hober: my recollection is that part of the idea of the imperative api was to do custom interesting slotting algorithms
04:43:49 <hiroshige> hiroshige has joined #components
04:44:02 <emilio> hober: basically enabling people to do slotting in interesting ways
04:44:23 <emilio> fergal_daly: what drives us right now is not that but making stuff unobservable to the author
04:44:46 <emilio> fergal_daly: this is why we care about the API
04:45:08 <pmdartus> s/??/pmdartus
04:45:58 <emilio> 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
04:46:27 <emilio> smaug: can we start with the children-only (throwing otherwise) and extend the API?
04:46:47 <emilio> rniwa: I thought there were some issues that prevented extensibility
04:47:11 <emilio> fergal_daly: the other issue is ordering the slot elements
04:47:22 <rniwa> https://github.com/whatwg/html/issues/3534#issuecomment-371437030
04:47:27 <emilio> fergal_daly: imperative makes that simple if we allow it to define the order
04:47:33 <jan> jan has joined #components
04:48:22 <emilio> rniwa: there was an issue mixing manual slotting and declarative slotting with nested shadow roots?
04:48:35 <emilio> fergal_daly: there is an issue with that but right now you set the mode on attachShadow
04:49:07 <emilio> ... so the proposal right now disallows that
04:49:26 <emilio> ... the proposal right now uses the light tree order but I think allowing the imperative to define the order would be useful
04:49:33 <emilio> rniwa: I think that'd be extensible
04:49:45 <emilio> smaug: how do you modify assignedNodes?
04:49:55 <emilio> ... it's a nodelist so you can't modify it
04:50:13 <emilio> fergal_daly: you'd copy it and reassign, but it's not ergonomic
04:50:20 <emilio> rniwa: seems like another mutable array
04:50:47 <emilio> [everyone points to Domenic's webidl proposal]
04:51:25 <emilio> [discussion about what assign being confusing about deleting all]
04:51:35 <emilio> rniwa: should we rename it to assignAll or replaceAssignment or something?
04:51:57 <emilio> jan: Can we make assignedNodes a settable property?
04:52:12 <emilio> rniwa: but it's a method that already exists
04:52:24 <emilio> jan: sorry, never mind
04:52:49 <emilio> 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
04:54:05 <emilio> ... and throwing in the case arbitrary descendants and such
04:55:00 <emilio> jan: Is there a way to manually manage one slot but put the remaining stuff in some other slot?
04:55:45 <emilio> ... would that be possible to do? I'd be uncomfortable leaving it up to the developer to do that
04:56:13 <emilio> ... also nested slots?
04:56:33 <emilio> emilio: you just assign the slot, it just works
04:56:47 <emilio> rniwa: right, in v1 there's only one tree, no redistribution happening
04:57:02 <emilio> jan: It'd be useful to have an example of how to do that
04:58:13 <emilio> fergal_daly: you may not use the slot attribute at all...
04:58:17 <zcorpan_> zcorpan_ has joined #components
04:58:23 <zcorpan_> present+
04:58:25 <emilio> emilio: hold on, so to implement a default slot you need a mutation observer and such right?
04:58:31 <emilio> rniwa: yes
04:58:51 <emilio> fergal_daly: there's also slot change events, do we need those when we're assigning manually?
04:59:08 <emilio> rniwa: you need that with nested shadow trees
04:59:18 <emilio> fergal_daly: do you?
04:59:46 <emilio> rniwa: yeah, if the parent shadow root has a slot you need to know that your flat tree changed even indirectly
05:00:51 <emilio> jan: would we get slot changes for the outer thing only?
05:01:01 <emilio> rniwa: the way it works right now is we fire it on the innermost slot
05:01:34 <emilio> [whiteboard time]
05:04:10 <emilio> fergal_daly: my motivation was to get rid of slotchange events because they're expensive sometimes
05:04:13 <Joshue108> Joshue108 has joined #components
05:05:19 <emilio> annevk: we could not dispatch it in the case there's no nested shadow root
05:05:24 <emilio> emilio: that'd be really confusing
05:05:39 <emilio> annevk: you could optimize where there's no event listeners
05:06:05 <jan> jan has joined #components
05:06:28 <emilio> hober: early break?
05:06:32 <emilio> [agreement]
05:06:34 <emilio> topic: end
05:15:13 <danclark_> danclark_ has joined #components
05:20:51 <rniwa> rniwa has joined #components
05:26:04 <Joshue108> Joshue108 has joined #components
05:26:18 <diervo> scribe: diervo
05:26:24 <Joshue108> present+
05:26:34 <pmdartus> present+
05:26:56 <jan> jan has joined #components
05:27:23 <Boaz_> Boaz_ has joined #Components
05:27:27 <diervo> present+
05:27:41 <Boaz_> Present+
05:28:01 <diervo> topic: AOM
05:28:19 <aboxhall_> https://github.com/whatwg/html/pull/3917
05:30:03 <zcorpan> zcorpan has joined #components
05:30:12 <zcorpan> present+
05:30:36 <jan> jan has joined #components
05:31:13 <diervo> annevk: AOM still uses frozen arrays?
05:31:20 <diervo> aboxhall_: yes
05:31:42 <diervo> Domenic: We could potentually use the new IDL for Arrys
05:31:50 <diervo> s/Arrys/arrays
05:33:14 <diervo> aboxhall_: id refs dont work across shadow boundaries
05:33:43 <diervo> [describing api]
05:34:13 <jan> jan has joined #components
05:34:21 <aboxhall_> https://github.com/WICG/aom/blob/gh-pages/explainer.md#reflecting-element-references
05:34:52 <jcraig> jcraig has joined #components
05:35:33 <diervo> 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)
05:36:08 <Joshue108> q+ to ask if there is an issue with shallow roots and AT
05:36:40 <diervo> annevk: from a shadow tree you can have an element in the light tree but not the other way around
05:37:14 <diervo> ??: there is no issues exposing this to assistive technologies
05:37:27 <diervo> rniwa: it shouldn't affect it
05:37:47 <zcorpan> (light tree = normal DOM tree, not inside shadow)
05:37:56 <diervo> rniwa: historicaly, because shadow root encapsulation, we allow insdide things outside but not the other way around.
05:38:22 <diervo> ... if you have any aria active descendent or any other attribute, it could reference something in the ancestry tree.
05:38:25 <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
05:38:53 <diervo> ??: bidirectionality
05:39:05 <diervo> annevk: what happens on remove? does it update?
05:39:09 <diervo> aboxhall_: the association holds
05:39:18 <diervo> annvek: you can point to something is not in the tree
05:39:20 <Joshue108> s/??:/Joshue108
05:40:05 <diervo> dot-minisculw: I think that is not a candidate to associate the element, it must be in hte DOM to be set
05:40:18 <diervo> s/dot-miniscule/dot-miniscule
05:40:25 <diervo> s/dot-minisculw/dot-miniscule
05:40:30 <John_Dai> John_Dai has joined #components
05:40:37 <diervo> annvk: Is it a problem that can point to an element that is not in the DOM?
05:41:16 <diervo> 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?
05:41:26 <diervo> annevk: label should not be able to point to something is not in the tree
05:41:32 <diervo> aboxhall_: what would happen?
05:42:06 <diervo> annvk: the label could be in the tree but not the thing it references to
05:42:18 <diervo> s/annvk/annevk
05:42:31 <diervo> Domenic: What about idrefs?
05:42:37 <diervo> annevk: when you remove the node, is no longer connected
05:43:13 <diervo> rniwa: in a form you have an id attribute no longer points to that element
05:43:31 <diervo> Domenic: the idl attribute still gives the reference to the same element
05:43:39 <diervo> rniwa: if that element happens to be the same id
05:43:56 <sanketj_> sanketj_ has joined #components
05:43:56 <diervo> annevk: we have the inverse, we have labels
05:44:07 <jdai> jdai has joined #components
05:44:09 <diervo> annevk: adding removeing labels work
05:44:12 <yoshiaki> yoshiaki has joined #components
05:44:32 <diervo> ??: that seems to make things mroe bittle beacuse their association will disapear
05:44:58 <diervo> hober: do I have to redo the association? I woulnd't have to in the old system
05:45:03 <zcorpan> s/??/zcorpan/
05:45:04 <yoshiaki> yoshiaki has joined #components
05:45:08 <jan_> jan_ has joined #components
05:45:21 <diervo> ... if we are going to offer a better api, it should be better otherwise will be in troubles
05:46:00 <Joshue108> agenda+ Is the AOM a suitable for broader semantic descriptions beyond WebComponents?
05:46:09 <diervo> smaug: would this cause an issue on webkit?
05:46:33 <diervo> rniwa: having a node in a document that references another node as a reference is might not be implementable
05:46:44 <diervo> ... we could figure out some magic, but will be very hard
05:46:45 <Joshue108> s/a suitable/a suitable model
05:47:04 <diervo> rniwa: its different case from iframes
05:47:24 <diervo> hober: I'm more concern about adoption than anything else
05:47:55 <diervo> ??: you could use any internal reference from an implmenetation point of view
05:48:26 <diervo> zcorpan: if we take the label-by for instance there is other way that you can make things out of the accesibility tree
05:48:37 <diervo> ... it can be in the DOM and still be ignore
05:48:39 <zcorpan_> zcorpan_ has joined #components
05:48:49 <diervo> ??: nothing of this change this proposal because it can already happen
05:48:53 <diervo> aboxhall_: this is an analogy
05:49:31 <diervo> aboxhall_: we could put a document method to know that is happening
05:49:43 <diervo> zcorpan: we could do it when we break the asscociation
05:49:56 <diervo> aboxhall_: do we want to allow setting elements as references which have never been added to the dom?
05:50:01 <diervo> zcorpan: the answer should be yes
05:50:09 <diervo> aboxhall_: to we allow returning that node as the value
05:50:23 <diervo> ... if I do elemenet.activeDecentant = neverAddedNode?
05:50:45 <diervo> ... if you set it to a disconected element, do you get it back?
05:51:05 <diervo> rniwa: I don't think we should allow it, a disconnected now would do anything
05:51:09 <yoshiaki_> yoshiaki_ has joined #components
05:51:11 <diervo> aboxhall_: its usefu to know it will resume
05:51:29 <diervo> rniwa: I just don't think we should create an API where its easy to do the wrong thing
05:52:00 <diervo> 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
05:52:07 <diervo> rniwa: why you don't have a tree?
05:52:16 <diervo> zcorpan: you might not know
05:52:25 <diervo> annevk: you can setup your association upfront
05:52:36 <diervo> zcorpan: the component might be a component at the top level, a light element
05:52:50 <diervo> ??: you could do this by setting up a list, which neither is in the dom
05:52:59 <diervo> aboxhall_: you are not prevented to do it today
05:53:13 <diervo> rniwa: its nonsensical to express a relationship where the things are not in the tree
05:53:23 <diervo> ... I disagree
05:53:39 <yoshiaki> yoshiaki has joined #components
05:54:19 <diervo> jan_: what are the problems?
05:54:44 <diervo> jan_: seems that its useful to express this relationships
05:54:53 <diervo> annevk: There is not precedent for this api shape
05:55:01 <diervo> jan_: for me this api feels more elegant
05:55:15 <diervo> ... seems that is a natural result
05:55:24 <diervo> annevk: how do we deal with ta node beign remove and inserted
05:55:41 <diervo> ... you still need to act on mutations
05:55:49 <diervo> rniwa: we can't expose the node inside the shadow tree
05:56:21 <diervo> Domenic: we could solve it as an implmentation detail
05:56:34 <diervo> ... you have a pointer that is a reference element and before returning it you do a bunch of checks
05:56:42 <diervo> annevk: how would that work?
05:57:03 <yoshiaki> yoshiaki has joined #components
05:57:04 <diervo> ... a refers to b, people looking at a gets null because its inside the shadow
05:57:11 <diervo> Domenic: I don't follow
05:57:20 <diervo> ... as far as the browser is concern there is no reference
05:57:29 <diervo> annevk: would still be an association
05:57:32 <diervo> Domenic: no
05:57:47 <diervo> Domenic: we can either null things out as they cross boundaries
05:57:51 <diervo> aboxhall_: or we do nothing
05:58:01 <diervo> ... treat it the same (violate encapsulation)
05:58:24 <diervo> rniwa: we can't expose it
05:58:55 <diervo> hober: when we do remove or add, things don't break you need to redo the work seems like a compromise
05:59:07 <diervo> aboxhall_: im ok with that
05:59:32 <diervo> rniwa: we might need to do it at insertion time or we might get into weird behaviour
06:00:17 <diervo> rniwa: if we do the violation at computation time, we could reference things in different tree, which creates circular dependencies
06:00:33 <diervo> hober: [trying to rephrase rniwa]
06:01:08 <diervo> 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
06:01:16 <diervo> hober: we could do cycle detection at insertion time
06:01:41 <diervo> rniwa: if we do it at the time of insertion, we could invalidation all the references
06:02:19 <diervo> hober: so you preserve the refernce, but you lost the ability to move thing around and keep them working
06:02:34 <diervo> ... the case of existing id attributes they still work
06:02:39 <diervo> rniwa: but do we care?
06:03:04 <diervo> ... I dont think we can make this better that id refs because its a string
06:03:31 <diervo> hober: this will be more brittle
06:03:58 <diervo> hober: do we understand where we are?
06:04:07 <diervo> hober: seems that there is no consensus?
06:04:20 <yoshiaki_> yoshiaki_ has joined #components
06:04:30 <diervo> zcorpan: an example - this feature doesn't need shadow root, you can use it with normal elements
06:04:40 <diervo> ... if you have a table and you want to do associaation with headers adn cells
06:04:58 <diervo> ... and there is not reasons why you wouldn't want to do the association prior
06:05:29 <diervo> ... with this apis this should work
06:05:46 <diervo> annevk: the equivalency its weird
06:05:49 <diervo> ... in some cases
06:06:05 <diervo> rniwa: seems that the insertion compromise might be good enough
06:06:19 <diervo> ... so you woulnd't have the crazy implementation complexity
06:06:23 <diervo> aboxhall_: so whats the summary?
06:06:40 <diervo> rniwa: do the validation when a node that references other node is inserted
06:07:18 <diervo> hober: by default we will get a lot of invalidations if things are in order
06:07:43 <diervo> rniwa: probably we need to speial case
06:08:21 <diervo> ??: this discussion is to avoid the current concern of leaking and circular referneces
06:08:26 <diervo> ... and encapsulation
06:08:44 <chrishall> chrishall
06:08:55 <zcorpan_> s/??/chrishall/
06:09:08 <diervo> rniwa: the fact that you can move elements you can get into circular dependencies
06:10:02 <diervo> chrishall: instead of invalidating a insert time we invalidate at computation time, when we try to follow the link
06:10:12 <diervo> annevk: you always get the object so you have to validate the object
06:11:10 <diervo> rniwa: [describing a complicated counter example]
06:12:05 <diervo> annevk: what is the problem exactly?
06:12:15 <diervo> chrishall: seems that still not a cycle
06:12:27 <diervo> ... do we need to remove the relationship entirely?
06:12:38 <diervo> rniwa: there is no other api where that node refernece exists
06:12:51 <diervo> annevk: maybe shadowroot?
06:13:10 <diervo> rniwa: yeah but that is intrisic to the shadow
06:13:19 <diervo> Domenic: slots are also like this
06:13:31 <diervo> annevk: the idea of validate something on the get is somewhat common IMO
06:13:41 <diervo> hober: where do we want to pay the cost?
06:13:54 <diervo> ... if w edo the vaidation on the get is more expesive
06:14:00 <diervo> ... on insert is a user cost
06:14:23 <diervo> annevk: in user land that looks like a lot of problems
06:14:34 <diervo> annevk: no weak references is hight level apis
06:14:38 <diervo> ... please!
06:15:18 <diervo> [debate about weak references brwoser implemnetation]
06:15:40 <diervo> annvek: are we saying that even if is disconected is null?
06:15:52 <diervo> aboxhall_: tree as in document?
06:16:28 <diervo> hober: can people file some issue about the alternatives?
06:16:28 <zcorpan_> (elements can be exposed to js after references have been removed if there's an event listener and it can still get events :) )
06:16:32 <diervo> topic: close
06:16:45 <Joshue108> TOPIC: Is the AOM a suitable interim architecture for more than Web Components, for example XR type applications?
06:17:18 <diervo> topic: AOM architecture
06:18:36 <xiaoqian> xiaoqian has joined #components
06:18:57 <diervo> Joshue108: there is a lack of semantics in other technologies from an accesibility perspective, how to address it?
06:19:19 <rniwa> rniwa has joined #components
06:19:27 <diervo> rniwa: how that relates to web components?
06:19:40 <diervo> Joshue108: beacuse the AOM was primarily defined for Web COmponents
06:19:52 <diervo> aboxhall_: there were also other use cases
06:20:18 <diervo> ... the usre input events for example is orthogonal, also virtual nodes,
06:20:31 <diervo> ??: historically the conversation have develop in parallel
06:21:33 <diervo> Joshue108: from the aom as it stands, is ti a suitable architecture?
06:21:44 <diervo> rniwa: not sure if this is the right forum
06:22:44 <diervo> topic: close
06:23:15 <hiroshige> hiroshige has joined #components
06:23:25 <diervo> topic: AOM web components
06:26:31 <JohnRiv> JohnRiv has joined #components
06:27:54 <diervo> [summarizing previous invariants and consensus]
06:28:34 <Domenic> https://html.spec.whatwg.org/multipage/forms.html#dom-lfe-labels see the example
06:30:06 <diervo> rniwa: insertion of computation would have the same restrictions
06:30:27 <diervo> chrishall: if you validate in insertation you are required teh author to inser them in teh right order
06:30:51 <diervo> rniwa: I think yes
06:31:29 <diervo> zcorpan_: seems like a tradeoff between cost for implementation vs. cost for web develoeprs
06:31:42 <diervo> rniwa: its the complexity of memory management
06:32:04 <diervo> aboxhall_: Im not clear of the behaviour rniwa wnats
06:32:18 <diervo> ... what the validation rules
06:32:29 <diervo> hober: [describing an example]
06:33:02 <diervo> rniwa: wheneve either node (reference, or referencee) at that point you run invalidation - which was pointed early will not work
06:33:42 <diervo> aboxhall_: why are we discussing the behaviour instead of what the user sees
06:33:57 <diervo> chrishall: I think we all agree that reference should survive add and remove
06:35:34 <tomalec> diervo: If we drop the reference integrity constraint, would that solve all the problems?
06:36:21 <diervo> zcorpan_: seems that we need to figure out if this is implementaable
06:36:50 <diervo> 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
06:37:19 <diervo> zcorpan_: if you have an element referenced and you remove it and put it back it should work
06:37:42 <diervo> ... then implementation have other requirements like not break encapsulation or not have circular dependnecies
06:37:56 <diervo> ... and the order shouldn't matter
06:39:03 <diervo> ... it needs to be implementabe
06:39:30 <annevk> annevk: perhaps cross-document needs to work due to HTML modules, if you import elements, set up relationships, then insert
06:39:31 <diervo> hober: this requirement seems like a low bar
06:39:53 <diervo> aboxhall_: Im unclear what it means to be invalid
06:40:27 <diervo> 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
06:41:26 <diervo> rniwa: if B is in another shadow tree that is not in the document thats bad too
06:41:52 <diervo> ... we can't reference two fully disconected trees
06:42:51 <diervo> topic: close
06:43:32 <zcorpan> zcorpan has joined #components
06:44:18 <zcorpan> zcorpan has joined #components
06:44:19 <ekashida> ekashida has joined #components
06:58:29 <yoshiaki> yoshiaki has joined #components
07:02:08 <rniwa> rniwa has joined #components
07:05:00 <rakina> rakina has joined #components
07:06:02 <zcorpan> zcorpan has joined #components
07:06:23 <jan> jan has joined #components
07:07:00 <pmdartus> scribe: pmdartus
07:07:22 <pmdartus> topic: Mitigate FOUC on CE
07:08:06 <pmdartus> Domenic: [present slides https://docs.google.com/presentation/d/1C3tzhdhB9wIOcJQv-PSzJE9kKhvVNU61Py1fYN2_5z0]
07:10:29 <pmdartus> Domenic: 2 problems: content that is not styled during the first render, invisible content that is visible before the script loads
07:11:28 <pmdartus> Domenic: option 1: use the :not(:defined) selector
07:11:45 <pmdartus> Domenic: option 2: use classic script to block the rendering
07:11:50 <whsieh> whsieh has joined #components
07:15:37 <pmdartus> ... introduce a new syntax to block the HTML parser when processing a certain element
07:16:00 <pmdartus> ... associating a module with a set of elements it defines
07:16:50 <pmdartus> ... challenges is it possible to actually block the parsing?
07:17:52 <sanketj_> sanketj_ has joined #components
07:18:17 <xiaoqian> xiaoqian has joined #components
07:18:21 <pmdartus> annevk: Since there are discrepancies between implementations, can we add a hit to not paint until DOMContentLoaded
07:18:22 <yoshiaki> yoshiaki has joined #components
07:19:27 <tomalec> q+ to mention that declarative-shadow-dom could also somehow mitigate FOUC.
07:19:32 <pmdartus> fergal_daly: Maybe we should annotate the markup to not paint certain content
07:21:35 <pmdartus> kouhei: There is a primitive when to paint, we need a primitive to tell not to paint. Maybe we should combine them?
07:22:28 <kouhei> kouhei has joined #components
07:24:08 <pmdartus> annevk: What should we block?
07:25:32 <pmdartus> 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.
07:25:55 <pmdartus> annevk: Why not blocking the rendering at all?
07:26:27 <pmdartus> Domenic: Because it prevents interaction with what have been already rendered
07:29:39 <zcorpan> zcorpan has joined #components
07:29:52 <pmdartus> Domenic: All the proposal are similar to font-display: fallback, ...
07:31:34 <pmdartus> Domenic: How does framework authors are currently solving this issue?
07:32:06 <pmdartus> jan: I would like to come up at a page level with a strategy on how to resolve unknown custom elements
07:33:12 <pmdartus> diervo: Would a customer accept that an entire page gets slower?
07:33:16 <danclark> danclark has joined #components
07:33:30 <pmdartus> Domenic: This really targets components that need to be present at first load.
07:34:21 <xiaoqian> xiaoqian has joined #components
07:34:52 <pmdartus> ??: Does display locking helps with this use case?
07:35:34 <pmdartus> Domenic: Yes it's related
07:36:34 <pmdartus> fergal_daly: There is maybe a distinction between some component like toggles and container components
07:36:57 <pmdartus> fergal_daly: visible vs. invisible components
07:37:22 <pmdartus> diervo: The element attributes can contains multiple tag names
07:37:30 <pmdartus> Domenic: Yeah it's possible
07:38:21 <pmdartus> rniwa: It's interesting that there is no blocking behaviors for module scripts
07:40:23 <pmdartus> Domenic: Good feedback, need more investigation. Will come back with a concrete proposal.
07:40:44 <pmdartus> topic: JSON modules
07:41:15 <yoshiaki> yoshiaki has joined #components
07:41:21 <pmdartus> danclark: Implemented behind experimental flag in Chromium
07:41:48 <pmdartus> ... Any concern with this proposal? Any interest from other implementers?
07:43:08 <pmdartus> hober: There is no difference between JSON and JS import in terms of syntax. This is pretty insecure.
07:43:19 <pmdartus> Domenic: It's done in NodeJS
07:43:38 <pmdartus> rniwa: It's not because Node implements it that we should do it
07:46:36 <pmdartus> rniwa: 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)
07:47:17 <pmdartus> annevk: img element already support multiple mime-types
07:51:07 <pmdartus> hoder: we want that the importer to provide a signal to know what is the expected module type.
07:52:13 <pmdartus> annevk: Can we use the import map to store this information?
07:52:43 <pmdartus> Domenic: This is far fetched, import map is only used to remap URL.
07:54:06 <pmdartus> rniwa: this is a problem for all module types. Same issue with CSS module.
07:55:21 <pmdartus> fergal_daly: Imagine an API returning weather data, it would be bad if it loaded some JS instead.
07:55:49 <pmdartus> annevk: having an opt-in is not great because dev will not opt-in.
07:57:14 <pmdartus> Domenic: We should use CSP to block the request
07:58:40 <pmdartus> 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
08:00:04 <pmdartus> Domenic: Let's fix the CSPs instead of inviting some new blocking mechanism
08:01:07 <pmdartus> hoder: an opt-in is not great, I would rather let the developers opt-out
08:01:22 <pmdartus> s/hoder/hober
08:02:58 <pmdartus> annevk: We will need some a new CSP primitive
08:05:07 <pmdartus> pmdartus: Why not using prefix or a suffix?
08:05:24 <pmdartus> rniwa: Yes it would solve the issue
08:06:01 <pmdartus> Domenic: TC39 recommend not messing up with the string and use an out-of-band signal
08:07:26 <masonfreed> masonfreed has joined #components
08:08:42 <pmdartus> annevk: We have done CORS XHRs to have by default safe communication with cross domains, but this proposal is not secure by design.
08:09:07 <pmdartus> Domenic: I don't understand why this is a security issue.
08:11:24 <pmdartus> ??: It's good feedback, we will come back with a new proposal.
08:12:09 <yoshiaki_> yoshiaki_ has joined #components
08:12:24 <hober> RRSAgent, generate minutes
08:12:24 <RRSAgent> I have made the request to generate https://www.w3.org/2019/09/17-components-minutes.html hober
08:12:31 <hober> RRSAgent, make minutes public
08:12:31 <RRSAgent> I'm logging. I don't understand 'make minutes public', hober.  Try /msg RRSAgent help
08:12:37 <hober> RRSAgent, make public
08:12:37 <RRSAgent> I'm logging. I don't understand 'make public', hober.  Try /msg RRSAgent help
08:12:55 <zcorpan> zcorpan has joined #components
08:28:19 <pmdartus> pmdartus has joined #components
08:29:33 <ekashida> ekashida has joined #components
08:30:01 <zcorpan> zcorpan has joined #components
08:30:31 <zcorpan> zcorpan has joined #components
08:35:07 <zcorpan> zcorpan has joined #components
08:47:01 <pmdartus> pmdartus has joined #components
08:48:11 <pmdartus> pmdartus has joined #components
08:53:48 <zcorpan> zcorpan has joined #components
09:22:30 <yoshiaki> yoshiaki has joined #components
09:41:43 <ekashida> ekashida has joined #components
09:47:21 <yoshiaki> yoshiaki has joined #components
12:06:13 <rniwa> rniwa has joined #components
12:30:53 <xiaoqian> xiaoqian has joined #components
14:33:24 <yoshiaki> yoshiaki has joined #components
19:25:51 <ekashida> ekashida has joined #components