[css-color-adjust-1] What happens with multiple <meta>s?

[tabatkins]

What should be the behavior if there are multiple <meta name=color-scheme> elements with different values?

My preference is that we honor the first and ignore the rest. This allows us to paint the background correctly as soon as possible.

However, Device Adaptation specifies that the relevant metas should be interpreted as style elements specifying a @viewport, so that they can cascade together; this means that the last meta affecting a particular @Viewport descriptor "wins".

What rule should we use?

[lilles]

When you say "honor the first", what does that mean for meta elements inserted by a script?

• If there are no color-scheme meta elements and you insert one?
• If there is a color-scheme meta and you insert another one before it with a script in head?

Just apply the first that is inserted into the document either via parser or script?

[tabatkins]

The details are in the spec now for that - whenever the set of metas is changed, we re-evaluate which one is first.

[smfr]

We should do whatever browsers do now for other meta tags. For the viewport meta tag (and other meta tags as far as I can see), iOS uses the last one. This sounds like something HTML should spec.

[lilles]

Fwiw, theme-color is spec'ed to be the first (which is also what Blink implements):

https://html.spec.whatwg.org/multipage/semantics.html#meta-theme-color

For viewport, the Blink implementation applies the last that was inserted into the document, or had its attributes modified, not necessarily the last in the tree-order. This is a behavior we inherited from WebKit.

[smfr]

Has the ship sailed on HTML speccing the same behavior for all <meta> tags?

[css-meeting-bot]

The CSS Working Group just discussed What happens with multiple <meta>s?.

The full IRC log of that discussion

<dael> Topic: What happens with multiple <meta>s?
<dael> github: https://github.com//issues/3846
<dael> TabAtkins: Meta name = color-scheme lets you set initial color-scheme so we can get that value out quick. What happens if you use multiple? Two obvious are take hte first or take the last valid one. Precedent both ways
<dael> TabAtkins: I propose we take the first so we get the value as quickly as possible so don't have to wait for rest of page to load before we apply effects
<dael> AmeliaBR: Since whole point of meta is to get it asap it does make sense. We have examples in HTML that are consistent
<dael> TabAtkins: theme value also takes the first so it's consistent that way
<dael> fantasai: I would consider multiple to be an error case. If you're flipping colors constantly that's your fault. I think it benefits authors if we're consistent and agree with smfr it should be one rule for all meta tags
<dael> fantasai: Given oldest is viewport that means using last one
<dael> TabAtkins: Using last for viewport gives the bad behavior you listed. I think viewport fell out of viewport defined as eq to a stylesheet
<dael> fantasai: It's an error case. If author wants correct they should not ut multiple. I think it's fine if broken isn't correct. Consistant story for authors is more important that it's always last. Arbiraryness is more disruptive then having to keep all the things
<dael> TabAtkins: But if we have to take last, we can't render until have downloaded enough of HTML. I agree with consistency argument. I'd like to be consistent with first and see if we can adjust viewport.
<smfr> q+
<dael> fantasai: If you want to go that route it's fine. i think it's important we're consistent. If you want to see first is web compat that's good.
<dael> astearns: Sounds like we already have different. I'm concerned about hitching consistency to viewport given comment from futhark that viewport is last one inserted into doc.
<dael> TabAtkins: Yeah, ours is messed up. We shoudl not rely on viewport
<astearns> ack smfr
<dael> smfr: before that comment I was reluctant on viewport. Changing viewport now does have more web compat concerns. I would love all meta tags to have sam.e need to figure out dynamically inserted nodes
<dael> smfr: UA might not process meta tags until end of head. Just because you have multiple doesn't mean you'll see flashes, UA can wait until end of head.
<myles> q+
<dael> TabAtkins: Certainly can, but end of head could be different packet and flush the queue. Definitely different behaviors allowed.
<astearns> ack myles
<fantasai> s/rely on viewport/rely on viewport behavior/
<dael> myles: Procedurally meta tag is defined in HTML. If we decide something here is there anyone that can make edits to resolve this?
<AmeliaBR> We are currently defining the meta value: https://drafts.csswg.org/css-color-adjust-1/#color-scheme-meta
<dael> TabAtkins: Should try and get agreement on consitent behavior and get that into general meta authoring guidelines
<dael> astearns: But this needs to be spec elsewhere
<dael> TabAtkins: Yes, actual definition is in HTML. They are deferring to us on this since we're defining it
<dael> astearns: I'm assuming that for web compat reasons we're not going to be able to change current viewport. Given that would anyone object to spec that the color-scheme meta will match theme-color and take first one found?
<dael> smfr: What happens with other meta like char-set?
<dael> TabAtkins: I do not know. But those are also more super legacy and likely to be weird
<dael> astearns: Would be nice to have answer
<dael> smfr: Agree.
<dael> fantasai: Don't want to resolve without jen or rachel
<dael> astearns: Fair
<dael> fantasai: I believe impact to author is bigger concern then get the earliest possible
<dael> TabAtkins: We've got 2 css things that are inconsistent so we'll have to change something. Maybe we have a new policy and legacy is legacy.
<dael> fantasai: If it's completely inconsistent and we can't align I'm fine with a going forward policy. If it's possible to align them all we should go that way
<fantasai> Or even to align most of them
<dael> astearns: TabAtkins can I ask you to do survey of meta tags that effect css?
<dael> TabAtkins: Looking at it. It's a consiquence of algo and not states so I'm chasing it down
<dael> astearns: let's wait on this issue until we get the survey and comments from authoring advocates. Sound good?
<dael> TabAtkins: mmhmm

[domenic]

FWIW of the meta tags that HTML defines processing models for, the following are the behaviors I see:

• application-name:
  • First that matches one of the user's preferred languages based on the lang="" attribute.
  • Does not state how to handle dynamic changes; just gives an algorithm for one-shot determining the application name.
  • Unclear whether ones inside Shadow DOM are ignored or counted (uses ambiguous "in a Document")
  • Inside and outside the head are treated the same.
• keywords:
  • concatenate, split on commas, remove duplicates.
  • Does not state how to handle dynamic changes.
  • Very unclear whether ones inside Shadow DOM are ignored or counted.
  • Inside and outside the head are treated the same.
• referrer:
  • Last one wins, except unsupported values are ignored and don't overwrite previous, supported values. This is intentional to allow fallback in legacy UAs and the conformance requirements do not prohibit multiple.
  • Dynamic changes are handled.
  • Ones inside shadow DOM are ignored.
  • Ones outside the head are ignored.
• theme-color:
  • First parseable-as-a-color wins. Conformance requirements prohibit multiple.
  • Dynamic changes are handled.
  • Ones inside shadow DOM are ignored.
  • Inside and outside the head are treated the same.

It's kind of a mess. We might be able to align some of these but probably not all.

If I were to recommend one to follow for this case it would probably be theme-color.

[tabatkins]

Aw, thank you for doing this analysis, Domenic! Saves me some trouble.

This makes me pretty confident that first-wins is the right way to go, and just unifying fully with theme-color seems totally reasonable.

[lilles]

The current spec says only the meta elements in head are considered. The recommendation from @domenic would be to change that, then.

Viewport is not spec'ed, but the behavior in both WebKit and Blink is that the last one wins, allowed in both head and body, but has broken behavior for DOM modifications (last change wins regardless of tree order). The same broken behavior for dynamic changes was the same for color-scheme in WebKit last time I checked.

@smfr Do you have any feedback based on the last comments from @domenic @tabatkins ?

[tabatkins]

Yeah, aligning would mean meta in body would work (tho be recommended against; it negates the whole point of providing it in a meta).