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 con

Re: Component Model Update

On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov wrote: > On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth 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 answer in previous discussions. >

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

On Thu, Aug 25, 2011 at 4:37 AM, Dimitri Glazkov wrote: > On Wed, Aug 24, 2011 at 12:19 PM, Erik Arvidsson wrote: >> On Wed, Aug 24, 2011 at 10:44, Dimitri Glazkov wrote: >>> What do you think? >> >> +1 >> >> It would surely allow certain use cases to be covered that are not >> covered today wit

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

On Thu, Aug 25, 2011 at 2:44 AM, Dimitri Glazkov 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 create one Shadow

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

On Thu, Aug 25, 2011 at 11:55 AM, Dimitri Glazkov wrote: > On Wed, Aug 24, 2011 at 2:44 PM, Dominic Cooney wrote: >> On Thu, Aug 25, 2011 at 2:44 AM, Dimitri Glazkov >> wrote: >>> All, >>> >>> Adam raises an interesting question: should we allow more t

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

On Thu, Aug 25, 2011 at 11:57 AM, Dimitri Glazkov wrote: > On Wed, Aug 24, 2011 at 2:38 PM, Dominic Cooney wrote: >> On Thu, Aug 25, 2011 at 4:37 AM, Dimitri Glazkov >> wrote: >>> On Wed, Aug 24, 2011 at 12:19 PM, Erik Arvidsson wrote: >>>> On Wed, Au

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

a good 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 wrote: >> On Thu, Aug 25,

Re: Component Model Update

On Thu, Aug 25, 2011 at 2:03 PM, John J Barton 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' thing on > ecmascript. That

Re: Component Model Update

Here is a quick first cut: How about use cases like these: - Extension that wants to inspect 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 and decorate it/fill

Re: Component Model Update

On Thu, Aug 25, 2011 at 5:41 PM, Olli Pettay 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 general

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 co

Re: Component Model Update

On Fri, Aug 26, 2011 at 12:42 AM, Roland Steiner wrote: > On Thu, Aug 25, 2011 at 4:24 PM, Dominic Cooney wrote: >> >> Here is a quick first cut: >> >> How about use cases like these: >> >> - Extension that wants to inspect 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 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 "decoration" you mean

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 behavi

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 th

Re: HTMLElement.register--giving components tag names

On Wed, Aug 31, 2011 at 1:38 PM, Erik Arvidsson wrote: > On Tue, Aug 30, 2011 at 22:33, Dominic Cooney 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 fiel

Re: HTMLElement.register--giving components tag names

On Sat, Sep 3, 2011 at 12:04 PM, Ian Hickson 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 spe

Notes from a component model pow-wow

imitri 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 dif

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

Re: HTML element content models vs. components

On Wed, Sep 28, 2011 at 3:39 PM, Roland Steiner 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 > (http://www.whatwg.org/specs/web-apps/current-work

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: … 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 improving her

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 , most of them would like to be block, or at maybe inline-block. One philoso

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

. wrote: > On Thu, Sep 29, 2011 at 6:38 PM, Dominic Cooney 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.   has auto-closing be

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

On Fri, Sep 30, 2011 at 12:36 PM, Ian Hickson wrote: > On Thu, 29 Sep 2011, Tab Atkins Jr. wrote: > > On Thu, Sep 29, 2011 at 7:05 PM, Dominic Cooney > wrote: > > > OK. > > > > > > I understand and are different in the respect of > > > automati

Re: Component Model f2f: Actionable things

On Sun, Nov 6, 2011 at 2:01 PM, Cameron McCormack 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 somewhat.

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 writ

Re: [Component Model] Decorator Challenges

On Wed, Nov 23, 2011 at 8:05 AM, Dimitri Glazkov 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 > from author’s perspective) constraints on the DOM tree, created by the > decorator. All of these co

Re: [Shadow DOM] Shadown DOM and Regions CSSOM

On Thu, Jun 21, 2012 at 6:23 PM, Andrei Bucur 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 NamedFlow

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 c

Re: Trialing Web Components

On Tue, Jul 10, 2012 at 12:21 PM, Dominic Cooney wrote: > 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

Re: [webcomponents] Custom Components and CSS Regions

On Wed, Dec 5, 2012 at 9:56 AM, Alan Stearns 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 - why might y

Re: [webcomponents] Custom Components and CSS Regions

On Fri, Dec 7, 2012 at 10:52 AM, Alan Stearns wrote: > >On 12/6/12 3:25 AM, "Dominic Cooney" wrote: > > > >>On Wed, Dec 5, 2012 at 9:56 AM, Alan Stearns wrote: > >> > >>... > >> > >>An insertion point is a element inside a sh

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 sol

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 wrote: > I wanted clarification on the meaning of @host rules [1] in combination > with the :scope pseudo selector [2]. > > Am I correct in

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Tue, Feb 26, 2013 at 2:51 AM, Dimitri Glazkov wrote: > On Mon, Feb 25, 2013 at 9:46 AM, Boris Zbarsky 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 contents (and then failing when

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

> On Feb 26, 2013 1:59 PM, "Tab Atkins Jr." wrote: > >> On Tue, Feb 26, 2013 at 10:44 AM, Dominic Cooney >> wrote: >> > Although the default provided by the spec is important, early adopters >> are >> > also important in shaping practice. There is ap

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Wed, Feb 27, 2013 at 4:03 AM, Boris Zbarsky 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 on an ad-h

Re: [webcomponents]: Making produce DocumentFragments

On Tue, Mar 12, 2013 at 8:13 AM, Dimitri Glazkov wrote: > Hi folks! > > Just had a quick discussion with Elliott and he suggested that instead of > building full-blown Documents, the just make > DocumentFragments, just like does. > I am confused by what you are proposing here. Templates "produ

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

On Tue, Mar 12, 2013 at 8:39 AM, Scott Miles 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 > proposal. > To g

Re: [webcomponents]: Making produce DocumentFragments

On Thu, Mar 14, 2013 at 5:14 AM, Dimitri Glazkov wrote: > > > > On Tue, Mar 12, 2013 at 10:20 PM, Dominic Cooney wrote: > >> On Tue, Mar 12, 2013 at 8:13 AM, Dimitri Glazkov wrote: >> >>> Hi folks! >>> >>> Just had a quick discussion with Elli

Re: [webcomponents]: Making produce DocumentFragments

On Fri, Mar 15, 2013 at 9:43 AM, Dimitri Glazkov wrote: > 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 > components in parallel.

[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 produce DocumentFragments

On Tue, Mar 19, 2013 at 1:19 AM, Dimitri Glazkov wrote: > > On Sun, Mar 17, 2013 at 1:46 PM, Elliott Sprehn wrote: > >> >> I'd rather like it if the spec said "the component document is a document >> that's always in standards mode and has no children" and then the contents >> of the component we

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

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

Re: [webcomponents]: Naming the Baby

"import" sounds good. Dominic On Thu, Mar 28, 2013 at 6:14 AM, Steve Orvell 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 loaded a

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

On Thu, Apr 11, 2013 at 5:53 AM, Erik Arvidsson 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 broken here? outer

Re: [webcomponents]: de-duping in HTMLImports

On Thu, Apr 11, 2013 at 4:41 PM, Scott Miles 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. >> >> That doe

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

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

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

s proposed, I think the differences are observable. > Anyway the group seems keen on inheritance so I hope it works out. > > > On Mon, Apr 15, 2013 at 11:24 PM, Dominic Cooney wrote: > >> On Sat, Apr 13, 2013 at 12:03 PM, John J Barton < >> johnjbar...@johnjbarton.co

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

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

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

On Tue, Jun 25, 2013 at 11:24 AM, Hayato Ito wrote: > On Tue, Jun 25, 2013 at 7:18 AM, Dimitri Glazkov > wrote: > > Dear WebAppelites, > > > > This past Friday, in always sunny (except when foggy) San Francisco, > > there has been a (totally not) s3kr3t gathering of minds > > (http://www.w3.org/

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

On Fri, Sep 27, 2013 at 2:27 PM, Daniel Buchner 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 > DOMComponentsLoa

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

On Sun, Sep 29, 2013 at 9:27 AM, Daniel Buchner 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 > DOMComponentsLoaded. Being notif

Re: [webcomponents] HTML Imports

On Thu, Oct 10, 2013 at 2:42 AM, Scott Miles wrote: > On Mon, Oct 7, 2013 at 3:24 AM, James Graham wrote: > >> 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 should you be able to access th

Re: Cross Origin Web Components: Fixing iframes

On Tue, Nov 26, 2013 at 2:03 PM, Ryosuke Niwa 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 > decisions. So I

Re: Cross Origin Web Components: Fixing iframes

On Wed, Nov 27, 2013 at 2:19 PM, Ryosuke Niwa wrote: > > On Nov 27, 2013, at 8:57 AM, Dominic Cooney wrote: > > On Tue, Nov 26, 2013 at 2:03 PM, Ryosuke Niwa wrote: > >> Hi, >> >> I have been having informal discussions of our earlier proposal for >>

Re: Cross Origin Web Components: Fixing iframes

On Wed, Dec 4, 2013 at 11:45 AM, Ryosuke Niwa wrote: > > On Nov 26, 2013, at 10:15 PM, Dominic Cooney wrote: > > On Wed, Nov 27, 2013 at 2:19 PM, Ryosuke Niwa wrote: > >> >> On Nov 27, 2013, at 8:57 AM, Dominic Cooney wrote: >> >> On Tue, Nov 2

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 wrote: > On Dec 6, 2013, at 5:01 PM, Ryosuke Niwa wrote: > > On Dec 6, 2013, at 1:20 AM, Brian Di Palma wrote: > > On Fri, Dec 6, 2013 at 3:24 AM, Ryosuke Niwa wrote: > > On Nov 12, 2013, at 12:45 AM, Ryosuke Niwa wrote: > > On Nov 12, 2013, at 8:

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

On Sat, Dec 7, 2013 at 3:44 PM, Maciej Stachowiak wrote: > > On Dec 6, 2013, at 7:41 PM, Elliott Sprehn wrote: > > > > > On Thu, Dec 5, 2013 at 5:37 PM, Ryosuke Niwa wrote: > > Hi, > > > > Given that many important/natural use cases of custom elements involve > shadow DOM, > > can we add a flag

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 wrote: > On Dec 5, 2013, at 10:09 PM, Hajime Morrita wrote: > > On inheritance around HTMLElement family, there seems to be a confusion > between interface side inheritance and implementation side inheritance. > > Right. Differentiating the two is ve

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 wrote: > > On Dec 7, 2013, at 4:38 PM, Dominic Cooney wrote: > > On Fri, Dec 6, 2013 at 3:34 PM, Ryosuke Niwa wrote: > >> On Dec 5, 2013, at 10:09 PM, Hajime Morrita wrote: >> > On inheritance around HTMLEleme

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 wrote: > On Dec 5, 2013, at 7:32 PM, Scott Miles 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 use of shadow DOM. > > > >

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 wrote: > On Dec 8, 2013, at 4:42 PM, Dominic Cooney wrote: > > On Sun, Dec 8, 2013 at 7:25 PM, Ryosuke Niwa wrote: >> >> On Dec 7, 2013, at 4:38 PM, Dominic Cooney wrote: >> >> On Fri, Dec 6, 2013 at 3:34 PM, Ryo

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

On Thu, Dec 12, 2013 at 5:17 AM, pira...@gmail.com wrote: > 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 Galaxy Note II > E

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

On Fri, Dec 13, 2013 at 2:29 AM, Brian Kardell wrote: > > On Dec 11, 2013 11:48 PM, "Ryosuke Niwa" wrote: > > > > > > On Dec 11, 2013, at 6:46 PM, Dominic Cooney wrote: > > > ... > >>> El 11/12/2013 21:10, "Edward O'Connor"

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

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

On Fri, Dec 13, 2013 at 5:59 PM, Maciej Stachowiak wrote: > > On Dec 7, 2013, at 4:38 PM, Dominic Cooney wrote: > > >> > Built-in HTML elements have lots of hooks to modify their behaviour (for > example, HTMLVideoElement's autoplay attribute.) The analogy is exten

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: x.setAttribute('a', 'b'); // before here ... If x is a Custom Element with an attributeChangedCallback, setAttribute will queue

Re: Custom-elements: document.registerPolyfillElement ?

On Mon, Jun 9, 2014 at 4:00 PM, Brett Zamir wrote: > I was looking to make a genuine polyfill for (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 means for polyfil

Re: CustomElement: Type extension on custom tag

Hi Joshua, I implemented Custom Elements in Chrome. In the 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: [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

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: > > Promise importDocument(DOMString url); > > > > I was thinking about Worker’s importScripts(DOMString…

Re: Custom Elements: insert/remove callbacks

On Thu, May 7, 2015 at 4:43 PM, Anne van Kesteren wrote: > On Wed, May 6, 2015 at 11:01 PM, Justin Fagnani > 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 elements' hook is "inserted into"/"removed

Re: Custom Elements: is=""

On Thu, Jul 2, 2015 at 3:59 PM, Ryosuke Niwa wrote: > > > On Jun 13, 2015, at 4:49 PM, Léonie Watson > wrote: > > > > From: Bruce Lawson [mailto:bru...@opera.com] > > Sent: 13 June 2015 16:34 > > > > On 13 June 2015 at 15:30, Léonie Watson > wrote: > >> why not use the extends= syntax you menti

Re: Custom Elements: "createdCallback" & cloning

On Thu, Jul 2, 2015 at 4:05 PM, Anne van Kesteren 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 JavaScript featu

Re: Custom Elements: "createdCallback" & cloning

On Mon, Jul 13, 2015 at 4:32 AM, Olli Pettay wrote: > On 07/12/2015 08:09 PM, Anne van Kesteren wrote: > >> On Fri, Jul 10, 2015 at 10:11 AM, Dominic Cooney >> wrote: >> >>> I think the most important question here, though, is not constructors or >>> p

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 recently. > > > > Unfortunately I won't be at

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 restr

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 element, > like ? No. I