- From: Rik Cabanier <cabanier@gmail.com>
- Date: Mon, 3 Nov 2014 10:04:30 -0800
- To: Paul LeBeau <paul.lebeau@gmail.com>
- Cc: Dirk Schulze <dschulze@adobe.com>, FX <public-fx@w3.org>
- Message-ID: <CAGN7qDCfNmJzpt+ApD+UzQ_=JZtLBCAXbp3xyJg32csMc1=TMw@mail.gmail.com>
On Mon, Nov 3, 2014 at 9:38 AM, Paul LeBeau <paul.lebeau@gmail.com> wrote: > The Error Processing section of the SVG spec says: "The document shall be > rendered up to, but not including, the first element which has an error." > > Would not a bad input, such as a bad URL reference be counted as an > error? If so, processing should(?) stop at the filter primitive before the > <feImage>. Which to me sounds exactly like option 3. > If we define that a missing image is allowed, it wouldn't be an error any more :-) Moving forward I believe we should make things more permissive. > On 4 November 2014 06:25, Rik Cabanier <cabanier@gmail.com> wrote: > >> >> >> On Mon, Nov 3, 2014 at 6:14 AM, Dirk Schulze <dschulze@adobe.com> wrote: >> >>> Hi, >>> >>> I checked the behavior of different SVG viewers on <feImage>[1] with a >>> missing image resource. It appears that we have three behavior categories >>> across 7 different SVG viewers (6 if you still count WebKit and Blink as >>> one). Tested: Safari, Chrome, IE, Firefox, Opera (presto), Illustrator, >>> InkScape (no result), Batik. >>> >>> All viewers apply an SVG filter on content even if <feImage> has a >>> missing resource. Other then that, viewers either: >>> >>> 1) treat <feImage> as a transparent black image taking all primitive >>> regions into account, >>> 2) replace the missing image with a “missing image” icon and take all >>> primitive regions into account or >>> 3) treat <feImage> and all successor color manipulating primitives as >>> null filter. >>> >>> Example: https://www.w3.org/Bugs/Public/attachment.cgi?id=1531 >>> Description: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27221#c0 >>> >>> Option 1) looks reasonable for me and is easy to implement/specify. >>> Option 2) looks strange but at least gives authors feedback of what is >>> going on. I am unsure how to specify 3) and how it actually is implemented. >>> Maybe someone from Mozilla could clarify. >>> >> >> I agree that 1) is the most reasonable option. >> Can you break out which browser does what option? >> > >
Received on Monday, 3 November 2014 18:05:01 UTC