Re: customized built-in element questions

On Sun, Aug 21, 2016 at 12:02 PM, Mark Giffin wrote: > I have two questions I cannot seem to find the answer to in the Custom > Elements spec, > https://www.w3.org/TR/2016/WD-custom-elements-20160721/ > > 1. Can I use the is= syntax for more than one customized built-in

Re: [Custom Elements] Should I write v1 Custom Elements in a way backwards compatible with v0 API?

I implemented custom elements in Chrome (twice.) This looks reasonable to me. The exact timing of createdCallback and constructor running, and errors around element creation, are different. If authors stick to the restrictions of custom elements "v1" they should be fine, because they're more

Re: Custom elements backing swap proposal

On Sat, Oct 24, 2015 at 4:02 PM, Ryosuke Niwa wrote: > > > On Oct 24, 2015, at 9:55 AM, Elliott Sprehn > wrote: > > > > I've been thinking about ways to make custom elements violate the > consistency principle less often and had a pretty awesome idea

Re: Custom Elements: createdCallback cloning

On Mon, Jul 13, 2015 at 4:32 AM, Olli Pettay o...@pettay.fi wrote: On 07/12/2015 08:09 PM, Anne van Kesteren wrote: On Fri, Jul 10, 2015 at 10:11 AM, Dominic Cooney domin...@google.com wrote: I think the most important question here, though, is not constructors or prototype swizzling. I

Re: Custom Elements: createdCallback cloning

On Thu, Jul 2, 2015 at 4:05 PM, Anne van Kesteren ann...@annevk.nl wrote: In the interest of moving forward I tried to more seriously consider Dmitry's approach. Based on es-discussion discussion https://esdiscuss.org/topic/will-any-new-features-be-tied-to-constructors it seems likely new

Re: Custom Elements: is=

On Thu, Jul 2, 2015 at 3:59 PM, Ryosuke Niwa rn...@apple.com wrote: On Jun 13, 2015, at 4:49 PM, Léonie Watson lwat...@paciellogroup.com wrote: From: Bruce Lawson [mailto:bru...@opera.com] Sent: 13 June 2015 16:34 On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com

Re: Custom Elements: insert/remove callbacks

On Thu, May 7, 2015 at 4:43 PM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, May 6, 2015 at 11:01 PM, Justin Fagnani justinfagn...@google.com wrote: How are you supposed to tell if one of your ancestors was removed? Is that a hook builtin elements have today? Blink's built-in

Re: [Imports] Considering imperative HTML imports?

On Thu, Apr 16, 2015 at 1:37 PM, Travis Leithead travis.leith...@microsoft.com wrote: Was an imperative form of HTML imports already considered? E.g., the following springs to mind: PromiseDocument importDocument(DOMString url); I was thinking about Worker’s importScripts(DOMString…

Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

On Fri, Mar 27, 2015 at 2:53 AM, Travis Leithead travis.leith...@microsoft.com wrote: Hi folks, Today’s ShadowDOM model is designed around only adding shadow roots to element in the ‘light side’. I assume this is intentional, but was hoping someone could describe why this design was

Re: CustomElement: Type extension on custom tag

Hi Joshua, I implemented Custom Elements in Chrome. In the definition construction algorithm http://www.w3.org/TR/custom-elements/#dfn-definition-construction-algorithm, step 8.2, it says: If BASE does not exist or is an interface for a custom element, set ERROR to InvalidName and stop. In

Re: Custom-elements: document.registerPolyfillElement ?

On Mon, Jun 9, 2014 at 4:00 PM, Brett Zamir bret...@gmail.com wrote: I was looking to make a genuine polyfill for dialog (not just a shim), and I found Polymer's CustomElements helpful, but realized too late that the spec required x- prefixes. I still feel like it would be useful to have a

Re: Custom element callbacks timing

My understanding is that these callbacks can be invoked at roughly two points in time: The first one is when the browser is about to return to script. An example is: script x.setAttribute('a', 'b'); // before here ... /script If x is a Custom Element with an attributeChangedCallback,

Re: [custom elements] Improving the name of document.register()

On Fri, Dec 13, 2013 at 5:44 PM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: I also really like defineElement. I am not sure that it is easy to understand what it actually means to register an element, where as defining an element is pretty clear. Kenneth On Fri, Dec

Re: [custom elements] Improving the name of document.register()

On Fri, Dec 13, 2013 at 2:29 AM, Brian Kardell bkard...@gmail.com wrote: On Dec 11, 2013 11:48 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 11, 2013, at 6:46 PM, Dominic Cooney domin...@google.com wrote: ... El 11/12/2013 21:10, Edward O'Connor eocon...@apple.com escribió: Hi

Re: [custom elements] Improving the name of document.register()

On Thu, Dec 12, 2013 at 5:17 AM, pira...@gmail.com pira...@gmail.comwrote: I have seen registerProtocolHandler() and it's being discused registerServiceWorker(). I believe registerElementDefinition() or registerCustomElement() could help to keep going on this path. Send from my Samsung

Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

On Tue, Dec 10, 2013 at 6:38 AM, Ryosuke Niwa rn...@apple.com wrote: On Dec 8, 2013, at 4:42 PM, Dominic Cooney domin...@google.com wrote: On Sun, Dec 8, 2013 at 7:25 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 7, 2013, at 4:38 PM, Dominic Cooney domin...@google.com wrote: On Fri, Dec 6

Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

On Sun, Dec 8, 2013 at 7:25 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 7, 2013, at 4:38 PM, Dominic Cooney domin...@google.com wrote: On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 5, 2013, at 10:09 PM, Hajime Morrita morr...@google.com wrote

Re: [webcomponents] Decoupling Custom Elements and Shadow DOM (Was Proposal for Cross Origin Use Case and Declarative Syntax)

On Fri, Dec 6, 2013 at 12:49 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 5, 2013, at 7:32 PM, Scott Miles sjmi...@google.com wrote: We don't think decoupling custom elements and shadow DOM completely is useful given that most important and natural use cases of custom elements involve the

Re: [webcomponents] Binding Custom Element without Polluting Global Scope (Was Proposal for Cross Origin Use Case and Declarative Syntax)

On Sat, Dec 7, 2013 at 10:06 AM, Ryosuke Niwa rn...@apple.com wrote: On Dec 6, 2013, at 5:01 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 6, 2013, at 1:20 AM, Brian Di Palma off...@gmail.com wrote: On Fri, Dec 6, 2013 at 3:24 AM, Ryosuke Niwa rn...@apple.com wrote: On Nov 12, 2013, at

Re: [webcomponents] Auto-creating shadow DOM for custom elements

On Sat, Dec 7, 2013 at 3:44 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 6, 2013, at 7:41 PM, Elliott Sprehn espr...@chromium.org wrote: On Thu, Dec 5, 2013 at 5:37 PM, Ryosuke Niwa rn...@apple.com wrote: Hi, Given that many important/natural use cases of custom elements

Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 5, 2013, at 10:09 PM, Hajime Morrita morr...@google.com wrote: On inheritance around HTMLElement family, there seems to be a confusion between interface side inheritance and implementation side inheritance. Right.

Re: Cross Origin Web Components: Fixing iframes

On Wed, Dec 4, 2013 at 11:45 AM, Ryosuke Niwa rn...@apple.com wrote: On Nov 26, 2013, at 10:15 PM, Dominic Cooney domin...@google.com wrote: On Wed, Nov 27, 2013 at 2:19 PM, Ryosuke Niwa rn...@apple.com wrote: On Nov 27, 2013, at 8:57 AM, Dominic Cooney domin...@google.com wrote: On Tue

Re: Cross Origin Web Components: Fixing iframes

On Tue, Nov 26, 2013 at 2:03 PM, Ryosuke Niwa rn...@apple.com wrote: Hi, I have been having informal discussions of our earlier proposal for cross-orign use cases and declarative syntax for web components, and I realized there was a lot of confusion about our motivations and decision

Re: Cross Origin Web Components: Fixing iframes

On Wed, Nov 27, 2013 at 2:19 PM, Ryosuke Niwa rn...@apple.com wrote: On Nov 27, 2013, at 8:57 AM, Dominic Cooney domin...@google.com wrote: On Tue, Nov 26, 2013 at 2:03 PM, Ryosuke Niwa rn...@apple.com wrote: Hi, I have been having informal discussions of our earlier proposal for cross

Re: [webcomponents] HTML Imports

On Thu, Oct 10, 2013 at 2:42 AM, Scott Miles sjmi...@google.com wrote: On Mon, Oct 7, 2013 at 3:24 AM, James Graham ja...@hoppipolla.co.ukwrote: On 06/10/13 17:25, Dimitri Glazkov wrote: And, if the script is executed against the global/window object of the main document, can and

Re: [webcomponents] Per-type ready event for Custom Elements

On Fri, Sep 27, 2013 at 2:27 PM, Daniel Buchner dan...@mozilla.com wrote: We're seeing issues with custom element ready state awareness under various common async load patterns like AMD, CommonJS, etc. Essentially, when a developer brings in their definitions via one of these systems, the

Re: [webcomponents] Per-type ready event for Custom Elements

On Sun, Sep 29, 2013 at 9:27 AM, Daniel Buchner dan...@mozilla.com wrote: WebComponentsReady is an event in the Polymer stack that fires when all known registered custom elements are ready for interaction - X-Tag has similar event (now just a hook into the polyfill's) called

Re: [webcomponents]: Shadow DOM + CSS = 3 Meeting Summary

On Tue, Jun 25, 2013 at 11:24 AM, Hayato Ito hay...@google.com wrote: On Tue, Jun 25, 2013 at 7:18 AM, Dimitri Glazkov dglaz...@google.com wrote: Dear WebAppelites, This past Friday, in always sunny (except when foggy) San Francisco, there has been a (totally not) s3kr3t gathering of

Re: Does JS bound to element need to inherit from HTMLElement?

On Fri, Apr 19, 2013 at 11:55 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Thu, Apr 18, 2013 at 11:11 PM, Dominic Cooney domin...@google.comwrote: On Wed, Apr 17, 2013 at 12:01 AM, John J Barton johnjbar...@johnjbarton.com wrote: I wonder if there may be a cultural difference

Re: Does JS bound to element need to inherit from HTMLElement?

I hope it works out. On Mon, Apr 15, 2013 at 11:24 PM, Dominic Cooney domin...@google.comwrote: On Sat, Apr 13, 2013 at 12:03 PM, John J Barton johnjbar...@johnjbarton.com wrote: While I completely understand the beauty of having any JS object bound to an element inherit functions

Re: Does JS bound to element need to inherit from HTMLElement?

On Sat, Apr 13, 2013 at 12:03 PM, John J Barton johnjbar...@johnjbarton.com wrote: While I completely understand the beauty of having any JS object bound to an element inherit functions that make that object 'be an element', I'm unsure of the practical value. To me the critical relationship

Re: [webcomponents]: Re-imagining shadow root as Element

On Thu, Apr 11, 2013 at 5:53 AM, Erik Arvidsson a...@chromium.org wrote: For the record I'm opposed to what you are proposoing. I don't like that you lose the symmetry between innerHTML and outerHTML. Sorry for replying to such a cold thread. Could you elaborate on what symmetry is being

Re: [webcomponents]: de-duping in HTMLImports

On Thu, Apr 11, 2013 at 4:41 PM, Scott Miles sjmi...@google.com wrote: On Thu, Apr 11, 2013 at 12:33 AM, Angelina Fabbro angelinafab...@gmail.com wrote: I don't believe it's *needed* exactly, but we imagined somebody wanting to import HTML, use it destructively, then import it again.

Re: [webcomponents]: Naming the Baby

import sounds good. Dominic On Thu, Mar 28, 2013 at 6:14 AM, Steve Orvell sorv...@google.com wrote: Err, yeah, thanks for pointing that out. I also like import or imports. This makes sense given that the rel attribute is described as defining the relationship between the resource being

Re: [webcomponents] Adjusting offsetParent, offsetTop, offsetLeft properties in Shadow DOM

On Sun, Mar 24, 2013 at 3:50 PM, Elliott Sprehn espr...@gmail.com wrote: On Mon, Mar 18, 2013 at 4:48 AM, Dominic Cooney domin...@chromium.orgwrote: ... I think the offset{Parent, Top, Left} properties should be adjusted. This means that in the above example, b.offsetParent would be body

[webcomponents] Adjusting offsetParent, offsetTop, offsetLeft properties in Shadow DOM

Summary: I think the Shadow DOM spec should specify how offset* properties are handled around shadows. Further, I think traversable and non-traversable shadows should be handled uniformly. The offsetParent property should return the first offsetParent at the same level of shadow as the receiver,

Re: [webcomponents]: Making link rel=components produce DocumentFragments

On Fri, Mar 15, 2013 at 9:43 AM, Dimitri Glazkov dglaz...@google.comwrote: Here's one scenario where keeping components Documents might be a good idea. Suppose you just built a multi-threaded parser into your renderer engine, and you would like to hook it up to start loading multiple

Re: [webcomponents]: Making link rel=components produce DocumentFragments

On Thu, Mar 14, 2013 at 5:14 AM, Dimitri Glazkov dglaz...@google.comwrote: On Tue, Mar 12, 2013 at 10:20 PM, Dominic Cooney domin...@google.comwrote: On Tue, Mar 12, 2013 at 8:13 AM, Dimitri Glazkov dglaz...@google.comwrote: Hi folks! Just had a quick discussion with Elliott and he

Re: [webcomponents]: Making link rel=components produce DocumentFragments

On Tue, Mar 12, 2013 at 8:13 AM, Dimitri Glazkov dglaz...@google.comwrote: Hi folks! Just had a quick discussion with Elliott and he suggested that instead of building full-blown Documents, the link rel=components just make DocumentFragments, just like template does. I am confused by what

Re: [webcomponents]: First stab at the Web Components spec

On Tue, Mar 12, 2013 at 8:39 AM, Scott Miles sjmi...@google.com wrote: My issue is that the target of this link will not in general be an atomic thing like a 'component' or a 'module'. It's a carrier for resources and links to other resources. IMO this is one of the great strengths of this

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Tue, Feb 26, 2013 at 2:51 AM, Dimitri Glazkov dglaz...@chromium.orgwrote: On Mon, Feb 25, 2013 at 9:46 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/25/13 12:33 PM, Tab Atkins Jr. wrote: If a script is explicitly looking inside the shadows of unknown controls and checking their

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

. On Feb 26, 2013 1:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Feb 26, 2013 at 10:44 AM, Dominic Cooney domin...@chromium.org wrote: Although the default provided by the spec is important, early adopters are also important in shaping practice. There is apparently strong conviction

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Wed, Feb 27, 2013 at 4:03 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/26/13 1:57 PM, Tab Atkins Jr. wrote: An argument to the contrary (which you do seem to acknowledge later in your message, if I'm reading correctly): if you make shadow private, but allow authors to make them public

Using Shadow DOM @host rule with :scope pseudo-selector

I wanted clarification on the meaning of @host rules [1] in combination with the :scope pseudo selector [2]. Am I correct in assuming that if I wanted to style the host element, and only the host element, I could apply these features in combination this way? @host { :scope { border: 1px

Re: Using Shadow DOM @host rule with :scope pseudo-selector

] https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#host-at-rule On Fri, Feb 1, 2013 at 12:10 PM, Dominic Cooney domin...@google.com wrote: I wanted clarification on the meaning of @host rules [1] in combination with the :scope pseudo selector [2]. Am I correct in assuming

Re: [webcomponents] Custom Components and CSS Regions

On Fri, Dec 7, 2012 at 10:52 AM, Alan Stearns stea...@adobe.com wrote: On 12/6/12 3:25 AM, Dominic Cooney domin...@google.com wrote: On Wed, Dec 5, 2012 at 9:56 AM, Alan Stearns stea...@adobe.com wrote: ... An insertion point is a content element inside a shadow DOM subtree

Re: [webcomponents] Custom Components and CSS Regions

On Wed, Dec 5, 2012 at 9:56 AM, Alan Stearns stea...@adobe.com wrote: There are some similarities between Web Components insertion points and CSS Regions. Both facilities allow you to project content from one element into another. I'd like to compare the two when used inside custom components

Re: Trialing Web Components

I can comment on the status of Web Components in Chromium: - Large parts of the Shadow DOM spec are implemented, but you have to enable them in about:flags first (ctrl-f and search for Shadow DOM). More is available in more recent versions (for example Google Chrome Canary or Google Chrome dev

Re: Trialing Web Components

On Tue, Jul 10, 2012 at 12:21 PM, Dominic Cooney domin...@google.comwrote: I can comment on the status of Web Components in Chromium: - Large parts of the Shadow DOM spec are implemented, but you have to enable them in about:flags first (ctrl-f and search for Shadow DOM). More is available

Re: [Shadow DOM] Shadown DOM and Regions CSSOM

On Thu, Jun 21, 2012 at 6:23 PM, Andrei Bucur abu...@adobe.com wrote: Hello, This is a cross-post from the www-style discussion list in case anyone is interested about this subject: Currently the CSS Regions spec doesn't mention what happens with regions that are part of a shadow tree. The

Re: [Component Model] Decorator Challenges

On Wed, Nov 23, 2011 at 8:05 AM, Dimitri Glazkov dglaz...@chromium.orgwrote: 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 from author’s perspective) constraints on the DOM tree, created by the

Re: State of subclassing and tag names in the component model

Hi Boris, This is my current thinking, although this blends/steals a lot of ideas from TPAC: There are two kinds of components—ones that are a refinement of something in HTML, like a select element or a button; and ones that have no genuine peer in HTML. This is the litmus test: If you were

Re: Component Model f2f: Actionable things

On Sun, Nov 6, 2011 at 2:01 PM, Cameron McCormack c...@mcc.id.au wrote: Would you be able to post the code from the blog post comment example? Here it is what you saw, with some irrelevant parts removed. Just to set expectations: this was already two months old, so it lags our current thinking

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

So, to make this really explicit: div’s default display is block, but x-div’s default display is inline. Is there anything else that I missed? Looking at use cases http://wiki.whatwg.org/wiki/Component_Model_Use_Cases, most of them would like to be block, or at maybe inline-block. One

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

at 10:53 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Sep 29, 2011 at 6:38 PM, Dominic Cooney domin...@google.com wrote: So, to make this really explicit: div’s default display is block, but x-div’s default display is inline. Is there anything else that I missed? Not quite.  p has auto

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

On Fri, Sep 30, 2011 at 12:36 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 29 Sep 2011, Tab Atkins Jr. wrote: On Thu, Sep 29, 2011 at 7:05 PM, Dominic Cooney domin...@google.com wrote: OK. I understand div and x-foo are different in the respect of automatically closing p-s

Re: HTML element content models vs. components

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 content model of HTML elements. Take for example a list

Dynamic behavior attachment does not work, subtyping elements could work (Was: Re: Behavior Attachment Redux, was Re: HTML element content models vs. components)

Hixie wrote: snip … The pure JS side of things, which is all that is needed for what we're talking about here, needs nothing more than just adding a prototype, something which is not only well-supported by all browsers, but defined in increasingly careful detail. Interoperability is only

Should the shadow host element be rendered? (Was: Re: Notes from a component model pow-wow)

Tab: How well is display: transparent received, eg on www-style? I have a feeling this question—whether to render the host or not—depends on whether you are using shadow DOM with components, or with existing elements. When you want to use shadow DOM with components, the current solution seems OK

Notes from a component model pow-wow

Glazkov dpc--Dominic Cooney (me) hyatt--Dave Hyatt jamesr--James Robinson maciej--Maciej Stachowiak rs--Roland Steiner sam--Sam Weinig sicking--Jonas Sicking slightlyoff--Alex Russell plus others who I failed to log--sorry dg: wanted to implement XBL2, 2 years later, slightlyoff (dojo) had different

Re: HTMLElement.register--giving components tag names

On Sat, Sep 3, 2011 at 12:04 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 30 Aug 2011, Dominic Cooney wrote: I'm proposing we add something that lets script extend the set of tag names, so there is less of a bright line between elements defined in the HTML spec and elements defined in script

Re: xdash name prefixes (was Re: Component Model Update)

I think for convenience registration probably should be carried around with the component, because: 1. It is convenient for the author using the component. 2. If the component library reuses its own abstractions, it probably expects them to have a specific element name. Putting registration in

Re: HTMLElement.register--giving components tag names

On Wed, Aug 31, 2011 at 1:38 PM, Erik Arvidsson a...@chromium.org wrote: On Tue, Aug 30, 2011 at 22:33, Dominic Cooney domin...@chromium.org wrote: You will notice that this says nothing about how prototypes are wired up. It should. Maybe the argument to extend should have an optional second

HTMLElement.register--giving components tag names

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 pulls new contacts from the server. Components also need to hook up internal behavior

Re: Components/constructable DOM elements: mandatory tag registration?

I think HTMLElement.call should throw if there’s not an associated tag name. However exactly how that association happens, I am not sure. JavaScript can’t rely on the 'constructor' property. Shadowing the tagName attribute on the prototype is not ideal, because it may be mutable and it would be

Re: Component Model Update

On Fri, Aug 26, 2011 at 12:42 AM, Roland Steiner rolandstei...@google.com wrote: On Thu, Aug 25, 2011 at 4:24 PM, Dominic Cooney domin...@google.com wrote: Here is a quick first cut: How about use cases like these: - Extension that wants to inspect input type=password and warn you when you

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

On Fri, Aug 26, 2011 at 12:24 AM, Roland Steiner rolandstei...@google.com wrote: Unless I'm misunderstanding something, I believe this actually is - or at least touches upon - several questions in disguise: .) Do we want to allow decoration of elements that are already in the DOM tree? If by

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

On Thu, Aug 25, 2011 at 11:55 AM, Dimitri Glazkov dglaz...@chromium.org wrote: 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

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

On Thu, Aug 25, 2011 at 11:57 AM, Dimitri Glazkov dglaz...@chromium.org wrote: 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

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

plan. If we come up with use cases, we can reevaluate in the light of new ideas. Even if new use cases prove compelling, starting with a single shadow is probably still a good approach anyway. Dominic On Wed, Aug 24, 2011 at 2:38 PM, Dominic Cooney domin...@google.com wrote: On Thu, Aug 25, 2011

Re: Component Model Update

On Thu, Aug 25, 2011 at 2:03 PM, John J Barton johnjbar...@johnjbarton.com wrote: I'm still trying to digest this, but it seem pretty clear the 'confinement' is the clear scope thing I was asking about on es-discuss.  According to that discussion, this means needs to fit with the 'modules'

Re: Component Model Update

Here is a quick first cut: How about use cases like these: - Extension that wants to inspect input type=password and warn you when you are entering you password in an insecure form (from abarth earlier in the thread.) - Password manager that wants to find anything that looks like a login panel

Re: Component Model Update

On Thu, Aug 25, 2011 at 5:41 PM, 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: * Created a

Re: Component Model Update

On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth w...@adambarth.com wrote: I feel somewhat like I'm walking into the middle of a movie, but I have a couple questions.  Please forgive me if my questions have already been

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

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...@chromium.org wrote: What do you think? +1 It would surely allow certain use cases

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

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 (http://wiki.whatwg.org/wiki/Component_Model#Encapsulation), you can only

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

Element.create looks neat. Three thoughts: First, I think Element.create *and* constructors like new HTMLDivElement(attributes, children) are both useful. Element.create is good when you have a tag name in hand, are creating unknown elements, or are creating elements that don’t have a specific