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

[Charles Pritchard]

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:
type="text" role="input" />


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  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:



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 glu

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

[Roland Steiner]

On Fri, Sep 23, 2011 at 1:58 AM, Charles Pritchard  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  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.


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,  isn't specced out.


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.


Cheers,

- Roland

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

[Charles Pritchard]

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

And semantically, I can always do: role="x-my-custom-role input"

-Charles