Earlier this year, WebKit updated the behavior of the CSS background shorthand property. With this change, the background shorthand property will reset the background-size to its default value of auto auto if it’s not set in the shorthand declaration. This change brings Chrome and other WebKit browsers in compliance with the specification and matches the behavior of Firefox, Opera and Internet Explorer.

With Chrome for Android moving forward to current revisions on WebKit, this change is now rolling out in Android. Because this was a fix to webkit, sites that tested in multiple browsers are likely not affected.

Old way of doing things

// background-size is reset to auto auto by the background shorthand 
.foo {  
  background-size: 50px 40px;
  background: url(foo.png) no-repeat;
}

The background shorthand property does not contain any size property and will therefore reset the background-size to its default value of auto auto.

Correct way to specifying image size

// background-size is specified after background
.fooA {
  background: url(foo.png) no-repeat;
  background-size: 50px 40px;
}


	
// background-size is specified inline after position
.fooB {
  background: url(foo.png) 0% / 50px 40px no-repeat;
}

In fooB, specifying a background-size in the background shorthand requires the position (0%) be specified first, followed by a forward slash then the background-size (50px 40px). |

Fixes for existing code

There are several options that will provide an easy fix for this:

• Use background-image instead of the background shorthand property.
• Set the background-size last, with a higher specificity than any other CSS rules that set background on that element, and don’t forget to check and :hover rules.
• Apply the !important property to background-size.
• Move the sizing information to the background shorthand property.

Bonus: background image offsets

In addition to this change, there’s now greater flexibility in positioning the image within the background. In the past, you could only specify the image position relative from the top left corner, now you can specify an offset from the edges of the container. For example setting background-position: right 5px bottom 5px; the image will be positioned 5px from the right edge and 5px from the bottom. Check out this sample on JSBin

Comments | permalink

You've probably already heard that Chrome for Android Beta launched today. This new browser is based on the Chromium open source project, and brings with it many of the latest HTML5 features that Chrome developers have come to know and love. For an overview of the new hotness, see the launch announcement on blog.chromium.org and a more detailed overview on code.google.com. I'll quickly go through the stuff I personally find most interesting:

UI Improvements

Chrome for Android makes it easy for developers to create modern mobile web user interfaces using fixed positioning, and overflow: scroll for individually scrollable elements. In addition, native-like scroll behavior is enabled by default. Chrome for Android supports the old flexbox model, though be aware that the original flexbox model is deprecated in favor of a new one. Also supported are DateTime pickers, and early support for <input type="range">.

Fast graphics

Chrome for Android also supports hardware accelerated canvas, and performs quite well. There's also support for requestAnimationFrame, which is important for mobile, letting the browser decide when to render, giving it a chance to manage battery life more efficiently in GPU intensive applications. Chrome for Android introduces a slew of other notable HTML5 features including File System API, IndexedDB, Web Workers and Web Sockets.

Remote debugging

Hands down, my personal favorite feature of Chrome for Android is remote debugging through the Chrome Developer Tools. Remote debugging makes it very easy for web developers to debug their application as it's running live on their mobile device, without having to resort to clever hacks such as Weinre. Here's a quick screencast showing this feature in action:

For more information about remote debugging, see this remote debugging article.

Try Chrome for Android Beta for yourself by downloading it from the Android Market. If you've written a mobile web app to use a feature, but Chrome for Android doesn't support it, keep in mind that this is a beta release, and see if this is already a known issue, and star it if it is. Otherwise, please log a bug via new.mcrbug.com.

I'm stoked about the positive impact Chrome for Android will make on the mobile web developer community, and looking forward to see the great things we can build together! If you have additional questions, see if they are already answered in this FAQ. Otherwise, if you have a Chrome-specific mobile web development question, please post it on Stack Overflow, tagged with the google-chrome and android tags.

Comments | permalink

Heads-up from our friends at Opera, who have been testing WebGL on actual OpenGL ES 2.0 hardware: many demos and applications use highp precision in fragment shaders when it’s not really warranted.

Highp in fragment shaders is an optional part of the OpenGL ES 2.0 spec, so not all hardware supports it (and even when they do, there may be a performance hit). Using mediump will usually be good enough and it will ensure that your applications will work on mobile devices as well.

In practice, if your fragment shader previously started with

precision highp float;

precision mediump float; // or lowp

Comments | permalink