| 14:48 | <annevk> | I feel like Björn wrote that www-archive message for me... |
| 15:50 | <annevk> | pbarth: did you merry Adam? |
| 15:50 | <annevk> | marry, doh |
| 17:10 | <annevk> | heycam|away: yt? |
| 17:11 | <annevk> | heycam|away: can you default to a string literal in IDL? |
| 17:14 | <annevk> | http://dev.w3.org/2006/webapi/WebIDL/#prod-DefaultValue says yes |
| 19:54 | <jsbell> | [1000, -1, -2, Infinity, -Infinity, NaN].forEach(function(x) { try { document.createElement('select').options.add(document.createElement('option'), x); } catch (e) { console.log(x + ": " + e); } }) |
| 19:55 | <jsbell> | FF17 throws on +/-Infinity. Chrome 23/Safari 6/IE10 throw on -2, +/-Infinity and NaN |
| 19:57 | <jsbell> | Based on the HTML + WebIDL specs I wouldn't expect any of them to throw. :P |
| 20:07 | <jwalden> | optional (HTMLElement or long)? before = null |
| 20:08 | <jwalden> | I don't remember stuff fully to be confident, but I think that takes either an element, or any value (which will then be coerced to long) |
| 20:08 | <jwalden> | so, yeah, not throwing at all I *think* might be spec-right |
| 20:09 | jwalden | doesn't remember the option interface well enough to know what of these options is at all sane |
| 20:22 | <jsbell> | jwalden: I noticed this futzing with the ES number-> IDL long conversion code. |
| 20:23 | <jwalden> | unsurprising :-) |
| 20:23 | <jsbell> | Could toss an [EnforceRange] in the spec's IDL to get throwing behavior on non-finites, but dunno why FF distinguishes NaN, and throwing on < -1 would require prose anyway. |
| 20:23 | <jwalden> | another fun thing to test is { valueOf: function() { return "bazinga"; } } |
| 20:23 | <jwalden> | er, s/return/throw/ |
| 20:25 | <jsbell> | I haven't tried, but I bet incrementing a counter in valueOf would give inconsistent results as well. |
| 20:26 | <jwalden> | undoubtedly :-) |
| 20:33 | jwalden | tries reading Gecko variant code to figure out what causes that behavior, spends too much time following twisty passages, gives up |
| 20:34 | <jwalden> | we'll adhere to webidl requirements in semi-short order, I expect |
| 20:34 | jwalden | doesn't know the timeline for this particular bit of code being converted, tho |
| 20:44 | <annevk> | jsbell: are you sure long accepts NaN? |
| 20:44 | <annevk> | jsbell: that seems kinda unlikely |
| 20:46 | <annevk> | jsbell: don't mind me, I'm wrong :/ |
| 20:48 | <annevk> | jwalden: btw, Ms2ger explained why that algorithm was correct after all |
| 20:49 | <annevk> | jwalden: the global named properties are on some prototype object |
| 20:49 | jwalden | would have thought long == Int32, and ECMAScript conversions would use the ToInt32 operator |
| 20:49 | <annevk> | jwalden: so using the [[GetOwnProperty]] would get there eventually |
| 20:50 | <annevk> | jwalden: yeah that's correct |
| 20:50 | <jwalden> | if that's not the case, that's mildly surprising |
| 20:50 | <jwalden> | in which case NaN would become 0 for your test, jsbell |
| 20:50 | <annevk> | it's ToInt32(ToNumber(V)) |
| 20:50 | <jwalden> | ToNumber(NaN) => NaN, ToInt32(NaN) => 0 |
| 20:50 | <annevk> | http://dev.w3.org/2006/webapi/WebIDL/#es-long (with some exceptions for extended attributes) |
| 20:50 | <jwalden> | for better or worse |
| 20:51 | <annevk> | but Infinity also becomes 0 |
| 20:51 | <annevk> | and Gecko throws for that... |
| 20:51 | <jwalden> | Gecko |
| 20:51 | <jwalden> | er |
| 20:51 | <jwalden> | Gecko's not using webidlish code right now, so all bets are off as to what it does :-) |
| 20:52 | <jwalden> | at least, not for that particular interface/method/argument |
| 20:52 | <annevk> | fair enough |
| 20:52 | jwalden | will be glad when non-webidl stuff is all dead |
| 20:53 | <annevk> | yeah, then we can start fighting Web IDL |
| 20:53 | <annevk> | or something like that :) |
| 20:54 | <jwalden> | I shouldn't be, but I'm continually amazed by how much of Gecko semantics is just "that's what the random internal method that happened to be used, did" |
| 20:55 | <annevk> | it seems kinda natural for any system that grows big, to have a lot of inconsistencies |
| 20:56 | <annevk> | you get that even when there's one person developing the system for an extended period of time |
| 20:57 | <jwalden> | I dunno, I find algorithms are just that much worse to read, usually, if they're not isomorphic to the spec steps |
| 20:58 | <jwalden> | which naturally leads me into writing helper methods like ToUint32 or whatever, where at least if they're wrong it's just a matter of changing guts |
| 20:58 | <jwalden> | rather than having to change a hundred places all converting in different ways |
| 20:58 | <jwalden> | meh, doesn't really matter at this point |
| 20:59 | <annevk> | well that certainly makes sense :) |
| 20:59 | <annevk> | I meant more what came before the standard and to some extent the standards we're developing now; that they all have their inconsistencies |
| 20:59 | <jwalden> | true enough |
| 21:21 | <jsbell> | jwalden: re: "what the random internal method... did" - and the resulting specs are such fun to implement, because you know that in some code base, somewhere, there's some trivial and probably very efficient implementation of what seems like an insanely baroque algorithm. |
| 21:22 | <jwalden> | in my experience, usually the internal method is also insanely baroque and inefficient :-) |
| 21:22 | <jwalden> | with special cases nobody's seriously thought through because some random page needed something |
| 21:22 | <jsbell> | Sure, kill my sense of hope... ;-) |
| 21:22 | <jwalden> | even redundant special cases |
| 21:22 | <jwalden> | heh |
| 21:29 | <annevk> | jsbell: not sure what specs you're reading, but I usually aim to simplify what the implementations did |
| 21:37 | <Hixie> | i have no idea what that mail on www-archive means |
| 21:38 | <Ms2ger> | Hixie, "encodings suck" |
| 21:42 | <annevk> | It's about BOM taking precedence over the encoding declaration and supposedly whether X-Content-Type-Options should influence that or not... And whether it's a good idea to begin with. Overall I took it as subtle critique of the Encoding Standard :-) |
| 21:55 | <Hixie> | sounds complicated |
| 22:39 | <jsbell> | Hixie: Saw "An error occurred submitting your review comment" from the HTML spec. Maybe I typed too much, maybe there's a back-end issue. |
| 22:40 | <Hixie> | looking... |
| 22:40 | <Hixie> | (did you save your comment text, perchance?) |
| 22:41 | <jsbell> | Hixie: it does not appear to have been cleared from the input field, so yes |
| 22:41 | <Hixie> | i got back a "Text Too Long" from bugzilla |
| 22:41 | <Hixie> | thought i worked around that though |
| 22:42 | <Hixie> | ah, i see |
| 22:42 | <Hixie> | let me fix this... |
| 22:45 | <Hixie> | jsbell: do you still have it up? |
| 22:46 | <Hixie> | jsbell: if so, try submitting again |
| 22:46 | <jsbell> | submittifying... |
| 22:46 | <jsbell> | success! |
| 22:46 | <Hixie> | sweet |
| 22:48 | <Hixie> | i really don't understand where these people are coming from who type in random things in that form |
| 22:48 | <Hixie> | got one just now that's just an address |
| 22:48 | <Hixie> | why would you do that? |
| 22:51 | <annevk> | a bot reverse engineering the rules? |
| 22:52 | <Hixie> | doesn't look like it |
| 22:52 | <Hixie> | every one i've seen, they visit a few pages, then send a wacked comment |
| 22:53 | <Hixie> | maybe they're trying to do a search? |
| 22:53 | <Hixie> | and that's just what's got focus? |