Re: The ability to turn off animations in browsers

Stu Cox <[email protected]> Tue, 11 Jun 2013 11:02:37 +0100
Newsgroups gmane.comp.web.html.general
Message-ID <CAJ-2Ov7FMoi0K_0HhUKnM=OwvOrAvnXcO2iBAnX1e3AUZipVfA@mail.gmail.com>
--001a11c3715c115ca604dede01ed
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 10 June 2013 17:59, David Woolley <[email protected]> wrote:

> The extreme case would be e-Ink based devices, which have very low idle
> power consumptions, but the trend with "web designers" is to use all the
> processing power that they can get their hands on, in order get the
> attention of jaded users, at a time when hardware is getting better and
> better at power management.  Low end gaming GPUs can have a power
> consumption change of 60 watts between a static picture and maximum
> animation, and CPUs may also vary by about that much.
>
> I'd actually want this for accessibility and usability reasons.  For the
> elderly and people with more formal cognitive disabilities, the animation
> is distracting - its often meant to be - its there to get people to look =
at
> the advertising, rather than the editorial.
>
> Actually, I'd also suggest the increasing number of pages that seem to be
> continually running scripts also has an impact on energy wastage.  I tend
> to see this in terms of hogging the CPU on a single core system, but, on =
a
> modern system I'm sure that produces a quite significant power consumptio=
n.
>
> This is all really a "web design" rather than an HTML issue.
>


I think being able to disable power-intensive browser features would be a
very good thing. With FF OS apparently targeting low-cost devices &
emerging markets, it's something I could imagine being very beneficial
there =96 and something I've thought about myself.

However, in order for it to *work*, designers and developers would have to
shift their thinking. Even with feature detection, loads of assumptions are
still frequently made: that support for X implies support for Y (because
all current browsers which support X also support Y).

Developers define their browser support and assume they have everything
those browsers support, then feature detect thereafter. Being able to
disable features turns every "yes" in a caniuse.com table into a "maybe"
and gives a minimum spec less meaning: an app supporting IE10+ would still
need to feature detect animations.

I actually think it would be very beneficial for browser and device
compatibility and accessibility if developers took an "assume nothing"
approach and considered that any individual browser, device or user
capability may or may not be present. Education would be a serious
challenge though.

--001a11c3715c115ca604dede01ed
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On 10 June 2013 17:59, David Wo=
olley <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" t=
arget=3D"_blank">[email protected]</a>&gt;</span> wrote:<br><div c=
lass=3D"gmail_quote">



<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div style=3D"overflow:hidden">The extreme case would be e=
-Ink based devices, which have very low idle power consumptions, but the tr=
end with &quot;web designers&quot; is to use all the processing power that =
they can get their hands on, in order get the attention of jaded users, at =
a time when hardware is getting better and better at power management. =A0L=
ow end gaming GPUs can have a power consumption change of 60 watts between =
a static picture and maximum animation, and CPUs may also vary by about tha=
t much.<br>




<br>
I&#39;d actually want this for accessibility and usability reasons. =A0For =
the elderly and people with more formal cognitive disabilities, the animati=
on is distracting - its often meant to be - its there to get people to look=
 at the advertising, rather than the editorial.<br>




<br>
Actually, I&#39;d also suggest the increasing number of pages that seem to =
be continually running scripts also has an impact on energy wastage. =A0I t=
end to see this in terms of hogging the CPU on a single core system, but, o=
n a modern system I&#39;m sure that produces a quite significant power cons=
umption.<br>




<br>
This is all really a &quot;web design&quot; rather than an HTML issue.</div=
></blockquote></div><br><br></div><div class=3D"gmail_extra">I think being =
able to disable power-intensive browser features would be a very good thing=
. With FF OS apparently targeting low-cost devices &amp; emerging markets, =
it&#39;s something I could imagine being very beneficial there =96 and some=
thing I&#39;ve thought about myself.<br>



</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra" style=
>However, in order for it to *work*, designers and developers would have to=
 shift their thinking. Even with feature detection, loads of assumptions ar=
e still frequently made: that support for X implies support for Y (because =
all current browsers which support X also support Y).</div>

<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
>Developers define their browser support and assume they have everything th=
ose browsers support, then feature detect thereafter. Being able to disable=
 features turns every &quot;yes&quot; in a <a href=3D"http://caniuse.com">c=
aniuse.com</a> table into a &quot;maybe&quot; and gives a minimum spec less=
 meaning: an app supporting IE10+ would still need to feature detect animat=
ions.</div>

<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
>I actually think it would be very beneficial for browser and device compat=
ibility and accessibility if developers took an &quot;assume nothing&quot; =
approach and considered that any individual browser, device or user capabil=
ity may or may not be present. Education would be a serious challenge thoug=
h.<br>

</div><div class=3D"gmail_extra" style><br></div></div>

--001a11c3715c115ca604dede01ed--