Intent to Ship: Unprefixed CSS Clipping Paths
57 views
Skip to first unread message
Fredrik Söderquist
Sep 6, 2016, 7:33:41 AM9/6/16
to blink-dev
f...@opera.com
https://drafts.fxtf.org/css-masking-1/
The CSS Clipping Path (CSS Masking specification) property without the "webkit" prefix.
This property (with and without prefix) has been around for a while - initially for SVG content, and later on also applying to HTML. Like many properties that started out in SVG and was later generalized, it's had some weird quirks around what is supported where and how. (Example: both 'clip-path' and '-webkit-clip-path' was supported on SVG content, but supported different types of clips; 'clip-path' was not supported on HTML, but naturally 'clipPath' was still exposed as a property on CSSStyleDeclaration.)
Firefox: In development (Supports <url> but not <basic-shape>. The latter is behind a flag.)
Edge: Public support ("Under consideration")
Safari: In development (Still prefixed)
Web developers: Positive
For <basic-shape> clips (Gecko's experimental impl. included) the interop is fairly decent. Blink does not currently implement the <geometry-box> part of the property, which would be the largest point of deviation for <basic-shape>. For <url> referenced clipping paths, the basic support is pretty good (probably because of the SVG lineage) but there could be issues with some implementation for <clipPath>s with clipPathUnits=userSpaceOnUse, with regards to the position of the clipping path. Across the board there are also issues around fragmentation.
Expected to be low. Because of the mixed support-chart there could be cases where 'clip-path' will now override '-webkit-clip-path' and cause failures. (Example: External URL references and data: URLs.)
Philip Jägenstedt
Sep 6, 2016, 10:34:45 AM9/6/16
to Fredrik Söderquist, blink-dev
Questions :)
As you mentioned, clipPath is already exposed via CSSOM, and it looks like clip-path does parse and show up as element.style.clipPath for HTML elements, so is it about hooking things up internally to actually work?
In general I think we should be more accepting of imperfection when unprefixing things, since both the prefixed and unprefixed should be aliases and change together. Still, if this were a launch of an entirely new feature, do you think any of the mentioned issues, like perhaps <geometry-box>, would be things to fix before shipping? Just checking if there are any relatively easy fixes that could do anything to reduce interop risk.
Fredrik Söderquist
Sep 6, 2016, 10:47:31 AM9/6/16
to Philip Jägenstedt, blink-dev
On Tue, Sep 6, 2016 at 4:34 PM, Philip Jägenstedt <foo...@chromium.org> wrote:
Questions :)As you mentioned, clipPath is already exposed via CSSOM, and it looks like clip-path does parse and show up as element.style.clipPath for HTML elements, so is it about hooking things up internally to actually work?
Currently '-webkit-clip-path' and 'clip-path' parse differently (somewhat simplified: "none | url(...) | <basic-shape>" vs. "none | url(...)"), so that's one aspect of the above. The other (related) is things like crbug.com/512502.
In general I think we should be more accepting of imperfection when unprefixing things, since both the prefixed and unprefixed should be aliases and change together. Still, if this were a launch of an entirely new feature, do you think any of the mentioned issues, like perhaps <geometry-box>, would be things to fix before shipping? Just checking if there are any relatively easy fixes that could do anything to reduce interop risk.
I haven't seen any interest (read: bugs/feature requests) in/for that particular "sub-feature", so I figured it could wait. I don't see any major implementation difficulties with it though.
/fs
On Tue, Sep 6, 2016 at 1:33 PM Fredrik Söderquist <f...@opera.com> wrote:f...@opera.com https://drafts.fxtf.org/css-masking-1/ The CSS Clipping Path (CSS Masking specification) property without the "webkit" prefix.This property (with and without prefix) has been around for a while - initially for SVG content, and later on also applying to HTML. Like many properties that started out in SVG and was later generalized, it's had some weird quirks around what is supported where and how. (Example: both 'clip-path' and '-webkit-clip-path' was supported on SVG content, but supported different types of clips; 'clip-path' was not supported on HTML, but naturally 'clipPath' was still exposed as a property on CSSStyleDeclaration.) Firefox: In development (Supports <url> but not <basic-shape>. The latter is behind a flag.) Edge: Public support ("Under consideration") Safari: In development (Still prefixed) Web developers: PositiveFor <basic-shape> clips (Gecko's experimental impl. included) the interop is fairly decent. Blink does not currently implement the <geometry-box> part of the property, which would be the largest point of deviation for <basic-shape>. For <url> referenced clipping paths, the basic support is pretty good (probably because of the SVG lineage) but there could be issues with some implementation for <clipPath>s with clipPathUnits=userSpaceOnUse, with regards to the position of the clipping path. Across the board there are also issues around fragmentation.Expected to be low. Because of the mixed support-chart there could be cases where 'clip-path' will now override '-webkit-clip-path' and cause failures. (Example: External URL references and data: URLs.)
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Philip Jägenstedt
Sep 6, 2016, 3:09:19 PM9/6/16
to Fredrik Söderquist, blink-dev
On Tue, Sep 6, 2016 at 4:47 PM Fredrik Söderquist <f...@opera.com> wrote:
On Tue, Sep 6, 2016 at 4:34 PM, Philip Jägenstedt <foo...@chromium.org> wrote:Questions :)As you mentioned, clipPath is already exposed via CSSOM, and it looks like clip-path does parse and show up as element.style.clipPath for HTML elements, so is it about hooking things up internally to actually work?Currently '-webkit-clip-path' and 'clip-path' parse differently (somewhat simplified: "none | url(...) | <basic-shape>" vs. "none | url(...)"), so that's one aspect of the above. The other (related) is things like crbug.com/512502.
I guess the parsing will be unified and the properties will be made aliases in CSSProperties.in?
In general I think we should be more accepting of imperfection when unprefixing things, since both the prefixed and unprefixed should be aliases and change together. Still, if this were a launch of an entirely new feature, do you think any of the mentioned issues, like perhaps <geometry-box>, would be things to fix before shipping? Just checking if there are any relatively easy fixes that could do anything to reduce interop risk.I haven't seen any interest (read: bugs/feature requests) in/for that particular "sub-feature", so I figured it could wait. I don't see any major implementation difficulties with it though.
Makes sense, as long as support can be reliably tested with CSS.supports() if eventually implemented.
LGTM1
Fredrik Söderquist
Sep 6, 2016, 3:38:22 PM9/6/16
to Philip Jägenstedt, blink-dev
On Tue, Sep 6, 2016 at 9:09 PM, Philip Jägenstedt <foo...@chromium.org> wrote:
On Tue, Sep 6, 2016 at 4:47 PM Fredrik Söderquist <f...@opera.com> wrote:On Tue, Sep 6, 2016 at 4:34 PM, Philip Jägenstedt <foo...@chromium.org> wrote:Questions :)As you mentioned, clipPath is already exposed via CSSOM, and it looks like clip-path does parse and show up as element.style.clipPath for HTML elements, so is it about hooking things up internally to actually work?Currently '-webkit-clip-path' and 'clip-path' parse differently (somewhat simplified: "none | url(...) | <basic-shape>" vs. "none | url(...)"), so that's one aspect of the above. The other (related) is things like crbug.com/512502.I guess the parsing will be unified and the properties will be made aliases in CSSProperties.in?
Correct.
In general I think we should be more accepting of imperfection when unprefixing things, since both the prefixed and unprefixed should be aliases and change together. Still, if this were a launch of an entirely new feature, do you think any of the mentioned issues, like perhaps <geometry-box>, would be things to fix before shipping? Just checking if there are any relatively easy fixes that could do anything to reduce interop risk.I haven't seen any interest (read: bugs/feature requests) in/for that particular "sub-feature", so I figured it could wait. I don't see any major implementation difficulties with it though.Makes sense, as long as support can be reliably tested with CSS.supports() if eventually implemented.
That ought to work, but I'll make sure to test it out.
/fs
Rick Byers
Sep 8, 2016, 10:22:03 AM9/8/16
to Fredrik Söderquist, Philip Jägenstedt, blink-dev
LGTM2
Dimitri Glazkov
Sep 8, 2016, 11:35:15 AM9/8/16
to Rick Byers, Fredrik Söderquist, Philip Jägenstedt, blink-dev
LGTM3
Reply all
Reply to author
Forward
0 new messages