3 ms·
I love Firefox, but I am encountering problems like this more and more often. It's a disaster to use with Coursera or Netflix.
by rohern 14y ago
I love Firefox, but I am encountering problems like this more and more often. It's a disaster to use with Coursera or Netflix.
- whatshisface 14y ago"This page is best viewed with Google Explorer" It looks like the page is doing something funny with javascript to render the bars, why not just use good old css?
- jgraham 14y agoThe problem is that the site is using SVG paint servers to provide a gradient for the progress rect. The gradient is specified in a SVG def element with id barGradient in the HTML file. So far so good. The problem arises because the fill rule is written as "fill: url(#barGradient)" and is placed in an external CSS file. In this case the fragment should be resolved against the stylesheet URL, not the HTML document URL [1]. It appears that Gecko and Opera get this right and WebKit doesn't. However the page relies on the incorrect behaviour here. (I also note that Gecko and Presto do different things after they fail to resolve the paint server; Gecko falls back to "none", Presto to the default fill colour. My reading of SVG 1.2T is that Gecko is correct in this case [2]). tldr; The page relies on a WebKit bug. The Gecko rendering is correct. [1] http://www.w3.org/TR/css3-values/#urls http://www.w3.org/TR/css3-values/#urls [2] http://www.w3.org/TR/SVGTiny12/painting.html#SpecifyingPaint http://www.w3.org/TR/SVGTiny12/painting.html#SpecifyingPaint
- anti-pattern 14y agoAh, that makes sense. Thanks for explaining it! This was my first time using SVG. So, what is the best solution? Defining SVG styles in a style tag?
- jgraham 14y agoThat would work, yes.