The JavaScript element.style.clipPath is present (returns "" instead of undefined), indicating a prefix is NOT needed. However, if you apply a clipPath (without the -webkit- prefix), it doesn't work! Here's a reduced test case: https://codepen.io/GreenSock/pen/4ec363d7fca960b501b390634fdf2e39?editors=0010 For a non-valid property (like element.style.bogus), undefined is returned (correct). So this clipPath behavior is very confusing (and I'd say clearly a bug). The element.style.clipPath test is passing, but functionality fails. It should either be fully functional in unprefixed form, or element.style.clipPath should return undefined. Possibly a related thread: https://bugs.webkit.org/show_bug.cgi?id=187888
<rdar://problem/49764514>
clip-path is present in computed style because it's present for SVG in the non-prefixed form.
This seems like non-standard behavior. My demo isn't using an SVG element. Shouldn't it be returning undefined (indicating it's not supported on that element)? Of course ideally it would actually just work unprefixed.
We did not unprefix clip-path yet (though there is a patch for doing so). Sadly that means that both properties behave like 2 different properties as long as we did not unprefix (and alias the prefixed version) of Clip-path.
(In reply to Dirk Schulze from comment #4) > We did not unprefix clip-path yet (though there is a patch for doing so). > Sadly that means that both properties behave like 2 different properties as > long as we did not unprefix (and alias the prefixed version) of Clip-path. Forgot the background: clip-path was introduced by and for SVG. -WebKit-Clip-path for HTML first. So those properties currently ARE 2 different properties. When unprefixing we plan to make them one. Foundation is there already. You should be able to find the bug that is duplicated by this bug by searching for clip-path.