| 13:48 | <asmodai> | holy leaking memory batman *eyes firefox curiously* |
| 17:18 | <Hixie> | why was 'mod' removed from calc()? |
| 21:19 | <rniwa> | AryehGregor: are you here? |
| 22:04 | <rniwa> | annevk: hi anne |
| 22:07 | <annevk> | hey rniwa |
| 22:07 | <rniwa> | annevk: how are you doing? |
| 22:08 | <annevk> | pretty good, bit sleepy :) |
| 22:08 | <rniwa> | annevk: I see. I'm a bit confused about the whole discussion on HTMLCollection |
| 22:08 | <annevk> | still trying to get used to the cold after my shortish break |
| 22:09 | <rniwa> | annevk: oh oops, that sucks. |
| 22:09 | <rniwa> | annevk: hopefully it gets better. |
| 22:09 | <annevk> | well I think sicking wants to add new members to e.g. NodeList at some point |
| 22:09 | <rniwa> | annevk: yeah, that makes sense. |
| 22:09 | <rniwa> | annevk: but do you think he's opposed to make getElement*by* return HTMLCollection? |
| 22:10 | <annevk> | HTMLCollection has a named getter which would make that difficult if e.g. someone used an ID anywhere on the web and that matches the new member name while also using HTMLCollection in some way |
| 22:10 | <rniwa> | annevk: as I noted on the thread, I filed a WebKit bug and was intending to work on it this weekend or so |
| 22:10 | <rniwa> | but it sounded as if jonas doesn't want that. |
| 22:11 | <annevk> | I think he was somewhat opposed to getElementsByClassName, not the others |
| 22:12 | <rniwa> | annevk: I see. |
| 22:12 | <rniwa> | annevk: FWIW, we're never got complaints about named getters so maybe we can disable that feature? |
| 22:12 | <rniwa> | we've* |
| 22:13 | <annevk> | I think even WebKit has a named getter for getElementsByTagName |
| 22:13 | <annevk> | bz pointed that out |
| 22:13 | <rniwa> | annevk: ah, you're right. |
| 22:13 | <rniwa> | annevk: we had that extension on NodeList :( |
| 22:13 | <annevk> | yeah so this change would mean you can try to clean that up |
| 22:14 | <annevk> | gonna go watch some parks and recreation |
| 22:14 | <rniwa> | annevk: I will definitely do that assuming there's no compat. issues |
| 22:15 | <rniwa> | annevk: alright. ttyl. |
| 22:16 | rniwa | is so confused by Objective-C syntax |
| 22:25 | <zewt> | hmm, would be nice to get HTML's use of "default action" updated to use DOM4 terms (canceled flag) ... low editorial priority, i assume |
| 22:26 | <zewt> | rniwa: objc is one of the few languages that simply doesn't make even the most basic intuitive sense to me |
| 22:26 | <zewt> | putting aside weirdo functional languages, I guess |
| 22:27 | <rniwa> | zewt: like prolog? |
| 22:28 | <rniwa> | zewt: I mean it's a declarative language. but I find declarative programming languages even less intuitive than functional programming languages. |
| 22:29 | <zewt> | annevk: is the preferred way to look at "canceled flag" after dispatch to refer to the flag directly, or to use the return value of the "dispatch" algo |
| 22:29 | <zewt> | the latter seems more natural to me (but then there'd be no reason to have the return value at all, I think) |
| 22:30 | <zewt> | er |
| 22:30 | <zewt> | the former looks more natural (using the flag directly) |
| 22:36 | <annevk> | zewt: you'd use fire so there's no return value I think |
| 22:38 | <annevk> | could maybe move the return value to dispatchEvent() |
| 22:38 | <zewt> | "fire" only lets you create a basic Event, for events with other interfaces, etc. you want dispatch directly, right? |
| 22:38 | <zewt> | that's what i was thinking |
| 22:38 | <annevk> | no fire is also used for events with other interfaces |
| 22:38 | <annevk> | you'd use a modified fire definition |
| 22:38 | <zewt> | how? sounds contradictory |
| 22:39 | <annevk> | http://dev.w3.org/2006/webapi/progress/#firing-events-using-the-progressevent-interface-for-http |
| 22:39 | <annevk> | because otherwise you also need to set the trusted flag, etc. |
| 22:39 | <zewt> | yeah that looks contradictory |
| 22:39 | <zewt> | it's saying "dispatch an event using the Event interface using the ProgressEvent interface" :) |
| 22:40 | <zewt> | not that it's not obvious what's really meant |
| 22:40 | <annevk> | not if you read it in the way that it's overriding |
| 22:40 | <annevk> | which is more logical imo |
| 22:43 | <zewt> | replying to clipboard thread suggesting: |
| 22:43 | <zewt> | 7. Fire an event using the ClipboardEvent interface, with its type attribute initialized to e and its clipboardData attribute initialized to data transfer, at event target. If the event's canceled flag is set then abort these steps. |
| 22:47 | <annevk> | the if statement should prolly be step 8 for clarity |
| 22:47 | <zewt> | it was before, i moved it into 7 based on http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#form-submission-algorithm step 6 |
| 22:48 | <annevk> | hmm |
| 22:48 | <zewt> | seems like having a concise pattern for this is good ... not sure if it's unclear or not |
| 22:49 | <annevk> | maybe I should postpone encoding stuff a bit more and work on DOM next week too |
| 22:51 | <zewt> | let me know if you think strongly one way or the other; don't want to bait people like paul by going back and forth |
| 22:52 | <annevk> | I don't, it's something that can be mended easily over time |
| 22:53 | <annevk> | especially if we make specs more hackable |
| 22:53 | <zewt> | ("this spec hasn't been set in stone so it can start getting out of date, so everyone should use a useless, confusing, decade-old spec" sigh) |
| 22:56 | <annevk> | yeah i don't know what's up with that |
| 22:56 | <annevk> | i can sort of see the i want-to-play-by-silly-rules-so-i-cannot-reference-what-implementors-actually-need, but if you need to reference the newer draft anyway, also referencing crappy material is just wrong |
| 22:57 | <annevk> | that you even need to argue such a point because of some hearsay about "hot debate" |
| 22:57 | <annevk> | ugh |