16:57:52 <RRSAgent> RRSAgent has joined #components
16:57:52 <RRSAgent> logging to https://www.w3.org/2020/10/29-components-irc
16:57:54 <Zakim> RRSAgent, make logs Public
16:57:55 <Zakim> please title this meeting ("meeting: ..."), Ralph
16:58:02 <Ralph> meeting: CSS Module Scripts
16:58:42 <Bert> Bert has joined #components
16:58:48 <MasakazuKitahara_> MasakazuKitahara_ has joined #components
17:00:24 <Bert> present+
17:00:32 <graynorton> graynorton has joined #components
17:00:44 <jan> jan has joined #components
17:01:00 <dandclark> present+
17:01:21 <masonfreed> masonfreed has joined #components
17:02:11 <Rob> Rob has joined #components
17:02:23 <Rob> present+
17:02:33 <bkardell__> bkardell__ has joined #components
17:03:33 <Lars> Lars has joined #components
17:03:39 <miriam> present+
17:03:43 <justin> justin has joined #components
17:05:04 <BoCupp> present+
17:05:06 <yuzhe-han> yuzhe-han has joined #components
17:06:45 <cpn> cpn has joined #components
17:08:04 <TabAtkins> TabAtkins has joined #components
17:08:12 <masonfreed> present+
17:08:18 <AramZS> present+
17:09:01 <hober> present+
17:09:39 <leobalter> present+
17:10:32 <masonfreed> q+
17:11:21 <BoCupp> q?
17:11:31 <smaug> present+
17:11:35 <TabAtkins> +1 to this assertion, it's nice
17:11:38 <Westbrook> Westbrook has joined #components
17:12:01 <bkardell__> present+
17:12:03 <hober> q+
17:12:26 <Bert> q+ to ask clarification about syntax
17:13:05 <justin> agree
17:14:00 <masonfreed> q+
17:14:21 <BoCupp> q?
17:14:23 <Zakim> Bert, you wanted to ask clarification about syntax
17:14:52 <annevk> q+ to ask how @import can be supported if it's not today
17:15:43 <Rob> For anyone interested in import assertions in general, here's a tc39 proposal link: https://github.com/tc39/proposal-import-assertions
17:15:56 <Ralph> [Dan, there's a request for a pointer to your slides]
17:16:05 <slightlyoff> present+
17:16:08 <leobalter> q+ what comes in the imported namespace object?
17:16:10 <slightlyoff> q?
17:16:28 <leobalter> q+ namespace
17:17:00 <justin> same - what is "q?" :)
17:17:21 <Rob> Here's the follow on proposal for json modules: https://github.com/tc39/proposal-json-modules
17:17:42 <justin> q+
17:17:54 <dandclark> https://1drv.ms/p/s!AtmAxiCADIM8nf4vuh8bmWLljCv4tQ
17:17:57 <Zakim> annevk, you wanted to ask how @import can be supported if it's not today
17:19:38 <annevk> (to be clear, my concern applies either way)
17:21:12 <smaug> q+
17:23:05 <slightlyoff> CSS already does this, right?
17:23:56 <annevk> yeah
17:25:02 <slightlyoff> q?
17:25:03 <BoCupp> q?
17:25:06 <slightlyoff> q+
17:25:50 <kevinpschaaff> kevinpschaaff has joined #components
17:26:06 <kevinpschaaf> kevinpschaaf has joined #components
17:26:18 <annevk> I think speculative loading is a pretty compelling reason this isn't a concern and allowing speculative loading seems good.
17:28:11 <annevk> (And if you are concerned, CSP \o/.)
17:29:30 <masonfreed> q+
17:31:03 <BoCupp> ACTION: file an issue on when to fail when attempting import of CSS in workers
17:32:24 <slightlyoff> +1 to @masonfreed's point on alignment
17:33:17 <BoCupp> mason: reason we should silently ignore @import in CSS modules and not throw is because that what a stylesheet does today - we should align
17:33:47 <Westbrook> +1 to following CSS resiliency to error on this
17:34:02 <BoCupp> justin: semantics for JS import of CSS can be different, throw feels more natural and feels better as a way to punt this decision
17:34:20 <Bert> q+
17:34:40 <justin> q+
17:34:45 <BoCupp> brian: questions whether the prior statement of @import being ignored in CSS stylesheet is true
17:35:06 <BoCupp> q?
17:35:08 <TabAtkins> Nope, if an @import fails it just fails, the rest of the stylesheet proceeds as normal
17:35:12 <annevk> bkardell__: seems you're wrong: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/8641
17:35:48 <MikeSmith> RRSAgent, make minutes
17:35:48 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/29-components-minutes.html MikeSmith
17:35:53 <MikeSmith> RRSAgent, make logs public
17:36:29 <MikeSmith> RRSAgent, make logs public
17:36:59 <BoCupp> bert: is it better to just embed CSS in JS?
17:37:20 <BoCupp> annevk: you can do that if you want with constructable stylesheets
17:37:50 <annevk> Bert: https://wicg.github.io/construct-stylesheets/#constructing-stylesheets
17:39:23 <annevk> https://github.com/whatwg/html/pull/4898 is the PR and doesn't have other concerns afaict.
17:41:06 <BoCupp> topic: should adoptedStyleSheets be assignable
17:41:57 <masonfreed> https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-624773407
17:42:01 <hober> q+
17:42:11 <BoCupp> dan: arguments for include easy way to init component with set of well known styles, arguments against are that you can overwrite previous entries accidentally
17:42:37 <justin> q+
17:42:41 <TabAtkins> q+ to respond to .item()
17:42:42 <BoCupp> hober: want this to be consistent with document.styleSheets
17:43:05 <masonfreed> q+
17:43:57 <TabAtkins> q-
17:44:03 <TabAtkins> (Justin is covering my comments.)
17:45:02 <BoCupp> justin: there is a back compat issue with adding .item to array, so there will be a fork between JS and CSS items
17:45:12 <masonfreed> q+
17:45:25 <MikeSmith> q+ to ask
17:45:39 <hober> q+
17:46:06 <MikeSmith> q- after
17:46:13 <MikeSmith> q- later
17:46:19 <BoCupp> mason: I think adoptedStyleSheets should be assignable, the use case is definitely there for assigning a set of stylesheets at a moment in time and not try to slice or do something more complicated
17:47:03 <BoCupp> hober: can we just spec a property with a different name to avoid backward compatibility concerns
17:47:49 <leobalter> q+
17:47:53 <MikeSmith> q- later
17:48:01 <slightlyoff> usage is relatively high for this feature today: https://chromestatus.com/metrics/feature/timeline/popularity/2846
17:48:09 <justin> q+
17:48:25 <BoCupp> +1 to mason's point on it supports good scenarios, not just a question of back compat
17:48:31 <hober> q+
17:48:41 <MikeSmith> q- later
17:48:50 <slightlyoff> q+
17:48:54 <dandclark> q+
17:48:55 <MikeSmith> q- later
17:49:57 <annevk> As I noted just now in the issue, note that there's precedent for assigning with classList and relList. They're slightly different, but seem comparable enough.
17:50:16 <jan> q+
17:50:19 <BoCupp> justin: framework author perspective, we have very static styles that make the assignment syntax nice
17:50:27 <Rob> q+
17:50:35 <BoCupp> justin: many of our scenarios are single actor and would benefit from assignment
17:51:31 <dandclark> q-
17:51:34 <BoCupp> hober: strange thing about assignability is that observablearray will copy the array, not take a reference, so subsequent mutation to the original array will not impact adoptedStyleSheets set
17:52:15 <MikeSmith> q- later
17:52:33 <BoCupp> hober: usage being high seems more like argument for Chrome compat and not right API
17:53:21 <BoCupp> Alex can you write what you said?  I missed it.
17:53:32 <justin> q+
17:53:58 <MikeSmith> q- later
17:54:16 <slightlyoff> I said: the length of the list of the assigned list doesn't have much cost; you should think about costs of assignment as being relative to the amount of CSS being applied (and it's expense) rather than number of items in the list
17:54:21 <emilio> q+
17:54:27 <MikeSmith> q- later
17:54:31 <BoCupp> Jan: I like ObservableArray, push would be great for my library.  We add stylesheets across multiple prototypes and push seems more usable
17:55:04 <BoCupp> Justin: not arguing against ObservableArray, just adding assignability
17:55:17 <leobalter> q+
17:55:25 <slightlyoff> Rob's point is a good one: these are not exclusive options
17:55:33 <MikeSmith> q- later
17:55:54 <BoCupp> Rob: we prefer assignability for our framework... (Rob can you please write the reason you said)
17:57:02 <BoCupp> ACTION: continue discussion for adoptedStyleSheets in issue
17:58:04 <BoCupp> Emilio: like ObservableArray, wants alignment with other APIs though
17:58:09 <Zakim> MikeSmith, you wanted to ask
17:59:09 <Rob> FASTElement uses adoptedStyleSheets today. During initial component creation there's typically a fixed set of sheets that we assign, so having the assignability of the property is preferred in that scenario. However, we have additional scenarios where we need to dynamically add and remove specific sheets. For that use case, the observable array APIs are ideal. So, for us, having both assignability and observability are desired if possible.
17:59:26 <BoCupp> Justin: made proposal for @sheet syntax for CSS bundling where @sheet could be named and available for import.  PTAL
17:59:39 <BoCupp> Mike: what's the overall plan in terms of where it will live?
17:59:46 <BoCupp> Dan: it will be in the HTML spec
18:00:54 <Rob> Thanks all!
18:01:10 <slightlyoff> so excited to see this moving forward; great work all
18:01:41 <dandclark> Slides: https://1drv.ms/p/s!AtmAxiCADIM8nf4vuh8bmWLljCv4tQ
18:01:46 <dandclark> Import Assertions PR: https://github.com/whatwg/html/pull/5883
18:01:58 <slightlyoff> hober: giving up on inline modules in JS is one of my great ES6 regrets; I think Shu has a path back, tho
18:02:05 <Ralph> zakim, end meeting
18:02:05 <Zakim> As of this point the attendees have been Bert, dandclark, Rob, miriam, BoCupp, masonfreed, AramZS, hober, leobalter, smaug, bkardell__, slightlyoff
18:02:07 <Zakim> RRSAgent, please draft minutes v2
18:02:07 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/29-components-minutes.html Zakim
18:02:07 <dandclark> CSS Modules PR (to be integrated with Import Assertions): https://github.com/whatwg/html/pull/4898/
18:02:10 <Zakim> I am happy to have been of service, Ralph; please remember to excuse RRSAgent.  Goodbye
18:02:14 <Zakim> Zakim has left #components
18:02:28 <justin> @slightlyoff Dan E has a new proposal for inline modules :)
18:46:27 <jensimmons> jensimmons has joined #components