W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > May 2017

Re: [fxtf-drafts] [css-masking] Define "raw geometry" for `<clipPath>` clipping

From: Fredrik Söderqvist via GitHub <sysbot+gh@w3.org>
Date: Thu, 25 May 2017 20:33:08 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issue_comment.created-304116286-1495744386-sysbot+gh@w3.org>
That's indeed one way to frame it - and this pretty much how Blink (and IIRC, WebKit) handles this in the general case (modulo other details, as @AmeliaBR mentions.) It really boils down to engine architecture and requirements on that based on the rendering architecture/pipeline. (In Presto we handled this in a similar, but not exactly the same way, for instance.)
I believe the "Raw geometry" formulation (and whatever it used to say, ISTR it was slightly different) - as well as the limited content model - was there to allow an implementation to just "collect" a list of geometric primitives based on the element types, and construct the clip path from that. (Engines commonly do that for their fast-paths, and that in itself tends to be slippery slope because of all the cases you need to consider even then...)
With the history lesson out of the way, I wonder which way would be the easiest to specify this: Properties to ignore and properties to replace (like using `clip-rule` instead of `fill-rule`) - **or** - properties that do apply (and properties to replace...) Or some other way. `<text>` indeed seems to be the big trouble maker here (lots of properties that could be considered to be affecting the "geometry".)

GitHub Notification of comment by fsoder
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/170#issuecomment-304116286 using your GitHub account
Received on Thursday, 25 May 2017 20:33:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:21 UTC