On Fri, Dec 7, 2012 at 1:36 PM, Maciej Stachowiak m...@apple.com wrote:
Would this involve creating a bindingsFoo() for every method foo() that is
exposed to bindings? For example, would we have to add
XMLHttpRequest::bindingsSend(), even though there's no real need for a
special internal
(sending from correct address)
Come late here. I basically support Darin's point.
Here is some addition:
As Maciej said, we don't need to do this for all API. We can do this by
opt-in basis, as an optimization.
Since we have [implementedAs] IDL attribute already, we can even start this
today
On Dec 7, 2012, at 12:28 PM, Elliott Sprehn espr...@chromium.org wrote:
This seems like it would introduce bugs and make maintaining the DOM harder
since we'd need to duplicate logic.
We should not needlessly duplicate logic. If the change causes us to copy and
paste code, we’re doing it
Hi folks.
Many of the APIs designed for use in the DOM are not efficient for use inside
WebKit, or have designs that are better for JavaScript than for C++. Antti
Koivisto and I have been discussing how to best communicate this to WebKit
contributors so they don’t end up using inefficient
Sounds like a good idea in general.
On Fri, Dec 7, 2012 at 9:27 AM, Darin Adler da...@apple.com wrote:
Many of the APIs designed for use in the DOM are not efficient for use
inside WebKit, or have designs that are better for JavaScript than for C++.
Antti Koivisto and I have been discussing
This seems like it would introduce bugs and make maintaining the DOM harder
since we'd need to duplicate logic. Right now we have appendChild() and
parserAppendChild(), and using parserAppendChild() for anything not in the
parser introduces web observable bugs and changes in behavior. We also only
Would this involve creating a bindingsFoo() for every method foo() that is
exposed to bindings? For example, would we have to add
XMLHttpRequest::bindingsSend(), even though there's no real need for a special
internal XMLHttpRequest::send()? Would getters and setters that map to
JavaScript
7 matches
Mail list logo