Is it okay to just alias -webkit-mask-composite to mask-composite?

[saschanaz]

d1ac0cf just added all the mask things as aliases, but per MDN the syntax of this specific one is quite different. Why is it safe to just alias it?

[miketaylr]

It could just be a bug due to me not understanding it well.

[miketaylr]

See also:

https://searchfox.org/mozilla-central/rev/4b88e0b8cca115009e82fdd65e5bf5812ff99128/devtools/shared/css/generated/properties-db.js#2110-2126

  "-webkit-mask-composite": {
    "isInherited": false,
    "subproperties": [
      "mask-composite"
    ],
    "supports": [],
    "values": [
      "add",
      "exclude",
      "inherit",
      "initial",
      "intersect",
      "revert",
      "subtract",
      "unset"
    ]
  },

[miketaylr]

Looking at https://www.w3.org/TR/css-masking-1/#the-mask-composite

<compositing-operator> = add | subtract | intersect | exclude

That seems to match what is in properties-db.js. So yeah, this isn't a "simple alias", but an alias that only supports the subset of values that match the unprefixed values.

[saschanaz]

It seems that list conflicts with webkit and blink implementations, it seems they don't overlap and MDN is right about it?

  '-webkit-mask-composite': {
    values: [
      'clear',
      'copy',
      'source-over',
      'source-in',
      'source-out',
      'source-atop',
      'destination-over',
      'destination-in',
      'destination-out',
      'destination-atop',
      'xor',
      'plus-lighter',
    ],
  },

[miketaylr]

We could do one of two things: document what Gecko does, or keep this as a simple alias. I suspect it's not worth the effort for Gecko to implement all the values, without any evidence that this breaks sites. What do you think @saschanaz?

[saschanaz]

document what Gecko does, or keep this as a simple alias

I think those two options are same given that Gecko implements it as a simple alias. There at least should be a note that the aliased -webkit-mask-composite is incompatible with webkit/blink implementation (although then I'm not sure why the alias should even exist).

[miketaylr]

I just noticed simple alias isn't even defined, and we should fix that.

There at least should be a note that the aliased -webkit-mask-composite is incompatible with webkit/blink implementation (although then I'm not sure why the alias should even exist).

I think this largely depends on what values are important for web compatibility. If no important sites use destination-atop, but they all use add, then it seems useful to have. But if Gecko wants to unship it, we can remove it from the spec.

[saschanaz]

My comments are largely based on the MDN data and spec, for actual implementation I guess @emilio might have an opinion.

[domenic]

We could do one of two things: document what Gecko does, or keep this as a simple alias

Shouldn't we try to get all three browsers to converge on a single interoperable behavior, and have the spec reflect whatever that is?

[miketaylr]

Shouldn't we try to get all three browsers to converge on a single interoperable behavior, and have the spec reflect whatever that is?

Yeah, that's ideal. Unfortunately I don't recall the circumstances surrounding the addition of -webkit-mask-composite - if Gecko had bugs requiring it, or it was initially added by EdgeHTML and Gecko followed. (note: there is some history at #14).

We could do the research to determine which values are important for compat, beyond add, substract, intersect, exclude. As of right now, those are the interoperable values between webkit, gecko, and blink. In theory if the others aren't used, or usage is low-enough to justify removal from the other engines, that would be a nice outcome.

(I guess that's the entire point of this issue being opened and I was too quick to reply. 🙈 )

[saschanaz]

We could do the research to determine which values are important for compat, beyond add, substract, intersect, exclude. As of right now, those are the interoperable values between webkit, gecko, and blink.

Really? CSS.supports("-webkit-mask-composite: add") returns false on Chrome but true on Firefox. I think the implementations of Firefox and Chrome are totally incompatible with each other.

[emilio]

Yeah, so what we implement is just an alias for mask-composite: https://searchfox.org/mozilla-central/rev/7b1de5e29d878cc163dec7beaf9b57a2f0f41aaa/servo/components/style/properties/longhands/svg.mako.rs#169

Blaming it, it goes back to the original implementation of the property in https://bugzilla.mozilla.org/show_bug.cgi?id=686281: https://hg.mozilla.org/mozilla-central/rev/f6eba571ce59.

So this is a bit messy. It was probably just added for consistency with other mask aliases which do share syntax per https://bugzilla.mozilla.org/show_bug.cgi?id=686281#c167.

cc @dbaron in case he remembers more context.

[dbaron]

I don't remember, other than that that bug went through quite a few cycles of review and it was hard to keep track of at the time. I don't think I was aware there was a syntax difference.

[gsnedders]

It seems that list conflicts with webkit and blink implementations, it seems they don't overlap and MDN is right about it?

Indeed. If I'm understanding correctly:

-webkit-mask-composite	mask-composite
clear
copy
source-over	add
source-in	intersect
source-out	subtract
source-atop
destination-over
destination-in
destination-out
destination-atop
xor	exclude
plus-lighter

w3c/fxtf-drafts@bb5f277 seems to be the spec change which changed away from what Blink/WebKit implement, though it doesn't link to any resolution or issues, hence I don't know how broad support for the simplification was at the time.

Note that Blink & WebKit only support the prefixed property, so even if the totally different Gecko implementation is some level of evidence that sites don't rely on the prefixed property, it may only be because they additionally support the unprefixed property.

On the face of it, the options are:

1. Define -webkit-mask-composite as <composite-mode>, per WebKit and Blink today, potentially ensuring something is defined as to how this is combined with the mask-composite property in the cascade.
2. Drop -webkit-mask-composite entirely (though for both WebKit and Blink this is presumably blocked on supporting mask-composite), given Gecko's implementation is okay for web compat seemingly.
3. Define -webkit-mask-composite as a legacy shorthand with only four values (which depends on WebKit and Blink being okay with dropping the rest).