Adding back blink-dev; my bad for not replying-all.
Shu (cc'ed) pointed me to how previous features like top-level await have managed to tie together V8 and Blink flags. You add the V8 flag first, then do something like
https://chromium.googlesource.com/chromium/src.git/+/a19d7fc6b8427d89ade3e1db19098d065a35f8b6 on the Blink side. The key seems to be SetV8FlagIfFeature. I hope that helps?
-Domenic
-----Original Message-----
From: Daniel Clark <
dan...@microsoft.com>
Sent: Tuesday, September 29, 2020 18:07
To: Domenic Denicola <
d...@domenic.me>
Subject: RE: Intent to Prototype and Ship: Import Assertions
That's a fair point. I was thinking that the compat risk is minimal if unknown assertions are rejected by default, but I guess that's not even settled per recent discussion at
https://github.com/whatwg/html/issues/5640. To some extent I guess this depends on how those discussions and the HTML integration unfold.
One difficulty with launching the assertions syntax behind a flag is that there's a question of how best to coordinate with the existing two experimental flags for JSON and CSS modules. Ideally, turning on JSON or CSS modules would also turn on the V8 flag, but it doesn't look like there's much functionality for coordinating V8 runtime flags with Blink flags. The runtime_enabled_features.json5 are exposed in content_shell under internals.runtimeFlags, but I don't see any existing code where the V8 implementation consumes these in C++.
But I understand that flag management difficulties are not justification for shipping a feature, so worst case scenario we can have 3 flags, and the CSS and JSON modules ones will just not do anything interesting unless the V8 import assertions flag is turned on as well (or else all imports of the module types will fail at runtime, since there will be no way to provide the type assertions). We might then run into difficulties if/when we try to ship an origin trial, but that bridge can be crossed when we reach it.
-----Original Message-----
From: Domenic Denicola <
d...@domenic.me>
Sent: Tuesday, September 29, 2020 8:32 AM
To: Daniel Clark <
dan...@microsoft.com>
Subject: RE: Intent to Prototype and Ship: Import Assertions
I’m a little wary of unflagging these in V8 if they don't add any actual value for web developers. It would make more sense to me to leave them behind a flag, until such a time as they can ship in tandem with JSON modules or some similar web-developer-facing feature. Otherwise, I wouldn't be confident that all design and implementation issues are sufficiently worked out.
Stated in terms of
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.chromium.org%2Fblink%2Fguidelines%2Fweb-platform-changes-guidelines&data=02%7C01%7Cdaniec%40microsoft.com%7C095817ef409e46bc535308d8648cc660%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369903077563397&sdata=SJB8HRGsknHxOT7GtdKUUDnPsYcb2DDft1EYlRnriIM%3D&reserved=0, I am slightly worried about compat risk if using these to build a web-developer-facing feature uncovers the need for backward-incompatible changes. (E.g., on the HTML Standard pull request for these, there is still debate between Igalia and the HTML Standard editors on changes that are, potentially, compat-breaking.) And I can't see how import assertions, by themselves, move the web forward enough to justify the risk.
From: 'Daniel Clark' via blink-dev <
blin...@chromium.org>
Sent: Monday, September 28, 2020 19:55
To:
blin...@chromium.org
Subject: [blink-dev] Intent to Prototype and Ship: Import Assertions
Contact emails
mailto:
dan...@microsoft.com
Explainer
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftc39%2Fproposal-import-assertions&data=02%7C01%7Cdaniec%40microsoft.com%7C095817ef409e46bc535308d8648cc660%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369903077563397&sdata=Ff2tWlJxOo6B5FaeU26%2BjDxNApJCQUYz9RD%2F8CW4RtM%3D&reserved=0
Specification
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftc39.es%2Fproposal-import-assertions%2F&data=02%7C01%7Cdaniec%40microsoft.com%7C095817ef409e46bc535308d8648cc660%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369903077563397&sdata=RQMQ7eSa%2FkmTmyZUp28402REmDACC3vzJ8tFkNyzktA%3D&reserved=0
Summary
Import Assertions are an inline syntax for module import statements to pass on more information alongside the module specifier. The syntax is as follows (shown here is the proposed method for importing a JSON module):
import json from "./foo.json" assert { type: "json" }; Blink component
Blink>HTML>Script
TAG review
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3ctag%2Fdesign-reviews%2Fissues%2F535&data=02%7C01%7Cdaniec%40microsoft.com%7C095817ef409e46bc535308d8648cc660%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369903077563397&sdata=ePcAhqVDz8gC8us1jrnCAUzuDzpJTdB%2BaxROVHU1DLk%3D&reserved=0
TAG review status
Issues Addressed
Risks
Interoperability and Compatibility
Given positive signals from other browser implementers we expect this feature to have wide support across browser platforms.
Gecko: Positive (
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fstandards-positions%2Fissues%2F373&data=02%7C01%7Cdaniec%40microsoft.com%7C095817ef409e46bc535308d8648cc660%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369903077563397&sdata=derpONMWWSCFh7JVhgjbweSJ4JyQfINLmQ45SRAfX5M%3D&reserved=0) Worth prototyping
WebKit: Positive
Web developers: Positive
Ergonomics
This feature will be used in tandem with new module types (JSON, CSS, HTML...), and may have additional future uses with module imports. Performance costs will be pay-for-play.
Activation
Build tools and polyfills may be useful for adoption as import attributes and new module types roll out across various browser platform implementations.
Security
This feature is intended to address the security concern described in
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwebcomponents%2Fissues%2F839&data=02%7C01%7Cdaniec%40microsoft.com%7C095817ef409e46bc535308d8648cc660%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369903077563397&sdata=KNSMPFzOy5mYyZ0zN3FYRaB4L6OR8WhWEjzR3I8WC%2FI%3D&reserved=0. Aside from that, the feature does not have any particular security concerns. See the TAG security and privacy review (
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftc39%2Fproposal-import-assertions%2Fblob%2Fmaster%2Ftag-security-and-privacy.md&data=02%7C01%7Cdaniec%40microsoft.com%7C095817ef409e46bc535308d8648cc660%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369903077573391&sdata=Lk7NmutElXXtVh9VopFQPZeFFP8RiZ1S5Y96B9QA2q4%3D&reserved=0)
Goals for experimentation
Validate this feature as a prerequisite for JSON and CSS Modules.
Ongoing technical constraints
None
Debuggability
No special debuggability support needed.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
No
Tracking bug
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Fdetail%3Fid%3D1132413&data=02%7C01%7Cdaniec%40microsoft.com%7C095817ef409e46bc535308d8648cc660%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369903077573391&sdata=N0KY93S6GYOJiNRLj%2BjgtmJsosk0mGcaWf3aMurlbMs%3D&reserved=0
Link to entry on the Chrome Platform Status
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.chromestatus.com%2Ffeature%2F5765269513306112&data=02%7C01%7Cdaniec%40microsoft.com%7C095817ef409e46bc535308d8648cc660%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369903077573391&sdata=VGGBnU6peByABubBseVOiCCbFQ9%2FqTyDr%2BI40hgo0ic%3D&reserved=0
Additional Note
If there are no objections we’d like to ship the import assertions syntax in V8 without gating it behind a flag. The Import Assertions proposal is unlikely to have major changes at this point, and there’s little risk of users taking dependencies on this syntax until features that actually use it (e.g. new module types) are released in a non-experimental manner. The JSON and CSS modules prototypes are still behind an experimental flag, and any plan to support them by default would be announced separately.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mailto:
blink-dev+...@chromium.org.
To view this discussion on the web visit
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fchromium.org%2Fd%2Fmsgid%2Fblink-dev%2FMW2PR00MB0315C274F206795703884D08C5351%2540MW2PR00MB0315.namprd00.prod.outlook.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=02%7C01%7Cdaniec%40microsoft.com%7C095817ef409e46bc535308d8648cc660%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369903077573391&sdata=kAE6axeQdxMFefg%2FuUdq%2Fhv7lL%2FfFrkooGgPWImNBhA%3D&reserved=0.