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.

Sign up for GitHub

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

Jump to bottom

Make spec state that <meta name> must not be use for any new features with UA processing requirements, and instead new attribute should be minted: <meta newfeature=value> #2335

Open
sideshowbarker opened this issue Feb 8, 2017 · 7 comments
Open

Make spec state that <meta name> must not be use for any new features with UA processing requirements, and instead new attribute should be minted: <meta newfeature=value> #2335

sideshowbarker opened this issue Feb 8, 2017 · 7 comments
Labels
addition/proposal New features or enhancements

Comments

@sideshowbarker
Copy link
Contributor

For context, see #2229 (comment) part of the comment thread starting around #2229 (comment).

We should consider having the spec state that when minting new features that have UA processing requirements and that need a markup hook, meta[name] must not be used.

That is, we should have the spec make clear that the way meta has been used for meta[name=referrer], meta[name=theme-color], meta[name=viewport], and meta[name=application-name] is an anti-pattern that going forward we must avoid repeating.

The alternative proposed is that we have the spec state that for any new features similar to meta[name=referrer], meta[name=theme-color], or meta[name=viewport] that have UA processing requirements, a new separate new attribute for meta should be minted for each such feature:

<meta newfeature="value">
@sideshowbarker sideshowbarker changed the title Add guidance for UA implementors to avoid discourage use of <meta name> for any new features with UA processing requirements Add guidance for UA implementors to avoid discourage use of meta[name] for any new features with UA processing requirements Feb 8, 2017
@sideshowbarker sideshowbarker changed the title Add guidance for UA implementors to avoid discourage use of meta[name] for any new features with UA processing requirements Make spec state that <meta name> must not be use for any new features with UA processing requirements, and instead a new attribute should be minted: <meta newfeature=value> Feb 8, 2017
@sideshowbarker sideshowbarker changed the title Make spec state that <meta name> must not be use for any new features with UA processing requirements, and instead a new attribute should be minted: <meta newfeature=value> Make spec state that <meta name> must not be use for any new features with UA processing requirements, and instead new attribute should be minted: <meta newfeature=value> Feb 8, 2017
@sideshowbarker sideshowbarker mentioned this issue Feb 8, 2017
Merged
@zcorpan zcorpan added addition/proposal New features or enhancements good first issue Ideal for someone new to a WHATWG standard or software project labels Sep 1, 2018
@zcorpan zcorpan mentioned this issue Sep 26, 2019
Open
@Malvoz Malvoz mentioned this issue Sep 26, 2019
Open
@Malvoz Malvoz mentioned this issue Oct 14, 2019
Closed
@adrianhopebailie adrianhopebailie mentioned this issue Oct 15, 2019
Closed
@Malvoz Malvoz mentioned this issue Apr 22, 2020
Closed
@eportis-cloudinary eportis-cloudinary mentioned this issue Jun 1, 2022
Closed
@zcorpan zcorpan removed the good first issue Ideal for someone new to a WHATWG standard or software project label Jun 2, 2022
@zcorpan
Copy link
Member

zcorpan commented Jun 2, 2022

I was reminded of this issue for WICG/client-hints-infrastructure#108 (comment)

In w3ctag/design-reviews#702 (comment) @domenic says http-equiv should be used for new things that modify the processing model, and name for metadata.

So, where do we stand wrt the proposal in this issue? Using feature="value" instead of http-equiv="feature" content="value" seems tempting to me, although a possible issue is that we don't want to use dashes in new HTML attribute names, and features names are likely to contain dashes.

@domenic
Copy link
Member

domenic commented Jun 2, 2022 •
edited
Loading

Hmm yeah, I had forgotten about the alternative of introducing new attributes.

I'm not too worried about longer feature names. We'll just use the usual runeverythingtogethercase.

I also am not sure I agree with the OP's assessment of application-name and theme-color as being in the processing-model-impacting category. They feel more like metadata, which some parts of the UA sometimes use? And they're reflected back to JS (via document.querySelector("meta[name='theme-color']").content if nothing else). But they don't change something fundamental to the page's behavior, like referrer clearly does. (I'm not sure where viewport fits but I suspect more toward referrer.)

Pros of new attributes:

  • Although http-equiv is defined as a "pragma", it's pretty confusing, due to what's historically ended up there.
  • The "HTTP equivalence" name is a total lie, so moving away from it might be good.
  • Consistent with charset="".

Pros of continuing to use http-equiv:

  • Somewhat more consistent with the spec's current division and definitions.
  • Encourages metadata (whether informative or processing-model modifying) into a key/value format, which seems vaguely appropriate.
  • Avoids us having to define what <meta feature1="value1" feature2="value2" http-equiv="refresh" content="value4"> does. (Although I guess we have that issue with charset="" + name="" + http-equiv="" already, and maybe it's fine?)
  • Leaves the attribute space for "things that modify the feature", in the way that media="" does today.

@sideshowbarker
Copy link
Contributor Author

I don’t have a strong opinion on using http-equiv vs. minting new attributes. Looking at the pros and cons in #2335 (comment) it doesn’t seem that one or the other is clearly better or worse.

But I do still feel strongly that the spec should normatively state that name must not be used (in cases where a new attribute or http-equiv could be used instead). Shoehorning more things into name should be discouraged.

@zcorpan
Copy link
Member

zcorpan commented Jun 3, 2022

I agree with those, and would add

Pros of new attributes:

  • Shorter
  • Easy feature-detection (check presence of IDL attribute)

Pros of http-equiv:

  • Less mental overhead for web developers to remember which features use which syntax. We already have meta name vs meta http-equiv vs link rel, adding yet another way to do things would add more special cases to remember.

On balance, I think http-equiv is better. I haven't seen requests for feature-detection of the existing meta features, so maybe it's not needed.

There is also the option of adding new attributes to <html>, though it doesn't work so well when you need multiple attributes (like for theme-color + media), but it could make sense for some features.

@annevk
Copy link
Member

annevk commented Jun 3, 2022

I think there's another wrinkle that any kind of policy done through markup ends up being a mutable policy (if only from unset to set), which is not always great. If we're going to make changes here let's add a warning against using these for policies.

@domenic
Copy link
Member

domenic commented Jun 3, 2022 •
edited
Loading

I think the remaining thing we might not have have consensus on is whether it's OK to use name="" for metadata that is UA-processed, but does not "impact the processing model". To be clear, by "impact the processing model" I mean: cause web-developer observable effects on other ways the browser processes your HTML or JavaScript or CSS.

Clear examples of not impacting the processing model in this way are application-name and theme-color. If I understand @sideshowbarker correctly, he's suggesting that we should not have used name="" for those, or for any future features of that type.

Part of this is presumably motivated by how, per #2229, we have dropped the registration requirement for name="" and thus anyone could be using any name value in their document. So any name we choose would have the possibility of reinterpreting conformant documents, and possibly make them invalid.

I think I prefer not to go that far. I think it's OK to have name="" generally be used for non-"processing-model-impacting" metadata, in the above sense. And then there might be some special cases of that metadata, which certain user agents process and do something interesting with. This fits with the pattern of the original name="" values like keywords and description, which scraper or indexer user-agents would have special processing for. theme-color and application-name feel like just extensions of keywords and description, aimed this time at web browsers.

What do others think?

@annevk
Copy link
Member

annevk commented Jun 3, 2022

I think it'll be hard to predict that something will never "impact the processing model". If something like theme-color becomes very popular, user agents might want to add an API around it or elevate it to a CSS feature for which theme-color sets the default.

That is not to say that I think it's problematic that they use the name="" attribute. I don't think any of these have been problematic. They're not always being aesthetically pleasing, but we wouldn't have taken a fundamentally different approach either. We should maybe find a better home for https://wiki.whatwg.org/wiki/MetaExtensions though.

@domenic domenic mentioned this issue Nov 1, 2022
Open
loqibot pushed a commit to indieweb/wiki that referenced this issue Feb 20, 2023
[tantek] added "HTML spec proposal to disallow further meta name prop…
66d3994 
…osals: whatwg/html#2335" to "See Also"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
addition/proposal New features or enhancements
Milestone
No milestone
Development

No branches or pull requests
4 participants
@sideshowbarker @zcorpan @domenic @annevk