<div dir="ltr">On Fri, Jun 13, 2014 at 1:16 AM, Anne van Kesteren <span dir="ltr"><<a href="mailto:annevk@annevk.nl" target="_blank">annevk@annevk.nl</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Fri, Jun 13, 2014 at 10:12 AM, Ryosuke Niwa <<a href="mailto:rniwa@webkit.org">rniwa@webkit.org</a>> wrote:<br>
> What I'm saying is that we can implement it in JavaScriptCore for<br>
> performance and we still make it look like a regular DOM object with<br>
> wrappers to preserve the semantics.<br>
<br>
</div>I understand that, but given that it is in the JavaScript engine at<br>
that point, they cannot realistically standardize on a different<br>
abstraction later on.</blockquote><div><br></div><div>What kind of abstraction layer are you thinking of? As far as I looked at the working draft, DOMPoint, etc... are regular DOM objects specifically created for DOM APIs. I can't think of use cases for these kinds of objects without DOM.</div>
<div><br></div><div>I feel like we're talking past each other so let me rephrase it again. All I'm saying is that whether something is implemented in JSC or WebCore is a pure implementation detail. We should be able to do whatever the heck we please to do as long as our implementations adhere to respect specifications. Heck, JSC and WebCore could be a single project called WebKit that can't be separately built.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">And I got the impression typed arrays caught them off guard, so giving them a heads up this time around might be good.</blockquote>
<div><br></div><div>I understand your concern and sentiment but I'm having a hard time imagining what kind of problems/concerns would TC39 have with these interfaces that are clearly prefixed with DOM.</div><div><br>
</div>
<div>- R. Niwa</div><div><br></div></div></div></div>