I have two questions:
1. Does this affect our ability to polyfill doc.register in current
browsers?
2. Are you saying we're going to nix the ability to easily register
insertion, removal, and attribute change callbacks from the API?
I believe #2 is very important and should not be
*
So this won't work?*
var MyButton = document.register(‘x-mybutton’, {
prototype: Object.create(HTMLButtonElement.prototype, { ... })
});
class MySuperButton extends MyButton { ... };
document.register('x-superbutton', MySuperButton);
*But this will?*
function MyButton() {
On Wed, Feb 6, 2013 at 9:03 AM, Erik Arvidsson a...@chromium.org wrote:
On Tue, Feb 5, 2013 at 8:26 PM, Daniel Buchner dan...@mozilla.com wrote:
I have two questions:
Does this affect our ability to polyfill doc.register in current
browsers?
Good point. This is really important to us
Scott: is this example not intended to work in IE9? It throws, the output
object is missing the 'oranginate' method.
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Wed, Feb 6, 2013 at 12:32 PM, Scott Miles sjmi...@google.com wrote:
There were several errors in
__proto__.
On Wed, Feb 6, 2013 at 12:41 PM, Daniel Buchner dan...@mozilla.com
wrote:
Scott: is this example not intended to work in IE9? It throws, the
output
object is missing the 'oranginate' method.
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
Corporation
On Wed, Feb 6, 2013 at 1:34 PM, Scott Miles sjmi...@google.com wrote:
On Wed, Feb 6, 2013 at 1:27 PM, Daniel Buchner dan...@mozilla.com wrote:
So you're directly setting the user-added methods on matched elements in
browsers that don't support proto, but what about accessors
. The reason I'm not freaking out
about defineProperties is IMO because I can avoid it when I don't need it
(which is about 99% of the time).
Scott
On Wed, Feb 6, 2013 at 1:50 PM, Daniel Buchner dan...@mozilla.com wrote:
I just made sure it worked, and it does. As for developers freaking out,
I
is *necessary* for IE
compatibility. I'm 80% sure it is not.
S
On Wed, Feb 6, 2013 at 2:10 PM, Daniel Buchner dan...@mozilla.com wrote:
I guess it isn't a show stopper for poly-*ish*-fills, I would just wrap
the native document.register method where it is present sniff the
incoming prototype
Scott is right, there isn't a great polyfill answer for this part of the
spec, but fortunately it doesn't affect too potential many use-cases.
Developers will still go bananas for the functionality we can provide in
legacy UA versions.
- Daniel
On Feb 7, 2013 8:51 PM, Scott Miles
I love it, gives the developer control over the addition of sugar (just a
spoonful of...) and code preference, while at the same time addressing our
requirement set. Ship it!
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Thu, Feb 14, 2013 at 1:48 PM, Dimitri
It seems to me (please correct me if this is inaccurate) that you can't *
really* polyfill ES6 extension of existing element constructor inheritance,
because afaik, you cannot call the existing native constructors of elements
- it throws. So if you can only do a jankified 1/2 fill, why not just
the user has to do is *not* call it, and only call super constructors
if they are custom.
For that reason, I don't see why this is an issue.
Or if you want you can polyfill HTMLButtonElement.call.
HTMLButtonElement.call = function() {};
On Thu, Feb 14, 2013 at 2:36 PM, Daniel Buchner dan
The polyfill rabbit hole of half-hearted, faux-ES6 polyfilling of
constructor inheritance seems to be far deeper than both conceptually in
code-level affect than our simple examples show. Further, what is so sexy
about forcing the pattern when we can't, hard stop, no-way, polyfill *class
*and
No, I believe this is *precisely *the thing to worry about - these nits and
catch-case gotchas are the sort of things developers see in an emerging
API/polyfill and say awe, that looks like an fractured, uncertain hassle,
I'll just wait until it is native in all browsers -- we must avoid this
at
What does it actually profit us to singularly tie document.register to
require an ES6-esque syntax before it lands anyway? No one is saying not to
use it *when it arrives*, we're offering a way to make sure the polyfill
layer isn't needlessly bound to inconsequential externalities.
Hell, if you
I'm not sure I buy the idea that two ways of doing the same thing does not
seem like a good approach - the web platform's imperative and declarative
duality is, by nature, two-way. Having two methods or an option that takes
multiple input types is not an empirical negative, you may argue it is an
, 2013 at 8:42 AM, Daniel Buchner dan...@mozilla.com
wrote:
I'm not sure I buy the idea that two ways of doing the same thing does
not
seem like a good approach - the web platform's imperative and
declarative
duality is, by nature, two-way. Having two methods or an option that
takes
multiple
it pathological to make the 'non
constructor-returning API' return a constructor?
On Mon, Feb 18, 2013 at 12:59 PM, Daniel Buchner dan...@mozilla.comwrote:
I agree with your approach on staging the two specs for this, but the
last part about returning a constructor in one circumstance and undefined
, but how does the system know what
localName to use? I believe the notion was that the localName would be
inferred from the prototype, but there are various semantic tags that share
prototypes, so it seems ambiguous in these cases.
S
On Tue, Feb 19, 2013 at 1:01 PM, Daniel Buchner dan
(HTMLElement.prototype);
Afaict, the 'headerness' cannot be expressed this way.
On Tue, Feb 19, 2013 at 8:34 PM, Daniel Buchner dan...@mozilla.comwrote:
Wait a sec, perhaps I've missed something, but in your example you never
extend the actual native header element, was that on purpose? I was under
Ready/created, inserted, removed, and attributeChanged are the minimum
must-havs for developers - we heavily rely on each one of these callbacks
in the components we've developed thus far. The usefulness of this API is
neutered without these hooks - they're table stakes, plain and simple.
Jonas,
, Mar 11, 2013 at 11:55 AM, Daniel Buchner dan...@mozilla.com wrote:
Ready/created, inserted, removed, and attributeChanged are the minimum
must-havs for developers - we heavily rely on each one of these callbacks
in the components we've developed thus far. The usefulness of this API is
neutered
Just to be clear, these are callbacks (right?), meaning synchronous
executions on one specific node. That is a far cry from the old issues
with mutation events and nightmarish bubbling scenarios.
Where does bubbling come in?
- I thought the concern was over the same issues that plagued
inserted and removed can probably be end of micro task, but
attributeChanged definitely needs to be synchronous to model the behavior
of input type where changing it from X to Y has an immediate effect on
the APIs available (like stepUp).
Actually, I disagree. Attribute changes need not be
have in
addressing the case Elliot presents?
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Mon, Mar 11, 2013 at 2:42 PM, Elliott Sprehn espr...@gmail.com wrote:
On Mon, Mar 11, 2013 at 2:32 PM, Daniel Buchner dan...@mozilla.comwrote:
inserted and removed can
*Daniel can confirm but in all of the stuff i have seen and played with so
far it is...you want a changing a component attribute to have some effect.
Internally you would use mutation observers i think.*
-
We have built quite a few custom elements now, and here's the
role/behaviors of
What about obscured, opaque, invisible, or restricted?
On Tue, Mar 12, 2013 at 3:34 PM, Alan Stearns stea...@adobe.com wrote:
On 3/12/13 2:41 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 3/12/13 5:19 PM, Dimitri Glazkov wrote:
However, to allow developers a degree of enforcing integrity of
I have a counter proposal that takes into a count both the easy-to-declare,
1-to-1 case, as well as the 1-template-to-many-elements case:
https://gist.github.com/csuwldcat/5358039
I can explain the advantages a bit more in an hour or so, I just got pulled
into a meeting...le sigh.
Daniel J.
certainly doesn't exclude that
ability/use case (or so I thought - correct if wrong)
Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation
On Wed, Apr 10, 2013 at 1:27 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Wed, Apr 10, 2013 at 4:15 PM, Daniel Buchner dan
/5358612 ?
On Wed, Apr 10, 2013 at 1:43 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Wed, Apr 10, 2013 at 4:38 PM, Daniel Buchner dan...@mozilla.comwrote:
*What about CSP that forbids inline
scripts?https://wiki.mozilla.org/Apps/Security#Default_CSP_policy
*
Is there any reason
templates.
On Wed, Apr 10, 2013 at 8:19 PM, Daniel Buchner dan...@mozilla.com wrote:
Here are a few (compelling?) answers/arguments:
1. Style elements had never done this before, yet it rocks socks:
style scoped
2. It would be new for script elements, but hardly new for other
Here are a few (compelling?) answers/arguments:
1. Style elements had never done this before, yet it rocks socks: style
scoped
2. It would be new for script elements, but hardly new for other
elements. There are plenty of elements that have various behaviors or
visual
, Apr 10, 2013 at 9:00 PM, Daniel Buchner dan...@mozilla.comwrote:
It's incredibly important that we agree that association of a template
with element happens on the element side, something like: element
template=foo-template (or by placing the template inside element, if
that is the API we want
Err...polyfill doesn't mean you can do something via a different route that
produces a similar outcome, it means you back fill the API so that you can
use 1:1 syntax that never needs to know if the evn supports the native
underlying API or not.
I don't mean to disparage ES6 - as a former
just replace the global constructor. That might be OK, and
we can detect this override to register the class as needed.
2. Prefixing with HTML seems like an anti pattern.
On Fri, Apr 12, 2013 at 5:08 PM, Daniel Buchner dan...@mozilla.comwrote:
@John - what about what I just sent through
On Fri, Apr 12, 2013 at 3:20 PM, Dimitri Glazkov dglaz...@google.comwrote:
2) since we do have to live with generated constructors -- at least
for a little while, we have two decoupled operations:
a) create prototype
b) generate constructor.
Is this order required? Can we not generate the
* Here are four ways to avoid the subclassing problem for custom elements
*
* 1) Only allow instances of custome dom elements to be instantiated
using document.createElement(x-foo).
*
*
*
*Wearing web developer hat, I never make elements any other way than
createElement (or HTML), so this would
*At least somebody explain why this is conceptually wrong.
*
Nothing is conceptually wrong with what you've stated Scott. I could live
with a prototype element that is scoped to the element as long as there
was some sort of 'registeredCallback' (as you previously alluded to many
posts back) that
*How, as component author, do I ensure that my imperative set up code runs
and modifies my element DOM content before the user sees the un-modified
custom element declared in mark-up? (I'm cheating, since this issue isn't
specific to your prototype) *
When you say ...runs before the user sees the
*
*
*Gee, that's not very encouraging: this is the most important kind of issue
for a developer, more so than whether the API is inheritance-like or not.*
IMO, the not-yet-upgraded case is nothing new, and developers will hardly
be surprised. This nit is no different than if devs include a jQuery
parsing, just wait for them to arrive, then call them. Something
else is going on I suppose, so I'm just wasting your time.
On Mon, Apr 15, 2013 at 2:42 PM, Daniel Buchner dan...@mozilla.comwrote:
*
*
*Gee, that's not very encouraging: this is the most important kind of
issue for a developer
*I am going to offer a cop-out option: maybe we simply don't offer
imperative syntax as part of the spec?
*
Why would we do this if the imperative syntax is solid, nicely
compatible, and relatively uncontentious? Did you mean to say declarative?
Daniel J. Buchner
Product Manager, Developer
that use case for the web of today?
On Tue, Apr 16, 2013 at 3:02 PM, Dimitri Glazkov dglaz...@google.comwrote:
On Tue, Apr 16, 2013 at 3:00 PM, Daniel Buchner dan...@mozilla.com
wrote:
I am going to offer a cop-out option: maybe we simply don't offer
imperative syntax as part of the spec
presumably make that association, if it needed to.*
On Tue, Apr 16, 2013 at 3:47 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Apr 16, 2013, at 3:13 PM, Dimitri Glazkov wrote:
On Tue, Apr 16, 2013 at 3:07 PM, Daniel Buchner dan...@mozilla.com
wrote:
One thing I've heard from many of our
*This is just a repackaging of Object.defineProperties( target,
PropertyDescriptors ) thats slightly less obvious because the target
appears to be a string.
*
Is another difference that the 'x-foo' doesn't have to be 'known' yet? It
seems to be a bit more than a repack of Object.defineProperties
Waldron waldron.r...@gmail.comwrote:
On Wed, Apr 17, 2013 at 6:59 PM, Daniel Buchner dan...@mozilla.comwrote:
*This is just a repackaging of Object.defineProperties( target,
PropertyDescriptors ) thats slightly less obvious because the target
appears to be a string.
*
Is another difference
.
Rather, at some third quantum of time a combination of those things is
constructed, keyed on 'element name'.
Most of the rest is syntax, subject to bikeshedding when and if the main
idea has taken root.
On Wed, Apr 17, 2013 at 4:33 PM, Daniel Buchner dan...@mozilla.comwrote:
So let me
it - but I guess that's what separates us
less-intelligent simpletons from Jedi like yourself.
Have a wonderful evening Rick.
On Wed, Apr 17, 2013 at 8:46 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Wed, Apr 17, 2013 at 7:33 PM, Daniel Buchner dan...@mozilla.comwrote:
So let me be *crystal
As some of you are aware, a widget spec or two (
http://www.w3.org/TR/2012/PR-widgets-apis-20120522/) have been floating
around for a while. These were never widely adopted for various reasons -
not the least of which was their complexity.
Well, hold on to your shorts folks: I would like to
In my opinion, the current spec's complexity in relation to its feature
goal, is high. This doesn't mean it was a bad spec or deficient, it could
be due to a number of factors: different assumptions about what widgets
should do, packaging choices that existed before web apps gained steam, or
a
On Mon, Jul 22, 2013 at 11:55 PM, Charles McCathie Nevile
cha...@yandex-team.ru wrote:
On Mon, 22 Jul 2013 09:59:33 -0700, Daniel Buchner dan...@mozilla.com
wrote:
In my opinion, the current spec's complexity in relation to its feature
goal, is high.
I think it is pretty important
On Tue, Jul 23, 2013 at 4:44 AM, Marcos Caceres w...@marcosc.com wrote:
On Monday, July 22, 2013 at 11:54 PM, Daniel Buchner wrote:
To clarify, I am proposing that we make a simple app manifest entry the
only requirement for widget declaration: widget: { launch_path: ... }. The
issue
understanding why this proposal is facing such stop energy.
On Tue, Jul 23, 2013 at 8:12 AM, Marcos Caceres w...@marcosc.com wrote:
On Tuesday, July 23, 2013 at 3:06 PM, Daniel Buchner wrote:
On Tue, Jul 23, 2013 at 4:44 AM, Marcos Caceres w...@marcosc.com(mailto:
w...@marcosc.com) wrote
I concur. On hold doesn't mean forever, and the imperative API affords us
nearly identical feature capability. Nailing the imperative and getting the
APIs to market is far more important to developers at this point.
On Aug 12, 2013 4:46 PM, Alex Russell slightly...@google.com wrote:
As discussed
document - let's not throw the baby out with the bath water (maybe
this is already the thinking?)
- Daniel
On Tue, Aug 13, 2013 at 8:06 AM, Brian Kardell bkard...@gmail.com wrote:
On Tue, Aug 13, 2013 at 9:15 AM, Daniel Buchner dan...@mozilla.comwrote:
I concur. On hold doesn't mean forever
Yep. HTML Imports are standing on their own.
Dimitri, did I ever tell you you're my hero? (#ProTip: to get the full
effect, sing it with that Bette Midler tone)
On Tue, Aug 13, 2013 at 10:02 AM, Dimitri Glazkov dglaz...@google.comwrote:
On Tue, Aug 13, 2013 at 9:59 AM, Daniel Buchner dan
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
DOMComponentsLoaded/WebComponentsReady event has already fired, leaving
them with
after the promise has been fulfilled and then still get called back. That
sounds like it would be helpful for those users.
I believe the new font load events spec is making good use of them for
exactly this purpose.
On 27 Sep 2013, at 01:29, Daniel Buchner dan...@mozilla.com wrote
I don't see any compelling reason not to provide both. Let's not mistake an
appeal for a simple, backwards-compatible allowance, as a slight to
Promises ;)
On Fri, Sep 27, 2013 at 7:38 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Sep 27, 2013 at 1:52 AM, Daniel Buchner dan
,
are not altogether convincing points (which is of course my opinion, I
welcome yours).
On Fri, Sep 27, 2013 at 8:02 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Sep 27, 2013 at 10:56 AM, Daniel Buchner dan...@mozilla.com
wrote:
I don't see any compelling reason not to provide both.
Twice
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 notified that all elements in source are ready
for interaction is
Dimitri: right on.
The use of script-after-import is the forcing function in the blocking
scenario, not imports. Let's not complicate the new APIs and burden the
overwhelming use-case to service folks who intend to use the technology in
alternate ways.
For my bit, as long as the size of the
On Nov 20, 2013 11:07 AM, John J Barton johnjbar...@johnjbarton.com
wrote:
On Wed, Nov 20, 2013 at 10:41 AM, Daniel Buchner dan...@mozilla.com
wrote:
Dimitri: right on.
The use of script-after-import is the forcing function in the blocking
scenario, not imports.
Yes.
Let's
in the face
of significant network delay. As I said earlier, most apps will turn this
problem over to the design team rather than cause users to leave while the
browser spins waiting for the page to render.
On Thu, Nov 21, 2013 at 3:01 PM, Daniel Buchner dan...@mozilla.comwrote:
Yes, that's
at 3:01 PM, Daniel Buchner dan...@mozilla.comwrote:
Yes, that's the primary motivation. Getting FUC'd is going to be a
non-starter for serious app developers. We were just thinking of ways to
satisfy the use-case without undue burden.
, Nov 22, 2013 at 9:05 AM, Jonas Sicking jo...@sicking.cc wrote:
On Nov 22, 2013 8:24 AM, Daniel Buchner dan...@mozilla.com wrote:
Personally I don't have any issues with this solution, it provides for
the use-cases we face. Also, it isn't without precedent - you can opt for a
sync
. If the parser
finds custom elements in the page that match user-defined elements tag
names, it would block rendering until the associated link import has
finished loading and registering the containing custom elements.
Thoughts?
- Daniel
On Wed, Nov 20, 2013 at 11:19 AM, Daniel Buchner dan
Yes, that's the primary motivation. Getting FUC'd is going to be a
non-starter for serious app developers. We were just thinking of ways to
satisfy the use-case without undue burden.
I don't see this solution scaling at all.
Imports are a tree. If you have any import that includes any other import,
now the information about what tags to wait for has to be duplicated
along every node in that tree.
If a library author chooses to make any sort of all-in-one import to
Right on Dimitri, I couldn't agree more. It seems like an involved (but
highly beneficial) pursuit - but heck, maybe we'll find an answer quickly,
let's give it a shot!
Alex, I completely agree that declarative features should play a huge role
in the solution, and I love the power/granularity
for the rest. A complex declarative solution seems like the worst of both.
HTH,
jjb
On Wed, Nov 27, 2013 at 11:50 AM, Daniel Buchner dan...@mozilla.comwrote:
Right on Dimitri, I couldn't agree more. It seems like an involved (but
highly beneficial) pursuit - but heck, maybe we'll find an answer quickly
ction and cursor which
protocol handlers do not seem to be ready to perform.
However, I believe that copy-and-paste (and drag-and-drop) is part of an
app-to-app interaction APIs.
Paul
Daniel Buchner<mailto:dabuc...@microsoft.com>
20 octobre 2015 18:36
I’m trying to understand exac
<art.bars...@gmail.com>
Cc: Daniel Buchner <dabuc...@microsoft.com>; public-webapps@w3.org
Subject: Re: App-to-App interaction APIs - one more time, with feeling
2015/10/15 下午11:58於 "Arthur Barstow"
<art.bars...@gmail.com<mailto:art.bars...@gmail.com>>寫道：
>
&
l
From: Paul Libbrecht [mailto:p...@hoplahup.net]
Sent: Sunday, October 18, 2015 9:38 AM
To: Daniel Buchner <dabuc...@microsoft.com>
Cc: public-webapps@w3.org
Subject: Re: App-to-App interaction APIs - one more time, with feeling
Daniel,
as far as I can read the post, copy-and-paste-interoperabili
74 matches
Mail list logo
