Go read his post Call for Action: The Open Web Needs You *Now*. Or read some of what I’ve excerpted below.

As in the past with IE6, it’s not a question of innovation but a question of hardware market dominance and software bundled with hardware. But there is an aspect of the problem we did not have during the IE6 era: these web sites are also WebKit-specific because they use only “experimental” CSS properties prefixed with -webkit-* and not their Mozilla, Microsoft or Opera counterparts. So even if the browser sniffing goes away, web sites will remain broken for non-WebKit browsers.

In many if not most cases, the -webkit-* properties WebKit-specific web sites are using do have -moz-*, -ms-*, -o-* equivalents. Gradients, Transforms, Transitions, Animations, border-radius, all interoperable enough to be browser-agnostic. Their web authors need only a few minutes to make the site compatible with Mozilla, Microsoft or Opera. But they never did it.

Emphasis mine. As I said in my previous post, a vendor prefix means that the property is in flux, and the syntax of functionality may change radically once it’s finalized and implemented. But here we have this mass of (primarily mobile-targeted) web sites* that are calcifying the web in its current state.

The problem is so bad that, as Glazou says in his post, other browsers will start supporting/implementing themselves the -webkit-* prefix, turning one single implementation into a new world-wide standard. Yes, every major browser vendor, Opera included, will likely implement support for -webkit-* properties.

Save your celebration, son. Your laziness and myopia is what got us here.**. The best we can hope for is that Opera, Mozilla, and Microsoft agree to support the same set of -webkit-* properties, and agree to handle conflicts and cascades the same way.

But what if they don’t? Frankly, either way, we have a hot web development mess on our hands. We’ll either have more of the same proprietary prefix lock-in, or we’ll have a tangled mess of conflicting implementations.

Okay, so what can I do?

If there is any good news, it’s that you can get us out of this mess. Here’s how.

Step 1: Educate yourself about the state of browser support for CSS properties

• HTML5 Please
• When can I use
• www-style@w3.org Mail Archives
• CSS Discuss

Step 2: Use tools to make writing cross-browser CSS3 easier

• David Desandro’s CSS Textmate bundle
• LESS
• SaSS
• Compass
• CSS3 Please
• CSS3 Generator
• CSSLint
• Chris Coyier also has an excellent roundup of CSS pre-processing tools
• Or just write your own script to do it for you†

Step 3: Retrofit your existing code

That’s self explanatory.

Now ideally, you would also test in every browser. But I understand the tradeoffs between market share and time. For what it’s worth, Opera tries to make testing easier with its Opera Mobile emulator. You can also set up an Opera Mini test environment on your own machine. Firefox also offers a mobile emulator. For Android, install the SDK (it’s painless). Pro-tip: You can also run other Android browsers using the SDK.

Let’s not repeat the mistakes of years past in the mobile space. We know better, and we can do better.

UPDATE 1: Check out the Prefix the Web project.

*Having learned the lessons with IE6 sites that are optimized for larger screens are less guilty of this.

**Ever the one for fairness and nuance, I present Ian Lunn’s Vendor Prefixing: Standing Up for Developers.

† This is a PHP snippet that I use from the command line to write individual properties. I use a Mac, so I’m not entirely sure how this would work on a Windows machine. I’m sure it would benefit from a #!/usr/bin/php path or the like for Linux users, but it runs as is for me. Save it as a file anywhere you’d like. Run it using php "unprefixed-property: value".

<?php

$pref = array('moz','webkit','ms','khtml','o');

$str = '';

foreach($pref as $p){
   printf('-%s-%s;',$p,$argv[1]);
   echo "\n";
}

echo $argv[1].";\n";
?>

]]> http://tiffanybbrown.com/2012/02/09/on-mobile-web-development-part-2-stop-building-webkit-only-sites/feed/ 0 http://tiffanybbrown.com/2012/02/07/input-typerange-and-androids-stock-browser/ http://tiffanybbrown.com/2012/02/07/input-typerange-and-androids-stock-browser/#comments Wed, 08 Feb 2012 04:04:56 +0000 tiffany http://tiffanybbrown.com/?p=6629 Android’s stock browser supports the range input type, but in versions 3.x4.x and below (not sure about Android 4.x), it doesn’t actually display the UI.

It does, however, support parts of the Shadow DOM. That means we can style this element, and give our users a visible control.

The image below shows a rather garish green-and-orange version of the range user interface widget. This is after adding some styling, as it appears in the stock Android browser.

And below is the CSS that gives us the above image.

input[type='range']{
    background: #0c0;
    height:10px;
}

input[type='range']::-webkit-slider-thumb{
    background:#f60;
    height:30px;
    width:30px;
    border-radius: 30px;
}

To date, this does not affect Chrome or Safari for the Desktop. ::-webkit-slider-thumb does partially affect iOS Safari. I’ve included an image of what it looks like below (not to scale). Notice that the thumb color changes, but the slider background does not.

This may also affect other browsers that use Webkit such as the Web Browser for S60 Nokia and Samsung’s Dolfin. I haven’t tested it yet, but if you have, please let us know in the comments.

Also keep in mind that this element has a pretty poor user interaction in Android browser. It’s not very responsive, and doesn’t operate all that intuitively. This is true of most mobile browsers, but in my opinion (and based on limited experience), Android is worst of all.

]]> http://tiffanybbrown.com/2012/02/07/input-typerange-and-androids-stock-browser/feed/ 0 http://tiffanybbrown.com/2011/04/06/thoughts-on-practices-for-css-gradients/ http://tiffanybbrown.com/2011/04/06/thoughts-on-practices-for-css-gradients/#comments Wed, 06 Apr 2011 23:35:48 +0000 tiffany http://tiffanybbrown.com/?p=5838 Examples of CSS gradients are cropping up in the wild, and with good reason. CSS gradients:

• don’t require the additional HTTP request of an image file.
• are easier to modify than image files.
• “weigh less” than most image files.

That’s the ideal, at least. In their current state, gradients are actually a hot mess. The reality?

• The specification is still in flux.
• Full gradient support is not available in all modern browsers. (For now, Opera 11 only supports linear gradients.)
• Many older, though relatively recent versions of browsers (Internet Explorer 8 & 9, Opera 10 Desktop, Opera Mobile, and Opera Mini, for example) don’t suport CSS gradients at all.

So, how can developers take advantage of gradients and still support older browsers? Let’s look at some approaches.

Set a background color

Take a look at the following CSS:

#linear{
    width:400px;
    height:300px;
    background-image: -moz-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
    background-image: -webkit-gradient(linear, 0% 0%, 100% 100%, from(#f60), to(#fc0), color-stop(0.5,#c09) );
    background-image: -o-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
}

This is a fairly common scenario. The developer (*cough*me*cough*) covered most of her bases, but forgot one: browsers that don’t support gradients at all. You can see what this looks like in Internet Explorer 9 (see Figure 1).

Figure 1. Internet Explorer 9 doesn’t yet support CSS gradients. This is what it looks like if you don’t supply a background color.

Now look at the following CSS:

#linear{
    width:400px;
    height:300px;
    background-color: #333;
    background-image: -moz-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
    background-image: -webkit-gradient(linear, 0% 0%, 100% 100%, from(#f60), to(#fc0), color-stop(0.5,#c09) );
    background-image: -o-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
}

Here we’ve set a background image, but we’ve also set a background color. Browsers that don’t support CSS gradients will ignore the last three lines. (Note: each browser also ignores the other browsers’ vendor-specific prefixes.)

Setting a background color is the easiest fall back for older / less modern browsers.

Set a background image using an external file

Consider the following CSS.

#linear{
    width:400px;
    height:300px;
    background-image: url(migas.jpg);
    background-image: -moz-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
    background-image: -webkit-gradient(linear, 0% 0%, 100% 100%, from(#f60), to(#fc0), color-stop(0.5,#c09) );
    background-image: -o-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
}

In this example, we’re taking advantage of how browsers apply the cascade. As it turns out, Opera 11, Chrome whatever-the-heck-version-it’s-up-to, and Firefox 4 will not make the HTTP request for the external file. Safari, however, does (see Figure 2). Internet Explorer 9 (and less-modern browsers) will only load the external file. Depending on your audience, this may be an acceptable alternative.

Figure 2. Safari downloads all images. Click to embiggen.

Note: I have just barely tested this in mobile browsers. (Opera Mobile 11 doesn’t support gradients. Users will see the external image).

Use SVG gradients to create a background image

Internet Explorer 9 and Opera 10 (including Mobile) do not support CSS gradients. They do, however, both support the use of SVG images as background images. Another alternative to using external images, then, is to use an SVG file.

#linear{
    width:400px;
    height:300px;
    background-image: url(gradient.gif);
    background-image: url(gradient.svg);
}

This example works in all current desktop browsers, and most mobile browsers. Safari 5, again, will download both images. Most others will download the latter SVG image. The advantages here are clarity and (arguably) ease of maintenance. Want a different gradient? Change the images.

You should be aware, though, that some recent(-ish) versions of mobile WebKit — such as the T-Mobile myTouch 4G browser — don’t support SVG backgrounds. You’ll still need to add a linear gradient for those browsers, or set a background color.

Or keep doing what we’ve been doing

Of course, the growth of SVG and CSS gradients support doesn’t preclude using GIF, PNG or JPG gradients. The biggest point in favor of using bitmap images is that they still work in older browsers and current ones.

As with any aspect of web development, the right approach should balance concerns of maintainability, file size, and the browser distribution of your audience.

You left out linear-gradient!

I left it out of the examples above for two reasons: (1) simplicity; and (2) the syntax could change (though if I had to predict, it won’t change by much). Be forward-thinking! There are very few reasons not to include the proposed linear-gradient syntax in your code.

]]> http://tiffanybbrown.com/2011/04/06/thoughts-on-practices-for-css-gradients/feed/ 3 http://tiffanybbrown.com/2010/09/22/links-for-2010-09-22/ http://tiffanybbrown.com/2010/09/22/links-for-2010-09-22/#comments Thu, 23 Sep 2010 02:51:48 +0000 tiffany http://tiffanybbrown.com/?p=4588

Running scripts in WebKit

WebKit nightly builds now support the HTML5 async and defer script attributes. This makes it easier for web pages to load faster by downloading JavaScript without blocking other elements of the page.

How and Why Chrome Is Overtaking Firefox Among Power Users

Oh snap! Chrome comes out ahead in a recent Lifehacker poll. And oh sniggety snap! Opera comes in with 16.64%. I am a Firefox devotee because of its developer and privacy extensions, namely Request Policy and Better Privacy.

Open Data’s Access Problem, and How to Solve it

Shorter version: ensuring equality of access is key. Also see: Open Data: Empowering the Empowered or Effective Data Use for Everyone?

Build Your First PHP for Android Application

Some fine folks ported PHP to Android, which means that your favorite scripting language can now be used to create programs for your phone.

]]> http://tiffanybbrown.com/2010/09/22/links-for-2010-09-22/feed/ 2 http://tiffanybbrown.com/2010/02/04/on-apples-ipad-html5-and-the-future-of-flash/ http://tiffanybbrown.com/2010/02/04/on-apples-ipad-html5-and-the-future-of-flash/#comments Thu, 04 Feb 2010 06:40:09 +0000 tiffany http://tiffanybbrown.com/?p=3359

So Apple announced the iPad, and it won’t support Flash.

That shouldn’t be a surprise. Neither the iPhone nor iPod Touch support Flash. Indeed most mobile platforms don’t (yet) support Flash. Even the smartest of smart phones have limited processing power and storage space compared to laptops and desktops.

According to Steve Jobs, Apple doesn’t support Flash on its mobile devices because “it’s buggy.” But I’d guess their decision has as much to do with Flash’s capabilities. Many of the products in that cash cow known as the Apple App Store could be developed using Flash instead.¹ Supporting Flash would undermine that billion-dollar revenue stream, piss off iPhone / iPad developers, and also put Apple at Adobe’s mercy.

Besides, everyone’s moving towards HTML5, right? Well yes they are, but not so quickly. I wouldn’t rule Flash out for another 3 to 5 years.

Why do I say this? Four reasons:

1. Flash has inertia on its side. Major content sites such as Disney and Hulu still use Flash to deliver video, animation, and interactive experiences. According to Adobe’s statistics, Flash has over 90% penetration in mature markets. Developers already know how to use Flash and ActionScript to create these experiences. In short: there are a lot of folks invested in Flash as a platform.

2. HTML 5 isn’t quite ready for prime time. It’s a shifting standard, a work-in-progress. Though even Internet Explorer 8 supports some significant HTML5 features, Internet Explorers 6 and 7 do not. And both browser versions are still used widely enough that dropping support is not an option for most developers.²

3. Flash is still the best cross-browser, cross-platform way to serve audio and video. Safari / WebKit, Firefox / Mozilla and Opera all support the HTML5 video element. They do not, however support the same codec.

   Apple is squarely in the H.264 camp. Google paid a licensing fee so that it could include an H.264 decoder in Chrome. H.264 is a patented codec. Any browser that wants to enable H.264 video will need to pay a licensing fee.

   Licensing fees and patent concerns are why Opera and Mozilla are backing Ogg Theora. Ogg Theora is an open sourced codec with no known patents. I should add here that Chrome also supports Ogg Theora. Google, perhaps wisely, chose to include both.

   The big monkey wrench in video element adoption, however, is Internet Explorer. Internet Explorer is waiting for them other fools to work out that default codec business before it implements support for the element.

   And all of this is before we get into the differences in how browser vendors will execute the specification. That’s a whole ‘nother headache.

   We will be using Flash until clients are willing to pay for separate Safari, Firefox and Internet Explorer video integration or until the HTML5 working group agrees on a default codec.

4. Adobe is working to bring Flash to other mobile platforms. As Adobe’s Chief Technology Officer Kevin Lynch explained, We are now on the verge of delivering Flash Player 10.1 for smartphones with all but one of the top manufacturers. This includes Google’s Android, RIM’s Blackberry, Nokia, Palm Pre and many others across form factors including not only smartphones but also tablets, netbooks, and internet-connected TVs. Could the iPhone and iPad’s lack of Flash support be a deciding factor in consumers’ decisions not to buy an Apple device?

My Prediction for Flash

I suspect that as HTML5 gains prominence, Flash will — eff that, it should — shift from an authoring environment for its proprietary SWF format to one that generates HTML, CSS, JS and SVG code for the browser. I think the building blocks for such software are in place. Flash Builder (formerly Flex Builder) for example, eliminates (most of) the need for FLA files. Perhaps developers will one day use a mix of ActionScript and JavaScript in the Flash Builder authoring environment to create web-ready assets and animation that don’t require a browser plug-in.

Mobile-friendly Web Development Right Now

Despite the fact that Flash is supposed to come to every other mobile platform, Apple’s decision to keep Flash off of the iPhone, iPad, and iPod Touch is not without impact. Apple still runs the smart phone market; in some ways they drive the mobile web. That means the prudent path is (still) progressive enhancement, and ensuring that your critical content and navigation are built using HTML.

So will I buy an iPad?

Nope. I have a laptop, a smart phone (a T-Mobile G1), a desktop and an iPod Touch. To me, the iPad is that weird spot between my smart phone or iPod Touch and a laptop with the convenience of neither. It doesn’t have the pocket-sized portability of my iPod Touch or my phone. And it doesn’t (yet) have the robust features of a laptop — USB ports, optical media drives, and the ability to install any app. I can’t justify the value for the price.

Besides, I still much prefer books to e-readers. I can sell books, trade books, leave books, loan books, and get books wet. I am not about to soak in the tub with a $300 device, but I would with an $11 book.

What do you think about the iPad, Apple’s decision, or the future of Flash and HTML5?

¹ Many of these apps could also be built using HTML, CSS and JavaScript, but there’s no money in that either.

² There are scripts available to make IE act right, of course. ExCanvas, for example, mimics support for the canvas element in IE. Simple HTML5 isn’t much different from HTML 4.01. You can actually forge ahead with HTML5 now if you don’t need advanced features like DOM Storage.

Yesterday the folks at Surfin’ Safari announced several new and/or improved features to its Web Inspector. Web Inspector is a debugging tool similar to Firebug and Page Speed or YSlow. These updates will be be available in the next version of Safari. To use them now, install a nightly build of WebKit.

The latest version includes:

• Improved Editing Element Attributes and Style Properties feature
• Ability to create and modify existing CSS rules and selectors
• View colors in short hex, full hex, RGB, HSL or its name (if available)
• Storage monitoring is now rendered in an editable data grid and includes cookie data
• Ajax debugging
• New keyboard shortcuts
• Better support of the Firebug Command Line API

There are several additional features that I haven’t mentioned here. Read the post for a more complete picture.

Critical JavaScript vulnerability in Firefox 3.5

The vulnerability can be mitigated by disabling the JIT in the JavaScript engine. This post tells you how to do so.

3D CSS transforms available in Leopard via WebKit nightlies

The feature was already available in Safari 4 for Snow Leopard, but now it’s available for Leopard as well.