On May 1, 2015, at 10:46 AM, Travis Leithead travis.leith...@microsoft.com
wrote:
If you take a look at [1], we extend the custom elements registration
mechanism so that the constructor is still available in the hosting global,
yet the implementation is defined in the isolated environment
On Thu Apr 23 02:58 PM, Maciej Stachowiak wrote:
https://github.com/w3c/webcomponents/wiki/Isolated-Imports-Proposal
I welcome comments on whether this approach makes sense.
Security rules are unclear but love this approach
Hi everyone,
I wrote up a proposal (with input and advice from Ryosuke Niwa) on a possible
way to extend Web Components to support fully isolated components:
https://github.com/w3c/webcomponents/wiki/Isolated-Imports-Proposal
https://github.com/w3c/webcomponents/wiki/Isolated-Imports-Proposal
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28541
Bug ID: 28541
Summary: Custom elements should use ES6 class constructor
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
Status: NEW
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28545
Bug ID: 28545
Summary: Declarative syntax for custom elements
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28543
Bug ID: 28543
Summary: Custom elements should call user defined constructor
synchronously
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28544
Bug ID: 28544
Summary: Custom elements should not upgrade elements by setting
prototype
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
On Tue, Feb 24, 2015 at 4:35 PM, Dimitri Glazkov dglaz...@google.com wrote:
Wait, what do you mean by that is what custom elements provide for today..
The entire pattern of template-stamping depends on the fact that custom
elements aren't broken when cloning/importing.
There's no hook
is a good start as that is what custom elements provide for
today...
Wait, what do you mean by that is what custom elements provide for today..
The entire pattern of template-stamping depends on the fact that custom
elements aren't broken when cloning/importing.
:DG
...@annevk.nl
wrote:
On Tue, Feb 24, 2015 at 4:35 PM, Dimitri Glazkov dglaz...@google.com
wrote:
Wait, what do you mean by that is what custom elements provide for
today..
The entire pattern of template-stamping depends on the fact that custom
elements aren't broken when cloning/importing
On Tue, Feb 24, 2015 at 7:37 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Feb 24, 2015 at 4:35 PM, Dimitri Glazkov dglaz...@google.com
wrote:
Wait, what do you mean by that is what custom elements provide for
today..
The entire pattern of template-stamping depends on the fact
On 2/23/15 4:27 AM, Anne van Kesteren wrote:
1) If we run the constructor synchronously, even during cloning. If
the constructor did something unexpected, is that actually
problematic? It is not immediately clear to me what invariants we
might want to preserve. Possibly it's just that the code
/constructor were to run
asynchronously, it would still be observable.
In that regard, perhaps what we need another option (although 4 might be a
developer friendly superset of this):
5) Don't do anything. Custom elements will be broken upon cloning if there are
internal states other than
I've been continuing to explore synchronous constructors for custom
elements as they explain the parser best. After reading through
https://speakerdeck.com/vjeux/oscon-react-architecture I thought there
might be a performance concern, but Yehuda tells me that innerHTML
being faster than DOM
Dimitri: Okay, I can follow up with Ryosuke. I’m happy to share our thoughts
and needs for subclassing components.
Anne/Steve: I’d originally indicated that this technique couldn't be applied to
extending native HTML elements. Since the two of your seemed interested in
that, I spent some time
from what you want to solve, no?
The problem I think needs solving for minimum viable custom elements is
reducing reliance on bolt-on accessibility. From the example provided
http://janmiksovsky.github.io/base-template/ it appears that in this
instance it does achieve that end.
I don't know
On Thu, Feb 12, 2015 at 11:33 AM, Steve Faulkner
faulkner.st...@gmail.com wrote:
this turned up today:
A possible solution for web component subclasses
https://github.com/JanMiksovsky/base-template#a-possible-solution-for-web-component-subclasses
needs people who actually understand this
solution
for this, perhaps something like HTML modules, but shipping a v1 of
custom elements in multiple browsers should not have to wait for that.
It also does not address subclassing normal elements. Again, while
that seems desirable the current ideas are not attractive long term
solutions
On 12 February 2015 at 10:58, Anne van Kesteren ann...@annevk.nl wrote:
which is a very different problem from what you want to solve, no?
The problem I think needs solving for minimum viable custom elements is
reducing reliance on bolt-on accessibility. From the example provided
http
viable custom elements is
reducing reliance on bolt-on accessibility. From the example provided
http://janmiksovsky.github.io/base-template/
http://janmiksovsky.github.io/base-template/ it appears that in this
instance it does achieve that end.
I don't know whether this will extend
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27977
Bug ID: 27977
Summary: [Custom]: mixin pattern: custom elements should be
able to extend any base tag with is=
Product: WebAppsWG
Version: unspecified
Hardware: PC
As an example I made a simple input-based Custom Element which prevents
alphabetic input, and dropped it in an very simple Ember app.
Here's the version with a subclassed input:
http://jsbin.com/mevemu/1/edit?html,output
And the version with an input nested in a custom element:
Thanks for the mentioning the Ember issue Chris :) I've filed it here:
https://github.com/tildeio/htmlbars/issues/288
On Thu, Feb 5, 2015 at 7:13 AM, Chris Bateman chrisb...@gmail.com wrote:
As an example I made a simple input-based Custom Element which prevents
alphabetic input, and dropped it
On Feb 4, 2015, at 7:59 AM, Domenic Denicola d...@domenic.me wrote:
In IRC Anne and I were briefly discussing how type= is the is= of Web
Applications 1.0. That is, input type=date is similar to img is=x-gif
or similar---it has a reasonable fallback behavior, but in reality it is a
Yeah, I had noted in that post that wrapping a native element with a custom
element was an option - only drawback is that the markup isn't as terse (which
is generally advertised as one of the selling points of Custom Elements). But
that doesn't seem like a deal breaker to me, if subclassing
On 4 February 2015 at 16:51, Ryosuke Niwa rn...@apple.com wrote:
my-custom-formatterinput/my-custom-formatter
I think if this worked. i.e. hid the styling and allowed styling over top,
while allowing access to the input functionality would be a good solution
for the many many instances of
/Archives/Public/public-webapps/2015JanMar/0410.html
Since custom elements aren't supported by all browsers initially, authors have
to implement the fallback anyway.
I'm not certain having two different mechanisms, namely type and is
attributes, to specify the type of an input an element
:
Yeah, I had noted in that post that wrapping a native element with a
custom element was an option - only drawback is that the markup isn't as
terse (which is generally advertised as one of the selling points of Custom
Elements). But that doesn't seem like a deal breaker to me, if subclassing
needs
Bateman chrisb...@gmail.com
wrote:
Yeah, I had noted in that post that wrapping a native element with a
custom element was an option - only drawback is that the markup isn't as
terse (which is generally advertised as one of the selling points of
Custom
Elements). But that doesn't seem like a deal
On Feb 4, 2015, at 11:26 AM, Alice Boxhall aboxh...@google.com wrote:
So a web page author would write
x-slider min=-100 ... etc.
and then the custom element would sprout an input type=range ...etc with
the attribute values copied across?
No. The page author would write x-sliderinput
:41 PM, Chris Bateman chrisb...@gmail.com
mailto:chrisb...@gmail.com wrote:
Yeah, I had noted in that post that wrapping a native element with a custom
element was an option - only drawback is that the markup isn't as terse
(which is generally advertised as one of the selling points of Custom
On Feb 4, 2015, at 11:11 AM, Chris Bateman chrisb...@gmail.com wrote:
Ugh, I forgot about that. Without subclassing - terseness is a very minor
drawback, but remapping the interface is a big pain.
Could you give us a concrete use case in which remapping the interface is
necessary or
On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com wrote:
Yeah, I had noted in that post that wrapping a native element with a
custom element was an option - only drawback is that the markup isn't as
terse (which is generally advertised as one of the selling points of Custom
with a custom
element was an option - only drawback is that the markup isn't as terse
(which is generally advertised as one of the selling points of Custom
Elements). But that doesn't seem like a deal breaker to me, if subclassing
needs to be postponed.
Great to hear! We should make sure
:
On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com
wrote:
Yeah, I had noted in that post that wrapping a native element with a
custom element was an option - only drawback is that the markup isn't as
terse (which is generally advertised as one of the selling points of Custom
On 4 February 2015 at 19:05, Alice Boxhall aboxh...@google.com wrote:
So then how do we treat it as fallback content i.e. un-rendered, while
allowing it to be accessible to to the AT layer?
I suggest as in the working canvas example i provided, it not only be
exposed AT but also to keyboard
noted in that post that wrapping a native element with a custom
element was an option - only drawback is that the markup isn't as terse
(which is generally advertised as one of the selling points of Custom
Elements). But that doesn't seem like a deal breaker to me, if subclassing
needs
- only drawback is that the markup isn't as
terse (which is generally advertised as one of the selling points of Custom
Elements). But that doesn't seem like a deal breaker to me, if subclassing
needs to be postponed.
Chris
As I pointed out ealier:
input is=x-foo
x-fooinput/x-foo
seems
Assuming a situation where a native element – with custom functionality –
is dynamically injected into the page, the basic options I can think of are:
- input is=my-custom-formatter
- input class=my-custom-formatter and a page-level listener
- input class=my-custom-formatter and call a
On Wed, Feb 4, 2015 at 3:43 PM, Chris Bateman chrisb...@gmail.com wrote:
An better example of both A and B (than my previous hypothetical) might be
GitHub's time is=relative-time extension:
https://github.com/github/time-elements/.
FWIW, I do want subclassing of builtins to work. Maybe not
I hope others can address the question of why custom element callbacks are
useful, and meet the bar of being a feature we should add to the web platform
(with all the UA-coordination that requires). I just wanted to interject into
this input discussion.
In IRC Anne and I were briefly
/examples/demo-as-you-type.html
Thanks for a great use case. I think this is a problem we should solve
one way or another but I’m not convinced custom elements is the best
solution for the problem at hand.
If we accept that being able to specify the number of decimal points is a
valid use case, I
On Feb 3, 2015, at 7:13 AM, Chris Bateman chrisb...@gmail.com wrote:
Why don't we just make all input elements support these new attributes we're
adding?
In my opinion, I'd say because you can't possibly cover every case - what
about doing the same kind of formatting for social
On Sat, Jan 31, 2015 at 10:41 PM, Elliott Sprehn espr...@chromium.org wrote:
The animation is a custom element called paper-ripple, where do you see it
using -webkit-tap-highlight-color?
The initial page uses that. Ryosuke's reply to this particular demo is
a lot more on topic. It's not using
On Sat, Jan 31, 2015 at 7:40 PM, Chris Bateman chrisb...@gmail.com wrote:
The -webkit-appreance CSS is definitely another issue, so here's an example
with just JS behavior:
input is=number-input decimals=2
The way to do this, FWIW, is input type=number step=0.01 and solve
the styling issue.
this is a problem we should solve one way
or another but I’m not convinced custom elements is the best solution for the
problem at hand.
If we accept that being able to specify the number of decimal points is a valid
use case, I hope we can all agree that being able to specify the radix or the
base
On Sat, Jan 31, 2015 at 5:58 AM, fantasai fantasai.li...@inkedblade.net wrote:
-webkit-appearance: none isn't a proprietary extension, it's a prefixed
version of something that was once in a standards-track document. It
got removed because there were serious design problems with the original
On Sat, Jan 31, 2015 at 8:25 AM, Tantek Çelik tan...@cs.stanford.edu wrote:
I'm tracking the state of requests for 'appearance' here:
https://wiki.csswg.org/spec/css4-ui#appearance
Feel free to directly edit that wiki page and add more concrete data /
research that you think will help make a
On Fri, Jan 30, 2015 at 7:22 PM, Alice Boxhall aboxh...@google.com wrote:
Sure, that works for this example (which was created in a huge rush at the
last minute before a talk, like probably 90% of my productive work), but I
don't believe it wouldn't work for
, it's not at all clear
to me why that example needs custom elements to begin with. If we
assume this proprietary extension exists, we can just do this:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397
Which is much much simpler and requires none of the HTML imports,
shadow tree
not at all clear
to me why that example needs custom elements to begin with. If we
assume this proprietary extension exists, we can just do this:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397
Which is much much
not work reliably across browsers. Furthermore, it's not at all clear
to me why that example needs custom elements to begin with. If we
assume this proprietary extension exists, we can just do this:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397
[...]
So, I naively ask
why that example needs custom elements to begin with. If we
assume this proprietary extension exists, we can just do this:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397
[...]
So, I naively ask, what's stopping us from standardising something like
-webkit-appearance
On 29 January 2015 at 19:48, Ryosuke Niwa rn...@apple.com wrote:
And we have a proposal to do both of these things: decorators [1]
yes, indeed. What is the status of decorators? Last I looked, it had
been removed from the web components umbrella, so I thought it had
been sent to a farm upstate,
Anne wrote:
but do you see a viable way to get there?
I don't have enough technical understanding to know what is viable or not,
you and others are saying that the current accessibility feature support
baked in to custom elements spec via is= is not acceptable
To recap
What is= provides
could cause synchronous invocation of script as well.
This would give custom elements the same freedom as builtin elements.
We could even add a hook for popping of the end tag so you can emulate
the behavior of these elements: script, style, object, video, and
audio. I don't think there's a way to do
with everything Steve has said about accessibility. Extending
existing elements also gives us progressive enhancement potential.
Try https://rawgit.com/alice/web-components-demos/master/index.html in
Safari or IE. The second column isn't functional because it's using
brand new custom elements. The first
or IE. The second column isn't functional because it's using
brand new custom elements. The first column loses the web componenty
sparkles but remains functional because it extends existing HTML
elements.
There's a similar story with Opera Mini, which is used by at least
250m people
On Thu, Jan 29, 2015 at 3:54 PM, Steve Faulkner
faulkner.st...@gmail.com wrote:
I don't have enough technical understanding to know what is viable or not,
you and others are saying that the current accessibility feature support
baked in to custom elements spec via is= is not acceptable
I don't have enough technical understanding to know what is viable or not,
you and others are saying that the current accessibility feature support
baked in to custom elements spec via is= is not acceptable
That seems rather disingenuous.
where am I being disingenuous?
I don't
/alice/web-components-demos/master/index.html in
Safari or IE. The second column isn't functional because it's using
brand new custom elements. The first column loses the web componenty
sparkles but remains functional because it extends existing HTML
elements.
There's a similar story with Opera
elements also gives us progressive enhancement potential.
Try https://rawgit.com/alice/web-components-demos/master/index.html in
Safari or IE. The second column isn't functional because it's using
brand new custom elements. The first column loses the web componenty
sparkles but remains functional
On 29 January 2015 at 19:09, Brian Kardell bkard...@gmail.com wrote:
composition actually seems to let you express something equally good without
ambiguity more easily except insofar as giving you a really first-class
fallback option if you don't support JS, but... I'm having a really hard
accessibility feature support
baked in to custom elements spec via is= is not acceptable
That seems rather disingenuous.
where am I being disingenuous?
I don't understand how the various pieces are pulled together to make an
element work in browsers to an extent to be able to offer
-functional pages is vital for the people who don't use latest
greatest Chromium or Gecko browsers.
b
But in the context of custom elements (not shadow dom) these should be able
to do 'createdCallback' etc on the server... I can't really see any reason
why they couldn't/wouldn't.
--
Brian Kardell
have to accept some oddity in order to enable
custom elements. The Dmitry proposal seems to have the advantage in
that it creates the tree in the same manner and that there's a
plausible strategy for retrofitting normal elements to match its
design.
--
https://annevankesteren.nl/
write-barrier-style abstraction) still make sense. The JS that
implements the parser or DOM may desire to run the custom elements JS code
only in certain places (see Mutation Events - Mutation Observers).
If implementations are so desired, they could certainly do that. There is
nothing
accessible and usable by
people with disabilities, there are a lot of hoops developers must jump
through. [3] I think reducing this burden on the developer is a worthwhile
technical design consideration for Custom Element implementation in
browsers.
See the Custom Elements Semantics section
On 16 January 2015 at 10:25, Steve Faulkner faulkner.st...@gmail.com
wrote:
https://rawgit.com/alice/web-components-demos/master/index.html
apologies, this demo needs chrome to illustrate it working well.
--
Regards
SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/
developer ergonomics
compared to custom elements making it unlikely to be used much.
It may be that it is too hard to implement type extensions (i freely admit
much of the discussion on this thread is over my head), but I do not think
that it should be dismissed out of hand
On Thu, Jan 15, 2015 at 8:18 PM, Dimitri Glazkov dglaz...@google.com wrote:
Why is Not having identity at creation-time is currently a mismatch with
the rest of the platform a problem? Why does it all have to be consistent
across the board? Are there any other platform objects that are created
Hi Anne,
I have not suggested is= as the method that must be implemented (I have not
demanded anything), what I have tried to suggest is that minimum viable
custom elements with all accessibility as bolt-on is a poor solution by
design. From an acc view it means custom elements are nothing more
On Fri, Jan 16, 2015 at 2:29 AM, Ryosuke Niwa rn...@apple.com wrote:
And I'm suggesting to do the same (picking the simplest design) in HTML
custom elements by only supporting synchronous definition of elements, and
letting authors and frameworks decide how to upgrade existing elements
On Jan 16, 2015, at 9:58 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Jan 16, 2015 at 2:29 AM, Ryosuke Niwa rn...@apple.com wrote:
And I'm suggesting to do the same (picking the simplest design) in HTML
custom elements by only supporting synchronous definition of elements
to understand why
you guys don't think this software engineering best-practice applies to custom
elements. It seems like a textbook example of where inversion-of-control
applies.
(BTW I really recommend that Wikipedia article as reading for anyone
interested; it ties together in one place a lot
that then gets later replaced. Any script that needs to
store the reference or attach event listeners could simply wait until custom
elements dependencies are resolved or observe DOM mutations in the document.
After all, if authors are storing node references or attaching event listeners
prior
desire to run the custom elements JS code
only in certain places (see Mutation Events - Mutation Observers).
If your concern is that it would block the rendering of the page,
No, it is not.
If your concern is that authors must wait until other scripts that define
custom elements
No argument that callbacks are also a useful new addition.
:DG
be enthusiastic enough to support this motion since that's more or
less what I've been saying for the past six months or so.
I hope that we are iterating to a subset that everyone is happy with.
It would be great to get custom elements in all browsers. As far as I
can tell the main sticking point
:
On Wed, Jan 14, 2015 at 9:52 PM, Dimitri Glazkov dglaz...@google.com
wrote:
FWIW, I think that element upgrade is sort of fundamental to the
usefulness
of custom elements. In a world where most scripts are non-blocking
(that's
hopefully the modern world we should aim for), I'll effectively
On Wed, Jan 14, 2015 at 9:52 PM, Dimitri Glazkov dglaz...@google.com wrote:
FWIW, I think that element upgrade is sort of fundamental to the usefulness
of custom elements. In a world where most scripts are non-blocking (that's
hopefully the modern world we should aim for), I'll effectively
On Thu, Jan 15, 2015 at 5:12 PM, Kenneth Rohde Christiansen
kenneth.christian...@gmail.com wrote:
Anne, maybe you could write on the wiki what the current Web Components
implementation in Chrome is using. That would make it a bit easier to follow
for people who didn't follow all of the
Thanks, this is very useful!
On Thu Jan 15 2015 at 5:40:02 PM Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Jan 15, 2015 at 5:12 PM, Kenneth Rohde Christiansen
kenneth.christian...@gmail.com wrote:
Anne, maybe you could write on the wiki what the current Web Components
implementation
pretty reasonable given that we already have lots of cases where custom
elements do things sorta-async and native elements need to do things more
synchronously.
On Thu, Jan 15, 2015 at 12:27 PM, Ryosuke Niwa rn...@apple.com wrote:
On Jan 15, 2015, at 11:47 AM, Brian Kardell bkard...@gmail.com wrote:
Not to sidetrack the discussion but Steve Faulker made what I think was a
valid observation and I haven't seen a response... Did I miss it?
When and in
On Thu, Jan 15, 2015 at 8:03 AM, Anne van Kesteren ann...@annevk.nl wrote:
* I think we could iterate towards a v2 that has an aspect of
upgrading but perhaps works a bit differently from the current setup.
E.g. a way to include an entire subtree of custom elements with a
fallback mechanism
, but instead have to
override provided hooks.
If ES6 classes' constructor doesn't fundamentally work with custom elements,
then why don't we change the design of ES6 classes.
We would essentially be saying that the design of ES6 classes should be built
to support one particular construction pattern
Steve's concerns are best illustrated with a more complicated element like
button. He did a great pull request to the custom elements spec that
contrasts all the work you have to do with taco-button vs. button
is=tequila-button:
https://w3c.github.io/webcomponents/spec/custom/#custom-tag
in this article, but HTML only has h1–6. Currently,
without custom elements, I can do this:
div role=heading aria-level=7Cuora amboinensis, the southeast Asian box
turtle/div
Suppose instead that TedHaitchSeven is a subclass of HTMLElement and
I've registered it as ted-h7. In its constructor
is privileging the
native elements with some ability to jump to the front the queue. Which seems
pretty reasonable given that we already have lots of cases where custom
elements do things sorta-async and native elements need to do things more
synchronously.
Let's think about this for a minute
Not to sidetrack the discussion but Steve Faulker made what I think was a
valid observation and I haven't seen a response... Did I miss it?
On Thu, Jan 15, 2015 at 6:43 PM, Domenic Denicola d...@domenic.me wrote:
Steve's concerns are best illustrated with a more complicated element like
button. He did a great pull request to the custom elements spec that
contrasts all the work you have to do with taco-button vs. button
is=tequila
On Jan 15, 2015, at 3:17 PM, Domenic Denicola d...@domenic.me wrote:
From: Ryosuke Niwa [mailto:rn...@apple.com]
If ES6 classes' constructor doesn't fundamentally work with custom elements,
then why don't we change the design of ES6 classes.
We would essentially be saying
On Jan 14, 2015, at 12:52 PM, Dimitri Glazkov dglaz...@google.com wrote:
FWIW, I think that element upgrade is sort of fundamental to the usefulness
of custom elements. In a world where most scripts are non-blocking (that's
hopefully the modern world we should aim for), I'll effectively
On Jan 15, 2015, at 11:47 AM, Brian Kardell bkard...@gmail.com wrote:
Not to sidetrack the discussion but Steve Faulker made what I think was a
valid observation and I haven't seen a response... Did I miss it?
When and in which thread? Could you give us a pointer?
- R. Niwa
FWIW, I think that element upgrade is sort of fundamental to the usefulness
of custom elements. In a world where most scripts are non-blocking (that's
hopefully the modern world we should aim for), I'll effectively expect to
walk the tree anyway.
And if I walk the tree anyway, what's the point
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24579
On Wed, Jan 14, 2015 at 11:11 AM, Domenic Denicola d...@domenic.me wrote:
From: Erik Arvidsson [mailto:a...@google.com]
I'm not sure how that is speced but in Blink we have an extended IDL
attribute called CustomElementCallbacks which
On Jan 14, 2015, at 12:25 PM, Domenic Denicola d...@domenic.me wrote:
From: Ryosuke Niwa [mailto:rn...@apple.com]
Let me restate the problem using an example. Suppose we're parsing
my-element/my-elementmy-other-element/my-other-element.
Once the HTML is parsed, the DOM tree is
From: Erik Arvidsson [mailto:a...@google.com]
I'm not sure how that is speced but in Blink we have an extended IDL
attribute called CustomElementCallbacks which means that we are going to call
the pending callbacks after the method/setter.
If I recall this is how Anne and others were
On Jan 14, 2015, at 10:41 AM, Domenic Denicola d...@domenic.me wrote:
From: Ryosuke Niwa [mailto:rn...@apple.com]
See Boris' responses in another thread [1] and [2]. Jonas outlined how this
could work in the same thread [3]
Thanks for the references. But avoiding this problem is
201 - 300 of 642 matches
Mail list logo
