Csswg-drafts: Add -webkit- gradients to CSS Images
Currently these are defined at https://compat.spec.whatwg.org/#css-image-type as mapping to specific _dated_ versions of the standardized properties.
It seems better if these are all defined in the same place so we can at least be sure there's a single underlying set of primitives.
annevk
All 7 comments
I don't even think they do map to specific dated versions? All the stuff from that version is unchanged in the current syntax; current is just expanded. I think we just alias the functions, so you can use newer stuff in them too.
I'm not 100% sure tho and would have to check. @bfgeek is on holiday for the month, tho - pinging @eae to see if the -webkit gradient functions are just aliases or actually handled separately?
tabatkins
on 14 Dec 2018
Looks like I'm wrong; they are indeed different. I even wrote the patch that added unprefixed support, which was distinct from the legacy prefixed support!
tabatkins
on 14 Dec 2018
Honestly, keeping the outdated version of gradients in the new standard forever doesn't seem a good idea to me. The modern version of gradients, with the "magic corners" feature, is definitely better than that old version, and I hope the old version could be safely removed from browsers at some point. I would rather copy the dated definition (and probably adjust it to match the browsers' implementation completely) directly to the Compatibility standard, similarly to how background-clip: text and text-fill-color/text-stroke-* are currently defined.
SelenIT
on 17 Dec 2018
As long as browsers need to support something in order to render the web, it's worthwhile to document them in standards. Whether the definition lives in Compat or Images doesn't make a huge difference, but in general I prefer things to live where they would actually be defined, and to treat the Compat spec like a clearing-house for things that need to be integrated into other specs.
tabatkins
on 18 Dec 2018
Veto.
eae
on 18 Dec 2018
Just in case anyone's confused (like I was) "eae" above isn't @eaenet (who I suspect would not oppose this).
frivoal
on 14 Jan 2019
What are the odds...
For the record, I am not opposed to this at all.
eaenet
on 14 Jan 2019
Related issues
castastrophe
路
3Comments
gsnedders
路
3Comments
SelenIT
路
3Comments
Meteor0id
路
3Comments
nigelmegitt
路
4Comments
Most helpful comment
As long as browsers need to support something in order to render the web, it's worthwhile to document them in standards. Whether the definition lives in Compat or Images doesn't make a huge difference, but in general I prefer things to live where they would actually be defined, and to treat the Compat spec like a clearing-house for things that need to be integrated into other specs.