On Tue, 05 May 2015 13:58:03 +0200, Philip Jägenstedt <
phi...@opera.com>
wrote:
> This intent already has 3 LGTMs, but before proceeding to implement it
> would be nice to see Anne's concerns addressed.
Technically the implementation is in codereview already, but fair enough.
> Taking a step back, external <use> seems like a rather strange thing in
> general, cross-origin or not.
On basis of what web developers seem to think is natural I'd disagree that
it's strange. External <use> has been a part of SVG since version 1.0 of
the spec, and I do think that was a deliberate choice to allow urls rather
than just id values.
> I am pretty far removed from SVG, so do the
> people who work most in core/svg/ (including ed) think the complexity of
> this feature is worth it?
I'd like to hear what others think here, since it seems that external
<use> is for the most part already implemented and shipped. This intent
doesn't really add much complexity on top of that.
> Could external <use> come in the way of any
> future (but plausible) simplification of <use>?
That's a pretty open question. What (plausible) simplifications did you
have in mind?
> Philip
>
> On Thu, Apr 30, 2015 at 10:11 AM, Anne van Kesteren <
ann...@annevk.nl>
> wrote:
>
>> On Wed, Apr 29, 2015 at 10:21 AM, Erik Dahlström <
e...@opera.com> wrote:
>> > This change enables CORS in svg, and adds 'crossorigin' attributes,
>> > following the same pattern as in html. For <use> elements the default
>> is
>> "No
>> > CORS", meaning that both client and server needs to opt in for the
>> > crossorigin fetch to succeed.
>>
>> This doesn't make sense. What do you mean? From below it sounds like
>> you mean that the default mode for <use> is "same-origin", and that
>> you want to allow "cors".
That is indeed what I meant.
>> > For the <script> and <image> elements the
>> > default is to allow crossorigin fetches since content would otherwise
>> break,
>> > however, it's possible to control the information transmitted with the
>> > request by using the 'crossorigin' attribute.
>>
>> This also doesn't make sense.
Please be more specific.
The intent is to share behavior with how the 'crossorigin' attribute
applies to the corresponding html elements, script and img respectively.
The code is effectively already shared internally.
>> > The patch will not really change anything for <image> and <script>,
>> apart
>> > from exposing the 'crossorigin' attribute on the corresponding IDL
>> > interfaces.
>>
>> That seems bad. For <script> the feature that crossorigin provides is
>> better error handling.
Ok, and that's a bad thing for <svg:script> how exactly?
>> For <image> the feature it provides would be
>> reading the image data through <canvas>, though I'm not sure you can
>> draw an <image> at the moment.
I'm not sure why exposing an attribute that is already used internally
when fetching does any harm.
>> > There's general agreement in the SVG WG that svg should use CORS.
>> Mozilla
>> > expressed some concerns over CORS in <use> (since gecko shares
>> resource
>> > documents), but indicated that those concerns could hopefully be
>> worked
>> out
>> > in SVG2.
>>
>> It seems bad to me that SVG's processing model with regards to
>> fetching and security is still not defined in detail. At some point I
>> made an attempt with Dirk at defining the basic building blocks, but I
>> don't think much came of it:
>>
>>
https://etherpad.mozilla.org/fixing-svg-processing
That document looks a little out of date, a number of these elements have
already been dropped from the svg2 spec. And I don't know what the
document tested, since there are no links to any tests, just claims about
what browsers did at some point in time.
I'd agree that clearly defined processing models for <anything> is a
generally good thing. How detailed such a model would need to be for svg I
think is up to the WG to decide, with your input ideally. That discussion
seems more suited for
www...@w3.org though.
Cheers