Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attributes divergence #34

Open
xtuc opened this issue Dec 9, 2019 · 3 comments
Open

Attributes divergence #34

xtuc opened this issue Dec 9, 2019 · 3 comments

Comments

@xtuc
Copy link
Member

xtuc commented Dec 9, 2019

One of the concerns with arbitrary attributes it's a possible divergence in an already divergent ecosystem (tooling configuration are not shared for instance).

For the Babel implementation the plan would be to make it available, via the Babel AST, to plugins. Plugin authors would be free to define their own attributes.

@bmeck
Copy link
Member

bmeck commented Dec 12, 2019

I'm not comfortable with only forwarding this through the whole language if only 1 attribute is supported (type) and only a whitelist of values to match the web. I feel that having a variety of keys and values is important for hosts that do not have overlap. Per my experience in Node, I am not clear on what advantage this would solve and as such having a mandated single type attribute itself is an interop concern without a clear benefit to Node as a host currently.

E.g. Browsers adding things like credentials: 'include' seems plausible to the web, but I don't think it should be placed as a mandate upon other hosts.

@mikeal
Copy link

mikeal commented Dec 12, 2019

As we think about the future we’re going have files that need to be interpreted in multiple environments and we expect those environments to change over time (like the browser adding credentials: ‘include’ for instance).

If we assume that only a single property is important we aren’t future proofing very well. It should be safer to just forward along all the properties and assume arbitrary properties may be present and could be important to someone at some point in the future.

MylesBorins added a commit that referenced this issue Feb 4, 2020
@littledan
Copy link
Member

Ultimately, I think the main tool we have available for ensuring compatibility across environments is making normative requirements in the specification. The current draft specification defines requirements for type:, and specifically for type: "json". Other attribute keys and values are left up to host environments to determine, how restrictive or unrestrictive they would be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants