HTML and CSS Reference
In-Depth Information
Memory allocation and computational burden
If you go around compositing every element in the DOM just for the sake of hard‐
ware acceleration, the next person who works on your code may chase you down
and beat you severely.
Power consumption and battery life
Obviously, when hardware kicks in, so does the battery. Developers are forced to
take the wide array of device constraints into consideration while writing mobile
web apps. This will be even more prevalent as browser makers start to enable access
to more and more device hardware. Luckily, we will soon have an API for checking
the status of the device battery .
You will encounter glitchy behavior when applying hardware acceleration to parts
of the page that were already accelerated. So knowing if you have overlapping ac‐
celeration is very important.
To make user interaction smooth and as close to native as possible, you must make the
browser work for you. Ideally, you want the mobile device CPU to set up the initial
animation, and then have the GPU responsible for only compositing different layers
during the animation process. This is what translate3d , scale3d , and translateZ do:
they give the animated elements their own layer, thus allowing the device to render
everything together smoothly.
CSS features can come at a cost on low-end devices. When using CSS gradient , box-
shadow , borders , and background-repeat , you are using the device GPU to paint your
images on the fly. CSS can be very powerful for rendering a nice user interface, but you
should avoid doing this type of work in software when it can be prebaked in images.
This means you should use sprites so the device downloads only a single image and
embed data URIs in your CSS files for smaller images.
A few animations that don't require repaints are:
CSS selector performance can cripple older mobile browsers. Using selectors like:
div [ style *= 'foo' ]
will severely reduce performance on iOS devices up to version 4.3.x.
Search WWH ::

Custom Search