Remove -webkit-mask-box from the legacy alias name so they stand on their own.
karlcow opened this issue · 11 comments
6 years later no browsers are implementing mask-border and variants. We should probably remove -webkit-mask-box from the legacy alias name, and move them to a section where we say that they need to be supported on their own.
Originally posted by @karlcow in #14 (comment)
Maybe a note could be added that the intent is that they would be used/aliased as mask-border, but at this time nobody does, nor even implement mask-border.
As of today
- P2 WebKit Bug 229900 [css-masking] Implement mask-border properties. Last updated 2021-09-10
- P3 Gecko Bug 877294 [Meta] Implement border box mask (mask-border-*) support. Last updated 2016-03-03.
There is also a Add -webkit- prefixed aliases for mask-border-* properties which proposes an alias once mask-border is implemented. - Blink No bug founds related to implementing mask-border
canIuse mask-border is in fact just mentioning -webkit-mask-box
That looks pretty dead to me as an alias for now.
@birtles I see you are one of the spec editors. Do you see any progress?
@tabatkins do you know if Google has an intent to implement mask-border?
@miketaylr Should we move these properties in their own section as there is no real implemented mapping 1-1 to a non-aliased one.
Sorry, I haven't touched that spec for years.
I didn't find any breakage on webcompat issues related to -webkit-mask-box and mask-border.
On GitHub, CSS are usually already associating the two propoerties with the same value.
- Usage of -webkit-mask-box-image: around 0.8%
- The rest is around 0.1% or less.
I think the most important thing is to keep linking to https://drafts.fxtf.org/css-masking/#the-mask-border-source etc, since that's where it's properly specced (even without unprefixed implementations). Whether that is considered a legacy alias, or its own thing - I don't think it matters much.
Possibly browsers implement the unprefixed props one day, and then it becomes a legacy alias. Do we move things back?
Possibly browsers implement the unprefixed props one day, and then it becomes a legacy alias. Do we move things back?
yes.
Sure, that works for me (I'm also fine with doing nothing ^___^).
@miketaylr what about if I send a PR to add a comment similar to the one about -webkit-background-size pointing to this issue here?
https://compat.spec.whatwg.org/#css-simple-aliases
SGTM!
I think the most important thing is to keep linking to https://drafts.fxtf.org/css-masking/#the-mask-border-source etc, since that's where it's properly specced (even without unprefixed implementations).
Strong +1 to this.
Whether that is considered a legacy alias, or its own thing - I don't think it matters much.
Honestly I'm a bit skeptical about how much value there is in this. Even just putting a note saying that this isn't actually an alias in existing implementations seems… kinda sensible? Or maybe we need some new concept for aliasing which isn't aliasing that can also cover things like -webkit-box where we want it to be an "alias" of the Flexbox [X] WD.
yes.
The way I understand the aliasing section is that:
Hey here, you need to support these values as aliases of these because if you do not the sites will break.
While in this case, none of the browsers, actually implement the other values. So for now it is really a case of
you need to implement these CSS properties with the behavior defined in the spec defining mask-border
which is not aliasing.