On 9/27/2011 10:26 PM, Roland Steiner wrote:
> On Fri, Sep 23, 2011 at 1:58 AM, Charles Pritchard <chuck@jumis.com
> <mailto:chuck@jumis.com>> 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