| 00:13 | gsnedders | wonders why Google.com is being so slow |
| 00:14 | <jcranmer> | gsnedders: a lot of networks just went down? |
| 00:15 | <gsnedders> | I mean, taking a minute to connect to "www.google.com" is wrong. |
| 07:06 | <heycam> | Hixie, ping? |
| 07:07 | <Hixie> | here |
| 07:08 | <heycam> | so i'm thinking about your [XXX]es that are meant to be like "partial" interfaces |
| 07:08 | <heycam> | and i see that they all only have attributes on them, no operations |
| 07:09 | <heycam> | so that means what you really want is to avoid having a new object in the prototype chain for objects implementing these interfaces |
| 07:09 | <heycam> | e.g. you don't want a new, empty prototype object in the chain that corresponds to the interface with the applets attribute on it |
| 07:10 | <heycam> | but, i don't think "extending" the interfaces, at the IDL level, is the right thing to do |
| 07:10 | <heycam> | you just want to control the JS aspects of it |
| 07:10 | <heycam> | so e.g. if these extended interfaces did have operations, then they would go on to the HTMLDocument prototype object (in this case) |
| 07:13 | <heycam> | well actually i see you have two kinds of XXXes now |
| 07:13 | <heycam> | on WindowModal, where you separate it because sometimes you want this interface to be implemented and sometimes not, but if it is, then there's no extra object in the prototype chain for WindowModal |
| 07:14 | <heycam> | and for the things in the Obsolete section, where they're separate just so you don't see them in the earlier sections |
| 07:14 | <heycam> | but they are actually part of the same interface |
| 07:16 | <heycam> | ok maybe i'm talking myself into allowing "partial" interface definitions |
| 07:16 | <heycam> | for that second case |
| 07:16 | <heycam> | even though it's only because of how you want to organise the spec |
| 07:16 | <heycam> | but for the WindowModal case i think your XXX does need to be something like NoPrototypeObject |
| 07:19 | <heycam> | maybe partial should also exist to support adding new constants from different specs, like DOMException codes |
| 07:22 | <heycam> | also, i'm thinking of moving a bunch of things from extended attributes into the "proper" syntax |
| 07:22 | <heycam> | like optional arguments, variadic operations |
| 07:23 | <heycam> | i'm gonna give up pretending web idl is a superset of omg idl |
| 07:26 | <Hixie> | (still here, hold on) |
| 07:27 | <Hixie> | heycam: basically my desire is to not have the spec separation affect the prototype chain |
| 07:28 | <Hixie> | heycam: so we should be able to take, e.g., HTMLDocument, or Window, and split it amongst multiple specs and have zero effect on implementation requirements |
| 07:28 | <Hixie> | heycam: basically i'm trying to avoid the problem hsivonen mentions regularly where you end up splitting the tech into silos per wg |
| 07:30 | <heycam> | so, having a [NoPrototypeObject] could do that |
| 07:30 | <heycam> | especially if the interface only has attributes, since they never go in prototype objects |
| 07:30 | <Hixie> | they'll have methods sometimes |
| 07:30 | <Hixie> | i'm surprised that they don't already |
| 07:31 | <heycam> | maybe something like [AugmentPrototype=Window] instead |
| 07:31 | <Hixie> | yes |
| 07:31 | <Hixie> | that would work |
| 07:31 | <Hixie> | and then the "actual" interface name wouldn't matter? |
| 07:32 | <Hixie> | i.e. it'd be an editorial concern only? |
| 07:32 | <heycam> | yes, except for other language bindings |
| 07:32 | <heycam> | which don't have prototypes |
| 07:32 | <Hixie> | well for bindings that have classes i'd want the same thing |
| 07:32 | <heycam> | they'd be proper, separate interfaces still |
| 07:32 | <heycam> | yeah? |
| 07:32 | <Hixie> | the idea is for there to be zero differences |
| 07:32 | <heycam> | how should it matter? |
| 07:32 | <heycam> | if you say "all HTMLDocument objects also implement HTMLDocumentObselete" |
| 07:33 | <heycam> | oh casting would matter |
| 07:33 | <Hixie> | don't you have to explicitly cast from one to the other? |
| 07:33 | <Hixie> | right |
| 07:33 | <heycam> | i mean, you'd need to cast |
| 07:33 | <heycam> | hmm |
| 07:33 | <heycam> | so it sounds like you exactly want a "partial" modifier on interface |
| 07:34 | <Hixie> | the point is we should be able to take HTML5, 10 years from now, when it's all perfectly implemented (hah), and make 15 specs out of it and be able to release that as an Edited Recommendation that has zero changes required to any test suites in any languages |
| 07:34 | <Hixie> | with all the same code working unchanged |
| 07:34 | <Hixie> | that's basically what i'm doing, btw -- taking DOM2 HTML, and splitting it into the "obsolete" and "today" sections in html5 |
| 07:35 | <Hixie> | 10 years after DOM2 HTML was published |
| 07:36 | <heycam> | ok i'm gonna go for a "partial" keyword then, see how it goes |
| 07:36 | <Hixie> | cool |
| 07:36 | <heycam> | partial interface HTMLDocument : ... { /* now stuff */ }; partial interface HTMLDocument { /* old stuff */ }; |
| 07:37 | <Hixie> | do i put it on all interfaces? |
| 07:37 | <heycam> | hmm |
| 07:37 | <heycam> | you want any interface to be extendable? |
| 07:37 | <Hixie> | i'm sure there will be specs that add to Window if there aren't already |
| 07:37 | <heycam> | right |
| 07:37 | <Hixie> | and it would have been nice to be able to add to HTMLElement instead of having the side interfaces, for some cases |
| 07:38 | <Hixie> | but i dunno |
| 07:38 | <heycam> | yeah i'm not sure |
| 07:38 | <Hixie> | i mean, if we have to have it to extend, you're basically saying it's the opposite of "final" |
| 07:38 | <heycam> | well, not really |
| 07:38 | <heycam> | you can extend with ":" |
| 07:38 | <heycam> | but it's a different kind of extending |
| 07:38 | <Hixie> | yeah |
| 07:39 | <Hixie> | ":" and also with "side" interfaces |
| 07:39 | <Hixie> | like how EventTarget is on all Nodes |
| 07:39 | <heycam> | right |
| 07:39 | <heycam> | depends on how you want the prototype chain to look |
| 07:39 | <Hixie> | but for some cases like Window that seems... wrong |
| 07:39 | <Hixie> | yeah |
| 07:39 | <heycam> | yeah Window is a bit special in that regard, in that you think of it as just a pool of properties that you add to |
| 07:39 | <Hixie> | i guess in practice people would just say that the interface they want to extend had "partial" on it |
| 07:39 | <Hixie> | even if it didn't |
| 07:40 | <heycam> | heh perhaps |
| 07:40 | <Hixie> | so in practice even if you say we have to put it on both, it won't matter |
| 07:40 | <Hixie> | it's just nice to annotate one of them (the "not primary" one, there's usually a clear one that is the "primary" one) as being an extention of another |
| 07:42 | <heycam> | it's kinda weird for languages like java to have an interface whose definition changes depending on which specs you decide to implement |
| 07:43 | <Hixie> | why? |
| 07:43 | <Hixie> | how is that different from when you decide how much of one spec to implement? |
| 07:43 | <Hixie> | it's not like spec boundaries reflect actual implementation boundaries, like, ever |
| 07:44 | <heycam> | it's different if you want to use two libraries together, say |
| 07:44 | <heycam> | let's say a spec first defines interface A |
| 07:44 | <heycam> | and a later spec defines an extension to A |
| 07:44 | <heycam> | and both of these specs used this "partial" keyword to allow this |
| 07:45 | <heycam> | one library was compiled with the first A, and another library was compiled with the extended A |
| 07:45 | <heycam> | now both libraries have different A.class files |
| 07:45 | <heycam> | whichever one the class loader finds first is the one that will be usable |
| 07:45 | <heycam> | you need to be sure to get the extended one loaded first somehow |
| 07:46 | <heycam> | but then it's impossible if there were two extensions to A, and each library chose the different extended one |
| 07:46 | <heycam> | you couldn't get both libraries working together in the one program |
| 07:48 | <Hixie> | what about if you use two libraries, and they both implement a part of the same spec? |
| 07:48 | <Hixie> | same problem |
| 07:48 | <Hixie> | literally the same problem, because the next day that spec might be split into two |
| 07:49 | <Hixie> | and the day after that the specs might be merged together again |
| 07:49 | <heycam> | you could at least have the same all-in-one interface implemented by both libraries, but some of those methods just throw a NotImplementedException or something |
| 07:49 | <heycam> | in fact you would need to, to get it to compile |
| 07:50 | <Hixie> | i guess in java maybe. in javascript we encourage implementations that don't support something to not expose it, so that you can test to see if it exists |
| 07:50 | <heycam> | yes |
| 07:51 | <heycam> | it's a benefit of not having to implement a whole interface i suppose |
| 07:51 | <Hixie> | well it's a benefit of easy reification |
| 07:52 | <heycam> | benefit of duck typing (sorta)? |
| 07:53 | <Hixie> | vaguely |
| 07:53 | <Hixie> | not exclusively though |
| 07:53 | <Hixie> | it's a benefit of late binding and easy reification |
| 07:54 | <Hixie> | sorry, not reification, reflection |
| 07:54 | <Hixie> | late binding and reflection |
| 07:54 | <Hixie> | because you can compile code that uses something without it needing to be supported, and then you can test to see if that code would work, and if it doesn't, you can skip it |
| 07:57 | <heycam> | so for something like WindowTimers, would you want to do that with partial instead? |
| 08:01 | <Hixie> | yeah |
| 08:01 | <Hixie> | actually no |
| 08:01 | <Hixie> | well |
| 08:01 | <Hixie> | gah, i dunno |
| 08:02 | <Hixie> | WindowTimers is also implemented by the WorkerUtils object |
| 08:02 | <heycam> | ah |
| 08:02 | <Hixie> | but i'd want it to appear on the prototype of WorkerUtils (which itself should just appear on the prototype of two other interfaces), and i'd want it to appear as if it was part of Window also |
| 08:02 | <Hixie> | and it's specced in the same spec as Window but not the same spec as WorkerUtils |
| 08:03 | <heycam> | do any of these use ":"? |
| 08:03 | <heycam> | or is it [ImplementedOn] |
| 08:04 | <Hixie> | none of these use : |
| 08:04 | <heycam> | btw i think i like the "Node implements EventTarget;" kind of syntax |
| 08:04 | <Hixie> | oh actually that's a lie |
| 08:04 | <Hixie> | the WorkerUtils thing is implemented on interfaces that do use inheritance |
| 08:05 | <heycam> | [AugmentPrototype] Window implements WindowTimers; |
| 08:05 | <heycam> | or if you're doing something with ":" |
| 08:06 | <heycam> | interface ExtendedWindow : [AugmentPrototype] Window ... |
| 08:06 | <heycam> | but have Java interfaces change depending on which specs you choose to implement seems bad to me |
| 08:07 | <Hixie> | well i don't really mind how you end up doing things for java really |
| 08:07 | <Hixie> | i'm mildly professionally interested in how what you do ends up for C++, because of Native Client's use of WebIDL |
| 08:07 | <Hixie> | but really my interest lies in JS |
| 08:09 | <heycam> | having c++ classes with different members seems as bad as with java |
| 08:09 | <heycam> | mixin abstract classes (just like different java interfaces) seems ok though |
| 08:12 | hsivonen | raises eyebrows at www-tag |
| 08:15 | <hsivonen> | s/www-tag/www-archive- |
| 08:20 | <heycam> | Hixie, i'll think about partial/[AugmentPrototype] a bit more, gotta head home now |
| 08:51 | <Hixie> | heycam: cool, thanks |
| 11:40 | <zcorpan_> | gsnedders: http://gsnedders.html5.org/outliner/process.py?url=http%3A%2F%2Fsimon.html5.org%2Fsandbox%2Fhtml%2Fgoogle-chrome-comic seems wrong |
| 14:40 | <annevk42> | http://troogle.wordpress.com/2009/06/17/google-is-trying-to-set-us-up-breaking-news-the-new-web-project-revealed-before-its-release/ wtf |
| 14:40 | <annevk42> | especially since http://whois.domaintools.com/thenewwebproject.com points back to them |
| 14:41 | <annevk42> | some kind of elaborate joke that did not cover its tracks? |
| 14:42 | <Dashiva> | "we believe the GOVERNMENT is involved too" |
| 14:42 | <Philip`> | "Google has plans to work together with Microsoft ..." - clearly this whole thing is just a work of fiction |
| 14:43 | <Dashiva> | It looks like a parody of that British guy who walked around with visible secret papers |
| 14:44 | <annevk42> | http://cocaman.ch/wp/2009/06/the-new-web-project-its-a-movie-and-plot-against-google/ |
| 14:46 | <annevk42> | they could have at least used a proxy for the whois |
| 15:55 | <Philip`> | http://asyourworldchanges.wordpress.com/2009/05/31/hear-me-stumble-around-white-house-recovery-and-data-gov-web-sites/ looks potentially informative |
| 20:08 | <ojan> | I know arun's not around, but maybe others here know the answer to my question...why does File API need getAsDataURI and getAsText? |
| 20:09 | <ojan> | as in, can't you replace getAsDataURI with a few lines of code wrapping getAsText? |
| 20:18 | <annevk2> | i guess it's just a convenience thing |
| 20:18 | <annevk2> | not sure it's needed if we get the getAsLocalURL() |
| 20:19 | <annevk2> | ojan, seems best to comment on public-webapps |
| 20:20 | <ojan> | annevk2: will do. just wanted to make sure i wasn't missing something obvious |
| 20:20 | <ojan> | annevk2: yeah, getAsLocalURL does seem very useful to me |
| 20:20 | <annevk2> | oh wait, I guess PNG and such won't get you text but will get you data URLs |
| 20:21 | annevk2 | wonders why he did not think of that |
| 20:21 | <annevk2> | but then getAsText might work anyway, it's not very well defined |
| 20:22 | <ojan> | i was thinking that if you passed base64 as the encoding to getAsText it ought to work for binary content |
| 20:24 | <annevk2> | base64 is not a character encoding, however |
| 20:24 | <annevk2> | but then getAsText is underdefined |
| 21:26 | <annevk5> | oh yay, some guy is advocating software patents on www-style |
| 21:54 | <sicking> | Hixie, ping |
| 22:15 | <Hixie> | sicking: here |
| 22:15 | <sicking> | Hixie, is there a draft for File drag-n-drop? |
| 22:16 | <sicking> | Hixie, we have an intern that's going to start working on it pretty much today |
| 22:16 | <sicking> | Hixie, we can do a lot without a spec for now I think, but it'd be nice to have a draft |
| 22:16 | <annevk5> | there's a proposal on the WHATWG list |
| 22:17 | <Hixie> | i'm waiting for arun's draft to stabalise |
| 22:17 | <Hixie> | but basically i expect datatransfer to get some new api for files |
| 22:18 | <Hixie> | maybe make getData and setData take |any| instead of DOMString |
| 22:18 | <Hixie> | and have them return either DOMStrings for Files |
| 22:18 | <Hixie> | or alternatively, have the files be totally separate |
| 22:18 | <sicking> | Hixie, ok |
| 22:18 | <Hixie> | just a .files or something on DataTransfer |
| 22:19 | gsnedders | hits more bugs in PHP. ergh. |
| 22:19 | <Hixie> | oh hey, arun is mozilla too, i forgot |
| 22:19 | <Hixie> | go light a fire under his chair :-) |
| 22:19 | <Hixie> | i think we'll go with just .files |
| 22:20 | <gsnedders> | Hixie: But that'll mean he'll have to move away from his computer, thus making him take longer to write the spec |
| 22:20 | <Hixie> | gsnedders: it is implied that he'd be tied down first and only released once the spec was done, thus increasing the motivation to work on it :-) |
| 22:20 | <Hixie> | sicking: yeah so i imagine we'll add a .files that returns a sequence<File> |
| 22:22 | <sicking> | Hixie, ok |
| 22:22 | <sicking> | Hixie, ugh, we'll have to add support for sequence<> to gecko... |
| 22:22 | <sicking> | Hixie, the idea is that that'll map to a JS array, right? |
| 22:24 | <sicking> | annevk5, where is the proposal on the whatwg list? What's the subject line? |
| 22:25 | virtuelv | thinks "file" should be the atom here, whether that is a file or collection of files |
| 22:26 | <virtuelv> | and treat, at least, zip files as if they were collections of files |
| 22:26 | <othermaciej> | sicking: fwiw we have a patch to implement it for WebKit, and we proposed an API on WHATWG |
| 22:26 | <virtuelv> | that way, an application could easily process openoffice (and similar) documents like epub |
| 22:27 | <othermaciej> | sicking: our version is fairly agnostic with respect to details of Arun's draft |
| 22:27 | <sicking> | othermaciej, cool |
| 22:27 | <sicking> | othermaciej, do you have a link to the draft you proposed? |
| 22:27 | <gsnedders> | Hixie: But then you risk him dying before he finishes the spec, which means you need to find a new editor |
| 22:28 | <othermaciej> | http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/020302.html |
| 22:28 | <othermaciej> | sicking: ^ |
| 22:30 | <Hixie> | that's basically what i just described :-) |
| 22:30 | <Hixie> | sicking: sequence<T> is just shorthand for an interface with a length property and an item() property or something like that, i think |
| 22:30 | <Hixie> | sicking: basically i just mean your regular DOM list of things |
| 22:32 | gsnedders | gives up trying to obtain Lightroom, seeming Adobe keep refusing to sell it to me |
| 22:32 | <gsnedders> | Oh well, their lost sale. |
| 22:34 | <sicking> | Hixie, ok |
| 22:44 | <sicking> | othermaciej, btw, have you had a look at the API that Arun proposed for File? |
| 22:45 | <sicking> | othermaciej, I know FileDialog is still controversial, but it'd be nice to hear how you feel about File |
| 22:45 | <othermaciej> | sicking: not yet |
| 22:45 | <othermaciej> | sicking: on my TODO list of spec review |
| 22:46 | <othermaciej> | I just did a careful review of ForceTLS so I'm in a reviewing mood |
| 22:46 | <sicking> | hehe |
| 22:46 | <sicking> | sweet |
| 22:46 | <othermaciej> | sicking: I expect to have issues with it if there's still synchronous file I/O, which I suspect there is |
| 22:47 | <sicking> | othermaciej, nope, asynch only |
| 22:47 | <othermaciej> | then maybe not so much! |
| 22:47 | <sicking> | sweet! |
| 22:47 | <sicking> | i know you guys had concerns about googles Blob proposal, which was async only |
| 22:47 | <othermaciej> | we're obviously interested in making file access better, and it would be nice to have fine DnD and our <input type="file" multi> fuly spec'd |
| 22:48 | <sicking> | not sure what that feedback was though, so not sure if it applies to File |
| 22:48 | <othermaciej> | I dunno |
| 22:48 | <Hixie> | i'll spec both of those within days of arun's proposal being stable |
| 22:48 | <sicking> | othermaciej, Agreed. I think the only controversial part is FileDialog, assuming you're fine with file I/O |
| 22:48 | <othermaciej> | right now we're just using the File interface as a dumb handle |
| 22:56 | <Hixie> | sicking: oh i got a response back from the gmail guys about the filedialog thing -- if you can get arun here that'd be great to discuss it |
| 22:57 | <sicking> | Hixie, you should mail arun and me so we can figure out a day that works |
| 23:00 | <sicking> | Hixie, what about storing File in localStorage? |
| 23:00 | <sicking> | Hixie, I'd imagine that that's needed for offline-gmail |
| 23:07 | <Hixie> | sicking: well i'm free whenever |
| 23:07 | <annevk5> | sicking, would that do a copy or reference the file on disk? |
| 23:07 | <Hixie> | sicking: gmail uses the sql database stuff for their offline gmail |
| 23:08 | <Hixie> | sicking: but yes, they would like a way to store references to Files while waiting for an opportunity to upload them |
| 23:08 | <Hixie> | sicking: i was more talking about FileDialog though |
| 23:08 | <Hixie> | sicking: turns out they didn't use flash to avoid using <input type=file> at all -- in fact they didn't even list that as a reason for using flash until i specifically asked them about it |
| 23:08 | <Hixie> | sicking: and then they dismissed that as not a big deal |
| 23:08 | <annevk5> | if you just wanna store references the local:<id> thing would work I think, you can just store those in localStorage |
| 23:09 | <sicking> | annevk5, how its stored seems like an implementation detail. I'd imagine sqlite has blob support |
| 23:09 | <annevk5> | Hixie, did they use it for async upload and multiple files? |
| 23:10 | <Hixie> | sicking: i wouldn't expect the local:<id> thing to survive page load, but i guess that depends on how we define it |
| 23:10 | <sicking> | Hixie, yeah, my question about localStorage was orthogonal to the meeting |
| 23:10 | <Hixie> | er |
| 23:10 | <Hixie> | s/sicking/anne/ |
| 23:10 | <annevk5> | sicking, it's not an implementation detail, a reference to the file is very different from copying it |
| 23:11 | <annevk5> | e.g. the user could modify the file later on |
| 23:11 | <Hixie> | annevk5: the two things they said were multiselection of photos, and file upload progress. |
| 23:11 | <sicking> | annevk5, ah, yes, we should define that it's the contents of the file at the time of the call to store it in localStore |
| 23:11 | <annevk5> | Hixie, yay for me guessing why they used Flash |
| 23:12 | <annevk5> | and boo for sicking not believing me :p |
| 23:12 | <Hixie> | annevk5: and then they added dnd of files, local display of files while uploading, and selecting or uploading a whole folder at once |
| 23:12 | <sicking> | annevk5, i prefer data over guessing |
| 23:12 | <Hixie> | and finally they mentioned the <input accept=""> feature (though not by name) |
| 23:12 | <sicking> | annevk5, except when I'm the one guessing |
| 23:12 | <sicking> | annevk5, :) |
| 23:12 | <annevk5> | sicking, so it appears :) |
| 23:12 | <Hixie> | oh and resuming uploads after browser crash |
| 23:13 | <Hixie> | though that one was more theoretical |
| 23:13 | <sicking> | Hixie, flash supports that? |
| 23:13 | <annevk5> | i always wonder whether selecting a folder should be a UI feature or some semantic thing like <input type=folder> |
| 23:13 | <Hixie> | i think that was after they transitioned from why they used flash to what they wanted most of all |
| 23:14 | <sicking> | Hixie, localStorage being able to store files would take care of that |
| 23:14 | <Hixie> | anyway their answer to "so, uh, styling of <input type=file> isn't an issue?" was basically "oh i guess that would be nice too" but they basically said it wasn't a big deal compared to the rest |
| 23:14 | <Hixie> | so i vote for dropping FileDialog for now |
| 23:14 | <sicking> | we'll see |
| 23:14 | <Hixie> | sicking: or the sql database, yeah |
| 23:15 | <sicking> | Hixie, yeah, though i'm not sure what our timeline is for sql database. I think we still want to see some other API |
| 23:15 | <sicking> | Hixie, have had some discussions about that internally recently |
| 23:15 | <Hixie> | yeah, we were talking about it in #developers recently too |
| 23:15 | <sicking> | ok |
| 23:16 | <Hixie> | basically i'm gonna do nothing on the sql front until october and then i'm gonna suggest moving to LC |
| 23:16 | <sicking> | mostly due to the pains of standardizing a SQL dialect, and then having to implement a sql parser that maps that dialect to sqlite |
| 23:16 | <Hixie> | and after that look into speccing teh actual dialect |
| 23:16 | <Hixie> | so you have until then to come up with a better solution :-) |
| 23:16 | <sicking> | i don't see how we could move into LC without a dialect |
| 23:16 | <Hixie> | which i'd likely support since i have no desire to actual spec out the dialect :-) |
| 23:17 | <sicking> | heh |
| 23:17 | <sicking> | hence i vote for File in localStorage for now :) |
| 23:17 | <Hixie> | well the dialect would be its own spec i think |
| 23:17 | <sicking> | and across postMessage |
| 23:17 | <Hixie> | i don't know what file in localStorage would really be |
| 23:17 | <Hixie> | postMessage should definitely support it |
| 23:18 | <sicking> | Hixie, what do you mean, what it would be? |
| 23:18 | <gsnedders> | Oh dear… |
| 23:18 | <Hixie> | sicking: well localStorage up to now has only been unstructured name-value string pairs |
| 23:18 | <sicking> | Hixie, can't we just make the value <string-or-file>? |
| 23:18 | <gsnedders> | If you follow the rules for comparing charsets in UTS #22, you end up with iso-ir-9-1 and iso-ir-91 being identical, but they shouldn't be. |
| 23:19 | <Hixie> | sicking: i don't think gmail wants an unstructured answer here; and extending DOMString to DOMString-or-File seems weird when you don't allow anything else |
| 23:19 | <sicking> | nono, not touch DOMString |
| 23:19 | <Hixie> | gsnedders: do browsers support those? |
| 23:19 | <sicking> | that would be, um, crazy |
| 23:19 | <gsnedders> | Hixie: No idea. |
| 23:19 | <Hixie> | sicking: that's what i'm saying :-P |
| 23:19 | <Hixie> | sicking: anyway, send mail |
| 23:19 | <Hixie> | sicking: i'm swamped right now |
| 23:19 | <sicking> | ok |
| 23:20 | <Hixie> | sicking: and waiting for arun to finish his draft before i think of this |
| 23:20 | <gsnedders> | Hixie: On an HTML 5 note, it'd be nice if the charset override table used the same case as the IANA registry (i.e., lowercase "w" for "windows-*") |
| 23:20 | <sicking> | ok, i'll try to spend some time with him touching up the current draft |
| 23:21 | <sicking> | it needs a lot of editing, but I'm not sure that the actual APIs will be much different from what we have now |
| 23:21 | <sicking> | apart from Annes bikeshedding ;) |
| 23:21 | <Hixie> | gsnedders: send mail |
| 23:21 | <sicking> | and possibly FileDialog since you're all a bunch of pansies ;) |
| 23:21 | gsnedders | was expecting that answer :) |
| 23:21 | <othermaciej> | Hixie: the reasons cited for using Flash to upload sound just like what the MobileMe people told us |
| 23:22 | <othermaciej> | which is why we added multi-file selection and file upload progress (via XHR) to Safari |
| 23:22 | <annevk5> | sicking, arun already accepted all my comments :) |
| 23:22 | <annevk5> | sicking, well, apart from FileDialog, but it seems I'm not alone |
| 23:23 | <sicking> | annevk5, see above re 'pansy' ;) |
| 23:24 | <annevk5> | sicking, says the man who doesn't wanna do redirects :p |
| 23:25 | <sicking> | annevk5, redirects are the root of all evil |
| 23:25 | <sicking> | annevk5, together with money |
| 23:25 | <sicking> | annevk5, and premature optimizations |
| 23:25 | <Hixie> | scripting modal dialogs are the root of more evil than redirects :-P |
| 23:26 | <sicking> | there's going to be a dialog no matter what (in the non-dnd case) |
| 23:26 | <Hixie> | a user-invoked one is not a big deal |
| 23:26 | <sicking> | The difference between having it triggered by an arbitrary click, and on a JS call, is very small |
| 23:26 | <sicking> | Hixie, UAs are free to warn instead of putting up a dialog if the JS-call happens outside a click |
| 23:27 | <sicking> | Hixie, a'la popup blockers |
| 23:28 | <Hixie> | sicking: any feature that is admitted to need popup-blocker-like treatment _at the design stage_ is imho a non-starter |
| 23:35 | <sicking> | Hixie, i don't think it needs a popup blocker |
| 23:35 | <sicking> | Hixie, IE has had this API for ages. Granted, that's not the best indicator ever |
| 23:36 | <sicking> | Hixie, also, geoid is doing the same thing |
| 23:39 | <Hixie> | IE doing something is not a good indicator that it is secure. |
| 23:39 | <sicking> | i know, but i've never heard or people being annoyed by it |
| 23:39 | <Hixie> | and the geoloc stuff isn't a modal dialog, it pops up an asynchronous UI that can then later cause the script to get a callback |
| 23:39 | <sicking> | or attacked by it |
| 23:39 | <Hixie> | anyway |
| 23:39 | <sicking> | FileDialog is async too |
| 23:39 | <Hixie> | we don't have a need for this, and people aren't really happy about it |
| 23:40 | <Hixie> | so why do it |
| 23:54 | <Hixie> | hsivonen, others: i'm writing a section for the parser spec talking about some error handling cases and basically explaining how they end up as they do |
| 23:54 | <Hixie> | if you have any specific error cases you would like me to discuss in particular, let mek now |