<anne> scribe: weinig

Overview

dg: We are starting with an overview and demo
... [looks for dongle]

ar: We are working on an imperative model that allows subclassing HTML Elements
... We are working on a declarative form, but it is not ready
... [gives a demo]
... In the demo we are creating an idiomatic JavaScript class that subclasses from HTMLElement
... the class is registered as an extension, must start with x-
... this plugs into the parser to add your own element types

travis: would you subclass from Node

ar: that wouldn't make much sense, you really need to subclass HTMLElement

yehuda: can you subclass HTMLInputElement

ar: that would be hard, since we would have to define the shadow DOM for form controls for all browsers
... it might make sense to only inherit from HTMLElement

yehuda: what about span?

ar: span is just like HTMLElement
... another aspect is the Shadow DOM, from XBL
... any element should be allowed to have a shadow DOM

travis: CSS has generated content, how is this different

ar: generated content has certain restrictions, just before and after for instance

yehuda: can shadow DOM listen for new events

ar: [notes that events will work]
... using the shadow dom, you could use canvas as the rendering, while still having the DOM
... shadow DOM is conceptually different, and can be specified seperately
... [notes in demo that subclassed element has multiple parts, though only one real child in the DOM]
... many complicated components suffer from "div soup" today, and shadow dom helps this
... shadow DOM is created using ShadowRoot constructor
... shadow DOM API allows you to set a content element

dg: content element gives you an insertion point
... it also doesn't effect the DOM, only the layout

dc: a good example is <details>
... with <summary>
... [draws disclosure triangle UI]
... details would have a shadow DOM with an image for the disclosure triangle
... <summary> will be forwarded to content elements in the shadow dom
... content elements get chosen in document order

ar: this is all about creating HTML element subclassing
... [shows using subclassing of HTML Elements using ecmascript 6 syntax]

js: Why is ShadowRoot a new node type?
... Why not use element

ar: we consider it like a document fragment
... unlike HTCs, this is not a new document

js: adding a new node seems like a big deal
... XBL just uses a template element

ar: I would be ok with that, since shadow root combines both creating the root and attaching it

dg: we originally just wanted to use document fragment
... the shadow root never renders
... dominic thinks we should only render the shadow root
... then do css magic

dc: we want innerHTML to work, so we don't use document fragment
... if shadow root are elements, we would probably want to not replace the children, but rather the element it is the shadow of

rs: one question is how does styling the host element effect shadow content

ar: we think that starting with subclassing just HTML elements is a good start
... form serialization is something we should allow through a protocol that any element can implement

<anne> Hixie: is web controls still up?

<anne> http://www.whatwg.org/specs/web-controls/current-work/

ar: the component model is helping us flesh out what problems remain in the web platform

<anne> nothing much there

ar: yes, you could describe implementations using this, but we don't want that right away
... one thing we should discuss is what is needed from the declarative model

macrus: I was part of the team that made HTC

marcus: we took the opposite approach, with the declarative model first
... what are the hurdles

ar: we are thinking about and <element> element

yehuda: I found the declarative part of XTC the most confusing
... may have been documentation

yehada: may have been my background as a web developer

ar: [types on the screen]
... what happens when we are loading the webcomponent and the unknown elements are parsed
... one problem is that doing it after the fact is that people may have references to the unknown elements already
... we would have a "becomes" event

someone: why not sync

everyone: sync is bad, no one likes sync

anne: another options is to make it like html manifest
... that solves the source order (unknown element before <link>) but not loading issue

js: changing elements in place seems bad

ar: we are not doing that
... the "becomes" events will create a new element, and the old one gets yanked out the tree

[lots of yelling]

anne: the new element will actually be created before the event

js: it doesn't matter if the element is in the document
... we can fire events on all elements

ar: [is showing stuff on a projector]

<heycam> Scribe: heycam

ar: [explains how the proposed declarative syntax maps to js]
... we use <template> because we'd like to introduce that in the model-view proposal as well
... this template does not run script
... it doesn't have side effects, network requests

dg: template would be a really useful chunk to have without shadow dom or component model

ar: through <link> you can importa a definition
... <link rel="webcomponent href="comment.html">
... what if you want to declare that some attributes proxy to an internal implementation?
... so that you can do a +1 or Like button that has access to cross origin resources
... all these things are same origin in this world so far
... but I think we can come up witha declarative syntax where you can define your attributes, script runs in the cross origin context, and postMessage is used between them

dg: it could just be an attribute on <link> "confine"
... instead of introducing the definiton into the document, it instead introduces proxies for these elements
... then you could have a real live thing that has a synchronous api to a cross origin iframe e.g.
... that looks like your component but exists in a separate document
... it would just work

ar: the primary impetus for this system design is that when building large scale apps, we want to use DOM as the primary retained mode API
... we write declaratively the template, and use script to modify later

yk: seems good, but i'd like to play with it to give feedback

ar: haven't provided builds yet, but it's on our todo list

yk: i think it woud be valuable to get people to try to build something with it

js: the element element needs the ability to have declaratively not xbl1 declarative style but something where you can define an api

ar: if you have a special script type, to prevent it from being executed otherwise...

[ ar puts <script> inside <element> ]

dg: in the script, "this" would not be window, it'd be the element

ar: you've define your own Constructor name in an attribute, but instead if you use <script> in there you'd just use the name of the function/class you declare in there

yk: don't want it to conflict with the extends="" you specify either

js: one of the things that's nice about xbl1/2 is the ability to have purely stylistic bindings attached with css
... a shadow dom that's generated and which you can put two borders instead of one for example

ar: i think the css style of attachemnt is desirable

<ArtB> Meeting: Component Model Gathering @ TPAC

ar: you can think of tagName as a css property you're matching against
... one thing to worry about is applying/unapplying templates

js: i don't think css-attached bindings should allow defining api
... a trivial example in css is you can't have a two bordered element

dg: we had this discussion, spent a bit of time, any time you step into decorators it's a pit of despair
... the problem is simple
... decorators should have no non-local effects
... constrained to that, there's little interesting you can do
... maybe css should just handle this use case

js: i think css should be able to do it, and by using this syntax
... you'll also need <content>
... you'll want to have a <style> element too, so you can attach scoped style

ar: that's not missing, it's in the <template>

js: i don't see why we couldn't use the same shadom dom for this
... we can allow behaviour, but just not api
... if all you want to do is change style, why would you want to add api?

ar: why would you want to add event handlers?
... if I can script the object from event handlers, the horse has left the barn

dg: if you don't get that object, then there's nothing interesting you can do
... that's why xbl2 is so hard
... because there's nothing you can take away forom it

js: xbl2 has a problem with binding/unbinding
... from a js point of view, any binding that is attached is done at creation time and never detached

ar: there is an additional step we'd like to propose
... it's an orthogonal problem
... we can accept something like MS's watchSelector proposal, and build on that

js: i want to do something not scripted
... you might have a specific css property type that desugars to watchSelector
... and then have a shadow for the shadow, or a pseudoshadow
... if an element has a shadow and you want to compose it with another, for example a parent, then you have two levels of shadow doms
... you need to define how it flattens
... your'e saying i can't extend the api?
... which is the constraint you need to enforce if you want to allow detachment
... at that point, why not allow detachment?

dg: if you are applying with css, you need detachment

js: i don't want detachment nad attachment of js apis from css

ar: so side effect fre?
... i suggest that's a separate problem

dg: the problem I see here is that there's a party that's interested in doing decorators
... the set of people working on it is not here
... and we're blocked on that
... you're saying "get interested in that problem"

js: i'm fine with coming up with a proposal for it
... I think we'll need a proposal for it before implementing in Gecko

This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: i/We are starting with an overview and demo/Topic: Overview
Succeeded: s/watn/want/
Succeeded: s/bea n/be an/
Succeeded: s/lists/list/
Found Scribe: weinig
Inferring ScribeNick: weinig
Found Scribe: heycam
Inferring ScribeNick: heycam
Scribes: weinig, heycam
ScribeNicks: weinig, heycam

WARNING: Replacing previous Present list. (Old list: Travis_Leithead)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ James_Graham


WARNING: Replacing previous Present list. (Old list: James_Graham)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Cameron_McCormack


WARNING: Replacing previous Present list. (Old list: Cameron_McCormack)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Anne_VK

Present: Anne_VK Ian_Hickson Yehuda_Katz Dominic_Cooney Ryosuke_Niwa Wonsook_Lee Doug_Schepers Jacob_Rossi Roland_Steiner Cyril_Concolato Wilhelm James_Graham Sylvain_Galineau maybe_some_other_people Marcus_MSFT Jonas_Sicking Cameron_McCormack Alex_Russell Dmitri_Glazkov Sam_Weinig Ted_OConnor Travis_Leithead

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 02 Nov 2011
Guessing minutes URL: http://www.w3.org/2011/11/02-webapps-minutes.html
People with action items: