| 05:45 | <Hixie> | back, fwiw |
| 05:45 | <Hixie> | abarth: why so? |
| 05:59 | <abarth> | Hixie: we're just reading about seamless and srcdoc |
| 05:59 | <abarth> | Hixie: reading how the two interact |
| 10:31 | <annevk> | https://dvcs.w3.org/hg/domcrypt/shortlog is somewhat confusing |
| 10:49 | <AryehGregor> | So, exciting tip: if you're taking your computer from America, and it has a power supply that supports both 110V and 220V, make sure that before you hook it up to 220V, you check that you don't have to flip a switch or anything. |
| 10:50 | <AryehGregor> | Otherwise you might need to make an unexpected trip to the computer store. |
| 10:50 | <AryehGregor> | (Apparently, the Hebrew term for a power supply is ספק כח.) |
| 10:50 | <j_wright> | thanks edison |
| 12:43 | <annevk> | https://bugzilla.mozilla.org/show_bug.cgi?id=641821#c59 |
| 12:44 | <annevk> | didn't Gecko argue against that initially? |
| 12:44 | <annevk> | oh well |
| 12:44 | <annevk> | good to see people read the spec carefully when implementing... |
| 12:45 | <Ms2ger> | Gecko is a rendering engine, it can't argue against anything :) |
| 12:50 | <annevk> | you know what I mean |
| 12:51 | <Ms2ger> | You know Mozillians' comments are almost always in a personal capacity :) |
| 12:52 | <annevk> | it was either sicking or smaug so it doesn't matter much in this case |
| 12:57 | <Ms2ger> | Speak of the devil |
| 12:58 | smaug____ | is not a devil, just a friendly dragon |
| 12:59 | <smaug____> | annevk: argue agains what? |
| 12:59 | <smaug____> | against |
| 13:00 | smaug____ | needs to still file bugs found in the spec during the week |
| 13:00 | <annevk> | having two records for a replace operation |
| 13:01 | <smaug____> | annevk: in some cases there sure are many records |
| 13:01 | <smaug____> | there is the record removing the new node from its old parent |
| 13:02 | <smaug____> | then record adding to the new parent |
| 13:02 | <smaug____> | the latter can be combined with removing the old node |
| 13:02 | <smaug____> | I need to still check what latest webkit does |
| 13:03 | smaug____ | doesn't know how to update chrome |
| 13:10 | <annevk> | I was referring to the comment in that bug... |
| 13:10 | <annevk> | it was not about adopting |
| 13:10 | <annevk> | you'll always need a separate record for that |
| 14:48 | <AryehGregor> | When is .isTrusted supposed to be true? |
| 14:49 | AryehGregor | wonders if input events from execCommand() should have it true or false |
| 14:49 | <annevk> | false |
| 14:49 | <AryehGregor> | Okay, why? |
| 14:50 | <AryehGregor> | Should it be true if the execCommand() is triggered by a user action (e.g., hitting a key triggers document.execCommand("insertText"))? |
| 14:52 | <annevk> | hmm, I guess input is some kind of corner case |
| 14:52 | <annevk> | isTrusted is true when the spec says to dispatch the event |
| 14:52 | <annevk> | e.g. readystatechange on XMLHttpRequest will have it set to true |
| 14:53 | <AryehGregor> | The spec for execCommand() says to dispatch the command. |
| 14:53 | <AryehGregor> | The author can invoke execCommand(), of course. |
| 14:53 | <zewt> | annevk: seems like it should be true in this case, if the event object is constructed by execCommand and can't be arbitrarily manipulated |
| 14:53 | <zewt> | that is, it's always seemed to me that !isTrusted means "this object was constructed by hand" |
| 14:54 | <zewt> | or something like that |
| 14:54 | <annevk> | yeah, something like that |
| 14:54 | <annevk> | :) |
| 14:54 | <annevk> | not sure it's actually needed |
| 14:55 | <zewt> | hmm |
| 14:55 | <zewt> | form.click() results in !isTrusted |
| 14:55 | <zewt> | (in FF) |
| 14:55 | <zewt> | which seems odd |
| 14:56 | <zewt> | at least to how i've intuitively viewed isTrusted |
| 14:56 | <zewt> | (personally I've never found isTrusted to be terribly useful, anyway...) |
| 14:57 | <annevk> | so in Gecko it might be user-initiated; something to do with their XBL impl |
| 14:57 | <zewt> | (when are you ever not required to trust other scripts on the page, anyway?) |
| 14:58 | <annevk> | XBL |
| 14:58 | <zewt> | xbl isn't relevant to web pages... |
| 14:58 | <annevk> | I'm not saying having isTrusted makes sense |
| 14:59 | <zewt> | weird, didn't know webkit (or at least chrome) doesn't have form.click (or maybe I did and I forgot, since I've been over this territory before) |
| 14:59 | <annevk> | maybe file a bug on DOM 3 Events? |
| 14:59 | <annevk> | I just specced isTrusted because it was there... |
| 14:59 | <zewt> | i'm sure it won't be removed so I won't waste my time |
| 14:59 | <annevk> | the new editor is far more reasonable |
| 14:59 | <zewt> | not important enough (to me) to spend time arguing for that anyway (if anyone else wants to, go for it) |
| 14:59 | <annevk> | and we could at least learn what it's for |
| 14:59 | <Ms2ger> | 3249 // Click() is never called from native code, but it may be |
| 14:59 | <Ms2ger> | 3250 // called from chrome JS. Mark this event trusted if Click() |
| 14:59 | <Ms2ger> | 3251 // is called from chrome code. |
| 14:59 | <annevk> | yeah I might |
| 15:01 | <zewt> | if it doesn't do anything meaningful, it could also just always be true, which would be less likely to break pages (still not guaranteed, though) and simplify things |
| 15:01 | <annevk> | hmm |
| 15:01 | <annevk> | is it even supported in every browser? |
| 15:02 | <zewt> | someone might still be using it for other unintended purposes, like "did I initiate the event or did the user" |
| 15:02 | <zewt> | (which you can always do by tacking a property on the event when you create it, of course) |
| 15:03 | <zewt> | seems to not be there in chrome |
| 15:04 | <zewt> | don't have ie9 handy |
| 15:06 | <Ms2ger> | If it's in D3E, IE probably has it |
| 17:20 | <Ms2ger> | TabAtkins, nicely done |
| 17:22 | <annevk> | that does look pretty |
| 17:29 | <kennyluck> | oh my goodness. |
| 17:59 | <gsnedders> | "Design" |
| 17:59 | <gsnedders> | "W3C" |
| 17:59 | <gsnedders> | I think my brain just imploded. |
| 17:59 | <gsnedders> | Just wow. It's really quite well done. |
| 23:13 | <heycam> | Hixie, on HTMLCanvasElement the "_callback" argument can now be named just "callback" (argument identifiers don't need to be escaped when they're any of the names at http://dev.w3.org/2006/webapi/WebIDL/#prod-ArgumentNameKeyword) |