- From: Charles Pritchard <chuck@jumis.com>
- Date: Sun, 08 Apr 2012 15:44:10 -0700
- 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. -Charles
Received on Sunday, 8 April 2012 22:44:34 UTC