/irc-logs / w3c / #webapps / 2008-12-17 / end
Options:
- # Session Start: Wed Dec 17 00:00:01 2008
- # Session Ident: #webapps
- # [00:07] * Joins: heycam (cam@130.194.72.84)
- # [00:08] <Hixie> heycam: i would appreciate your review of my last html5 checkin -- http://html5.org/tools/web-apps-tracker?from=2535&to=2536
- # [00:08] <Hixie> heycam: in particular, please be as anal about the terminology as possible
- # [00:08] <Hixie> heycam: as once i got that batch right, i'm going to start shoving that terminology all over the spec
- # [00:09] <heycam> ok cool, i'll take a look at it this afternoon
- # [00:10] <Hixie> thanks
- # [00:11] <sicking> heycam, does the WebIDL spec currently define what to do about the whole mess of default behaviour when passing null to a function that takes a string?
- # [00:11] <sicking> heycam, as well as other weird conversions, such as passing NaN/Infinity/-1 to a function that takes an unsigned int
- # [00:12] <heycam> sicking, there's a default behaviour of converting null to "null", unless overridden with a [Null] extended attribute
- # [00:13] <heycam> http://dev.w3.org/2006/webapi/WebIDL/Overview.html#es-DOMString
- # [00:13] <sicking> heycam, so we'd have to amend all the DOM-Core methods that take a string but defines behavior for null?
- # [00:13] <heycam> for unsigned longs, it says to just convert them to ToUint32
- # [00:13] <heycam> http://dev.w3.org/2006/webapi/WebIDL/Overview.html#es-unsigned-long
- # [00:14] * sicking would prefer to stick with the mozilla strategy, unsurprisingly
- # [00:14] <heycam> sicking, yeah that's a downside to the current choice of default
- # [00:15] <heycam> what's the mozilla strategy for converting to an unsigned long?
- # [00:15] <sicking> no, i mean for null->string
- # [00:16] <heycam> oh, ok
- # [00:16] <sicking> where we basically say that null is a valid string value that doesn't need conversion
- # [00:16] <heycam> that is the stance i took, too
- # [00:16] <sicking> which is generally treated as empty string, unless something else is indicated
- # [00:17] <sicking> i don't know what we do for unsigned longs
- # [00:17] <sicking> is ToUint32(V) an ECMA thing?
- # [00:17] <heycam> so you'd suggest to change the default handling of null for DOMStrings to convert to an empty string, and have xattrs change that to keeping a null or converting it to the string "null" as required?
- # [00:17] <heycam> sicking, yeah
- # [00:18] <sicking> heycam, sort of yeah. Though conversion to 'null' seems like it would never be required
- # [00:19] <heycam> i haven't encountered a method that does require that
- # [00:19] <heycam> but it is way null stringifies
- # [00:19] <heycam> *the way
- # [00:19] <sicking> heycam, and technically speaking you wouldn't need xattrs for keeping null-as-null either, you could always do that and in prose describe what to do. Though that might be more error prone
- # [00:20] <heycam> sicking, so you'd recommend removing [Null] altogether, defaulting to conversion to empty string, and letting it be overridden in prose?
- # [00:20] <sicking> well, you could argue that no stringification occurs, i.e. null is considered a valid DOMString value. But I agree that that is spec-juggling
- # [00:21] <heycam> another bad thing about [Null] is that it's somewhat of a visual blight in IDL
- # [00:22] <sicking> so first off, any changes here will very likely need browser buy-in. Though that is equally the case for the current draft
- # [00:22] <sicking> since we're talking about some pretty big changes to one or more browsers
- # [00:22] <heycam> sicking, this is just changes to how these things are expressed in the IDL though
- # [00:23] <heycam> those writing the interfaces are free to write their IDL to describe current practice
- # [00:23] <sicking> well, ultimately what we do as default in the IDL i think will be what most functions will use
- # [00:23] <heycam> *unless* you want to interpret already-published IDL with Web IDL
- # [00:23] <heycam> ok
- # [00:24] <sicking> no, i think we don't have to interpret current IDL as webidl. But I do think that the default behavior matters a lot still
- # [00:25] <heycam> ok. i think it's a reasonable argument that since treating null as empty string is most common, that that should be the default.
- # [00:26] <heycam> might do some testing over the holidays to check that that's actually the case
- # [00:30] * Quits: aroben (aroben@69.137.139.251) (Quit: Leaving)
- # [00:37] <sicking> heycam, cool
- # [01:41] * Quits: Lachy (Lachlan@85.196.122.246) (Ping timeout)
- # [01:47] * Joins: Lachy (Lachlan@85.196.122.246)
- # [02:03] * Joins: harry (kcome@58.213.213.72)
- # [03:20] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
- # [04:43] * Quits: anne (annevk@217.174.106.250) (Ping timeout)
- # [06:25] * Quits: phenny (phenny@80.68.92.65) (Client exited)
- # [06:29] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
- # [06:30] * Joins: billyjackass (MikeSmith@mcclure.w3.org)
- # [06:31] * Quits: billyjackass (MikeSmith@mcclure.w3.org) (Client exited)
- # [07:09] * Joins: heycam (cam@203.217.82.242)
- # [07:41] * Joins: phenny (phenny@80.68.92.65)
- # [08:45] * Joins: anne (annevk@217.174.106.250)
- # [10:35] * Joins: tlr (tlr@128.30.52.30)
- # [10:51] * Quits: tlr (tlr@128.30.52.30) (Quit: tlr)
- # [11:00] * Joins: tlr_ (tlr@128.30.52.30)
- # [11:01] * tlr_ is now known as tlr
- # [11:23] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
- # [11:37] * Joins: ArtB (c0646811@128.30.52.43)
- # [11:43] * Joins: Lachy (Lachlan@213.236.208.22)
- # [12:23] <heycam> hi ArtB
- # [13:05] <ArtB> heycam, Hi Cameron
- # [13:48] * Quits: harry (kcome@58.213.213.72) (Quit: Leaving)
- # [14:45] * Joins: harry (kcome@58.217.139.86)
- # [15:09] * Quits: ArtB (c0646811@128.30.52.43) (Quit: CGI:IRC (Ping timeout))
- # [15:09] * Joins: aroben (aroben@69.137.139.251)
- # [15:13] * Joins: ArtB (c0647cda@128.30.52.43)
- # [15:31] * tlr is now known as tlr-bbiab
- # [17:13] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
- # [17:32] * tlr-bbiab is now known as tlr
- # [19:10] * Quits: harry (kcome@58.217.139.86) (Quit: Leaving)
- # [19:13] * Joins: shepazu (schepers@128.30.52.30)
- # [20:05] * Quits: shepazu (schepers@128.30.52.30) (Quit: Core Breach)
- # [20:24] * Joins: Lachy (Lachlan@85.196.122.246)
- # [20:27] * Quits: sicking (chatzilla@63.245.220.242) (Client exited)
- # [20:37] * Parts: anne (annevk@217.174.106.250)
- # [20:44] * Joins: sicking (chatzilla@63.245.220.242)
- # [20:46] * Quits: sicking (chatzilla@63.245.220.242) (Client exited)
- # [20:55] * Joins: sicking (chatzilla@63.245.220.242)
- # [21:09] * Joins: anne (annevk@217.174.106.250)
- # [21:31] * Quits: ArtB (c0647cda@128.30.52.43) (Quit: CGI:IRC)
- # [21:57] * Quits: anne (annevk@217.174.106.250) (Ping timeout)
- # [21:59] * Joins: dave_levin (dave_levin@72.14.227.1)
- # [22:03] * Joins: arve (arve@80.202.66.74)
- # [22:30] * Quits: heycam (cam@203.217.82.242) (Quit: bye)
- # [22:34] * Quits: marcos (marcos@87.196.232.155) (Quit: marcos)
- # [23:16] * Joins: heycam (cam@130.194.72.84)
- # [23:48] * Quits: tlr (tlr@128.30.52.30) (Quit: tlr)
- # Session Close: Thu Dec 18 00:00:00 2008
The end :)