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

I've snipped the transcript to parts relevant to my top-posted discussion.


We already have web components; there are two shimmering examples on the 
net right now.

1.

First, there's Canvas. Canvas has a subtree, and at some point earlier 
on, it was referred to as the Canvas shadow dom.
In IE9, I can add all sorts of tags into that subtree dom, and they will 
show up in the OS-level accessibility API, with full ARIA support.

It's a great platform for prototyping. It also highlights what I 
consider the most important use case for components:
complex widgets. ARIA 1.0 was an HTML4-aware attempt at enabling authors 
to build complex semantics from simpler ones.

That needs to be taken into account: a component may have multiple 
roles. Consider spreadsheets. That UI-paradigm has
been around a long time. But what are they? They're a combination of 
various components, input boxes, select boxes,
auto-completion, and grids. So you end up with something like this:
<div role="spreadsheet application"><select role="listbox" /><input 
type="text" role="input" /><table role="grid" /></div>

Now that's a very old UI-paradigm, and it's still rather awkward to 
support, semantically.

I've produced quite a few Web Components experiments in Canvas, using 
the subtree. And that leads me onto the second example:
we have select boxes and textarea. Those are components. Just look at 
how well they can be screwed up, look at the issues in IE6 on
styling the select boxes, on z-indexing, and so forth. So fun!

2.
Let's start with existing elements as "use case" examples of Web Components.

My experiments with components began with the <select> element, 
something that, at the time,  was not very flexible.
I needed to make sure the DOM was accessible; ARIA is sure a big help 
nowadays. I needed to make it re-usable.

Let's start with the easy ones, the items that are already implemented 
and documented.
http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/

Here's one:
input[type=range]::-webkit-slider-thumb

It's a great example of an area where ARIA 1.0 does not have -enough- of 
a vocabulary. ARIA contributors worked
within HTML4 to define how an author might create new UI components from 
existing ones.

We have an opportunity now to document the sub-elements of single form 
controls.
Until we can express what existing form controls do, I see no compelling 
case to leap forward and try to express new components.

It does seem plausible that these selectors, in context, can unify CSS 
Element names and DOM Element ids.

The author of the component could use document.getElementId(), the 
component consumer would use css selectors:
<div role="slider input" id="range"><span id="-webkit-slider-thumb" /></div>

If the author is trying to target a UA that does not support components, 
they'll probably want to use more rugged
element selectors, so they can copy and paste their code.



3.

TL;DR: Canvas subtree is a real-world example of shadow dom semantics, 
though parts of the rendering tree are handled in script.
CSS pseudo-selectors for form elements are a functioning example of 
component re-use.


-Charles




On 9/20/2011 4:59 PM, Dominic Cooney wrote:
> dg: wanted to implement XBL2, 2 years later, slightlyoff (dojo) had
> different proposal--simple web components. 1 yr ago post to webkit-dev
> about components. XBL2 seems nice because it is a written spec. What's
> the shape of the problem? See whatwg wiki Component_Model (MSFT
> indicated some interest at least)
>
> GOAL: Make sure everyone understands the problem we're trying to solve.
> GOAL: Get feedback on the way to solve the problem.
> GOAL: Get specific ideas.
>
> Methodology:
> 1. Come up with a set of use cases that capture what you want to accomplish.
> 2. Study use cases come up with a set of properties.
> 3. Design building blocks that cohere with desired properties.
> ... see the wiki ... Component_Model_Methodology
>
> Our use cases: Let the things that are happening on the web already
> and in web browsers already happen in a more natural fashion. A lot of
> JS frameworks do a lot "wrong" (a lot of crap
>
> sam: what is success?
>
> dg: can accomplish the use cases. Flow from use cases to
> properties. Properties are orthogonal to each other. Building blocks
> satisfy properties.

>
> boris: in +1/Like buttons you include some script and then write a tag
> name, so if you could have the page do the registration maciej:
> register and specify a tag name and a url which does something (ie
> registration) although you could have scoped names maciej: alpha
> renaming of component names

...

>
> dg: we may have not produced use cases yet that cover this well ...
>
> hyatt: form controls!

...


> maciej: do you have any way when you subclass something to copy its
> shadow DOM?
>
> slightlyoff: it is just a lifecycle; you can call methods or not and
> do what you want.

...

>
> sicking: why do you need to use the parent class' shadow tree? maciej:
> what if I want to create a subclass of textarea that has the parent's
> textarea and have some extra buttons rs+dg: just use composition
> hyatt+maciej: you end up having to write a lot of forwarding dg: but
> you only need 5% of that glue sam+maciej: if you want to create a
> component that is a drop-in replacement for textarea then you have to
> do all of the forwarding, so if you do subclassing you can't subclass
> any nontrivial behavior

...

> slightlyoff: Our intent was to heal the rift between DOM and
> JavaScript.
>
> boris: You want to solve the problem of passing an extended object
> like canvas+behavior to the DOM and have it treated like a canvas.
>
> maciej: This design can subclass div or p, but not textarea, which is
> a weird place to draw the line.
>
> slightlyoff: The only reason you need forwarding is when a generic
> mixin won't do what you want.
>
> boris: most of this is implementation details.
>
> maciej: having to lock down the structure for every form element. If
> you have a future OS that has a completely different look.
>
> boris: we added a resizer element to textarea so the shadow tree changed.

...
>
> maciej: examples are useful; usage examples; patches to see how the
> details work internally. Writing up in much more detail how these
> pieces work. Doesn't necessarily need to be to spec level of detail
> and precision.
>

Received on Thursday, 22 September 2011 16:59:30 UTC