| 00:10 | <ytrezq> | Hello, How I may enable content-encoding compression from a CGI script? I mean how I can set the correct line in the http header? |
| 01:09 | <gsnedders> | So Test262 is on GitHub, and they're considering merging the PRs as enough for licensing, so yay easier submissions! |
| 01:09 | <gsnedders> | On the other hand, will they keep up with PRs? |
| 01:25 | <annevk-cloud> | Ms2ger: looks like you should file a bug |
| 03:34 | <foolip> | is it considered ugly to use float in WebIDL? |
| 03:35 | <foolip> | we're considering making some attributes float in WebVTT, but if we go with double we're going to waste memory, which I don't want |
| 03:36 | <foolip> | but with float you can have a strange case that the value you set is not the value you then get back (in JavaScript, that is) |
| 03:36 | <foolip> | nessy: ^ |
| 03:54 | <nessy> | foolip: float is part of WebIDL http://www.w3.org/TR/WebIDL/#idl-float - but yeah, is there a preference? |
| 04:05 | <nessy> | foolip: I just checked and there are no "float" values in use in IDL in the HTML spec, if that's any indication (they are all double) |
| 04:07 | <nessy> | foolip: my guess is it's left to the browser as a quality of implementation issue (but Hixie can clarify) |
| 05:50 | <Hixie> | foolip: why would it waste memory, given that it's going to be a JS Number in any case? |
| 06:34 | <zcorpan> | foolip: http://heycam.github.io/webidl/#idl-float says double is preferred |
| 06:38 | <Domenic_> | One day, it will all be "number." With some validation annotations. |
| 06:40 | <Domenic_> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=24241#c4 |
| 06:56 | <foolip> | Hixie: if the IDL says double and you store it as float internally, it seems trivial to write a test case that would fail: cue.line=veryPreciseNumber;assert(cue.line==veryPrecisNumber) |
| 06:56 | <foolip> | zcorpan: have you looked through https://www.w3.org/Bugs/Public/show_bug.cgi?id=19836 ? |
| 07:00 | <zcorpan> | foolip: have now |
| 07:06 | <foolip> | zcorpan: WDYT? |
| 07:06 | <foolip> | I don't want the implementation to have to store these things as double internally, that's just wasteful |
| 07:08 | <zcorpan> | foolip: i'm not competent about memory stuff, but can't you just store as double when necessary and use a more compact type otherwise? |
| 07:09 | <zcorpan> | foolip: i'd just specify double and let the smart guys figure out how to do it efficiently :-) |
| 07:09 | <foolip> | zcorpan: not really, having two different representations massively complicates things, it'll end up worse than just using double everywhere |
| 07:10 | <foolip> | zcorpan: would you complain when your test case fails to get the same number out of the attribute as you put in? |
| 07:11 | <zcorpan> | foolip: that seems like the wrong question |
| 07:11 | <zcorpan> | foolip: more relevant is if authors would complain or worse, write buggy code but not realize it |
| 07:13 | <zcorpan> | foolip: but i fail to see how this attribute is different from all other doubles in html |
| 07:13 | <foolip> | I don't know, is it common for things that are double to not actually have double precision? |
| 07:14 | <zcorpan> | at some point html changed all floats to doubles |
| 07:15 | <foolip> | so WebIDL says "Unless there are specific reasons to use a 32 bit floating point type, specifications should use double rather than float" |
| 07:15 | <foolip> | is "we don't need double precision" a "specific reason"? :) |
| 07:16 | <zcorpan> | if it was it wouldn't say that :-P |
| 07:18 | <zcorpan> | video.volume is double |
| 07:19 | <foolip> | the thing with cues is that you will have lots of them, so small differences matter more |
| 07:20 | <foolip> | so, OK, I guess that using float in WebIDL isn't cool, now what |
| 07:21 | <foolip> | I suppose just use float internally and hope that nobody writes that test case |
| 07:23 | <zcorpan> | no :-) |
| 07:23 | <zcorpan> | ask on public-script-coord, the "there are lots of cues" reason might be valid |
| 07:24 | <zcorpan> | the same discussion was had about something in http://dev.w3.org/fxtf/geometry/ ... i don't remember what the reasoning was but it seems it now doesn't use float |
| 07:26 | <foolip> | zcorpan: ok, will allow double into the spec first and write that email second |
| 07:26 | <foolip> | nessy: ^ |
| 08:16 | <Ms2ger> | Hrm |
| 08:17 | <Ms2ger> | If you call click() on a disabled button, should a click event be fired? |
| 08:19 | <foolip> | Ms2ger: "yes" seems like the simplest answer |
| 08:19 | <Ms2ger> | Is there anything wrong with my test at http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2775? |
| 08:22 | <foolip> | Ms2ger: probably, but http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#run-synthetic-click-activation-steps doesn't seem to cared about disabled, so that bit doesn't seem wrong |
| 14:31 | <macfreek> | Hi, I dropped a mail to admin⊙wwo for an account, but did not yet get a reply. If someone here is able to help, please reply. Thanks! |
| 14:31 | <macfreek> | (the mail was send last Friday) |
| 14:38 | <MikeSmith> | macfreek: will look now |
| 14:38 | <macfreek> | thanks. |
| 14:38 | <MikeSmith> | but please hang around here longer than 5 minutes this time :) |
| 14:38 | <macfreek> | NP :) |
| 14:43 | <gsnedders> | Is there any Java DOM impl that works with nu.validator.htmlparser.dom.HTMLDocumentBuilder with XMLViolationPolicy = ALLOW? |
| 14:44 | <MikeSmith> | gsnedders: not that I'm aware of |
| 14:44 | <gsnedders> | Okay. |
| 14:44 | <MikeSmith> | but I'm not so familiar with what's out there |
| 14:44 | <MikeSmith> | hsivonen would certainly know better |
| 14:44 | <MikeSmith> | and maybe smola |
| 14:45 | <gsnedders> | I'm probably best suited just creating a minimal TreeBuilder that just keeps the parser right, anyway. |
| 14:46 | <MikeSmith> | yeah that might not require so much effort really |
| 14:52 | <hsivonen> | gsnedders: I don't know, but it seemed sensible to keep open the option that someone might write one |
| 14:52 | <hsivonen> | gsnedders: You might want SaxTree |
| 14:57 | <MikeSmith> | macfreek: please either DM me your e-mail address and username you want, or just type in here |
| 15:02 | <gsnedders> | hsivonen, MikeSmith: if I come up with a whole load of questions, should I ask you here, by email personally, or some ML? |
| 15:08 | <MikeSmith> | gsnedders: I would be happier with questions here but hsivonen would be more help than me and I suspect he'd prefer direct e-mail so that's probably a better choice |
| 15:11 | <gsnedders> | The other important question before starting anything: is it up to date with the spec? |
| 15:27 | <MikeSmith> | gsnedders: the parser behavior is as up to date with the spec as the gecko parser is |
| 15:39 | <hsivonen> | gsnedders: You can ask here or in email. the latest .zip release is not up to date. (I should fix.) The repo is almost up to date except for a couple of minor things. |
| 15:39 | <gsnedders> | hsivonen: I was looking at the repo anyway :) |
| 18:07 | <Hixie> | well https://www.w3.org/Bugs/Public/show_bug.cgi?id=24408 is special |
| 18:08 | <Hixie> | foolip: depends if it's readonly or writable, i'm not clear on what you're doing exactly |
| 18:11 | <Hixie> | Ms2ger: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24396 what am i supposed to do? is this different from the bug it was cloned from? i'm confused. |
| 18:11 | <Ms2ger> | Hixie, document != window |
| 18:12 | <Hixie> | there's two sets of these? jesus |
| 18:13 | <Domenic_> | So the usual way of extending navigator with a "namespace" seems to be... creating a non-constructable class, somehow magically constructing an instance of it, then putting that instance on `navigator`? |
| 18:13 | <Hixie> | what do you mean by "namespace"? |
| 18:14 | <Domenic_> | e.g. navigator.storageQuota.queryInfo("temporary"), navigator.storageQuota.requestPersistentQuota(0), both functions are under the "storageQuota" namespace |
| 18:15 | <Hixie> | ah |
| 18:15 | <Hixie> | you don't want to use the word "namespace" for that, that's just confusing |
| 18:15 | <Hixie> | if you mean, "how do i add members to an interface defined in another specification", there's two ways that are considered good practice |
| 18:15 | <Hixie> | 1. ask the editor of said specification to add the member |
| 18:15 | <Hixie> | 2. create a "partial interface". |
| 18:16 | <Domenic_> | Sure, that's not the part I'm confused on |
| 18:16 | <Domenic_> | The part I'm confused on is what you put in that partial interface |
| 18:16 | <Domenic_> | it seems the tradition is to create a non-constructible class, then put a magically-constructed instance of that class in the partial interface |
| 18:16 | <jgraham> | Yes |
| 18:17 | <Domenic_> | welp |
| 18:18 | <jgraham> | Well it's not like anyone actually finds it hard to use |
| 18:18 | <Hixie> | wait, what? |
| 18:18 | <Hixie> | how do you put a "magically-constructed instance" of a "non-constructible class" in an interface? |
| 18:18 | <jgraham> | and we couldn't have really waited until 20XY for ES to finally standardise modules |
| 18:18 | <Domenic_> | jgraham: could have just used normal objects and functions |
| 18:18 | <Domenic_> | Hixie: using magic WebIDL powers |
| 18:19 | <jgraham> | Hixie: I assume he means something like navigator in window.navigator |
| 18:19 | <Hixie> | if you want to add "requestPersistentQuota" to "storageQuota" you just say "partial interface StorageQuota { void requestPersistentQuota() }" |
| 18:19 | <Domenic_> | you can put [NoInterfaceObject] on something, but still somehow create instances of it by doing readonly attribute NonConstructibleClass thingy |
| 18:19 | <jgraham> | Domenic_: Not sure how that would have been better. Or necessarily worked at all |
| 18:19 | <Hixie> | oh you mean how do you put the storageQuota attribute itself onto Navigator? |
| 18:20 | <Domenic_> | jgraham: pretty simple. navigator.storageQuota = { queryInfo() { /* algorithm for query info */ }, requestPersistentQuota() { /* algorithm for requesting a quota */ } }; |
| 18:20 | <Domenic_> | Hixie: yes, that's the issue. |
| 18:20 | <Hixie> | partial interface Navigator { readonly attribute StorageQuota storageQuota; }, "on getting, the storageQuota attribute must return an instance of the StorageQuota interface. The same instance must be returned each time." |
| 18:21 | <Hixie> | and interface StorageQuota { } |
| 18:21 | <Hixie> | no need for any [attributes] |
| 18:21 | <jgraham> | Hixie: This isn't a practical question afaict |
| 18:21 | <Hixie> | oh |
| 18:21 | <jgraham> | This is a theoretical purity question |
| 18:21 | <Domenic_> | well, ok, if StorageQuota is constructible, then that makes sense |
| 18:21 | <Domenic_> | this isn't very theoretical |
| 18:21 | <Domenic_> | this is a "how would i implement this API in jsdom" question |
| 18:21 | <Hixie> | why would it be constructible? |
| 18:21 | <Hixie> | it has no constructor |
| 18:21 | <Domenic_> | how do you create instances of it then? |
| 18:21 | <Hixie> | you just do |
| 18:21 | <Hixie> | the browser can do whatever |
| 18:21 | <Domenic_> | ... O_O |
| 18:22 | <jgraham> | Domenic_: In general the idea that you can write the DOM in pure JS with no external environment is brokwn |
| 18:22 | <jgraham> | *broken |
| 18:22 | <Hixie> | interfaces defined in IDL can't ever be constructed from JS, they're all "magical" in that they have browser code backing it |
| 18:23 | <Hixie> | i mean even if they have constructors, what you get back is a browser-implemented instance |
| 18:23 | <Domenic_> | jgraham: all i'm asking is for the DOM to expose objects to JavaScript that actually can be implemented in JavaScript. Not APIs that are impossible for a normal JS programmer to ever create and expose to another JS programmer. |
| 18:23 | <Hixie> | the prototypes are browser-created prototypes |
| 18:23 | <Hixie> | etc |
| 18:23 | <Hixie> | i don't understand |
| 18:24 | <Hixie> | why would you ever want to create one of these from JS? |
| 18:24 | <Domenic_> | this is basically a document.all issue |
| 18:24 | <Domenic_> | it's impossible for JS to create an object that has properties but is falsy |
| 18:24 | <Domenic_> | similarly it's impossible for JS to create a non-constructible class that somehow also has instances existing as a property of navigator |
| 18:24 | <Hixie> | it's like how you can't create a Win32 window without using the Win32 API |
| 18:24 | <Domenic_> | both are crazy |
| 18:27 | <Hixie> | what do you mean by "non-constructible class" exactly? |
| 18:27 | <Hixie> | in JS there are no classes and everything is constructible, no? |
| 18:28 | <Hixie> | i guess only Functions are constructible |
| 18:28 | <Hixie> | i don't really understand the question |
| 18:28 | <Domenic_> | "class" in JS is shorthand for constructor function with a well-defined prototype |
| 18:28 | <Domenic_> | (formalized in ES6 by the `class` keyword syntactic sugar) |
| 18:28 | <jgraham> | Hixie: There's no value of X such that new X() will give you back a storageQuota |
| 18:29 | <Domenic_> | jgraham: and, that wouldn't be a problem, except that Object.getPrototypeOf(navigator.storageQuota) gives you a well defined StorageQuota.prototype object |
| 18:29 | <Hixie> | jgraham: isn't that true for all objects in DOM? |
| 18:29 | <jgraham> | Hixie: Not really |
| 18:29 | <jgraham> | I mean you can do new Event() these days |
| 18:30 | <Hixie> | sure but it's not a generic JS-backed Event |
| 18:30 | <Hixie> | it's a browser-implemented Event |
| 18:30 | <jgraham> | Sure |
| 18:30 | <Hixie> | so it's not a "class" |
| 18:30 | <Domenic_> | sure it is |
| 18:30 | <Domenic_> | it's a function which vends instances of its prototype |
| 18:30 | <Domenic_> | (when called with `new`) |
| 18:30 | <jgraham> | Well it depends on whether you can actually implement an Event in js with equivalent semantics |
| 18:30 | <Hixie> | its prototype is kinda useless though, it's full of native code functions |
| 18:31 | <Domenic_> | that's a useful prototype |
| 18:31 | <Hixie> | i guess i don't understand what we're talking about then |
| 18:31 | <Domenic_> | the problem is not that sometimes methods can be [native code] |
| 18:31 | <Hixie> | what's the problem we're trying to solve? |
| 18:31 | <Domenic_> | the problem is that you can create frankenstein objects exposed to JS but not possible for a JS programmer to ever create himself, or to encounter outside of this weird browser world |
| 18:32 | <jgraham> | OK, then I am also confused. I also don't understand how far down you want to push this |
| 18:32 | <jgraham> | I don't understand why you care about being able to do new X() but not about the fact that you can't implement any of the properties of an X |
| 18:32 | <Domenic_> | such as, a `storageQuota` property which is an instance of `StorageQuota.prototype` where `StorageQuota` is not actually a constructor but instead a function that always throws. |
| 18:33 | <Hixie> | why is "you can create frankenstein objects exposed to JS but not possible for a JS programmer to ever create himself" a problem? |
| 18:34 | <Domenic_> | well, i think that's our fundamental point of contention :) |
| 18:34 | <jgraham> | (one could create an object in JS that would allow something to be constructed once, but not again, I think) |
| 18:34 | <Hixie> | Domenic_: is it a problem that the same is true in the Win32 API? That there are concepts that exist as singletons in the API and can't be created from user code? |
| 18:34 | <Domenic_> | jgraham: not a bad mental model. I might be pacified. |
| 18:35 | <Domenic_> | Hixie: there are no concepts in the Win32 API that can't be implemented in C |
| 18:35 | <Domenic_> | that's the analogy |
| 18:35 | <Hixie> | Domenic_: sure there are. |
| 18:35 | <Domenic_> | Oh? |
| 18:35 | <Hixie> | Domenic_: a Win32 Window can't be created by a C program without using the Win32 API. |
| 18:35 | <Hixie> | jgraham: in pure JS, you can always just create a new object that is identical to an existing object, as far as i can tell. just copy all its members. |
| 18:35 | <Domenic_> | sure. but Window itself is implementable in C |
| 18:36 | <Hixie> | Domenic_: well sure. You could implement an entire browser in JavaScript, too. |
| 18:36 | <Domenic_> | Window isn't some weird thing that follows different rules than all other objects exposed to C code |
| 18:36 | <Domenic_> | s/exposed to/created by/ |
| 18:36 | <Hixie> | yes it is? |
| 18:36 | <Hixie> | i mean, not _all_ other objects |
| 18:36 | <Hixie> | there's tons of stuff vended by the Win32 API |
| 18:36 | <Hixie> | File handles, for example |
| 18:37 | <Domenic_> | sure. but they're structs, or pointers, or whatever |
| 18:37 | <Hixie> | so? |
| 18:37 | <Hixie> | you can't just make your own |
| 18:37 | <Hixie> | you have to use the one handed to you by the Win32 API, otherwise it won't work |
| 18:37 | <Domenic_> | not, e.g. pointers which can only be dereferenced once, or some similar strange thing that breaks language invariants |
| 18:38 | <Hixie> | just redefine your idea of what is a JS invariant to not include things that are done by the DOM API |
| 18:38 | <Hixie> | then your problem is solved |
| 18:38 | <Domenic_> | yes, that would certainly do the trick |
| 18:39 | <Hixie> | a better analogy would be a unix process |
| 18:39 | <Domenic_> | if I was programming in JS + magic C++ powers, I would have a different set of invariants. And I realize spec writers *are* programming in that language. |
| 18:39 | <Hixie> | there's no way that a C program can create a process, short of asking the unix kernel to do so |
| 18:39 | <Domenic_> | But the process will be represented by a normal C object that obeys C invariants |
| 18:39 | <Hixie> | no? at best it's represented as an integer. |
| 18:40 | <Hixie> | you can't actually get to the object itself. |
| 18:40 | <Hixie> | it's only visible to kernel code. |
| 18:40 | <Domenic_> | yes yes. an integer that obeys C invariants, is my point |
| 18:40 | <Domenic_> | the only thing visible to C is things that obey C invariants |
| 18:40 | <Domenic_> | that's exactly what I'm saying |
| 18:40 | <Hixie> | no, the integer you get back is a kernel process handle. |
| 18:40 | <Hixie> | no other integer is that. |
| 18:41 | <Domenic_> | whereas in the DOM there are many things available to JS that do not obey JS invariants |
| 18:41 | <Hixie> | C integers have invariants like "you can add 1 to it and it'll still be useful" |
| 18:41 | <Domenic_> | *language* invariants |
| 18:41 | <Hixie> | do that to a PID and you get nothing useful at all. |
| 18:41 | <Hixie> | what do you mean by "language"? |
| 18:41 | <Domenic_> | not human semantic "invariants" |
| 18:41 | <Domenic_> | I mean, in the C language spec |
| 18:41 | <Hixie> | so if we put the DOM spec inside the JS spec you'd suddenly be ok with it? |
| 18:42 | <Domenic_> | Yeah, I guess so. |
| 18:42 | <Hixie> | ok. then imagine there is one huge spec labeled "The Web" that contains all these specs. |
| 18:42 | <Hixie> | that's what i've been arguing we should do for years. |
| 18:42 | <Domenic_> | heh |
| 18:42 | <Hixie> | it's just that for practical purposes we're editing it in separate docs for now. |
| 18:42 | <Domenic_> | i think there's value in stratifying into e.g. language and libraries |
| 18:42 | <Domenic_> | and making sure libraries obey invariants of the language |
| 18:43 | <Hixie> | i think this requires defining "language" and that any such definition would be arbitrary |
| 18:43 | <Domenic_> | traditionally it's pretty clear how to define programming languages as separate from their runtimes or libraries. the success of JS in both node and browser environments seems like an obvious thing to bring up here. |
| 18:44 | <Hixie> | nah, the line is always very blurry. |
| 18:44 | <Hixie> | is CORE::* in Perl part of the language, or the library? |
| 18:45 | <Hixie> | is system.oas part of the Pascal language, or the library? |
| 18:45 | <Hixie> | system.pas even |
| 18:45 | <Hixie> | are RegExp and Date part of the JS language, or the library? |
| 18:46 | <Hixie> | is it bad that you can't create your own RegExp-like or String-like object with its own literals, in JS? |
| 18:46 | <Hixie> | or are they part of the language? |
| 18:46 | <Hixie> | why is a "realm" part of the language, but "Window" part of the library? |
| 18:47 | <Domenic_> | fair. i guess you can take an empirical "greatest common factor" approach. |
| 18:48 | <Hixie> | i'll agree to that, so long as you agree that the JS language used in Node and the JS language used in browsers are different JS languages. |
| 18:48 | <Hixie> | very similar, granted, but different nonetheless. |
| 18:49 | <Domenic_> | i don't see that; what's the argument? |
| 18:50 | <Hixie> | "this", in browsers, isn't the global object |
| 18:50 | <Hixie> | it's a WindowProxy object. |
| 18:50 | <Domenic_> | oh fuck :P |
| 18:50 | <Domenic_> | yeah you're right |
| 18:50 | <Domenic_> | also the JS in browsers has the ability to create falsy objects with properties |
| 18:51 | <Domenic_> | those are the two actual modifications to the language spec if i recall |
| 18:51 | <Hixie> | at which point, the "greatest common factor" of the browser version of JS includes most of the DOM, so... :-) |
| 18:51 | <Domenic_> | lol |
| 18:52 | <Domenic_> | i think i've been cornered by logic and must admit defeat |
| 18:52 | <Hixie> | À la fin de l'envoi, je touche. |
| 18:59 | <Hixie> | btw i think a greatest common factor approach works for multiple implementations, but i don't know how to apply it to, say, perl5. is everything that ships with the basic compiler part of the language? That's a hell of a lot of libraries. I think a better approach may be to look at what you have access to without any explicit imports, which would include Core::* but not e.g. IO::Socket. |
| 19:00 | <Hixie> | but if you do that, then on browsers the DOM still gets included as part of the core. |
| 19:00 | <Hixie> | that definition would exclude the STL from C++, though, which is intuitively nice. |
| 19:00 | <Hixie> | and it would include system.pas but exclude sysutils.pas in ObjectPascal, which also works neatly. |
| 19:02 | <Hixie> | in C++ it would mean you had thread-local variables as part of the language, but pthreads (needed to make use of them) as part of a library. |
| 19:02 | <Hixie> | it would mean that the kernel was not part of the language, too, which is interesting and in contrast to the JS/DOM pair. |
| 19:14 | <mrbkap> | dglazkov: ping? |
| 19:15 | <Ms2ger> | Speaking of which |
| 19:15 | <Ms2ger> | I haven't bothered dglazkov about tests today |
| 19:16 | <mrbkap> | Ms2ger: get in line! |
| 19:18 | <Ms2ger> | jsbell, ping! |
| 19:18 | <jsbell> | Ms2ger: ? |
| 19:19 | <Ms2ger> | jsbell, any reason the TextEncoder/Decoder tests aren't in web-platform-tests? |
| 19:20 | <jsbell> | just lack of time. (I think I got myself added to the right github groups but never did the work) |
| 19:20 | <dglazkov> | good almost noon, Whatwg! |
| 19:21 | <Ms2ger> | jsbell, you don't need any permissions to create a pull request :) |
| 19:21 | <dglazkov> | mrbkap: pong |
| 19:21 | <mrbkap> | dglazkov: hey, I was wondering if you'd seen https://www.w3.org/Bugs/Public/show_bug.cgi?id=24002 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=24003 |
| 19:23 | <dglazkov> | mrbkap: I had not. morrita is currently wearing the imports spec editor hat, though |
| 19:23 | <mrbkap> | dglazkov: oh, ok. |
| 19:23 | <dglazkov> | mrbkap: will comment, though |
| 19:25 | <mrbkap> | dglazkov: thanks. |
| 19:26 | <dglazkov> | Ms2ger: I will review moar things on critic too. Is critic-as-preferred-tool expressed/documented anywhere? Because I see peeps doing in-line github reviews, too. |
| 19:27 | <Ms2ger> | dglazkov, I find it a lot easier to follow a review on github, but if you don't want to use better tools, you're free to comment on github :) |
| 19:27 | <Ms2ger> | s/follow/follow *than*/ |
| 19:35 | <Hixie> | heycam: why do you have this restriction?: If [Exposed] appears on an overloaded operation, then it must appear on all overloads, with the same identifier list. |
| 19:35 | <Hixie> | heycam: consider e.g. APIs that in workers take a string or an integer, but in Windows take a string, an integer, or a DOM node. |
| 19:35 | <Ms2ger> | [heycam is in a meeting discussing https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682] |
| 19:36 | <Hixie> | ok that's probably a better use of this time, granted |
| 19:40 | <Domenic_> | Ms2ger: oh yay! |
| 20:25 | <heycam> | Hixie, so that would have complicated invoking the overload resolution stuff and the checking of valid IDL stuff (things being distinguishable) so I wanted to avoid it unless we really need it |
| 21:49 | <Hixie> | heycam: k |
| 21:49 | <Hixie> | heycam: i'll get back to you if i find a case |
| 21:49 | <heycam> | Hixie, cool; shouldn't be too hard to add, but more than I wanted to do at the time :) |
| 21:49 | <Hixie> | ok so here's one possible case |
| 21:50 | <Hixie> | from xhr: |
| 21:50 | <Hixie> | void send(optional (ArrayBufferView or Blob or Document or [EnsureUTF16] DOMString or FormData or URLSearchParams)? data = null); |
| 21:50 | <Hixie> | (man, that's quite the type description) |
| 21:50 | <heycam> | isn't it |
| 21:50 | <Hixie> | i presume that the Document part of this will be Window-only |
| 21:50 | <heycam> | yeah |
| 21:50 | <heycam> | I wonder if we could do it automatically |
| 21:50 | <heycam> | knowing that Document is window only |
| 21:51 | <heycam> | or if that would be too subtle |
| 21:51 | <Hixie> | well so that's an interesting point |
| 21:51 | <Hixie> | does it matter what the _arguments_ to a method are? |
| 21:51 | <Hixie> | you can't actually get a Document from that |
| 21:51 | <heycam> | true |
| 21:51 | <Hixie> | and since you can't get a Document at all, it doesn't much matter what the overloads are... |
| 21:51 | <heycam> | you'll never have a Document |
| 21:51 | <heycam> | it might well be ok to just leave that there |
| 21:51 | <Hixie> | yeah... |
| 21:52 | <heycam> | I didn't add any IDL author conformance criteria preventing it |
| 21:52 | <Hixie> | let me try to convert HTML to this and see what happens |
| 21:52 | <heycam> | ok |
| 21:53 | <Hixie> | [PrimaryGlobal] implies [Global=Window] ? |
| 21:53 | <heycam> | yep |
| 21:53 | <Hixie> | k |
| 21:53 | <heycam> | well, it implies [Global=TheInterfaceIt'sOn] |
| 21:53 | <Hixie> | oh ok |
| 21:53 | <Hixie> | cool |
| 21:53 | <heycam> | still trying to keep Window the name not special :) |
| 21:55 | <Hixie> | let me know if anyone ever puts [PrimaryGlobal] on anything else |
| 21:55 | <Hixie> | i'd love to see that! |
| 21:56 | <Hixie> | do i have to expose things like enums or callbacks? |
| 21:57 | <Hixie> | wow it's surprising how many interfaces html defines that are just on Window |
| 21:57 | <Hixie> | how about typedefs? |
| 21:57 | <jory> | "Not sure where to put it? Why not try Window?" |
| 21:58 | <Hixie> | well mostly all the element interfaces |
| 21:58 | <Hixie> | descendants of Node |
| 21:58 | <Hixie> | i wonder if i should expose all the Event types |
| 21:59 | <Hixie> | just on general principle |
| 22:08 | <annevk> | SimonSapin: 1024 ftw |
| 22:12 | <Hixie> | should ApplicationWorker be exposed to Window,Worker, or just Window,SharedWorker? it'd be useless in a dedicated worker... |
| 22:15 | <dglazkov> | what's an ApplicationWorker? |
| 22:16 | <Hixie> | uh |
| 22:16 | <Hixie> | ApplicationCache, my bad |
| 22:16 | <Hixie> | i have workers on the mind |
| 22:16 | <dglazkov> | darn it. I got excited :-\ |
| 22:16 | <dglazkov> | "it's a worker that fills out various applications for you" |
| 22:17 | <dglazkov> | new ApplicationWorker("mastercard"); |
| 22:17 | <Hixie> | heh |
| 22:17 | <dglazkov> | returns a Promise, of course. |
| 22:18 | <Hixie> | one that never gets fulfilled? :-) |
| 22:18 | <dglazkov> | it's a asymptotic promise |
| 22:18 | <Hixie> | heycam|away: is there any point doing [Exposed] on a [NoInterfaceObject] interface? |
| 22:19 | <Hixie> | heycam|away: or should the [Exposed] maybe instead be on the "implements" statement? |
| 22:30 | <Hixie> | heycam|away: or alternatively, there should be a rule that says that a Global to which an interface isn't exposed can't reference the interface, either via "implements" or via reference |
| 22:30 | <Hixie> | heycam|away: and then that should continue down the chain, so we can check we haven't forgotten to expose something |
| 22:58 | <Hixie> | heycam|away: i guess the ancestor of the global doesn't need to be told to be exposed, right? |
| 23:01 | <GPHemsley> | Sorry for slacking on the wiki username requests everyone (Hixie). |
| 23:01 | <Hixie> | heh, i'm slacking too man |
| 23:02 | <Hixie> | though, see thread on whatwg@ |
| 23:02 | <Hixie> | where i try to kill the main need :-) |
| 23:11 | <GPHemsley> | I generally approve that proposal |
| 23:17 | <Hixie> | GPHemsley: yeah, need to get mike and henri on board though |
| 23:18 | <GPHemsley> | mm |
| 23:26 | <Hixie> | man, there's a lot of "require"s in the HTML spec |
| 23:26 | <Hixie> | 268 "required" |
| 23:26 | <Hixie> | auditing that is gonna be a pain |
| 23:36 | <annevk> | Domenic_: is there a list of use cases for subclassing promises? |
| 23:38 | astearns | la5t call |
| 23:39 | <astearns> | bah, wrong window |