| 00:00 | <gsnedders> | (Because it didn't work cross-origin) |
| 00:00 | <jwalden> | bumpy landings happen |
| 00:00 | <gsnedders> | I'm tempted to just try and make the change to an accessor in Carakan, and go back to arguing for that. |
| 00:01 | <gsnedders> | And try and pick the fight for the setter once we've got major mobile libraries not relying upon it. |
| 00:01 | <gsnedders> | Because I do really want to get rid of the setter. |
| 00:02 | <jwalden> | word to your mother |
| 00:02 | <gsnedders> | What I want is someone to do a good write-up of why you don't want to mutate [[Prototype]] and shove it in the face of developers who do. |
| 00:03 | <gsnedders> | jwalden: You were CC'd on the emails about dropping __proto__ before, weren't you, about a year or so ago now? |
| 00:04 | gsnedders | thinks he remembers Apple people agreeing in principle |
| 00:05 | <gsnedders> | Eh, not even I was. |
| 00:06 | <gsnedders> | Just your later email RegExp.prototype.compile. |
| 00:06 | <jwalden> | oh gag, that idiocy |
| 00:07 | <jwalden> | I vaguely remember some sort of segue there, not much more than that |
| 00:07 | gsnedders | doesn't really have his email on this laptop |
| 00:07 | <gsnedders> | And webmail is making me gag. |
| 00:09 | <gsnedders> | But yeah, on the whole I think we should just make it an accessor on Object.prototype and move towards getting rid of the setter. |
| 00:10 | <gsnedders> | Making the setter throw from strict is kinda evil, but probably a good idea. |
| 00:10 | <gsnedders> | (From what I've seen relying upon the setter, it's all non-strict) |
| 00:16 | <TabAtkins> | Did ES5 globally change the "reserved keyword" policy to not block them from being property names? |
| 00:17 | <jwalden> | you could always have them as property names |
| 00:17 | <jwalden> | but now, you can have them to the right of dots, as names in object literals, etc. |
| 00:18 | <TabAtkins> | Really? I thought ES3 prevented you from doing, say, foo.delete() |
| 00:18 | <jwalden> | f["delete"]() |
| 00:18 | <TabAtkins> | That's what I meant, yeah. |
| 00:18 | <jwalden> | if you wanted to call such a function, or access such a property, you needed bracket notation |
| 00:19 | <jwalden> | the Javaheads in particular found this annoying for the delete method on files (I think) |
| 00:42 | <smaug____> | um, I'm bad with CSS |
| 00:43 | StoneCypher | <3 css |
| 00:43 | <smaug____> | how do I get layout where 1st column has the width of its content, and other 2 columns fill the rest of the viewport (they may overflow: auto if needed) |
| 00:44 | <smaug____> | all the "columns" are div elements |
| 00:44 | <StoneCypher> | <left style="position: absolute; left: 0; width: whatever;"/><right style="position: absolute; left: whatever; right: 0;"/> |
| 00:44 | <StoneCypher> | or any of a million other ways |
| 00:44 | <StoneCypher> | oh, width of its content |
| 00:45 | <StoneCypher> | hm. |
| 00:45 | <StoneCypher> | <left style="position: absolute; left: 0; width: auto;"/><right style="position: relative; left: 100%; right: 0;"/> might work |
| 00:45 | <jwalden> | sounds like you want a box that will flex |
| 00:45 | <smaug____> | jwalden: yeah |
| 00:45 | <StoneCypher> | flexbox doesn't reach many browsers yert |
| 00:45 | <StoneCypher> | yet* |
| 00:46 | <smaug____> | I guess I could use -moz-box |
| 00:46 | <smaug____> | or flex, whatever it is called |
| 00:46 | <StoneCypher> | the above should do portably |
| 00:46 | <jwalden> | I just passed by dholbert a minute ago, I could corner him until he finishes implementing it |
| 00:46 | <smaug____> | :) |
| 00:46 | <jwalden> | might need reinforcements, tho |
| 00:51 | <TabAtkins> | smaug____: Use flexbox. |
| 01:31 | <smaug____> | hmm, can't get it to work |
| 01:31 | <smaug____> | it is ok if container of a column is small enough |
| 01:31 | <smaug____> | but overflow: auto doesn't work the way I'd like |
| 01:47 | <MikeSmith> | heycam: do we have any tests for WebIDL? |
| 01:48 | <heycam> | MikeSmith, AryehGregor has written some |
| 01:48 | <heycam> | I have not |
| 01:48 | <MikeSmith> | OK |
| 01:48 | <heycam> | we need to start a thread on the list about which specs we'll choose to be the basis of our test suite |
| 01:48 | <MikeSmith> | AryehGregor: you got WebIDL tests? |
| 01:48 | <MikeSmith> | heycam: OK |
| 01:50 | heycam | lunch bbl |
| 07:41 | <asmodai> | crap |
| 07:42 | <asmodai> | memory constraints on an Android device, pushing your browser out of memory when a new app starts, is a lovely way to lose your open tabs |
| 07:49 | <charlvn> | asmodai: just needs a model where memory isn't shared, similar to chrome |
| 07:53 | <asmodai> | charlvn: That or keeping a state file around |
| 08:22 | <charlvn> | asmodai: a state file could also be a good idea for when you need to turn off or restart your phone |
| 08:22 | <charlvn> | so that could serve two purposes |
| 08:27 | <asmodai> | charlvn: Guess I now know what to suggest to the Opera guys ;) |
| 08:39 | <charlvn> | asmodai: good idea; this is going to become a critical feature moving forward if we want to move the world from "traditional" mobile apps to html-based mobile apps |
| 08:40 | <asmodai> | I find myself often looking up some things in tabs while lying in bed to look at during the day |
| 08:40 | <asmodai> | and then you find your tabs gone XD |
| 08:50 | <annevk> | morning |
| 08:56 | <asmodai> | Hey annevk |
| 08:58 | <charlvn> | morning annevk |
| 08:58 | <annevk> | foolip |
| 08:58 | <annevk> | oops |
| 08:59 | <asmodai> | Now he's calling us fools |
| 09:01 | <charlvn> | foolip - a cross between a fool and a lip |
| 09:03 | <annevk> | so despite all the arguments we had on the list, web intents is still using <intent>? |
| 09:03 | <annevk> | blargh |
| 09:15 | <zcorpan> | matjas: no utf-8 love for the binary convertor? |
| 09:16 | <jgraham> | There was some blog post from a Mozilla guy going "hey, we could perhaps just replace all of this with messaging". Did nothing come of that? |
| 09:16 | <matjas> | zcorpan: i could make one that uses 24 bits per glyph |
| 09:16 | <zcorpan> | matjas: that's not how utf-8 works :-) |
| 09:17 | <matjas> | no, but it’s easier :) |
| 09:17 | <zcorpan> | booo :-P |
| 09:48 | <annevk> | I wonder if Adam Klein is going to provide an updated patch for mutations... |
| 09:54 | <foolip> | charlvn, it's a cross between foo and philip :) |
| 10:18 | <charlvn> | foolip: that sounds fubar :P |
| 10:27 | <foolip> | charlvn, why thank you :) |
| 10:31 | <annevk> | Timing-Allow-Origin header oh god |
| 10:48 | <annevk> | updated XHR BOM handling and defined text/html encoding details |
| 11:13 | <annevk> | anyone opposed to XHR defining the HTTP behavior of data URLs? |
| 11:14 | <jgraham> | Wild guess: Julian |
| 11:15 | <annevk> | nah |
| 11:18 | <annevk> | http://webwereld.nl/nieuws/109547/eu-hof-verbiedt-copyright-filterplicht-voor-hosters.html |
| 11:18 | <annevk> | sweet |
| 11:18 | <annevk> | zo xs4all piratebay ban is ruled obsolete now? |
| 11:18 | <annevk> | oh hosting |
| 11:19 | <annevk> | meh |
| 11:29 | <charlvn> | annevk: yeah i don't think that applies to ISPs |
| 11:30 | <charlvn> | i don't care much about the pirate bay but the concept of having sites banned is just so anti-western it's histerical |
| 11:36 | <charlvn> | heh i can actually open thepiratebay.org at work, just not at home (on ziggo) :P |
| 11:36 | <annevk> | you're in the Netherlands these days? |
| 11:36 | <annevk> | o_O |
| 11:37 | <annevk> | sort of thought you'd be in South Africa still |
| 11:37 | <charlvn> | annevk: what is that supposed to mean? :P |
| 11:39 | <annevk> | unless you're a different charlvn, I'm just surprised |
| 11:40 | <charlvn> | annevk: nah it's the same me (i hope, otherwise i have another me running around somewhere) |
| 12:17 | <annevk> | maybe http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#data:-urls-and-http should be included in HTML? |
| 12:17 | <annevk> | or at least in HTML's fetching algorithm |
| 13:11 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=16000 is mine |
| 13:11 | <annevk> | teehee |
| 13:23 | <Velmont> | 16:45 < annevk> abarth: if you're not around I'll prolly check in "null" <<< As long as it's either "null" or "list-of-origins" I agree. I find it easier to be explicit in the spec, -- I've shown I'm not so good at looking up dependent specs. :-) |
| 13:27 | <MikeSmith> | made some updates to http://platform.html5.org/history/ today |
| 13:29 | <jgraham> | You've been editing history? |
| 13:36 | <annevk> | Velmont: it's null now |
| 13:36 | <annevk> | Velmont: well unique origin which becomes null when serialized |
| 14:21 | <annevk> | it would be nice if there was some URL hack to easily query bugs |
| 14:21 | <annevk> | e.g. w3.org/Bugs/open/xhr or some such for all open xhr bugs |
| 14:21 | <annevk> | bugzilla search is just awful |
| 14:24 | <charlvn> | @annevk instead of this? https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=XHR&resolution=--- |
| 14:26 | <zcorpan> | MikeSmith: <!doctype html> was around june/july 2005 |
| 14:26 | <annevk> | that's reasonably short |
| 14:27 | <zcorpan> | MikeSmith: there was <!doctype html5> also for a very short period, iirc |
| 14:27 | <jgraham> | annevk: There is a REST API. Make your own |
| 14:27 | <jgraham> | Or steal http://shaver.off.net/diary/2011/01/22/i-made-a-thing/ |
| 14:28 | <[tm]_> | zcorpan: ok |
| 14:28 | <[tm]_> | will update it later |
| 14:29 | <annevk> | whoa |
| 14:29 | <annevk> | OS X Mountain Lion |
| 14:29 | <annevk> | I haven't seen any rumors thus far |
| 14:29 | <charlvn> | http://atomictango.com/wp-content/uploads/2009/08/Mac-OSX-Cougar.jpg |
| 14:39 | <jgraham> | annevk: Oh look they are only letting signed apps run by default. That seems about right given there are 3 years for mpligrim's prediction to come true |
| 14:40 | <jgraham> | (and only app-store apps as a non-default option) |
| 15:22 | <StoneCypher> | i'm having some trouble with seams between polygons in canvas. stroking the edges isn't an option; they have complex fills. expanding the polygons also isn't an option. do i have a better answer than to supersample? |
| 15:26 | <Philip`> | StoneCypher: If the polygons never overlap, maybe you could draw them onto a black background with globalCompositeOperation='lighter'? |
| 15:26 | <StoneCypher> | unfortunately that doesn't work in chrome or opera |
| 15:26 | <Philip`> | Otherwise I guess antialiasing will always cause some inaccuracies |
| 15:26 | <StoneCypher> | er, no |
| 15:26 | <StoneCypher> | lots of canvas-style systems don't have this problem |
| 15:27 | <StoneCypher> | computer graphics had this worked out in the 1980s |
| 15:27 | <StoneCypher> | and i don't think that the w3 would release a graphics specification that made high quality graphics impossible |
| 15:27 | <StoneCypher> | this is a 101 topic, like corner mitering |
| 15:31 | <Philip`> | I thought most techniques required some extra buffer space (for supersampling at least some components of the pixels), which doesn't fit with canvas's model of a single 32-bit bitmap |
| 15:31 | <annevk> | time to stock up on yoghurt and eggs |
| 15:32 | <StoneCypher> | Philip`: lol no |
| 15:32 | <Philip`> | Otherwise it seems impossible to distinguish between a pixel drawn by an earlier polygon that is opaque and 50% covered, and a pixel that is fully covered and drawn with 50% alpha |
| 15:32 | <StoneCypher> | Philip`: and also, canvas doesn't specify the memory model, and layered patches are exactly how chrome works |
| 15:32 | <Philip`> | (assuming they're being draw in independent operations) |
| 15:32 | <StoneCypher> | er, it's really not. |
| 15:32 | <Velmont> | annevk: yoghurt? tomatoes and eggs, isn't it? |
| 15:33 | <StoneCypher> | antigrain geometry does it with constructive stacking. flash does it with supersampling. etc. |
| 15:33 | <StoneCypher> | and frankly |
| 15:33 | <StoneCypher> | it wouldn't be that hard to believe that there's a way to render multiple polys at once |
| 15:33 | <StoneCypher> | or something i just don't know about |
| 15:33 | <annevk> | Velmont: thanks for the reminder, should get tomatoes too |
| 15:33 | <StoneCypher> | but i cannot for the life of me imagine that the w3c said "let's make a vector engine that is fundamentally unable to render geometry that's touching" |
| 15:34 | <StoneCypher> | the idea that a vector engine can't represent two shapes next to one another correctly |
| 15:34 | <StoneCypher> | that violates the very most basic usage of vector graphics |
| 15:34 | <StoneCypher> | in a hilariously broken way |
| 15:34 | <Philip`> | (The W3C didn't really have anything to do with the design) |
| 15:34 | <StoneCypher> | i'm really not interested in nitpicking who it was that didn't actually make a mistake this obvious. |
| 15:34 | <Philip`> | (It was mostly just Apple, then incrementally extended by various people) |
| 15:34 | <StoneCypher> | *apple*U ? |
| 15:35 | <StoneCypher> | well fuck, then yes, it probably is this broken |
| 15:35 | <StoneCypher> | god damnit, i have to throw this whole thing away, then. >:( |
| 15:35 | <StoneCypher> | who makes a vector geometry standard that can't handle basic vector geometry |
| 15:36 | <StoneCypher> | this is an embarrasment. |
| 15:36 | <StoneCypher> | and don't give me that "it works in passes, it can't work otherwise" answer again, because 1) no it doesn't, and 2) yes it could |
| 15:36 | <StoneCypher> | here's chrome working exactly the way you say it doesn't: http://neugierig.org/software/chromium/notes/2010/07/clipping.html |
| 15:36 | <Velmont> | Don't see the need to be so angry. |
| 15:36 | <StoneCypher> | why not |
| 15:37 | <StoneCypher> | the whole web is, apparently, moving to a broken standard |
| 15:37 | <StoneCypher> | one that most graphics people in the 1980s knew how to get around |
| 15:37 | <StoneCypher> | anyway, i'm not angry |
| 15:37 | <Velmont> | Well, I'm quite sure one guy being angry on an IRC channel isn't really going to help that. |
| 15:37 | <StoneCypher> | please stop playing freud with strangers |
| 15:37 | <StoneCypher> | thanks |
| 15:38 | <Velmont> | No, not angry, but ... some less intense word. |
| 15:38 | <annevk> | upset |
| 15:38 | <Velmont> | Yes |
| 15:38 | <Velmont> | That :-) |
| 15:38 | <StoneCypher> | i can see the two of you are good at reading emotions. |
| 15:38 | <annevk> | but euh, broken standards? |
| 15:38 | <annevk> | film at 11 |
| 15:38 | <StoneCypher> | yes, that's how we get places like this, is people saying "i don't really care that this is fundamentally broken, and you shouldn't either." |
| 15:39 | <StoneCypher> | not really interested in people being not interested. |
| 15:39 | <annevk> | StoneCypher: anyway, if you want vectors, wouldn't it be better to use SVG? |
| 15:39 | <annevk> | StoneCypher: <canvas> is for bitmap graphics |
| 15:39 | <StoneCypher> | i don't want vectors. i want raster. |
| 15:39 | <jgraham> | StoneCypher: I thought it was rather close to the graphics model on OSX |
| 15:39 | <annevk> | mkay |
| 15:39 | <jgraham> | Maybe I am wrong |
| 15:39 | <StoneCypher> | jgraham: yeah, that's why when they said it was apple i suddenly said "shit, maybe it is this broken" |
| 15:39 | <StoneCypher> | jgraham: apple's graphics model is the only major graphics model on the market that has this problem |
| 15:39 | <Philip`> | StoneCypher: That post says "the layer code never worked for <canvas> at all. Canvas calls don't manage the clipping stack as WebKit does. In fact, canvas code might not ever bother to pop the clipping stack. So, for canvas, we still use immediate, 1-bit clipping.", so it sounds like it's not compatible with how people currently use canvas, and anyway it's described as "a hack" and "falling apart" so it doesn't sound like an ideal model |
| 15:40 | StoneCypher | sighs |
| 15:40 | <StoneCypher> | Philip`, that's why i gave you that post |
| 15:41 | <StoneCypher> | was to show that layer clipping was indeed a valid case, which is what you had just said was not |
| 15:41 | <StoneCypher> | honestly i just wanted to know if anyone knew of a way to deal with this |
| 15:41 | <StoneCypher> | not to get into a series of mutually incompatible excuses for it being broken |
| 15:42 | <StoneCypher> | and for all of your discussions of how angry or upset you imagine i am, what you're actually misreading is frustration at people's rush to say things that have nothing to do with what i'm actually asking, which distracts from that i have a practical problem and someone in here may already have dealt with it |
| 15:42 | <StoneCypher> | there was someone trying to help at one point |
| 15:43 | <StoneCypher> | please stop bikeshedding so that that may return, thank you |
| 15:43 | <jgraham> | StoneCypher: If you can suggest a backwards-compatble fix for the problem, please propose it on the maioling list along with your use case |
| 15:43 | <StoneCypher> | jgraham: backwards compatible is probably not possible |
| 15:43 | <StoneCypher> | but there may be something in place already |
| 15:44 | Philip` | was mostly just wanting to learn what ways the problem could be solved in, and whether any would be feasible to fit into the current canvas compatibility constraints |
| 15:44 | <StoneCypher> | well |
| 15:44 | <StoneCypher> | the general hacks to dealing with something like this are to expand the polygons (not possible for me) or to scale the canvas, render at a higher scale, then scale back down (doesn't fix the problem entirely, and very cpu expensive) |
| 15:45 | <StoneCypher> | actually |
| 15:45 | <StoneCypher> | there is a reasonable backwards compatible fix |
| 15:46 | <Philip`> | I guess you'd also want to disable the standard antialiasing when drawing at the higher scale (else you'll still get the seams)? |
| 15:46 | <StoneCypher> | just add a way to lock the canvas against geometric writes which either flushes on first non-geometric write or call |
| 15:46 | <StoneCypher> | that way the geometries can be applied at once and the only problem is getting the user to write their shared seams in a single batch |
| 15:46 | <StoneCypher> | still causes problems if you have composite layering |
| 15:47 | <StoneCypher> | but it's a hell of a lot better than nothing |
| 15:53 | <StoneCypher> | oh, huh |
| 15:54 | <StoneCypher> | actually that might already exist |
| 15:54 | <StoneCypher> | it may be that you can just postpone the call to .fill() |
| 15:54 | <StoneCypher> | ... nope :) |
| 15:55 | <Velmont> | And all browsers behave like that? |
| 15:55 | <StoneCypher> | there's a hack that works with three of the five |
| 15:55 | <StoneCypher> | but yes, without the hack, they all show the seams at varying levels |
| 15:56 | <Velmont> | I mean with the posponing on fill. |
| 15:56 | <StoneCypher> | oh. no, that doesn't work anywhere, i was just wrong |
| 15:57 | <Velmont> | OK. -- I might've thought someone had written it like that. It looked like a possible way to implement it. |
| 15:58 | <StoneCypher> | well it would be a smart way to write it |
| 15:58 | <StoneCypher> | and this makes it look like that's sane: https://developer.mozilla.org/samples/canvas-tutorial/6_1_canvas_composite.html |
| 16:05 | <StoneCypher> | i guess another sane way to fix this that would be ... not backwards compatible but backwards tolerant |
| 16:05 | <StoneCypher> | would be to make a new context type |
| 16:05 | <StoneCypher> | 2d-procedural |
| 16:05 | <StoneCypher> | or something like that |
| 16:06 | <StoneCypher> | Velmont: would that be sufficient? 'cause that way nothing existing would break, and things could be adapted to the improved way with nearly zero effort |
| 16:10 | <jgraham> | I think you would need some major wins to get people on board with an entire new model |
| 16:11 | <jgraham> | Basically you woudl have to justify the cost of pulling people who would otherwise be working on, say, WebGL and making htem reimplement 2D canvas instead |
| 16:11 | <jgraham> | Plus the cost of retraining authors |
| 16:11 | <jgraham> | Plus the confusion |
| 16:18 | <Velmont> | It's sad that we didn't have it earlier. Having looked at it, I find the way the canvas model works now very strange and counterintuitive to how I thought it did. |
| 16:20 | <annevk> | damn it |
| 16:20 | <annevk> | forgot eggs amid all the yoghurt |
| 16:20 | <Velmont> | Getting a whole new context type will be seen as a quite intrusive and big thing, -- so I guess it'd meet a lot of opposition. Not that I know much about it. |
| 16:20 | <Velmont> | annevk: wth are you really doing? :P |
| 16:21 | <jgraham> | annevk: Did you remember tomatoes? |
| 16:21 | <annevk> | man, I fail at grocery shopping, does not get much sadder than that |
| 16:21 | <annevk> | I have some tomatoes |
| 16:21 | <annevk> | even onions |
| 16:21 | <jgraham> | Are they in the fridge? |
| 16:21 | <jgraham> | (the tomatoes) |
| 16:21 | <annevk> | tomatoes yes, onions no? |
| 16:22 | <jgraham> | Oh, you fail at storing tomatoes too then |
| 16:22 | <jgraham> | (it's OK I get that wrong quite often too) |
| 16:22 | <annevk> | they're the tiny tomatoes |
| 16:22 | <annevk> | man nobody ever taught me this stuff :) |
| 16:23 | <jgraham> | apparently the low fridge temperatures aren't good for the flavour-releasing compunds in the tomatoes |
| 16:23 | <jgraham> | No, I learnt this quite recently |
| 16:23 | <jgraham> | Which is why I still get it wrong quite often; habit |
| 16:23 | <StoneCypher> | jgraham: it wouldn't be an entire new model |
| 16:24 | <StoneCypher> | jgraham: it would just be adding two small concepts: delayed rendering of geometric primitives and a slight variant on the string used to get the context (which is how context is already meant to work) |
| 16:24 | <StoneCypher> | the only reason to do it at all is that the required change is not strictly backwards compatible |
| 16:24 | <jgraham> | StoneCypher: Could it be a mode on the existing context? |
| 16:24 | <jgraham> | Could we smuggle it in with path objects somehow? |
| 16:24 | <StoneCypher> | i don't know what a path object is. |
| 16:25 | <jgraham> | Is there a more creative solution? |
| 16:25 | <StoneCypher> | one, but it's not perfect |
| 16:25 | <StoneCypher> | what's a path object |
| 16:25 | <StoneCypher> | that might be a good answer |
| 16:25 | <jgraham> | They will be objects representing paths |
| 16:25 | <annevk> | jgraham: I'm taking out the tomatoes |
| 16:25 | <StoneCypher> | jgraham: beginPath, lineTo, closePath? |
| 16:27 | <jgraham> | StoneCypher: I am not entirely sure how it will work |
| 16:27 | <jgraham> | annevk might know better |
| 16:27 | <jgraham> | or Hixie |
| 16:27 | <annevk> | new Path() |
| 16:28 | <annevk> | then you have some methods on the Path() object to describe the path |
| 16:28 | <StoneCypher> | jgraham: i mean the change i'm considering is simple. instead of .getContext('2d'), .getContext('2d-delayed'), then add two methods, .setDelayedFill(boolean) and .fillNow() |
| 16:28 | <StoneCypher> | or whatever |
| 16:28 | <annevk> | then you invoke fill(path) or some such |
| 16:28 | annevk | forgot the details |
| 16:28 | <StoneCypher> | oh. |
| 16:28 | <jgraham> | If you have path objects you can delay the rendering, right? |
| 16:28 | <StoneCypher> | well that, if you could fill multiple at once, would be enough |
| 16:28 | <StoneCypher> | jgraham: well you need that, but you also need the ability to fill a batch instead of a single object |
| 16:29 | <StoneCypher> | if there was canvasContext.fillMany(Array) |
| 16:29 | <StoneCypher> | that'd do the job |
| 16:29 | <StoneCypher> | annevk: is that sensible? |
| 16:29 | <annevk> | you should probably email the list |
| 16:29 | <jgraham> | StoneCypher: Then I suggest you mail the list |
| 16:29 | StoneCypher | is brand new to canvas |
| 16:29 | StoneCypher | will have to find the list |
| 16:29 | StoneCypher | just started learning canvas yesterday |
| 16:30 | <annevk> | I don't know man, better to email the list and add something like "Path object feedback" |
| 16:30 | StoneCypher | really wants this to be an already-solved problem that's just obscure |
| 16:30 | <annevk> | StoneCypher: http://www.whatwg.org/mailing-list#specs |
| 16:30 | <StoneCypher> | it seems like such an unlikely omission |
| 16:30 | <StoneCypher> | annevk: thanks |
| 16:30 | <annevk> | StoneCypher: if it's solved someone will point it out |
| 16:30 | <StoneCypher> | part of the reason i'm sad is Hixie usually knows exactly what i'm doing wrong |
| 16:30 | <StoneCypher> | granted it's been two years since i've needed to ask him |
| 16:31 | <StoneCypher> | but |
| 16:31 | StoneCypher | shrugs |
| 16:31 | <StoneCypher> | i'll get like three words into typing the question, won't have even hit return yet, and he'll answer |
| 16:32 | <StoneCypher> | oh well, maybe the mailing list has an idea :) |
| 16:32 | <StoneCypher> | annevk, jgraham, Velmont: do you see any immediate problems with a batch fill call for multiple path objects? |
| 16:32 | <StoneCypher> | Philip` too |
| 16:32 | <StoneCypher> | and then if not, thank you each for thinking this over with me |
| 16:32 | <annevk> | no, but then Path is still theoretical :) |
| 16:32 | <StoneCypher> | oh |
| 16:33 | <annevk> | I mean it's coming soonish, but there's no spec yet |
| 16:33 | <StoneCypher> | theoretical as in "this might exist" or theoretical as in "this will exist in the future" |
| 16:33 | <StoneCypher> | ah. |
| 16:33 | StoneCypher | really wanted this to work in chrome, because chrome's canvas is like 8x faster than the other browsers :( |
| 16:35 | <StoneCypher> | ok, i'm'a go have lunch and see if i can think of a way through this. |
| 16:35 | <StoneCypher> | thanks each |
| 16:35 | <AryehGregor> | MikeSmith, they're not nearly as complete or correct as I'd like, but yeah, I have some. E.g., http://w3c-test.org/webapps/DOMCore/tests/approved/interfaces.html |
| 16:36 | <StoneCypher> | ooh. |
| 16:36 | <StoneCypher> | can tests be donated to that? |
| 16:36 | <annevk> | yes |
| 16:36 | <StoneCypher> | :D |
| 16:36 | <StoneCypher> | how please? |
| 16:36 | <MikeSmith> | AryehGregor: excellent, thanks |
| 16:36 | <annevk> | StoneCypher: http://lists.w3.org/Archives/Public/public-webapps-testsuite/ |
| 16:37 | <annevk> | StoneCypher: i.e. upload them somewhere (using the same testharness framework) and point them out on the list, or attach them to your email or some such |
| 16:37 | <StoneCypher> | it may be productive to set up a dvcs for that, so that people can donate tests more trivially (pull request in git terminology) |
| 16:37 | <annevk> | StoneCypher: they're in dvcs |
| 16:37 | <StoneCypher> | orly. are pull requests (or equivalent) a valid donation method? |
| 16:37 | <annevk> | StoneCypher: http://dvcs.w3.org/hg/webapps/ iirc |
| 16:38 | <annevk> | http://dvcs.w3.org/hg/webapps/file/tip/DOMCore/tests |
| 16:38 | <jgraham> | We haven't got them on github yet |
| 16:38 | <StoneCypher> | :D :D :D |
| 16:38 | <jgraham> | We probably should |
| 16:38 | <StoneCypher> | i would think github a great idea, just because it lowers the conceptual barrier to entry for so many people |
| 16:38 | <StoneCypher> | even though it's functionally equivalent |
| 16:39 | <annevk> | yeah, we should move all specs there too |
| 16:39 | <StoneCypher> | anyway, lunch and think-time |
| 16:39 | <StoneCypher> | bbl |
| 16:39 | <annevk> | kind of annoying as the W3C is using Mercurial at the moment |
| 16:39 | <annevk> | but it can be solved somehow |
| 16:39 | <MikeSmith> | we can easily mirror repos to git |
| 16:39 | <MikeSmith> | at github or wherever else |
| 16:39 | <jgraham> | For some value of easilly |
| 16:39 | <MikeSmith> | well, I can do it |
| 16:40 | <MikeSmith> | so that by definition means it's easy |
| 16:40 | <annevk> | MikeSmith: sweet |
| 16:40 | <jgraham> | But really if we are using github, we want to be able to accept pull requests |
| 16:40 | <MikeSmith> | yeah |
| 16:40 | <MikeSmith> | can do it both ways |
| 16:40 | <jgraham> | And afaict that is the point at which it all goes to hell |
| 16:40 | <annevk> | I have to go for a bit, but I'm definitely interested in working on this |
| 16:40 | <jgraham> | MikeSmith: Can one pull to a non-master branch in github? |
| 16:40 | <annevk> | making it easier for people to hack on specs / tests |
| 16:41 | <MikeSmith> | well, we can push from git repo to the mercurial one |
| 16:41 | <MikeSmith> | jgraham: dunno |
| 16:41 | <jgraham> | MikeSmith: In theory, or you got it working? |
| 16:41 | <MikeSmith> | but don't know that we'd need to |
| 16:41 | <MikeSmith> | well |
| 16:41 | <MikeSmith> | in theory |
| 16:41 | <jgraham> | MikeSmith: The only functional setup I remember seeing is doublec's Mozilla one |
| 16:41 | <annevk> | specs with http://s3.amazonaws.com/github/ribbons/forkme_right_darkblue_121621.png |
| 16:42 | <jgraham> | http://www.bluishcoder.co.nz/2011/04/16/my-git-workflow-for-mozilla-development.html |
| 16:43 | <jgraham> | The noticable thing about that setup is that he *never* commits to master |
| 16:43 | <jgraham> | (in git) |
| 16:43 | <jgraham> | I know in theory hg-git allows this to work, but it seems to be fragile as hell |
| 16:44 | <jgraham> | So if the flow of patches to master is always from hg to git it is rather simple |
| 16:44 | <jgraham> | (to keep the repos in sync) |
| 16:44 | <AryehGregor> | jgraham, I'm not clear on if you want me to modify my patch and resubmit it, and if so, what changes you want. Do you want me to add protection against infinite recursion? It seems like it's not worth the added code complexity to handle it -- the caller would have to be fairly pathological to trigger it, and it would be trivially diagnosed by going into a debugger, waiting a little while, and hitting "pause". |
| 16:45 | <jgraham> | AryehGregor: I think it is OK as is |
| 16:45 | <jgraham> | Unless you can think of a design that isn't goign to cause the horrible API surface area explosion we are currently seeing |
| 16:45 | <AryehGregor> | Also: I use hg-git to convert git to hg for the editing spec repo. I just never change the hg version; I don't even pull from git to hg. I just do a fresh hg clone of the git repo when I want to publish. |
| 16:46 | <AryehGregor> | jgraham, well, we could do like Mozilla and just pare back to assert_true() and assert_equals() and let everyone use assert_true() for everything nontrivial. |
| 16:46 | <jgraham> | AryehGregor: That works as long as no one ever touches the hg version |
| 16:46 | <AryehGregor> | The problem is it doesn't print the values nicely. |
| 16:46 | <jgraham> | I assume that won't be the case here |
| 16:46 | <AryehGregor> | jgraham, yep. Fortunately, I'm the only one with commit access to my hg version. |
| 16:47 | <jgraham> | AryehGregor: Having only two functions is even worse :) |
| 16:47 | <AryehGregor> | Well then, pick your poison. |
| 16:48 | <jgraham> | Well, it feels like there exist other parts of design space that we just didn't use e.g. assert_equals(actual, expected, comparator) |
| 16:48 | <jgraham> | where comparator is a function |
| 16:48 | <AryehGregor> | In mochitests, people seem not to care much about informative error messages. They're written by and for Gecko developers, so it's assumed to be fine if you have to hunt through the source code to find the failure. |
| 16:48 | <jgraham> | and you provide some built in functions |
| 16:48 | <AryehGregor> | Well, as the saying goes: the solution to any problem in computer science is more abstraction. |
| 16:49 | <jgraham> | Well that particular solution has the nice property that assert_array_approx_equals becomes assert_array_equals(expected, actual, delta(0.01)) |
| 16:49 | <jgraham> | rather than a whole new function |
| 16:50 | <AryehGregor> | And then every call needs to have four arguments instead of three? Or you want to autodetect the number of arguments? |
| 16:50 | <AryehGregor> | If you're making an optional third argument anyway, why not make it a number for now, instead of requiring the delta()? Are there other functions we'd want just now? |
| 16:51 | <jgraham> | Well apparently you want a comparator that checks expected.indexOf(actual) != -1 |
| 16:51 | <jgraham> | So that's two plus normal comparison |
| 16:52 | <AryehGregor> | How about instead of passing a function, you just pass a boolean? |
| 16:52 | <jgraham> | I can't work out what the boolean would do :) |
| 16:52 | <AryehGregor> | So instead of assert_equals(foo, bar, function(foo,bar){return bar.indexOf(foo) != -1}, desc), just assert_equals(foo, bar, bar.indexOf(foo) != -1, desc). |
| 16:52 | <AryehGregor> | It would basically be assert_true(bar.indexOf(foo) != -1, desc). |
| 16:53 | <AryehGregor> | Except with foo and bar used in printing the message. |
| 16:53 | <jgraham> | Well the point is that you would provide the comparison functions |
| 16:53 | <AryehGregor> | Yeah, but why not just have the caller do the comparison instead of passing a function whose only role is to be called with two known arguments? |
| 16:54 | <AryehGregor> | I guess it might be shorter if the arguments are complicated. |
| 16:54 | <jgraham> | Because it means that assert_array_whatever is just a map() |
| 16:54 | <AryehGregor> | . . . and? |
| 16:55 | <jgraham> | So you don't have to implement seperate API for the object case, the array case, and the single argument case |
| 16:55 | <jgraham> | You should end up with N+M functions rather than N*M |
| 16:56 | <AryehGregor> | Is N*M functions really a problem? It's morally equivalent to passing one of the arguments as part of the function name. |
| 16:56 | <AryehGregor> | You could even autogenerate the functions if you like. |
| 16:57 | <jgraham> | Oh my, that sounds awful |
| 16:57 | <AryehGregor> | ["", "_array", "_object"].forEach(function(s) { window["assert" + s + "_equals"] = function(.... |
| 16:57 | <AryehGregor> | Well, I think we knew before now that our stylistic preferences differ. :) |
| 16:57 | <jgraham> | I agree from the end user point of view it doesn't make that much difference. Unless you want to do something more complex where I guess it could matter |
| 16:59 | <AryehGregor> | You can always fall back to assert_true(). |
| 16:59 | <jgraham> | e.g. if you had some function that could either return x in px or y in pt, instead of hardcoding x and y in an array you could pass a function that calculates y given x |
| 16:59 | <jgraham> | Of course, assert_true is always there as a last resort |
| 17:00 | <AryehGregor> | 80/20 rule -- assert_true should be fine for anything that's not particularly common. |
| 17:01 | <jgraham> | It seems somewhat bad to make the complicated cases the ones that are hardest to read and get the worst error messages |
| 17:01 | <jgraham> | Anyway I am not particularly attached to this idea |
| 17:01 | <jgraham> | Or, I wish I had used this design at the start, but I didn't |
| 17:01 | <AryehGregor> | "No consensus positions were found, and all parties left the telecon frustrated. Time estimates for finishing work on Transforms however were agreed to be within 2-3 months if appropriately prioritized. (This of course assumes future telecons are dedicated to making progress rather than arguing process.)" |
| 17:01 | <AryehGregor> | That sounds like the CSSWG, all right. |
| 17:02 | <jgraham> | So, no transforms for > 3 months then |
| 17:03 | <AryehGregor> | No unprefixed transforms. |
| 17:03 | <AryehGregor> | Which is ridiculous. |
| 17:04 | <AryehGregor> | Since the syntax has been completely stable for like a year. |
| 17:04 | <AryehGregor> | Interop is sure a heck of a lot better than, say, CSSOM. |
| 17:06 | <othermaciej> | I'm surprised that some of the people who opposed unprefixing transforms were also among those who said they thought they may need to implement widely used -webkit properties in a non-WebKit engine |
| 17:06 | <othermaciej> | it goes to show how much faith there is in the "unprefix at CR" rule, even though it is pretty arbitrary |
| 17:10 | <jgraham> | othermaciej: Only Sylvian or am I misreading? |
| 17:11 | <othermaciej> | I guess it was hard to follow who else was opposed |
| 17:11 | <othermaciej> | fwiw I think "drop prefix once syntax is stable enough for backwards compat" is a much more sensible rule than "drop prefix after entering CR", both in general and in this specific case |
| 17:12 | <othermaciej> | not sure if it is worth posting to www-style since I am not technically a CSS WG member |
| 17:13 | jgraham | predicts you would be told that CR is the point at which "syntax is stable enough for backwards compat" |
| 17:16 | <wilhelm_> | Are minutes available anywhere? |
| 17:19 | <othermaciej> | jgraham: given that specs sometimes drop out of CR and then completely change syntax or even drop whole properties, I think that is demonstrably not the case |
| 17:22 | <annevk> | when two vendors ship, you better get your story straight or just spec what they do |
| 17:22 | <jgraham> | othermaciej: Given that I think the whole Process is a work of fiction, I'm not going to disagree. |
| 17:26 | <MikeSmith> | http://www.w3.org/News/2012.html#entry-9363 |
| 17:26 | <annevk> | http://www.w3.org/2002/ws/soapjms/ o_O |
| 17:27 | <jgraham> | Funny how SOAP makes you feel dirty |
| 18:34 | <StoneCypher> | [11:42] <jgraham> MikeSmith: The only functional setup I remember seeing is doublec's Mozilla one |
| 18:34 | <StoneCypher> | doublec plays here? |
| 18:34 | <StoneCypher> | i haven't talked to chris in ages |
| 18:42 | <gsnedders> | http://googlecode.blogspot.com/2012/02/tech-preview-of-chromium-with-dart.html |
| 18:50 | <bga> | good news |
| 18:50 | <smaug____> | sad |
| 19:01 | <TabAtkins> | othermaciej: Sylvain's precise position was, apparently, that he supported implementing the *non-standard* (but widely-used) -webkit things, but he didn't support recognizing the -webkit prefix on existing standardized properties. |
| 19:01 | <TabAtkins> | This was not communicated clearly during the meeting, but came out during the telcon yesterday. |
| 19:01 | <othermaciej> | does that mean they'd delete support for -webkit things as soon as someone writes an Editor's Draft? |
| 19:01 | <TabAtkins> | I don't know. |
| 19:02 | <othermaciej> | it sounds suspiciously like "I support a rule that coincidentally matches what Microsoft cares about but not what Mozilla cares about" |
| 19:02 | <TabAtkins> | I don't fully understand Sylvain's position, just that it's at least that much delta from Tantek's. |
| 19:04 | <bga> | i wait when ms add C# as scriptling lang to ie :) |
| 19:04 | <gsnedders> | Why add a single CLR language? :P |
| 19:05 | <bga> | or whole NET, yeah |
| 19:05 | <bga> | will be cool |
| 19:05 | <TabAtkins> | AryehGregor: Please note that this was not "the CSSWG" failing. It was particular members specifically resisting. |
| 19:09 | <Philip`> | "Both the Dart VM and modern JavaScript engines are first-class targets for Dart." - I wonder if that means they won't do blog posts and press releases saying how Chrome is ten times faster than any other browser on some application that happens to be written in Dart, or if the Dart VM will instead end up being more first-class than the JS translator |
| 19:14 | <jgraham> | Philip`: You so funny |
| 19:15 | <gsnedders> | Philip`: Will you marry me, your wit never ceases to amaze? |
| 19:15 | <jgraham> | TabAtkins: You do know though; Microsoft never drop support for things that they have released |
| 19:16 | <jgraham> | Because in 20 years time some fortune 100 company will have an intranet running IE10 on Windows Vista that depends critically on -webkit-something |
| 19:16 | <TabAtkins> | Probably, yeah. |
| 19:30 | <AryehGregor> | TabAtkins, if the process of the CSSWG allows such particular members to successfully resist, the process of the CSSWG is at fault and the CSSWG as a whole is accountable (even if some individual members aren't). |
| 19:34 | <TabAtkins> | The entire point of a standards body is to find consensus between members. It can't always do so. So, we must take action as individuals. |
| 19:37 | <jgraham> | Uh, no, the point of a standards body is to create standards |
| 19:37 | <jgraham> | Consensus is just a common way to achieve that |
| 19:37 | <AryehGregor> | The entire point of a web standards body is to ensure interoperability between browsers. Browsers implementing properties with names that work only in those browsers is ipso facto a failure of standards development. |
| 19:38 | <AryehGregor> | Consensus is a lousy way to make good standards, fiat works much better. |
| 19:38 | <AryehGregor> | Or arbitration, let's say. |
| 19:38 | <jgraham> | AryehGregor++ |
| 19:38 | <AryehGregor> | An individual can make compromises much more efficiently than a group voting on something. |
| 19:39 | <AryehGregor> | The compromise should be between major implementers, without consideration for anyone else, as far as implementer requirements go. |
| 19:39 | <AryehGregor> | That's a grand total of roughly three parties, maybe four if you're generous. |
| 19:39 | <AryehGregor> | Sometimes they won't agree on anything, but then discussion usually doesn't help. Resolve the issue -- either spec something or leave it undefined, but move on. |
| 19:39 | <AryehGregor> | The CSSWG tends to rehash the same issues endlessly without making anyone happy. |
| 19:40 | <AryehGregor> | Which leads to paralysis. |
| 19:40 | <AryehGregor> | The fact that there are about a million specs written by people who don't coordinate adequately and aren't working within a well-defined framework for rendering extensions doesn't help. |
| 19:41 | <AryehGregor> | (the framework for syntax extensions is good, but not layout) |
| 19:46 | <jwalden> | discussion seemed to be smashingly successful for the video codec issue |
| 19:46 | <AryehGregor> | Right, in which case the right answer is to leave it undefined and move on. |
| 19:46 | <AryehGregor> | No point in dwelling on it. |
| 19:47 | <AryehGregor> | WebM might win in a year or two, but not because of discussion. |
| 19:51 | <doublec> | StoneCypher: hi |
| 20:25 | <TabAtkins> | The three implementors you mention are precisely the ones that aren't agreeing. Or rather, one isn't agreeing with the other two. |
| 20:29 | <AryehGregor> | In the case of prefixes, they really don't need to agree. They can just independently decide whether to unprefix. |
| 20:30 | <TabAtkins> | I agree. |
| 20:30 | <AryehGregor> | FWIW, from the vote it looked like different WebKit developers had different opinions, so not sure what side you count them as. |
| 20:30 | <TabAtkins> | Apple was on one side, Chrome was on the other. |
| 20:36 | <jgraham> | wrt prefixes the problem is exactly that the standards goup is rying to maintain a highly unstable equlibrium |
| 20:36 | <AryehGregor> | So Mozilla and Google should unprefix, Microsoft and Apple don't have to if they don't want to. Problem solved. |
| 20:36 | <jgraham> | *group |
| 20:36 | <Wilto> | Woah, I showed up just in time. Everything is solved forever! |
| 20:44 | <jgraham> | Wilto: Not everything maybe. But I am getting the experience of being the choir whilst AryehGregor preaches. And given my horrible singing voice and general tone-deafness, being in a choir is a new experience for me! |
| 20:44 | AryehGregor | is also not particularly musical :( |
| 20:44 | <Wilto> | I’ve just resolved not to use the internet anymore, me. PROBLEM(S) SOLVED |
| 20:46 | <gsnedders> | AryehGregor: You should do a sing-along Sound of Music! |
| 20:46 | gsnedders | hides from jgraham |
| 20:47 | <Wilto> | The hills are alive with the sound of markup. |
| 20:55 | <TabAtkins> | AryehGregor: Any idea what the interop story is for Transitions/Animations? |
| 20:55 | <AryehGregor> | TabAtkins, not a clue. |
| 20:55 | <AryehGregor> | I'm just starting to poke at tests. |
| 20:58 | <TabAtkins> | kk. |
| 20:58 | <TabAtkins> | Also, <3 for your testing. |
| 21:01 | AryehGregor | is currently working on porting a Gecko transition test file to be cross-browser and based on testharness.js |
| 21:06 | <AryehGregor> | Transitions are complicated. I don't like them. :( |
| 21:06 | <AryehGregor> | Transforms are simple. :) |
| 21:06 | <TabAtkins> | Learn to love the third dimension of time. |
| 21:07 | <AryehGregor> | Transforms already have four dimensions. |
| 21:07 | <AryehGregor> | Without time. |
| 21:07 | <TabAtkins> | Four? |
| 21:07 | <AryehGregor> | Well, kind of. |
| 21:07 | <AryehGregor> | I mean, matrix3d() is 4x4. |
| 21:07 | <AryehGregor> | The fourth coordinate isn't spatial or temporal, but it's there. |
| 21:07 | <TabAtkins> | But it has 3d in its name! |
| 21:07 | <TabAtkins> | QED |
| 21:08 | <AryehGregor> | Admittedly, it's a representation of something resembling three-dimensional projective space with four coordinates, so there are really only three *dimensions*. |
| 21:08 | <AryehGregor> | (it's not quite regular old projective space) |
| 21:08 | <AryehGregor> | (it has an origin, and (x, y, z, w) !~ (-x, -y, -z, -w)) |
| 21:26 | jgraham | wonders what !~ is |
| 21:26 | <AryehGregor> | "not equivalent" |
| 21:27 | <jgraham> | Ah |
| 21:27 | <jgraham> | That makes more sense than "no of the same order of magnitude as" :) |
| 21:27 | <AryehGregor> | In projective space, one normally says that (x1, ..., xn) ~ (y1, ..., yn) if there exists some nonzero t so that (t*x1, ..., t*xn) = (y1, ...., yn). |
| 21:27 | <AryehGregor> | In 3D transform space, it seems like this only holds for positive t, not nonzero t. |
| 21:28 | <jgraham> | I imagine there is some great reason one has 4 coordinates to describe 3 dimensions, but I have no idea what it is |
| 21:28 | <AryehGregor> | P^(n - 1)(R) is defined as (R^n \ {0})/~ for the above ~. |
| 21:28 | <AryehGregor> | Perspective, basically. |
| 21:28 | <AryehGregor> | It's a clever trick. |
| 21:36 | AryehGregor | wonders why people mistype his name as Areyeh |
| 21:36 | <AryehGregor> | More than a few people have done that. |
| 21:36 | <AryehGregor> | Why that specific misspelling? |
| 21:38 | <StoneCypher> | it's just another english transliteration |
| 21:38 | <StoneCypher> | also it's phonetically how an american would spell that sound |
| 22:03 | <karlcow> | MikeSmith: for http://platform.html5.org/history/ do you consider SVG 1.0 be part of it? http://www.w3.org/TR/SVG10/ |
| 22:04 | <heycam> | depends what "new" means |
| 22:04 | <shepazu> | depends what "means" means |
| 22:05 | <MikeSmith> | karlcow: really so far I've only been adding milestones from WF2 and Web Apps 1.0 |
| 22:05 | <karlcow> | depends depends |
| 22:05 | <MikeSmith> | I've not even added any CSS3 stuff |
| 22:05 | <karlcow> | ok MikeSmith I was not sure about the scope of the list |
| 22:05 | <MikeSmith> | I think I will leave those to somebody else who knows that history better |
| 22:07 | <shepazu> | MikeSmith: who maintains http://platform.html5.org/ ? |
| 22:10 | <annevk> | http://imgur.com/urWHb man |
| 22:10 | <annevk> | now that's a cool suit to have |
| 22:11 | <StoneCypher> | is that a miyazaki creature? |
| 22:11 | <StoneCypher> | that looks like it belongs in totoro or something |
| 22:12 | <annevk> | that is Totoro |
| 22:12 | <StoneCypher> | oh. |
| 22:12 | <StoneCypher> | see 'cause i haven't actually seen totoro, only posters |
| 22:12 | <StoneCypher> | huhuhu |
| 22:12 | <annevk> | worth watching |
| 22:12 | <StoneCypher> | yeah i just haven't gotten around to it, i've seen most of his other work |
| 22:12 | <StoneCypher> | adore mononoke hime |
| 22:12 | <StoneCypher> | and nausicaa |
| 22:13 | <annevk> | nausicaa is cool |
| 22:13 | <annevk> | I really liked that one |
| 22:14 | <Velmont> | <3 |
| 22:14 | <StoneCypher> | kiki might be my favorite |
| 22:14 | <shepazu> | nausicaa was the first miyazaki I ever saw, back when I was a kid, before I had any idea what anime was (it hadn't really reached the US yet) |
| 22:14 | <StoneCypher> | i cut my teeth on speed racer |
| 22:14 | <shepazu> | that sounds painful :) |
| 22:14 | <MikeSmith> | shepazu: the community maintains it |
| 22:14 | <StoneCypher> | then manzinger z, voltron and lupin the 3rd |
| 22:15 | <Velmont> | annevk: My gf have been making clothes for herself the last week (I got her, finally, after 3 years og nagging, a sewing machine). So when she saw me laughing at something, and looking at my screen, she said she could make me a suit like that :P |
| 22:15 | <annevk> | don't say no |
| 22:17 | <annevk> | in other news, DOM4 has mutation listener stuff embedded |
| 22:17 | <annevk> | first draft |
| 22:17 | <annevk> | euh mutation observer |
| 22:17 | <TabAtkins> | yay! |
| 22:17 | <smaug____> | reviewing needed :) |
| 22:17 | <smaug____> | callback is wrong... |
| 22:18 | smaug____ | should file bugs |
| 22:18 | <annevk> | callback is right |
| 22:18 | <smaug____> | it is wrong :) |
| 22:18 | <smaug____> | it has never been right in the D4 draft |
| 22:19 | <annevk> | what exactly is wrong then? |
| 22:20 | <smaug____> | let me find the right syntax... |
| 22:20 | <smaug____> | it should allow { handleMutation: function() {} } |
| 22:20 | <annevk> | no it shouldn't |
| 22:20 | <annevk> | we had a long discussion on that |
| 22:20 | <annevk> | so yeah, not a bug |
| 22:21 | <smaug____> | I haven't seen such discussion about mutationcallback |
| 22:21 | <smaug____> | anyway, I'll implement { handleMutations: function() {} } :) |
| 22:21 | <TabAtkins> | It would be awesome if you didn't make unilateral changes in your impl that no one else wants. |
| 22:23 | <smaug____> | it would be awesome if specs wouldn't make the web APIs more inconsistent |
| 22:23 | <annevk> | pretty sure sicking won't allow it |
| 22:23 | <TabAtkins> | { handleMutations: ... } isn't consistent anyway. If you're making that argument, implement as { handleEvent: ... } |
| 22:24 | <smaug____> | handleEvent doesn't make any sense |
| 22:24 | <TabAtkins> | +1 |
| 22:24 | sicking | agrees with smaug |
| 22:24 | <sicking> | i think it should be onmutation |
| 22:26 | <jgraham> | oh, please not this again |
| 22:45 | <sicking> | i do however think it's more important to make an API good, than to make it consistent with existing stuff |
| 22:45 | <sicking> | especially since we hear nothing but complaints about how much the DOM sucks |
| 23:45 | <annevk> | le sigh |
| 23:51 | <MikeSmith> | le un atre shitstorm |
