Re: Scope and range of styles

On Thu, Sep 25, 2014 at 12:04 PM, Juergen Roethig
<roethig@dhbw-karlsruhe.de> wrote:
> Robert Longson wrote:
>>>
>>> That's what I was talking about: In a similar way as you may reference an
>>> external stylesheet in an HTML file (via the <link> tag), you may reference
>>> the very same external stylesheet in an SVG document (not via a <link> tag
>>> which does not exist in SVG, but via a <?xml-stylesheet ?> declaration, as
>>> the usual way for XML files to reference CSS files). Your assumption "[...]
>>> the SVG must then be complete in a single file" is simply wrong - your SVG
>>> file may reference CSS files as well as
>>
>>
>> No my assumption is right, otherwise you have a privacy leak.
>> https://bugzilla.mozilla.org/show_bug.cgi?id=628747 contains a detailed
>> discussion of this issue.
>>
>>> JavaScript files, it may even be generated by another (non-SVG) XML file
>>> which references an XSLT file which might again reference other files ...
>>
>>
>> javascript isn't allowed in svg-as-an-image either. You'll find all
>> existing UAs enforce these rules.
>
>
> So, some existing UAs do it like that (obviously even differently, some
> allow parts, some disallow all), but there is not any statement in SVG 1.1
> (that's the very same specification you were referring to) saying what it
> must be like in that case! I tend to argue that in such a case the browser
> incompletely implements SVG 1.1. If this incompleteness (to not allow
> whatever external resources in SVG files loaded via <img>) is a real must,
> this might result in a statement in future standards (SVG 2.0 or whatever),
> or in the relevant HTML5 "standard" giving such restrictions to SVG files
> which are included via <img>. But why should SVG 1.1 be amended with such a
> statement? SVG 1.1 is a standard since 2003, second edition since 2011, and
> just because that, we should have a third edition?
>
> Once again: I do not see the need to modify the existing standard SVG 1.1
> (that's the one you were explicitly referring to) to reflect a restriction
> which is obviously an individual browser implementation restriction. In the
> same way, we should not remove some filters from SVG 1.1 just because some
> browser vendors were not able to implement them up to now.

Regardless of whether or not SVG1.1 is changed, the SVG Integration
spec <https://svgwg.org/specs/integration/> covers the topic here.
This is not a matter of "some browsers failing to do something", but
all the browsers purposely making an unspecified behavior change, and
the spec finally catching up to them.

~TJ

Received on Thursday, 25 September 2014 19:15:21 UTC