Re: Ambiguities in fill:url() / stroke:url() syntax

On Sun, Oct 28, 2012 at 12:08 PM, Robert O'Callahan
<robert@ocallahan.org> wrote:
> On Sun, Oct 28, 2012 at 11:33 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>> On Sun, Oct 28, 2012 at 11:20 AM, Robert O'Callahan
>> <robert@ocallahan.org> wrote:
>> > On Sun, Oct 28, 2012 at 11:04 PM, Tab Atkins Jr. <jackalmage@gmail.com>
>> > wrote:
>> >> I don't have any better ideas besides "just do everything right".
>> >
>> > What does that mean?
>>
>> It means ::handwave:: and just magically work correctly depending on
>> whether you're linking to a paint source or not.
>
>
> Still not a very satisfying answer. :-)
>
> The issue is especially complicated because I think the way you load the
> document --- whether as an external resource document, or as an image ---
> could affect whether you're linking to a paint server or not; if not now,
> then in the future as Web standards evolve. For example, we currently
> restrict subresource URIs in SVG documents to URIs that don't load other
> resources --- i.e., data: and blob: (for security reasons). But we don't
> restrict subresource URIs in external resource documents that way. So if
> there was ever a situation where the success or failure of a subresource
> load in foo.svg could affect the type of element referenced by foo.svg#abc,
> you could construct a document foo.svg where what foo.svg#abc refers to
> depends on whether you loaded it as an external resource document or an
> image. Now I can't actually think of a way this could happen today, but I
> can think of lots of "near misses" --- for example, if we allowed scripting
> in either external resource documents or SVG images, or if we allowed Web
> Components in either, or if we had a transclusion feature that let you load
> content directly into a document, or if we allowed dynamic loading of DTDs.
>
> Additional complications arise if what is referenced by foo.svg#abc can
> change over time, e.g. while foo.svg loads, or if <meta refresh> is allowed
> in SVG images or external resource documents, or if the "id" attribute can
> be animated in any way, or you're able to dynamically modify the DOM of an
> external resource document or an SVG image document in any way. Then we
> could get into situations where UA is "linking to a paint source" so
> treating the URI as an external resource reference, then suddenly it isn't.
> Or vice versa. We have to reload the document in a different way? Or
> something.

Very good points.  I wasn't thinking about dynamic changes.

In that case, as long as we're *able* to head off SVG Stacks at the
pass, I'm cool with your alternate approach, suitably expanded to
disallow all things that *look* like MFs in step a (that is,
everything with an ident followed by an = sign).

> By the way, if someone created an document foo.svg with a paint server
> element whose ID is "xywh=0,0,10,10", how would your magical approach treat
> url(foo.svg#xywh=0,0,10,10)? :-)

I think SVG agreed recently (dunno if it's made it into the SVG2
draft) that we'll restrict the syntax of fragment identifiers to
disallow all MF-looking things from referring to elements.

~TJ

Received on Sunday, 28 October 2012 13:41:36 UTC