01:09 | <GPHemsley> | Filed DOM 3 Events spec bug for event order: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22641 |
02:20 | <jpwhiting_> | MikeSmith: yep, I'm hitting something different this time, I moved the sources to package it as a debian package, and when I try to build jing-trang's ant can't find apache-ant for some reason |
02:24 | <GPHemsley> | ...and closed as INVALID |
02:24 | GPHemsley | shrugs |
02:24 | <jpwhiting_> | http://pastebin.com/DV0Z3FLT |
02:25 | <jpwhiting_> | MikeSmith: the issues I was having earlier were because my spec was added to validator/presets.txt but not validator/w3c-presets.txt where it needed to be |
02:29 | <MikeSmith> | jpwhiting_: yeah that bit of complexity is my fault I guess |
02:30 | <MikeSmith> | jpwhiting_: so you're creating a Debian package of the validator? Are you planning to actually get it in the main Debian package repo? |
02:32 | <MikeSmith> | jpwhiting_: Maybe the reason you're seeing http://pastebin.com/DV0Z3FLT during the build is that it's ignoring your system CLASSPATH |
02:33 | <Yuhong> | MS just fixed document.createElement("th").cellIndex in older versions of IE to conform to the standard in the just released Cumulative Update. |
02:33 | <Yuhong> | Old behavior was an address leak. |
02:33 | <jpwhiting_> | MikeSmith: my System CLASSPATH? |
02:33 | jpwhiting_ | is new to java, sorry |
02:33 | <Yuhong> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=16757#c10 |
02:33 | <jpwhiting_> | I have JAVA_HOME set, but that's about it |
02:34 | <jpwhiting_> | no, not packaging for debian itself, just making a debian package out of validator.nu for a client |
02:34 | <jpwhiting_> | to use inside their ubuntu based virtualmachine |
02:34 | <MikeSmith> | ok |
02:34 | <jpwhiting_> | the weird thing is it works fine when I run it from one path |
02:35 | <MikeSmith> | jpwhiting_: so if you look at the jing-trang/ant script, you'll see it feeds -cp to java |
02:35 | <jpwhiting_> | but I tar up the original sources gotten with build/build.py checkout && build/build.py dldeps |
02:35 | <jpwhiting_> | then untar it when creating the package and do python build/build.py --local build to build it |
02:35 | <jpwhiting_> | ah, I see, /me dives deeper |
02:35 | <MikeSmith> | -cp jing-trang/lib/ant-launcher.jar |
02:36 | <jpwhiting_> | ok, I do have that file, maybe $JING_TRANG_HOME is getting mucked up somehow? |
02:36 | jpwhiting_ | reads build.py again |
02:37 | <MikeSmith> | I guess you could just hack the build script to call "ant" instead of "./ant" there |
02:37 | <MikeSmith> | line 558 of build.py |
02:38 | <jpwhiting_> | the difference being that ./ant sets classpath, where my system's ant doesn't? |
02:38 | <MikeSmith> | - runCmd(os.path.join(".", "ant")) |
02:38 | <MikeSmith> | + runCmd("ant") |
02:38 | <jpwhiting_> | yep, gotcha, /me tries |
02:39 | <MikeSmith> | jpwhiting_: I dunno what that jing-trang/ant script is attempting to do. It's upstream code that we pull into the validator build as a dependency. |
02:40 | <jpwhiting_> | still it's very weird to me that it works when untarred in one place on my disk, and fails when untarred in another place |
02:40 | <MikeSmith> | yeah that is weird |
02:40 | <jpwhiting_> | maybe build/build.py checkout sets some paths or something? |
02:40 | <MikeSmith> | I don't think it does |
02:40 | <MikeSmith> | though not sure |
02:41 | MikeSmith | checks |
02:41 | <jpwhiting_> | my system doesn't know what "ant" is |
02:41 | <MikeSmith> | hmm, OK |
02:42 | <jpwhiting_> | no ant in $JAVA_HOME/bin either |
02:42 | <jpwhiting_> | using openjdk-7-jdk |
02:42 | <jpwhiting_> | one other weird thing I found is that the one checkout of validator.nu that's working has manifest and such in jing-trang/ but the one that doesn't is missing them |
02:42 | <jpwhiting_> | does ant create those? |
02:43 | <MikeSmith> | no, ant doesn't create those |
02:43 | <MikeSmith> | and you won't find "ant" in $JAVA_HOME/bin normally |
02:44 | <MikeSmith> | so anyway, forget what I said about running "ant" instead |
02:44 | <jpwhiting_> | erm, sorry not manifest, I meant modbuild.xml, modules.xml and the build folder |
02:44 | <MikeSmith> | yeah, so those are needed |
02:44 | <MikeSmith> | and I think they do get created by ant |
02:45 | <Yuhong> | Actually, only IE9 is fixed in the July update. |
02:46 | <jpwhiting_> | MikeSmith: even if I set JING_TRANG_HOME to the path where jing-trang is checked out to, then run ,/ant I get the java.lang.ClassNotFoundException: org.apache.tools.ant.Main |
02:47 | <jpwhiting_> | maybe the ant jar is bad? |
02:47 | <Yuhong> | Hixie: w() in the DOM Viewer is broken in IE8. |
02:47 | <Hixie_> | i think you mean, IE8 is broken |
02:47 | <MikeSmith> | jpwhiting_: the ant-launcher.jar and ant.jar binaries are distributed as part of jing-trang, so those are what your java environment should be using for the jing-trang build |
02:47 | <jpwhiting_> | yeah, I see them in jing-trang/lib |
02:48 | <Yuhong> | I use this a lot for tests. |
02:48 | <MikeSmith> | if it's not finding them, then I'd guess it's because your build environment doesn't have $JING_TRANG_HOME set |
02:48 | <Yuhong> | For example, I was trying to use http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1673 to test the latest Cumulative Update to see if the behavior is fixed. |
02:49 | <jpwhiting_> | why would it have JING_TRANG_HOME set? |
02:49 | <jpwhiting_> | I mean, what sets that? |
02:49 | <jpwhiting_> | heh, jing-trang/ant sets it to dirname $0 |
02:50 | <MikeSmith> | jpwhiting_: yup |
02:50 | <Yuhong> | It is fixed for IE9 in the just released cumulative update, BTW. Old behavior is an address leak. |
02:50 | <zewt> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=22641 filing bugs on dom events seems like a waste of time, heh |
02:52 | <Yuhong> | Unfortunately, as I said before, I can't imagine mutation events going away any time soon, as IE9/10 do not support mutation observers. |
02:53 | <jpwhiting_> | MikeSmith: k, I'll figure this out, thanks for the pointers :) |
02:53 | <MikeSmith> | k |
03:00 | <jpwhiting_> | MikeSmith: hmm, does java not cope well with : in path names maybe? |
03:01 | jpwhiting_ | is using this from within an obs checkout, so part of the path is home:jwhiting:branches:blah blah |
03:03 | <jpwhiting_> | heh, seems so, that's working much better from a path without : in it |
03:03 | <jpwhiting_> | phew, problem solved |
04:00 | <MikeSmith> | jpwhiting: good to hear |
04:01 | <MikeSmith> | and ":" is the right path separator on Linux |
04:01 | <MikeSmith> | for java |
04:01 | <MikeSmith> | but on windows it needs to be ";" I think |
04:04 | <zewt> | things that need to die: code that uses a variable for platform path separators |
04:04 | <zewt> | (do people really not know that / is a valid path separator in windows) |
08:32 | <JakeA> | Do we have a way to get the base url of the page? As in, what relative paths will be resolved against? |
08:37 | <MikeSmith> | JakeA: not in the URL spec? |
08:38 | <JakeA> | Not that I can see, new urls have a default base of about:blank |
08:38 | <JakeA> | I remember Anne telling me why it didn't default to the base of the current page, but I can't remember |
08:38 | <JakeA> | …what it actually was |
09:05 | <galant> | animations for anniversaries on google homepage can't be viewed on mobile phones? Because they are done in canvas.. |
12:10 | <JakeA> | I just got a 50k bounce on the mailing list, is anyone able to clear it through? |
12:10 | <JakeA> | It's a reply to @getify so it's naturally over 50k |
12:12 | <Ms2ger> | You could trim? |
12:12 | <Ms2ger> | But I believe Hixie_ moderates |
12:14 | <JakeA> | Yeah, I've done a lot of that already, but I'm worried I'll get accused of editing & misrepresenting the original view |
12:14 | <JakeA> | most of the content is the original email with replies inline |
13:03 | <galant> | canvas hit regions are supported by older browsers? |
13:07 | <Ms2ger> | They're not supported anywhere |
13:09 | <galant> | yeah |
13:09 | <galant> | I have no idea how to make canvas drawings responsive to mouse events, if you know some link for reading on this please tell me thanks |
13:10 | <smaug____> | you just add mouse event listener and check the coordinates in the event listener? |
13:11 | <JakeA> | You can test the x/y position of the click, or absolutely position an a[href] over the hit areas. The latter may be more accessible. |
13:15 | <galant> | thanks for ideas |
13:15 | <galant> | so Google uses this? :D |
13:15 | <galant> | for their animations |
13:15 | <galant> | hehe |
13:15 | <galant> | Hixie do the Google homepage animations on anniversaries? :DDD |
13:15 | <galant> | hehe |
13:16 | <galant> | JakeA, that absolutely positioned <a> is best idea and easiest lol it can be done in seconds |
13:16 | <galant> | Im not sure about other ideas though never done that |
13:16 | <galant> | JakeA, how to test x/y position of the click just curious? |
13:17 | <JakeA> | When you add a click listener to the canvas you'll get one of these as an event object https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent |
13:18 | <galant> | on older browsers too>? |
13:18 | <JakeA> | clientX/Y is what you're looking for |
13:18 | <JakeA> | well… certainly everything that supports canvas |
13:19 | <galant> | event.clientX is the thing right? |
13:19 | <galant> | yeah this works on every element not just canvas :) nice |
13:21 | <galant> | guys |
13:22 | <galant> | if I create some kind of interface for some API as a side effect of working on my projects do you want me to give it to you you can them implement such things in the APIs you make if you decide too, so others can have use of my work too |
13:32 | <JakeA> | you should make your code available on github for people. If it turns out to be super-popular and could be done much faster natively, it might make it into the spec |
13:32 | <JakeA> | this happened with selector matching in jQuery etc |
13:32 | <JakeA> | became querySelectorAll in the spec |
13:36 | <galant> | ok JakeA thanks |
14:25 | <MikeSmith> | ...and Hallvord announces |
14:26 | <MikeSmith> | and post-mortems |
14:31 | <gsnedders> | MikeSmith: Opera lost him first. |
14:32 | <Ms2ger> | I did see him pop up in bugzilla a lot lately |
14:37 | <jgraham> | pointer? |
14:38 | <Ms2ger> | His blog |
14:38 | <gsnedders> | http://my.opera.com/hallvors/blog/goodbye |
14:56 | <jgraham> | Interesting post mortem. Things to agree with and things to disagree with. |
15:08 | <Ms2ger> | Someone should count how many former Operians we hired now |
15:08 | <Ms2ger> | / will hire |
15:10 | <gsnedders> | Ms2ger: Going how far back? :P |
15:11 | <Ms2ger> | Last year or so? |
15:13 | <gsnedders> | I can only think of four off-hand. |
16:07 | <Hixie_> | JakeA: you still need help with moderation? |
16:09 | <JakeA> | nah, I cut it down & went plain text |
16:09 | <JakeA> | cheers |
17:07 | <Ms2ger> | Github slow for anyone else? |
17:11 | <jgraham> | I'm not getting spammed so I assume it isn't down |
17:11 | <jgraham> | Website doesn't seem slower than normal |
17:13 | <jgraham> | Fetching worked OK |
17:13 | <jgraham> | So, no? |
17:26 | <esprehn> | annevk: is there a reason you removed document.body from DOM core? |
17:26 | <esprehn> | it's used by every application ever... seems weird |
17:27 | <esprehn> | also document.title which is used by tons of apps |
17:33 | <gsnedders> | esprehn: Removed? Were they ever added? They've always been in HTML 5. |
17:34 | <esprehn> | oh I see, DOM Core just defines a subset of the Document interface :/ |
17:34 | <esprehn> | yeah this is missing lots of stuff, that should have tipped me off :) |
17:49 | <esprehn> | Hixie_: steps 3 and 4 of the document.body setter algorithm are backwards |
17:55 | <Hixie_> | esprehn: file a bug |
17:55 | <Hixie_> | there's a tool on the page to do so :-) |
17:56 | <annevk> | esprehn: euhm wut |
17:56 | <esprehn> | annevk: nothing I was just confused |
17:56 | <annevk> | ah I see |
17:56 | <Hixie_> | esprehn: (but why do you think they're backwards?) |
17:57 | <annevk> | yeah, the separation is not exactly ideal, but I don't think we've completely figured out yet whether or not to merge all document objects so we'll see I guess |
17:57 | <Hixie_> | esprehn: (they're mutually exclusive) |
17:57 | <esprehn> | Hixie_: step 4 null checks the documentElement, step 3 calls replaceChild on it |
17:57 | <Hixie_> | esprehn: step 3 can't get to the replaceChild call unless documentElement has a child |
17:58 | <esprehn> | ah yeah |
17:58 | <esprehn> | still seems weird to do that step before looking for a missing documentElement |
17:59 | <Hixie_> | *shrug* |
17:59 | <esprehn> | yeah, I won't file a bug |
18:00 | <esprehn> | btw WebKit's behavior here is all kinds of fun. document.body returns the first <body> unless there's a <frameset> in which case we return that |
18:01 | <Hixie_> | that's per spec |
18:01 | <Hixie_> | more or less |
18:01 | <esprehn> | hmm? |
18:01 | <Hixie_> | spec says "the first child of the html element that is either a body element or a frameset element" |
18:02 | <esprehn> | the spec doesn't say <html><body><frameset></html> and document.body should return <frameset> right? |
18:02 | <esprehn> | the spec says pick the first one you see |
18:03 | <Hixie_> | yeah, it's not quite webkit's behaviour |
18:03 | <Hixie_> | hence the "more or less" |
18:03 | <esprehn> | webkit also throws HierarchyRequestError if you do document.body = <frameset> |
18:04 | <jgraham> | Sounds like you have some bugs to fix ;) |
18:06 | <esprehn> | yeah |
18:33 | <annevk> | Hixie_: so how stable is the canvas in worker stuff? |
18:33 | <annevk> | Hixie_: given http://wiki.whatwg.org/wiki/CanvasInWorkers it might be not very stable? |
18:38 | <Ms2ger> | annevk, nobody's implemented it, so, unstable :) |
18:38 | <annevk> | Ms2ger: so we're thinking about it but if there's major outstanding feedback... |
18:38 | <tantek> | Ms2ger - I like your reasoning :) |
18:38 | <annevk> | Ms2ger: but if there's no major outstanding feedback, it'd be more attractive |
18:39 | <Ms2ger> | That page was last edited 1 March |
18:41 | <annevk> | so yeah |
18:41 | <annevk> | unstable |
18:41 | <Ms2ger> | Anyway, make Hixie_ prioritize any feedback |
18:44 | <annevk> | Hixie_: http://cdn.meme.li/instances/400x/39616780.jpg |
18:45 | <tantek> | LOL |
18:46 | <zcorpan> | sup guys |
18:48 | <annevk> | sup zcorpan |
18:49 | <zcorpan> | having vacation :-) |
18:49 | <Ms2ger> | Did we hire zcorpan already? |
18:50 | <zcorpan> | is that a website? |
18:54 | <Ms2ger> | Arewemployingzcorpanyet.com |
18:55 | <annevk> | zcorpan: sounds good :) |
18:57 | <zcorpan> | 402 Payment Required |
18:58 | <Ms2ger> | I'm sure we can arrange something |
19:11 | zcorpan | leaves again |
19:30 | <annevk5> | Hixie_: so "exposed to JavaScript"... where is defined that Event is exposed to workers? |
19:30 | <annevk_> | Hixie_: or WebSocket? |
19:31 | <annevk_> | Hixie_: I think I'd prefer it if you changed the defaults |
19:31 | <annevk_> | Hixie_: say that everything is exposed to JavaScript regardless of global |
19:31 | <annevk_> | unless stated otherwise |
19:31 | <annevk_> | Hixie_: and then I'll have DOM and such say otherwise |
19:36 | <Hixie_> | annevk: looked around for feedback on canvas and workers, but didn't see any |
19:36 | <Hixie_> | annevk_: do you have a link to the e-mail or bug in question? |
19:36 | <Hixie_> | annevk_: we should say that events and websocket are exposed. |
19:37 | <Hixie_> | annevk_: in general, the default is not to expose, i think |
19:37 | <Hixie_> | annevk_: since most things involve the dom |
19:37 | <annevk_> | really? |
19:38 | <annevk_> | I think if you exclude Node and its descendants most things are non-DOM |
19:39 | <annevk_> | there's http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jan/thread.html#msg18 |
19:39 | <Hixie_> | i responded in that thread |
19:40 | <annevk_> | http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Mar/0160.html |
19:40 | <annevk_> | (minor) |
19:40 | <Hixie_> | yeah, that's the issue of workers not listing all the things yet |
19:41 | <annevk_> | I wonder why http://wiki.whatwg.org/wiki/CanvasInWorkers is not mentioned on the list |
19:41 | <annevk_> | Maybe because Gregg left Google? |
19:43 | <annevk_> | Hixie_: in my experience pretty much any new API we create we want in workers |
19:45 | <jsbell> | Has the "should APIs in Workers be sync or async?" debate recurred since Futures arrived? |
19:46 | <Hixie_> | apis in workers can be both |
19:46 | <annevk_> | smaug____: should we remove [NoInterfaceObject] from XMLHttpRequestEventTarget? |
19:47 | <annevk_> | jsbell: http://infrequently.org/2013/05/the-case-against-synchronous-worker-apis-2/ is there |
19:47 | <annevk_> | jsbell: when we discussed this at Mozilla, opinions were split |
19:47 | <annevk_> | jsbell: also, promises |
20:21 | <annevk_> | Hixie_: so Window, Node and descendants, bits of Navigator-related interfaces, anything else not going into Worker? |
20:22 | <annevk_> | Hmm, NodeList, HTMLCollection, DOMTokenList |
20:22 | <Ms2ger> | Everything that touches nodes? :) |
20:22 | <Hixie_> | there's a ton of them |
20:22 | <Hixie_> | "Node and descendants" alone is a list longer than my arm |
20:22 | <Ms2ger> | webperf? |
20:23 | <Hixie_> | we shouldn't enable things in workers without carefully thinking about it |
20:26 | <annevk_> | our current list is https://etherpad.mozilla.org/WorkerThreadAPIs |
20:30 | <jsbell> | annevk: damnit, I typed Promises then edited it to Futures. Get with the program, brain! |
20:30 | <annevk_> | Hixie_: I think I'll just go and list for each interface if they're exposed in both environments |
20:32 | <annevk_> | Hixie_: although for that having "Exposed to document and worker environments" and such as shorthands would be useful |
20:32 | annevk_ | files a bug with that idea |
20:34 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=22646 |
20:54 | <Hixie_> | you want a shorthand for a five-word phrase that says two things? :-) |
20:55 | <annevk> | Hixie_: basically below each IDL block I'd be able to say x, y, or z |
20:56 | <annevk> | Hixie_: makes it somewhat clearer what the worker situation is for everyone and doesn't involve 3 cross-references |
20:58 | <Hixie_> | i don't understand |
20:58 | <Hixie_> | what do you think you have to say today? |
20:59 | <annevk> | So I define [Constructor] interface Foo {}; |
20:59 | <annevk> | I expect I have to say somewhere it works in both workers and documents |
20:59 | <annevk> | or just in documents |
21:00 | <annevk> | I'm also running into minor issues with e.g. XMLHttpRequest |
21:00 | <Hixie_> | oh you want to change "The SharedWorkerGlobalScope interface must only be exposed to JavaScript if the JavaScript global environment is a shared worker environment." to something shorter? |
21:00 | <Ms2ger> | Anyone got interesting things to test for document.images? |
21:00 | <annevk> | Hixie_: yes |
21:00 | <Hixie_> | we could just have [Exposed=Worker], [Exposed=Window] (default), [Exposed=Window,Worker] |
21:01 | <annevk> | (The issue I'm running into is how to deal with Document appearing in the IDL, and HTMLFormElement appearing in FormData's IDL.) |
21:01 | <Hixie_> | heycam: ^ |
21:01 | <Hixie_> | annevk: how do browsers deal with it? |
21:01 | <annevk> | Hixie_: they just deal |
21:01 | <annevk> | "prose" |
21:01 | <annevk> | (which I've added for now) |
21:02 | heycam | acks, will think when I'm off the phone |
21:02 | <Ms2ger> | Yeah, the hard part is when only part of an interface is exposed to workers |
21:03 | <annevk> | could maybe make [Exposed] work everywhere somehow? |
21:03 | <annevk> | send(([Exposed=Window] Document or DOMString) data) |
21:04 | <Ms2ger> | [[Exposed=Window]Constructor...? |
21:04 | <annevk> | readonly attribute ([Exposed=Window] Document or null) responseXML |
21:04 | <Hixie_> | or just have two different IDLs |
21:04 | <annevk> | Ms2ger: yeah something like that |
21:04 | <annevk> | Hixie_: like you do for navigator? |
21:05 | <annevk> | seems kinda overkill for most of XHR, although I guess we could make that work in some way |
21:05 | <Ms2ger> | Navigator actually is called WindowNavigator in workers |
21:07 | <annevk> | I know |
21:17 | <Hixie_> | annevk: yeah |
21:19 | <annevk> | Hixie_: I guess if we have [Exposed] we could name it the same even |
21:20 | <annevk> | but still, kinda bloaty |
21:22 | <Hixie_> | Ms2ger: i assume you mean WorkerNavigator |
21:22 | <Hixie_> | we could use the same name, just need some prose to say which one you mean |
21:22 | <Ms2ger> | Er, yes |
21:22 | <Ms2ger> | I can't speel |
21:40 | <heycam> | how many things do we have in the middle of an interface that we want to turn off in workers? |
21:42 | <annevk> | heycam: FormData, XMLHttpRequest, cannot really think of something else |
21:42 | <heycam> | but, members of an interface? or are these interface members which mention those types? |
21:43 | <annevk> | It might be good to not expose responseXML in Workers |
21:43 | heycam | wonders how bloating it would be to put [Exposed=…] on those interface members, if there are only a couple of them |
21:43 | <annevk> | I think responseType = "document" we deal with in prose |
21:43 | <annevk> | heycam: ah yeah, we could just duplicate definitions I suppose |
21:43 | <heycam> | ah, so the issue I guess is that we mention Document in the return type? |
21:44 | <annevk> | one send() for Window and one for Worker |
21:44 | <heycam> | I guess it's not technically a problem |
21:44 | <annevk> | heycam: that's the issue |
21:44 | <heycam> | as long as prose never returns a Document object |
21:44 | <annevk> | heycam: I'd prefer not to expose responseXML at all, but e.g. for FormData I'd want a constructor in workers that doesn't take an argument |
21:45 | <heycam> | I see |
21:45 | <annevk> | heycam: we could maybe have some wording around interfaces not existing in workers? |
21:45 | <annevk> | heycam: e.g. Document doesn't exist, therefore (Document or DOMString) ends up meaning DOMString |
21:45 | <annevk> | and Document? ends up meaning null |
21:46 | <heycam> | maybe |
21:46 | <annevk> | and optional HTMLFormElement x means no argument? |
21:46 | <annevk> | dunno |
21:46 | <heycam> | would it result in members disappearing altogether? |
21:46 | <heycam> | might be a bit nonobvious |
21:46 | <annevk> | seems somewhat more complicated |
21:46 | <heycam> | looking at the idl |
21:47 | <annevk> | saying Constructor is X in Window and Y in Worker seems easier |
21:47 | <heycam> | yeah |
21:47 | <annevk> | and responseXML is only in Window, and send() is X in Window and Y in Worker |
21:47 | <heycam> | in prose you mean? |
21:47 | <annevk> | no with the flag |
21:47 | <heycam> | ah |
21:47 | <annevk> | well or prose |
21:47 | <heycam> | [[Exposed=…][Constructor(…)] looks funny to me :) |
21:48 | <annevk> | needs moar ] |
21:48 | <annevk> | or less [ I guess |
21:49 | heycam | hopes to avoid mentioning "workers" in Web IDL itself |
21:50 | <heycam> | ok, time for coffee |
21:58 | <annevk> | I hope Kyle doesn't expect anyone to actually read those emails o_O |
22:18 | <annevk> | heycam|away: So the way you can do it is by having the [Global] annotation and then other specs can say [Expose=GlobalName] |
22:19 | <annevk> | heycam|away: plus maybe some shortcut so they two Worker globals can also have a shared Global name |
22:19 | <annevk> | heycam|away: that way you'd avoid mentioning specific globals yet we could still have per-global IDL |