[components] Summary of open questions
Hi all, To give a broader overview over the everything involved with components, I summarized all open questions (as far as we see it) at http://wiki.whatwg.org/wiki/Component_Model_Discussion . Please chime in with opinions on any item and/or stuff you think is missing and should belong on the list. Cheers, - Roland
[Bug 14084] Hi! Returning a null from getItem() if the key does not exist is downright semantically wrong. null is a full-fledged value which can be serialized (JSONed), and is NOT the value we get
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14084 Anne changed: What|Removed |Added Resolution|LATER |WONTFIX --- Comment #5 from Anne 2011-10-12 01:59:01 UTC --- WONTFIX per comment 2 and comment 4. If you disagree with this resolution please reopen. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: Reminder: RfC: Last Call Working Draft of Web IDL; deadline October 18
On 10/11/11 4:08 PM, ext Travis Leithead wrote: Is there a comment tracking doc for this LC (e.g., lc2)? I don't see one in CVS. (I think Cameron returns soon though.)
Re: Behavior Attachment Redux, was Re: HTML element content models vs. components
On Tue, 11 Oct 2011, Erik Arvidsson wrote:
>
> I think one thing that is missing from this table/proposal is how the
> prototype chain is hooked up.
>
> For the permanent case I would like to see the user defined object on
> that chain.
>
>
> function FancyButton () {}
> // registration and whatevs
>
>
>
>
> b.constructor === FanceButton
> b.__proto__ === FancyButton.prototype
> b.__proto__.__proto__ === HTMLButtonElement.prototype
That sounds fine to me.
I wouldn't want to require that authors use JS to define a binding though.
If a binding doesn't define an API, just a shadow tree and some scoped
styles, I would expect it to be purely declarative (still function when
JS is disabled) both for the is="" case and the 'binding:' case.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [widgets] Killing file:// of evil (widget URI ready for pub)
I'm not sure if you're on device-apis, Marcos, but you might be interested in this - what happens when you no longer need to intercept localhost; http://www.w3.org/mid/6dfa1b20d858a14488a66d6eedf26aa35d61fed...@seldmbx03.corpusers.net Mark.
[Bug 14084] Hi! Returning a null from getItem() if the key does not exist is downright semantically wrong. null is a full-fledged value which can be serialized (JSONed), and is NOT the value we get
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14084 Art Barstow changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER --- Comment #3 from Art Barstow 2011-10-11 20:13:12 UTC --- I think v1 of this spec should focus on current implementations and as such, the change proposed in comment 0 can be considered for the next version of the spec. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 13972] var bgPage = chrome.extension.getBackgroundPage(); function saveTabData(tab, data) { if (tab.incognito) { bgPage[tab.url] = data; // Persist data ONLY in memory } else { localStorage[tab
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13972 Art Barstow changed: What|Removed |Added Status|NEW |RESOLVED CC||art.bars...@nokia.com Resolution||NEEDSINFO --- Comment #1 from Art Barstow 2011-10-11 20:10:19 UTC --- Please be more specific about the spec bug. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
RE: Reminder: RfC: Last Call Working Draft of Web IDL; deadline October 18
Is there a comment tracking doc for this LC (e.g., lc2)? >-Original Message- >From: public-script-coord-requ...@w3.org [mailto:public-script-coord- >requ...@w3.org] On Behalf Of Arthur Barstow >Sent: Tuesday, October 11, 2011 4:37 AM >To: public-script-coord; public-webapps >Subject: Reminder: RfC: Last Call Working Draft of Web IDL; deadline >October 18 > >On 9/27/11 3:56 PM, ext Arthur Barstow wrote: >> On September 27 a Last Call Working Draft of Web IDL was published: >> >> http://www.w3.org/TR/2011/WD-WebIDL-20110927/ >> >> The deadline for comments is October 18 and all comments should be >> sent to: >> >> public-script-co...@w3.org >> >> The comment tracking doc for the previous LC is: >> >> http://dev.w3.org/2006/webapi/WebIDL/lc1.txt >> >> Cameron, Philippe - if you think it is necessary, please fwd this >> e-mail to ECMA TC39. >> >> -AB >> >
Re: Behavior Attachment Redux, was Re: HTML element content models vs. components
On Tue, 11 Oct 2011, Dimitri Glazkov wrote:
> On Tue, Oct 11, 2011 at 11:25 AM, Erik Arvidsson wrote:
> > By splitting I meant (and I think Ian did as well) that we have
> > decorators that does not change the interface and then we have
> > components which can change the shadow tree and define a new interface
> > (API).
> >
> > The decorators can be attached and detached at runtime using css and
> > maybe even an imperative API. The decorators cannot change the
> > interface.
> >
> > The components have to be defined before first access and elements are
> > created tied to a specific interface.
>
> +1. However, Hixie just one message ago indicated that he doesn't see
> distinction between components and decorators (or bindings). So I think
> there's still some clarification work to do.
I don't see a distinction between the word "component" and the word
"binding". The term "binding" comes from the point of view of the linking
of a definition to an element. The term "component" comes from the point
of view of the definition itself. Microsoft has historically used the term
"component" ("HTC" stands for "HTML Component"), whereas Mozilla has
historically used the term "binding" ("XBL" stands for "(something)
Binding Language", for various values of "something").
These aren't the only terms that have been used to describe this, by the
way. The term "behaviour" has long been used (indeed "behavior" the CSS
property used to link to an HTC component, and was originally the property
used to link to an XBL binding, and that term was used by the CSS working
group to refer to the concept; e.g. "BECSS" stands for "Behavioral
Extensions to CSS"). The CSS working group also worked on a technology
called "Action Sheets", which is in the same space.
The main development in this space recently has been the idea of the split
Erik describes in the text quoted above. That is, that a component, or
binding, can be an API-defining component or API-defining binding,
permanently bound using is="" at element-creation time; and a component,
or binding, can be a decorator component or decorator binding, bound from
CSS (or using is="", or via an API), in a potentially transient manner,
but not defining an API.
Or to use a table:
| Decorator binding or | Permanent binding or
| decorator component | permanent component
-+--+--
Can be bound at element-| YES |YES
creation time (is="") | |
-+--+--
Can be bound from CSS | YES |NO
-+--+--
Can be bound from an API| YES |NO
-+--+--
Can be rebound to another | YES |NO
binding later | |
-+--+--
Can have the binding| YES |NO
removed altogether | |
-+--+--
Can define a shadow tree| YES |YES
-+--+--
Can define ARIA roles for | YES |YES
the element and shadow tree| |
-+--+--
Can define scope styles | YES |YES
-+--+--
Can define event handlers | YES |YES
-+--+--
Can run script from timers | YES |YES
-+--+--
Can manipulate the DOM via | YES |YES
script | |
-+--+--
Can define a public API | NO |YES
-+--+--
Must be declared in the | YES |YES
page before the binding| |
can be used| |
-+--+--
Since these are so close to each other, I don't see much value in having
different solutions for decorating bindings (used for presentation,
changing what existing widgets look and feel like) vs permanent
API-defining bindings (used to introduce new widget
Re: Behavior Attachment Redux, was Re: HTML element content models vs. components
On Tue, Oct 11, 2011 at 11:25 AM, Erik Arvidsson wrote: > By splitting I meant (and I think Ian did as well) that we have > decorators that does not change the interface and then we have > components which can change the shadow tree and define a new interface > (API). > > The decorators can be attached and detached at runtime using css and > maybe even an imperative API. The decorators cannot change the > interface. > > The components have to be defined before first access and elements are > created tied to a specific interface. +1. However, Hixie just one message ago indicated that he doesn't see distinction between components and decorators (or bindings). So I think there's still some clarification work to do. :DG< > > erik > > > > > > > > > On Tue, Oct 11, 2011 at 10:57, Tab Atkins Jr. wrote: >> On Tue, Oct 11, 2011 at 10:01 AM, Dimitri Glazkov >> wrote: >>> On Mon, Oct 10, 2011 at 4:55 PM, Erik Arvidsson wrote: Splitting this up into two different things is great. >>> >>> The specific meaning of "splitting up" is where the things get >>> interesting. As far as I understand Hixie's idea, the component (which >>> exposes API) and the binding (which supplies shadow tree) aren't >>> coupled, which means they can share no internal state. For example, >>> you can't close over a set of event listeners that interact with >>> shadow DOM in a component method, because the listeners are applied >>> separately. I don't think that's workable. >>> >>> It seems to me that we should have a way to create a shadow DOM >>> subtree inside of the component -- component's own tree (aka element >>> behavior attachment). >>> >>> Then, there could be a separate method to decorate a component with >>> one additional shadow tree using CSS (aka decorator behavior >>> attachment). >>> >>> The component model is explicitly interested in the former, not the latter. >> >> Agreed. Having the shadow tree entirely separate from the component >> is explicitly bad in many cases. It prevents you from doing native >> implementation of many of the shadow-using HTML elements, like > controls>, which need to hook the controls markup together with the >> scripting. >> >> Being able to decorate an element with a script-free shadow tree >> declaratively might be useful, but it's separate from the component >> use-cases. >> >> ~TJ >> >
Re: Behavior Attachment Redux, was Re: HTML element content models vs. components
By splitting I meant (and I think Ian did as well) that we have decorators that does not change the interface and then we have components which can change the shadow tree and define a new interface (API). The decorators can be attached and detached at runtime using css and maybe even an imperative API. The decorators cannot change the interface. The components have to be defined before first access and elements are created tied to a specific interface. erik On Tue, Oct 11, 2011 at 10:57, Tab Atkins Jr. wrote: > On Tue, Oct 11, 2011 at 10:01 AM, Dimitri Glazkov > wrote: >> On Mon, Oct 10, 2011 at 4:55 PM, Erik Arvidsson wrote: >>> Splitting this up into two different things is great. >> >> The specific meaning of "splitting up" is where the things get >> interesting. As far as I understand Hixie's idea, the component (which >> exposes API) and the binding (which supplies shadow tree) aren't >> coupled, which means they can share no internal state. For example, >> you can't close over a set of event listeners that interact with >> shadow DOM in a component method, because the listeners are applied >> separately. I don't think that's workable. >> >> It seems to me that we should have a way to create a shadow DOM >> subtree inside of the component -- component's own tree (aka element >> behavior attachment). >> >> Then, there could be a separate method to decorate a component with >> one additional shadow tree using CSS (aka decorator behavior >> attachment). >> >> The component model is explicitly interested in the former, not the latter. > > Agreed. Having the shadow tree entirely separate from the component > is explicitly bad in many cases. It prevents you from doing native > implementation of many of the shadow-using HTML elements, like controls>, which need to hook the controls markup together with the > scripting. > > Being able to decorate an element with a script-free shadow tree > declaratively might be useful, but it's separate from the component > use-cases. > > ~TJ >
Re: Behavior Attachment Redux, was Re: HTML element content models vs. components
On Tue, 11 Oct 2011, Tab Atkins Jr. wrote: > On Tue, Oct 11, 2011 at 10:01 AM, Dimitri Glazkov > wrote: > > On Mon, Oct 10, 2011 at 4:55 PM, Erik Arvidsson wrote: > >> Splitting this up into two different things is great. > > > > The specific meaning of "splitting up" is where the things get > > interesting. As far as I understand Hixie's idea, the component (which > > exposes API) and the binding (which supplies shadow tree) aren't > > coupled, which means they can share no internal state. For example, > > you can't close over a set of event listeners that interact with > > shadow DOM in a component method, because the listeners are applied > > separately. I don't think that's workable. > > > > It seems to me that we should have a way to create a shadow DOM > > subtree inside of the component -- component's own tree (aka element > > behavior attachment). > > > > Then, there could be a separate method to decorate a component with > > one additional shadow tree using CSS (aka decorator behavior > > attachment). > > > > The component model is explicitly interested in the former, not the latter. > > Agreed. Having the shadow tree entirely separate from the component > is explicitly bad in many cases. It prevents you from doing native > implementation of many of the shadow-using HTML elements, like controls>, which need to hook the controls markup together with the > scripting. Indeed. I think it is important that we be able to style with different types of interactive controls straight from CSS. That requires scripting, event handlers, scoped styles, and a shadow tree, and doesn't require defining a new API. That's a different use case than e.g. being able to create an entirely new widget that happens to hook into form submission by piggy-backing on , though. That might well want to expose a new API, while in addition wanting all the other things mentioned above. You wouldn't want to hook the new API from CSS, given the desire for stable APIs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Behavior Attachment Redux, was Re: HTML element content models vs. components
On Tue, 11 Oct 2011, Dimitri Glazkov wrote: > On Mon, Oct 10, 2011 at 4:55 PM, Erik Arvidsson wrote: > > Splitting this up into two different things is great. > > The specific meaning of "splitting up" is where the things get > interesting. As far as I understand Hixie's idea, the component (which > exposes API) and the binding (which supplies shadow tree) aren't > coupled, which means they can share no internal state. As far as I'm concerned, the term "component" and the term "binding" mean the same thing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Behavior Attachment Redux, was Re: HTML element content models vs. components
On Tue, Oct 11, 2011 at 10:01 AM, Dimitri Glazkov wrote: > On Mon, Oct 10, 2011 at 4:55 PM, Erik Arvidsson wrote: >> Splitting this up into two different things is great. > > The specific meaning of "splitting up" is where the things get > interesting. As far as I understand Hixie's idea, the component (which > exposes API) and the binding (which supplies shadow tree) aren't > coupled, which means they can share no internal state. For example, > you can't close over a set of event listeners that interact with > shadow DOM in a component method, because the listeners are applied > separately. I don't think that's workable. > > It seems to me that we should have a way to create a shadow DOM > subtree inside of the component -- component's own tree (aka element > behavior attachment). > > Then, there could be a separate method to decorate a component with > one additional shadow tree using CSS (aka decorator behavior > attachment). > > The component model is explicitly interested in the former, not the latter. Agreed. Having the shadow tree entirely separate from the component is explicitly bad in many cases. It prevents you from doing native implementation of many of the shadow-using HTML elements, like , which need to hook the controls markup together with the scripting. Being able to decorate an element with a script-free shadow tree declaratively might be useful, but it's separate from the component use-cases. ~TJ
Re: Behavior Attachment Redux, was Re: HTML element content models vs. components
On Mon, Oct 10, 2011 at 4:55 PM, Erik Arvidsson wrote: > Splitting this up into two different things is great. The specific meaning of "splitting up" is where the things get interesting. As far as I understand Hixie's idea, the component (which exposes API) and the binding (which supplies shadow tree) aren't coupled, which means they can share no internal state. For example, you can't close over a set of event listeners that interact with shadow DOM in a component method, because the listeners are applied separately. I don't think that's workable. It seems to me that we should have a way to create a shadow DOM subtree inside of the component -- component's own tree (aka element behavior attachment). Then, there could be a separate method to decorate a component with one additional shadow tree using CSS (aka decorator behavior attachment). The component model is explicitly interested in the former, not the latter. :DG<
Re: Behavior Attachment Redux, was Re: HTML element content models vs. components
On Tue, 11 Oct 2011, Roland Steiner wrote: > On Tue, Oct 11, 2011 at 04:58, Ian Hickson wrote: > > > > On Tue, 4 Oct 2011, Roland Steiner wrote: > > > On a second note, what you essentially seem to demand is swapping > > > out entire HTML sub-branches based on presentation. > > > > It's not how I would describe it (I wouldn't expect the shadow trees > > to be written using HTML), but to a first approximation, sure. > > Intriguing - could you elaborate on the above? Do you mean shadow trees > should not use HTML, but something different? (If so, what instead? pure > JS?) Or do you mean shadow trees should not be defined in the HTML of > the main DOM and then swapped into the shadow trees? If the latter, I > fully agree. Shadow trees tend to just be a bunch of semantic-free elements (like ), not semantic-rich HTML (like or ); so much so that in XBL2 we actually had an XBL-namespace so you wouldn't have to use the HTML namespace . It's not an important difference. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Mutation Observers: a replacement for DOM Mutation Events
On Mon, Oct 10, 2011 at 7:51 PM, Sean Hogan wrote: > On 24/09/11 7:16 AM, Adam Klein wrote: >> - Is free of the faults of the existing Mutation Events mechanism >> (enumerated in detail here: >> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html) > > A simpler solution that is free from the faults listed in that email would > be to have (at max) one mutation observer for the whole page context. I > guess this would be called at the end of the task or immediately before page > reflows. > > If a js lib (or multiple libs) want to provide finer grained mutation > handling then let them work out the details. That seems unworkably restrictive. It's very easy to imagine multiple libraries listening for different kinds of things at the same time. Libraries would just end up re-implementing event distribution, which is something we can avoid by doing it correctly now. ~TJ
Reminder: RfC: Last Call Working Draft of Web IDL; deadline October 18
On 9/27/11 3:56 PM, ext Arthur Barstow wrote: On September 27 a Last Call Working Draft of Web IDL was published: http://www.w3.org/TR/2011/WD-WebIDL-20110927/ The deadline for comments is October 18 and all comments should be sent to: public-script-co...@w3.org The comment tracking doc for the previous LC is: http://dev.w3.org/2006/webapi/WebIDL/lc1.txt Cameron, Philippe - if you think it is necessary, please fwd this e-mail to ECMA TC39. -AB
