Hi,
I added another pattern to the catalog. It is a loading indicator: http://commons.wikimedia.org/wiki/File:Loading_indicator_pattern.png
I tried to keep it simple and make it fit different background chromes. To see it in motion you can go to http://dl.dropbox.com/u/30377416/design/loading-indicator/loading.html
Feedback is welcome
Pau
I like the design.
For the final though it would be nice to see it minimizing the calls to JS to do the actual animation. Heck, we could probably eliminate the image just about entirely.
- Use svg + css transforms + css animations in supporting browsers (IE10, Chrome, Firefox, ...) - Fallback to svg + css transforms + css transitions with a callback to restart the transition at the end in supporting browsers (optional, animation over transition support is more mature than I remember) - Fallback to svg + css transforms + js timeouts in supporting browsers (IE9) - Fallback to VML in supporting browsers (IE8 and below) - Fallback to an animated .gif in the worst case scenario (generally shouldn't happen)
Using svg + css will allow us to have high resolution (no hidpi issues), in the best case scenario avoid js loops entirely, and get the benefit of hardware acceleration. ((Oh on that topic I hear you may want to use 3d transformations when available even thought we're doing 2d. Apparently using the 3d ones triggers hardware acceleration in some cases the 2d transformations don't))
For reference this is what I got so far for a svg experiment in webkit: <style> .spin { -webkit-animation: spin 1s; -webkit-animation-timing-function: linear; -webkit-animation-iteration-count: infinite; } @-webkit-keyframes spin { from { -webkit-transform: rotate(0deg); }
to { -webkit-transform: rotate(360deg); } } </style> <svg width="200px" height="200px" version="1.1"> <circle cx="100" cy="100" r="35" fill="transparent" stroke="#000" stroke-width="10" stroke-opacity="0.21"></circle> <circle cx="100" cy="100" r="30" fill="transparent" stroke="#565656" stroke-width="1" stroke-opacity="0.5"></circle> <circle cx="100" cy="100" r="40" fill="transparent" stroke="#565656" stroke-width="1" stroke-opacity="0.5"></circle> <path d="M100,100 m 35,0 a 35,35 45 0 0 -35,-35" stroke="#36B" fill="transparent" stroke-linecap="round" stroke-width="5" class="spin" style="-webkit-transform-origin: 100px 100px;"></path> </svg>
The colors detailed inside the image may be off from reality.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On 12-10-30 10:35 AM, Pau Giner wrote:
Hi,
I added another pattern to the catalog. It is a loading indicator: http://commons.wikimedia.org/wiki/File:Loading_indicator_pattern.png
I tried to keep it simple and make it fit different background chromes. To see it in motion you can go to http://dl.dropbox.com/u/30377416/design/loading-indicator/loading.html
Feedback is welcome
Pau
-- Pau Giner Interaction Designer Wikimedia Foundation
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Hi Daniel,
I'm happy you like the loading indicator.
The implementation I created was a quick hack to show the animation. As you commented, the ideal solution should be friendly with high resolution displays, support old browsers, and not be js intensive. According to what I saw on bug 32101https://bugzilla.wikimedia.org/show_bug.cgi?id=32101 it seems that there is still no consensus on how to better achieve the above requirements.
In any case, feel free to submit your initial implementation to the Agora repository at GitHub https://github.com/wikimedia/agora, and fallbacks/adjustments can be added later to better support different platforms.
The svg I created for the circular indicator is available at http://commons.wikimedia.org/wiki/File:Loading_indicator_circle.svg
Thanks
Pau
On Wed, Nov 14, 2012 at 6:49 AM, Daniel Friesen daniel@nadir-seen-fire.comwrote:
I like the design.
For the final though it would be nice to see it minimizing the calls to JS to do the actual animation. Heck, we could probably eliminate the image just about entirely.
- Use svg + css transforms + css animations in supporting browsers (IE10,
Chrome, Firefox, ...)
- Fallback to svg + css transforms + css transitions with a callback to
restart the transition at the end in supporting browsers (optional, animation over transition support is more mature than I remember)
- Fallback to svg + css transforms + js timeouts in supporting browsers
(IE9)
- Fallback to VML in supporting browsers (IE8 and below)
- Fallback to an animated .gif in the worst case scenario (generally
shouldn't happen)
Using svg + css will allow us to have high resolution (no hidpi issues), in the best case scenario avoid js loops entirely, and get the benefit of hardware acceleration. ((Oh on that topic I hear you may want to use 3d transformations when available even thought we're doing 2d. Apparently using the 3d ones triggers hardware acceleration in some cases the 2d transformations don't))
For reference this is what I got so far for a svg experiment in webkit:
<style> .spin { -webkit-animation: spin 1s; -webkit-animation-timing-function: linear; -webkit-animation-iteration-count: infinite; } @-webkit-keyframes spin { from { -webkit-transform: rotate(0deg); } to { -webkit-transform: rotate(360deg); } } </style>
<svg width="200px" height="200px" version="1.1"> <circle cx="100" cy="100" r="35" fill="transparent" stroke="#000" stroke-width="10" stroke-opacity="0.21"></circle> <circle cx="100" cy="100" r="30" fill="transparent" stroke="#565656" stroke-width="1" stroke-opacity="0.5"></circle> <circle cx="100" cy="100" r="40" fill="transparent" stroke="#565656" stroke-width="1" stroke-opacity="0.5"></circle> <path d="M100,100 m 35,0 a 35,35 45 0 0 -35,-35" stroke="#36B" fill="transparent" stroke-linecap="round" stroke-width="5" class="spin" style="-webkit-transform-origin: 100px 100px;"></path> </svg>
The colors detailed inside the image may be off from reality.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On 12-10-30 10:35 AM, Pau Giner wrote:
Hi,
I added another pattern to the catalog. It is a loading indicator: http://commons.wikimedia.org/wiki/File:Loading_indicator_pattern.png
I tried to keep it simple and make it fit different background chromes. To see it in motion you can go to http://dl.dropbox.com/u/30377416/design/loading-indicator/loading.html
Feedback is welcome
Pau
-- Pau Giner Interaction Designer Wikimedia Foundation
Design mailing listDesign@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/design
On 12-11-15 8:02 AM, Pau Giner wrote:
Hi Daniel,
I'm happy you like the loading indicator.
The implementation I created was a quick hack to show the animation. As you commented, the ideal solution should be friendly with high resolution displays, support old browsers, and not be js intensive. According to what I saw on bug 32101 https://bugzilla.wikimedia.org/show_bug.cgi?id=32101 it seems that there is still no consensus on how to better achieve the above requirements.
A loader should generally only ever happen on a page where JS is enabled so deciding how to handle this situation is much easier. This stuff is made up of simple shapes so vector graphics are the cleanest way to implement this. And since we're in JS we can easily test capabilities and switch to VML when in an SVG-less IE. And best performance is naturally done through using the best available css.
In any case, feel free to submit your initial implementation to the Agora repository at GitHub https://github.com/wikimedia/agora, and fallbacks/adjustments can be added later to better support different platforms.
Mine so far is just an experiment. Mostly a prototype for the SVG and one of the types of css that the JS would generate. I'd love to write the actual implementation with the SVG, VML, JS fallbacks, etc... But sadly I don't have the free time to build something like that outside of work.
The svg I created for the circular indicator is available at http://commons.wikimedia.org/wiki/File:Loading_indicator_circle.svg
I revised my experiment based on that with better sizes, colours, and arcs instead of layered circles.
<style> .spin { -webkit-animation: spin 1s; -webkit-animation-timing-function: linear; -webkit-animation-iteration-count: infinite; } @-webkit-keyframes spin { from { -webkit-transform: rotate(0deg); }
to { -webkit-transform: rotate(360deg); } } </style> <svg width="37px" height="37px" version="1.1"> <path d="M18,18 m 17.5,0 a 17.5,17.5 0 0 1 -35,0 a 17.5,17.5 0 0 1 35,0 z m -5,0 a 12.5,12.5 0 0 1 -25,0 a 12.5,12.5 0 0 1 25,0 z" fill="#000" stroke="#565656" stroke-width="0.5" style="fill-rule: evenodd;" stroke-opacity="0.19607" fill-opacity="0.083"></path> <path d="M18,18 m 15,0 a 15,15 0 0 0 -15,-15" stroke="#36B" fill="transparent" stroke-linecap="round" stroke-width="2" class="spin" style="-webkit-transform-origin: 18px 18px;"></path> </svg>
That SVG could be extrapolated from something like: diameter = 35 border = 0.5 ringwidth = 5 gap = 1 <svg width="{ceil([diameter]/2)*2+[border]*2}" height="{ceil([diameter]/2)*2+[border]*2}" version="1.1"> <path d="M{[diameter]/2+[border]},{[diameter]/2+[border]} m {[diameter]/2},0 a {[diameter]/2},{[diameter]/2} 0 0 1 -{[diameter]},0 a {[diameter]/2},{[diameter]/2} 0 0 1 {[diameter]},0 z m -{[ringwidth]},0 a {([diameter]-[ringwidth]*2)/2},{([diameter]-[ringwidth]*2)/2} 0 0 1 -{[diameter]-[ringwidth]*2},0 a {([diameter]-[ringwidth]*2)/2},{([diameter]-[ringwidth]*2)/2} 0 0 1 {[diameter]-[ringwidth]*2},0 z" fill="#000" stroke="#565656" stroke-width="{[border]}" style="fill-rule: evenodd;" stroke-opacity="0.19607" fill-opacity="0.083"></path> <path d="M{[diameter]/2+[border]},{[diameter]/2+[border]} m {[diameter]/2-[ringwidth]/2},0 a {[diameter]/2-[ringwidth]/2},{[diameter]/2-[ringwidth]/2} 0 0 0 -{[diameter]/2-[ringwidth]/2},-{[diameter]/2-[ringwidth]/2}" stroke="#36B" fill="transparent" stroke-linecap="round" stroke-width="{[ringwidth]-[gap]*2-[border]*2}" class="spin" style="-webkit-transform-origin: {[diameter]/2+[border]}px {[diameter]/2+[border]}px;"></path> </svg> ie: This should even be variable by size, bordering, gap, etc...
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Thanks
Pau
On Thu, Nov 15, 2012 at 11:57 PM, Daniel Friesen <daniel@nadir-seen-fire.com
wrote:
On 12-11-15 8:02 AM, Pau Giner wrote:
The implementation I created was a quick hack to show the animation. As you commented, the ideal solution should be friendly with high resolution displays, support old browsers, and not be js intensive. According to what I saw on bug 32101https://bugzilla.wikimedia.org/show_bug.cgi?id=32101 it seems that there is still no consensus on how to better achieve the above requirements.
A loader should generally only ever happen on a page where JS is enabled so deciding how to handle this situation is much easier. This stuff is made up of simple shapes so vector graphics are the cleanest way to implement this. And since we're in JS we can easily test capabilities and switch to VML when in an SVG-less IE. And best performance is naturally done through using the best available css.
I wouldn't bother with VML; old IE can get an animated GIF and nobody'll know the difference. :)
I revised my experiment based on that with better sizes, colours, and arcs
instead of layered circles. [snip]
For some reason this doesn't animate correctly in Safari or Chrome when I zoom in; the origin of the rotation moves away from the center.
-- brion
I created a version of the loading indicator that I think it meets the desired requirements: http://dl.dropbox.com/u/30377416/design/loading-indicator/loading.html
It is based on:
- An animated SVGhttp://dl.dropbox.com/u/30377416/design/loading-indicator/images/loading.svg - Use of an animated gifhttp://dl.dropbox.com/u/30377416/design/loading-indicator/images/loading.giffallback based on multiple backgrounds support (similar to what is described herehttp://www.broken-links.com/2010/06/14/using-svg-in-backgrounds-with-png-fallback/ ).
The CSS code is the following:
.loading{ background: transparent url(images/loading.gif) center center no-repeat; background: none, transparent url(images/loading.svg) center center no-repeat; background-size: 100% 100%; height: 34px; width: 34px; }
The solution does not involve Javascript or complex (or vendor-specific) CSS. The "none," forces the use of multiple backgrounds so that to the SVG background is processed only by modern browsers, while the GIF one is shown for browsers not supporting multi-backgrounds such as old IE versions. As Brion commented, I think there is no need for more types of fallback.
The approach has some limitations:
- It does not work for Android 2.1 -2.3 default browser since it supports multiple backgrounds but not SVG, so it tries to display the 2nd background but no image is displayed. - It is sub-optimal for some old browser versions which may support SVG but du not display it since they lack multi-background support (such as FF 2 - 3.5). This is not a big problem since they will see the gif version.
Apart from the above I found no more issues with this approach. If there are no major complaints I'll be submitting this to the Agora repo as an initial implementation for the loading indicator. Later it can be taken as a reference to add Android-specific fixes.
On Fri, Nov 16, 2012 at 9:50 PM, Brion Vibber bvibber@wikimedia.org wrote:
On Thu, Nov 15, 2012 at 11:57 PM, Daniel Friesen < daniel@nadir-seen-fire.com> wrote:
On 12-11-15 8:02 AM, Pau Giner wrote:
The implementation I created was a quick hack to show the animation. As you commented, the ideal solution should be friendly with high resolution displays, support old browsers, and not be js intensive. According to what I saw on bug 32101https://bugzilla.wikimedia.org/show_bug.cgi?id=32101 it seems that there is still no consensus on how to better achieve the above requirements.
A loader should generally only ever happen on a page where JS is enabled so deciding how to handle this situation is much easier. This stuff is made up of simple shapes so vector graphics are the cleanest way to implement this. And since we're in JS we can easily test capabilities and switch to VML when in an SVG-less IE. And best performance is naturally done through using the best available css.
I wouldn't bother with VML; old IE can get an animated GIF and nobody'll know the difference. :)
I revised my experiment based on that with better sizes, colours, and arcs
instead of layered circles. [snip]
For some reason this doesn't animate correctly in Safari or Chrome when I zoom in; the origin of the rotation moves away from the center.
-- brion
For some reason this looks weird on an iPad (3rd gen). In default view, I see a 3/4 black circle, and the top left quarter "grey" circle, with a turning 1/4 circle. When I zoom in, the circle is all black with the turning 1/4 circle.
When I look at the individual images, I see only light colored circles with a turning 1/4 blue circle.
-- Siebrand Mazeland
M: +31 6 50 69 1239 Skype: siebrand
Op 23 nov. 2012 om 18:42 heeft Pau Giner pginer@wikimedia.org het volgende geschreven:
I created a version of the loading indicator that I think it meets the desired requirements: http://dl.dropbox.com/u/30377416/design/loading-indicator/loading.html
It is based on: An animated SVG Use of an animated gif fallback based on multiple backgrounds support (similar to what is described here). The CSS code is the following:
.loading{ background: transparent url(images/loading.gif) center center no-repeat; background: none, transparent url(images/loading.svg) center center no-repeat;
background-size: 100% 100%; height: 34px; width: 34px;}
The solution does not involve Javascript or complex (or vendor-specific) CSS. The "none," forces the use of multiple backgrounds so that to the SVG background is processed only by modern browsers, while the GIF one is shown for browsers not supporting multi-backgrounds such as old IE versions. As Brion commented, I think there is no need for more types of fallback.
The approach has some limitations: It does not work for Android 2.1 -2.3 default browser since it supports multiple backgrounds but not SVG, so it tries to display the 2nd background but no image is displayed. It is sub-optimal for some old browser versions which may support SVG but du not display it since they lack multi-background support (such as FF 2 - 3.5). This is not a big problem since they will see the gif version. Apart from the above I found no more issues with this approach. If there are no major complaints I'll be submitting this to the Agora repo as an initial implementation for the loading indicator. Later it can be taken as a reference to add Android-specific fixes.
On Fri, Nov 16, 2012 at 9:50 PM, Brion Vibber bvibber@wikimedia.org wrote:
On Thu, Nov 15, 2012 at 11:57 PM, Daniel Friesen daniel@nadir-seen-fire.com wrote:
On 12-11-15 8:02 AM, Pau Giner wrote:
The implementation I created was a quick hack to show the animation. As you commented, the ideal solution should be friendly with high resolution displays, support old browsers, and not be js intensive. According to what I saw on bug 32101 it seems that there is still no consensus on how to better achieve the above requirements.
A loader should generally only ever happen on a page where JS is enabled so deciding how to handle this situation is much easier. This stuff is made up of simple shapes so vector graphics are the cleanest way to implement this. And since we're in JS we can easily test capabilities and switch to VML when in an SVG-less IE. And best performance is naturally done through using the best available css.
I wouldn't bother with VML; old IE can get an animated GIF and nobody'll know the difference. :)
I revised my experiment based on that with better sizes, colours, and arcs instead of layered circles. [snip]
For some reason this doesn't animate correctly in Safari or Chrome when I zoom in; the origin of the rotation moves away from the center.
-- brion
-- Pau Giner Interaction Designer Wikimedia Foundation
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Thanks for the feedback siebrand.
I could reproduce it in Safari and fix it. Does it work now in the iPad?
the fix infolved replacing "none" with "transparent":
background: *transparent*, transparent url(images/loading.svg) center center no-repeat;
On Fri, Nov 23, 2012 at 7:10 PM, Siebrand Mazeland (WMF) < smazeland@wikimedia.org> wrote:
For some reason this looks weird on an iPad (3rd gen). In default view, I see a 3/4 black circle, and the top left quarter "grey" circle, with a turning 1/4 circle. When I zoom in, the circle is all black with the turning 1/4 circle.
When I look at the individual images, I see only light colored circles with a turning 1/4 blue circle.
-- Siebrand Mazeland
M: +31 6 50 69 1239 Skype: siebrand
Op 23 nov. 2012 om 18:42 heeft Pau Giner pginer@wikimedia.org het volgende geschreven:
I created a version of the loading indicator that I think it meets the desired requirements: http://dl.dropbox.com/u/30377416/design/loading-indicator/loading.html
It is based on:
- An animated SVGhttp://dl.dropbox.com/u/30377416/design/loading-indicator/images/loading.svg
- Use of an animated gifhttp://dl.dropbox.com/u/30377416/design/loading-indicator/images/loading.giffallback based on multiple backgrounds support (similar to what is
described herehttp://www.broken-links.com/2010/06/14/using-svg-in-backgrounds-with-png-fallback/ ).
The CSS code is the following:
.loading{ background: transparent url(images/loading.gif) center center no-repeat; background: none, transparent url(images/loading.svg) center center no-repeat; background-size: 100% 100%; height: 34px; width: 34px; }
The solution does not involve Javascript or complex (or vendor-specific) CSS. The "none," forces the use of multiple backgrounds so that to the SVG background is processed only by modern browsers, while the GIF one is shown for browsers not supporting multi-backgrounds such as old IE versions. As Brion commented, I think there is no need for more types of fallback.
The approach has some limitations:
- It does not work for Android 2.1 -2.3 default browser since it
supports multiple backgrounds but not SVG, so it tries to display the 2nd background but no image is displayed.
- It is sub-optimal for some old browser versions which may support
SVG but du not display it since they lack multi-background support (such as FF 2 - 3.5). This is not a big problem since they will see the gif version.
Apart from the above I found no more issues with this approach. If there are no major complaints I'll be submitting this to the Agora repo as an initial implementation for the loading indicator. Later it can be taken as a reference to add Android-specific fixes.
On Fri, Nov 16, 2012 at 9:50 PM, Brion Vibber bvibber@wikimedia.orgwrote:
On Thu, Nov 15, 2012 at 11:57 PM, Daniel Friesen < daniel@nadir-seen-fire.com> wrote:
On 12-11-15 8:02 AM, Pau Giner wrote:
The implementation I created was a quick hack to show the animation. As you commented, the ideal solution should be friendly with high resolution displays, support old browsers, and not be js intensive. According to what I saw on bug 32101https://bugzilla.wikimedia.org/show_bug.cgi?id=32101 it seems that there is still no consensus on how to better achieve the above requirements.
A loader should generally only ever happen on a page where JS is enabled so deciding how to handle this situation is much easier. This stuff is made up of simple shapes so vector graphics are the cleanest way to implement this. And since we're in JS we can easily test capabilities and switch to VML when in an SVG-less IE. And best performance is naturally done through using the best available css.
I wouldn't bother with VML; old IE can get an animated GIF and nobody'll know the difference. :)
I revised my experiment based on that with better sizes, colours, and
arcs instead of layered circles. [snip]
For some reason this doesn't animate correctly in Safari or Chrome when I zoom in; the origin of the rotation moves away from the center.
-- brion
-- Pau Giner Interaction Designer Wikimedia Foundation
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Nope. No HQ image on zoom.
-- Siebrand Mazeland
M: +31 6 50 69 1239 Skype: siebrand
Op 23 nov. 2012 om 20:00 heeft Pau Giner pginer@wikimedia.org het volgende geschreven:
Thanks for the feedback siebrand.
I could reproduce it in Safari and fix it. Does it work now in the iPad?
I polished the technique a bit more to solve previous issues: http://dl.dropbox.com/u/30377416/design/loading-indicator/loading-gradient.h...
To better detect browser capabilities, I used a transparent gradient as a secondary background image. That makes old Webkit browsers (which solves problem with Android 2.x) and IE9 (capable of multi-background but not animations) to use the Gif Fallback.
background: transparent url(images/*loading.gif*) center center no-repeat;
background-image: *linear-gradient(transparent, transparent),* url(images/ *loading-static.svg*);
In addition, I used CSS animations since the SVG animation was problematic on Safari.
In theory (based on browser version support for gradientshttp://caniuse.com/css-gradientsand svg http://caniuse.com/#feat=svg), it should work across all browsers (some SVG-capable old browsers may still use the fallback but it guarantees that SVG is not used by browsers not able to render it).
Pau
On Fri, Nov 23, 2012 at 8:06 PM, Siebrand Mazeland (WMF) < smazeland@wikimedia.org> wrote:
Nope. No HQ image on zoom.
-- Siebrand Mazeland
M: +31 6 50 69 1239 Skype: siebrand
Op 23 nov. 2012 om 20:00 heeft Pau Giner pginer@wikimedia.org het volgende geschreven:
Thanks for the feedback siebrand.
I could reproduce it in Safari and fix it. Does it work now in the iPad?
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
-- Matma Rex
2012/11/26 Pau Giner pginer@wikimedia.org:
I polished the technique a bit more to solve previous issues: http://dl.dropbox.com/u/30377416/design/loading-indicator/loading-gradient.h...
Pau, you are missing an unprefixed @keyframes rule, without which this won't work on Opera:
@keyframes spin { from { transform: rotate(0deg); } to { transform: rotate(360deg); } }
After it's added, it works nicely.
On Nov 27, 2012, at 8:19 AM, Bartosz Dziewoński matma.rex@gmail.com wrote:
-- Matma Rex
2012/11/26 Pau Giner pginer@wikimedia.org:
I polished the technique a bit more to solve previous issues: http://dl.dropbox.com/u/30377416/design/loading-indicator/loading-gradient.h...
Pau, you are missing an unprefixed @keyframes rule, without which this won't work on Opera:
@keyframes spin { from { transform: rotate(0deg); } to { transform: rotate(360deg); } }
After it's added, it works nicely.
Also the ms prefix seems bogus, afaik IE <= 9 doesn't support it at all. And IE10 supports unprefixed.
http://caniuse.com/#feat=css-animation
I'd drop -ms and -moz, keep -webkit and add unprefixed.
-- Krinkle
Thanks to all for your comments.
I applied Krinkle and Bartosz comments and defined the ruless using LessCSS to be included in the Agora repo. I submitted a pull requesthttps://github.com/wikimedia/agora/pull/7 to continue there the development. An example can be viewed here (it may be a bit slow since Less is not pre-compiled but applied live for the example): http://dl.dropbox.com/u/30377416/design/agora/examples/loading-indicator/loa...
S, these little moving elements are better evaluated in context (when peripheral vision is used) than staring directly at them. When we apply this in context we'll probably need to adjust the rotation speed to play well with the animation capabilities of browsers.
Pau
On Tue, Nov 27, 2012 at 11:01 PM, Krinkle krinklemail@gmail.com wrote:
On Nov 27, 2012, at 8:19 AM, Bartosz Dziewoński matma.rex@gmail.com wrote:
-- Matma Rex
2012/11/26 Pau Giner pginer@wikimedia.org:
I polished the technique a bit more to solve previous issues:
http://dl.dropbox.com/u/30377416/design/loading-indicator/loading-gradient.h...
Pau, you are missing an unprefixed @keyframes rule, without which this won't work on Opera:
@keyframes spin { from { transform: rotate(0deg); } to { transform: rotate(360deg); } }
After it's added, it works nicely.
Also the ms prefix seems bogus, afaik IE <= 9 doesn't support it at all. And IE10 supports unprefixed.
http://caniuse.com/#feat=css-animation
I'd drop -ms and -moz, keep -webkit and add unprefixed.
-- Krinkle
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Mon, Nov 26, 2012 at 2:19 PM, Pau Giner pginer@wikimedia.org wrote:
I polished the technique a bit more to solve previous issues: http://dl.dropbox.com/u/30377416/design/loading-indicator/loading-gradient.h...
I'm vaguely aware of a puff of white at the end of the blue worm, so my eyes flicker between its head and tail. I notice it more in Firefox than Chromium.
I'm not on drugs but I'm not a designer. :-)
-- =S Page software engineer on E3