Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-24 Thread Brendan Eich
On Sep 24, 2009, at 7:55 AM, Maciej Stachowiak wrote: It seems like this is a Web IDL issue. I don't see any reason for Web IDL to move to ECMA. It is a nominally language-independent formalism that's being picked up by many W3C specs, and which happens to have ECMAScript as one of the

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-24 Thread Brendan Eich
On Sep 24, 2009, at 11:53 AM, Maciej Stachowiak wrote: This may be difficult for many reasons, but where the spec ends up is less important to me (and if you make me choose either-or, I prefer w3's RF to Ecma's RAND on first principles) than that we have good collaboration without

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Brendan Eich
Three distinct topics are being mixed up here: 1. Whether to use WebIDL or some unproposed alternative. 2. Whether to use catchall patterns in new WebIDL-defined interfaces. 3. Whether the JS WebIDL bindings should be standardized by Ecma or W3C. The straw man (0. Whether to remove catchall

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Brendan Eich
On Sep 25, 2009, at 12:08 PM, Jonas Sicking wrote: On Fri, Sep 25, 2009 at 9:56 AM, Brendan Eich bren...@mozilla.com wrote: My positions are: 1. WebIDL, the bird in the hand (I agree with Sam: go invent something better, come back when you're done). 2. Don't keep perpetuating catchall

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Brendan Eich
I will stop the over-citing madness here and now :-P. The struggle to formalize ArrayLike, which seems like a common goal for ES the core language and for WebIDL's ES bindings, makes me want to give an exception to the catchalls considered harmful for new interfaces injunction. I agree

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Brendan Eich
On Sep 25, 2009, at 4:57 PM, Maciej Stachowiak wrote: On Sep 25, 2009, at 1:18 PM, Brendan Eich wrote: So if you are doing more ArrayLike interfaces, let's keep talking. Don't let at least my catchalls-considered-harmful statements stop progress on ArrayLikes. Perhaps when catchalls

Re: WebIDL

2009-09-26 Thread Brendan Eich
On Sep 25, 2009, at 11:43 PM, Yehuda Katz wrote: Do we disagree that it is a worthy goal to have a specification that can be understood without having to take a while? I certainly understand the utility in using something with precedent like IDL (for implementors). Perhaps the IDL version could

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

2009-09-27 Thread Brendan Eich
On Sep 26, 2009, at 11:16 PM, Cameron McCormack wrote: OK, that is indeed what I’m hearing from you guys. “Host objects may implement these [internal] methods in any manner unless specified otherwise” in ES3 doesn’t sound like it’s particularly discouraging of the different behaviour that Web

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

2009-09-27 Thread Brendan Eich
On Sep 26, 2009, at 11:28 PM, Maciej Stachowiak wrote: There are methods, but I'm not optimistic that they will cause property reflection to wither. getItem/setItem/removeItem/key/clear methods, plus .length -- not a balanced name-set stylistically, but usable to avoid collisions (my key

Re: Web IDL Garden Hose

2009-09-27 Thread Brendan Eich
On Sep 27, 2009, at 10:41 AM, David-Sarah Hopwood wrote: Brendan Eich wrote: On Sep 26, 2009, at 6:08 PM, Maciej Stachowiak wrote: This may provide a way to implement some of these behaviors in pure ECMAScript. The current proposal does allow [[Construct]] without [[Call]], but not [[Call

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

2009-09-27 Thread Brendan Eich
On Sep 27, 2009, at 4:15 PM, Maciej Stachowiak wrote: On Sep 27, 2009, at 11:28 AM, Brendan Eich wrote: But there's no point pretending the Web (ES, DOM, etc.) is an example of a well-designed toolkit for building user-facing distributed apps! But we're not really free to discard

Re: [DOMCore] fire and dispatch

2011-03-05 Thread Brendan Eich
2. Run getters and define in which order they are retrieved This can get pretty hard to specify (esp. because it involves describing what happens if those getters reenter the API you're defining). Why is that particularly hard? Calling fireEvent (or whatever it will be called) twice on a

Re: [FileAPI] File.slice spec bug

2011-04-12 Thread Brendan Eich
Darin's position is leaning toward not breaking compatibility with what Chrome has shipped for a while. That's one consideration. It can't be the only consideration, or there's no point having a discussion and whatever Chrome ships first is an instant standard. When we talked to Kenneth Arnold

Re: [FileAPI] File.slice spec bug

2011-04-12 Thread Brendan Eich
Dmitry Titov dim...@chromium.org wrote: It can be more then it looks though - if site detects File.slice and then uses it, it will automatically pick up FF and Opera now because the method now is defined. FF and Opera just added File slice support, IIUC. For Firefox at least we are willing to

Re: [FileAPI] File.slice spec bug

2011-04-13 Thread Brendan Eich
On Apr 13, 2011, at 7:01 AM, Darin Fisher wrote: Agreed. I certainly don't assert that whatever Chrome ships first should be regarded as standard. Our rapid release schedule depends on platform features beginning life with a vendor prefix. I believe that we goofed in this case by not

Re: [WebIDL] Exceptions

2011-07-06 Thread Brendan Eich
On Jul 6, 2011, at 5:05 PM, Jonas Sicking wrote: On Wed, Jul 6, 2011 at 2:23 PM, Aryeh Gregor simetrical+...@gmail.com wrote: On Wed, Jul 6, 2011 at 7:06 AM, Anne van Kesteren ann...@opera.com wrote: So with Web IDL going to Last Call does this mean that the exception model outlined in

Re: [WebIDL] Exceptions

2011-07-07 Thread Brendan Eich
On Jul 7, 2011, at 10:09 AM, Aryeh Gregor wrote: On Wed, Jul 6, 2011 at 9:46 PM, Brendan Eich bren...@mozilla.org wrote: Gecko is buggy if it is using the dynamic scope. Please file that bug and cc: me. Gecko says the exception is an instanceof the DOMException object that corresponds

Re: What type should .findAll return

2011-11-11 Thread Brendan Eich
On Nov 11, 2011, at 1:05 AM, Jonas Sicking wrote: Hi All, So, we've debated a lot the exact syntax for .find/.findAll. However I intentionally requested that we split out the discussions about return type for .findAll to a separate thread. So I'm starting that thread here. There are a

Re: What type should .findAll return

2011-11-11 Thread Brendan Eich
On Nov 11, 2011, at 10:44 AM, Jonas Sicking wrote: On Fri, Nov 11, 2011 at 10:06 AM, Brendan Eich bren...@mozilla.org wrote: On Nov 11, 2011, at 1:05 AM, Jonas Sicking wrote: And to ensure that the object acts as much as possible as an array it should also have it's [[Class]] set

Re: What type should .findAll return

2011-11-11 Thread Brendan Eich
On Nov 11, 2011, at 3:07 PM, Allen Wirfs-Brock wrote: I'm happy to start a separate thread on es-discuss about this, but I'm worried that it'll fragment the current thread. In theory, public-script-coord exists for exactly this sort of discussion and the ESdiscuss people who care should be

Re: What type should .findAll return

2011-11-14 Thread Brendan Eich
On Nov 14, 2011, at 3:13 PM, Yehuda Katz wrote: It seems as though the spec intends to disallow host objects (i.e. DOM) from fully acting like an Array, which is clearly the intent here. Perhaps this is a time for willful disobedience and a correction in ES6? Calm down -- this

Re: What type should .findAll return

2011-11-14 Thread Brendan Eich
again for my in-jest comment. Yehuda Katz (ph) 718.877.1325 On Mon, Nov 14, 2011 at 3:23 PM, Brendan Eich bren...@mozilla.org wrote: On Nov 14, 2011, at 3:13 PM, Yehuda Katz wrote: It seems as though the spec intends to disallow host objects (i.e. DOM) from fully acting like an Array

Re: [XHR] Constructor behavior seems to be underdefined

2012-03-30 Thread Brendan Eich
See the [[Scope]] internal property of function objects from ECMA-262 13.2, 10.4.3, etc. /be Boris Zbarsky wrote: As far as I can tell, the WebIDL specification doesn't define anything about what really happens when a constructor is invoked, once the arguments have been converted to the IDL

Re: [IndexedDB] Problems unprefixing IndexedDB

2012-08-10 Thread Brendan Eich
From: Kyle Huey m...@kylehuey.com Jonas mentioned earlier on this list that we unprefixed IndexedDB in Firefox nightlies some time ago. We ran into a bit of a problem.[0] Most of the IndexedDB tutorials (including ours and HTML5 Rocks[1] :-/) tell authors to deal with prefixing with:

Re: Sync API for workers

2012-09-04 Thread Brendan Eich
David Bruant wrote: I can imagine, it sounds hard indeed. Do you have numbers on how it affects performance? Or an intuition on these numbers? I don't need to be convinced that it affects performance significantly, but just to get an idea. This is not going to be easy to estimate, but you

Re: Moving File API: Directories and System API to Note track?

2012-09-22 Thread Brendan Eich
Maciej Stachowiak wrote: On Sep 21, 2012, at 10:10 PM, Jonas Sickingjo...@sicking.cc wrote: For what it's worth, I put together a draft for what an API would look like that has basically the same feature set as the current FileSystem API, but based on DeviceStorage. It's a much smaller API

Re: Moving File API: Directories and System API to Note track?

2012-09-25 Thread Brendan Eich
Maciej Stachowiak wrote: On Sep 22, 2012, at 9:35 PM, Maciej Stachowiakm...@apple.com wrote: On Sep 22, 2012, at 8:18 PM, Brendan Eichbren...@mozilla.com wrote: And two of the interfaces are generic and reusable in other contexts. Nice, and DOMRequest predates yours -- should it be done

Re: IndexedDB: undefined parameters

2012-10-10 Thread Brendan Eich
Boris Zbarsky wrote: In fact, WebIDL doesn't even do what you want here with [TreatUndefinedAs=Missing]. All that does is that if it's present on an argument and all arguments after it, and if all the values passed for all those arguments are undefined, then the effective overload used is

Re: Moving File API: Directories and System API to Note track?

2012-10-11 Thread Brendan Eich
Glenn Maynard wrote: I'm interested in the same from Mozilla side: what are the real issues that you think are unsolvable, or do you just think the underlying use cases aren't compelling enough for the work required? Speaking for myself, not for all Mozillans here, I find the use-cases Eric

Re: CSP 1.1 DOM design

2012-11-05 Thread Brendan Eich
David Bruant wrote: This M.O. is exacerbated by the reality that most of the folks writing these specs are C++ hackers, not JS developers. For many, WebIDL becomes a safety blanket that keeps them from having to ever think about the operational JS semantics or be confronted with the

Re: [DOM4] Short and Efficent DOM Traversal

2013-07-28 Thread Brendan Eich
Domenic Denicola wrote: `.iterator()` is a nonstandard Mozilla-ism; Rather, a temporary state while we were arguing about ES6 and waiting for symbols to be specified (still waiting). It's not a permanent addition. /be

Re: Allow javascript: URIs for registerProtocolHandler

2013-09-17 Thread Brendan Eich
Anne van Kesteren mailto:ann...@annevk.nl September 17, 2013 12:25 PM Really? I thought registerProtocolHandler() was only a hook for navigation. As an aside, the plan of record is to limit javascript URLs to navigation. Unless they result in undefined, in which case they evaluate against the

Re: Polished FileSystem API proposal

2013-10-29 Thread Brendan Eich
Hard links are peculiar to Unix filesystems. Not interoperable across all OSes. Symbolic links, OTOH... /be Brian Stell mailto:bst...@google.com October 29, 2013 4:53 PM I meant eg, V1/dir1/file1, V2/dir1/file1.

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

2013-12-07 Thread Brendan Eich
(I'm an extensiblewebmanifesto.org signer.) Separate specs that compose well are great, and all. Requiring this kind of boilerplate out of the gave is not: this.createShadowRoot().appendChild(document.importNode(template.contents)); Wanting to avoid this kind of boilerplate is not a stab in

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

2013-12-07 Thread Brendan Eich
What does polymer do? Cows are already treading paths. I still smell a chance to do better out of the gate (gave, thanks autospellcheck! lol). Call me picky. Knee-jerking about scenario solving (I think I taught Yehuda that one) doesn't help. Particular response, please. /be

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

2013-12-09 Thread Brendan Eich
Ryosuke Niwa wrote: As for the social endorse button, I've never seen a popular SNS share buttons implemented using HTML button elements; most of them add their own DOM to add icons, etc... Right you are. And there's a deeper reason why like (endorse, LOL) buttons use iframes: the ability to

Re: [fullscreen] Problems with mouse-edge scrolling and games

2014-02-24 Thread Brendan Eich
Glenn Maynard wrote: It's not the application's job to keep the mouse cursor responsive, it's the system's. Hiding the system mouse cursor and drawing one manually is always a bad idea. Agreed! In the same vein, programmers cannot avoid GC pauses without relying on pause-free or at least

Re: [Gamepad] Liveness of Gamepad objects

2014-04-29 Thread Brendan Eich
Boris Zbarsky wrote: For what it's worth, the way Gecko implements this is by setting up that lifetime guarantee only when an expando is added to the object (or some other things, like use as a WeakMap key, happen). Until then we allow it to be GCed. What do other engines do in general?

Re: WebApp installation via the browser

2014-05-30 Thread Brendan Eich
Jeffrey Walton wrote: Are there any platforms providing the feature? Has the feature gained any traction among the platform vendors? Firefox OS wants this. /be

Re: WebApp installation via the browser

2014-05-30 Thread Brendan Eich
Jeffrey Walton wrote: On Fri, May 30, 2014 at 9:04 PM, Brendan Eichbren...@mozilla.org wrote: Jeffrey Walton wrote: Are there any platforms providing the feature? Has the feature gained any traction among the platform vendors? Firefox OS wants this. Thanks Brendan. As a second related

Re: Fallout of non-encapsulated shadow trees

2014-07-01 Thread Brendan Eich
Domenic Denicola wrote: True encapsulation, wherein each element gets some kind of isolated world in which to implement itself, is much harder. Blink-in-JS [1] accomplishes something along these lines, but does not leverage custom elements, shadow DOM, or the like, and essentially works by

Re: Fallout of non-encapsulated shadow trees

2014-07-01 Thread Brendan Eich
I meant Shadow DOM below, where I wrote Web Components. IIRC Mozilla second, Google first, are implementing. Anyone else? /be Brendan Eich wrote: I'm not saying WebComponents aren't good enough, note well. Sounds like they're pretty good and can be evolved and built upon to be even better

Re: Fallout of non-encapsulated shadow trees

2014-07-01 Thread Brendan Eich
Domenic Denicola wrote: Well, but*for explaining the platform* it is just as useless. That is a false idol if it means no intermediate steps that explain some but not all of the platform. It may be useful independently for authors who wish to protect against interference by people who

Re: Fallout of non-encapsulated shadow trees

2014-07-01 Thread Brendan Eich
Domenic Denicola wrote: From: Brendan Eich [mailto:bren...@secure.meer.net] That is a false idol if it means no intermediate steps that explain some but not all of the platform. Sure. But I don't think the proposed type 2 encapsulation explains any of the platform at all. Are you sure

Re: Fallout of non-encapsulated shadow trees

2014-07-01 Thread Brendan Eich
Domenic Denicola wrote: From: Brendan Eich [mailto:bren...@secure.meer.net] I don't even know what 3 means. Is it well defined, or just some utopia? I think it is as well defined as 2 is. Both are really in terms of vague requirements: 2. Widget libraries should be implementable without

Re: Fallout of non-encapsulated shadow trees

2014-07-01 Thread Brendan Eich
Boris Zbarsky wrote: On 7/1/14, 9:13 PM, Brendan Eich wrote: Are you sure? Because Gecko has used XBL (1) to implement, e.g., input type=file, or so my aging memory says. We use XBL to implement marquee. Also video playback controls, per your next message. We do not use XBL to implement

Re: Blocking message passing for Workers

2014-08-11 Thread Brendan Eich
David Bruant wrote: Le 09/08/2014 16:22, Brian Kardell a écrit : On Aug 9, 2014 10:16 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: There is still a case for blocking primitives for projects that compile from other languages (C, C++, Python, Java, C#, etc.) to JS [3].

Re: Blocking message passing for Workers

2014-08-12 Thread Brendan Eich
David Bruant wrote: Le 12/08/2014 02:11, Brendan Eich a écrit : David Bruant wrote: Le 09/08/2014 16:22, Brian Kardell a écrit : On Aug 9, 2014 10:16 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: There is still a case for blocking primitives for projects

Re: Blocking message passing for Workers

2014-08-12 Thread Brendan Eich
David Bruant wrote: That's not what I had understood. So both types of APIs (sync and async) will be available to workers for say, IndexedDB? If that's the case, I have no problem with it and we can stop the discussion. What I remembered of the state of the consensus was that given sync APIs

Re: Blocking message passing for Workers

2014-08-12 Thread Brendan Eich
David Bruant wrote: I proposed exposing both here http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0164.html Jonas Sicking wasn't sold http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0165.html You didn't reply, but we now have a good argument thanks to your point

Re: {Spam?} Re: [xhr]

2014-09-02 Thread Brendan Eich
cha...@yandex-team.ru wrote: Sorry. As with showModalDialog() we would really like to make this feature disappear. I realize this makes some forms of code generation harder, but hopefully you can find a way around that in time. Perhaps we should set some sense of expectation about*when*

Re: =[xhr]

2014-09-03 Thread Brendan Eich
David Rajchenbach-Teller wrote: it would require changes to Java2Script. Big changes -- CPS conversion, compiling with continuations. This would require identifying all the potential blocking points. It's not clear anyone will do it, even if it is feasible (thanks to Java's static types and

Re: =[xhr]

2014-09-03 Thread Brendan Eich
David Rajchenbach-Teller wrote: Clearly, it would require big changes, although compiling to return Promise and using Task.js + yield at call sites would probably be much simpler than CPS conversion. All call sites, every last Java method = JS function call? That means every single function

Re: New approach to activities/intents

2014-11-10 Thread Brendan Eich
Dimitri Glazkov wrote: Domenic's question still needs addressing separately, but just a quick response here -- the API roc described there is different. Tubes are just like talking to a worker or any MessagePort. There is no extra API surface emerging from getContext-like function call. Any

Re: New approach to activities/intents

2014-11-11 Thread Brendan Eich
Dimitri Glazkov wrote: I thought about this a bit and realized that we first need to have a common criteria to evaluate whether we even need something like Tubes. That should be done before we get into mechanics of the solution. I apologize for jumping the gun. And I apologize even more to

Re: HTML imports in Firefox

2014-12-15 Thread Brendan Eich
Ashley Gullen wrote: On 15 December 2014 at 19:09, Boris Zbarsky bzbar...@mit.edu mailto:bzbar...@mit.edu wrote: But more to the point, we're not shipping imports because we've gotten feedback from a number of people that imports are not solving the problems they actually need

Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-11 Thread Brendan Eich
Marc Fawzi wrote: even if the DOM must remain a single-threaded and truly lock/barrier/fence-free data structure, what you are reaching for is doable now, with some help from standards bodies. ***But not by vague blather*** Sorry, I was too grumpy -- my apologies. I don't see much

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Brendan Eich
with a condescending response, as if ... What the hey! Mr. Eich! I guess this explains the origin of JS: a knee jerk reaction to then-trendy ideas... That's not the way to go about all inclusive debate. Thank you. Sent from my iPhone Brendan Eich mailto:bren...@secure.meer.net February 10, 2015 at 5

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Brendan Eich
Please stop overloading public-webapps with idle chatter. React and things like it or based on it are going strong. Work there, above the standards. De-jure standardization will follow, and we'll all be better off for that order of work. /be Marc Fawzi wrote: How about a thread-safe but

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Brendan Eich
Marc Fawzi wrote: I've recently started using something called an atom in ClojureScript and it is described as a mutable reference to an immutable value. It holds the state for the app and can be safely mutated by multiple components, and has an interesting thing called a cursor. It is lock

Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-12 Thread Brendan Eich
Marc Fawzi wrote: This guy here is bypassing the DOM and using WebGL for user interfaces https://github.com/onejs/onejs He even has a demo, with no event handling other than arrow keys at this point, and as the author admits ugly graphics, but with projects like React-Canvas (forget the

Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-12 Thread Brendan Eich
Aryeh Gregor wrote: This is all horrible, but that's life. Indeed, nature is nasty. Search for sacculina carcini life cycle for but one example. The Web and the Internet are evolving systems with some parallels and analogies to biological evolution. See http://www.cc.gatech.edu/~dovrolis/

Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-12 Thread Brendan Eich
Brendan Eich wrote: over-the-top work Apologies if this overloaded trope is confusing without more context -- it could mean wildly excessive, or doing what soldiers in trenches did in WWI when the whistle blew (see https://www.youtube.com/watch?v=fssPqRWx9U0 :-/), but I meant build on top

Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-14 Thread Brendan Eich
, 2015 at 12:33 PM On 2/11/15 3:04 PM, Brendan Eich wrote: If you want multi-threaded DOM access, then again based on all that I know about the three open source browser engines in the field, I do not see any implementor taking the huge bug-risk and opportunity-cost and (mainly) performance

Re: Exposing structured clone as an API?

2015-04-24 Thread Brendan Eich
Step where you need to, to avoid falling over :-P. The problems with generalized/extensible clone are clear but we have structured clone already. It is based on a hardcoded type-case statement. It could be improved a bit without trying to solve all possible problems, IMHO. /be Anne van