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
, 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
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
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/
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
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
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
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
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
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
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
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
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
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
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*
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
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
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
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].
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
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
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
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
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
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
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
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
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?
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
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
(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
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
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.
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
65 matches
Mail list logo
