Open gibson042 opened 1 year ago
I think that it's very important there not be an escape hatch - giving the ecosystem carte blanche to throw whatever they like in here risks fragmenting the language.
The proposal already allows each implementation to define its own list of supported attributes: https://tc39.es/proposal-import-assertions/#sec-hostgetsupportedimportassertions
This suggestion wouldn't change that. It would, however, allow a way for new assertions to be added without requiring fragmentation of source files.
@gibson042 Maybe the link has changed to this? https://tc39.es/proposal-import-attributes/#sec-hostgetsupportedimportattributes
Now that #131 has established a requirement for implementations to reject unknown attributes, deferring the upgrade concerns of https://github.com/tc39/proposal-import-assertions/issues/21#issuecomment-551987820 and https://github.com/tc39/proposal-import-assertions/issues/56#issuecomment-629698719 is more hazardous. As suggested in https://github.com/tc39/proposal-import-assertions/pull/131#issuecomment-1453846367 , I think it would be valuable to add an escape hatch allowing authors to explicitly indicate that particular import attributes should be ignored when they are unknown to an implementation. It would be logically similar to the
!
criticality flag of the IETF timestamp suffixes draft, but with reversed polarity. As a strawperson, @nicolo-ribaudo suggested syntax likewith { type: "css", layer?: "utilities" }
orwith { type: "css", "layer?": "utilities" }
.And a final point noted at https://github.com/tc39/proposal-import-assertions/pull/131#issuecomment-1458296576 :