You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been wondering if it's worth documenting clearly why we have this type mechanism to ensure it does not get circumvented by types going forward.
E.g., say an "html" module type were added and those modules could themselves not execute script or import other modules. Then if a script execution ability was added, that should warrant a new type as existing consumers might not anticipate that happening.
The text was updated successfully, but these errors were encountered:
It's a core goal of module attributes to provide a mechanism to prevent this sort of privilege escalation, so I think it's great to talk these things through ahead of time. I'd say, we should create some sort of norm that the interpretation of a type value does not change in that way: if it starts out not being able to execute scripts, you should have to use a new type value to allow it to execute scripts.
I'm not sure whether this should be a normative requirement in ECMA-262, or more like something we'd put in W3C TAG design principles; maybe the latter would make more sense, as this is somewhat of a vague property.
I've been wondering if it's worth documenting clearly why we have this type mechanism to ensure it does not get circumvented by types going forward.
E.g., say an "html" module type were added and those modules could themselves not execute script or import other modules. Then if a script execution ability was added, that should warrant a new type as existing consumers might not anticipate that happening.
The text was updated successfully, but these errors were encountered: