IRC log of new-modules on 2019-09-18
Timestamps are in UTC.
- 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