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.3.1 : Tuesday, 20 November 2018 00:45:58 UTC