W3C home > Mailing lists > Public > public-tpac-unconference@w3.org > September 2019

RE: TPAC unconference breakout follow up

From: Daniel Clark <daniec@microsoft.com>
Date: Fri, 27 Sep 2019 16:36:57 +0000
To: Dominique Hazael-Massieux <dom@w3.org>, "'public-tpac-unconference@w3.org'" <public-tpac-unconference@w3.org>
Message-ID: <BN8PR00MB06284B81E2DED13E7DE36402C5810@BN8PR00MB0628.namprd00.prod.outlook.com>

Following below is a summary of the session I led (New Module types: JSON, CSS, HTML - https://w3c.github.io/tpac-breakouts/sessions.html#new-modules):

This session opened by introducing proposals for JSON, CSS, and HTML modules, in which the JavaScript module infrastructure is expanded to allow developers to 'import' content of those types in addition to JavaScript.  The new modules would participate in the module graph and share all of its benefits: static resolution of dependencies, parallelized loading without extra work by the developer, clear definition of components/API surfaces, and assurance that duplicate dependencies are only processed a single time.

The following 3 open design questions were then introduced and discussed:
A) How should CSS module @imports be handled?  Option 1 is to treat @import references in the normal way where each creates a distinct stylesheet reference.  Option 2 is to treat @imports as CSS modules in their own right such that duplicate imports share the same CSSStyleSheet identity.  The latter option has use cases for theme switching, where replacing the contents of an imported stylesheet will fan out to all locations where it is imported.  Some developers have already rolled their own solutions for doing this sort of theme switching so it seems there are uses cases here.
B) Should HTML modules be limited to static content, or should they be allowed to contain <script> and <style> elements that are interpreted as its child modules?  The latter option allows developers to build web components with HTML on top, sort of like small web pages.  There was some interest from the room in this approach.
C) Using MIME type to determine module type poses security concerns because a compromised distributor could send JavaScript instead of JSON/CSS back to the importer, which would then execute in the importer's domain.  CSP was proposed as a solution, but there were concerns about this being opt-in.  Other solutions involve specifying the resource type as part of the import statement, though the best way to do this is not yet clear.

Dan Clark
Microsoft Edge Engineering

-----Original Message-----
From: Dominique Hazael-Massieux <dom@w3.org> 
Sent: Wednesday, September 25, 2019 3:12 AM
To: 'public-tpac-unconference@w3.org' <public-tpac-unconference@w3.org>
Cc: nmooney@duosecurity.com
Subject: TPAC unconference breakout follow up

Dear all,

You're bcc'd on this message as one of the proposers for the breakout sessions at the TPAC unconference day last week [1].

First, thank you - your help in identifying topics for the sessions ahead of the day was critical in adopting the new approach to scheduling breakouts - the early feedback we have received on this new approach has been so far very positive.

Secondly, some of you have already shared short report from your sessions - these reports have now been published on the breakout page (along with the IRC minutes). For those who haven't, please send a report by email to your earliest convenience, or if you feel adventurous, contribute it directly in your session JSON file in
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Ftpac-breakouts%2Ftree%2Fmaster%2Fsessions&amp;data=02%7C01%7Cdaniec%40microsoft.com%7C5c1293445d5340325fac08d741a0e69d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637050031637833745&amp;sdata=T4zxdA0qDZRV%2B2B8VC0kj21ouoOdS4oKROawiS%2BgU7g%3D&amp;reserved=0 (under a "report" property whose value accepts HTML markup, e.g. [2]).

We plan to bring the broader community's attention to these summaries next week or so, so if you want to be part of that broadcast, make sure to send your summary sooner rather than later.

Finally, we're very interested in your feedback  as a breakout organizer on what would have made your life easier or your breakout more impactful, either before, during or after the breakout. Also, if there are lessons you learned in the process you think might be worth sharing with future organizers, please let us know.



1. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Ftpac-breakouts%2Fsessions.html&amp;data=02%7C01%7Cdaniec%40microsoft.com%7C5c1293445d5340325fac08d741a0e69d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637050031637833745&amp;sdata=ByW929vydR5UBY6v9RQqmeWXdfKViZO4ARm6aDyhgik%3D&amp;reserved=0
Received on Friday, 27 September 2019 16:40:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:35:26 UTC