search

whatwg / compat

Compatibility Standard
https://compat.spec.whatwg.org/
Other
112 stars 39 forks source link

Remove -webkit-mask-box from the legacy alias name so they stand on their own. #202

Open karlcow opened 2 years ago

karlcow commented 2 years ago

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 https://github.com/whatwg/compat/issues/14#issuecomment-1162736602

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.

karlcow commented 2 years ago

As of today

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.

birtles commented 2 years ago

Sorry, I haven't touched that spec for years.

karlcow commented 2 years ago

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.

miketaylr commented 2 years ago

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?

karlcow commented 2 years ago

Possibly browsers implement the unprefixed props one day, and then it becomes a legacy alias. Do we move things back?

yes.

miketaylr commented 2 years ago

Sure, that works for me (I'm also fine with doing nothing ^___^).

karlcow commented 2 years ago

@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

miketaylr commented 2 years ago

SGTM!

gsnedders commented 2 years ago

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.

karlcow commented 2 years ago

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.

karlcow commented 2 years ago

Related to our discussion