New issue
Advanced search Search tips

Issue 109212 link

Starred by 88 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: 2017-05-15
OS: All
Pri: 2
Type: Feature

Blocked on:
issue 769774

Blocking:
issue 729599
issue 751733


Show other hotlists

Hotlists containing this issue:
Top-Starred-Bugs


Sign in to add a comment

SVG (filter | fill | stroke | clip-path | mask | marker-*) from external files not applied

Project Member Reported by cos...@gmail.com, Jan 5 2012

Issue description

Chrome Version       : 18.0.996.0
OS Version: OS X 10.7.2
URLs (if applicable) : http://visual-effects-in-modern-browsers.googlecode.com/hg/SVG%20filter%20for%20HTML%20(external).html
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: FAIL
  Firefox 4.x: FAIL
  Firefox 11.x: PASS
     IE 7/8/9: 

What steps will reproduce the problem?
1. Define a filter in an SVG file, assign it an ID.
2. Embed some SVG in an HTML file.
3. Use the CSS directive "filter: url(file#id)" to reference the filter in the SVG file.

What is the expected result?
The filter should be applied.

What happens instead?
No filter is applied.

Please provide any additional information below. Attach a screenshot if
possible.

The page below seems to have a reasonably reduced test case. I'll be happy to make another one if it helps.
http://visual-effects-in-modern-browsers.googlecode.com/hg/SVG%20filter%20for%20HTML%20(external).html

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.15 (KHTML, like Gecko) Chrome/18.0.996.0 Safari/535.15

 

Comment 1 by tkent@chromium.org, Jan 5 2012

Labels: -Area-Undefined Area-WebKit WebKit-SVG

Comment 2 by kareng@google.com, Jan 24 2012

mike these look like CSS please unassign urself if they are not.

Comment 3 by kareng@google.com, Jan 24 2012

Owner: mikelawther@chromium.org
Status: Assigned
mike these look like css, please unassign urself if they are not.
I have been hoping for a fix to this for a long time.  FireFox gets this right, and has for quite a few releases now, whereas Chrome does not.

The following JS code executes fine inside FireFox (where "path" is an SVG element reference) and I apply a filter attribute that references a reusable effect stored in a "Resources.svg" file that is external to the SVG in which my code is executing...

   path.setAttributeNS(null, 'filter',    'url(Resources.svg#Effect_3D)');   

That renders the filter in FF as I'd expect.
But, in order to get this to work in Chrome, I need to include that defined-filter within the same SVG file as the JS code, and use the following code instead (note the lack of external file reference):

   path.setAttributeNS(null, 'filter',    'url(#Effect_3D)');

This bug GREATLY LIMITS RE-USE of SVG filter-definitions. Looking forward to a fix. Thanks.
An application outside of filters would also be quite useful:
https://developer.mozilla.org/En/Applying_SVG_effects_to_HTML_content#Using_external_references
Project Member

Comment 6 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-WebKit -WebKit-SVG Cr-Content-SVG Cr-Content
Can we get a link to the webkit bug?
I am not 100% sure, but is this not the Webkit bug?
https://bugs.webkit.org/show_bug.cgi?id=105904

Sure looks like it.  

Additionally, this webkit bug alludes to the same thing I believe:
https://bugs.webkit.org/show_bug.cgi?id=104169
Project Member

Comment 9 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 10 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content-SVG Cr-Blink-SVG

Comment 11 by Deleted ...@, Oct 7 2013

the same thing with clip-path reference to external file

Comment 12 by e...@opera.com, Dec 9 2013

Summary: SVG (filter | fill | stroke | clip-path | mask) from external files not applied (was: SVG filters from external files not applied)

Comment 13 by coini...@gmail.com, Sep 18 2014

so far, seems Firefox is the only one browser which can handle this correctly.
IE 11 also failed.
I have another testcase:
http://denilsonsa.github.io/html5-knob/bugs.html#bug-use-external-svg
https://github.com/denilsonsa/html5-knob/commit/e1cc3518f95f8f6d23e7fcd7c6bdbdf35b5c5f4b
I'm also attaching the files here. If you download them, you may need to use a local web server (such as "python3 -m http.server") due to same-domain restrictions.

My objective was to get the SVG from https://openclipart.org/detail/172010/driving-wheel and embed it inside my SVG code. I was extremely surprised when Chrome rendered absolutely nothing from the clipart. Then I studied the issue and wrote a minimal testcase.
bugs.html
18.2 KB View Download
drivingwheel.svg
27.4 KB Download
screenshot-chrome-and-firefox.png
72.8 KB View Download
bugs-external-file.svg
692 bytes Download
Labels: Hotlist-Recharge
This issue likely requires triage.  The current issue owner maybe inactive (i.e. hasn't fixed an issue in the last 30 days).  Thanks for helping out!

-Anthony

Comment 16 by f...@opera.com, Sep 28 2015

Labels: -OS-Mac -Cr-Blink OS-All
Summary: SVG (filter | fill | stroke | clip-path | mask | marker-*) from external files not applied (was: SVG (filter | fill | stroke | clip-path | mask) from external files not applied)

Comment 17 by f...@opera.com, Sep 28 2015

 Issue 536039  has been merged into this issue.
Since my issue got merged here (I guess I should have search better) I am confirming that this still only works in firefox. 

It would be nifty to have this working as it would provide the easiest way around the issue angularJS SPAs have with SVG filter/markers/.. urls()

Comment 19 by myfonj@gmail.com, Oct 1 2015

WebKit bug has been asked for; stumbled upon this couple not mentioned here yet:

https://bugs.webkit.org/show_bug.cgi?id=63283
"URL references are completely broken in SVG"
by Boris Zbarsky. "FIXED" in 2011 despite failing tests (?) has a "NEW" followup:

https://bugs.webkit.org/show_bug.cgi?id=65344
"Make external URL references work"
Stalled since 2012 despite Lea Verou's personal intervention.
Cc: pdr@chromium.org f...@opera.com
Labels: -Hotlist-Recharge
Owner: f...@opera.com
fs@, assigning to you to give advice on whether this should be considered a real bug or a feature request, and if the latter, what the priority should be.

Comment 21 by f...@opera.com, Oct 7 2015

Labels: -Type-Bug Type-Feature
I think I'll have to go with "feature request" - it's not a very well-defined part of the spec, although I think that most/all the common use cases require needn't much more than what's in the spec (see SVG2 notes on <use> for some of the issues.)
As for priority, I'm not quite sure how those map for feature requests, but leaving it at 2 doesn't seem too bad, but depending on the mapping it could probably be a 1 as well.

Comment 22 by myfonj@gmail.com, Oct 7 2015

Ad "Not well defined part of the spec": Where exactly you found ambiguity in `<funciri>` definition, so that it could stand for "possible to reference local fragment, but not external one"? (Are you referring to http://www.w3.org/TR/SVG2/struct.html#UseElement ?)


I looked at definitions in SVG1.1 specs and cannot see any haziness there:

'(…) An IRI which includes an IRI fragment identifier consists of an optional base IRI, followed by a "#" character, followed by the IRI fragment identifier. (…)'
^ http://www.w3.org/TR/SVG11/linking.html#IRIReference

'<FuncIRI> = Functional notation for an IRI: "url(" <IRI> ")".'
^ http://www.w3.org/TR/SVG11/types.html#DataTypeFuncIRI

And for example `marker-start` property value definition:
'Value: none | <funciri> | inherit'
^ http://www.w3.org/TR/SVG11/painting.html#MarkerStartProperty

Comment 23 by f...@opera.com, Oct 7 2015

The SVG2 section I was referring to is the one starting with "The element referenced by ‘use’ may be in a separate document." in https://svgwg.org/svg2-draft/struct.html#UseElement
The actual url(...) reference is a very small piece seen from an implementation perspective.
I'll also like to reiterate what I wrote above about how these "edge cases" may not have any greater (if any) impact for, at least the most common, use cases that exist.
The current behaviour is inconsistent as it behaves as expected when the base IRI points to the current IRI of the page and fails otherwise. 


Comment 25 by f...@opera.com, Oct 7 2015

c#24 are you referring to something like  issue 470608 ?
Yes, that is initially how I ran into this problem. 

In the presence of a base tag on the page, using only the IRI fragment id no longer works forcing you to specify the IRI base. However the base IRI will only work if it matches the current location and not if it is another resource. Firefox does not have this issue (have not tested in IE). I also have a recollection of this working in Opera back when it used Presto but I could be wrong. 

For anyone writing an angularJS app, or any SPA that treats the URL as the source of truth on the page, it forces the developer to perform acrobatics to get these SVG attributes to work and it ties their hands from being able to refactor out their dependencies. 




Comment 27 by f...@opera.com, Oct 7 2015

I'm a bit surprised that Firefox/Gecko does not have - I'd rather expected the opposite... As for Presto I believe your recollection is correct, although in earnest that was more likely because of "legacy reasons" (i.e when implementing the HTML parsing algorithm w/ inline SVG the URL resolver was not updated. Or something like that.)

The latest word on this issue seems to be:

http://www.w3.org/Graphics/SVG/WG/track/actions/3816

but let's try to keep this discussion in  issue 470608 .
But this issue goes beyond the base tag problem. That is just one case where the issue presents itself.

Say a developer defines a bunch of reusable elements in a <defs> block. To support blink browsers, they now have to include that block on every page where they expect to their defs elements rather than being able to have a single dependancies.svg resource. 

Regardless of developer woes, the SVG1.1 spec is quite clear in how IRIs should be handled.  Quoting verbatim from the spec's example of a possible IRI: "http://example.com/someDrawing.svg#Lamppost".



Comment 29 by f...@opera.com, Oct 9 2015

As I mentioned in c#23, the <funcIRI> (or <url> per later spec) is a very small piece of the overall puzzle. No one has yet said "we're not going to implement this". What I ask is simply not to mix this issue with the one concerning the resolution of the actual <url>.

Comment 30 by pdr@chromium.org, Nov 18 2015

Cc: nyerramilli@chromium.org
Issue 557417 has been merged into this issue.
When can we expect to see this bug resolved ? I'm using CrossWalk with Cordova to build an hybrid app and I need this functionality for my icons. Should I wait, or use another way ?

Comment 32 by f...@opera.com, Dec 10 2015

Unless your "timeline" reaches far into the future should probably consider using another technique (this doesn't feel like a perfect fit for icons though - this bug is essentially about external resources.)
Is there anyway we could bump the priority of this? 

Many applications are creating stores/manifests/sprite sheets of svgs that are more complex than just monochrome icons. I get that it's a gray area in the spec but given that defs only don't properly render for external resources it feels like a bug. 

While I don't mind jumping through a few hoops to make svgs work, especially now given that support for `use` is relatively new. Not having the ability to reference defs defined in external svgs forces us to inline those files in the actual page, causing performance to go down and reducing the cachability of the whole web page.
I second the bumping of the priority. 

This is absolutely not a grey area, the current approved spec is extremely clear on what kind of URIs should work and this is straight up a bug. The only grey area is in a yet to be approved spec. 

I'm using SVGs for rendering biological pathways for use in bioinformatics and having to use functions that update the urls on several hundred elements is far from optimal. 


Comment 35 by f...@opera.com, Feb 1 2016

I don't think we can reasonably raise the priority above P2 (doing so would only serve to give a false impression.) I do have this a high priority though, but I can't really say anything more than I did in c#32. Sorry.

Also, I'd like to riterate that this should not be confused with any issues related to URL resolution (such as <base>). Fixing this will not have any direct effect on that beyond allowing external resources.
Seriously guys, why still no url(external_file.svg#resId) support after four years? 

I wanted to use this feature to reference external gradients, it works on FF but not yet on chrome 54.

Labels: Hotlist-Interop
The predictability program is reviewing the top 50 starred Blink bugs this quarter, and this is #44 on that list.  We’re hoping that for each we can either close it, set an owner and target milestone, or set a NextAction date so that we know when to check back in.

fs@ Any update on your thinking here?

Comment 38 by f...@opera.com, Mar 23 2017

The main thing we need to get here is to extend (or replace) DocumentResource so that we get a Document with Frame (i.e and attached document.) Without that we can't do style-recalc (or layout), which we'll need to be able to do for the DocumentResource to be useble for this purpose. That will then need to be integrated with all the properties mentioned here. Maybe I can find some time to do a PoC soon.
NextAction: 2017-05-15
fs@, cool - thanks!  So maybe check back in in a couple months or something?

Comment 40 by f...@opera.com, Apr 4 2017

Sure, sgtm
The NextAction date has arrived: 2017-05-15
Issue 729599 has been merged into this issue.

Comment 43 by f...@opera.com, Jun 5 2017

Blocking: 729599
Ping on this one, since it's listed as a Q2 goal for paint-dev.

Comment 45 by f...@opera.com, Jun 20 2017

This is currently blocked on fixing underlying issues with the resource-handling.
And now it's 2017-09-28. I can't find a link to the issue this one is blocked on. Please, tell us about the status of the issue.

Comment 47 by f...@opera.com, Sep 28 2017

Blockedon: 769774

Comment 48 by f...@opera.com, Sep 28 2017

I've updated the blocking chain, filling in the gaps (that I know of ATM.)

Comment 49 by f...@opera.com, Nov 13 2017

Blocking: 751733
fs@, is this something you're still working on? I came across it because of Hotlist-Interop and the many stars :)
Closing in on it.

Sign in to add a comment