On 9/27/2011 10:26 PM, Roland Steiner wrote:
On Fri, Sep 23, 2011 at 1:58 AM, Charles Pritchard <[email protected]
<mailto:[email protected]>> wrote:
[...]
We have an opportunity now to document the sub-elements of single
form controls.
That is certainly a very valid goal. For example, it would really be
great if an author could create his/her own video element and be able
to re-use parts of the built-in <video> controls. One way could be to
assemble larger components from smaller ones, and make those
accessible to derived components.
However, getting all vendors to agree on a unified set of controls and
layouts for the various form and media elements will certainly take
time, and IMHO is only possible when the need for such arises.
I'd like to start with HTML forms. I'd like to start with the controls
that have already led to css attributes.
Think: -moz-appearance, -webkit-appearance.
We're discussing how authors may generate components: let's look at how
vendors -already- generate and style components.
This document right here, showing webkit CSS definitions of HTML
components is fantastic:
http://trac.webkit.org/browser/trunk/Source/WebCore/css/html.css
That document is easy to read and defines how WebCore displays HTML
components.
It's been made compact, for efficiency, so selectors are grouped
together, which hinders
readability, a little. But, it does show all sorts of selectors.
That document shows web components, with various elements exposed as
needed by WebKit vendors.
Other examples of components, which, despite controversy in the specs
process, still stand:
http://www.webkit.org/blog/363/styling-scrollbars/
https://developer.mozilla.org/En/CSS/%3A%3Aselection
Defining a new HTML component:
http://trac.webkit.org/wiki/Styling%20Form%20Controls
Until we can express what existing form controls do, I see no
compelling case to leap forward and try to express new components.
This I don't agree with. Authors currently can and do use various
frameworks to create what are essentially components, e.g., layout
managers - undaunted by the fact that the internal structure of, say,
<input> isn't specced out.
Yes, they can use ARIA 1.0 to mark up those frameworks; they can use
semantic HTML, and they can use polyfill methods.
I did not express myself well: I'm happy to see authors experiment, and
I'm happy to see discussion. I don't want that to stop.
But for spec editing, use cases and browser vendors, focus should be on
HTML 3.2 Forms.
It does seem plausible that these selectors, in context, can unify
CSS Element names and DOM Element ids.
I think that will be possible only in the simplest of cases. For more
complex components I don't think there necessarily will be a 1:1
mapping of a pseudo-element name to an actual element.
I'd like to focus on the simplest of cases: HTML Forms.
From there, we might find standard means of building more complex
components.
Whatever complexity I end up with, I can always decompose it back into
basic HTML forms.
Any value can be expressed in <input type="text">.
And semantically, I can always do: role="x-my-custom-role input"
-Charles
