W3C home > Mailing lists > Public > public-webapps-ui@w3.org > April 2012

Engaging scaling in an unstyled HTML5 checkbox

From: Charles Pritchard <chuck@jumis.com>
Date: Sun, 08 Apr 2012 15:44:10 -0700
Message-ID: <4F8214BA.7020106@jumis.com>
To: public-webapps-ui@w3.org
One of the more frustrating items I've encountered recently is the 
rendering behavior of <input type="checkbox" />.

On public-canvas-api we endured some long arguments about the merits of 
native widgets v. widgets managed by the scripting environment. The crux 
of the conversation was that authors ought to be using native widgets, 
and relying on browser vendors to get things right. Much of the 
conversation veered off into the extremes of text layout, such as <div 
contentEditable />. To move the conversation forward, and re-assert our 
use cases, I redirected attention back to the lowly <input 
type="checkbox" /> element. It's now accepted that <canvas><input 
type="checkbox" /></canvas> is a valid use of Canvas. It took us a few 
years to get vendors on-board with this.

Here I am, no longer working full-time in Canvas, but still trying to 
write quality applications and support a flexible UI.

This works well in Chrome Windows:
<input type="checkbox" style="width: 2em; height: 2em;" />

It does nothing of value in OS X. It just doesn't zoom.

In OS X, we need to use a scale+zoom combo:
<input type="checkbox" style="zoom: 2; -webkit-transform: scale(2,2);" />

In OS X, the transformation and zoom work neatly together. In Firefox, 
we can use transform, but we encounter low quality rasterization, as the 
pixels are scaled up.

Note that "zoom" itself is not a particularly welcome CSS semantic.  
Yet, we may encounter an issue in the future with Web Components, where 
zoom once again becomes necessary; transform being only have of the 
needed declaration.

We do find a working semantic in more browsers by re-implementing the 
rendering of checkbox through CSS selectors, using the 
"-webkit-appearance: none" semantic, and redefining the border and 
content of the checkbox. What a pain.

As developers, we often program defensively. The current crop of 
browsers has ever-more features and ever-more mistakes in implementation.

I simply wanted to use an unmodified pairing across vendors:
<label /><input type="checkbox" />

I'm sorry to report that authors writing complex web applications must 
use complex techniques on native widgets simply to maintain a baseline 
of compatibility.
Native widgets can work well for event handling, accessibility, and for 
fail-safe / fall back presentation. Otherwise, web app authors should 
consider the rendering of native widgets as unstable and a last-resort.

I'll be working this month to establish a compatibility and bug table 
for <input type="checkbox" />.
I'll then explore <button><input type="checkbox" /></button>; and other 
aberrations of HTML semantics.

Received on Sunday, 8 April 2012 22:44:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:34:07 UTC