| 00:54 | <TabAtkins> | Hixie or others: If task A is queued to Source A, and then task B is queued to Source B, we're guaranteed that A will pop before B, right? That is, temporal ordering of tasks is preserved across task sources? |
| 00:58 | <TabAtkins> | This is implicit if a browser ignores the task sources and just puts everything in a big queue, and seems like it would be easy to rely on, as the precise task source an event is queued into feels like an implementation detail to an author, and so I presume it's actually required. |
| 01:11 | <zewt> | TabAtkins: afaik, the whole point of different task sources is that ordering is *not* preserved across them--ordering is only preserved within the same task source |
| 01:12 | <zewt> | (well, there's also some stuff that says "delete all tasks in task source xxx", i think) |
| 01:13 | <zewt> | well, task *queues*--not completely sure what the distinction is between task queues and task sources, off-hand |
| 01:23 | <TabAtkins> | zewt: Problem there is that a worker can be using a proxy canvas, call commit(), and then postMessage to the main thread, but have no guarantee that when the message arrives the new data will have been pushed to the main-thread canvas. |
| 01:25 | <esprehn_> | TabAtkins: could we expose an oncommit event on canvas? |
| 01:25 | <esprehn_> | seems like something you'd want |
| 01:25 | <TabAtkins> | Yes, sounds useful. |
| 01:29 | <zewt> | TabAtkins: well, it sounds equivalent to sending messages over two MessagePorts (each with their own task source) to the same place--the order is undefined |
| 01:30 | <zewt> | if the order of two message ports can't be defined, committing a canvas would seem to have the same basic problem |
| 01:30 | <TabAtkins> | In that case, there's a bit of a usability problem, and we need an event on the canvas like esprehn_ says. |
| 01:31 | <esprehn_> | I think the event is nice as well since you don't need adhoc postMessage |
| 01:31 | <esprehn_> | it would seem fairly common to want your background image processor to tell the UI thread it's done drawing |
| 01:34 | <esprehn_> | ex. your game engine is drawing in the worker |
| 02:40 | <Hixie> | TabAtkins: no, the whole point of task sources is that they identify tasks that are not ordered relative to eacho ther |
| 02:41 | <Hixie> | TabAtkins: (thus most things should use the DOM manipulation task source) |
| 02:45 | <TabAtkins> | Hixie: Kk, in that case see the discussion immediately above, where we probably need an "oncommit" event fired at the main-thread canvas. |
| 02:45 | <TabAtkins> | So you can coordinate. |
| 02:45 | <Hixie> | if you need to coordinate, just send the bitmap across instead of using the proxies |
| 02:46 | <Hixie> | (it's no less performant) |
| 02:46 | <Hixie> | (in fact it's probably essentially the same code in the backend) |
| 02:46 | <TabAtkins> | You mean as an ImageBitmap? |
| 02:46 | <Hixie> | yeah |
| 02:49 | <TabAtkins> | I'll check and see if that's acceptable, or if there are hidden impl things that make it less performant. |
| 02:50 | <Hixie> | should be almost identical, but if it's not please do let me know! |
| 03:05 | <esprehn_> | Hixie: the event would still be nice :) |
| 03:14 | <Hixie> | esprehn_: when would the event fire? 60 times a second shortly after the bitmap was updated? |
| 03:15 | <esprehn_> | Hixie: is it really specced to swap buffers 60 times a second? I thought there was an explicit commit() from the worker |
| 03:15 | <Hixie> | i'm assuming the commit() will be called at the end of the requestAnimationFrame() callback |
| 03:16 | <esprehn_> | inside the worker? |
| 03:16 | <Hixie> | yeah |
| 03:17 | <esprehn_> | then yes, it'd fire that many times a second |
| 03:17 | <esprehn_> | just like if you did a postMessage() back at the page inside rAf |
| 03:18 | <Hixie> | why would that be useful? |
| 03:18 | <Hixie> | i don't really understand the use case here |
| 03:18 | <Hixie> | (not saying there isn't one -- i don't disagree, just don't understand |
| 03:18 | <Hixie> | ) |
| 03:18 | <esprehn_> | Hixie: because I want to setup things inside the <canvas>, for example putting DOM nodes down inside since they can receive focus and events, but are not drawn |
| 03:19 | <esprehn_> | Hixie: in my game engine the drawing/physics are happening in the worker, but I don't want the focusable things in the canvas tree to appear until the user can actually see them |
| 03:19 | <Hixie> | ah, then an event that fires sometime after the bitmap is synced is no good |
| 03:19 | <Hixie> | you'd want either a synchronous event, or to do the painting yourself |
| 03:20 | <TabAtkins> | Yeah, and with that scenario, "pass the ImageBitmap in your postMessage" is the right answer. |
| 03:20 | <esprehn_> | And then do drawImage(bitmap) and hope the implementation is smart about it? |
| 03:20 | <Hixie> | we could have a synchronous event, but it would preclude implementations doing the painting without going via the main thread, which i don't think is a good idea |
| 03:22 | <MikeSmith> | heycam: nice slides |
| 03:22 | <MikeSmith> | http://mcc.id.au/2013/lca-webidl/ |
| 03:22 | <esprehn_> | Hixie: if the worker is not committing in every rAf, how does the page know when it's safe to call toDataURL() and not get a blank visual? |
| 03:23 | <heycam> | MikeSmith, thanks; Chris Heilmann is responsible for the nice styling |
| 03:23 | <TabAtkins> | esprehn_: The *page* (main thread) never has a blank visual, once a single frame has come in. |
| 03:23 | <Hixie> | esprehn_: you mean, how do you know when at least one commit has been done? |
| 03:23 | <esprehn_> | Hixie: yes |
| 03:23 | <Hixie> | esprehn_: you don't |
| 03:24 | <esprehn_> | Hixie: Something like Google Feedback wants to know without polling the page constantly |
| 03:24 | <Hixie> | google feedback just wants to get what's actually rendering |
| 03:25 | <esprehn_> | yes, modulo rendering delay. So if Google Maps is still drawing and nothing has painted yet, we might wait for a single frame to appear before taking a screenshot |
| 03:25 | <MikeSmith> | heycam: ah I was going to ask about the styling. I should have figured Chris had a hand in it. I like the fact that the presentation starts with an thumbnail view of all the slides, instead of with the first slide. Seeing that, I think all slide tools should do it that way. Or provide it as an option at least. |
| 03:25 | <esprehn_> | Hixie: I guess that's somewhat specific, but it would be nice to know if the buffer in the canvas is "fresh" |
| 03:25 | <Hixie> | esprehn_: if google maps is still drawing and nothing has painted yet, that's probably what the user is bitching about, and thus probably a good thing to have in the screenshot :-) |
| 03:26 | <heycam> | MikeSmith, yeah that is unconvential. I think you put "?full" at the end to begin with the first slide. |
| 03:26 | <heycam> | MikeSmith, (the presentation toolkit is Shower) |
| 03:27 | <Hixie> | esprehn_: you cannot know if it's fresh, by design. There's no locking and no shared state, it's a purely asychronous message-passing system. |
| 03:27 | <Hixie> | esprehn_: the worker could send two commit() messages back to back, and the main thread might get them two weeks apart. |
| 03:27 | <kochi_> | hello, #whatwg |
| 03:27 | <esprehn_> | Hixie: you're misunderstanding |
| 03:27 | <Hixie> | hello kochi_ |
| 03:27 | <Hixie> | esprehn_: that's quite possible :-) |
| 03:27 | <esprehn_> | Hixie: there's no message passing system inside the <canvas> |
| 03:28 | <Hixie> | esprehn_: the entirety of canvas is one big message passing system |
| 03:28 | <Hixie> | esprehn_: (to the GPU) |
| 03:28 | <esprehn_> | Hixie: you should be able to ask the <canvas> if it's ever had any drawing commands or commit() executed on it |
| 03:28 | <kochi> | ah, from proper client again: hello! |
| 03:28 | <kochi> | (without underscore) |
| 03:29 | <esprehn_> | Hixie: that's trivial to detect, since the swap() for the draw under the hood is known. Or in some implementations they may not even allocate the output surface until some drawing command has been executed |
| 03:29 | <MikeSmith> | hey kochi |
| 03:29 | <Hixie> | esprehn_: if the commit() happened on a different thread, it's not at all necessarily trivial. |
| 03:29 | <kochi> | MikeSmith: hi! |
| 03:30 | <Hixie> | esprehn_: we could provide an async api that reports back "at some point in the past, i knew that we had/had not seen a commit()" |
| 03:30 | <Hixie> | esprehn_: but that doesn't seem hugely useful |
| 03:30 | <esprehn_> | I don't understand why that needs to be async |
| 03:31 | <Hixie> | esprehn_: because there's no locking and the commit() could be happening on another thread |
| 03:31 | <esprehn_> | Hixie: when does the context in the main thread get data so it's visible to getImageData() ? |
| 03:32 | <Hixie> | esprehn_: getImageData() is a bad API. It should have been async. It blocks on the GPU. |
| 03:32 | <Hixie> | esprehn_: the main thread has to ask the GPU for the data. |
| 03:34 | <kochi> | MikeSmith: i am still sorting it out from internal reviews for ime api spec, and trying to get it out until the end of the next week. |
| 03:35 | <MikeSmith> | kochi: sounds good. If you need any feedback or help from me, just let me know. |
| 03:36 | <kochi> | MikeSmith: thanks! |
| 03:37 | <esprehn_> | Hixie: so then the answer is never? or the answer is getImageData() should block on the commit? |
| 03:38 | <kochi> | a minor issue I would like to bring here is how assigning a property of an object with side effect allowed. |
| 03:38 | <Hixie> | esprehn_: the answer is that in principle the main thread gets the data either at some arbitrary point after the UI is updated, or it has to request it from the GPU |
| 03:39 | <kochi> | e.g. we have ime_context.enabled as readonly + ime_context.setEnabled(true or false) vs ime_context.enabled as read/write |
| 03:39 | <esprehn_> | Hixie: okay |
| 03:39 | <esprehn_> | Hixie: I wonder what the implications of this on out of process workers are |
| 03:40 | <esprehn_> | Hixie: You can't talk directly to the GPU from inside the other process, so commit() has to send the buffer/shm across to the painting thread in another process |
| 03:41 | <TabAtkins> | kochi: the latter is *much* better. |
| 03:41 | <kochi> | TabAtkins: hi! |
| 03:42 | <TabAtkins> | yo. ^_^ |
| 03:42 | <kochi> | TabAtkins: could you explain why? I got used to C++ programming and modifying a property without setter/getter makes me feel uneasy :) |
| 03:43 | <TabAtkins> | Because it's a C++ pattern, and that's now idiomatic JS. ^_^ |
| 03:44 | <TabAtkins> | Most of the DOM's sins can be traced to C++ programmers trying to apply C++ idioms to JS. (Or Java programmers doing the same.) |
| 03:44 | <esprehn_> | no, the idea is sane :) |
| 03:44 | <esprehn_> | JS just provides property getters and setters so there's no issue in the future |
| 03:45 | <TabAtkins> | Sorry, I was referring specifically to the syntax that kochi was suggesting, where the setter was an expliclitly-named "setFoo" method. |
| 03:45 | <kochi> | TabAtkins: hmm, but what if assigning .enable = true is a heavy operation? in that case, should we have an asynchronous method with callback? |
| 03:45 | <esprehn_> | yeah, setters will hopefully be a thing of the past soon |
| 03:45 | <TabAtkins> | Yes, the .enabled property might be a JS getter/setter under the hood. |
| 03:45 | <esprehn_> | even ObjC added properties |
| 03:45 | <TabAtkins> | kochi: It depends on the specifics. |
| 03:46 | <TabAtkins> | kochi: If setting it would do enough work to jank the thread, or for some other reason takes a non-trivial amount of time, then yes, you probably want it to be asynchronous. |
| 03:46 | <TabAtkins> | And thus a method with callbacks or events. |
| 03:46 | <Hixie> | esprehn_: that depends on the architecture. There's nothing in principle about computer science that says that the rendering can't happen off the main thread without main thread involvement. |
| 03:47 | <kochi> | TabAtkins: I see, probably people agree if the synchronous assignment blocks, having async method would be preferred. |
| 03:48 | <TabAtkins> | Yes. |
| 03:49 | <TabAtkins> | kochi: Like if it has to communicate cross-process, for example. |
| 03:49 | <kochi> | TabAtkins: thanks for the advice. |
| 03:51 | <kochi> | TabAtkins: so .setFoo() or .isFoo() is generally not a preferred naming? |
| 03:51 | <TabAtkins> | kochi: In general, yes. isFoo(), sometimes, depending on the API. If it's just to check on a boolean, then it's frowned upon. |
| 03:52 | <TabAtkins> | But if it's something like "isArray(object-that-might-be-an-array)", it's okay. |
| 03:52 | <kochi> | TabAtkins: i see. |
| 04:05 | <zewt> | Hixie: but real software is bound by the graphics systems of the OS they run on, and Microsoft isn't going to reengineer Direct3D to allow cross-process rendering to allow Firefox to implement it, so in reality they'd have to do something else |
| 04:08 | <zewt> | in reality i'd expect dedicated (not shared) workers to run in the same process as the thread that created them, and for most threaded rendering to use dedicated workers, so if they only have to fall back to something slow for shared workers, that's probably OK |
| 04:10 | <Hixie> | zewt: sure, and the spec allows that. But the spec has to be written for next decade's architectures as well as this decade's, so its constraints are sometimes narrower (or its requirements wider) than today's tech would imply. |
| 04:12 | <zewt> | Hixie: i don't think that applies here; if it was unreasonable to implement (which it probably isn't), the spec could forbid it today and relax the restriction when tech catches up |
| 04:32 | <jamesr_> | D3D allows for cross-process rendering just fine if you can assume D3D9Ex or up |
| 04:32 | <jamesr_> | so win xp is a bit screwed, but the drivers are so bad there you probably don't want to attempt to use the GPU for canvas anyway |
| 04:45 | <roc> | yes |
| 05:02 | <Hixie> | zewt: not sure exactly what you're referring to |
| 07:23 | <MikeSmith> | I prefer the Mark Watson messages that he sends from his iPhone |
| 07:24 | <MikeSmith> | they are much easiser to read -- much easier to distinguish what's him from what who he's quoting |
| 07:53 | <Ms2ger> | heycam|away, http://mcc.id.au/2013/lca-webidl/?full#Enumerations is wrong |
| 07:53 | <Ms2ger> | ctx.fillRule = "something"; // throws TypeError |
| 07:54 | <Ms2ger> | Actually, for attributes, it's ignored silently |
| 08:18 | <MikeSmith> | Ms2ger: on mac do you know is there a target name I can give to mach to get it to build a *.dmg? |
| 08:39 | <Ms2ger> | MikeSmith, package |
| 08:39 | <hsivonen> | Can someone review http://wiki.whatwg.org/wiki/Why_not_conneg#Server-side_choice_is_worse_for_intermediate_caches_than_browser-side_choice for technical accuracy, please? |
| 08:43 | <MikeSmith> | Ms2ger: super thanks |
| 08:43 | <Ms2ger> | Np :) |
| 08:43 | <jgraham> | hsivonen: Oh, interesting point. But I don't think I know better than you how HTTP caching works, so I don't think the fact that I don't see an error (without reading the spec) means that there are no errors |
| 08:55 | <annevk> | hsivonen: sounds about right |
| 08:56 | <annevk> | hsivonen: HTTP caching combined with content negotiation is pain |
| 08:56 | <annevk> | hsivonen: might want to ask mnot / jreschke I suppose |
| 11:57 | <annevk> | MikeSmith: kinda weird that the Notifications WG was extended without anyone asking me about it... |
| 11:58 | <annevk> | But I guess that's pretty much par for the course. |
| 12:29 | <annevk> | I wonder where http://www.w3.org/TR/its20/ is used to the extent of its-storage-size=25 |
| 12:29 | <annevk> | Also, for HTML's hyphenless design there's quite a few hyphens there |
| 12:31 | <MikeSmith> | annevk: about Notifications WG, I should have given you a heads-up about it |
| 12:32 | <MikeSmith> | you knew I had asked if anybody else would be willing to chair the group, right? |
| 12:32 | <annevk> | Btw, participating in the TAG as a non-Member is difficult as it requires Member access to e.g. dial into the teleconference |
| 12:33 | <annevk> | MikeSmith: I think I was just confused about the meaning of "very soon" in http://lists.w3.org/Archives/Public/public-web-notification/2012Nov/0008.html |
| 12:34 | <annevk> | (The TAG problem is largely theoretical for me btw starting Monday next week, but still.) |
| 12:35 | <Ms2ger> | Nice way to leave us hanging :) |
| 12:37 | <annevk> | Ms2ger: if unlike me you can access https://lists.w3.org/Archives/Member/tag/latest you might be able to find out more |
| 12:37 | <MikeSmith> | annevk: still if there's no requirement for TAG members to be from W3C member orgs or to sign up for "invited expert" member access, then dialing in should not require Member access so I will ask that be changed |
| 12:38 | <annevk> | MikeSmith: I think the Invited Expert thing is required, not sure if that has happened yet |
| 12:38 | <Ms2ger> | annevk, I see, that also answers my next question :) |
| 12:38 | <annevk> | Ms2ger: Was hoping to write a blog post, maybe this weekend |
| 12:39 | <MikeSmith> | there are lot of assumptions been made in the way that the TAG currently aoperates that are maybe going to ned to be changed or at least considered more carefully |
| 12:40 | <MikeSmith> | like I also had my own assumptions about the communication about the Notifications WG but I can see I should have handled that differently |
| 12:42 | <MikeSmith> | but the reason for the delay between Noveember and now in me saying anything else about it was it took that long to get confirmed agreement about getting a new chair, and then for me to go back to the W3C management and get it all approved |
| 12:42 | <MikeSmith> | and just delays from me personally in not getting around to it faster |
| 12:43 | <Ms2ger> | Sounds like you're having a lot of fun with the bureaucracy :) |
| 12:44 | <MikeSmith> | well handling this kind of stuff is not on my list of favorite things to do |
| 12:44 | <MikeSmith> | maybe I should have stepped back and asked somebody else on the team to handle ti |
| 12:45 | <Ms2ger> | Wouldn't fit in with the beer and other booze on that list? ;) |
| 12:45 | <MikeSmith> | shochu |
| 12:45 | <MikeSmith> | but yeah |
| 12:51 | jgraham | assumes that on Monday annevk will ascend to demigod status like Wesley Crusher did in a notably cringeworthy episode of Star Trek:TNG |
| 12:53 | <Ms2ger> | Sounds about right |
| 12:58 | <MikeSmith> | all right shit |
| 12:59 | <MikeSmith> | you guys guessed it |
| 12:59 | <MikeSmith> | so I might as well say |
| 12:59 | <MikeSmith> | we're appointing annevk to be Director |
| 13:01 | <Ms2ger> | "Programmable state-machines in CSS proposal" |
| 13:01 | <Ms2ger> | I think I'm going to skip this |
| 13:04 | <jgraham> | Ms2ger: I totally want it to be possible to build a turing machine in CSS. That actually renders the tape. |
| 13:04 | <jgraham> | Pure CSS of course |
| 16:16 | <annevk> | http://www.bbc.co.uk/news/business-21258205 omg |
| 16:18 | <annevk> | how do those people get a job? |
| 16:21 | <jgraham> | annevk: Would *you* admit to taking anything from Apple? |
| 16:21 | <miketaylr> | wow, that's really hard to listen to |
| 16:21 | miketaylr | cringes for everyone |
| 16:22 | <jgraham> | Although when they get onto "why would you buy a blackberry" he is pure fail |
| 16:23 | <jgraham> | Maybe he could have said "you wouldn't" and stopped. That's would have been shorter and contained the same essential message. |
| 16:24 | <miketaylr> | heh |
| 16:24 | <jgraham> | (note: I have no idea if BB actually has redeeming features, but "this product sucks" is the message I got from that interview) |
| 16:25 | <annevk> | Not acknowledging the question at all was just such a fail. Way to go for the BBC to not let them walk and call the guy out on his marketing speak. |
| 16:28 | <jgraham> | Yeah, but it's a bit unfortunate that question could be interpreted as "what would you like to be sued for?" |
| 16:29 | <Ms2ger> | Round corners |
| 16:34 | <Stevef> | darobin: ping |
| 17:40 | <dglazkov> | good morning, Whatwg! |
| 17:45 | <JonathanNeal> | heyo |
| 18:32 | <gsnedders> | jgraham: You don't mind if I add an optional dependency on a couple of C tries for html5lib? |
| 18:33 | <Ms2ger> | Ugh, C |
| 18:40 | <nimbu> | darobin: necolas wants to talk to you |
| 18:41 | <darobin> | divya: I'm connected on and off as I hop from meeting to meeting, so the simplest might be email |
| 18:41 | <darobin> | with which I'll lag until next week, but at least it won't get lost |
| 18:43 | <necolas> | darobin: it's ok, there's no rush. i was interested in finding out who to talk to about some things we're encountering while developing our (twitter) widgets. |
| 18:43 | <darobin> | necolas: sure thing! |
| 18:44 | <darobin> | I'm leaving here in 5 minutes, so either some time later, or robin⊙wo as you prefer |
| 18:44 | <necolas> | darobin: thanks, sounds good. |
| 18:44 | <darobin> | np |
| 18:45 | <gsnedders> | Ms2ger: The tests you added to html5lib are wrong in their expectation |
| 18:46 | <gsnedders> | You need more whitespace. Will fix. |
| 19:00 | <Ms2ger> | gsnedders, I'm afraid I have to admit I never got around to actually running them :) |
| 19:04 | <TabAtkins> | Ms2ger: Not full state machines, but the ability to design multi-step animations between states, seems useful. |
| 21:11 | <jgraham> | gsnedders: Have you checked the implementation for badness? e.g. istr that trie-based implementations of entity parsing can use rather a large amount of memory if not done carefully |
| 22:14 | <gsnedders> | jgraham: Yes. |
| 22:27 | <JonathanNeal> | This drag and drop polyfill should be working in IE8&9 http://jonathantneal.github.com/dropfile/ |
| 22:28 | <tantek> | that's an impressive accomplishment |
| 22:32 | <yroc> | Hixie: Section 4.6.14 (samp element), "Nested samp and kbd elements..." |
| 22:33 | <yroc> | Shouldn't it be "Nested *span* and kbd elements..."? |
| 22:33 | <Hixie> | no? |
| 22:33 | <Hixie> | why would it be span? |
| 22:33 | <yroc> | That seems to be what the accompanying example is showing. |
| 22:33 | <yroc> | <span class="prompt"> |
| 22:34 | <yroc> | Or is the example wrong? |
| 22:34 | <yroc> | Or am I wrong? |
| 22:39 | <Hixie> | look closer :-) |
| 22:39 | <Hixie> | there are spans there, it's true |
| 22:39 | <Hixie> | but they're just for styling |
| 22:42 | <yroc> | Yeah, but that's what the sentence says -- that samp and kbd are there for "styling of specific elements of the samp output" |
| 22:42 | <yroc> | But then spans are used for styling! |
| 22:57 | <Hixie> | yroc: yeah, i can add a comment about the span too. |
| 23:06 | <yroc> | OK great. Not to belabor the point, but when the sentence introducing the example says, "Nested samp and kbd elements allow for the styling of specific elements of the sample output...", what is the 'specific element' that sample output that samp is styling in the example? |
| 23:06 | <yroc> | Sorry: what is the 'specific element' that samp is styling in the example? |
| 23:07 | <yroc> | Because samp is wrapping the entire block. |
| 23:11 | <Hixie> | samp is styling the "output" of the computer, like, what would be on the screen |
| 23:11 | <Hixie> | and "kbd" is styling the input; in the case of kbd-nested-in-samp, the part of the output that echoed the input |
| 23:12 | <Hixie> | (Under <kbd>'s definition, the spec says "When the kbd element is nested inside a samp element, it represents the input as it was echoed by the system.") |
| 23:12 | <Hixie> | (reload for the latest update to that example btw) |
| 23:13 | <Hixie> | MikeSmith: you around? |
| 23:20 | <yroc> | Hixie: OK, it's clear. Thanks very much :) |
| 23:24 | <JonathanNeal> | Have you guys already addressed some of the keyboard issues talked about here? http://codeflow.org/entries/2013/jan/30/keyboard-events-in-javascript-are-broken/ |
| 23:24 | <Hixie> | not to my knowledge |
| 23:25 | <Hixie> | it's a huge amount of work that nobody who's sane has been brave enough to attempt |
| 23:25 | <Hixie> | jgraham: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17155 ping |
| 23:44 | <Hixie> | hsivonen, jgraham, gsnedders, abarth: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=17924 |
| 23:53 | <JonathanNeal> | Well gee, what all needs to be done? Write a spec? |
| 23:56 | <Hixie> | JonathanNeal: write a ton of test cases, figure out what the browsers are actually doing, figure out what a common ground is, convince all the browser vendors that converging on that common ground makes sense, and speccing it. |
| 23:57 | <Hixie> | and then, maintaining the spec for several years as everyone finds errors in your work :-) |
| 23:57 | <JonathanNeal> | just that? |
| 23:57 | <Hixie> | yup |
| 23:57 | <Hixie> | more or less |
| 23:57 | <jacobolus> | Hixie: any estimate of man hours for that? maybe 1000? |
| 23:57 | <Hixie> | hmmm |
| 23:58 | <zewt> | iirc keyboard stuff is hard because everyone's browser sniffing to work around the differences, which makes converging existing apis hard |
| 23:58 | <jacobolus> | maybe that's a bit high. 300-500 spaced out over a few years |
| 23:59 | <JonathanNeal> | We'll get fifty developers together and have it specced out over a weekend. |
| 23:59 | <Hixie> | reverse engineering the browsers is probably a full-time job for a couple of months, if you're not used to doing it, plus a month or two getting up to speed; figuring out what they're doing and what the common ground is is probably another month or so full time, convincing the vendors i'll get back to, writing the spec if you're used to it is probably a couple of days, if you're not maybe a month, full time. |
| 23:59 | <Hixie> | maintaining it is probably a low-bandwidth job for 5 years, maybe a day a week at most |
| 23:59 | <Hixie> | convincing the browser vendors to converge on one thing might be impossible, so i can't estimate how long it'd take |