Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><strong>Edit:</strong> </p> <p>There's a rough workaround for this that doesn't require hacking Raphael core code, but does depend on a not completely stable IE bug, described <a href="https://github.com/DmitryBaranovskiy/raphael/issues/177" rel="nofollow">https://github.com/DmitryBaranovskiy/raphael/issues/177</a></p> <p>It works by hiding the SVG pattern object from Raphael by renaming it in the Raphael object, causing <code>updatePosition()</code> to not be called. This stops Raphael moving the background image in SVG mode. In VML mode, IE8 has a bug whereby, even though the code moves the <code>&lt;fill&gt;</code> element, this isn't updated on the screen until a redraw is forced.</p> <pre><code>path.patternTmp = path.pattern; delete path.pattern; </code></pre> <p>This has the same other downside as the suggestion below that in VML mode it relies on an IE bug. But it works for simple cases. I haven't tested fully enough to see if there are other side effects of this fix, but there shouldn't be - looked at Raphael's source code, it looks like <code>updatePosition()</code> is the only Raphael function that uses <code>element.pattern</code>.</p> <h2><a href="http://jsbin.com/oxuyeq/10/edit" rel="nofollow">http://jsbin.com/oxuyeq/10/edit</a></h2> <p>Note that <code>path.pattern</code> has to be renamed like this every time an image fill is applied - so if you reapply the fill for any reason, you need to re-do this fix - and that re-applying the fill will 'fix' the IE bug we depend on causing the image to slip out of sync with the object.</p> <hr> <p><strong>Original answer:</strong> Here's a sort-of fix. It's ugly in two ways:</p> <ul> <li>For SVG, it relies on hacking Raphael core code (but only a small hack)</li> <li>For VML, it relies on an Internet Explorer redraw bug, and will fail if your code causes a redraw</li> </ul> <p>But you can get relative positions, so long as your code doesn't trigger an IE redraw (e.g. by re-setting the element's fill).</p> <p>Ideally, there would be a way of doing this that works robustly in IE VML rather than relying on a bug.</p> <hr> <p>You can do this ugly almost-fix by <strong>turning off the Raphael function <code>updatePosition()</code> somehow</strong>. The behaviour described above isn't an SVG default, it's a Raphael feature defined in the <code>updatePosition()</code> function which appears to be designed to make Raphael SVG elements' behaviour match how VML elements <em>would</em> behave if Internet Explorer wasn't a bundle of bugs held together with bugs. Note that the <code>updatePosition()</code> function is <em>only</em> called in SVG mode - VML fills are <em>supposed</em> to behave this way by default (but don't reliably because of the redraw bug described in the above linked question...).</p> <p>My (ugly) way of doing this is to modify the <code>updatePosition()</code> function code to this:</p> <pre><code>updatePosition = function (o) { if(!o.relativeFill) { // &lt;&lt;&lt; added this condition var bbox = o.getBBox(1); $(o.pattern, {patternTransform: o.matrix.invert() + " translate(" + bbox.x + "," + bbox.y + ")"}); } }, </code></pre> <p>...then, for each element you want to have a relative fill, you set <code>someElement.relativeFill = true;</code></p> <hr> <p>Note that <strong>this isn't good practice</strong> - e.g. a future Raphael update might use the relativeFill namespace for something else. It's just an example of a sticky plaster fix that (just about) works.</p> <hr> <p><strong>re. VML mode:</strong> In theory, you might be able to make this fix robust and not bug dependent by adding a similar condition to the place in the VML-mode Raphael functions <code>setFillAndStroke</code> and/or <code>setCoords</code> that set <code>fill.position</code> to a dynamic calculation. These seem to be the VML equivalent of <code>updatePosition()</code>. In theory, VML should by default set the fill relative to the shape so long as <a href="http://msdn.microsoft.com/en-us/library/bb229597%28v=vs.85%29.aspx" rel="nofollow"><code>alignshape = true</code> for the fill element, which in theory should be true by default</a>.</p> <p>But, it doesn't seem to work like that in practice. From my testing, relying on the IE bug as above actually seems to be <em>more</em> robust than trying to get IE VML to work as documented. In my testing, it's quite difficult to get IE8 to redraw the fill: only resetting the fill seems to do it.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload