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.
