Svg Transform="Rotate(180)" Does Not Work in Safari 11

SVG transform= rotate(180) does not work in Safari 11

In SVG 1.1 <svg> elements did not support transform attributes. In SVG 2 it is proposed that they should.

Chrome and Firefox implement this part of the SVG 2 specification, Safari does not yet do so and IE11 never will.

You can achieve the same result in browsers that do not support this SVG 2 feature either by replacing the <svg> element by a <g> element or by creating an <g> child element on the <svg> element and putting the transform on the <g> element.

SVG transform rotate by 90, 180 or 270 degrees not working on circle in Safari iOS 10

I've experienced this painfully on iOS 10.1 and Safari 10.0.1. The bug is definitely triggered by any rotate value which computes to a value divisible by 90 degrees.

But it gets weirder: the bug's presence is affected by the current zoom level.

See this demo/series of minimal test cases I put together (jsFiddle version here). Best to run the snippet then expand to full page:

svg {

height: 80px;

width: 80px;

}

circle {

fill: none;

stroke-dasharray: 150;

stroke-width: 4px;

stroke: #6fdb6f;

transform-origin: center center;

}

.degrot {

transform: rotate(-90deg);

}

.degrot-offset {

transform: rotate(-90.1deg);

}

.degrot-offset-more {

transform: rotate(-92deg);

}

.turnrot {

transform: rotate(-0.25turn);

}

.turnrot-offset {

transform: rotate(-0.251turn);

}

svg[viewBox] circle {

stroke-dasharray: 300;

stroke-width: 8px;

}

svg[viewBox].scaledown circle {

stroke-dasharray: 300;

stroke-width: 8px;

}

svg[viewBox].noscale circle {

stroke-dasharray: 150;

stroke-width: 4px;

}

svg[viewBox].scaleup circle {

stroke-dasharray: 75;

stroke-width: 2px;

}

.wc {

will-change: transform;

}

/* Demo prettification */

p:last-child {

margin-bottom: 0;

}

td {

padding: 10px;

}

tr td:first-of-type {

width: 80px;

min-height: 80px;

}

tr + tr td {

border-top: 1px solid #dcdcdc;

}
<table>

<tr><td colspan="2">In Safari 10.0.1 and iOS 10.1, strange behavior can be observed on SVG shapes with <code>rotate</code> values not divisible by 90 degrees, when <code>transform-origin: center center;</code></td></tr>

<tr>

<td>

<svg xmlns="http://www.w3.org/2000/svg">

<circle class="degrot" r="35" cy="40" cx="40" />

</svg>

</td>

<td>

<code>transform: rotate(-90deg);</code>

<p>The stroke improperly begins <a href="https://www.w3.org/TR/SVG11/shapes.html#CircleElement">at 3:00</a>, as if the <code>transform</code> rule hadn't been applied.</p>

</td>

</tr>

<tr>

<td>

<svg xmlns="http://www.w3.org/2000/svg">

<circle class="degrot-offset" r="35" cy="40" cx="40" />

</svg>

</td>

<td>

<code>transform: rotate(-90.1deg);</code>

<p>The stroke begins at (twelve seconds before) 12:00, as expected.</p>

</td>

</tr>

<tr>

<td>

<svg xmlns="http://www.w3.org/2000/svg">

<circle class="turnrot" r="35" cy="40" cx="40" />

</svg>

</td>

<td>

<code>transform: rotate(-0.25turn);</code>

<p>The same bug applies to any <code>rotate</code> value which computes to a multiple of 90 degrees.</p>

</td>

</tr>

<tr>

<td>

<svg xmlns="http://www.w3.org/2000/svg">

<circle class="turnrot-offset" r="35" cy="40" cx="40" />

</svg>

</td>

<td>

<code>transform: rotate(-0.251turn);</code>

<p>43 seconds before noon.</p>

</td>

</tr>

<tr><td colspan="2">But when the SVG element specifies a <code>viewBox</code> which is being scaled down, things can get weird:</td></tr>



<tr>

<td>

<svg viewBox="0 0 160 160" xmlns="http://www.w3.org/2000/svg">

<circle class="degrot" r="70" cy="80" cx="80" />

</svg>

</td>

<td>

<code>transform: rotate(-90deg);</code>

<p>So far, so the same.</p>

</td>

</tr>

<tr>

<td>

<svg viewBox="0 0 160 160" xmlns="http://www.w3.org/2000/svg">

<circle class="degrot-offset" r="70" cy="80" cx="80" />

</svg>

</td>

<td>

<code>transform: rotate(-90.1deg);</code>

<p>But now, offsetting by a little bit doesn't work, <em>unless</em> you zoom in the page in past a certain zoom threshold (either via pinching, or <code>View > Zoom</code> and/or keyboard shortcut). Try it; it's unsetting!</p>

<p>This is probably because of some rounding of that the zooming engine performs, because...</p>

</td>

</tr>

<tr>

<td>

<svg viewBox="0 0 160 160" class="scaledown" xmlns="http://www.w3.org/2000/svg">

<circle class="degrot-offset-more" r="70" cy="80" cx="80" />

</svg>

</td>

<td>

<code>transform: rotate(-92deg);</code>

<p>offsetting by a larger amount restores expected behavior.</p>

</td>

</tr>

<tr><td colspan="2">If the SVG element is not being scaled <em>down</em>, behavior identical to the first section resumes. Zooming has no effect:</td></tr>



<tr>

<td>



<svg viewBox="0 0 80 80" class="noscale" xmlns="http://www.w3.org/2000/svg">

<circle class="degrot" r="35" cy="40" cx="40" />

</svg>

<svg viewBox="0 0 40 40" class="scaleup" xmlns="http://www.w3.org/2000/svg">

<circle class="degrot" r="17.5" cy="20" cx="20" />

</svg>

</td>

<td>

<code>transform: rotate(-90deg);</code>

<p>

Top: No scaling (viewBox dimensions match parent element's)<br><br>

Bottom: Scaling up (viewBox dimensions half of parent element's)

</p>

</td>

</tr>

<tr>

<td>



<svg viewBox="0 0 80 80" class="noscale" xmlns="http://www.w3.org/2000/svg">

<circle class="degrot-offset" r="35" cy="40" cx="40" />

</svg>

<svg viewBox="0 0 40 40" class="scaleup" xmlns="http://www.w3.org/2000/svg">

<circle class="degrot-offset" r="17.5" cy="20" cx="20" />

</svg>

</td>

<td>

<code>transform: rotate(-90.1deg);</code>

<p>

Top: No scaling (viewBox dimensions match parent element's)<br><br>

Bottom: Scaling up (viewBox dimensions half of parent element's)

</p>

</td>

</tr>

<tr><td colspan="2">But there is one exception:</td></tr>

<tr>

<td>



<svg class="degrot wc" xmlns="http://www.w3.org/2000/svg">

<circle r="35" cy="40" cx="40" />

</svg>

</td>

<td>

<p>On the parent <code>svg</code> element:</p>

<code>transform: rotate(-90deg);<br>will-change: transform;</code>

<p>Iff the the the rotation is applied to a <em>parent</em> of the SVG shape (including the SVG element itself) along with the rule <code>will-change: transform</code>, all rotation values work as expected.</p>

</td>

</tr>

<tr><td colspan="2">All these behaviors have been observed in Safari 10.0.1 and iOS 10.1. They appear to be fixed as of iOS 10.2 Beta 2.</td></tr>

</table>

CSS endless rotation animation

Works in all modern browsers

.rotate{
animation: loading 3s linear infinite;
@keyframes loading {
0% {
transform: rotate(0);
}
100% {
transform: rotate(360deg);
}
}
}

Transform not Working on IOS

Found the problem, it was a silly one. I didn't use -webkit which is supported for iOS. Below is the solved JS Fiddle if anyone needs it ..

.circle-container {
position: relative;
width: 15em;
height: 14em;
padding: 2.8em;
/*2.8em = 2em*1.4 (2em = half the width of a link with img, 1.4 = sqrt(2))*/
border: dashed 0px;
border-radius: 50%;

}
.circle-container > a {
display: block;
text-decoration: none;
position: absolute;
top: 50%; left: 50%;
width: 4em; height: 4em;
margin: -2em;

text-align: center;
}

.circle-container div {
display: block;
text-decoration: none;
position: absolute;
top: 50%; left: 50%;
width: 4em; height: 4em;
margin: -2em;
text-align: center;
}
.circle-container img { display: block; width: 100%; height:320px; position:absolute; margin-left:-25px; margin-top:15px;}
.deg0 {
transform: translate(5.2em);
-webkit-transform: translate(5.2em);
-ms-transform: translate(5.2em);
} /* 12em = half the width of the wrapper */
.deg45 {
transform: rotate(45deg) translate(5.4em) rotate(-45deg);
-webkit-transform: rotate(45deg) translate(5.4em) rotate(-45deg);
-ms-transform: rotate(45deg) translate(5.4em) rotate(-45deg);
}
.deg90 {
transform: rotate(-90deg) translate(5em) rotate(90deg);
-webkit-transform: rotate(-90deg) translate(5em) rotate(90deg);
-ms-transform: rotate(-90deg) translate(5em) rotate(90deg);
}
.deg110 {
transform: rotate(45deg) translate(5em) rotate(-45deg);
-webkit-transform: rotate(45deg) translate(5em) rotate(-45deg);
-ms-transform: rotate(45deg) translate(5em) rotate(-45deg);
}
.deg135 {
transform: rotate(135deg) translate(5em) rotate(-135deg);
-webkit-transform: rotate(135deg) translate(5em) rotate(-135deg);
-ms-transform: rotate(135deg) translate(5em) rotate(-135deg);
}
.deg180 {
transform: translate(-5em);
-webkit-transform: translate(-5em);
-ms-transform: translate(-5em);
}
.deg225 {
transform: rotate(225deg) translate(5em) rotate(-225deg);
-webkit-transform: rotate(225deg) translate(5em) rotate(-225deg);
-ms-transform: rotate(225deg) translate(5em) rotate(-225deg);
}
.deg315 {
transform: rotate(315deg) translate(5em) rotate(-315deg);
-webkit-transform: rotate(315deg) translate(5em) rotate(-315deg);
-ms-transform: rotate(315deg) translate(5em) rotate(-315deg);
}

Bug in CSS3 rotateY transition on Safari?

As far as I can tell it's a bug, yes, Safari is rendering intersection where it shouldn't.

For some time I thought Safari is doing it right by always rendering intersection of elements, but as far as I understand the specs, only elements in the same 3d rendering context should intersect, and that would be children of elements with a transform-style of preserve-3d.

So far the only workaround I found (only tested on Windows yet where Safari shows the same behaviour) is to translate the underlying elements away on the z-axis. Without perspective being applied it won't actually translate, but Safari/Webkit seems to think it does (which probably is because it mistakenly treats the element as if it were in the same 3d rendering context as the actually transformed dialog) and so the elements do no longer intersect.

.effeckt-overlay {
position: fixed;
width: 100%;
height: 100%;
visibility: hidden;
top: 0;
left: 0;
opacity: 0;
-webkit-transition: 500ms;
-o-transition: 500ms;
transition: 500ms;
z-index: 1000;
background: rgba(0, 0, 0, 0.5);

-webkit-transform: translateZ(-1000px);
}

http://jsfiddle.net/eJsZx/5/



Related Topics



Leave a reply



Submit