XBL2: First Thoughts and Use Cases

2010-12-11 Thread Dimitri Glazkov
Hello, friendly elves that keep pushing the Web forward! I spent a few days internalizing the XBL2 spec and here's my first set of reactions. First, the XBL2 spec is truly an amazing feat. While reading it, I kept having visions of walking about an alien artifact, mesmerized by its scale, with a

Re: XBL2: First Thoughts and Use Cases

2010-12-12 Thread Dimitri Glazkov
On Sun, Dec 12, 2010 at 12:52 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Dec 11, 2010 at 1:04 PM, Dimitri Glazkov dglaz...@google.com wrote: Looking at the use cases, I couldn't think of anything that would require this type of functionality -- at least not at the cost of its

Re: XBL2: First Thoughts and Use Cases

2010-12-14 Thread Dimitri Glazkov
On Mon, Dec 13, 2010 at 10:33 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Dec 14, 2010 at 2:46 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Then there's no problem.  You don't need the templates to be live to make child changes work.  You just need to maintain some record that

Re: XBL2: First Thoughts and Use Cases

2010-12-14 Thread Dimitri Glazkov
On Tue, Dec 14, 2010 at 11:14 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/14/10 11:03 AM, Tab Atkins Jr. wrote: Script should be able to walk and mutate the shadow DOM for an element I'm not sure I agree, in fact.  Why should script be able to do this? Sorta supporting this has been a

Rename XBL2 to something without X, B, or L?

2010-12-14 Thread Dimitri Glazkov
Dear all, Looking at the use cases and the problems the current XBL2 spec is trying address, I think it might be a good idea to rename it into something that is less legacy-bound? Hixie already cleverly disguised the X as [X]engamous in the latest draft, and if this spec is to become part of

Re: Fwd: XBL2: First Thoughts and Use Cases

2010-12-15 Thread Dimitri Glazkov
On Wed, Dec 15, 2010 at 10:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Dec 15, 2010 at 10:19 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/15/10 7:51 AM, Tab Atkins Jr. wrote: (Events and such don't work on the final flattened tree Sort of.  Hit testing clearly needs to work

Re: Fwd: XBL2: First Thoughts and Use Cases

2010-12-15 Thread Dimitri Glazkov
On Wed, Dec 15, 2010 at 11:10 AM, Dimitri Glazkov dglaz...@google.com wrote: On Wed, Dec 15, 2010 at 10:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Dec 15, 2010 at 10:19 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/15/10 7:51 AM, Tab Atkins Jr. wrote: (Events and such don't

Re: Fwd: XBL2: First Thoughts and Use Cases

2010-12-15 Thread Dimitri Glazkov
On Wed, Dec 15, 2010 at 11:14 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/15/10 10:51 AM, Tab Atkins Jr. wrote: Yes, output ports can be moved.  I don't have any particular use-case for it, but under the current conceptual model for how output ports work, it's simpler to allow it than to

Re: Fwd: XBL2: First Thoughts and Use Cases

2010-12-16 Thread Dimitri Glazkov
On Thu, Dec 16, 2010 at 10:40 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/15/10 11:29 AM, Dimitri Glazkov wrote: That seems like an implementation detail. Metadata can be shared and cloned as needed, just like styles in CSS. Sort of.  It would need to be cloned as soon as the shadow tree

Re: XBL2: First Thoughts and Use Cases

2010-12-16 Thread Dimitri Glazkov
On Wed, Dec 15, 2010 at 10:53 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 15, 2010, at 11:14 AM, Boris Zbarsky wrote: At least in Gecko's case, we still use XBL1 in this way, and those design goals would apply to XBL2 from our point of view.  It sounds like you have entirely

Re: Fwd: XBL2: First Thoughts and Use Cases

2010-12-16 Thread Dimitri Glazkov
On Thu, Dec 16, 2010 at 12:23 PM, Olli Pettay olli.pet...@helsinki.fi wrote: On 12/16/2010 11:52 AM, Tab Atkins Jr. wrote: On Thu, Dec 16, 2010 at 10:40 AM, Boris Zbarskybzbar...@mit.edu  wrote: On 12/15/10 11:29 AM, Dimitri Glazkov wrote: That seems like an implementation detail. Metadata

Re: Moving XBL et al. forward

2011-03-09 Thread Dimitri Glazkov
be pursued. Dimitri Glazkov volunteers to edit the spec. I certainly do, although the link mentioned is not really a proposal, more like a clean-slate examination of the concrete use cases that a Web Component model should satisfy. ~TJ

Component Model is not an Isolation Model

2011-03-09 Thread Dimitri Glazkov
Greetings, fellow Web-Platform-o-nauts, Summary: We need a proper Isolation Model for the Web. Component Model ain't it. Art's email prodded me to condensate some of brain ether accumulated while looking at the use cases. Here's some for ya. After a productive discussion with the Caja folks and

Re: Moving XBL et al. forward

2011-03-10 Thread Dimitri Glazkov
That's just use cases. I used the latest draft of XBL2 for syntax -- might as well be pseudocode at this point. :DG On Thu, Mar 10, 2011 at 1:35 PM, Daniel Glazman daniel.glaz...@disruptive-innovations.com wrote: Le 10/03/11 16:26, Dimitri Glazkov a écrit : Ok, this is interesting. Which

Re: Moving XBL et al. forward

2011-03-10 Thread Dimitri Glazkov
Cameron++ Also, this is a public wiki. If you feel like the use cases aren't covering the problem domain to your satisfaction, please feel encouraged to make additions. :DG On Thu, Mar 10, 2011 at 1:46 PM, Cameron McCormack c...@mcc.id.au wrote: Daniel Glazman: Ok, so don't focus on the

Re: Component Model is not an Isolation Model

2011-03-10 Thread Dimitri Glazkov
On Wed, Mar 9, 2011 at 7:17 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/9/11 7:30 PM, Dimitri Glazkov wrote: From the perspective of the component, the isolation is unfairly punishing -- you can't use the outside DOM or even DOM element on which you're hoisted, you can't add methods

Re: Component Model is not an Isolation Model

2011-03-10 Thread Dimitri Glazkov
On Thu, Mar 10, 2011 at 1:59 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Mar 10, 2011 at 4:17 PM, Boris Zbarsky bzbar...@mit.edu wrote: 1)  Cross-site components are safe to use. 2)  You can't screw up and depend on implementation details of a    component, because if you're

Re: Component Model is not an Isolation Model

2011-03-10 Thread Dimitri Glazkov
On Thu, Mar 10, 2011 at 1:57 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Fri, Mar 11, 2011 at 8:54 AM, Boris Zbarsky bzbar...@mit.edu wrote: CDNs of various sorts, dedicated hostnames for different sorts of content (a la existing images.something.com setups), that sort of thing. If

Re: Component Model is not an Isolation Model

2011-03-10 Thread Dimitri Glazkov
On Thu, Mar 10, 2011 at 2:07 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/10/11 4:58 PM, Dimitri Glazkov wrote: We want to be useful and not in the way for this use case. Agreed-ish. For the cases where isolation is necessary, be that mashups or browser's implementation of HTML elements

Component Model Should Use DOM Object Inheritance

2011-03-10 Thread Dimitri Glazkov
Summary: There is no need to build another type of inheritance into the component model, since all DOM already has an inheritance mechanism. Another set of thoughts around use cases (http://wiki.whatwg.org/wiki/Component_Model_Use_Cases) A large part of complexity of the current XBL2 draft comes

Component Model: Landing Experimental Shadow DOM API in WebKit

2011-06-29 Thread Dimitri Glazkov
Hi Folks! With use cases (http://wiki.whatwg.org/wiki/Component_Model_Use_Cases) firmed up, and isolation (http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0900.html), inheritance (http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0941.html) out of the way, a component

Re: Component Model: Landing Experimental Shadow DOM API in WebKit

2011-06-29 Thread Dimitri Glazkov
On Wed, Jun 29, 2011 at 9:41 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/29/11 12:08 PM, Dimitri Glazkov wrote: 2) There is no separation between internal (http://dev.w3.org/2006/xbl2/#xblimplementation) and external objects, since we decided to push isolation into its own spec. I still

Re: Component Model: Landing Experimental Shadow DOM API in WebKit

2011-06-29 Thread Dimitri Glazkov
On Wed, Jun 29, 2011 at 10:14 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/29/11 12:59 PM, Dimitri Glazkov wrote: It will just return null when the membrane is in place. OK.  And the encapsulation will prevent other ways of getting at the shadow tree? Yes! element.shadow is the only way

Re: Component Model: Landing Experimental Shadow DOM API in WebKit

2011-06-29 Thread Dimitri Glazkov
+cam, in case his mail filters are haters. :DG On Wed, Jun 29, 2011 at 10:17 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Jun 29, 2011 at 10:14 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/29/11 12:59 PM, Dimitri Glazkov wrote: It will just return null when the membrane

Re: Component Model: Landing Experimental Shadow DOM API in WebKit

2011-06-29 Thread Dimitri Glazkov
On Wed, Jun 29, 2011 at 1:56 PM, Anne van Kesteren ann...@opera.com wrote: On Wed, 29 Jun 2011 19:17:01 +0200, Dimitri Glazkov dglaz...@chromium.org wrote: The former: http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/dom/Document.hl=208 How can

Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)

2011-06-30 Thread Dimitri Glazkov
Hi Maciej! First off, I really appreciate your willingness to get into the mix of things. It's a hard problem and I welcome any help we can get to solve it. I also very much liked your outline of encapsulation and I would like to start using the terminology you introduced. I am even flattered

Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)

2011-06-30 Thread Dimitri Glazkov
Maciej, as promised on #whatwg, here's a more thorough review of your proposal. I am in agreement in the first parts of your email, so I am going to skip those. == Are there other limitations created by the lack of encapsulation? == My understanding is yes, there are some serious limitations:

Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)

2011-06-30 Thread Dimitri Glazkov
On Thu, Jun 30, 2011 at 1:32 PM, Maciej Stachowiak m...@apple.com wrote: On Jun 30, 2011, at 1:03 PM, Dimitri Glazkov wrote: Maciej, as promised on #whatwg, here's a more thorough review of your proposal. I am in agreement in the first parts of your email, so I am going to skip those. =3D

Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)

2011-06-30 Thread Dimitri Glazkov
On Thu, Jun 30, 2011 at 2:21 PM, Maciej Stachowiak m...@apple.com wrote: On Jun 30, 2011, at 2:07 PM, Dimitri Glazkov wrote: On Thu, Jun 30, 2011 at 1:32 PM, Maciej Stachowiak m...@apple.com wrote: On Jun 30, 2011, at 1:03 PM, Dimitri Glazkov wrote: In the case of extending elements

Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)

2011-06-30 Thread Dimitri Glazkov
On Thu, Jun 30, 2011 at 2:50 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/30/11 5:45 PM, Dimitri Glazkov wrote: There's a very interesting distinction here. You don't attach components to DOM elements. DOM elements _are_ components. The only way to make a component is by sub-classing

Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)

2011-06-30 Thread Dimitri Glazkov
On Thu, Jun 30, 2011 at 2:50 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/30/11 5:45 PM, Dimitri Glazkov wrote: There's a very interesting distinction here. You don't attach components to DOM elements. DOM elements _are_ components. The only way to make a component is by sub-classing

Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)

2011-06-30 Thread Dimitri Glazkov
Perhaps the right solution is to require inherited and disallow access to shadow DOM tree if the sub-class is not overriding the subtree? :DG

Overview of behavior attachment as a general problem on the Web

2011-07-08 Thread Dimitri Glazkov
As a background for the wider Component Model discussion, I put together an overview of the general behavior attachment problem on the Web: http://wiki.whatwg.org/wiki/Behavior_Attachment Please take a look. Comments, additions, and critique are appreciated. :DG

Re: Element.create(): a proposal for more convenient element creation

2011-08-02 Thread Dimitri Glazkov
On Tue, Aug 2, 2011 at 1:27 AM, Roland Steiner rolandstei...@google.com wrote: On Tue, Aug 2, 2011 at 4:36 PM, Jonas Sicking jo...@sicking.cc wrote: This doesn't explain why a factory method is better than explicit constructors though? The above could be written as new

Re: Element.create(): a proposal for more convenient element creation

2011-08-02 Thread Dimitri Glazkov
On Tue, Aug 2, 2011 at 1:27 AM, Roland Steiner rolandstei...@google.com wrote: On Tue, Aug 2, 2011 at 4:36 PM, Jonas Sicking jo...@sicking.cc wrote: This doesn't explain why a factory method is better than explicit constructors though? The above could be written as new

Re: Element.create(): a proposal for more convenient element creation

2011-08-02 Thread Dimitri Glazkov
On Tue, Aug 2, 2011 at 10:37 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 2 Aug 2011, Dimitri Glazkov wrote: On Tue, Aug 2, 2011 at 1:27 AM, Roland Steiner rolandstei...@google.com wrote: On Tue, Aug 2, 2011 at 4:36 PM, Jonas Sicking jo...@sicking.cc wrote: This doesn't explain why

Component Model Update

2011-08-23 Thread Dimitri Glazkov
All, Over the last few weeks, a few folks and myself have been working on fleshing out the vision for the Component Model. Here's what we've done so far: * Created a general overview document for behavior attachment problem on the Web (http://wiki.whatwg.org/wiki/Behavior_Attachment); * Wrote

Re: Component Model Update

2011-08-24 Thread Dimitri Glazkov
at 1:40 PM, Dimitri Glazkov dglaz...@chromium.org wrote: All, Over the last few weeks, a few folks and myself have been working on fleshing out the vision for the Component Model. Here's what we've done so far: * Created a general overview document for behavior attachment problem on the Web

Re: Component Model Update

2011-08-24 Thread Dimitri Glazkov
Hi Olli! On Wed, Aug 24, 2011 at 3:13 AM, Olli Pettay olli.pet...@helsinki.fi wrote: On 08/23/2011 11:40 PM, Dimitri Glazkov wrote: All, Over the last few weeks, a few folks and myself have been working on fleshing out the vision for the Component Model. Here's what we've done so far

Re: [Component Model]: Shadow DOM Subtree per element: One or Many?

2011-08-24 Thread Dimitri Glazkov
On Wed, Aug 24, 2011 at 12:19 PM, Erik Arvidsson a...@chromium.org wrote: On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov dglaz...@chromium.org wrote: What do you think? +1 It would surely allow certain use cases to be covered that are not covered today with form control elements. How

Re: Component Model Update

2011-08-24 Thread Dimitri Glazkov
On Wed, Aug 24, 2011 at 2:50 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov dglaz...@chromium.org wrote: Yes, shadow DOM gives the author an extra lever

Re: [Component Model]: Shadow DOM Subtree per element: One or Many?

2011-08-24 Thread Dimitri Glazkov
On Wed, Aug 24, 2011 at 2:44 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 2:44 AM, Dimitri Glazkov dglaz...@chromium.org wrote: All, Adam raises an interesting question: should we allow more than one shadow DOM subtree per element? Background: per current design

Re: [Component Model]: Shadow DOM Subtree per element: One or Many?

2011-08-24 Thread Dimitri Glazkov
On Wed, Aug 24, 2011 at 2:38 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011 at 4:37 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Aug 24, 2011 at 12:19 PM, Erik Arvidsson a...@chromium.org wrote: On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov dglaz

Re: [Component Model]: Shadow DOM Subtree per element: One or Many?

2011-08-24 Thread Dimitri Glazkov
, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Aug 24, 2011 at 12:19 PM, Erik Arvidsson a...@chromium.org wrote: On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov dglaz...@chromium.org wrote: What do you think? +1 It would surely allow certain use cases to be covered that are not covered

Re: Component Model Update

2011-08-24 Thread Dimitri Glazkov
On Wed, Aug 24, 2011 at 8:23 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Wed, Aug 24, 2011 at 7:50 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Independent of our different point of view on control, shadow DOM needs debug APIs. So much the better if these are available

[Component Model] Declarative syntax for shadow DOM subtrees, was Re: Component Model Update

2011-08-25 Thread Dimitri Glazkov
On Thu, Aug 25, 2011 at 8:35 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Aug 25, 2011 at 1:41 AM, Olli Pettay olli.pet...@helsinki.fi wrote: One thing missing is some kind of declarative way to define shadow trees, similar to XBL1's content. It would be rather strange if one needs

Re: Some way to change an element's name would be useful

2011-08-29 Thread Dimitri Glazkov
Document.renameNode seems cool. Aside from the awkward user data event, it matches perfectly the needs of the Component Model (updated to reference it here: http://wiki.whatwg.org/wiki/Component_Model#Performance). I am curious why no one had implemented this. We should dust it off, add a normal

Custom tags over wire, was Re: HTMLElement.register--giving components tag names

2011-08-31 Thread Dimitri Glazkov
Splitting off to its own thread, because this deserves a good discussion. On Wed, Aug 31, 2011 at 12:00 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 31 Aug 2011 07:33:16 +0200, Dominic Cooney domin...@chromium.org wrote: Thanks for reading this far! These proposals aren't formal or

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

2011-08-31 Thread Dimitri Glazkov
On Wed, Aug 31, 2011 at 10:29 AM, Dimitri Glazkov dglaz...@chromium.org wrote: I will write up the exact algorithm in a wiki shortly. Here it is: http://wiki.whatwg.org/wiki/Component_Model_Progressive_Enhancement :DG

Re: HTMLElement.register--giving components tag names

2011-08-31 Thread Dimitri Glazkov
On Tue, Aug 30, 2011 at 10:33 PM, Dominic Cooney domin...@chromium.org wrote: Components (see http://wiki.whatwg.org/wiki/Component_Model_Use_Cases for examples of what I mean) need to present an API to script. For example, a contacts component might want to expose a refresh() method that

Re: HTMLElement.register--giving components tag names

2011-08-31 Thread Dimitri Glazkov
On Tue, Aug 30, 2011 at 10:33 PM, Dominic Cooney domin...@chromium.org wrote: Components (see http://wiki.whatwg.org/wiki/Component_Model_Use_Cases for examples of what I mean) need to present an API to script. For example, a contacts component might want to expose a refresh() method that

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

2011-09-02 Thread Dimitri Glazkov
On Fri, Sep 2, 2011 at 2:30 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 31 Aug 2011 19:29:28 +0200, Dimitri Glazkov dglaz...@chromium.org wrote: To put it differently, you want to start with a well-known element in markup, and, through the magic of computing, this element _becomes_

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

2011-09-03 Thread Dimitri Glazkov
On Sat, Sep 3, 2011 at 12:08 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 2 Sep 2011, Anne van Kesteren wrote: What we need is not a becomes= attribute (that renames an element and therefore forgoes its semantics) but rather a way to get complete control over a semantic element and tweak

Re: HTMLElement.register--giving components tag names

2011-09-03 Thread Dimitri Glazkov
Be careful with the big words. It can't be that inferior if it satisfies use cases that XBL2 can't. :DG On Sat, Sep 3, 2011 at 8:20 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 3 Sep 2011, Dominic Cooney wrote: I think the XBL approach is far superior here -- have authors use existing

Re: HTMLElement.register--giving components tag names

2011-09-03 Thread Dimitri Glazkov
On Sat, Sep 3, 2011 at 8:20 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 3 Sep 2011, Dominic Cooney wrote: I think the XBL approach is far superior here -- have authors use existing elements, and use XBL to augment them. For example, if you want the user to select a country from a map,

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

2011-09-04 Thread Dimitri Glazkov
On Sun, Sep 4, 2011 at 5:03 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Sun, Sep 4, 2011 at 1:56 PM, Dimitri Glazkov dglaz...@chromium.org wrote: The offsetWidth query could've triggered an event handler execution I don't think offsetWidth should be able to trigger synchronous

XBL2 is dead.

2011-09-22 Thread Dimitri Glazkov
I just read Anne's update (http://blog.whatwg.org/weekly-xbl-intents) and realized that while Dominic shared the notes (http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1513.html), there wasn't a nice short summary of the discussion published alongside. I should totally correct that.

Re: XBL2 is dead.

2011-09-26 Thread Dimitri Glazkov
On Mon, Sep 26, 2011 at 12:28 AM, Anne van Kesteren ann...@opera.com wrote: On Thu, 22 Sep 2011 20:30:24 +0200, Dimitri Glazkov dglaz...@chromium.org wrote: Further, instead of packaging Web Components into one omnibus offering, we will likely end up with several free-standing specs or spec

Behavior Attachment Redux, was Re: HTML element content models vs. components

2011-09-28 Thread Dimitri Glazkov
The way to solve this is not to change the content models, it's to use an actual li and bind it to the component. We should not have authors inventing new elements. It doesn't have fallback behaviour, it doesn't have semantics that can be interpreted by search engines and accessibility tools,

Re: HTML element content models vs. components

2011-09-28 Thread Dimitri Glazkov
On Tue, Sep 27, 2011 at 11:53 PM, Dominic Cooney domin...@chromium.org wrote: On Wed, Sep 28, 2011 at 3:39 PM, Roland Steiner rolandstei...@chromium.org wrote: Expanding on the general web component discussion, one area that hasn't been touched on AFAIK is how components fit within the

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

2011-09-28 Thread Dimitri Glazkov
On Wed, Sep 28, 2011 at 11:19 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/28/11 2:08 PM, Dimitri Glazkov wrote: So, we need a way to express in markup that a particular element is to be created with a particular behavior. Yes. Since the tagName is the only identifying property of a DOM

Re: HTML element content models vs. components

2011-09-28 Thread Dimitri Glazkov
On Wed, Sep 28, 2011 at 11:24 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/28/11 2:12 PM, Dimitri Glazkov wrote: C.) Just don't allow components to be used in places that have a special content model. I prefer this one, because: 1. It is very simple. 2. It discourages people from using

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

2011-09-28 Thread Dimitri Glazkov
On Wed, Sep 28, 2011 at 11:30 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/28/11 2:24 PM, Dimitri Glazkov wrote: Can you help me understand what the issues with fallback are? Sure.  If I want to attach a component to a table and to do that I have to write:  x-my-table    trtdContent/td

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

2011-09-28 Thread Dimitri Glazkov
On Wed, Sep 28, 2011 at 1:02 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 28 Sep 2011, Dimitri Glazkov wrote: Hi Ian! :) I already enumerated and hopefully addressed most of your concerns in http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1156.html and http://lists.w3.org

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

2011-09-28 Thread Dimitri Glazkov
transitive APIs. Blergh! TRANSIENT, not transitive. :DG

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

2011-09-28 Thread Dimitri Glazkov
On Wed, Sep 28, 2011 at 3:21 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 28 Sep 2011, Dimitri Glazkov wrote: I think new elements are completely fine as long as they are inheriting directly from HTMLElement. It's when we start dealing with sub-typing HTMLTableElement and such is when

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

2011-09-28 Thread Dimitri Glazkov
On Wed, Sep 28, 2011 at 3:54 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 28 Sep 2011, Dimitri Glazkov wrote: On Wed, Sep 28, 2011 at 3:21 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 28 Sep 2011, Dimitri Glazkov wrote: I think new elements are completely fine as long

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

2011-09-29 Thread Dimitri Glazkov
On Wed, Sep 28, 2011 at 4:52 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 28 Sep 2011, Dimitri Glazkov wrote: On Wed, Sep 28, 2011 at 3:54 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 28 Sep 2011, Dimitri Glazkov wrote: On Wed, Sep 28, 2011 at 3:21 PM, Ian Hickson i...@hixie.ch wrote

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

2011-09-29 Thread Dimitri Glazkov
On Sat, Sep 3, 2011 at 4:31 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 02 Sep 2011 20:47:27 +0200, Dimitri Glazkov dglaz...@chromium.org wrote: BTW, I really ought to put this fears list on the Wiki. Yeah that would probably be a good idea. Done: http://wiki.whatwg.org/wiki

Re: HTML element content models vs. components

2011-09-29 Thread Dimitri Glazkov
On Wed, Sep 28, 2011 at 11:36 AM, Dimitri Glazkov dglaz...@google.com wrote: On Wed, Sep 28, 2011 at 11:24 AM, Boris Zbarsky bzbar...@mit.edu wrote: We already have authors requesting a way of binding a data-presentation component to a table.  Which has a special content model. Man, I keep

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

2011-10-11 Thread Dimitri Glazkov
On Mon, Oct 10, 2011 at 4:55 PM, Erik Arvidsson a...@chromium.org 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

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

2011-10-11 Thread Dimitri Glazkov
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. jackalm...@gmail.com wrote: On Tue, Oct 11, 2011 at 10:01 AM, Dimitri Glazkov dglaz...@chromium.org

Component Model f2f: Actionable things

2011-11-02 Thread Dimitri Glazkov
You can see the minutes here: http://www.w3.org/2011/11/02-webapps-minutes.html First of all, thank you all for coming and participating. It was exhausting, and we just ran out of time. Stupid time! There was also a great conversation post-meeting, but unfortunately no minutes :( Things to act

Re: We just ran out of time ... [Was: Re: Component Model f2f: Actionable things]

2011-11-03 Thread Dimitri Glazkov
Meeting more frequently is something that appeals to me greatly. Email discussions (or worse IRC banter) are not as productive. :DG On Wed, Nov 2, 2011 at 9:38 PM, Arthur Barstow art.bars...@nokia.com wrote: On 11/2/11 6:41 PM, ext Dimitri Glazkov wrote: You can see the minutes here: http

Who is the audience?

2011-11-07 Thread Dimitri Glazkov
Here's one post-TPAC riff. Take it or leave it. One theme that was easy to observe at the conference was the pondering around who those mysterious consumers of what we do are, how to reach them, and how to reason about them. I heard people speak of Web Authors and Web Developers and making

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

2011-11-22 Thread Dimitri Glazkov
On Tue, Nov 22, 2011 at 12:18 AM, Yehuda Katz wyc...@gmail.com wrote: Yehuda Katz (ph) 718.877.1325 On Tue, Nov 22, 2011 at 12:14 AM, Roland Steiner rolandstei...@chromium.org wrote: On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com wrote: Yehuda Katz (ph) 718.877.1325 On

[Component Model] Decorator Challenges

2011-11-22 Thread Dimitri Glazkov
This is a continuation of the Component Model discussion at TPAC, focusing on decorators (see definition here: http://wiki.whatwg.org/wiki/Behavior_Attachment). The design goal for decorators can summarized as follows: allow runtime (dynamic) application and unapplication of presentation (and

Re: XBL2, Component Model and WebApps' Rechartering [Was: Re: Consolidating charter changes]

2011-11-23 Thread Dimitri Glazkov
Hi Arthur! I am a procedural n00b and apologize in advance if this is not exactly what you're looking for. Let's iterate and get it to the digestible point :) In the next few months, I'll be working on and refining (with the help of folks who are interested in the subject): 1) a detailed spec

Re: [Component Model] Decorator Challenges

2011-11-28 Thread Dimitri Glazkov
On Wed, Nov 23, 2011 at 11:06 PM, Dominic Cooney domin...@google.com wrote: On Wed, Nov 23, 2011 at 8:05 AM, Dimitri Glazkov dglaz...@chromium.org wrote: We could explicitly prevent the decorator from ever having a state or being able to change it. This places a set of unorthodox (at least

Re: [Component Model] Decorator Challenges

2011-11-28 Thread Dimitri Glazkov
On Thu, Nov 24, 2011 at 6:40 PM, Roland Steiner rolandstei...@google.com wrote: On Wed, Nov 23, 2011 at 08:05, Dimitri Glazkov dglaz...@chromium.org wrote: Even if we attempt to separate the state of a decorator from the element and its document using an iframe- or worker-like machinery

Re: [Component Model]: Decorators and Fallback Content

2011-12-07 Thread Dimitri Glazkov
On Wed, Dec 7, 2011 at 12:01 AM, Charles Pritchard ch...@jumis.com wrote: TL;DR: How about supporting appearance: none for the canvas element, and decorator as well. The component introduces a decorator: url(#url) semantic to upgrade elements while maintaining backward compatibilty.

Re: [Component Model]: Decorators and Fallback Content

2011-12-07 Thread Dimitri Glazkov
On Wed, Dec 7, 2011 at 9:01 AM, Charles Pritchard ch...@jumis.com wrote: On 12/7/11 7:36 AM, Dimitri Glazkov wrote: On Wed, Dec 7, 2011 at 12:01 AM, Charles Pritchardch...@jumis.com  wrote: TL;DR: How about supporting appearance: none for thecanvas  element, and decorator as well

[webcomponents]: First draft of the Shadow DOM Specification

2011-12-20 Thread Dimitri Glazkov
Happy Holidays! In the joyous spirit of sharing, I present you with a first draft of the Shadow DOM Specification: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html It's not quite a Christmas miracle, more like that extra unlabeled gift box you found in the drapes while

Re: [webcomponents]: First draft of the Shadow DOM Specification

2011-12-20 Thread Dimitri Glazkov
On Tue, Dec 20, 2011 at 4:49 PM, Edward O'Connor eocon...@apple.com wrote: Hi Dimitri, You wrote: In the joyous spirit of sharing, I present you with a first draft of the Shadow DOM Specification: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html Awesome. Thanks for

Re: [webcomponents]: First draft of the Shadow DOM Specification

2011-12-21 Thread Dimitri Glazkov
On Tue, Dec 20, 2011 at 5:38 PM, Brian Kardell bkard...@gmail.com wrote: Yes, I had almost the same thought, though why not just require a prefix? I also think some examples actually showing some handling of events and use of css would be really helpful here... The upper boundary for css vs

Re: [webcomponents]: First draft of the Shadow DOM Specification

2011-12-22 Thread Dimitri Glazkov
will be: main... divs in the document: 2 There's also an interesting issue of when (and whether) script executes inside of a shadow DOM subtree (filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=15313 to track). :DG -Brian On Dec 21, 2011 11:58 AM, Dimitri Glazkov dglaz...@google.com

Re: [webcomponents]: First draft of the Shadow DOM Specification

2011-12-22 Thread Dimitri Glazkov
On Thu, Dec 22, 2011 at 12:49 PM, Brian Kardell bkard...@gmail.com wrote: On Thu, Dec 22, 2011 at 3:15 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Dec 22, 2011 at 7:10 AM, Brian Kardell bkard...@gmail.com wrote: ShadowRoot is a Node, so all of the typical DOM accessors apply

Re: [webcomponents]: First draft of the Shadow DOM Specification

2011-12-22 Thread Dimitri Glazkov
at least one example -- https://www.w3.org/Bugs/Public/show_bug.cgi?id=15173 :DG -Brian On Thu, Dec 22, 2011 at 4:04 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Dec 22, 2011 at 12:49 PM, Brian Kardell bkard...@gmail.com wrote: On Thu, Dec 22, 2011 at 3:15 PM, Dimitri

Re: [webcomponents]: First draft of the Shadow DOM Specification

2011-12-22 Thread Dimitri Glazkov
BTW, added an example: dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#shadow-dom-example :DG

Re: [webcomponents]: First draft of the Shadow DOM Specification

2011-12-23 Thread Dimitri Glazkov
DOMContentLoaded, FOUC is not an issue. The first paint will occur after the shadow subtrees are in place. :DG On Dec 22, 2011 8:16 PM, Brian Kardell bkard...@gmail.com wrote: Quick note :  That is the single best draft prose I have ever read :) On Dec 22, 2011 6:56 PM, Dimitri Glazkov

Re: [webcomponents]: First draft of the Shadow DOM Specification

2011-12-23 Thread Dimitri Glazkov
On Fri, Dec 23, 2011 at 10:37 AM, Brian Kardell bkard...@gmail.com wrote: On Dec 23, 2011 1:00 PM, Dimitri Glazkov dglaz...@chromium.org wrote: On Fri, Dec 23, 2011 at 5:23 AM, Brian Kardell bkard...@gmail.com wrote: In your example, you lost me on this part: // Insert Bob's shadow tree

[webcomponents]: Shadow DOM specification is now an Editor's Draft

2012-01-31 Thread Dimitri Glazkov
Dear public-webapps, The Shadow DOM specification is now a W3C Editor's Draft. I updated the spec to conform to PubRules. http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html Special thanks to Art for his cheerful guidance and advice. :DG

[webcomponents]: Shadow DOM specification is now an Editor's Draft

2012-01-31 Thread Dimitri Glazkov
Dear public-webapps, The Shadow DOM specification is now a W3C Editor's Draft. I updated the spec to conform to PubRules. http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html Special thanks to Art for his cheerful guidance and advice. :DG

Re: Installing web apps

2012-02-07 Thread Dimitri Glazkov
On Tue, Feb 7, 2012 at 5:31 AM, Robin Berjon ro...@berjon.com wrote: Hi all, On Feb 1, 2012, at 17:42 , Tim Berners-Lee wrote: On 2012-01 -20, at 14:32, Ian Hickson wrote Personally I think the idea of installing a Web app is anathema. You may, but others have a need for it. This is a hot

Re: April face-to-face meetings for WebApps

2012-02-07 Thread Dimitri Glazkov
On Tue, Feb 7, 2012 at 5:34 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 07 Feb 2012 13:55:59 +0100, Arthur Barstow art.bars...@nokia.com wrote: I am especially interested in whether Editors and Test Facilitators/Contributors will attend. Highly likely I'll attend. Me too. :DG

[webcomponents] Considering declarative event handlers

2012-02-07 Thread Dimitri Glazkov
Folks, To make Web Components more usable, I would like to consider providing a way to declare event handlers in markup. As I look over the use cases and try to implement them using the proposed syntax (http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html), a pattern emerges,

Re: [webcomponents] Considering declarative event handlers

2012-02-07 Thread Dimitri Glazkov
On Tue, Feb 7, 2012 at 12:05 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/7/12 2:41 PM, Dimitri Glazkov wrote: div class=overflow     script event=click         // this is the parent div element.         // event is the current event object.         if (event.target.className != 'more

Re: [webcomponents] Considering declarative event handlers

2012-02-07 Thread Dimitri Glazkov
On Tue, Feb 7, 2012 at 12:04 PM, Erik Arvidsson a...@google.com wrote: On Tue Feb 07 11:41:24 GMT-800 2012, Dimitri Glazkov dglaz...@chromium.org wrote: The pros are: * It's declarative and intuitively logical I think this is a cons. Now you need both markup and code where you only had

[webcomponents] HTML Parsing and the template element

2012-02-08 Thread Dimitri Glazkov
Hello folks! You may be familiar with the work around the template element, or a way to declare document fragments in HTML (see http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-November/033868.html for some background). In trying to understand how this newfangled beast would work, I

Re: [webcomponents] HTML Parsing and the template element

2012-02-08 Thread Dimitri Glazkov
On Wed, Feb 8, 2012 at 2:41 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Feb 8, 2012 at 2:00 PM, Dimitri Glazkov dglaz...@chromium.org wrote: == IDEA 1: Keep template contents parsing in the tokenizer == PRO: if we could come up with a way to perceive the stuff between template

  1   2   3   4   5   >