- 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
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