13:18:00 <RRSAgent> RRSAgent has joined #components
13:18:00 <RRSAgent> logging to https://www.w3.org/2019/04/25-components-irc
13:18:07 <Zakim> Zakim has joined #components
13:18:12 <slightlyoff> einsweniger: yes!
13:18:24 <hober> present+
13:19:20 <hober> rrsagent, this meeting spans midnight
13:19:20 <einsweniger> slightlyoff: in here?
13:19:57 <kouhei> hi! I'm kouhei (@nyaxt) from Google. He/him. Chrome loading platform TL. I'm particularly interested in modules (excited to see HTML, CSS, JSON... in the agenda :)
13:20:51 <einsweniger> Hi, I'm -1 (he/him, @einsweniger), almost graduated CS Master student from Germany, and I'm here because I'm curious about everything on the agenda and how these standards are developed. Particularly interested in Web Components and procedure in W3C/WHATWG.
13:20:59 <hober> rrsagent, make logs world-visible
13:21:25 <Dave_Batiste> Dave_Batiste has joined #components
13:22:08 <maqrgaree> maqrgaree has joined #components
13:22:29 <hober> Meeting: Web Components
13:22:35 <hober> Chair: annevk
13:22:48 <Stacey> Stacey has joined #components
13:22:56 <hober> Agenda: https://github.com/w3c/webcomponents/issues/802
13:23:29 <diervo> Can someone share me the link for the hangout so I can get Caridy to join?
13:24:01 <slightlyoff> I suspect annevk can (although it's not Hangouts, IIRC)
13:24:49 <bkardell_> I am Brian Kardell, I am a developer advocate from igalia and involved in a lot of standards discussions. I have also been a user of web components during all of the stages over the years in real sites - I am interested in the platform continually getting better for us all.
13:24:57 <BoCupp> BoCupp has joined #components
13:25:19 <hober> ScribeNick: diervo
13:25:58 <dlockhart> dlockhart has joined #components
13:26:42 <diervo> [Topic]: Web Component Modules [Travis, Daniel, Bo]
13:27:21 <annevk> diervo: justin: you can invite others by having them join https://v.mozilla.com/flex.html?roomdirect.html&key=jC3VkZxiaF
13:27:33 <annevk> diervo: justin: they'll need to install Vidyo
13:27:34 <tomalec_> tomalec_ has joined #components
13:28:28 <diervo> Following TC39, I will not take notes for the presentation itself unless you tell me otherwise
13:28:57 <annevk> diervo: sgtm
13:29:30 <sfdc_iurie> sfdc_iurie has joined #components
13:33:19 <jlin> jlin has joined #components
13:34:32 <justin> thanks @annevk
13:36:07 <pmdartus_> pmdartus_ has joined #components
13:44:21 <rniwa> rniwa has joined #components
13:44:32 <gregwhitworth> gregwhitworth has joined #components
13:49:02 <caridy> caridy has joined #components
13:55:42 <hober> q+ example
13:55:43 <justin> q+ internal vs external modules
13:55:50 <hober> yeah, just q+
13:55:53 <JanMiksovsky> JanMiksovsky has joined #components
13:55:55 <hober> q+
13:55:57 <justin> q+
13:56:00 <hober> q- example
13:56:03 <hober> q- hober
13:56:05 <annevk> q+ to say something
13:56:08 <annevk> ack anne
13:56:08 <Zakim> annevk, you wanted to say something
13:56:29 <hober> ack justin
13:56:32 <caridy> about HTML modules, I think we should continue to focus on the low-level pieces. once you offer an authoring format... it is game over because folks will continue to ask more and more high level apis for the authoring format.
13:57:12 <NavidZ_> NavidZ_ has joined #components
13:57:36 <caridy> additionally, bundling forces us to compile to JS... while this format allows tapping into the browser parsing and caching mechanism... as a bundling mechanism I do like it... as encapsulation mechanism, I like it... as an authoring format, I don't think we should consider it so.
13:57:49 <diervo> justin: Im concerned that inline vs external scripts will no longer be semantically equivalent
13:58:02 <rniwa> q?
13:58:20 <slightlyoff> caridy: can you say more (or cue up a comment) on the authoring format point?
13:58:24 <Ruphin> q+
14:01:06 <annevk> jlin++
14:06:05 <pmdartus> pmdartus has joined #components
14:08:24 <bferrua> bferrua has joined #components
14:08:52 <rniwa_> rniwa_ has joined #components
14:10:34 <diervo> justin: There are ways with primitives to avoid the magic specialization
14:10:50 <annevk> ack Ruphin
14:10:59 <diervo> anne: You have concerns with having inline scripts having specific/different behaviour
14:11:22 <sfdc_iurie> sfdc_iurie has joined #components
14:11:45 <diervo> ruphin: how this will work with bundlers where everything is compiled in one file?
14:11:55 <annevk> s/anne/BoCupp/
14:12:41 <diervo> slightyoff: You can solve that by the web packaging proposal.
14:13:27 <diervo> ruphin: backwards compatibility will have to be addressed
14:14:36 <justin> q+
14:15:21 <diervo> ruphin: the leaf node only styles support all the use cases and will be much more easier to implement
14:15:35 <diervo> annevk: what would you want to happen with script in the leaf scenario?
14:15:51 <diervo> ruphin: I don't know...
14:15:54 <rniwa_> q+
14:16:20 <rniwa> Zakim: q- rniwa_
14:16:23 <rniwa> Zakim: q+
14:16:27 <rniwa> q+
14:16:33 <rniwa> q- rniwa_
14:16:38 <diervo> BoCupp: The document will be innert, and we might be able to fail to load the module graph.
14:16:58 <diervo> +q
14:17:22 <annevk> q+ to ask if we can get from leaf to cycle if we ban script et al
14:18:30 <annevk> ack justin
14:18:34 <annevk> ack rniwa
14:18:36 <diervo> justin: complexity vs. adoption: how do we balance this will be a tricky quesiton
14:19:36 <annevk> q-
14:19:36 <diervo> rniwa: In order for this feature to be useful needs to be part of the module graph
14:20:26 <diervo> rniwa: I think we have precedences for some difference in behavior in external vs inline, so I'm support the proposal in favor of simplicity
14:22:33 <justin> q+
14:23:52 <Domenic> Domenic has joined #components
14:24:59 <annevk> ack diervo
14:25:02 <slightlyoff> perhaps there's a way for the import syntax to make a graph inert (or not)
14:25:03 <annevk> ack justin
14:25:17 <Ruphin> q+
14:25:22 <slightlyoff> I hear what diervo is saying: there's a time and a place for primitive-only
14:25:46 <sfdc_iurie> sfdc_iurie has joined #components
14:25:57 <slightlyoff> so maybe something like `<script type="module" src="component.html" inert>`?
14:26:32 <slightlyoff> the idea here would be that you'd basically turn off the script running in the inert case
14:26:44 <slightlyoff> would that solve it for you, diervo?
14:27:14 <diervo> justin: single file component was very important
14:27:23 <diervo> justin: for a lot of communities
14:27:51 <littledan> littledan has joined #components
14:28:15 <annevk> q?
14:28:19 <caridy> load them, let the browser to parse them
14:28:19 <caridy> cache then
14:28:19 <caridy> and let me link them together on my own
14:28:23 <diervo> pmdartus: declarative is very important because people don't want to have to write javascript
14:28:43 <tomalec_> q+
14:28:43 <caridy> but yes, we want to ability to load all these things...
14:28:48 <slightlyoff> caridy: would an inert flag (see ^^^) do what you want?
14:29:01 <annevk> ack Ruphin
14:29:10 <josh> josh has joined #components
14:29:47 <diervo> ruphin: for components to be authored it will be nice to have a canonical way to import components
14:30:11 <diervo> +q
14:31:01 <caridy> slightlyoff: yes, something like that
14:31:15 <diervo> ruphin: do we think HTML imports should be the canonical way
14:31:23 <annevk> q?
14:31:40 <annevk> ack diervo
14:31:46 <slightlyoff> caridy, diervo: so maybe we can propose something like that to BoCupp?
14:32:05 <bkardell_> I can offer that I worked for a company that had authors of pages that benefited from declarative use, and also a separation of specialties for those creating components in which many of the important people in that were not javascript oriented
14:32:06 <justin> q+
14:33:26 <diervo> tomalec_: Upvote for non-javascript web developers
14:33:30 <tomalec_> ack tomalec_
14:33:30 <slightlyoff> ISTM that the big difference here is "who runs script?" and enabling that to be more opt-in feels like it'll put your style of system in control w/o breaking the default symmetry with `<script type="module">`
14:33:42 <kouhei> +q
14:34:25 <muan> muan has joined #components
14:35:07 <rniwa> +q
14:35:07 <rniwa> q+
14:35:13 <gregwhitworth> q+
14:35:53 <annevk> ack justin
14:36:02 <kouhei> via IRC
14:36:05 <diervo> justin: What single file component framework owners would think, would they use them in favor of their internal transformation
14:36:06 <pmdartus_> pmdartus_ has joined #components
14:36:08 <kouhei> I also want to express support for enabling HTML+CSS+JS single file use-case via HTML modules.
14:36:13 <kouhei> I'm convinced that we want to have more than just inert for the use-case. Having said that, I think we still want to find a right balance that enables the single-file use-case while minimizing special and tricky behaviors. I have strong preference on having something transpilable.
14:37:42 <annevk> ack kouhei
14:37:46 <annevk> ack rniwa
14:37:54 <gregwhitworth> ack gregwhitworth
14:37:59 <diervo> rniwa: we all want import HTML a a module
14:38:26 <diervo> rniwa: Do you want to have script? Then you can't have leaf module
14:38:57 <slightlyoff> q+
14:39:12 <rniwa_> rniwa_ has joined #components
14:39:38 <rniwa_> q?
14:39:58 <diervo> slightlyoff: maybe we can have both: one behaviour where everything is innert, and another behaviour we can do module graph
14:41:16 <rniwa_> q+
14:41:56 <annevk> ack slightlyoff
14:42:00 <annevk> ack rniwa_
14:42:35 <diervo> rniwa: what is the point of importing an HTML you can do that already...
14:42:56 <diervo> Bo: The semantics of the module import
14:43:22 <diervo> annevk: we can optimize it on browser land
14:44:25 <gregwhitworth> q+
14:44:49 <diervo> Ruphin: there is a large group of developers where they desire to write raw HTML (without any hackery innerHTML, string concat)...
14:45:02 <justin> should we move on to CSS modules?
14:45:16 <dlockhart> With Polymer 1 & 2 that used HTML imports, the portion of the polyfill that did the import was a major source of performance issues for us in IE11 and Edge. As soon as we moved to Polymer 3 and Lit with plain JS files again we got an order of magnitude improvement.
14:45:39 <bkardell_> can someone minute the hand show poll
14:45:57 <slightlyoff> bkardell_: yes
14:46:22 <diervo> slightlyoff: who would object of a version of this if tehre is no control to turn it off?
14:47:12 <gregwhitworth> ack gregwhitworth
14:47:51 <slightlyoff> consensus of the room (to be explored externally): not a deal-breaker if script executes
14:48:13 <diervo> BoCupp: we will keep exploring since there is no objection
14:48:35 <slightlyoff> 👍
14:51:56 <diervo> [Moving on to JSON and CSS modules]
14:52:27 <annevk> q?
14:52:30 <diervo> Dan_Clark: We show support for CSS and JSON modules proposal (from Microsoft)
14:54:10 <diervo> [CSS Modules] - Justin
14:56:48 <sfdc_iurie> sfdc_iurie has joined #components
14:57:59 <gregwhitworth> justin: is there a spec proposal for CSS References?
14:58:36 <diervo> BoCupp: We should discuss if HTML import would have a different mime/type
14:59:00 <diervo> diervo: Salesforce would love to see CSS and HTML import to move forward
14:59:16 <diervo> pmdartus: Why would we like a new mime type?
15:00:26 <tomalec_> q+
15:00:46 <kouhei> q+
15:01:38 <justin> greg: https://github.com/w3c/csswg-drafts/issues/3714
15:02:08 <justin> oh... CSP
15:04:31 <diervo> tomalec: I was excited to be able to detect some of this behaviors
15:05:08 <diervo> annevk: We don't want to have a specific attribute on script if we can avoid it to disambiguate the behavior
15:05:16 <rniwa_> q+
15:05:43 <justin> q+
15:05:45 <hober> q+ slightlyoff hober
15:05:48 <annevk> q?
15:05:51 <tomalec_> ack tomelc_
15:05:54 <annevk> ack tomalec_
15:06:00 <kouhei> For the different processing semantics, can we rely on <html> tag attribute like <html module> or some other signal inside the html source stream?
15:06:08 <pmdartus> pmdartus has joined #components
15:06:33 <hober> q- slightlyoff
15:07:49 <rniwa> rniwa has joined #components
15:07:55 <rniwa> q?
15:10:10 <diervo> slightlyoff: we could have required a pragma for detecting wether the script where meant to be used as a module, today you can't
15:10:29 <diervo> Ruphin: what the ecosystem is doing is inventing new formats to solve this
15:10:34 <annevk> q?
15:10:47 <kouhei> I already posted above and has it read
15:10:50 <kouhei> thanks!
15:10:51 <kouhei> -q
15:11:02 <annevk> ack rniwa_
15:11:20 <sfdc_iurie> sfdc_iurie has joined #components
15:11:57 <littledan> The possibility of making multi-mode scripts (as the upgrade story) was a big, frequently made argument for why we must not have a sigil, in ES modules
15:12:21 <diervo> rniwa: We have a few concerns with changing the parser and also the potential problems on adding new mime/types (ex. proxy compatibility)
15:12:39 <slightlyoff> my specific suggestion here, as an alternatife to a new mimetype, would be a requirement for something like a pragma like `<!DOCTYPE module-html>`
15:12:41 <littledan> The idea was that additional mimetypes, file extensions, pragmas, etc would be difficult to adopt, whereas something in the script tag is easier
15:12:46 <slightlyoff> *alternative
15:12:50 <Travis> q+ Travis
15:13:10 <muan> muan has joined #components
15:13:16 <annevk> q+ to say that putting it inline is more complex as it requires changes the HTML parser
15:13:57 <littledan> If this is broadly understood to be an error, that's news to me; I thought the advocates of this design still believed in it
15:14:12 <hober> ack justin
15:17:14 <caridy> littledan, that's correct... we definitely have two camps there... I'm partially to be blame for some of that... Dave Herman, Yehuda and myself spent a lot of time on this topic... we really wanted to safe the .js filename... and I think time will tell, but yes... I also agree with @slightlyoff that we could have better solutions and we didn't foresee all the problems when modules were initialized designed.
15:17:27 <caridy> *save
15:17:50 <diervo> b: I think the multiple mime type is a no-go for all the reasons we talked about specially parsing, etc
15:18:09 <caridy> https://github.com/dherman/defense-of-dot-js
15:18:09 <diervo> maggie: ^^
15:18:53 <caridy> that proposal covers a lot of topics, including mimetype and other out of band signals for modules that will apply to html as well
15:19:27 <hober> ack hober
15:20:35 <caridy> I can see in "defense-of-dot-html" with similar constrains
15:20:53 <slightlyoff> caridy: so this argues to me for an internal sigil
15:22:07 <caridy> for js, time will tell, but I do 100% agree with you that we should not make similar mistake for html... yes... I do agree with you that for HTML, the sigil-like is probably good enough
15:23:11 <diervo> annevk: I'm still worried about having different mime-types or changing the HTML parsing (backwards compatibility)
15:24:09 <caridy> jajaja... see! defense-of-dot-html is coming soo I guess!
15:24:30 <diervo> ruphin: if pragma doesn' work,  how do we know on the server what mime-type to serve if they have the same extension?
15:24:49 <slightlyoff> q+
15:25:51 <justin> q+
15:25:54 <caridy> I want to conversation to go back to the root question, what exactly does it do when you load the html module directly? can we compromise there rather than get into this other converstaion?
15:27:23 <diervo> slightyoff: If we are going to have a different behavior, we should entertain the idea of a different mimetype
15:28:36 <diervo> maqrgaree: Agree with Alex,  I would rather have the syntax be as close as possible
15:28:49 <hober> s/maqrgaree/hober/
15:29:00 <diervo> BoCupp: Would the decision of leaf modules (innert) vs scriptted modules has an impact here?
15:29:19 <justin> s/BoCupp/Travis
15:29:29 <caridy> well said @slightlyoff! also, if the html is mostly a build target, then a different ext is just fine... you don't need IDEs and stuff... but as an authoring format, maybe it will take a while...
15:30:29 <littledan> q+
15:31:13 <diervo> annevk: Is the difference meanigful: If you navigate directly what happens? Do we care?
15:31:28 <diervo> justin: we need to enumerate the different problem
15:32:14 <diervo> BoCupp: So do we want to make it require a doctype and be more strict ?
15:32:17 <diervo> annevk: Maybe?
15:32:47 <diervo> annevk: We should go for the ergonomics
15:33:04 <diervo> annevk: I don't really see a new mime-type will be a big adoption hurdle
15:33:29 <diervo> ruphin: Having a new file type will be problematic from a developer perspective
15:35:17 <kouhei> new mimetype may mean it would be unusable in local filesystems (until OS updates to register one)
15:35:31 <diervo> BoCupp: thanks for the feedback
15:35:56 <diervo> [Custom pseudo classes]
15:36:09 <pmdartus_> pmdartus_ has joined #components
15:37:47 <caridy> I think @littledan was waiting on the queue...
15:37:57 <caridy> @annevk
15:38:04 <Domenic> I'm not sure we should do custom pseudo classes until we do ElementInternals in general
15:38:30 <Domenic> I would like to do ElementInternals + form-associated custom elements as a block, then other ElementInternals use cases like custom pseudo-classes.
15:39:06 <littledan> caridy: I was just going to relay some more context about the JS experience, but the timebox for this topic is up, so I'm fine to skip the comment and write it somewhere in GitHub if we end up continuing this topic
15:41:21 <caridy> caridy has joined #components
15:42:18 <rniwa> rniwa has joined #components
15:42:24 <annevk> https://github.com/w3c/webcomponents/issues/738
15:42:58 <Domenic> Gah Vidyo crashes. Will try my laptop.
15:43:26 <annevk> https://github.com/whatwg/dom/issues/533
15:44:04 <annevk> https://github.com/whatwg/dom/issues/533#issuecomment-459246383
15:44:15 <caridy> initially I did agreed with this... but then backpedal
15:44:39 <caridy> the main situation is that in many cases you want that be done sync.
15:45:07 <caridy> rather than waiting for the next tick
15:46:04 <hober> https://github.com/whatwg/dom/issues/533#issuecomment-366479191
15:46:09 <pmdartus_> q+
15:46:20 <Travis> q-
15:46:28 <annevk> q-
15:47:03 <littledan> q-
15:48:58 <caridy> for local components and private components
15:49:09 <caridy> and elements with the same name
15:49:51 <caridy> but this applies to anything... imagine that you just have a lib that creates an element... and that lib wants to control that... doing things only when the element is inserted or removed
15:49:54 <Travis> [previous modules topic]: link to HTML modules presentation: https://1drv.ms/p/s!AunvHLyCu51yiN1--9FGpN4wnxz41w
15:50:03 <caridy> where the lib doesn't know when and who will insert that element...
15:50:36 <caridy> so, we want to have the same behavior as of WC, where the reaction is sync
15:52:36 <justin> q+
15:53:16 <slightlyoff> q?
15:53:22 <slightlyoff> q-
15:54:55 <caridy> caridy has joined #components
15:55:30 <_caridy> _caridy has joined #components
15:55:41 <Domenic> Are people suggesting un-deprecating DOMNodeAttachedToDocument!?
15:56:16 <Domenic> rather, DOMNodeInsertedIntoDocument/DOMNodeRemovedFromDocument
15:58:09 <slightlyoff> I'm having a hard time telling = )
15:59:01 <pmdartus_> q-
15:59:08 <_caridy> for us, an event... or an api on the element will work fine
15:59:13 <_caridy> this is NOT about custom elements
15:59:20 <_caridy> but arbitrary elements
15:59:41 <_caridy> additionally,..
16:00:00 <_caridy> custom elements hooks (connetedCallback and disconnectedCallback) are very co=umbersome
16:00:07 <_caridy> thinks about mixins
16:00:22 <_caridy> how can you have a mixin for a custom element that participate on the connect/disconnect cycle?
16:00:30 <tomalec_> q+
16:00:40 <_caridy> it is impossible because you depend on the subclassing to call super.connectedCallback()
16:01:11 <_caridy> the same for regular inheritance, e.g.: XFoo extends XBar that extends HTMLElement
16:01:19 <_caridy> how can XBar participate on the lifecycle?
16:01:46 <_caridy> for us... we have LightningElement as a base class
16:02:34 <tomalec_> ack tomalec_
16:02:52 <justin> q-
16:03:04 <_caridy> YES! that will work
16:04:42 <_caridy> q+
16:06:08 <pmdartus> pmdartus has joined #components
16:07:09 <rniwa> q?
16:07:30 <Ruphin> Your microphone is not very clear
16:07:36 <Ruphin> Perhaps you should type your comment
16:08:17 <sfdc_iurie> sfdc_iurie has joined #components
16:08:49 <_caridy> sorry, vidyo crashes
16:09:20 <_caridy> my comment: this is not only about CE, but if you look at it from the CU perspective, it is also important... mixins and inhertiances are very error prompt
16:09:28 <moztor> moztor has joined #components
16:09:54 <_caridy> a subclass defining connectedCallback and not calling the super makes mixins and other super classes completely out of the life cycle
16:10:10 <_caridy> with an event, they could rely on it... for example
16:10:46 <_caridy> similarly for general libraries that have access to or create an element... they want to know when to do something rather than assume the element is already attached...
16:10:59 <Domenic> Normally I am all for solving TC39 problems (mixins are error prone) in the web space, but this really feels like a strange way to do so.
16:11:23 <annevk> q?
16:12:00 <_caridy> domenic, it is just a way to observe the state of .isConnected
16:12:03 <_caridy> that's all
16:12:25 <Domenic> Well, but you can already, if your mixee calls super.connectedCallback() per the mixin contract.
16:13:16 <diervo> correct but relies on the developer do the right thing
16:13:22 <_caridy> for custom element, it is partially possible... we do a lot of gymnastics here... for services and other stuff that need to observe the state of the element, but in general, it is important for us to have a reliable way to react to insertion and removal, including performance
16:13:38 <Domenic> Yep. That's why I'm saying, if mixins are hard for developers to do the right thing around, that's a language-level problem, IMO.
16:13:47 <tomalec_> Domenic, but you can do that only as an author of the class. I believe the issue is about possibility for an user of an instance of random node.
16:14:09 <Domenic> tomalec_: well, but that's in conflict with the desire to avoid the multi-actor problem.
16:15:23 <caridy> caridy has joined #components
16:15:42 <annevk> q?
16:15:45 <annevk> ack caridy
16:15:49 <annevk> ack _c
16:16:52 <caridy> q-
16:17:04 <caridy> an event works for us, yes!
16:17:05 <rniwa_> rniwa_ has joined #components
16:18:19 <diervo> For the record, Salesforce position: An Event or a sync API that will allow us to detect connect/disconnect
16:18:20 <pmdartus> pmdartus has joined #components
16:18:29 <diervo> we are in favor of :)
16:22:25 <Domenic> (Nobody tell them about DOMNodeInsertedIntoDocument/DOMNodeRemovedFromDocument...)
16:35:55 <smaug> not implemented everywhere
16:49:11 <caridy> caridy has joined #components
16:52:48 <JanMiksovsky> JanMiksovsky has joined #components
16:53:55 <DanClark> DanClark has joined #components
16:58:24 <tomalec_> tomalec_ has joined #components
16:59:08 <pmdartus> pmdartus has joined #components
16:59:57 <bferrua> bferrua has joined #components
17:00:19 <rniwa> rniwa has joined #components
17:02:36 <caridy> @domenic, in fact our current solution is partially using DOMNodeInsertedIntoDocument/DOMNodeRemovedFromDocument in chrome and safari, but we want an standard, non-deprecated, way to do this.
17:03:28 <hober> ScribeNick: slightlyoff
17:03:33 <slightlyoff> thanks
17:03:49 <vmpstr> vmpstr has joined #components
17:03:50 <josh> josh has joined #components
17:03:58 <justin> justin has joined #components
17:04:02 <slightlyoff> (inaudible)
17:04:19 <slightlyoff> slightlyoff: is the agenda ordered for the afternoon?
17:04:22 <slightlyoff> (no)
17:04:41 <slightlyoff> suggestion; let developers feature use-cases
17:04:52 <slightlyoff> annevk: an hour for this topic
17:05:00 <slightlyoff> (call for presentations)
17:05:04 <slightlyoff> 4 presentations
17:05:12 <slightlyoff> 10 minutes each, 5 minutes for questions
17:05:42 <slightlyoff> pmdartus to present
17:06:01 <slightlyoff> pmdartus from Salesforce, presenting "Web Components at Salesforce"
17:06:09 <slightlyoff> (slides to be linked)
17:06:44 <slightlyoff> pmdartus: the thing that is interesting in the UI is that everything is customizable; not only by us, but also by customers
17:07:01 <slightlyoff> pmdartus: they can install components from other vendors too; not just from us
17:07:13 <slightlyoff> pmdartus: also want flexibility to provide multiple versions of a component on a page
17:07:34 <slightlyoff> pmdartus: updates to componetns aren't mandatory, so need to not break
17:07:50 <slightlyoff> pmdartus: styling is under user/developer control
17:08:16 <westbrook> same.
17:08:16 <slightlyoff> pmdartus: requirements: back-compat, management of evolution, encapsulation, composition
17:08:48 <slightlyoff> pmdartus: "Realization: our platform happens to share the same constraints and features as the web platform!"
17:09:02 <slightlyoff> pmdartus: Lighting Web Components; the Salesforce UI approach
17:09:14 <slightlyoff> pmdartus: same WC building blocks
17:09:54 <slightlyoff> pmdartus: 3 layers: WC standards, LWC (on top of WC), and Salesforce Integrations (highest level)
17:10:25 <slightlyoff> pmdartus: 80% of customers use out-of-the-box experience; base components and CSS custom properties
17:10:42 <slightlyoff> pmdartus: in the middle, e.g. Hulu, where they use the base components + custom components
17:10:52 <slightlyoff> pmdartus: CSS Custom Properties for styling
17:11:25 <slightlyoff> pmdartus: at the high end, websites like Addidas. Few base components, full-custom on top of the platform. CSS Custom Properties and constructable stylesheets
17:12:04 <slightlyoff> pmdartus: use-case: multi-author; what if multiple partners define a `<custom-list>`?
17:12:30 <slightlyoff> pmdartus: also, multi-version. One component might use v1 of `<lighting-icon>` while another might use v2
17:12:39 <slightlyoff> pmdartus: looking fowrard to scoped registries to help
17:12:48 <slightlyoff> pmdartus: final use-cases are around Server-Side Rendering
17:13:13 <slightlyoff> pmdartus: Addidas, e.g., need SEO and to support a full range of browsers (including with JS disabled)
17:13:26 <slightlyoff> pmdartus: working to explore how to serialize/rehydarate
17:13:37 <slightlyoff> questions?
17:13:47 <slightlyoff> JanMiksovsky: how do you make use of constructable stylesheets?
17:14:40 <slightlyoff> pmdartus: goal is to create shared stylesheets that customers can write. Injected into all SDs, with limits on some selectors. Can speak more about how `::theme` and `::part` may not be the best way forward for us
17:15:01 <slightlyoff> rniwa: seems very similar to what we desiged WC for. Has it worked for your use-cases?
17:15:23 <slightlyoff> pmdartus: has worked well; but what are we using today? But we emulate Shadow DOM, emulate Custom Elements APIs, etc.
17:15:29 <pmdartus_> pmdartus_ has joined #components
17:15:48 <justin> is everyone on the video call muted? There are some noises coming through.
17:16:24 <slightlyoff> pmdartus: we might provide toggle at some point; still a lot of IE11 users
17:16:42 <slightlyoff> rniwa: so it sounds like the scoped registry is a showstopper?
17:16:44 <slightlyoff> pmdartus: yes
17:16:50 <slightlyoff> rniwa: server-side rendering too?
17:17:02 <slightlyoff> pmdartus: a native approach there or canonical implementation could help
17:17:29 <slightlyoff> diervo: 50% of our traffic is still IE 11 😭
17:17:39 <caridy> to clarify... everything is solvable...
17:17:41 <slightlyoff> (down to 48)
17:18:09 <muan> muan has joined #components
17:18:20 <caridy> registry is a big problem for us... because in our business model, you can only use components that you buy or are free to use...
17:18:33 <slightlyoff> thanks, caridy
17:18:34 <caridy> think about it from that perspective
17:18:48 <caridy> so, having local registry is very important for us...
17:18:52 <slightlyoff> JanMiksovsky presenting
17:19:08 <slightlyoff> JanMiksovsky: Elix
17:20:09 <slightlyoff> JanMiksovsky: worked on Shadow DOM v0; 7 years of experience
17:20:10 <caridy> then when you go into that mode... you have to take into account that different authors will have internal components that might have a similar name.... one thing that we have discovered that it is extremely reviling is the fact that if what you write in a template is not what goes into the dom... people get really confused
17:20:43 <caridy> so, for us, we really want to follow this principle: what you see in your template, is what you get in the DOM.
17:20:51 <slightlyoff> JanMiksovsky: mission is to prevent re-invention; want to provide highest-quality, basic elements to help folks get to a high-quality general-purpose UI component quickly
17:21:30 <slightlyoff> JanMiksovsky: a goal is to support extensive variation; no "one carousel to rule them all". Our quality goal is to use the native HTML elements as our reference point; well-constructued and predictable. Aiming for the same level of quality
17:21:39 <slightlyoff> JanMiksovsky: coming up on half of our targeted patterns
17:21:56 <slightlyoff> JanMiksovsky: not sure how long it'll take to get to full converage; new patterns emerge
17:22:29 <slightlyoff> JanMiksovsky: on quality; e.g. a Carousel, what happens if someone removes an element at runtime? Or puts in a `<style>` element into it?
17:22:43 <slightlyoff> JanMiksovsky: no reference that said "what should a good HTML element do?"
17:22:58 <slightlyoff> JanMiksovsky: so we published one; the "gold standard checklist", published on github
17:23:23 <slightlyoff> JanMiksovsky: Techniques: reactive core without React
17:23:32 <slightlyoff> JanMiksovsky: use Mixins for many things
17:23:46 <slightlyoff> JanMiksovsky: ARIA, keyboard focus, directional navigation, etc. etc.
17:24:17 <slightlyoff> JanMiksovsky: these are built out of mixins to build up components from basic patterns; 85% of the list-box is re-used in a carousel, e.g.
17:24:34 <slightlyoff> JanMiksovsky: we also have "Element Roles"; key parts in a Shadow Tree that can be offred up to be replaced
17:24:59 <slightlyoff> JanMiksovsky: so if an app already has a custom button, a spin box and offer up the slots for the buttons up so that a custom button can be added instead
17:25:44 <slightlyoff> JanMiksovsky: also have many compositional primitive elements; many of them are "stages". E.g. modal, crossfade, sliding stages
17:26:26 <slightlyoff> JanMiksovsky: by putting mixins and primitive elements together, we can achieve really complex effects; use "element patching" to achieve custom visualizations
17:26:40 <slightlyoff> JanMiksovsky: we let people pass in pieces of a component to use as parameters
17:26:59 <slightlyoff> JanMiksovsky: can apply the same ideas to tabs (not just cariousels, e.g.)
17:27:16 <slightlyoff> JanMiksovsky: can replace buton styles, can replace stage to support touch gestures, e.g.
17:27:39 <slightlyoff> JanMiksovsky: calls into question what's a tab, what's  a list. Spend a lot of time identifying abstract component classes which we then specialize.
17:27:52 <slightlyoff> JanMiksovsky: did the same thign for select/combobox/listbox/etc.
17:28:25 <slightlyoff> JanMiksovsky: have things like calendar parts
17:28:56 <slightlyoff> JanMiksovsky: let people build on top; e.g. a lunar calendar. Can replace elements in the grid of a calendar with something that knows how to render differently
17:29:09 <slightlyoff> JanMiksovsky: can then drop a calendar into a combo-box to customize
17:29:12 <tomek_wytrebowicz> tomek_wytrebowicz has joined #components
17:29:14 <slightlyoff> JanMiksovsky: a quick intro to Elix
17:29:54 <slightlyoff> JanMiksovsky: think of this as the next 100 elements we might add to HTML (although it's too early)
17:29:55 <slightlyoff> questions
17:30:01 <slightlyoff> annevk: like what you've done
17:30:26 <slightlyoff> annevk: the mixiing thing is somethign we need to figure out for how we can expose things to web developers from the platform
17:30:36 <slightlyoff> Ruphin: can you outline your main challenges?
17:30:45 <slightlyoff> JanMiksovsky: we file lots of bugs ;-)
17:30:55 <slightlyoff> JanMiksovsky: early adopters of V0 and V1 Web Components
17:31:01 <slightlyoff> JanMiksovsky: have tried to propose changes to help
17:31:38 <slightlyoff> JanMiksovsky: currently interested in styling; too hard right now. Our answer right now is that someone who wants to style a component needs to subclass and then needs to add styles. WOuld like to this to be possible in pure CSS
17:32:01 <slightlyoff> JanMiksovsky: have filed issues against `::part`; still need improvements
17:32:09 <slightlyoff> rniwa: is this mostly about inheretence?
17:32:59 <slightlyoff> JanMiksovsky: a number of styling challenges; we liek a lot about `::part`. Dot in the carousel has selected and unselected state but no way to target that in `::part`. Need custom pseudoclass and need `::part` to work with that
17:33:20 <slightlyoff> rniwa: very impressive! thank you
17:33:33 <slightlyoff> muan and josh from GitHub presenting
17:33:59 <muan> https://gist.github.com/muan/80ec131db2eef3e1ff43bcc4d760438d
17:34:49 <slightlyoff> muan: a lot of our work is aroudn progressive enhancement, similar to the way componentkitchen is doing things
17:35:05 <slightlyoff> muan: we explored SD, but not polyfillable; big perf hit. We don't use frameworks on GH frontend
17:35:14 <slightlyoff> muan: we are building elements that we think should be in the HTML spec
17:35:22 <slightlyoff> <list of elements>
17:35:39 <slightlyoff> the "fork" button dialog is a custom element
17:35:56 <slightlyoff> muan: the details dropown and many others are custom elements
17:36:08 <slightlyoff> muan: relative time changes, etc. etc.
17:36:27 <rniwa_> rniwa_ has joined #components
17:36:58 <slightlyoff> muan: we were early adopters of V0; started to build emoji fallback elements; a few years ago started to move from V0 to V1; expanding list of elements to subsume frontend JS code
17:37:11 <slightlyoff> muan: want frontend develoeprs not to need to build many components
17:37:20 <slightlyoff> josh: also intrested in scoped registry
17:37:30 <slightlyoff> josh: how is this working with other frameworks in a namespaced way?
17:37:59 <slightlyoff> josh: have stayed away from introducing app-specific elements; only elements that are available everywhere today. Want namespacing eventually
17:38:35 <slightlyoff> josh: lots of the page is SSR'd; wait on JS can be jaring
17:38:58 <slightlyoff> josh: we use a bit of LitHTML; intrested in template instantiation
17:39:22 <slightlyoff> josh: intersted in form participation, faking it today. Want to serialize more complex data structures
17:39:45 <slightlyoff> muan: want a "connected and parsed" callback
17:40:06 <slightlyoff> muan: connectedCallback doesn't help us here today
17:40:26 <slightlyoff> muan: want the ability to set tabindex focus flag without having to set the attribute ("inherently focusable")
17:40:30 <slightlyoff> questions?
17:40:36 <bkardell_> I feel like this thing about 'parsed' comes up literally every single time
17:40:43 <Domenic> pmdartus_: presentation isn't accessible, access denied
17:40:43 <slightlyoff> rniwa_: connected and parsed; is this about child element parsing?
17:40:48 <slightlyoff> muan: yes
17:41:04 <slightlyoff> muan: a mutation observer could do, but not great
17:41:15 <slightlyoff> rniwa_: what is preventing you from adoptiong Shadow DOM?
17:41:26 <slightlyoff> muan/josh: waiting on browser support
17:41:28 <bkardell_> I dont know a single person who has developed a fairly significant custom element that hasn't bumped against that :(
17:41:50 <slightlyoff> <IE 11 question>
17:41:55 <Domenic> annevk: I am unable to unmute myself
17:42:28 <slightlyoff> josh: we don't serve script to IE 11;  so they get the fallbak anyway
17:42:46 <slightlyoff> Domenic: <cutting out>
17:42:56 <bkardell_> I think there is just mad echo
17:43:13 <slightlyoff> muan: we server a details element polyfill to IE11
17:43:14 <westbrook> The cut off comes from the mics local to the room.
17:43:20 <slightlyoff> muan: so yo ucan still delete your account ;-)
17:43:24 <Domenic> I was saying: it seems understandable that a first-party site like GitHub doesn't need shadow DOM or strong encapsulation in general. It's most valuable for composing third-party widgets.
17:43:58 <slightlyoff> justin: so you need the parsed callback becuse it's not acceptable to show something that doesn't work?
17:44:09 <slightlyoff> josh: question is style scoping on initial paint
17:44:22 <slightlyoff> josh: happy to render something and then upgrade, but how do you handle scoped styles in the document?
17:44:30 <slightlyoff> josh: the rest of the component booting up later is acceptable
17:44:34 <annevk> q?
17:44:36 <Travis> q+
17:44:58 <slightlyoff> muan: also wanted to add that when we use autocomplete, we depend on the input being inside the element. They can see the element even w/o JS
17:45:22 <pmdartus> pmdartus has joined #components
17:45:56 <slightlyoff> josh: have to scope classnames with identifier prefixes; can't work around inherited properties that way, tho. Community-wide issue
17:45:56 <bkardell_> it seems like shadow dom is real useful for PE-like composition?
17:46:23 <slightlyoff> muan: also not suggesting our teams adopt it for scoped style encapsulation
17:46:51 <slightlyoff> josh: if we had something like `<style scoped>` for Shadow DOM that would help us
17:47:05 <slightlyoff> justin: what do you use for main-page CSS encapsulatin today?
17:47:12 <slightlyoff> josh: manual
17:47:28 <slightlyoff> Travis: noticed that some of your elements have an "experimental" label; how do you vett the?
17:47:29 <Andrew> Andrew has joined #components
17:47:46 <slightlyoff> muan: we add things to th GH codebase and then start converting existing UI that does the same thing
17:48:12 <slightlyoff> muan: at some point, we learn enough about what we need that we consider it stable
17:48:22 <slightlyoff> muan: once every instance in github.com is converted, stable
17:48:34 <slightlyoff> Ruphin to present
17:49:44 <slightlyoff> Ruphin: I don't represent ING; but have worked with them
17:49:55 <slightlyoff> Ruphin: ING is the largest bank in the Netherlands
17:50:14 <slightlyoff> Ruphin: 60% of the Dutch use these apps
17:50:23 <josh> josh has joined #components
17:50:23 <slightlyoff> Ruphin: 700 teams of developers worldwide
17:50:37 <slightlyoff> Ruphin: every team works on small features that are then composed
17:50:47 <slightlyoff> Ruphin: the web component model makese sense for them as a result
17:50:59 <slightlyoff> Ruphin: everything needs to be composed
17:51:19 <slightlyoff> Ruphin: no external code, but WC allow them to gaurantee compat
17:51:35 <slightlyoff> Ruphin: the whole app is an element; every dialog, every view is usually created by a different team
17:52:00 <slightlyoff> Ruphin: this app, e.g., is a Polymer 2 app, but has some LitElement in it too. Everyone interoperates via WC
17:52:25 <slightlyoff> Ruphin: a ridiculous number of features; 1300 projects, each of which have 1+ custom elements
17:52:36 <slightlyoff> Ruphin: random pages have piles of elements created by different teams
17:52:47 <slightlyoff> Ruphin: largest issue is a11y
17:53:16 <slightlyoff> Ruphin: as a bank, have high standards in this area. Shadow DOM is a difficult problem. Forms in particular
17:53:54 <slightlyoff> Ruphin: I work on a base set of components that implements base-layer a11y; looks like what Elix is doing; elements that handle baseline a11y
17:54:46 <slightlyoff> Ruphin: if you create an `<input>`; we have to inject native label, helper text, etc. and lots of stuff that need to work with native `<label>`
17:55:21 <slightlyoff> Ruphin: can't actually encapuslate because of node ownership and a11y. Largest problem we face. A team has been working for 18 months and has solved forms with these workarounds
17:55:30 <slightlyoff> Ruphin: calendars, dates, etc. all need a11y
17:55:47 <slightlyoff> questions?
17:56:01 <annevk> q?
17:56:05 <slightlyoff> rniwa_: curious about a11y; you have to insert elements into light DOM, why?
17:56:08 <bkardell_> idref
17:56:11 <slightlyoff> Ruphin: lots of ARIA things dont' work
17:56:13 <annevk> ack Travis
17:56:23 <slightlyoff> Ruphin: developer things don't work either
17:56:49 <slightlyoff> Ruphin: native labels inside different shadow roots break because of ID linkage
17:56:58 <slightlyoff> hober: AOM is working to address these problems
17:57:15 <slightlyoff> Ruphin: the ARIA model being based on a single scope and ID references breaks web components
17:57:31 <slightlyoff> Ruphin: no real way to address this except for some sort of global reference system
17:57:50 <slightlyoff> rniwa_: there's an issue on the HTML spec to let you reference something in JS...
17:57:55 <slightlyoff> Ruphin: form participation could also help
17:58:42 <slightlyoff> rniwa_: would be great if you could also come up with a list of concrete scenarios that you can't do today; we'd like to solve them. Requirements will als help us
17:58:53 <dlockhart> Basically any ARIA mechanism that's ID-based is a problem -- e.g. aria-labelledby, aria-describedby
17:59:04 <Andrew> Those seem like valid use cases
17:59:29 <slightlyoff> annevk: alice has a PR against HTML for IDREF; label/focus, element shoudl be able to delegate
17:59:47 <slightlyoff> rniwa_: we may also need a way to delegate labeling, focus, etc. etc.
17:59:53 <bkardell_> alice is working on many things in this area :)
17:59:57 <annevk> https://github.com/whatwg/html/pull/3917 is Alice's work on IDREF, FWIW
18:00:11 <slightlyoff> (Salesforce engineer): we have the same problem
18:00:27 <slightlyoff> richtext labels have the same problem
18:00:55 <slightlyoff> Ruphin: the more complex the element, the harder a11y gets
18:01:26 <westbrook> It would seem that some of the basic versions of this issue would be addressed by extending built-ins. Though definitely just the tip of the issue.
18:01:34 <slightlyoff> Ruphin: the method we're using is to have everything take attributes and genereates managed elements
18:01:51 <slightlyoff> Salesforce: even tricker with compound inputs
18:02:13 <slightlyoff> Ruphin: we have a solution for many for these
18:02:35 <rniwa> rniwa has joined #components
18:03:04 <tomalec> tomalec has joined #components
18:03:22 <slightlyoff> justin: is this the same as IDs in CSS?
18:03:30 <slightlyoff> Ruphin: those aren't global, but ARIA labels are
18:03:44 <slightlyoff> justin: but it has to be scoped, right?
18:03:47 <slightlyoff> Ruphin: that's the problem
18:04:34 <bkardell_> there was in css once too kinda
18:04:36 <slightlyoff> annevk: CSS doesn't use same-tree semantics; here we're looking at a request for cross-tree references
18:05:02 <bkardell_> deep / and stuff
18:05:28 <slightlyoff> diervo: some of the AOM stuff has merged; what can we push this to the top of the queue for implementers? This is really important for us
18:05:37 <slightlyoff> rniwa: an open question is exact shape
18:05:44 <slightlyoff> rniwa: don't want to implement the wrong thing
18:06:15 <Domenic> You should test the behind-a-flag implementation in Chrome (I think that exists?) and tell us if it works
18:06:48 <slightlyoff> rniwa: you can help by validating that a proposal will solve the problem for you
18:07:14 <slightlyoff> <AOM topic? elementinternals?>
18:08:03 <Domenic> ARIA references are separate from element-internals
18:08:12 <Domenic> Two complementary pieces of the puzzle
18:08:13 <Dave_Batiste> The ID scoping is an big issue for us (@D2L) as well.  ex. aria-labelledby, aria-describedby, etc.
18:08:31 <Domenic> ElementInternals AOM stuff allows more accessible components but is not directly related to cross-tree references
18:08:51 <Domenic> whatwg/html#3917 should work for cross-tree references
18:08:59 <Domenic> (i.e. solving ID scoping)
18:09:36 <slightlyoff> rniwa: perhaps we can discuss a11y tomorrow afternoon?
18:11:35 <slightlyoff> justin presenting lazy registration and scope registries
18:12:06 <slightlyoff> justin: the idea with scoped custom element registries is: 1) to allow you to construct them and 2) assign a registry to a shadow rot
18:12:09 <slightlyoff> *root
18:12:27 <slightlyoff> justin: the idea is that they would gain the element creation APIs (`cloneNode`, etc.)
18:12:52 <Andrew> It would be nice to be able to create a demo-component without having to namespace it
18:12:58 <slightlyoff> justin: if you create elements from that root using those APIs, you'd then get those definitions
18:13:17 <slightlyoff> justin: also, these would be hierarchial
18:13:36 <slightlyoff> justin: per TPAC conversation, references between registries wouldn't be that expensive; can be dynamic in DOM
18:14:05 <slightlyoff> justin: so when you create an element, e.g. `innerHTML` in a shadowRoot, will look up the tree of shadow roots to find a definition
18:14:15 <slightlyoff> justin: so teh scope of registries would be dynamic down the DOM tree
18:14:19 <slightlyoff> <code sample>
18:14:35 <annevk> One interesting thing with this is that we move back from constructors to factories
18:15:01 <slightlyoff> justin: today, it's only pratical for an element to define itself. So if an element doesn't define itself, and two others try to, one will fail
18:15:20 <slightlyoff> justin: scoped registries help by letting consumers define elements and avoid name collisions
18:15:25 <pmdartus_> pmdartus_ has joined #components
18:16:13 <dlockhart> We're not seeing Justin's slides on the Vidyo feed...
18:16:17 <slightlyoff> ...
18:16:29 <slightlyoff> justin: and constructors?
18:16:34 <dlockhart> That's better thanks
18:17:05 <slightlyoff> <live slide debugging>
18:17:20 <slightlyoff> rniwa: with this proposal, biggest challenge is ctor
18:17:36 <slightlyoff> rniwa: today we can look up global object of ctor and decide if it's an element
18:17:57 <slightlyoff> rniwa: here, we odn't know when to look something up. Also, what about `document.createElement()`?
18:18:14 <slightlyoff> rniwa: want something other than `innerHTML` inside custom elements
18:18:34 <slightlyoff> rniwa: do we let ctors work? do folks want `shadowRoot.createElement()` etc.?
18:18:53 <slightlyoff> rniwa: desired behavior unclear
18:19:12 <slightlyoff> annevk: interesting question: can you add elements to multiple registries?
18:19:32 <slightlyoff> justin: elements would still register themselves on the globa; can also optionally be registered in scoped registry
18:19:54 <slightlyoff> annevk: a single implementation to multiple scoped registries?
18:19:56 <slightlyoff> Ruphin: YES!
18:20:21 <slightlyoff> Ruphin: imagine someone makes a button and tabs; each tab wants a button element; everyone needs to import and define
18:20:31 <rniwa> q?
18:20:32 <Andrew> Agree
18:20:46 <slightlyoff> annevk: so you'll have ot use `createElement` on shadow roots
18:21:58 <slightlyoff> : you can imagine fully qualified names globally; aliases locally
18:22:11 <slightlyoff> diervo: we have the ability to do both; what you write is what you ssee
18:22:26 <slightlyoff> diervo: want folsk to be able to put a component anywhere and have the name be the same
18:22:34 <slightlyoff> diervo: "what you write is what you get"
18:22:51 <slightlyoff> justin: intresting to keep in mind what we're up against. React has lexical scoping
18:23:04 <slightlyoff> justin: quetsion here of pushing boilerplate down
18:23:08 <slightlyoff> annevk: wanted to ask about that
18:23:21 <slightlyoff> annevk: lots of other things in the platform depend on fixed local names
18:23:34 <slightlyoff> annevk: now the name is vaiable; how do those other things change to accomodate
18:23:46 <pmdartus_> q+
18:23:49 <slightlyoff> justin: elements styling themselves aren't using their name; they're using `:host`
18:24:41 <slightlyoff> rniwa: do folks want to use constructors?
18:24:52 <slightlyoff> <waht is the `tagName`>?
18:25:52 <slightlyoff> rniwa: chaining global scope references creates a very confused state
18:26:13 <slightlyoff> annevk: something registered in 2 different scoped registries; how do you handle that? Don't need chained globals to hit this
18:26:47 <slightlyoff> justin: the registry can hand you a contructor
18:28:12 <slightlyoff> <discussion of difficulties in lookup>
18:28:26 <slightlyoff> Jan: what Justin has up thre is fine
18:28:54 <slightlyoff> <slightlyoff asks a dumb question>
18:29:37 <slightlyoff> (discussion of registration hook)
18:30:56 <slightlyoff> "where do registries live"/"how are they inherited?"
18:31:35 <slightlyoff> rniwa/Jan: discussion of lookup vs. element's having backrefs to registries
18:32:07 <slightlyoff> justin: Chrome DOM team is sensitive references to Element for memory and perf
18:32:17 <slightlyoff> (pointer cost per element is high)
18:32:26 <slightlyoff> rniwa: also registry liveness
18:32:55 <slightlyoff> justin: new references to ShadowRoot are easier
18:33:07 <Travis> q+ BoCupp
18:34:02 <andrew> andrew has joined #components
18:34:15 <slightlyoff> <how does dynamic registry work? re-upgrade?>
18:35:26 <pmdartus_> -q
18:36:00 <BoCupp> q+ best practice for libraries defining custom elements
18:36:21 <annevk> q?
18:36:24 <slightlyoff> discussion of registry ownership and references
18:37:00 <rniwa> rniwa has joined #components
18:37:04 <rniwa> q?
18:37:08 <annevk> ack BoCupp
18:37:09 <slightlyoff> BoCupp: can you comment on best practices for libraries defining custom elements?
18:37:21 <slightlyoff> BoCupp: can a library use this concept and export registries?
18:37:35 <slightlyoff> BoCupp: or will they also continue to export classes?
18:39:27 <slightlyoff> justin: I thought you might be able to pass partially filled registries
18:39:50 <slightlyoff> justin: we saw something with meta-import files, but it creates a bottleneck in the deps graph and nobody knows which deps they have
18:40:11 <slightlyoff> justin: so this sort opacity makes things harder on linters and bundlers, etc.
18:40:13 <andrew> That's assuming the component wants to be reused
18:40:16 <bkardell_> seems like importing a 'package' tho?
18:40:35 <slightlyoff> justin: the idea instead is probably that folks define only what they use and tools should yell when you don't use something you define
18:40:41 <andrew> Runtime imports are effective
18:41:36 <caridy> caridy has joined #components
18:42:24 <slightlyoff> <discussion of registry passing>
18:42:35 <caridy> I do like @rniwa suggestion... to extend into that... I will like to see something like import maps, but for components that can be used in a shadow
18:42:47 <slightlyoff> rniwa: should you use a passed-in registry to bootstrap from? or should you do a dynamic lookup?
18:43:09 <slightlyoff> annevk: are you saying that a further-nested tree might want to use the global and not the scoped registry?
18:43:17 <slightlyoff> Ruphin: today it's common to self-define
18:43:35 <slightlyoff> Ruphin: if there's no inheritance model, Id' be forced to register everything I use
18:43:46 <andrew> Inheritance would create binded side-ffects
18:44:01 <JanMiksovsky> JanMiksovsky has joined #components
18:44:09 <bkardell_> is there a question of whether we need more than 'this level, or global'
18:44:16 <slightlyoff> diervo: if I create an element that nobody else has defined yet, it's a security issue for us
18:44:23 <bkardell_> like, is that the q on the table, it is not clear to me
18:44:27 <andrew> a-a would be different than a-b
18:44:32 <slightlyoff> diervo: in SF, an element that's in a shadow can't be upgraded by another definition later
18:44:51 <slightlyoff> justin: maybe closed shadow roots don't inherit?
18:44:59 <andrew> Registries could be defined on the component
18:45:03 <slightlyoff> annevk: don't want to couple features too much
18:45:13 <caridy> no, closed shadow is not really a good way to look at this justin
18:45:24 <pmdartus> pmdartus has joined #components
18:46:11 <JanMiksovsky> q+
18:46:38 <slightlyoff> diervo: the problem is the issue with customers overtaking someone else's element.
18:46:53 <slightlyoff> diervo: we prefer a non-inheritance approach
18:47:19 <slightlyoff> rniwa: maybe there could be one flag for this?
18:47:26 <Ruphin> q?
18:47:34 <Ruphin> q+
18:48:11 <slightlyoff> (room dislikes inheritance flag tied to closed roots)
18:48:12 <andrew> Would scoped registries override consuming registries?
18:48:24 <slightlyoff> JanMiksovsky: like the idea of having all the used elements listed
18:48:37 <pmdartus> q?
18:48:46 <slightlyoff> JanMiksovsky: also reasonable to have another option to `attachShadow` that can control global registry lookup defaulting
18:48:46 <Travis> I keep thinking about <my-element xmlns="my-namespace-for-this-subtree">...
18:49:15 <andrew> Could the ::part technique be used with the registry?
18:49:20 <bkardell_> how would that work exactly if it is on the shadow root, if the component hosting it is defined in the global registry won't it be hit before you ever get to the component that creates the shadow....?
18:49:31 <slightlyoff> rniwa: do we have consensus for a single flag on the registry; self, or self+global?
18:50:27 <andrew> part allow for a custom registry to be overriden
18:50:40 <slightlyoff> <debate about inheriting registries>
18:50:52 <tomalec> q+
18:51:18 <annevk> ack JanMiksovsky
18:51:29 <bkardell_> I feel like I need someone to explain to me how this works with a registry on a shadow actually
18:52:47 <annevk> ack Ruphin
18:53:09 <slightlyoff> bkardell_: we need to see example code
18:53:24 <slightlyoff> <discussion of what Salesforce does>
18:53:40 <slightlyoff> diervo: local registry can know which elements will be upgradeable
18:53:57 <slightlyoff> diervo: so that solves it for us; customer components are things we can implicitly create
18:54:02 <andrew> A factory for registering custom-elements
18:54:20 <slightlyoff> Travis: do you antiicpate having one registry per custom element?
18:54:41 <slightlyoff> diervo: we'll have namespaces; as long as we can fully control which elements are constructable from a particuarl tree, we're OK
18:54:59 <slightlyoff> diervo: we need to make sure that elements in a tree can't be created by *somebody else*
18:55:09 <andrew> Not just what, but who
18:55:16 <annevk> ack tomalec
18:55:19 <bkardell_> slightlyoff: yeah, I do... though, I started writing an example on paper and I kind of think I get it now
18:55:31 <andrew> Two people can upgrade salesforce-order-form
18:55:44 <slightlyoff> tomalec: being able to discard the global scope...maybe you can pass in a set of registries to use?
18:56:24 <slightlyoff> justin: one use-case might be lazy definitions, e.g. for content sites
18:56:43 <slightlyoff> justin: content itself might need elements but the app shell doesn't konw about them ahead of time
18:56:55 <slightlyoff> justin: so lazy lookup may need a similar system
18:57:04 <andrew> +1
18:57:18 <slightlyoff> <break>
19:15:35 <pmdartus_> pmdartus_ has joined #components
19:17:37 <josh> josh has joined #components
19:19:30 <rniwa> rniwa has joined #components
19:22:22 <slightlyoff> Topic: lazy element definition
19:22:55 <slightlyoff> justin: issue #782
19:23:07 <annevk> https://github.com/w3c/webcomponents/issues/782
19:23:18 <slightlyoff> justin: the idea is that a registry can take a tagname and a loader function rather than a tagname and a class
19:23:21 <bferrua> bferrua has joined #components
19:23:47 <slightlyoff> justin: the idea is that the loader function returns a promise and upgrades happen when it resolves
19:24:34 <slightlyoff> justin: salesforce had a large number of elements, needed to lazy-load; since initial dicussion, Google's internal tools do this, Stencil has introduced this, and React has introduced this with their "suspense" feature
19:25:18 <slightlyoff> justin: thinking about route-based code-splitting, route-based imports give you a place to split your code and put dynamic import into separate chunks. Routers do lazy loading, but if you're Amazon, the route you're on at a product page odesn't help. Too many to reason about in th router
19:25:45 <slightlyoff> justin: you'd get a massive bundle for the amazon route, e.g.. So what you want is to fetch the content then grab the components you actually used
19:25:52 <rniwa> q?
19:25:53 <slightlyoff> justin: are there open questions?
19:26:08 <slightlyoff> annevk: was curious about the alternative idea; a callback if a given name is used
19:26:26 <slightlyoff> smaug: this is what Mozilla has internally
19:26:31 <smaug> https://searchfox.org/mozilla-central/source/dom/webidl/CustomElementRegistry.webidl#11,25
19:26:55 <slightlyoff> justin: I suspect the most common implementation of that hook will be to call a dynamic `import()` anyhow?
19:27:08 <smaug> used for example in https://searchfox.org/mozilla-central/source/toolkit/content/customElements.js#678-680
19:27:13 <slightlyoff> justin: I think that'll the be the most ergonomic for the common case
19:27:22 <slightlyoff> annevk: but then it's not as flexible?
19:27:33 <slightlyoff> justin: the loader function can do anything, right?
19:27:45 <slightlyoff> Ruphin: does the loader function only get called once?
19:27:48 <slightlyoff> justin: yes
19:27:52 <tomalec> q+
19:28:12 <caridy> my position here is that I don't like to see more APIs that can put the element in some sort of TDZ
19:28:22 <caridy> we already have one... with the define element
19:28:50 <rniwa> q+
19:28:51 <slightlyoff> justin: some open questions: React's suspense has an async work signal that goes up the tree. They use this to signal that there are component definitions that are still loading; this lets them show, e.g., a spinner to cover up async work happening down the tree
19:29:09 <slightlyoff> justin: they do this by firing exceptions that carry promises; a better way to do this is to fire an event
19:29:17 <bkardell_> caridy: is it not the same one really?
19:29:19 <slightlyoff> justin: so should these elements fire off events?
19:29:23 <caridy> consumers of that element will have no way to know when it is ready to interact with it... or they have to be very defensive
19:29:50 <slightlyoff> Travis: missed this...but the upgrade is synchronous?
19:29:53 <slightlyoff> justin: yes
19:30:09 <diervo> +q
19:30:17 <annevk> ack tomalec
19:30:32 <JanMiksovsky> JanMiksovsky has joined #components
19:30:38 <slightlyoff> tomalec: how will this work with scoped registries?
19:30:39 <muan> muan has joined #components
19:31:02 <rictic> rictic has joined #components
19:31:03 <slightlyoff> justin: with scoped registries taht don't inherit, this gets simpler
19:31:25 <justin> justin has joined #components
19:31:35 <slightlyoff> justin: if you lazily define in a scoped registry and synchronously globally, which one gets it? is it the global?
19:31:49 <slightlyoff> <discussion of who wins>
19:33:03 <JanMiksovsky> q+
19:33:05 <slightlyoff> Ruphin: don't want randomness; global defintion winning sometimes seems weird to me
19:33:38 <slightlyoff> rniwa: a few bits of feedback: has the same issue as the async element definition; changes element charachteristics after the fact
19:34:03 <slightlyoff> rniwa: how do we avoid flash of content in these cases?
19:34:45 <bkardell_> it seems some people are actively choosing a thing currently that would have that characteristic rniwa?
19:34:52 <annevk> q+
19:35:00 <annevk> ack rniwa
19:35:03 <slightlyoff> rniwa: you might want to register some helper functions or let others know your thing is available...why are custom element special here?
19:35:39 <slightlyoff> justin: we have the mechanisms for determining that something was added and looking it up. That works across shadow roots. It's a special power that custom elements have that other parts of the system don't have (e.g. mutation observers)
19:35:58 <Ruphin> q?
19:36:00 <slightlyoff> justin: on the flash of unstyle content, that's why you'd consider an event to let something up the tree control this
19:36:25 <slightlyoff> Travis: I wonder if that event is per instance encountered by the parser? Or is it tied to the registry?
19:36:29 <annevk> Perhaps a callback for a new name helps because you might not know all the names you care about yet.
19:36:35 <rniwa> q+
19:36:53 <annevk> ack diervo
19:36:58 <justin> q+
19:37:25 <slightlyoff> diervo: had a similar question; we need sync, we wouldn't want to use this because we want to define what to upgrade and when to upgrade
19:37:42 <slightlyoff> justin: how can you sync load definitions?
19:37:59 <slightlyoff> diervo: we control the whole loading process; we don't let people do dynamic imports in userland
19:38:08 <caridy> we prefer to not insert the element until it is ready
19:38:19 <slightlyoff> diervo: any time you create an element, you need to know if it's ready
19:39:26 <caridy> that's not what the API is saying
19:39:38 <slightlyoff> justin: wanted to clarify that this is for consumers, not for producers. Folks who register for thier dependencies being lazily loaded, not the components itself
19:39:52 <caridy> the lazy is global, so anyone can define that behavior
19:39:54 <annevk> ack JanMiksovsky
19:40:29 <justin> caridy: > we prefer to not insert the element until it is ready
19:40:39 <justin> that can be up to the defining container, yeah?
19:40:46 <slightlyoff> JanMiksovsky: so this is interesting...CEs have names, and seeing something that isn't registered is a good cue to get something...but maybe there should be a simpler callback; maybe "I saw something I didn't know" in a callback, Proxy-style?
19:41:02 <slightlyoff> JanMiksovsky: something I didn't see is a way of knowing if an element is resolved yet or not
19:41:12 <slightlyoff> JanMiksovsky: will `get()` return a promise or something?
19:41:33 <slightlyoff> JanMiksovsky: can imagine wanting to handle the case where some things are defined but others aren't
19:41:37 <caridy> justin, if you move the API to the shadow, sure... but in reality, even if the container controls the element, knowing that it might not be ready, what happen if it slots that element into another element
19:41:46 <rniwa> q?
19:42:08 <caridy> how will that other element (the receiver of the slotted element) will know how to interact with it? think of x-menu, x-menu-item
19:42:11 <slightlyoff> annevk: you might also not know the full scope of elements you care about; may want to defer to another registry
19:42:39 <tomalec> q+
19:43:02 <rniwa> ack annevk
19:43:12 <hober> ack rniwa
19:43:12 <slightlyoff> <what's next?>
19:44:05 <slightlyoff> rniwa: need some sort of opt-in on the shadow-root
19:44:15 <slightlyoff> annevk: I was thinknig the registry?
19:44:25 <slightlyoff> rniwa: registry dispatches an event?
19:45:00 <tomalec> q-
19:45:05 <annevk> q?
19:45:14 <slightlyoff> rniwa: is anyone already doing this?
19:45:20 <slightlyoff> annevk: Mozilla is
19:45:25 <slightlyoff> justin: Stencil is too
19:45:26 <pmdartus> pmdartus has joined #components
19:45:36 <slightlyoff> justin: I also built a "split element" class
19:46:16 <slightlyoff> justin: but I don't think it should be left up to the implementer to decide if the element should be lazy; it needs to be up to the consumer
19:46:24 <slightlyoff> justin: same for observed attributes
19:46:58 <slightlyoff> <discussion about how you make a split class>
19:48:09 <bkardell_> can someone give alex a mic?
19:48:28 <slightlyoff> justin: this approach puts the burden on element producer
19:48:36 <slightlyoff> slightlyoff: this blows up with registration
19:48:48 <slightlyoff> (rathole on using Proxies for this)
19:49:21 <slightlyoff> annevk: does the FF API already know up-front which names it'll get?
19:49:34 <slightlyoff> smaug: it's a callback when we see something we haven't seen before
19:49:53 <slightlyoff> JanMiksovsky: if you have that you can prototype `.lazyDefine` on top of those semantics
19:50:00 <justin> q?
19:52:51 <slightlyoff> <discussion of how to make the tradeoff between general-purpose callback vs. more local, string-based API>
19:52:59 <rniwa_> rniwa_ has joined #components
19:53:03 <rniwa_> q?
19:53:05 <caridy> I do like the recommendation about the low-level API, just to know that there is a custom element in the shadow that is unknown... and from there... implementing something like lazy is fine.
19:53:48 <slightlyoff> diervo: having this API where you can control what to load or not may be useful, but concerned about how it can be misued
19:54:11 <slightlyoff> diervo: there's also a moment when something can be put into a `<slot>` where it isn't defined
19:54:27 <slightlyoff> diervo: so we're going to have to control use of this a lot
19:54:39 <JanMiksovsky> q+
19:54:46 <justin> q-
19:54:58 <slightlyoff> diervo: no concerns about having this api for, e.g., logging errors
19:55:14 <slightlyoff> JanMiksovsky: for this callback, would it be intersting to have that as a Level 0 and then build on top of that?
19:55:20 <slightlyoff> justin: more interesting than nothing for sure
19:55:39 <tomalec> q+
19:56:45 <slightlyoff> JanMiksovsky: we built a logging system very similar to the one described
19:56:55 <justin> q+
19:57:10 <slightlyoff> JanMiksovsky: there are things that people will be able to do with that sort of hook that may be the foundation of other things
19:57:17 <caridy> LOL
19:57:21 <slightlyoff> JanMiksovsky: are there implementers who are uncomfortalbe?
19:57:25 <slightlyoff> annevk: we already have it
19:57:25 <tomalec> q-
19:57:35 <slightlyoff> <laughing>
19:57:46 <slightlyoff> rniwa_: we'd like to make sure this is opt-in
19:57:51 <slightlyoff> justin: tied to teh scope?
19:57:56 <slightlyoff> (some agreement)
19:58:23 <JanMiksovsky> https://github.com/w3c/csswg-drafts/issues/3431
19:58:31 <slightlyoff> topic: custom pseudoclasses: https://github.com/w3c/webcomponents/issues/738
19:58:49 <JanMiksovsky> That issue on csswg-drafts captures a key connection between shadow parts and custom pseudo-classes. We really, really want both.
19:59:09 <slightlyoff> rniwa_: the goal is to allow elements to define their own states and set them in ways that are usable from CSS
20:00:33 <justin> q+
20:00:41 <rniwa_> q?
20:00:42 <slightlyoff> JanMiksovsky: we think both custom pseudoclasses and states are useful. The Elix components need this; components need to be aware of state and the best way to expose it was view pseudoclasses
20:01:39 <slightlyoff> Salesforce: we have button groups which are slots; button groups, so we need to udnerstand position (n'th child, e.g.) and lack of this has made it difficult to scale the UI in the way we'd prefer
20:02:25 <rniwa_> q+
20:02:31 <slightlyoff> justin: the interaction with `::part` expands the issue from being just about `elementInternals` and being more about state you add to an element in your shadow dom
20:03:07 <slightlyoff> JanMiksovsky: we'd be fine with...carousel with dots; setting properties on dots...that's fine if the carousel sets the state onto the part
20:03:31 <slightlyoff> justin: so any element you want to set a custom state on then needs to be a custom element
20:03:34 <slightlyoff> slightlyoff: why?
20:03:55 <slightlyoff> justin: you can't expose that via a `::part` on a non-custom element
20:04:06 <slightlyoff> JanMiksovsky: prioritize being able to expose own-state first
20:04:08 <justin> q-
20:04:13 <annevk> ack JanMiksovsky
20:04:17 <annevk> ack rniwa_
20:04:32 <slightlyoff> rniwa_: an open question about if the state needs to be on the shadow root or the element DOM
20:04:34 <rniwa_> https://github.com/w3c/csswg-drafts/issues/3431
20:04:47 <justin> my point was about allowing `::part(foo):state(bar)`
20:05:21 <slightlyoff> rniwa_: exposing state on part, with automatic forwarding, is hairy for implementations
20:05:35 <slightlyoff> (discussion of what the automatic forwarding entails)
20:07:11 <slightlyoff> JanMiksovsky: I can imagine a component host aggregating state from subtree; but others are disagreeing
20:07:23 <slightlyoff> justin: we don't have a mechanism for tracking that state
20:07:30 <slightlyoff> justin: we can't tell when the CSS state changes
20:07:48 <slightlyoff> JanMiksovsky: we'd need to look at concreate cases, but in many cases there are events
20:08:08 <justin> q?
20:08:36 <slightlyoff> annevk: back to "where should it be exposed",  I thought we had agreement on elementinternals?
20:09:07 <slightlyoff> annevk: on shadow root because it's encapsulated? Or should it be on the element? And we designed elementInternals so you can have private state w/o a shadow root
20:10:19 <slightlyoff> "a question of if it's a feature of the element or the shadow root"
20:10:27 <slightlyoff> JanMiksovsky: liveable if it's on SD
20:11:00 <bkardell_> would you genuniely have a private state without a shadow root? can someone give an example?
20:11:11 <slightlyoff> slightlyoff: is there an objection to using `elementInternals`?
20:11:23 <slightlyoff> hober: I don't have one
20:11:30 <slightlyoff> rniwa_: wasn't logged in the issue
20:11:54 <slightlyoff> justin: we discussed elementInternals regarding shadow dom traversal and futzing
20:12:14 <slightlyoff> annevk: the last couple of issues from tkent suggested `attachInternals()`
20:13:07 <tomalec> q+
20:13:34 <slightlyoff> annevk: are there issues with `elementInternals`?
20:13:48 <slightlyoff> tomalec: so this is for pseudos, not `::part`?
20:13:53 <slightlyoff> (yes)
20:14:29 <tomalec> ack tomalec
20:15:01 <slightlyoff> (we all struggle to recall what happened in Tokyo)
20:15:31 <pmdartus_> pmdartus_ has joined #components
20:15:41 <Domenic> My strong intuition is more on custom elements without a shadow root
20:15:50 <slightlyoff> +100
20:16:51 <slightlyoff> JanMiksovsky: it almost never comes up that you will attach a shadow root; we're fine with needing a SD
20:17:05 <Domenic> If parts have custom state, they should be custom elements, IMO
20:17:06 <slightlyoff> justin: you cant put a part after the pseudo
20:17:15 <Domenic> If they are just divs, then they can key off the state of their parent custom element
20:17:22 <slightlyoff> Domenic: can you q+
20:17:24 <slightlyoff> ?
20:17:33 <Domenic> Is it even worth it with the AV though...
20:17:35 <slightlyoff> rniwa_: you can use attributes
20:17:44 <Domenic> q+
20:17:48 <slightlyoff> Domenic: if only to get your point from IRC some airtime = )
20:18:00 <hober> Domenic: i was referring to a <div> in the light dom of the top level document; no shadow tree or custom element involved at all
20:18:18 <caridy> maybe the room should mute
20:18:27 <caridy> so domenic can talk.
20:18:43 <justin> q+
20:18:49 <slightlyoff> Domenic: built-in elements have custom states, so this makes custom states part of custom elements, which are unique in holding state
20:19:08 <slightlyoff> rniwa_: <restates>
20:19:21 <slightlyoff> Domenic: this isn't something every element or shadow root should get
20:19:35 <slightlyoff> justin: combinatorial issue w/ part and state?
20:19:55 <slightlyoff> Domenic/anne: you don't need parts for everything; elementInternals is fine for this
20:20:24 <slightlyoff> annevk: we should hold the line to put private state on `elementInternals` rather than moving it based on situation
20:20:50 <slightlyoff> justin: JanMiksovsky, when you saw explosion, was the element always a Custom Element?
20:21:10 <slightlyoff> JanMiksovsky: we support parameterized templates and let people pass things in
20:21:43 <Domenic> For styling sub-parts, you have two options: `my-custom-element:state(some-state)::part(my-subpart)` and `my-custom-element::part(my-subpart):state(some-state)`. The latter makes sense to me if my-subpart is a special element with its own internal state.
20:22:07 <slightlyoff> JanMiksovsky: <is a fan of this feature, wants it regardless of which version we get>
20:22:20 <diervo> Salesforce would love to see this implemented as well
20:22:37 <tomalec> +1 for Jan
20:22:50 <slightlyoff> justin: maybe also want to select on other classnames and attributes. With `::part` we let you expose internals but not states
20:23:19 <slightlyoff> justin: worried about global styling
20:23:29 <slightlyoff> Domenic: shadow DOM should be fore internal state
20:23:50 <slightlyoff> justin: burden on users; they have to fill in components not just build them
20:23:59 <BoCupp> q+ to there is no objection to a part having a state, right?
20:24:10 <Domenic> g-
20:24:12 <Domenic> q-
20:24:18 <annevk> ack justin
20:24:21 <annevk> ack BoCupp
20:24:21 <Zakim> BoCupp, you wanted to there is no objection to a part having a state, right?
20:24:24 <slightlyoff> slightlyoff: is a styling featuer going to solve that?
20:24:30 <rniwa> rniwa has joined #components
20:24:33 <slightlyoff> justin: for some cases
20:25:34 <slightlyoff> BoCupp: you were saying this was related to needing to have a `::part`?
20:26:16 <slightlyoff> <scribe miss>
20:26:57 <Domenic> Domenic: it should all follow naturally from allowing all psuedo-classes to work on parts. :state() is just one. But also :required should work, :invalid, etc.
20:27:13 <Domenic> rniwa: yes, but that only works if your part is a custom element that can set :state()s.
20:27:14 <rictic> I lost sound too
20:27:15 <Domenic> Domenic: agree
20:27:25 <rictic> and sound is back
20:27:49 <diervo> +1 to domenic and Bo clarifications
20:27:59 <tomalec> +1
20:28:13 <bkardell_> we seem to have lost sound and scrbe at the same time and come back to 'that's probably ok'
20:28:16 <slightlyoff> rniwa: request for concrete scenarios
20:28:22 <bkardell_> can someone repeat
20:28:23 <Ruphin> q+
20:28:57 <bkardell_> can someone say what bo described?
20:29:07 <slightlyoff> slightlyoff: is there anyone who doesn't want what Bo just described?
20:29:20 <diervo> Reprasing Domenic:
20:29:20 <diervo>  Domenic: it should all follow naturally from allowing all psuedo-classes to work on parts. :state() is just one. But also :required should work, :invalid, etc.
20:29:32 <slightlyoff> thank you, diervo
20:29:35 <bkardell_> ty
20:29:59 <bkardell_> +1
20:30:11 <slightlyoff> JanMiksovsky: I conclude that it's ok that things which need custom state need custom elements and we hang it off of `elementInternals`
20:30:14 <slightlyoff> rniwa: ok
20:30:56 <rniwa> or `shadowroot`
20:30:57 <slightlyoff> Ruphin: regarding competing with global style, I don't think we're going to compete with global styling. We can't offer that; we want encapsulation and what do people really need? With this concession, I can't imagine people will want more than this
20:31:25 <slightlyoff> q?
20:31:47 <slightlyoff> JanMiksovsky: I'll follow-up with an example to rniwa's request
20:31:53 <Ruphin> q-
20:32:43 <slightlyoff> annevk: we've closed all the issues up to the last 9 days; tkent introduced some built-in pseudoclasses, mabye we can split that from this feature?
20:32:47 <slightlyoff> slightlyoff: I think that's wise
20:35:21 <annevk> "F2F tentative conclusion: use `ElementInternals`, provided @rniwa is convinced by an example @JanMiksovsky will provide." is what I posted into the issue just now
20:36:41 <westbrook> if dominic presents, can we mute some of the in room mics?
20:38:19 <slightlyoff> topic: domenic presenting form submission and elementinternals
20:38:28 <slightlyoff> "event-based submission"
20:38:43 <slightlyoff> Domenic: "not super custom-elements related, but happy to recap and stop for questions"
20:38:56 <slightlyoff> Domenic: so Element Internals, how does it work?
20:39:12 <slightlyoff> Domenic: you get an `this.attachInternals()` that you can only call once
20:39:54 <slightlyoff> Domenic: a separate feature for disablign features; `static disableFeatures = ["internals"];`
20:40:10 <slightlyoff> Domenic: may also include Shadow DOM
20:40:19 <slightlyoff> Domenic: one way of thinking about this is element protected state
20:40:21 <slightlyoff> bkardell_: yes
20:40:45 <slightlyoff> Domenic: TC39 doesn't think that Protected can be added to JS; we asked them about this design and they said "this is pretty good considering the constraints"
20:41:04 <slightlyoff> Domenic: we had an opt-in and they said "this is going to be easy to circumvent", so opt-out is better
20:41:36 <slightlyoff> Domenic: re-exposing internals for subclasses is not easy if you don't care about strong encapsulation
20:41:41 <slightlyoff> Domenic: but decorators may help
20:42:04 <slightlyoff> (symbol-level visibility)
20:42:39 <slightlyoff> Domenic: hearing lots of demand for features based on this; form-associated custom elements, role/state/etc., pseudo-classes, etc.
20:42:59 <slightlyoff> Domenic: a nice way of giving built-in only behavior to custom elements
20:43:30 <caridy> ship it!
20:43:36 <bkardell_> can you share a url or something of what you are sharing Domenic?
20:43:40 <rniwa> q
20:43:41 <rniwa> q?
20:44:01 <bkardell_> q+
20:44:09 <bkardell_> can we have a url ?
20:44:19 <slightlyoff> bkardell_: I don't have one now
20:44:26 <bkardell_> ok
20:44:27 <slightlyoff> bkardell_: but we can ask when Domenic is done
20:44:29 <bkardell_> q-
20:44:51 <vmpstr> vmpstr has joined #components
20:45:07 <slightlyoff> Domenic: thre are a few states that are global to all form elements (enabled/disabled); we recently noted submit buttons have weird state too
20:45:14 <slightlyoff> Domenic: we can talk about that, but we might have a solution
20:45:25 <pmdartus> pmdartus has joined #components
20:45:38 <slightlyoff> Domenic: with the API I'm about to show, we csan do <all these things> (including labeled by)
20:45:44 <slightlyoff> <example code>
20:46:23 <slightlyoff> Domenic: `static formAssociated = true;` makes your element form-associated
20:47:06 <slightlyoff> Domenic: restore and autocomplete are complex sitautions that you'll want to hear about too
20:47:45 <slightlyoff> Domenic: `setFormValue()` sets your data; `form` is your "form owner", and same for `labels`
20:48:08 <slightlyoff> Domenic: state is exactly what the user typed, or what you'd show
20:48:25 <slightlyoff> Domenic: the value is separate; it's the canonicalized thing you put in `formData`
20:48:39 <slightlyoff> Domenic: checkboxes show this; many different states but they're barely related to the value
20:49:19 <slightlyoff> Domenic: can all be null, can be files, can be strings...or an be `formdata`, which lets you do compound controls
20:50:37 <slightlyoff> <discussion of validitiy>
20:50:45 <slightlyoff> Domenic: <demos>
20:51:36 <rniwa_> rniwa_ has joined #components
20:52:41 <annevk> <clapping>
20:52:47 <slightlyoff> prototype in Chrome Canary
20:53:45 <hober> q+ to ask about form-associating non-custom elements (<form><div contenteditable></div></form> v. <form><rich-editor></rich-editor></form>)
20:53:45 <Ruphin> q+
20:53:49 <slightlyoff> Domenic: feedback has been positive; partners are excited
20:53:59 <slightlyoff> q?
20:54:07 <rniwa_> q?
20:54:07 <bferrua_> bferrua_ has joined #components
20:54:36 <slightlyoff> hober: this is exciting; the obvious question: you have some sort of contentEditable thing, not using any web components, why can't we make those formAssociated?
20:54:59 <sfdc_iurie> sfdc_iurie has joined #components
20:54:59 <slightlyoff> hober: or, do these things need to be custom elements?
20:55:16 <slightlyoff> Domenic: you can imagine letting people attachInternals to any element
20:55:34 <slightlyoff> hober: maybe that's a different question?
20:55:39 <slightlyoff> slightlyoff: can you restate?
20:55:48 <rniwa_> q?
20:55:59 <sfdc_iurie> q+
20:56:26 <slightlyoff> hober: contentEditable is perhaps unique in that it's an existing feature that's not already formAssociated, but I guess your answer presumed that associating a contentEditable would allow someone outside the form tinker with the internals?
20:56:47 <rniwa_> q+
20:56:53 <slightlyoff> hober: maybe there's a solution to the contentEditable situation that uses a different mechanism?
20:57:10 <slightlyoff> Domenic: if we're not worried about non-content-editable things, that makes sense to me; we could imagine an attribute
20:57:22 <slightlyoff> Domenic: would need to be opt-in, but can imagine a path forward there
20:57:32 <slightlyoff> annevk: maybe a separate discussion
20:57:35 <muan> muan has joined #components
20:57:42 <slightlyoff> annevk: having this on `elementInternals` makes sense to me
20:57:49 <slightlyoff> annevk: don't want many ways to add private state
20:57:56 <hober> ack hober
20:57:56 <Zakim> hober, you wanted to ask about form-associating non-custom elements (<form><div contenteditable></div></form> v. <form><rich-editor></rich-editor></form>)
20:58:14 <slightlyoff> smaug: question about `setFormValue`; does it have to be eager? Can it be lazy? Worried about stream copies
20:58:45 <slightlyoff> Domenic: in my example, I do it eagersly, but a `formData` event could do it lazily
20:59:06 <slightlyoff> annevk: is there value in doing it eagerly?
20:59:24 <slightlyoff> Domenic: subtle value: form state restoration
20:59:42 <rniwa_> q?
21:00:14 <slightlyoff> Domenic: that might have worth for state, but not value
21:00:21 <slightlyoff> Ruphin: this looks amazing!
21:00:45 <annevk> ack Ruphin
21:00:46 <slightlyoff> Ruphin: have been looking at this featureset and what ING needs, and from what I can tell, this covers a very large part of the use-cases we've got
21:01:03 <annevk> ack sfdc_iurie
21:01:17 <Ruphin> q-
21:01:26 <Ruphin> q+
21:01:32 <slightlyoff> sfdc_iurie: what about form-fieds with multiple inputs?
21:01:38 <slightlyoff> Domenic: will show...
21:02:45 <slightlyoff> sfdc_iurie: in terms of validity; it'll apply to the whole element, not the internal fields, right?
21:02:56 <slightlyoff> Domenic: if you really want to encapsulate, you want to show one state
21:03:04 <slightlyoff> Domenic: at least programmatically
21:03:23 <slightlyoff> Domenic: but on the internal form elements, you can set/report validitiy to the internal elements
21:03:27 <Ruphin> q-
21:03:30 <slightlyoff> Domenic: we can put together a demo
21:04:22 <slightlyoff> <discussion of API for exposing this>
21:05:33 <slightlyoff> Domenic: there's no real protocol in the platform today for saying "i've got subfields and they're not valid" vs. "I'm a single control"
21:05:37 <caridy> we will buy this one for sure! ship it! smalls concerns like those mentioned by Iuri are not deal breakers... we just like to ask for me... as always!
21:06:06 <caridy> the only real concern for me is how to polyfill this in IE11 jajaja! but that's on us to solve it
21:06:24 <slightlyoff> rniwa_: might want to consider oother cases where there isn't an element per sae
21:07:30 <diervo> +q
21:07:36 <andrew> +1
21:07:38 <rniwa_> ack rniwa_
21:08:02 <westbrook> I second!
21:08:06 <slightlyoff> diervo: want to state for the notes that we really, really, really want this in the platform
21:08:19 <slightlyoff> Ruphin: if we can get this tomorrow it would be amazing
21:09:02 <slightlyoff> annevk: sounds like it's an action item on Apple and Mozilla to review the PR
21:09:19 <slightlyoff> annevk: and rniwa_ and hober should perhaps raise the other issues independently
21:09:42 <slightlyoff> rniwa_: compound value case may be intertwined....
21:09:49 <slightlyoff> Domenic: I think they'll be formData based eithe way
21:10:58 <slightlyoff> rniwa_: I have a concern with element reaction timing
21:11:11 <slightlyoff> Domenic: could be moved; will consult with tkent about performance in our prototype
21:11:12 <hober> q?
21:11:19 <diervo> q-
21:12:13 <Domenic> https://glitch.com/edit/#!/foam-sandal / https://foam-sandal.glitch.me/ for the demo
21:12:50 <slightlyoff> 👍
21:14:04 <bkardell_> \what was the svg one annevk?
21:14:32 <bkardell_> nm found it
21:15:24 <bkardell_> ty for the links Domenic!
21:15:32 <pmdartus_> pmdartus_ has joined #components
21:16:20 <Domenic> What stylesheet issue are we discussing?
21:16:49 <slightlyoff> thanks pmdartus_
21:18:03 <Domenic> annevk: want to project the issues list as you are triaging?
21:19:09 <rniwa_> https://github.com/w3c/webcomponents/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc
21:19:27 <Domenic> annevk: yes, thank you
21:19:35 <bkardell_> +1 thank u
21:24:22 <smaug> rniwa_: emilio says " yeah, there was a parallel issue, let me try to find it"
21:25:08 <Domenic> https://github.com/whatwg/html/issues/4547
21:25:12 <rniwa> rniwa has joined #components
21:25:14 <rniwa> https://html.spec.whatwg.org/multipage/semantics.html#the-style-element
21:25:18 <Domenic> https://github.com/whatwg/html/issues/4547 is about the missing browsing-context requirement
21:25:21 <rniwa> https://html.spec.whatwg.org/multipage/semantics.html#the-style-element
21:26:30 <Domenic> https://jsbin.com/cozenirite/1/edit?html,css,console,output test case showing browsing-context
21:26:46 <smaug> emilio gave link https://github.com/w3c/csswg-drafts/issues/3096
21:28:24 <pmdartus> pmdartus has joined #components
21:46:41 <caridy> caridy has joined #components
00:34:33 <tomalec> tomalec has joined #components
02:20:53 <tomalec> tomalec has joined #components
02:46:34 <caridy> caridy has joined #components
02:52:15 <caridy> caridy has joined #components
03:10:02 <Zakim> Zakim has left #components
03:23:23 <_caridy> _caridy has joined #components
05:02:17 <aboxhall> aboxhall has joined #components
05:47:32 <caridy> caridy has joined #components
06:14:35 <tomalec> tomalec has joined #components