– DRAFT –
CSS Module Scripts

<TabAtkins> +1 to this assertion, it's nice

<justin> agree

<Zakim> Bert, you wanted to ask clarification about syntax

<Rob> For anyone interested in import assertions in general, here's a tc39 proposal link: https://github.com/tc39/proposal-import-assertions

<Ralph> [Dan, there's a request for a pointer to your slides]

<justin> same - what is "q?" :)

<Rob> Here's the follow on proposal for json modules: https://github.com/tc39/proposal-json-modules

<dandclark> https://1drv.ms/p/s!AtmAxiCADIM8nf4vuh8bmWLljCv4tQ

<Zakim> annevk, you wanted to ask how @import can be supported if it's not today

<annevk> (to be clear, my concern applies either way)

<slightlyoff> CSS already does this, right?

<annevk> yeah

<annevk> I think speculative loading is a pretty compelling reason this isn't a concern and allowing speculative loading seems good.

<annevk> (And if you are concerned, CSP \o/.)

Action: file an issue on when to fail when attempting import of CSS in workers

<slightlyoff> +1 to @masonfreed's point on alignment

mason: reason we should silently ignore @import in CSS modules and not throw is because that what a stylesheet does today - we should align

<Westbrook> +1 to following CSS resiliency to error on this

justin: semantics for JS import of CSS can be different, throw feels more natural and feels better as a way to punt this decision

brian: questions whether the prior statement of @import being ignored in CSS stylesheet is true

<TabAtkins> Nope, if an @import fails it just fails, the rest of the stylesheet proceeds as normal

<annevk> bkardell__: seems you're wrong: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/8641

bert: is it better to just embed CSS in JS?

annevk: you can do that if you want with constructable stylesheets

<annevk> Bert: https://wicg.github.io/construct-stylesheets/#constructing-stylesheets

<annevk> https://github.com/whatwg/html/pull/4898 is the PR and doesn't have other concerns afaict.

should adoptedStyleSheets be assignable

<masonfreed> https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-624773407

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

hober: want this to be consistent with document.styleSheets

<TabAtkins> (Justin is covering my comments.)

justin: there is a back compat issue with adding .item to array, so there will be a fork between JS and CSS items

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

hober: can we just spec a property with a different name to avoid backward compatibility concerns

<slightlyoff> usage is relatively high for this feature today: https://chromestatus.com/metrics/feature/timeline/popularity/2846

+1 to mason's point on it supports good scenarios, not just a question of back compat

<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.

justin: framework author perspective, we have very static styles that make the assignment syntax nice

justin: many of our scenarios are single actor and would benefit from assignment

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

hober: usage being high seems more like argument for Chrome compat and not right API

Alex can you write what you said? I missed it.

<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

Jan: I like ObservableArray, push would be great for my library. We add stylesheets across multiple prototypes and push seems more usable

Justin: not arguing against ObservableArray, just adding assignability

<slightlyoff> Rob's point is a good one: these are not exclusive options

Rob: we prefer assignability for our framework... (Rob can you please write the reason you said)

Action: continue discussion for adoptedStyleSheets in issue

Emilio: like ObservableArray, wants alignment with other APIs though

<Zakim> MikeSmith, you wanted to ask

<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.

Justin: made proposal for @sheet syntax for CSS bundling where @sheet could be named and available for import. PTAL

Mike: what's the overall plan in terms of where it will live?

Dan: it will be in the HTML spec

<Rob> Thanks all!

<slightlyoff> so excited to see this moving forward; great work all

<dandclark> Slides: https://1drv.ms/p/s!AtmAxiCADIM8nf4vuh8bmWLljCv4tQ

<dandclark> Import Assertions PR: https://github.com/whatwg/html/pull/5883

<slightlyoff> hober: giving up on inline modules in JS is one of my great ES6 regrets; I think Shu has a path back, tho