Thread necromancy! To summarize the original post: Currently WebKit’s JS
binding implements EventTarget as a mixin—all event targets have
addEventListener, removeEventListener and dispatchEvent methods. I propose
WebKit put EventTarget on the prototype chain.
There were two basic questions in resp
To clarify:
This message isn't meant to say "if you don't like any of these, speak
up" (although you should feel free to speak up, as always). It's
meant to encourage folks to review the forthcomming patches with the
following standard for the underlying behavior change (i.e., not
"just" as patch
Maciej and I discussed this in IRC. We agree that it's important to
discuss the changes more broadly within the project, but we disagree
about the best format for that discussion.
If you're interested in these sorts of changes, please feel free to
add yourself to the CC list of this bug. Mark an
On Fri, Aug 5, 2011 at 5:16 PM, Maciej Stachowiak wrote:
> For example, Mark said that the following patch changes
> HTMLAnchorElement.getParameter:
>
> https://bugs.webkit.org/attachment.cgi?id=102840&action=review
>
> [...] I don't see any mention of the functions that changed behavior in the
On Aug 5, 2011, at 1:39 PM, Adam Barth wrote:
>
>> My proposal is to revert all the patches that changed behavior without
>> incorporating tests, and we can decide how to proceed from there. If it's
>> hard to even tell which those are, then we should just revert the whole
>> patch set. Then
I don't fully understand what's going on with those APIs. My understanding
prior to this morning is that they were special cased by the code
generator. It's on my list of things to investigate today.
Adam
On Aug 5, 2011 1:48 PM, "Sam Weinig" wrote:
> This list doesn't seem to include the chang
This list doesn't seem to include the changes in behavior to addEventListener
and removeEventListerner (from patches like
http://trac.webkit.org/changeset/92469 http://trac.webkit.org/changeset/92433).
Are those intentionally left out?
-Sam
On Aug 5, 2011, at 12:44 PM, Mark Pilgrim wrote:
>
Hi Maciej,
On Fri, Aug 5, 2011 at 1:16 PM, Maciej Stachowiak wrote:
> I have a hard time reading this wall of text, but it seems to me there were
> at least three things wrong with what happened:
I didn't mean to write a wall of test. I wanted to give Darin
complete answers to his questions be
On Fri, Aug 5, 2011 at 1:06 PM, Darin Adler wrote:
> Mark, Adam, thanks for your replies.
>
> It seems obviously OK to do this for new APIs that have not been around long,
> especially ones that never shipped in a production browser, for the same
> reason that we decided to do this for new funct
Hi Adam,
I have a hard time reading this wall of text, but it seems to me there were at
least three things wrong with what happened:
1) Patches mixing refactoring and behavior changes. This is bad. We should aim
whenever possible to separate behavior changes from refactoring. Reviewers
should
Mark, Adam, thanks for your replies.
It seems obviously OK to do this for new APIs that have not been around long,
especially ones that never shipped in a production browser, for the same reason
that we decided to do this for new functions from this point forward. I have no
quibble with that.
I think bytes and blobs would be sufficient.
+f...@google.com
On Fri, Aug 5, 2011 at 12:58 PM, Adam Barth wrote:
> Bytes and (likely) blobs are types we're planning to do in DOMCrypt.
> Hashing strings is slightly more delicate because you need to pick an
> encoding. Do you have a sense, if we
Bytes and (likely) blobs are types we're planning to do in DOMCrypt.
Hashing strings is slightly more delicate because you need to pick an
encoding. Do you have a sense, if we did bytes and blobs, would that
be enough, or are strings really important also?
Thanks,
Adam
On Fri, Aug 5, 2011 at 12
Here is the complete list of intentional behavior changes in patches
I've submitted in the past few months, along with bug URLs to show the
discussion / rationale behind each change:
https://bugs.webkit.org/show_bug.cgi?id=63065
IDBFactory.open()
https://bugs.webkit.org/show_bug.cgi?id=63079
I
Yes, hashing blobs. Here's the last line of the relevant meeting notes...
"In the end, we all agreed that the main thing with the highest utility
would be a native hashing implementation that could accept strings, bytes,
or BLOBs."
On Fri, Aug 5, 2011 at 12:32 PM, Adam Barth wrote:
> On Fri, Au
On Fri, Aug 5, 2011 at 12:09 PM, Michael Nordman wrote:
>> For example, the CryptoHash
>> interface can be implemented independently of the rest of the API and
>> provides value by itself.
>
> Moving forward on that part first sounds reasonable. I've been asked about
> that specifically by some ap
> For example, the CryptoHash
> interface can be implemented independently of the rest of the API and
> provides value by itself.
Moving forward on that part first sounds reasonable. I've been asked about
that specifically by some app developers that really aren't interested in
the other parts of
On Fri, Aug 5, 2011 at 11:12 AM, Darin Adler wrote:
> I assume that the legacy argument refactoring you are doing right now has a
> goal of no behavior changes. But I’ve noticed some cases where arguments are
> not marked optional in a few of the patches. Possibly I misunderstood the
> patch.
Hi Mark.
I assume that the legacy argument refactoring you are doing right now has a
goal of no behavior changes. But I’ve noticed some cases where arguments are
not marked optional in a few of the patches. Possibly I misunderstood the
patch. One example was arguments in canvas rendering contex
On Aug 4, 2011, at 6:40 PM, TAMURA, Kent wrote:
> Like INPUT_COLOR, I'd like to introduce feature flags for date, datetime,
> datetime-local, month, time, and week types.
> * We're going to implement dedicated UIs for them, and will want to disable
> it temporarily.
> * Their current implementat
20 matches
Mail list logo
