Re: [parameters] Outline for recasting SVG Parameters on top of CSS Variables

(comments follow)

On 2 November 2014 05:29, Robert Longson <longsonr@gmail.com> wrote:

> Given that this allows an image to be completely changed I suspect we
> wouldn't be willing to implement this feature to modify SVG-as-an-image
> i.e. via the image tag or backgound images. Using it via the object or
> iframe tags would be OK though.
>
> If it gives you the ability to do something that a gif or png doesn't
> allow then it breaks people's mental model of images. E.g. if you host a
> bulletin board and you vet image uploads somehow as safe then you should
> not be able to get around that by removing some part of the image to reveal
> a completely different image.
>
> Robert.
>

You can already do things with SVG-as-image that you can't with GIF or PNG,
by using target fragments and :target styles, or by using CSS media queries
(in an internal style element) to hide or show parts of the content at
different scales.  Either of these could conceivably be used to create an
image that looks very different in use from what it looks like viewed on
its own.

It's true that Chrome/Webkit do not supporting target fragments on CSS
images (although Chrome at least supports it in <img> sources).  I have
heard it described as a security issue, but I was never clear about that
because targets are applied client-side so there isn't anything
CORS-related about it. I hadn't thought about it from the perspective of
image vetting being a security issue.  I'd assumed it was a performance
decision -- only wanting to render the image once per file.

Nonetheless, if other implementers agree that image styles should always be
self-contained, then that would avoid the complications of having to decide
on a practical scheme to specify client-side parameters via a URL (which I
think is currently the stickiest part of the proposal).  Instead, a scheme
using <param> could be set up for <object> and normal CSS inheritance would
suffice for inline content.

ABR