New issue
Advanced search Search tips

Issue 603157 link

Starred by 2 users
Status: WontFix
Owner: ----
Closed: Apr 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

Filters applied to a <tspan> are being applied to whole <text> element

Reported by paul.leb...@gmail.com, Apr 13 2016 
UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36

Example URL:
https://jsfiddle.net/67nen0fs/4/

Steps to reproduce the problem:
1. View the linked jsfiddle page

What is the expected behavior?
Only the work "not" should have a red background.

What went wrong?
An area the size of the whole <text> element is red.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? No Firefox

Chrome version: 49.0.2623.112  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 21.0 r0

Raised here: http://stackoverflow.com/questions/36594990/applying-feflood-filter-to-tspan-not-working-as-expected

Fails in FF, but in a different way (no red background at all).
Works correctly in IE.

I've inlined the test case below in case the link breaks.

<svg width="450" height="40" viewBox="0 0 450 40"
     xmlns="http://www.w3.org/2000/svg" version="1.1">
	<defs>
	  <filter x="0" y="0" width="1" height="1" id="colorMe">
        <feFlood flood-color="red"/>
        <feComposite in="SourceGraphic"/>
    </filter>
	</defs>
    <text x="15" y="30" font-size="40px">You are 
    	<tspan fill="white" filter="url(#colorMe)">not</tspan> 
    	me
    </text>
</svg>

Comment 1 by paul.leb...@gmail.com, Apr 13 2016 

The spec says that 'filter' applies to "container elements and all graphic elements".  Given that tspan falls in neither of those groups, that suggests that filter is not valid on <tspan> at all.

That was the conclusion they came to in FF bug 917766 (https://bugzilla.mozilla.org/show_bug.cgi?id=917766).

Whether it is decided it is valid or not, the current behaviour in Chrome is broken either way.

Comment 2 by cbiesin...@chromium.org, Apr 13 2016

Components: -Blink Blink>SVG

Comment 3 by f...@opera.com, Apr 13 2016

Labels: -OS-Windows OS-All
A part of this is because of issue 349835. I see that SVG2 carries that text:

"It is possible to apply a gradient, pattern, clipping path, mask or filter to text. When one of these facilities is applied to text and keyword 'objectBoundingBox' is used (see Object bounding box units) to specify a graphical effect relative to the "object bounding box", then the object bounding box units are computed relative to the entire ‘text’ element in all cases, even when different effects are applied to different ‘tspan’ elements within the same ‘text’ element."

(Maybe something worth mentioning in your related GH issue =))

Confusing?

Comment 4 by paul.leb...@gmail.com, Apr 13 2016 

Thanks.  I guess this bug may be invalid.

Note: The GH issue referred to is https://github.com/w3c/svgwg/issues/103

Comment 5 by f...@opera.com, Apr 13 2016 

I think there are a few possible routes forward for this bug - depending on external events though in one way or another:

1) 'filter' should not apply -> make this bug be about removing that functionality.
2) Should apply, but only to the <tspan> bbox -> dupe to issue 349835 (or keep w/ dependency.)
3) Should apply per text above -> WontFix.

(Incidently, these could be named "FF", "IE" and "Chrome" respectively =D)

And for the history buffs, Presto did (2) - likely because the Adobe SVG plugin did that - and had a demo to that effect...

Comment 6 by paul.leb...@gmail.com, Apr 22 2016 

This bug should be closed as invalid. The behaviour is correct as per spec.

Comment 7 by f...@opera.com, Apr 22 2016

Status: WontFix (was: Unconfirmed)
For now at least =)
►

Sign in to add a comment