- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 19 Sep 2019 06:07:02 +0000
- To: public-fxtf-archive@w3.org
The SVG Working Group just discussed `make the behavior of an invalid mask be consistent with clip-path and filter`, and agreed to the following: * `RESOLVED: For clipping and masking, we follow the behavior of Edge, WebKit, and Blink in the https://github.com/w3c/fxtf-drafts/issues/130#issuecomment-390981529 table` * `RESOLVED: If a referenced filter is missing or invalid, the side effects like stacking context are still preserved.` <details><summary>The full IRC log of that discussion</summary> <heycam> Topic: make the behavior of an invalid mask be consistent with clip-path and filter<br> <heycam> github: https://github.com/w3c/fxtf-drafts/issues/130<br> <heycam> krit: the issue is what happens if a filter, mask, clip-path is invalid<br> <heycam> ... for filters, what happens if there's no content<br> <heycam> krit: so if you have a rect, apply a clip-path, but the referenced <clipPath> has no children<br> <heycam> mstange: looking at the table in the issue, does one of the rows describe if you have a filter in an external SVG that's still loading?<br> <heycam> AmeliaBR: no, but good question<br> <heycam> mstange: I ran into this before CSS filters existed. I wanted to darken on mousedown. I only set the filter on :active, which is when the external resource started loading<br> <heycam> ... so it would become blank<br> <heycam> AmeliaBR: I was thinking of the basic case of when you're first loading. but in the interactive case, sometihng disappearing would be bad<br> <heycam> myles: we have a similar situation with async image decoding<br> <heycam> ... where if oyu're on the first load of a webpage, we will not show the image until it's fully decoded<br> <heycam> ... but if you're in the middle of a page, and you change the src, you won't show nothing until the new image is decoded. you show the old image until the new one is ready<br> <heycam> AmeliaBR: first we need to make the basic case of what do you do when you know the reference is invalid, either it's a bad URL, or there's an error in the content you're referencing<br> <heycam> ... we have different rules for different elements, and different implementations<br> <heycam> ... my general preference is to try to harmonize as much as possible<br> <heycam> krit: I can go through the clip path examples<br> <heycam> krit: [reads from the table]<br> <heycam> myles: the no content case, I remember implementing this<br> <heycam> ... there was an SVG 1.1 test suite test for this<br> <heycam> myles: our fonts implementation doesn't match Gecko, it matches others. [it skips invalid child content of the clipPath]<br> <heycam> krit: Firefox is the odd one out here mostly, would they be willing to change?<br> <heycam> mstange: there's cases are all handled explicitly, should be simple to change<br> <heycam> ... not sure on jwatt's or longsonr's opinion<br> <heycam> RESOLVED: For clipping and masking, we follow the behavior of Edge, WebKit, and Blink in the https://github.com/w3c/fxtf-drafts/issues/130#issuecomment-390981529 table<br> <heycam> AmeliaBR: what's different between filters and clip/mask, is missing references<br> <heycam> ... if you have a url() reference to a missing element, clip/mask just applies no clip/mask<br> <heycam> ... for filter, the filtered element disappears<br> <heycam> ... which is usually not helpful<br> <heycam> krit: not sure if I did change this, but I would like to align with mask and clip<br> <heycam> ... the Filters spec has a special rule, if the url() reference is to a different file, then you treat it as a no-op<br> <heycam> krit: [reads spec text]<br> <heycam> ... so we already have changed the spec to not make the filtered element disappear<br> <heycam> myles: putting a filter on an element causing a stacking context, so we can't treat it as 'filter:none'<br> <heycam> AmeliaBR: as a no-op filter item<br> <heycam> krit: so a stacking context still gets created<br> <heycam> AmeliaBR: if your filter is invalid, that would be something to clarify in the spec<br> <heycam> krit: didn't find anything about external references. think it should behave in the same way<br> <heycam> mstange: I would be in agreement. I suppose we don't know how much content it would break<br> <heycam> ... but from an authoring perspective, I much prefer this behavior<br> <heycam> myles: if an author was trying to get a filter, and make a typo, their element would disappear<br> <heycam> ... it's hard to believe that there's content out there that relies on it disappearing<br> <heycam> AmeliaBR: when the url() is to another filter, and you get a network error<br> <heycam> ... the other issue is just debugging SVG filters is a pain, if your content keeps disappearing<br> <heycam> ... and the inconsistency with clipping/masking<br> <heycam> mstange: these are arguments for it being a pass through, not for there being no broken content<br> <heycam> myles: inside a filter you create a graph of nodes. do they also need this analysis performed on them?<br> <heycam> mstange: if you have in="" that refers to something non-existent<br> <heycam> AmeliaBR: each primitive has its own rules<br> <heycam> krit: if the filter reference is invalid, the filter is not applied, but the stacking context is still created<br> <heycam> heycam: you might have a filter property with multiple filters in it<br> <heycam> AmeliaBR: this would make the entire filter chain a no-op<br> <heycam> RESOLVED: If a referenced filter is missing or invalid, the side effects like stacking context are still preserved.<br> <AmeliaBR> Resolution was at https://github.com/w3c/svgwg/issues/631#issuecomment-505164786<br> <AmeliaBR> and at https://github.com/w3c/svgwg/issues/537#issuecomment-452092266<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/130#issuecomment-532981392 using your GitHub account
Received on Thursday, 19 September 2019 06:07:04 UTC