IRC log of components on 2019-09-17
Timestamps are in UTC.
- 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