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
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
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
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
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
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
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
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…
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
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
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
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,
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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,
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
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
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
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
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
.
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
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
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
]
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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'
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
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
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
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
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
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
77 matches
Mail list logo