Tiffany B. Brown » Web Development & Programming

On Mobile Web Development, Part 2: Stop building WebKit-only sites

tiffany — Thu, 09 Feb 2012 16:03:24 +0000

Following-up on my mobile web development post from last week, we have Daniel Glazou, co-chair of the CSS Working Group outlining the scope of the -webkit-prefix problem.

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

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"

Looping video in browsers that don’t yet support the loop attribute

tiffany — Tue, 04 Oct 2011 10:00:43 +0000

To date, Firefox does not yet support the loop attribute of the element. This snippet is a simple work-around. Once the video’s ended event is fired, it calls the play method.

For more, consult the media events section of the HTML5 specification.

XHR2 + CORS Slides, some AppCache-fu, OpenWebCamp, and Opera News

tiffany — Fri, 01 Jul 2011 01:00:49 +0000

For the June meeting of the HTML5 & CSS3 LA User Group, I spoke about XMLHttpRequest, Level 2 and Cross-Origin Resource Sharing headers. It’s always tough to present code. That goes double when you are sleep deprived, yet caffeinated and tongue-tied.

In any case, the slides — which is really just one really long, really heavy HTML file with inline CSS, JS, and images (thanks, data URIs!) — are now available.

Data URIs have been available for quite a while now, though Internet Explorer versions 5-7 don’t support them. They are string representations of file data, typically base-64 encoded. When used as an img or url() source, they reduce the number of HTTP requests. And as we know, making fewer HTTP requests is the number 1 rule of web site optimization … except y’know when it creates a 1.8MB HTML file .

It’s simple enough to convert files to a base64 encoded string with a few lines of code. Let’s assume we want to convert a file named “cars.png.” In PHP it might looks like this:

$filename = 'cars.png';
$ext = pathinfo($filename,PATHINFO_EXTENSION);
switch($ext){
     case 'gif':
          $type = 'image/gif';
          break;
     case 'png':
          $type = 'image/png';
          break;
     case 'jpeg':
          $type = 'image/jpeg';
          break;
}
$fileHandler = fopen($filename,"r");
$data = fread($fileHandler, filesize($filename));
print 'data:'.$type.';base64,'.base64_encode($data);

Despite the ginormous HTML file, I still think it’s useful for it to be a single-file package. After all, you only have to save and keep track of that one HTML file.

Application Cache

Bonus: you can view it offline because I took advantage of Application Cache.

Application Cache is an awesome technique that can speed up load times by caching data locally. But it also ensures that if connectivity is lost or unavailable, you can still visit that URL and have access to the content. This assumes, of course, that you’re using a browser that supports AppCache. The latest versions of most major browsers, including Opera 11+, do.

Application Cache is also quite simple — at least the basics of it are. First, add a manifest attribute to your element.

Then create a manifest file. It’s a simple, plain text file that must be sent with a Content-type: text/cache-manifest header. Typically the file name should have an .appcache extension, though it will work (for now, at least) if it’s named foo.manifest provided you send the correct content type header.

A basic manifest — the one I’ve used for the slides in fact — looks like this:

CACHE MANIFEST

CACHE:
index.html

That’s it. We have told our browser to cache this page. You can also specify which files the browser should always retrieve from the server with NETWORK, or which files to use if you need to fall back. It’s fascinating stuff. For more, check out HTML5 Doctor’s post, Go offline with application cache.

I’ll be at Open Web Camp!

I’ll be speaking more about AppCache and other things at Open Web Camp July 16 at Stanford University in Palo Alto. Come say hi.

Opera news, in case you missed it:

Opera 11.50 was released Tuesday
Opera Mini 6.1 and Opera Mobile 11.1 were released yesterday (6/29)

I’m most excited that the Opera Mobile rendering engine is now running Presto 2.8 which means it now supports multi-layouts (we run on tablets too!), session history and navigation, and the File API (among other things).

Check me out: Modern debugging tips and tricks

tiffany — Wed, 08 Jun 2011 14:17:56 +0000

Yesterday my first piece for A List Apart went live: Modern Debugging Tips and Tricks.

It’s an overview of using the JavaScript console that’s now available in every modern browser, and doing remote debugging using Opera Dragonfly and JS Console.

On URL design

tiffany — Thu, 06 Jan 2011 19:07:51 +0000

Namespaces can be a great way to build up a pragmatic URL structure that’s easy to remember with continued usage. What do I mean by a namespace? I mean a portion of a URL that dictates unique content.

One of Kyle Neath’s tips from his post URL design.

This. URLs make your site more usable, navigable and extensible, particularly when your site is a RESTful application.

[Via Jeremy Keith]

Why ActionScript 3.0 should be your first programming language

tiffany — Mon, 23 Aug 2010 15:00:58 +0000

Last week, a Twitter friend asked about learning programming and where to start. I suggested ActionScript 3.0, but 140 characters isn’t enough to explain why. That’s what blog posts are for.

ActionScript sounds like a weird choice, right? It’s client-side, not server-side. You can’t connect to a database or create files on the fly without some sort of middleware. And why would I suggest that budding programmers learn a dying language? HTML5, CSS3, and JavaScript are going to (eventually) take over the world, right?

That stuff is true, or will be in the near term. Yet I still think ActionScript 3.0 is worth learning, and that it’s a great starter language for budding developers. Here’s why.

ActionScript 3.0 is syntactically similar to other C-style languages. Curly braces rule! Semi-colons are awesome! Getting comfortable with how AS3 looks and works will make PHP or Java less intimidating.
ActionScript 3.0 is strongly-typed. Strongly- (or strictly-) typed languages enforce rules for variable behavior. It’s particularly useful when debugging, and will help you understand what different variable types are and how they work across languages.
ActionScript 3.0 is Object oriented. Objects are at the heart of several programming languages, and supported in several more. Getting comfortable with how OOP works in AS means it is easier to understand how it works in JavaScript, Ruby, PHP, and Java. In fact, ActionScript is in some ways similar to Java in how it’s structured.
ActionScript 3.0 is a dialect of ECMAScript. So is JavaScript. It’s remarkably easy to switch between the two, which brings me to my next point.
ActionScript 3.0 and Flash documents have a Document Object Model (DOM). Think of a Flash FLA as an HTML or XML document and ActionScript as the JavaScript that manipulates it. If you’re comfortable working with ActionScript objects and hierarchy, learning how to manipulate the HTML DOM is a breeze (and vice-versa).
ActionScript 3.0 supports Local Shared Objects, which is similar to HTML5 storage, and other key-value based datastores. Yep. Local storage “super cookies” have been available in Flash for years now. Learning how to use them in Flash and ActionScript will help you transition to an HTML5 future. What’s more, key-value datastores are the next wave of databases. The data structure for a “NoSQL” store is similar to those for a local shared object.
ActionScript 3.0 supports event-driven programming. Event listening and handling is critical to game development or interactive experiences in which the sequence of user input can’t be (or shouldn’t be) controlled. Knowing how to generate, add and remove elements from the stage, or when an item can be safely garbage collected are portable concepts that you can learn with ActionScript.

My point with this post isn’t to start a language holy war. I’m not even sure I like ActionScript, plus my first programming language was actually PHP. Still I recognize that the way ActionScript works and as importantly, how it’s used provides a nice foundation for beginning developers.

The HTML5 video progress event: Redux

tiffany — Tue, 06 Jul 2010 22:14:58 +0000

In my first post on HTML5 video and its progress event, I wrote:

Only Firefox provides a means to calculate the amount of the video that has been loaded. The progress event object includes total and loaded properties that reflect the total size of the video file, and the amount the browser has retrieved from the server. This is also a reflection of how each browser handles video downloads.

Erm, that’s only sort of true. As zcorpan explained in the comments, the latest version of Firefox implements an old version of the specification.

In the most recent version of the HTML5 spec, the total and loaded properties of the progress event were removed and (mostly) replaced by the video.buffered property.

So while Firefox 3.6.x is still the only browser that provides total and loaded properties in the progress event, the latest revision added a new property to the video element that works similarly — note the emphasis on ‘similarly.’

What’s the difference? Both the total and loaded properties of the progress event express the download’s progress in terms of bytes. The video.buffered property expresses the download’s progress in terms of seconds. They’re similar in that you can determine the status of a download, but using seconds instead of bytes is more relevant for seeking within a timed media file.

By checking video.buffered.end(), we can determine how many seconds of the video are available to the browser and provide the relevant error handling (if a user seeks too far) or interface changes (such as a loading progress bar).

I am still learning how the video.buffered property works, particularly in conjunction other properties and events of the video object. I will post more about this later.

One thing to remember: Firefox has not yet implemented the video.buffered property. It is only available in Safari, Chrome and (sort of) in Opera (still learning the ins-and-outs). (And Internet Explorer doesn’t support the video element at all, though version 9 should when it’s released.)

JavaScript tip: Use a for-loop to reveal properties and methods

tiffany — Tue, 29 Jun 2010 22:27:34 +0000

I’ve been tinkering with the HTML5 video element quite a bit lately. However, it’s not the best-documented thing in the world. There are very useful properties in the video element’s events that aren’t so clearly explained in the spec. Developing a media player means you have to uncover these properties using a little bit of scripting know-how.

Luckily for us, there is a very easy way to reveal the methods and properties of just about any element in the DOM. Experienced JavaScript developers probably know this. It’s possibly one of the most useful things you can know about using JavaScript: use a for-loop to reveal an object’s unknown properties and methods.

Let’s assume you have a div with an id value of “test.” Let’s also assume that you have Firebug, for Firefox installed (and enabled), or that you have enabled developer tools in Safari (this may work with Opera‘s Dragonfly as well).

To find out the properties and methods, for “test,” you would use the following code:

var p; // initialize this variable.

var testElement = document.getElementById('test');

for(p in testElement){
     console.log( p +': '+testElement[p] ); // using array notation for objects, which works just fine.
}

In Firebug, the output will look a bit like this:

That’s a list of every property and every method — and whether or not it’s a native part of the DOM (as supported by the browser) — available for this object.

Similarly, you can do the same thing with an event. Consider:


function clickHandler(evt){
      var p;
      for(p in evt){
            console.log( p+': '+evt[p] );
      }
}
testElement.addEventListener('click',clickHandler,false);

The code above would reveal all of the properties of the event listener (note that in Internet Explorer, you would use the attachEvent() method). This is how I learned that in Firefox, the progress event of the video element contains both “total” and “loaded” properties — which will come in handy for creating a loading progress display.

Now if you don’t use Firefox with Firebug, Safari (or Opera), you can also output the data to a

in your HTML page.

Increment and decrement, prefix and postfix

tiffany — Fri, 18 Jun 2010 20:00:05 +0000

I created this example of the increment (++) and decrement (--) operators in action because I needed to see how they work in combination.

I tested this example in Firefox, Safari, and later versions of Internet Explorer, but it probably works in Opera and Chrome as well.

Links for 2010-05-17

tiffany — Mon, 17 May 2010 20:55:51 +0000

Two web development links for your enjoyment.

FormData interface coming to Firefox: An overview of the FormData object of XMLHttpRequest, and how you will soon be able to use it in Firefox. From Hacks.Mozilla.Org.
Dealing With the Dreaded ‘Flash of Unstyled Text‘: Tips for mitigating, even eliminating the appearance of unstyled text when using @font-face. From Webmonkey.com.

To password mask or not password mask?

tiffany — Tue, 09 Feb 2010 17:00:20 +0000

That is the question Jakob Nielsen sparked with last summer’s column: Stop Password Masking. In this week’s A List Apart, Lyle Mullican discusses The Problem with Passwords, and writes:

However, making such a sweeping change to a fundamental user interaction could present serious problems. Consider some contexts in which a password might need to be entered in front of a large group of people, such as while using a conference room projector. And many years of web experience have set user expectations on how form elements should work. People understood that password masking was invented for their security. Failing to meet that expectation might undermine confidence, and we cannot afford to lose our users’ trust.

I agree with Nielsen here, and suggest that if you need to enter a password while using a conference room projector, you should have logged-in before your presentation.

Password masking prevents users from making sure the password is correct before sending it to the server. If you, like you should and I do, pick long, hard-to-guess passwords, an unknown mistype can be a source of frustration.

Password masking also provides a false sense of security, particularly on unencrypted connections. Sure it prevents a person peeking over your shoulder. But it doesn’t stop her from watching you type it on a keyboard. Nor does it stop someone from intercepting it with a packet sniffer if the password is sent as plain text.

In other words: password masking is a bad convention.

So what’s the answer? Password unmasking — a toggle that allows users to choose whether or not to show the password. It’s a fairly recent convention that’s become widely used for WiFi set-up screens. Jeremy Keith described one method of password masking last summer. Mullican covers a similar technique in his A List Apart piece.

Proposed File API specification

tiffany — Thu, 10 Dec 2009 15:15:35 +0000

Web applications should have the ability to manipulate as wide as possible a range of user input, including files that a user may wish to upload to a remote server or manipulate inside a rich web application. This specification defines the basic representations for files, lists of files, errors raised by access to files, and programmatic ways to read files. The interfaces and API defined in this specification can be used with other interfaces and APIs exposed to the web platform.

From File API working draft by Arun Ranganathan of Mozilla Corporation.

This API, if adopted by major browser vendors will allow client-side file manipulation and asynchronous uploads.

As far as I know, asynchronous uploads are only possible now using a combination of Flash and JavaScript such as SWFUpload. Flickr’s uploader uses a similar technique. Client-side file processing is impossible without a plug-in.

Flash Player Errors and How to Fix Them

tiffany — Fri, 04 Dec 2009 15:15:40 +0000

Trevor McCauley posted two new tutorials today about Flash Player Errors and how to fix them. One covers runtime errors, or errors that occur while a movie is playing. The other covers compiler errors or errors that occur while developing and testing a movie.

If you’re not using it already, may I suggest using Flex Builder as your ActionScript 3.0 IDE? It provides better debugging that Flash itself does. And you can use it with Flash assets by creating an SWC.

Also see: Debugging Flash applications with Firefox extensions

Yes, you really do need to learn JavaScript

tiffany — Thu, 03 Dec 2009 16:20:03 +0000

From Ed Finkler‘s PHP Advent 2009 piece, You Really Need to Learn JavaScript:

When I say “you need to learn JavaScript,” I don’t mean “learn how to copy and paste an example,” or “learn how to generate JavaScript with PHP.” I mean learn it as well as you already know PHP — or better.

Why? Because JavaScript drives rich clients, and all indications are that clients will be getting richer. You won’t be able to get away with just adding small snippets of JS to add tooltips and simple animations. Complex processing and UI management will require real knowledge of how to write JS, and how in [sic] interacts with the client’s APIs — the DOM, local storage, networking, OS features, and more.

And I will add: not jQuery, not MooTools, not Dojo, but real, actual, JavaScript (and DOMScripting). Finkler tells you why and points you to some resources for learning more.

Big Boston Warmup: Interactive Infographics done well

tiffany — Fri, 13 Nov 2009 15:23:48 +0000

Via @gsetser: The Big Boston Warm Up, an infographic presentation whose goal is to get you to donate a coat and help keep homeless people and families a little warmer this winter.

The experience begins on the home page with a series of graphics that show the circumstances of Boston’s homeless. It’s a broad demographic profile, which is far less effective, in my opinion, than homeless people in their own words. But I can understand the logistical and ethical concerns of featuring videos of homeless people.

In addition to data about Boston’s homeless, the site includes donation locations both in Boston and nationwide. To further spur you to donate, Land’s End (the company behind this coat drive) points out that coats go to local homeless people. If you donate a coat in Alabama, it goes to a person in Alabama.

But I think the best piece — the part that lets you really feel like you and your donation have made a difference is the “Find Your Coat” feature.

Yup! Donate a coat, get a number and find out where your coat has gone. I don’t have a code, so I can’t tell you what it looks like on the other side. But I am curious to find out. It’s this tangible tie-in — one that piques curiosity and interest if you haven’t donated, and rewards you with warm fuzzies if you have — that makes this campaign (potentially) very effective.

Site by: Firstborn.