[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).

[tabatkins]

Agenda+ to agree on matching Domenic's recommendation, making <meta name=color-scheme> match the processing of <meta name=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.

[lilles]

Should we also try to resolve on moving this to the html spec?

[dbaron]

For extensibility to future color values, it might be worth dropping the "Conformance requirements prohibit multiple" from both color-scheme and theme-color, so that developers can use fallback with older and newer values (with the newer value first). (e.g., consider use of a lab() color that's out of the sRGB gamut, intended only for implementations that support things reasonably).

[css-meeting-bot]

The CSS Working Group just discussed [css-color-adjust-1] What happens with multiple <meta>s?, and agreed to the following:

• RESOLVED: Have color scheme use the same meta scheme as theme color.
• RESOLVED: Ask HTML to specify this and move out of CSS specs

The full IRC log of that discussion

<dael> Topic: [css-color-adjust-1] What happens with multiple <meta>s?
<dael> github: https://github.com//issues/3846
<dael> TabAtkins: Have the <meta> name and equals color shceme. Page declares color on root element in way that comes in early on page w/o requiring load css file. Might have noticable delay while page has not great canvas background
<dael> TabAtkins: What happens if you spec same meta multiple times
<dael> TabAtkins: Several options. Reviewing HTML where you can have several metas all possible patterns exist. No consistency. Things that are most similar, esp theme-color meta which adjusts color of UI on page has a specific behavior. First one that's parsable wins and if things are dynamically updated we re-run selection algo
<dael> TabAtkins: Fine for me.
<dael> TabAtkins: Does mean you don't have standard css fallback behavior where can spec newer color and a fallback. Trade off is you don't have to wait several packets to make sure there's no additional metas.
<dael> TabAtkins: Trade-off is fine since this is designed to give a value as soon as possible
<dbaron> You can do the CSS-like fallback behavior by doing it in the reverse order, too, no?
<dael> TabAtkins: Suggest we unify with theme-color meta. First things that parses in the document with the restrictions listed by Dominik.
<TabAtkins> https://github.com//issues/3846#issuecomment-577337007
<TabAtkins> last option
<cbiesinger> s/Dominik/Domenic/
<dael> Rossen_: You said...we prefer the first one if it parses and subsiquent do not trigger restyle. What about nested documents? In an iFrame do I need to know there was already match in primary doc?
<dael> TabAtkins: In terms of selecting a meta no communication. Applying theme colors I don't know if we inherit into other docs but if we do it works same as CSS. iframe selection own meter b/c separate document
<dael> Rossen_: Okay. If based on main there was potentially some info leaked
<dael> Rossen_: Second question, have you considered opposite where we treat it more like style and continue to consider everything? What's main reason to reject it?
<dael> TabAtkins: Not crazy. Reason to reject is first nice to reuse similar modal. Second the purpose of this feature is get a value as fast as possible without making browser delay to get more stuff. Being able to see first and know it's the color to display I think is valuable b/c no need to run trade offs about should I delay paint while I wait to see if there's overrides.
<dael> TabAtkins: If you need multi values due to new color schemes you can just put a style tag in. It's a bit more verbose and depending on your exact csp set up it may not work
<dael> TabAtkins: Addressing exact use case I think we lean toward take first one that matches over benefit of fallback
<dael> Rossen_: Okay. Is more restrictive model. I can't tell if it will be final, but we can also if there are compelling cases to allow subsiquent metas we can scale out model.
<dael> TabAtkins: Ultimately though we talked aout more color schemes I don't think there's any plans now to add them. At least for next several years we're stuck with 2 so we don't have to worry about it. If it changes calculus is different
<dael> astearns: dbaron pointed out if you're concerned about not parsing you can put in reverse order to get fallback order
<dael> TabAtkins: Yeah. Yeah. You can do that. It does have same fallback as CSS. dbaron is right. You put 2 metas, first has new syntax. Modern browsers find the first and use, old can't parse, skip, and than use old. Have fallback, opposite order of CSS
<dael> dbaron: Only weird is it's non-conformant
<dael> TabAtkins: In older browser, yeah
<dael> dbaron: Conformance requirement says it's not allowed to have multiple. Maybe that's not great
<dael> TabAtkins: Agree, value to loosen it
<dael> astearns: Any more comments?
<dael> astearns: Comment from Rune about moving it to HTML spec
<dael> TabAtkins: Agree. Need to settle and than tell HTML what to put in.
<dael> TabAtkins: I think it's abstract theme-color algorithm and have it apply to both
<dael> astearns: Prop: Have color scheme use the same meta scheme as theme color.
<dael> astearns: Perhaps changing conformance requirement to both. Recommend this as change to HTML spec
<dael> TabAtkins: Yep
<dael> astearns: Objections to the scheme?
<dael> RESOLVED: Have color scheme use the same meta scheme as theme color.
<dael> astearns: Obj to have this spec entirely in HTML an not our specs?
<dael> RESOLVED: Ask HTML to specify this and move out of CSS specs
<dbaron> it might still be worth �linking to� the HTML spec to point it out

[astearns]

At the end of the minutes above, @dbaron suggested we should have a link out to the HTML spec definition. I agree

[lilles]

PRs landed for both css-color-adjust and whatwg/html.

Tests moved to wpt/html and Blink implementation fixed: https://chromium-review.googlesource.com/c/chromium/src/+/2380654