W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Web Components use cases, was Re: Notes from a component model pow-wow

From: Charles Pritchard <chuck@jumis.com>
Date: Wed, 28 Sep 2011 09:40:01 -0700
Message-ID: <4E834DE1.1070105@jumis.com>
To: Roland Steiner <rolandsteiner@google.com>
CC: Dominic Cooney <dominicc@chromium.org>, WebApps WG <public-webapps@w3.org>, Dimitri Glazkov <dglazkov@chromium.org>, Sam Weinig <weinig@apple.com>, Maciej Stachowiak <mjs@apple.com>, Boris Zbarsky <bzbarsky@mit.edu>, David Hyatt <hyatt@apple.com>, Jonas Sicking <jonas@sicking.cc>, James Robinson <jamesr@chromium.org>, Alex Russell <slightlyoff@google.com>, peterv@propagandism.org
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:

That document is easy to read and defines how WebCore displays HTML 

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:

Defining a new HTML component:

>     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 

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"

Received on Wednesday, 28 September 2011 16:40:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:24 UTC