Note the rects in the test are to indicate the filter effect region, to ensure it is correctly set for orientation. This knocks off one privacy issue.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Apply EXIF orientation data in SVG feImage filtersUsage of this is fairly low (https://chromestatus.com/metrics/feature/timeline/popularity/5757), so this is very likely to be web compatible, as only a small percentage of the small number of feImages will have EXIF data.
How do Safari and Firefox handle this? If we are diverging from their behavior, can you file a spec issue for this?
// with different CSS properties. The filter appearannce might then varynit: appearannce -> appearance
<link rel="help" href="https://drafts.fxtf.org/filter-effects/#feImageElement">This link is 404. Maybe https://drafts.csswg.org/filter-effects/#feImageElement?
<rect x="10" y="10" width="100" height="100" filter="url(#f1)"/>nit: indentation
<link rel="help" href="https://drafts.fxtf.org/filter-effects/#feImageElement">update this (or remove it, as it's just a reference)
<rect x="10" y="10" width="100" height="100" filter="url(#f1)"/>nit: indentation
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Apply EXIF orientation data in SVG feImage filtersUsage of this is fairly low (https://chromestatus.com/metrics/feature/timeline/popularity/5757), so this is very likely to be web compatible, as only a small percentage of the small number of feImages will have EXIF data.
How do Safari and Firefox handle this? If we are diverging from their behavior, can you file a spec issue for this?
Ah, I now see https://github.com/w3c/svgwg/issues/819#issuecomment-4565532924. Can we wait for this to resolve before landing this?