- From: Nikolas Zimmermann <zimmermann@physik.rwth-aachen.de>
- Date: Wed, 28 Jul 2010 13:22:52 +0200
- To: Erik Dahlstrom <ed@opera.com>
- Cc: www-svg@w3.org
Am 15.07.2010 um 12:40 schrieb Erik Dahlstrom: > On Thu, 15 Jul 2010 11:39:24 +0200, Nikolas Zimmermann <zimmermann@physik.rwth-aachen.de > > wrote: > >> Good morning SVG crowd, >> >> I'd like to discuss clipping inconsistencies between Opera/FF and >> WebKit, when it comes to error handling. >> In the screenshot you can see WebKit, Firefox and Opera rendering the >> clip-path-recursive-call-by-child.svg example (attached in this >> mail). > ... >> I've chosen to ignore the clipPath, which is in error state (as it >> contains a cycle), but still render the object, which referenced it. >> >> Firefox seems to detect the cycle and doesn't render the element at >> all (probably because of the note in the error processing document). >> Opera just ignores the cycle and renders both elements. > > No, what Opera does is detect the cycle and break it at the time > it's discovered, and we've chosen to follow the spec for what > happens if there's an invalid clip-path IRI reference in a child > element of a clipPath element: > [[ If the IRI reference is not valid (e.g it points to an object > that doesn't exist or the object is not a ‘clipPath’ element) the > ‘clip-path’ property must be treated as if it hadn't been > specified. ]] > > Which means that the rect inside the clipPath should be drawn (or in > other words: it should contribute to the clipping region), but > without the 'clip-path' property applied. > > Note that there's nothing in the spec that says that the 'clip-path' > IRI reference means the element in question is "in error", so the > error processing rules don't apply in this case. Ok, I made up my mind, and I think it's a fine solution to handle these edge cases. WebKit/SVG will follow the same route, as soon as the patch lands :-) Cheers, Niko
Received on Wednesday, 28 July 2010 11:23:22 UTC