Open annevk opened 5 years ago
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?
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!
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.
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.
Veto.
Just in case anyone's confused (like I was) "eae" above isn't @eaenet (who I suspect would not oppose this).
What are the odds...
For the record, I am not opposed to this at all.
@tabatkins so is it still clear what exactly to document for the -webkit-
gradients, and would that go in Appendix A: Deprecated Features and Aliases or directly into 3. Gradients (likely as a new 3.6 Deprecated prefixed gradients)?
@tabatkins oh I assigned you because you added 'needs edits' and argued for having this defined in Images 4, and not in Compatibility.
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.