Meeting minutes
<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://
<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://
<dandclark> https://
<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://
bert: is it better to just embed CSS in JS?
annevk: you can do that if you want with constructable stylesheets
<annevk> Bert: https://
<annevk> https://
should adoptedStyleSheets be assignable
<masonfreed> https://
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://
+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://
<dandclark> Import Assertions PR: https://
<slightlyoff> hober: giving up on inline modules in JS is one of my great ES6 regrets; I think Shu has a path back, tho