whatwg/html

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>

sideshowbarker opened this issue · 7 comments

sideshowbarker commented

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">
zcorpan commented

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 commented

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 commented

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 commented

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.

  • 👍1
annevk commented

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.

  • 👍2
domenic commented

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 commented

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.