| 01:41 | <Hixie> | well crap |
| 01:41 | <Hixie> | html5 doesn't have anything that's comma-separated |
| 01:41 | <Hixie> | so making accept= comma separated is way more work than it should be |
| 02:29 | <Dashiva> | Hixie: But once you have comma support there's room for input @type=email-list :D |
| 02:30 | <Hixie> | -_- |
| 02:31 | <Dashiva> | awh, don't give me that face |
| 02:43 | <Hixie> | wow |
| 02:44 | <Hixie> | rfc2045 doesn't actually define anything that matches type "/" subtype |
| 03:45 | <MikeSmith> | wakaba: you there? |
| 03:46 | <MikeSmith> | wanted to ask about you conformance-checker implementation |
| 04:16 | <MikeSmith> | http://blog.mozilla.com/blassey/2008/09/23/camera-input-tag/ |
| 04:58 | <MikeSmith> | Hixie: you there? |
| 04:58 | <Hixie> | yo |
| 04:59 | <MikeSmith> | hey man. Wanted to ask if I might be able to steal your demos from your presentation earlier this week |
| 05:02 | <Hixie> | yeah, totally |
| 05:02 | <Hixie> | you asked earlier and i said yes already in fact :-) |
| 05:03 | <MikeSmith> | Hixie: sorry, I guess I missed your Yes. I got a crap network connection here |
| 05:03 | <MikeSmith> | Hixie: you got a URL? |
| 05:05 | <Hixie> | whatwg.org/demos/ |
| 05:05 | <Hixie> | link near the bottom |
| 05:06 | <MikeSmith> | OK |
| 05:06 | <MikeSmith> | thanks |
| 07:55 | <Hixie> | aw, still no tag minutes |
| 09:20 | <hsivonen> | no XHTML2 minutes, either |
| 09:43 | <zcorpan_> | i just marked all new (since yesterday) emails on public-html as read |
| 09:43 | <zcorpan_> | hope i didn't miss something interesting |
| 09:44 | <hsivonen> | I just learned that I'm not getting email due to an electricity outage |
| 10:14 | <glazou> | hell |
| 10:14 | <glazou> | o |
| 10:15 | <glazou> | I have a question related to html5 drag and drop, section 6.8.4.2 |
| 10:17 | <glazou> | how can the drag source know the draganddrop succeeded but on the desktop ? |
| 10:18 | <glazou> | I want my script, from onDrop on the source, to perform a special operation in that case |
| 10:31 | <annevk2> | funny, 3 out of 5 WHATWG demos are obsolete per latest thinking |
| 10:34 | <glazou> | hi annevk2 |
| 10:34 | <hsivonen> | glazou: bonjour. nice to see you here |
| 10:34 | <glazou> | hi henri |
| 10:34 | <glazou> | I'm playing with html5 d&d and find a few issues in a multi-app environmet |
| 10:35 | <glazou> | environment even |
| 10:35 | <glazou> | I think i'll send it to the mailing-list |
| 10:37 | <annevk2> | bonjour, dunno much about d&d |
| 10:37 | <hsivonen> | d&d isn't my area, either |
| 10:37 | <annevk2> | there is this demo though: http://www.whatwg.org/demos/2008-sept/dnd/dnd.html |
| 10:38 | <glazou> | looking |
| 10:40 | <glazou> | yeah does not help me |
| 10:40 | glazou | writes an email to the list |
| 11:01 | <glazou> | sent |
| 11:01 | <glazou> | hey tantek was here and I did not see hm :-( |
| 11:01 | <annevk2> | he's mostly lurking |
| 11:07 | <Hixie> | oh hey, i should have checked irc before my e-mail |
| 11:08 | <Hixie> | glazou: just replied to your message |
| 11:08 | <glazou> | thanks Hixie |
| 11:09 | <glazou> | Hixie, you can't use mouse events... |
| 11:09 | <glazou> | you're outside of the window ! |
| 11:09 | <glazou> | you don't even get the evens |
| 11:09 | <glazou> | events |
| 11:09 | <Hixie> | right, hence the capture API |
| 11:09 | <glazou> | exactly but it's not here yet |
| 11:09 | <Hixie> | (the idea is the (new) method would make it so all mouse events until the button is released would go to the element you pick, instead of the real target) |
| 11:09 | <Hixie> | correct, there's no real solution for this today |
| 11:10 | <Hixie> | even with that API, you still couldn't position or scale the window, so you couldn't do, e.g., what chrome or safari do with dragging of tabs |
| 11:10 | <glazou> | sigh |
| 11:10 | <glazou> | yep |
| 11:10 | glazou | is missing this right now in FF |
| 11:10 | <Hixie> | that's probably more something for css animation and css transform though |
| 11:11 | <Hixie> | at least the scaling and animation aspects |
| 11:11 | <glazou> | I guess the "detach sidebar item" menuitem is all I can do for the time being :-( |
| 11:11 | <Hixie> | the window positioning, i don't know |
| 11:11 | <Hixie> | part of the problem is that we're somewhat moving away from letting web authors control windows |
| 11:11 | <Hixie> | e.g. i see what chrome does with window.open() to be the way forward for window.open() |
| 11:11 | <Hixie> | which is in-tab |
| 11:12 | <Hixie> | i'd expect things like docking, snapping, and dragging of ui elements to be a ua-level feature rather than webapp-level |
| 11:13 | <glazou> | Hixie: never heard of Prism or Adobe Air ? web-apps are ua-level these days... |
| 11:13 | <Hixie> | even with prism (or apps generated by <bb type=makeapp> in html5) the apps are still webapps, so they're still sandboxed |
| 11:14 | <Hixie> | adobe air apps are privileged, so they're not subject to the limitations (and they're as dangerous as native apps) |
| 11:27 | <othermaciej> | I don't think we'd want to give Safari standalone web apps any special privs |
| 11:40 | <Hixie> | it's quite amusing how much of wf2 is written defensively. it's almost like a manifesto in places rather than a spec. |
| 11:41 | <othermaciej> | yet another way in which it is too reactive against XForms |
| 11:41 | <Hixie> | yeah |
| 12:12 | <annevk2> | Karl is leaving the W3C: http://twitter.com/karlw3c/statuses/932668509 |
| 12:12 | <glazou> | yep |
| 12:12 | <glazou> | Hixie: you've seen <input type="camera"> ? |
| 12:13 | <annevk2> | he's changing it in <input type=file accept=image/png>, no? |
| 12:13 | <annevk2> | or some such |
| 12:13 | <Hixie> | glazou: i haven't; uri? |
| 12:13 | <annevk2> | mikesmith posted it earlier |
| 12:13 | <glazou> | http://blog.mozilla.com/blassey/2008/09/23/camera-input-tag/ |
| 12:14 | <glazou> | very ineresting |
| 12:14 | <glazou> | see also my blog for my comments |
| 12:14 | <glazou> | annevk2: hmm seems a bad change to me |
| 12:15 | <Hixie> | ah, yeah |
| 12:15 | <annevk2> | wasn't sure about it either |
| 12:15 | <Hixie> | this is an area that needs some serious infrastructure work |
| 12:15 | <hsivonen> | glazou: so if I don't have a webcam, how do I connect a jpg file to type=camera? |
| 12:15 | <Hixie> | because what we really need is a way to get stream objects |
| 12:15 | <Hixie> | so we can send video streams |
| 12:15 | <Hixie> | forms aren't really suitable for that |
| 12:16 | <hsivonen> | (actually, all my Internet devices have a camera, but I run my MacBook with lid closed and Cinema Displays don't have cameras for some reason) |
| 12:16 | <Hixie> | probably an area for WebSocket, too |
| 12:16 | <Hixie> | and the blob apis, whenever we get around to those |
| 12:17 | <hsivonen> | given the security considerations, <input type=file> makes sense |
| 12:17 | <hsivonen> | if the text field is zapped |
| 12:17 | <hsivonen> | and there's UI for both browsing the file system and activating a camera |
| 12:19 | <Hixie> | woah, runaway error on the validator |
| 12:19 | Hixie | gets thousands of errors |
| 12:20 | <glazou> | hsivonen: if you don't have a webcam the input element shows "no webcam" |
| 12:21 | <glazou> | " UI for both browsing the file system and activating a camera" is faaaaar beyond an average user's knowledge |
| 12:21 | <Hixie> | hsivonen, aha, originally the error here was <span title="foo</span> instead of <span title="foo">foo</span> |
| 12:22 | <hsivonen> | glazou: how is it beyond user's knowledge to have something like: |
| 12:22 | <hsivonen> | Upload photo: [Use Camera] [Choose file] |
| 12:22 | <hsivonen> | ? |
| 12:22 | <glazou> | that should be author's decision |
| 12:23 | <hsivonen> | [Use Camera] [Choose file] is browser-managed |
| 12:23 | <glazou> | if the web page is made for cameras only for instance |
| 12:23 | <hsivonen> | glazou: why author decisions instead of user decision? |
| 12:23 | <glazou> | author's decision overridable by user |
| 12:24 | <glazou> | hsivonen: when a web site gives you a wysiwyg editable area, do you need to override author's decision to show a textarea for source code ? |
| 12:24 | <Hixie> | so did karl decide to move on like dino? |
| 12:25 | <glazou> | Hixie: I started pondering about it long ago |
| 12:25 | <glazou> | and w3c has a few financial issues these days |
| 12:25 | <glazou> | seemed the right time to move on I guess |
| 12:26 | <othermaciej> | I think we'd probably let <input type="file" accept="image"> have a camera option |
| 12:26 | <glazou> | d'oh firefox does not set screenX/screenY on ondragend |
| 12:26 | <othermaciej> | but that might not be as nice as an in-page preview |
| 12:26 | <hsivonen> | glazou: camera is more hardware and user situation dependent |
| 12:26 | <glazou> | othermaciej, hsivonen: my only goal here is the following one : get rid of the dozens of flash-based widgets that do only webcam capture |
| 12:27 | <glazou> | and "please attach a portrait" with file upload |
| 12:27 | <hsivonen> | glazou: shouldn't the camera input degrade to file upload in old UAs, though? |
| 12:28 | <glazou> | yep |
| 12:28 | <glazou> | hsivonen: but that's a camera or input ; you suggested above camera and input |
| 12:28 | <hsivonen> | that argues for type=file plus something in another attribute |
| 12:28 | <othermaciej> | glazou: I like replacing things that Flash does |
| 12:28 | <glazou> | not necessarily |
| 12:28 | <glazou> | othermaciej: eheh :) |
| 12:28 | <othermaciej> | is it important for picture taking UI to be direct in the browser window? |
| 12:28 | <othermaciej> | the preview at least? |
| 12:28 | <glazou> | yes |
| 12:28 | <glazou> | it's a webapp |
| 12:28 | <glazou> | standalone |
| 12:29 | <othermaciej> | the dialog on <input type="file"> is an important security feature in a way |
| 12:29 | <othermaciej> | since it prevents Web Apps from tricking you into uploading a file |
| 12:29 | <hsivonen> | glazou: why can't the browser put up a preview dialog/sheet? |
| 12:29 | <glazou> | well the browser should always ask "do you want to let this web page use your webcam ?" |
| 12:29 | <othermaciej> | a preview where you click a separate button to upload with no dialog could have security issues |
| 12:29 | <glazou> | hsivonen: because dialogs are bad |
| 12:29 | <hsivonen> | glazou: that seems like the wrong way. rather, I'd want the capture to be user action initiated |
| 12:29 | <othermaciej> | security alerts are bad, especially when divorced from the task |
| 12:30 | <hsivonen> | like the Browse button on file upload today |
| 12:30 | <glazou> | hsivonen: I can live with that too |
| 12:30 | glazou | has a meeting at the French Senate and must run |
| 12:30 | <glazou> | bye people |
| 12:30 | <hsivonen> | bye |
| 12:34 | <Hixie> | i should go too |
| 12:35 | <Hixie> | i have a meeting with my bed. |
| 12:35 | <Hixie> | nn |
| 12:35 | <hsivonen> | nn |
| 13:07 | <annevk2> | you could have an overlay the moment you hit "use webcam" |
| 13:07 | <annevk2> | just like you get an overlay for <input type=date> |
| 13:29 | <zcorpan_> | i wonder if i need something more generic for HIERARCHY_REQUEST_ERR checking |
| 13:30 | <zcorpan_> | than listing all conditions for all methods when it should throw |
| 13:31 | <zcorpan_> | maybe i should say "this is a legal tree" and "if running this algorithm would result an illegal tree, raise exception" |
| 13:33 | <annevk2> | how do you get a node from a cross origin document? |
| 13:33 | <annevk2> | re: adoptNode |
| 13:39 | Philip` | sees that Gandi's hosting will cost double what the beta did, and wonders if that affects hsivonen's preferences much |
| 13:40 | <annevk2> | something made Ubuntu crash... |
| 13:42 | <hsivonen> | Philip`: the new price makes it less attractive to keep both the Kotisivut.com VM and the Gandi VM |
| 13:49 | <hsivonen> | Philip`: having only a Gandi VM is a bit iffy considering that I'd have no practical recourse if Gandi opted to delete my VM (dealing with a local company is safer in that sense) |
| 13:49 | <hsivonen> | Philip`: having only the Kotisivut.com VM isn't that great, either, because it can't flex |
| 14:33 | <zcorpan_> | annevk2: you set document.domain |
| 14:43 | <annevk2> | zcorpan_, why should importNode not work when both sites have set document.domain? |
| 14:46 | <zcorpan_> | annevk2: it should |
| 14:53 | <annevk2> | zcorpan_, then it's still not clear to me when you can exchange nodes cross origin (because document.domain doesn't matter) |
| 14:56 | <zcorpan_> | annevk2: you can exchange nodes when both nodes's ownerDocument have the same effective script origin |
| 14:58 | <zcorpan_> | annevk2: setting document.domain affects the effective script origin |
| 14:58 | <annevk2> | "Providing search engines with dynamic URLs should be favored over hiding parameters to make them look static." from http://googlewebmastercentral.blogspot.com/2008/09/dynamic-urls-vs-static-urls.html wtf |
| 14:58 | <annevk2> | zcorpan_, in what scenario would the SECURITY_ERR be raised? |
| 15:04 | <zcorpan_> | annevk2: hmm i see what you mean... it's not possible to get a reference to a node that you can't adopt |
| 15:04 | <zcorpan_> | or is it? |
| 15:07 | <annevk2> | I don't think it is |
| 15:08 | <zcorpan_> | sweet then i can just remove the check |
| 15:08 | <annevk2> | though now I wonder what the origin of responseXML is |
| 15:27 | <Philip`> | annevk2: That blog post seems to be kind of confusing at getting the intended point across |
| 15:29 | <Philip`> | where the point seems to be that answer.foo?language=en&answer=3&sid=98971298178906&query=URL is better than answer.foo/en/3/98971298178906/URL because it's easier for a computer to work out what part of the URL is a parameter and hence might not significantly affect the document retrieved from that URL |
| 15:30 | <Philip`> | but it sounds quite easily misinterpretable as e.g. saying answer.foo?answer=3&... is better than answer.foo/3?..., which (I think) it doesn't mean |
| 15:42 | <annevk2> | yeah |
| 15:42 | <annevk2> | my weblogis indexed fine |
| 15:43 | <annevk2> | and they better keep it that way |
| 16:29 | myakura | finds client-side storage implementation for IE6/IE7 (using DHTML behavior): http://translate.google.com/translate?u=http%3A%2F%2Fd.hatena.ne.jp%2FZIGOROu%2F20080924%2F1222221363&hl=ja&ie=UTF-8&sl=ja&tl=en |
| 16:32 | <hsivonen> | myakura: cool. have you tested it? |
| 16:33 | <myakura> | hsivonen: no. just started reading the code. |
| 16:34 | <myakura> | there's a test case though http://svn.coderepos.org/share/lang/javascript/exdomstorage/trunk/sample/index.html |
| 16:40 | <hsivonen> | only the localStorage part of the demo works for me |
| 16:40 | <hsivonen> | anyway, I think this should be on the wiki |
| 16:44 | <Philip`> | Looks like it's just implemented with cookies |
| 17:57 | <hsivonen> | annevk2: Stack Overflow also has: http://stackoverflow.com/questions/42169/if-you-were-programming-a-calendar-in-html-would-you-use-table-tags-or-div-tags |
| 18:18 | <sicking> | Hixie, shouldn't you use .data rather than .message in the workers spec? |
| 18:18 | <sicking> | Hixie, event.data vs. event.message that is |
| 18:22 | <annevk2> | seems the mistake is only in the examples |
| 18:22 | <sicking> | annevk2, yeah |
| 18:41 | <aboodman> | sicking: yt? |
| 18:41 | <sicking> | yo, talking workers with Ben :) |
| 18:43 | <aboodman> | i think the key point you're missing is that it should be easy to create 'conversations' |
| 18:43 | <aboodman> | in fact, i would argue that should really be the only way to communicate with a worker |
| 18:43 | <aboodman> | this is real feedback we have gotten on gears workers |
| 18:44 | <aboodman> | once you accept that, it pretty much leads to my proposed design |
| 18:44 | <sicking> | aboodman, it's just as easy now as with your proposal, no? The difference is just in the name 'startConversaion' vs 'connect' |
| 18:45 | <aboodman> | sicking: one sec, loading spec |
| 18:45 | Philip` | thinks 'connect' looks much easier to spell :-) |
| 18:46 | <sicking> | aboodman, though there is a different way, as well, to communicate with dedicated workers, yes |
| 18:46 | <aboodman> | what is supposed to happen in the current spec when someone calls 'startconversation' on a dedicated worker |
| 18:46 | <aboodman> | does a 'connect' event fire inside the worker? |
| 18:46 | <sicking> | yeah |
| 18:47 | <aboodman> | k, there is a bug in the spec then |
| 18:47 | <sicking> | (btw, i'm fine with renaming 'startConversaion' to 'connect' if that makes a difference) |
| 18:47 | <sicking> | oh? |
| 18:47 | <aboodman> | onconnect is only on SharedWorkerGlobalScope from what I can see |
| 18:47 | <aboodman> | yes, we should make that change, startConveration() -> connect() |
| 18:48 | <sicking> | oh |
| 18:48 | <sicking> | wait |
| 18:48 | <sicking> | you're right |
| 18:48 | <sicking> | when startConversaion is called onmessage is called |
| 18:48 | <sicking> | not onconnect |
| 18:48 | <aboodman> | oh, because startConversation takes a message |
| 18:48 | <aboodman> | and where does the port show up? |
| 18:49 | <sicking> | and you get an event with a string and a port |
| 18:49 | <sicking> | right |
| 18:49 | <aboodman> | so we basically have *three* different mechanisms at work |
| 18:49 | <aboodman> | a) you can use workers the old school way, like gears is today, with one channel shared between all clients |
| 18:49 | <sicking> | two in shared and two in dedicated, with one existing in both |
| 18:49 | <sicking> | yeah |
| 18:50 | <aboodman> | b) you can call startConversation(), which fires a message event, and the worker code has to know to fish the port out of the event, instead of using the global port object |
| 18:50 | <aboodman> | c) you can create an instance of a shared worker, which will fire onconnect |
| 18:50 | <aboodman> | which has a port you can use to respond |
| 18:50 | <aboodman> | i think it would be very nice to combine all these into one mechanism |
| 18:50 | <sicking> | 'a' only exists for dedicated, and 'c' only for shared |
| 18:51 | <sicking> | i agree it seems excessive |
| 18:51 | <aboodman> | right, but there are still three things to understand |
| 18:51 | <sicking> | yup |
| 18:51 | sicking | ponders |
| 18:51 | <aboodman> | in my proposal usage is always the same |
| 18:51 | <aboodman> | connect() gets you a port |
| 18:51 | <aboodman> | call sendMessage() on port |
| 18:51 | <aboodman> | on the inside, you get onconnect |
| 18:51 | <aboodman> | reply on the port you got from onconnect |
| 18:51 | <sicking> | it does make it painful for the most simple case though |
| 18:52 | <aboodman> | i don't agree :) |
| 18:52 | <aboodman> | it makes it one line more painful |
| 18:52 | <aboodman> | a small price i think |
| 18:52 | <sicking> | everybody will end up with code like onconnect = function(e) { myPort = e.port; myPort.onmessage = myHandler } |
| 18:53 | <sicking> | everyone will have to write that snippet of code |
| 18:53 | <aboodman> | i would really prefer that we have a global onconnect, which would help that case |
| 18:53 | <sicking> | that is with a global onconnect |
| 18:53 | <aboodman> | sorry, |
| 18:53 | <aboodman> | global onmessage |
| 18:53 | <sicking> | that gets very messy with passable ports |
| 18:53 | <aboodman> | how so? |
| 18:54 | <sicking> | all of a sudden your global onmessage starts receiving more messages since someone passed in a port |
| 18:55 | <sicking> | and will your global onmessage still receive messages from ports that have been passed elsewhere? |
| 18:55 | <aboodman> | that would presumably only happen if the passed port is live |
| 18:55 | <aboodman> | but that's a good point with the idea of having a global onmessage |
| 18:55 | <aboodman> | that is a problem |
| 18:55 | <aboodman> | ok, i'm fine not having a global onmessage. the inside code becomes: |
| 18:55 | <sicking> | i think we can narrow it down to two communication methods maybe |
| 18:55 | <sicking> | the simple one for dedicated workers |
| 18:55 | <aboodman> | onconnect = function(e) { e.onmessage = function() { ... } } |
| 18:56 | <aboodman> | which is not that different from what people do with onload today |
| 18:56 | <sicking> | how so? today you just do onload = function () { ... } |
| 18:56 | <aboodman> | onload = function() { myButton.onclick = function() { ... } } |
| 18:56 | <sicking> | also you need to store e.port so you can post stuff out |
| 18:56 | <aboodman> | no you dont |
| 18:57 | <aboodman> | you get the port in the messages |
| 18:57 | <aboodman> | (i thought) |
| 18:57 | <sicking> | you do? |
| 18:57 | <sicking> | maybe as the source |
| 18:57 | <aboodman> | yeah, as the source |
| 18:57 | <sicking> | though that only works if you're inside a message handler |
| 18:57 | <sicking> | it doesn't work if you are just producing data |
| 18:58 | <sicking> | such as polling data from the network and sending out stuff to the window |
| 18:58 | <aboodman> | that is a lesser use case |
| 18:58 | <aboodman> | we only need to support it, not make it beautiful |
| 18:58 | <aboodman> | imo |
| 18:58 | <sicking> | isn't that what you guys needed for gmail? |
| 18:58 | <aboodman> | gmail? gears? what? |
| 18:58 | <aboodman> | :) |
| 18:58 | <aboodman> | no, we don't do that |
| 18:58 | <aboodman> | it was a hypothetical use case |
| 18:59 | <aboodman> | anyway you still don't need to store the port for that use case if you use closures, which is pretty common |
| 18:59 | <aboodman> | but i admit: there is more leg work here. |
| 19:00 | <aboodman> | on both sides. |
| 19:00 | <aboodman> | it's a tradeoff for having the api be consistent across all use cases. |
| 19:01 | <sicking> | so i think we should reduce to 2 communication methods. A simple one for the most common (imho) and simple case, dedicated worker with a single communication channel. And one complicated one for shared workers and/or multiple conversaions |
| 19:02 | <aboodman> | multiple conversations will be very common |
| 19:02 | <sicking> | i really think anything beyond just a single dedicated worker that you put off some heavy work onto is going to be much more rare |
| 19:02 | <aboodman> | the most common case that I'm aware of is synchronization |
| 19:02 | <aboodman> | of a local db with the network |
| 19:03 | <aboodman> | in that case, the common implementation will be: a single shared worker |
| 19:03 | <aboodman> | each UI action will create a conversation |
| 19:03 | <aboodman> | and wait for it's reply |
| 19:03 | <sicking> | i think it'll be more stuff like crypto or parsing or stuff like that |
| 19:03 | <aboodman> | the shared worker is filling the role of a server. so you need transaction ids. |
| 19:04 | <sicking> | for a shared worker i agree that having multiple conversaions is going to be the common case |
| 19:04 | <aboodman> | not just for a shared worker though. |
| 19:04 | <sicking> | which is why we should make that the only way to communicate to a shared worker |
| 19:04 | <sicking> | for a dedicated i think just a single conversation is going to be much more common |
| 19:04 | <aboodman> | if you have a worker providing services for a UI, and the user can initiate multiple actions in parallel, thenyou need conversations. |
| 19:06 | <aboodman> | say you have a UI that has three buttons, and each button sets off a lengthy operation that you perform in a worker. |
| 19:06 | <aboodman> | without conversations, you need to keep track of which reply went with which button manually. |
| 19:06 | <aboodman> | blech. |
| 19:07 | <sicking> | i agree that we should have conversaions for sure |
| 19:08 | <sicking> | but i don't think we should force that onto the usecase of a single dedicated worker wanting to perform some heavy work such as crypto on a worker |
| 19:08 | <aboodman> | in that case, it's just one extra line |
| 19:08 | <aboodman> | or 10 extra characters if you chain the method call :) |
| 19:08 | <sicking> | the difference is that i think it'll be the common case |
| 19:08 | <sicking> | so i prefer to optimize for making that simple |
| 19:09 | <aboodman> | s/10/8/g (i can't spell) |
| 19:10 | <aboodman> | ok, but at the very least, it sounds like you agree the api can be simplified for shared workers and conversations on a dedicated worker along the lines i proposed: |
| 19:10 | <aboodman> | * remove the port properties in the shared worker interfaces |
| 19:11 | <aboodman> | * make startconversation just return a port, and fire onconnect |
| 19:11 | <sicking> | are there port properties on shared workers? |
| 19:11 | <aboodman> | http://www.whatwg.org/specs/web-workers/current-work/#shared1 |
| 19:12 | <sicking> | oh |
| 19:12 | <sicking> | ooh |
| 19:12 | <sicking> | i remember |
| 19:12 | <aboodman> | there is none on the inside, i don't know why |
| 19:12 | <sicking> | yeah, i'm fine with removing that |
| 19:13 | <sicking> | the way it works now is that when you create a shared worker |
| 19:13 | <sicking> | that basically calls startConversation |
| 19:13 | <sicking> | except onconnect rather than onmessage is fired |
| 19:13 | <aboodman> | right |
| 19:13 | <sicking> | and the 'outer' port is put on the .port rather than being returned anywhere |
| 19:14 | <sicking> | btw, there is basically no way we can remove onmessage as a way to set up conversaions |
| 19:14 | <sicking> | since you can just use postMessage("here ya go", myPort) |
| 19:15 | <aboodman> | i don't follow |
| 19:15 | <sicking> | so today you can do this: |
| 19:15 | <sicking> | ch = new MessageChannel; |
| 19:15 | <sicking> | w = new SharedWorker(...); |
| 19:16 | <sicking> | w.postMessage("lets talk", ch.port2); |
| 19:16 | <sicking> | ch.port1.onmessage = function(e) { ... } |
| 19:17 | <aboodman> | i guess |
| 19:17 | <aboodman> | i still don't understand this use case at all |
| 19:17 | <aboodman> | but it is orthagonal to what i'm talking about |
| 19:17 | <sicking> | yeah, that's basically already part of HTML5, not part of workers at all |
| 19:17 | <aboodman> | if people also want the ability to pass ports around, ok... |
| 19:17 | <sicking> | Hixie has been talking about that a lot |
| 19:17 | <aboodman> | html5 is not really set in stone |
| 19:18 | <sicking> | so i assume that google wants that |
| 19:18 | <aboodman> | nobody has implemented this feature yet, right? |
| 19:18 | <sicking> | for widgets and the like |
| 19:18 | <aboodman> | somebody wants it, just not me. |
| 19:18 | <sicking> | not sure if the other postMessage implementations do that |
| 19:18 | <sicking> | heh :) |
| 19:18 | <aboodman> | i don't think it's valid to say 'it's already in html5, we can't remove it' |
| 19:19 | <aboodman> | the spec specifically says that it is in progress |
| 19:19 | <aboodman> | if there are good reasons to pass ports around, hey, great, let's keep them. |
| 19:19 | <sicking> | so i don't want to talk for hixie, but from what i understand there were requirements around widgets that required that |
| 19:19 | <aboodman> | he explained them in our last meeting, i just am still not convinced. |
| 19:19 | <aboodman> | anyway, i think that issue can be separated. |
| 19:21 | <sicking> | sure |
| 19:23 | <aboodman> | so would you be in favor of: (my proposal - global onmessage) + DedicatedWorker::sendMessage + DedicatedWorkerGlobalScope::onmessage |
| 19:23 | <sicking> | yup, think so :) |
| 19:23 | <aboodman> | ok, that is still a significant change from the current spec |
| 19:24 | <sicking> | i think it can be discussed if we should have an 'onconnect' or if we should reuse 'onmessage' |
| 19:24 | <aboodman> | you mean just overloading the event? |
| 19:24 | <aboodman> | so you get an onmessage event when a connection happens? |
| 19:24 | sicking | ponders |
| 19:24 | <sicking> | right, some such |
| 19:25 | <sicking> | hmm |
| 19:25 | <sicking> | doesn't really work for shared workers since they don't have onmessage |
| 19:25 | <sicking> | so yeah, what you said :) |
| 19:27 | <aboodman> | thanks, i will reply to the mail thread pointing to this irc log and summarizing |
| 19:37 | Philip` | reads the log and sees 'startConversaion', 'startconversation', 'startConversaion', 'startConveration', 'startConversaion', 'startConversation', and continues to think that renaming to 'connect' would be good |
| 19:38 | <aboodman> | :) |
| 19:38 | <aboodman> | as a rule, my poor typing should not be taken as indication of the quality of an api. |
| 19:39 | <Philip`> | aboodman: It's an indication of the problems that many other people are likely to experience |
| 19:40 | <aboodman> | i'm in favor of 'connect()' |
| 19:40 | <Philip`> | Data suggests that <script langauge="..."> is pretty common |
| 19:41 | <Philip`> | which is apparently why we have <meter> instead of <gauge> |
| 19:41 | <Philip`> | So I think those typos are relevant evidence :-) |
| 19:42 | <Philip`> | although I'm probably wrong |
| 19:42 | <Philip`> | because people take more care when typing code than typing IRC |
| 19:42 | <Philip`> | and so typos will be much rarer when people write actual code, and only real spelling difficulties matter |
| 19:44 | <sicking> | aboodman, so with connect there will still be 3 ways to have a conversation (sort of) on a dedicated worker |
| 19:44 | <sicking> | aboodman, as the html5 spec stands today |
| 19:44 | <aboodman> | explain/ |
| 19:45 | <sicking> | aboodman, i'm not really opposed to changing that, but it would need changing |
| 19:45 | <aboodman> | sicking: how so? |
| 19:45 | <sicking> | aboodman, so there will be worker.postMessage('hi there'); |
| 19:45 | <sicking> | ch = new MessageChannel(); worker.postMessage('lets converse', ch.port1); |
| 19:46 | <sicking> | and port = worker.connect(); |
| 19:46 | <sicking> | i'm not in love with the second one, but as things stand it's there |
| 19:47 | <aboodman> | i guess, i don't count that one because i don't see people doing it. |
| 19:47 | <aboodman> | you'll only use that when you want to do ... whatever it is hixie forsees people doing with it |
| 19:47 | <sicking> | well |
| 19:47 | <aboodman> | but ok. |
| 19:47 | <sicking> | there is the argument that impls will end up having to impl all 3 since hixie will use it in acid7 |
| 19:48 | <aboodman> | let's keep the issue of passing ports separate. |
| 19:48 | <sicking> | no matter if people want it or not |
| 19:48 | <aboodman> | i think they really are separate concerns. |
| 19:48 | <sicking> | ok |
| 20:45 | Hixie | is very confused about the feedback on workers |
| 20:45 | <gsnedders> | Hixie: n00b. |
| 20:46 | <Hixie> | sicking: the original API had just one way of using messages, and you and aaron both asked for more ways (he asked for .startConversation, you asked for the API to be flattened onto the dedicated workers for ease of use) |
| 20:46 | <Hixie> | sicking: and now you're both asking for the APIs to be unified again but leaving some of the differences? |
| 20:46 | <Hixie> | what changed? |
| 21:10 | <Hixie> | holy wow |
| 21:11 | <Hixie> | i scanned 100 million documents and found absolutely no occurances of <input type=file accept> |
| 21:11 | Hixie | increases his sample by a factor of 10 and tries again |
| 21:20 | <gsnedders> | I am far too good at procrasintating. |
| 21:20 | <gsnedders> | Must. write. personal. statement. |
| 21:21 | <gsnedders> | But my stomach hurts and I don't wanna. |
| 21:30 | Philip` | sees some with <input type=text accept> and <input type=submit accept>, but isn't surprised that he doesn't see any on type=file because it's very unlikely that a site will have a file upload box on public pages |
| 21:31 | <Hixie> | there were lots of <input type=file> elements |
| 21:31 | <Hixie> | just none with accept |
| 21:32 | <Philip`> | http://google.com/codesearch?q=type%3D%22file%22+accept%3D |
| 21:33 | <Philip`> | Seems reasonably common and varied there |
| 21:35 | <Hixie> | what does "Generating the page that the server would have generated on the fly on the client side while offline seems really hacky. I really don't |
| 21:35 | <Hixie> | er |
| 21:36 | <Hixie> | what does |accept="{@mime-types}"| do in xslt? |
| 21:37 | <Philip`> | Wild guess: Sets the accept attribute value on the output element to be the value of the mime-types attribute on the input element (i.e. the element that matched the <xsl:template>) |
| 21:37 | Hixie | sees accept="text/*.xml" and is a little sadder |
| 21:37 | <Hixie> | ooh, that makes sense |
| 21:37 | <Hixie> | ok |
| 21:38 | <Hixie> | looks like a lot of people use foo/* |
| 21:38 | <Hixie> | including text/* |
| 21:38 | <Hixie> | which is odd |
| 21:38 | <Hixie> | and people seem to put spaces around their commas |
| 21:38 | <Philip`> | where I guess {...} is string interpolation, and contains an XPath expression that returns a string, or something like that |
| 21:39 | <Philip`> | because it'd be kind of crazy and unintuitive if they designed the language in any other way |
| 21:39 | <Philip`> | and I like to assume people aren't crazy :-) |
| 21:40 | <Hixie> | accept="text/*.*" |
| 21:40 | <Hixie> | that fails in so many ways |
| 23:56 | <weinig> | Hixie: ping? |