01:44:40 <RRSAgent> RRSAgent has joined #new-modules
01:44:40 <RRSAgent> logging to https://www.w3.org/2019/09/18-new-modules-irc
01:44:42 <wseltzer> rrsagent, make logs public
01:58:29 <denis> denis has joined #new-modules
03:10:43 <denis> denis has joined #new-modules
03:50:53 <jessie> jessie has joined #new-modules
03:57:23 <denis> denis has joined #new-modules
04:17:35 <danclark> danclark has joined #new-modules
04:19:29 <sanketj_> sanketj_ has joined #new-modules
04:19:53 <BoCupp> BoCupp has joined #new-modules
04:21:06 <sanketj> sanketj has joined #new-modules
04:22:59 <BoCupp> scribe: bocupp
04:23:10 <BoCupp> topic: json, css, and HTML modules
04:26:42 <juyoung> juyoung has joined #new-modules
04:28:08 <JuanCorona> JuanCorona has joined #new-modules
04:31:09 <TabAtkins> TabAtkins has joined #new-modules
04:31:15 <TabAtkins> ScribeNick: TabAtkins
04:31:26 <pmdartus> pmdartus has joined #new-modules
04:31:27 <vkuntz> vkuntz has joined #new-modules
04:31:28 <TabAtkins> danclark: [introduces]
04:31:35 <bashi> bashi has joined #new-modules
04:31:35 <TabAtkins> danclark: Talking abou tne wmodule types: json, css, html
04:31:37 <vkuntz> present+
04:31:47 <TabAtkins> danclark: Gonna introduce, show hwo they work, show snippets, why they're useful for web devs.
04:31:52 <heycam> heycam has joined #new-modules
04:31:54 <TabAtkins> danclark: Some might be recap, some might be new to you.
04:31:56 <hayato> hayato has joined #new-modules
04:32:05 <TabAtkins> danclark: lastly, open issues and design questions
04:32:09 <nhiroki> nhiroki has joined #new-modules
04:32:27 <TabAtkins> danclark: Problem to solve is today, to write a web comp that's reusable and importable, the ony way to package it is with JS, primarily JS modules.
04:32:36 <TabAtkins> danclark: The css and html doesn't have a home, it lives in the JS.
04:32:48 <TabAtkins> danclark: We'd like to empower authors to write html as html, etc for inclusion with their components
04:32:49 <tpk> tpk has joined #new-modules
04:32:56 <TabAtkins> danclark: We already have a great tool for dep management in JS.
04:33:10 <TabAtkins> danclark: JS odules gives me static dependencies, parallel loading, clear syntax for API surface
04:33:13 <Irfan> Irfan has joined #new-modules
04:33:17 <MikeSmith> MikeSmith has joined #new-modules
04:33:18 <Irfan> present+
04:33:21 <TabAtkins> danclark: A module can define what it exports, importer can define what they want to import
04:33:31 <TabAtkins> danclark: And they're only loaded once, even if they're imported multiple times
04:33:32 <JuanCorona> present+
04:33:44 <TabAtkins> danclark: So that's great for JS, but dont' ahve a story for html and css
04:33:54 <TabAtkins> danclark: There's some work to be done in advance for css/html modules
04:34:00 <TabAtkins> danclark: Synthetic module record has been specced
04:34:26 <TabAtkins> danclark: Idea is I take some resource, like JSON, which can be projected into JS, if i want to plug them into the mod ule graph there's some common boilerplate I need to achieve that, both in spec and impls.
04:34:36 <TabAtkins> danclark: Synthetic module spec formalized that boilerplate
04:34:48 <TabAtkins> danclark: So we implemented synthmod records in Blink/v8
04:34:59 <TabAtkins> danclark: Then did JSON modules, with Igalia, behind a flag.
04:35:02 <tomayac> tomayac has joined #new-modules
04:35:07 <TabAtkins> danclark: I just import JSON resource, get a JSON object.
04:35:22 <TabAtkins> danclark: CSS modules are an integration of constructable stylesheets into the module system
04:35:32 <TabAtkins> danclark: [shows code example using adoptedStylesheets]
04:35:37 <yigu> yigu has joined #new-modules
04:35:47 <TabAtkins> danclark: Why want this?
04:36:03 <TabAtkins> danclark: If i'm developing a webcomp and want to include styles, all the ways have rough edges
04:36:26 <masonfreed> masonfreed has joined #new-modules
04:36:26 <TabAtkins> danclark: most obvious is a <style> element in the shadow dom. Ergonomics, there's an extra element there now. Might be some perf implications too.
04:36:58 <TabAtkins> danclark: Alternatively I can use constructable stylesheets directly, inlining CSS in my JS and make a stylesheet. Not great for ergonomics again, lots of CSS in JS. And perf again, processing it twice.
04:37:22 <TabAtkins> danclark: Can get around this by fetching and stuffing into constructable stylesheet directly, but then i'm manually managing these fetches. Lots to get right.
04:37:35 <TabAtkins> danclark: [shows before/after of a webcomp using css modules]
04:38:00 <TabAtkins> danclark: Lastly, Html modules
04:38:17 <DavidClarke> DavidClarke has joined #new-modules
04:38:17 <heycam>  present+
04:38:27 <TabAtkins> danclark: Same idea here, building html for custom elements requires HTML as a JS string, or doing lots of document.createElement() with lots of dom operations, totally unreadable.
04:38:55 <DavidClarke> present+
04:38:57 <TabAtkins> danclark: [shows off html module example]
04:39:09 <TabAtkins> danclark: HTML module returns a document object, I can append it wherever I want
04:39:19 <TabAtkins> danclark: Don' thave to manually build that dom in a tricky way
04:39:33 <TabAtkins> danclark: Progress: JSON modules, thanks to Igalia, are in HTML spec. Built in blink behind flag.
04:39:39 <TabAtkins> danclark: CSS modules, prototyped in Blink, spec draft.
04:39:44 <TabAtkins> danclark: HTML modules, similar to CSS.
04:40:06 <TabAtkins> danclark: we consider css modules kinda a prereq to html modules, we'll cover some details of that later
04:40:11 <TabAtkins> danclark: Any questions so far?
04:40:29 <denis> denis has joined #new-modules
04:40:33 <TabAtkins> heycam: Do you see much benefit for css modules beyond just inserting a <link> into the shadow tree?
04:40:50 <TabAtkins> danclark: Dev ergonomis, we don't want to mess with the dom. It's a little easier without an extra element there.
04:40:52 <jessie> jessie has joined #new-modules
04:41:12 <TabAtkins> danclark: Also, a <link> means I have a new instance of the stylesheet in each instance of th ecustom element.
04:41:27 <TabAtkins> danclark: CSS Module means I know it's all the same, even if it's from different custom elements.
04:41:34 <TabAtkins> heycam: Is this because you want to modify them?
04:41:40 <TabAtkins> danclark: Possibly yes.
04:41:48 <TabAtkins> heycam: Because browsers shoudl dedup automatically
04:42:11 <TabAtkins> heycam: Okay, then import, it's not too much work to map a fetch to a consructed stylesheet.
04:42:39 <TabAtkins> danclark: Interesting with more dependencies. A widget library tehat shares stylesheets, it's nice to plug into the module system and not worry abou tmaanging the fetch calls.
04:43:01 <TabAtkins> danclark: And when combining module types, a JS module that defines and lemeent and imports a css module, i know that by th etime by JS code is executing, I already know my CSS is available and processed.
04:43:23 <TabAtkins> danclark: Just one stylesheet, import isn't that interesting, but in non-trivial situations module graph give syou a lot of power and ease.
04:44:17 <TabAtkins> [something about base urls from Jake]
04:44:43 <hiroshige> hiroshige has joined #new-modules
04:45:01 <TabAtkins> ???: Is there a naming question? You can't tell whether it's css, json, etc from the statement.
04:45:18 <TabAtkins> danclark: That's my third open issue on this slide, i'll loop back to it.
04:45:44 <heycam> s/???/ThomasSteiner/
04:45:50 <diervo> diervo has joined #new-modules
04:45:56 <TabAtkins> rniwa: Which repo do we file issues on?
04:46:03 <diervo> present+
04:46:17 <TabAtkins> danclark: the web components repo, w3c/web-components
04:46:22 <TabAtkins> w3c/webcomponents
04:46:40 <TabAtkins> MikeSmith: CSS modules is mainly intended for web components use-case?
04:46:45 <TabAtkins> danclark: That's our primary right now, yeah.
04:47:13 <TabAtkins> phil cupp: I could see a replacement for scoped style, where stylesheets hang off of elements, etc.
04:47:25 <TabAtkins> BoCupp: But right now it's limited to shadow roots, yeah.
04:47:37 <tomayac> The issue is https://github.com/w3c/webcomponents/issues/759
04:47:52 <TabAtkins> MikeSmith: We already have a way to import CSS into an html document, we don't have one for html, so for the dev community we want to be more clear about what problem we're solving that isn't the <link> element.
04:48:29 <TabAtkins> jake archibald: CSS doesn't need CORS normally, does that affect modules here?
04:48:47 <TabAtkins> danclark: Same semantics as JS modules, it requires CORS approval for cross-origin stuff
04:48:52 <TabAtkins> TabAtkins: I approve of this.
04:49:06 <TabAtkins> thomasSteiner: Browser vendor feedback?
04:49:34 <TabAtkins> BoCupp: We have some interest from annevk in discussions (firefox), maybe ryosuke wants to say something
04:50:02 <TabAtkins> rniwa: We'r enot opposed, we like th eidea of improving dev experience, but we do have some concerns with mime-type issue, etc. And maybe something with dynamic import behavior.
04:50:26 <TabAtkins> jake archibald: Bundlers have this issue already, how to interpret a resource. Like an image, is it a blob, or a data url, etc.
04:50:44 <TabAtkins> danclark: So first open issue: how does @import work in the stylesheet?
04:50:45 <Irfan> rrsagent,make minutes
04:50:45 <RRSAgent> I have made the request to generate https://www.w3.org/2019/09/18-new-modules-minutes.html Irfan
04:50:52 <TabAtkins> danclark: First obvious way is handle them same as normal stylesheets.
04:51:16 <TabAtkins> danclark: When I include an @import in two different imported sheets, I'll have two different stylesheet objects.
04:51:21 <TabAtkins> (an @import of the same url)
04:51:37 <TabAtkins> danclark: Anothe roption is to treat an @import in a CSS module as a module in their own right; they stop being leaf modules.
04:51:55 <TabAtkins> danclark: Most interesting effect here is that multiple stylesheets @importing the same sheet only imports once.
04:52:11 <TabAtkins> danclark: [example from justin fagniani]
04:53:16 <TabAtkins> danclark: [example swap out styles in a sheet based on a theme]
04:53:40 <TabAtkins> danclark: We think that's kinda neat. It also complicates the model tho.
04:53:51 <TabAtkins> danclark: @imported sheet no longer has a parent stylesheet
04:54:07 <Bowen> Bowen has joined #new-modules
04:54:08 <TabAtkins> danclark: So it' snot clear if the wins here are worth complicating the model.
04:54:25 <TabAtkins> danclark: Interested if people find it compelling, or have customers that might want this behavior. Feedback can be given in issue thread later.
04:54:46 <TabAtkins> heycam: Is that a common way now for people to dynamically swap styles? To dig into CSSOM, as opposed to setting class names?
04:54:58 <TabAtkins> heycam: More difficult here, yeah, because lots of shadow trees rather than one instance to change.
04:55:05 <Zakim> Zakim has joined #new-modules
04:55:28 <Irfan> rrsagent,make minutes
04:55:28 <RRSAgent> I have made the request to generate https://www.w3.org/2019/09/18-new-modules-minutes.html Irfan
04:55:31 <TabAtkins> danclark: A bit easier here, because you don't ahv e to do OM dancing, just swap the whole thing around.
04:56:38 <TabAtkins> jake: Can be done manually with some hackier work today.
04:56:49 <TabAtkins> jake: [gives example from the issue thread]
04:57:29 <TabAtkins> ???: We can speak for SalesForce, we are transitioning to a WB arch, and we have customers that want basic customization, and variables are fine for them. But we have others that want to redesign the whole thing, and we're envisioning short stylesheets that get injected into shadows.
04:57:46 <TabAtkins> ...so regardless, we'd like a single place to be able to change these things.
04:58:12 <TabAtkins> diervo: [missed about nested imports]
04:58:31 <TabAtkins> diervo: In that example, element.css imports other things. We walk the tree and resolve imports ahead of time.
04:59:08 <pmdartus> present+
04:59:15 <pmdartus> s/??/pmdartus
04:59:28 <TabAtkins> BoCupp: If you're the widget author, not the page author, you're affecting th einnards of your control.
04:59:57 <TabAtkins> BoCupp: Either you can require the page author to do a convention that'll apply to everyone, which feels a little weird to me. Or you iterate thru each instance of the component and notify them.
05:00:15 <TabAtkins>  BoCupp: Whereas here it's probably an API exported in one place, a changeTheme().
05:00:48 <TabAtkins> rniwa: Historically theming in WC sense was suggested done thru css variables, etc.
05:00:53 <TabAtkins> rniwa: How does this play with that?
05:01:21 <TabAtkins> BoCupp: Orthogonal.
05:02:30 <TabAtkins> rniwa: So myq uestion is if this "small number of predefined themes" that this enables more popular/common than css variables customizable theme?
05:02:48 <TabAtkins> diervo: It's about control. Some customers, css vars are totally fine, everything they need.
05:02:58 <TabAtkins> diervo: But not for everyone.
05:03:21 <TabAtkins> diervo: WE can say "these are the classes/elements you can customize", but some people want to take over in ways we can't predict.
05:03:37 <TabAtkins> diervo: So we want a long-term reliable way to make sure this high-control sort of customer can be handled.
05:04:01 <TabAtkins> rniwa: Yeah in this one you can just past in all the style you want and get full control.
05:04:49 <TabAtkins> rniwa: that raises an interesting question. in some cases you don't want to give that control to someone.
05:05:31 <TabAtkins> rniwa: [question about cloning imported stylesheets]
05:06:09 <TabAtkins> rniwa: So in this idea, you don't have control over whether th eimported sheet is shared or not, it's always shared.
05:06:34 <TabAtkins> danclark: Next issue. HTML modules, again some appraoches.
05:06:47 <TabAtkins> danclark: html as leaf, basically a doc fragment
05:06:55 <TabAtkins> danclark: static contents, scripts dont' run, etc
05:07:22 <TabAtkins> danclark: also possible to make them much more powerful, allow them to contain scripts that are processed as js modules, style/link that are interepreted as css modules, etc
05:07:35 <TabAtkins> danclark: one way to take advantage of this is [shows example]
05:07:45 <TabAtkins> danclark: my content is static in the module
05:08:25 <TabAtkins> danclark: so since this is in the context of an html module, the style here would be a child css module, and i can use it in the js module usable with adopted stylesheets
05:08:50 <TabAtkins> danclark: We haven't totally settled on semantics, but it's similar to a JS module ahving multiple imports.
05:09:07 <TabAtkins> slightlylate: would those be exposed as children of the module object?
05:09:11 <TabAtkins> danclark: Not right now.
05:09:24 <TabAtkins> danclark: They're only exposed via the dom.
05:09:38 <TabAtkins> danclark: But the js in the html module could choose to explicitly export things to the module object.
05:10:20 <TabAtkins> danclark: another idea here is to include script in my html module, and those scripts get access to the html module they're in via a special import syntax `import.meta.document`
05:11:31 <TabAtkins> diervo: We don't allow sloppy mode, right?
05:11:40 <TabAtkins> danclark: Yeah only modules, don't allow classic scripts
05:11:56 <TabAtkins> danclark: Otherwise classic scripts can sync call out to other scripts, breaks all sorts of invariants.
05:12:20 <TabAtkins> danclark: If we went this way, you could still use it as a leaf mode, the default export would be the document.
05:12:43 <TabAtkins> danclark: And it could be overriden if you wanted, via normal export semantics
05:12:49 <TabAtkins> rniwa: Does this doc hav ea browsing context?
05:12:52 <TabAtkins> danclark: No.
05:12:58 <TabAtkins> jake: So images wont' load, etc
05:13:10 <TabAtkins> danclark: If we go this way, you can write you web components with html on top.
05:13:17 <TabAtkins> danclark: Style and script as children in the html.
05:13:19 <vkuntz> vkuntz has joined #new-modules
05:13:26 <TabAtkins> danclark: And now my web components look liek little web pages
05:13:35 <TabAtkins> danclark: We think this is interesting and potentially a good practice.
05:13:41 <vkuntz> present+
05:14:03 <TabAtkins> thomasSteiner: Good for toolchains too, easier to handle.
05:14:40 <TabAtkins> danclark: An example of this is, Blink is building some new type sof elements as modules
05:14:44 <TabAtkins> danclark: Layered API stuff
05:15:01 <TabAtkins> danclark: [shows code for <toast>]
05:16:09 <TabAtkins> danclark: Questions aobut this? Interesting way of authoring components?
05:16:25 <TabAtkins> danclark: It can potentiallys ignificant complexify HTML modules, but I think the opportunities are pretty interesting.
05:17:28 <TabAtkins> danclark: open issue about mime type
05:17:42 <TabAtkins> danclark: Can't look at file extension. If i get json, how do i know what type of module to instantiate?
05:17:46 <TabAtkins> danclark: Maybe there's a security concern here
05:18:14 <TabAtkins> danclark: one way of looking at this is that json is syntax sugar for a js file that creates a json object and return sit
05:18:43 <TabAtkins> danclark: but maybe i think of this as a replacement for fetching some text and JSON.parsing it. nowhere there is oppo to run script, but this import *can* if the mime type is json
05:18:50 <TabAtkins> s/is json/is js/
05:19:26 <TabAtkins> danclark: if host i'm importing from is compromised, could get surprise xss
05:19:54 <TabAtkins> danclark: might be able to fix this by creating a way to specify type unambiguously in the import
05:20:09 <TabAtkins> danclark: Another way is CSP script-src, but it got shut down last night
05:20:18 <TabAtkins> diervo: It was opt-in, that was the objection.
05:20:48 <yigu_> yigu_ has joined #new-modules
05:21:54 <TabAtkins> TabAtkins: have we talked to tc39 about adding a clause to the import statement to let you specify the type?
05:22:12 <TabAtkins> [discussion]: tc39 seemed negative, wanted out-of-band info
05:22:18 <TabAtkins> TabAtkins: But that's our exact attack scenario!
05:22:28 <TabAtkins> rniwa: might be worth bringing up again, make sure they're sure
05:22:38 <TabAtkins> rniwa: also, csp adoption isn't great, relying on that might not be great
05:23:09 <TabAtkins> MikeSmith: What about CORB?
05:23:17 <TabAtkins> slightlylate: nobody really knows about that
05:23:29 <TabAtkins> rniwa: and it's solving a different problem, it can disallow content-sniffing, but mime type isn't stopped by that
05:23:48 <TabAtkins> slightlylate: as a terrible hack, if tc39 won't change the surface syntax, there's space in the url syntax to smuggle in type info.
05:24:23 <TabAtkins> BoCupp: do you think this is just the mime type, or is it a larger problem of importing?
05:24:43 <TabAtkins> slightlylate: we have it elsewhere. any time we have syntax that makes assumptions about the type of content it' simporting, like CSS @import
05:25:04 <TabAtkins> rniwa: Yeah other things like subresource integrity can't be specified.
05:37:51 <denis> denis has joined #new-modules
05:38:55 <danclark> danclark has joined #new-modules
05:38:59 <jessie> jessie has joined #new-modules
05:39:45 <drousso> drousso has joined #new-modules
05:39:56 <danclark> This was Justin comment with the @import theming example: https://github.com/w3c/webcomponents/issues/759#issuecomment-490692275
05:40:58 <danclark> (lots of other CSS module discussion on that same thread)
05:42:58 <danclark> Ryosuke filed an issue on the relying-on-MIME-type-to-determine-module-type security issue here: https://github.com/w3c/webcomponents/issues/839#issuecomment-532517385
05:43:37 <drousso> present+ (I forgot to do this earlier)
05:43:41 <drousso> not sure if it matters at this point
06:59:01 <denis> denis has joined #new-modules
07:31:53 <drousso> drousso has joined #new-modules
07:54:11 <MikeSmith> MikeSmith has left #new-modules
07:57:21 <Zakim> Zakim has left #new-modules
08:14:51 <TabAtkins> TabAtkins has left #new-modules
08:30:37 <drousso> drousso has joined #new-modules
08:31:06 <drousso> drousso has joined #new-modules