- From: Doug Schepers <schepers@w3.org>
- Date: Wed, 07 Apr 2010 01:17:31 -0400
- To: Shelley Powers <shelley.just@gmail.com>
- CC: Jonas Sicking <jonas@sicking.cc>, Maciej Stachowiak <mjs@apple.com>, HTMLWG WG <public-html@w3.org>
Hi, Shelley- Shelley Powers wrote (on 4/6/10 11:21 PM): > On Tue, Apr 6, 2010 at 9:58 PM, Jonas Sicking<jonas@sicking.cc> wrote: >> On Tue, Apr 6, 2010 at 7:33 PM, Shelley Powers<shelley.just@gmail.com> wrote: >>> If there was interest in doing this before, why is only now people are >>> asking these questions? >> >> If I understand your question right, in large part nothing has >> happened in this area in the past because W3C stopped development of >> HTML after the release of HTML4. >> > > Jonas, I know the history of the WhatWG effort. It started with Web > Forms 2.0. These web elements were not added to the spec a couple of > months ago. They've been in the spec for years. The datetime input > element type was added to Web Forms 2.0 by a group of Opera, Mozilla, > and Apple folks in a private email list over six years ago. > > So, folks knew that these issues were going to arise at some point. > And since these elements didn't arise in HTML4, I'm not sure why it > would be pertinent to the current situation. I suspect the reason it hasn't been discussed before is that there are an unlimited number of things we can do to improve the Web platform --a list of things that grows and changes rapidly-- and a limited number of people to specify and implement them... and those people often disagree about what the right thing to do is. Sometimes you have to step back and take a holistic look at the platform and identify what's missing, and what has changed in priority. Though I differ with your conclusions, I think your questioning of these new form controls has helped highlight an important issue... how do we style these elements and their pseudo-elemental components? I think that a careful examination of the common constituents of these controls would give a lot of power to designers while still allowing for innovation by browser vendors in rendering them. For example, you showed 2 different styles of slider, one with tickmarks and a rectangular thumb and the other a simple bar with a round thumb; a designer could still change the color of the thumb and bar (and maybe things like rounding of corners) and specify the color of tickmarks if they happen to be present on that platform (or to hide them if they so choose); I alluded to this in my earlier email that kicked off this topic of styling native controls [1]... if no tickmarks are normally rendered, that pseudo-element rule simply won't be applied, and that's okay. It may have occurred to me more readily because, like a lot of people in the SVG developer community, I've been rolling my own SVG controls for a decade or so, in several different libraries, where each component (slider bar, thumb, tickmark, labels, etc.) is a distinct element, and thus easily styled. People who create HTML equivalents out of <div>, <p>, etc. have a similar experience, I imagine. I see ARIA as a real boon for these custom controls, especially in SVG where we never intend to have native form controls, but I see equal need for CSS to afford native controls the same kind of stylability (and I'm glad to see that some browser implementers and CSS WG folks are amenable to that). [1] http://lists.w3.org/Archives/Public/www-style/2010Apr/0076.html Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Received on Wednesday, 7 April 2010 05:17:38 UTC