| 00:05 | <dbaron> | TabAtkins, so by "concrete object" do you mean "box" or do you mean something else? |
| 00:05 | <dbaron> | TabAtkins, I was assuming you meant "box". |
| 00:05 | dbaron | is wondering whether to introduce cement objects and bricks |
| 00:06 | <jcranmer> | cinder blocks |
| 00:12 | <dbaron> | I should probably just unsubscribe from www-style. |
| 00:12 | <dbaron> | It's full of people arguing about things that nobody's even said or written down anywhere. |
| 00:25 | <roc> | just be selective about which threads you read |
| 00:54 | <rniwa> | sicking: yt? |
| 00:59 | <sicking> | rniwa: pong |
| 01:01 | <rniwa> | sicking: hi |
| 01:01 | <rniwa> | sicking: do you have a time now? |
| 01:01 | <sicking> | rniwa: just about to head into a meeting, shouldn't be more than an hour, will you still be around? |
| 01:02 | <rniwa> | sicking: oh sure |
| 01:02 | <rniwa> | sicking: I'll probably be around 'til 6:30 |
| 01:02 | <rniwa> | sicking: if not 7 |
| 01:02 | <sicking> | cool |
| 01:02 | <sicking> | ping me at 6 if i haven't pinged you already |
| 01:02 | <rniwa> | sicking: ok |
| 01:32 | <sicking> | rniwa: back |
| 01:32 | <rniwa> | sicking: hi |
| 01:32 | <rniwa> | sicking: so I was sort of looking at the big picture of undoManager |
| 01:33 | <rniwa> | sicking: and I've started to think that maybe we've taken a wrong path in certain things |
| 01:33 | <sicking> | rniwa: oh? |
| 01:33 | <rniwa> | sicking: right now, we're going to have undoManger.automaticTransact and undoManager.manualTransact, right? |
| 01:33 | <rniwa> | sicking: and then we'll have two separate interfaces for those objects |
| 01:33 | <sicking> | yup |
| 01:34 | <sicking> | sort of |
| 01:34 | <rniwa> | sicking: but then, we'll need to expose those in [] |
| 01:34 | <sicking> | i don't actually know that we need real interfaces |
| 01:34 | <rniwa> | sicking: that would mean that the return value of [] would either be Object |
| 01:34 | <sicking> | they're more like pure JS-objects |
| 01:34 | <rniwa> | sicking: or we have to define some AbstractInterface for it |
| 01:34 | <sicking> | rniwa: oh |
| 01:35 | <sicking> | rniwa: i think it's fine to use Object. If we indeed even are going to use interfaces here at all |
| 01:35 | <rniwa> | sicking: but this would really ingrains the concept of automatic/manual transaction into undomnager |
| 01:35 | <rniwa> | sicking: in the sense, undo manager needs to know all |
| 01:35 | <rniwa> | sicking: in my original proposal, I tried to de-couple those concepts so that undomanager doesn't need to know anything about automatic transaction |
| 01:36 | <rniwa> | sicking: undomanager would just call apply, unapply, reapply |
| 01:36 | <rniwa> | sicking: which is nice from implementor's perspective |
| 01:36 | <sicking> | rniwa: hmm |
| 01:36 | <rniwa> | sicking: with current approach, we have to end up adding bindings for undoManger.automaticTransact and undoManager.manualTransact and then share code somehow |
| 01:36 | <rniwa> | sicking: because most of steps in those are identically equal |
| 01:36 | <sicking> | rniwa: i don't really care what's nice from an implementation perspective though. It's much more important to have a good API |
| 01:37 | <sicking> | rniwa: to a certain extent of course, it shouldn't be completely insane to implement |
| 01:37 | <rniwa> | sicking: in the sense the only difference between automaticTransact and manualTransact is how it calls apply |
| 01:37 | <rniwa> | sicking: or what object it takes |
| 01:38 | <rniwa> | sicking: so I've started to think that it might be better to provide an API that creates automatic transaction instead |
| 01:38 | <rniwa> | sicking: i.e. we'll have createAutomaticTransaction function or just new AutomaticTransaction |
| 01:38 | <rniwa> | sicking: that'll create an object with unapply/reapply functions given apply function |
| 01:38 | <rniwa> | (function names are pending) |
| 01:39 | <rniwa> | sicking: this would allow us to have simple transact function again |
| 01:39 | <sicking> | rniwa: is there a reason to do this other than save a few lines of code in the implementation? |
| 01:39 | <rniwa> | sicking: I think this makes the interface conceptually simpler |
| 01:39 | <sicking> | rniwa: i think it's much more important to look at what's a good API from a usability point of view first |
| 01:39 | <rniwa> | sicking: because all transactions are just transactions |
| 01:40 | <sicking> | rniwa: what happens if someone calls reapply multiple times in a row on a automatic transaction? |
| 01:40 | <sicking> | rniwa: or unapply and then apply? |
| 01:41 | <sicking> | rniwa: hmm.. actually |
| 01:41 | <rniwa> | sicking: I guess it could ignore subsequence calls |
| 01:42 | <sicking> | rniwa: so how would this work, would createAutomaticTransaction run the "execution function"? |
| 01:42 | <rniwa> | sicking: no, it'll just create a transaction object |
| 01:43 | <rniwa> | sicking: e.g. you do undoManager.transact(createAutomaticTransaction(myCommand, 'typing')) |
| 01:43 | <rniwa> | sicking: in some sense, automaticTransact is a syntactic sugar for this |
| 01:43 | <rniwa> | sicking: but I found that having one function for doing things is better than having two |
| 01:44 | <sicking> | rniwa: from an implementation point of view, or from a usability point of view? |
| 01:44 | <rniwa> | sicking: e.g. this would allow author's script to pass transactions around |
| 01:44 | <rniwa> | sicking: from author's point of view as well |
| 01:44 | <rniwa> | sicking: so in the current design, you need to know whether you're creating an automatic transaction or manual transaction |
| 01:44 | <rniwa> | sicking: if you've just got a transaction object from some helper function |
| 01:44 | <rniwa> | sicking: e.g. |
| 01:45 | <rniwa> | sicking: var transaction = createMyTransaction(...); |
| 01:45 | <sicking> | that makes some sense i agree |
| 01:45 | <rniwa> | sicking: and then I wouldn't know whether I should call automaticTransact or manualTransact |
| 01:45 | <sicking> | right |
| 01:45 | <rniwa> | sicking: if we have createAutomaticTransaction, then we can always call transact |
| 01:46 | <sicking> | rniwa: still is a lot to type every time you create a automatic transaction though :( |
| 01:46 | <rniwa> | sicking: yeah, that's one drawback |
| 01:46 | <sicking> | rniwa: i wonder if we can also add a helper function that does the work for you |
| 01:46 | <rniwa> | sicking: also it's harder to add properties in this syntax |
| 01:46 | <sicking> | rniwa: that's a good point |
| 01:46 | <sicking> | very good even |
| 01:47 | <rniwa> | sicking: yeah so I'm not sure which way is better at this point |
| 01:47 | <sicking> | rniwa: i think we can help with the typing by creating a helper function |
| 01:47 | <sicking> | rniwa: but the properties part is worse |
| 01:47 | <rniwa> | sicking: right. |
| 01:47 | <rniwa> | sicking: so one thing I was thinking is that we can make createAutomaticTransaction take some object |
| 01:47 | <rniwa> | sicking: and let the resultant transaction object retrieve all properties the original object had |
| 01:48 | <rniwa> | sicking: but that's a very strange object |
| 01:48 | <sicking> | rniwa: i.e. we can add a function like addAutomatic(func) { return this.transact(createAutomaticTransaction(func)) } to the interface |
| 01:48 | <rniwa> | sicking: yeah |
| 01:48 | <sicking> | rniwa: that sounds hacky |
| 01:48 | <sicking> | (the automatic copying that is) |
| 01:48 | <rniwa> | sicking: but I'm suspecting that many use cases of automatic transaction doesn't require adding new properties |
| 01:48 | <sicking> | rniwa: you'll loose things like the prototype chain |
| 01:48 | <rniwa> | sicking: right |
| 01:49 | <sicking> | rniwa: which i believe Alex Russel really wants to use to be able to do things like manager.transact(new MyOwnTransactionClass(...)); |
| 01:49 | <rniwa> | sicking: on the other hand, we could have createAutomaticTransaction just add/assign unapply/reapply properties |
| 01:49 | <rniwa> | sicking: instead of creating of new object |
| 01:49 | <rniwa> | creating new |
| 01:50 | <rniwa> | sicking: yeah, that'll nice |
| 01:50 | <rniwa> | 'll be* nice |
| 01:50 | <sicking> | having the DOM monkey-patch your objects seems somewhat unfortunate |
| 01:51 | <rniwa> | sicking: so if we'll have createAutomaticTransaction(x)=x but x will get extra properties |
| 01:51 | <rniwa> | sicking: yeah |
| 01:51 | <rniwa> | sicking: it's not particularly clean either |
| 01:51 | <rniwa> | sicking: alternatively, we could add "automatic" boolean to transaction object |
| 01:51 | <rniwa> | sicking: so instead of having two methods |
| 01:51 | <rniwa> | sicking: we'll just have a boolean that determines whether it's automatic or not |
| 01:52 | <rniwa> | sicking: in the object itself |
| 01:52 | <sicking> | rniwa: yeah, that seems ok |
| 01:52 | <sicking> | rniwa: i do like the idea of being able to return a transaction |
| 01:52 | <rniwa> | sicking: yeah |
| 01:52 | <sicking> | rniwa: but i *really* liked the syntax you guys had in your original email that came up with the transaction objects as they are now |
| 01:52 | <rniwa> | sicking: so we'll have undoManager.transact({apply:~~, automatic:true}) |
| 01:53 | <rniwa> | sicking: which one? |
| 01:53 | <sicking> | rniwa: the one that introduced the syntax as it is now |
| 01:53 | <rniwa> | sicking: oh undoManager.transact({apply:~~, automatic:true}) ? |
| 01:54 | <sicking> | nono, much much earlier |
| 01:54 | <sicking> | nevermind, i think our irc'ing just crossed paths :) |
| 01:54 | <sicking> | rniwa: i like the automatic:true idea |
| 01:55 | <sicking> | rniwa: that seems like it would take care of the original use case |
| 01:55 | <rniwa> | sicking: mn... like undoManager.transact(new ManagedTransaction(...)) ? |
| 01:56 | <sicking> | you just lost me :) |
| 01:57 | <rniwa> | sicking: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-August/032766.html ? |
| 01:57 | <rniwa> | sicking: ok |
| 01:58 | <sicking> | rniwa: what I'm saying is that the undoManager.transact({ apply: ..., automatic: true }) seems to solve the use case of having code like: transact = someFunctionThatGeneratesTransactions(); undoManager.transact(transact); |
| 01:58 | <rniwa> | sicking: yeah |
| 01:58 | <rniwa> | sicking: ok, I'll post something up on whatwg and make this change subsequently |
| 01:58 | <rniwa> | sicking: this will lets us just have one implicit interface |
| 01:58 | <rniwa> | sicking: and one transact |
| 01:58 | <rniwa> | :D |
| 01:59 | <sicking> | rniwa: yup. Might be good to come up with something shorter than "automatic" though. Maybe just "auto"? |
| 01:59 | <sicking> | i'll leave the bikeshedding to others :) |
| 01:59 | <rniwa> | sicking: yeah, auto works |
| 01:59 | <sicking> | rniwa: also, i'm still not sold on apply+reapply. I still think just apply is better :) |
| 01:59 | <sicking> | with a boolean argument |
| 02:00 | <rniwa> | sicking: hmm.... I still make the same argument AryehGregor made and say booleans are bad |
| 02:00 | <rniwa> | sicking: I find a function that does both do & undo to be semantically hard to understand |
| 02:01 | <rniwa> | sicking: unfortunately, there are no good precedents for this because most of Undo API just provide functions for undo/redo |
| 02:01 | <rniwa> | sicking: and not the initial execution |
| 02:01 | <sicking> | rniwa: sure, i wouldn't propose to merge do/undo |
| 02:01 | <rniwa> | sicking: oops I meant do/redo |
| 02:01 | <sicking> | rniwa: booleans are bad on the callsite generally |
| 02:01 | <rniwa> | sicking: I'm not buying the idea that developers would duplicate code |
| 02:01 | <rniwa> | sicking: when he can just call apply |
| 02:01 | <sicking> | rniwa: but here the callsite is inside the browser code, so that's not a problem |
| 02:02 | <sicking> | rniwa: but he can't call apply, you brought up good reasons for why they should be slightly different |
| 02:02 | <rniwa> | sicking: also arv made an argument that booleans are hard to remember which one is which |
| 02:02 | <sicking> | rniwa: again, that's generally true on the caller side, not on the callee side |
| 02:02 | <rniwa> | sicking: so he can do reapply: function() { /* some work! */ this.apply(); } |
| 02:03 | <sicking> | rniwa: i don't think you can do selection like that |
| 02:03 | <sicking> | rniwa: also, look at the examples that you sent to the list, they all duplicated code |
| 02:03 | <rniwa> | sicking: or reapply: function() { this.apply(); /* some work */ } |
| 02:04 | <rniwa> | but should I define function(isApply) {...} or function(isReapply) {...}? |
| 02:05 | <sicking> | rniwa: Either way, it'll be obvious when you look at any example |
| 02:05 | <sicking> | rniwa: the problem with boolean arguments is that you can't tell on the caller side: apply(false) |
| 02:05 | <sicking> | rniwa: but on the callee side it's always documented using the variable name |
| 02:06 | <sicking> | rniwa: i'm also not convinced that the differences between apply/reapply are always so simple that you can implement them before and/or after |
| 02:06 | <rniwa> | sicking: so the argument was that it's hard to remember which boolean it was when you write the function for the first tie |
| 02:06 | <rniwa> | time* |
| 02:06 | <sicking> | though i'd have to think to come up with an example |
| 02:07 | <sicking> | rniwa: how would you do that without looking at docs or examples? |
| 02:07 | <rniwa> | sicking: well, you probably remember it was undoManager |
| 02:07 | <rniwa> | sicking: and on firebug or developer console, you can see that it has transact method |
| 02:08 | <rniwa> | sicking: and maybe I'll vaguely remember it takes apply function |
| 02:08 | <zewt> | if that's a person's way of learning an api, they're going to get confused no matter what the type of the argument :) |
| 02:08 | <rniwa> | zewt: well, I almost always use developer tools to figure out property names, etc... |
| 02:08 | <rniwa> | zewt: too lazy to search |
| 02:09 | <rniwa> | zewt: most of the times, properties I find do what their name suggest to do |
| 02:09 | <rniwa> | anyways |
| 02:09 | <zewt> | seems like a strange reason to abolish bools, heh |
| 02:09 | <rniwa> | zewt: I guess |
| 02:10 | <zewt> | if there was more info to send i'd suggest passing an object, like events, but that's a bit overkill if that's all there is |
| 02:10 | <sicking> | rniwa: i'm not convinced that it'll be easier to remember that there's both a "apply" and a "reapply" function, than to remember that it takes a isReapply boolean argument |
| 02:11 | <rniwa> | sicking: I've talked to a couple of developers internally and they told me they'd prefer apply/reapply simply because they don't like booleans |
| 02:11 | <rniwa> | sicking: but then they also told me they'll be fine with booleans |
| 02:11 | <zewt> | if an api made me provide two separate functions that are very similar, i'm pretty sure i'd quick patch it away so i don't have to deal with that |
| 02:12 | <zewt> | (i havn't looked closely enough to know why "apply" and "reapply" are separate concepts, though) |
| 02:12 | <rniwa> | zewt: if you don't supply reapply, it falls back to apply |
| 02:12 | <zewt> | ah |
| 02:12 | <rniwa> | zewt: apply is called when you call undoManager.transact |
| 02:12 | <jamesr_> | how's that better than having a bool? if authors forget about reapply, in both cases their apply() function is called |
| 02:12 | <rniwa> | zewt: reapply is called, well, when a user triggers redo |
| 02:13 | <zewt> | i guess as someone who's typed "int main(int argc, char *argv[])" a few thousand times, worrying about this seems minor :) |
| 02:13 | <rniwa> | zewt: I can never remember which comes first although I've been writing c programs over a decade |
| 02:13 | <zewt> | if i think about it i'd probably forget--i just let my fingers type it |
| 02:14 | <zewt> | digit coprocessors |
| 02:14 | <rniwa> | mn.. maybe I'll like it better if we renamed apply/reapply |
| 02:14 | <rniwa> | sicking: how about executeDo and executeUndo? |
| 02:15 | <rniwa> | sicking: or execute and executeUndo? |
| 02:15 | <sicking> | rniwa: i like apply/unapply/reapply better |
| 02:15 | <rniwa> | sicking: ? |
| 02:15 | <rniwa> | sicking: you like apply/unapply better? |
| 02:15 | <sicking> | rniwa: the names that is |
| 02:15 | <rniwa> | sicking: I think the problem is that apply appears to indicate that it's only called for the first time |
| 02:16 | <sicking> | rniwa: oh, i see |
| 02:16 | <jamesr_> | do/undo/redo? |
| 02:16 | <sicking> | rniwa: i generally try to stay out of naming issues |
| 02:16 | <rniwa> | jamesr: I think we want to get rid of redo function |
| 02:16 | <sicking> | :) |
| 02:16 | <rniwa> | jamesr: do/undo seems fine |
| 02:17 | <rniwa> | jamesr: but might be too generic? |
| 02:17 | <rniwa> | jamesr: we want to let duck type it so user may want to inherit from some other objects |
| 02:17 | <zewt> | do is a keyword :) |
| 02:17 | <rniwa> | zewt: oh that won't work :( |
| 02:17 | <sicking> | zewt: that's ok in ES5 |
| 02:17 | <sicking> | rniwa: no, that's not a problem in ES5 |
| 02:18 | <rniwa> | sicking: probably better to avoid it though |
| 02:18 | <zewt> | why is it okay, that sounds gross, heh |
| 02:18 | <rniwa> | sicking: you never know which JIT compiler has bugs |
| 02:18 | <rniwa> | sicking: good principle > i generally try to stay out of naming issues |
| 02:18 | <rniwa> | sicking: makes you productive :) |
| 02:19 | <sicking> | rniwa: we have functions called 'delete' in indexedDB |
| 02:19 | <rniwa> | sicking: oh dear |
| 02:23 | <rniwa> | sicking: but I think the problem here is that do is defined by author |
| 02:23 | <rniwa> | sicking: so you'll writ something like undoManager.transact{do: funciton(redo) {..}, undo: funciton() {..}) |
| 02:23 | <rniwa> | sicking: I guess it's fine in this simple case but might be annoying in more complicated case |
| 02:23 | <rniwa> | sicking: how old is ES5 support among browsers? |
| 02:23 | <rniwa> | sicking: I don't want to make library author's life harder but I don't want to worry about backward compat. if it's form ages ago |
| 02:23 | <sicking> | rniwa: JIT's don't matter here, only ecmascript parsers |
| 02:23 | <sicking> | rniwa: it was renamed from 'remove' to 'delete' based on developer input |
| 02:23 | <sicking> | rniwa: past the parser it's just strings |
| 02:23 | <sicking> | rniwa: one option would be to do both things |
| 02:23 | <sicking> | rniwa: have apply/reapply/unapply, pass a boolean argument to apply/reapply, and do the fallback to apply if reapply doesn't exist |
| 02:23 | <sicking> | rniwa: that way, if you have really different implementations between apply/reapply you can split it into two functions |
| 02:23 | <sicking> | rniwa: but if you don't, you can just add a few branches |
| 02:23 | <sicking> | s/but if you don't/but if the differences are small/ |
| 02:23 | <rniwa> | sicking: that's what I meant :) |
| 02:24 | <rniwa> | sicking: > parsers |
| 02:24 | <dglazkov> | zewt: ftfy https://encrypted.google.com/ |
| 02:24 | <rniwa> | sicking: should have said engine* |
| 02:24 | <sicking> | hmm... seems like i have connectivity issues |
| 02:24 | <sicking> | rniwa: did you get my last message? |
| 02:24 | <rniwa> | sicking: yeah |
| 02:24 | <rniwa> | sicking: that might be a good idea |
| 02:24 | <sicking> | rniwa: the "s/but if you don't/but if the differences are small/" one? |
| 02:24 | <rniwa> | sicking: having both* |
| 02:25 | <sicking> | cool |
| 02:25 | <rniwa> | sicking: okay, let's do that for now |
| 02:25 | <zewt> | dglazkov: :D |
| 02:25 | <sicking> | rniwa: for what it's worth, if you do { "do": function(...) { ... } }, that will work even in ES3 parsers |
| 02:25 | <rniwa> | sicking: sorry about the delay in responses, I want to be more responsive but I've been blocked by regressions from my Apple-style-span removals |
| 02:25 | <rniwa> | sicking: oh that's a good point |
| 02:26 | <rniwa> | sicking: mn... come to think of it |
| 02:26 | <rniwa> | sicking: maybe we don't need automatic boolean |
| 02:26 | <rniwa> | sicking: maybe we should just rename apply for automatci function to execute |
| 02:26 | <sicking> | ok, gotta run, circus class! |
| 02:27 | <rniwa> | sicking: so that manual transaction would have apply(bool), unapply, and optionally reapply |
| 02:27 | <rniwa> | sicking: and automatic transactoin would have execute |
| 02:27 | <rniwa> | sicking: ah, ok. |
| 02:27 | <rniwa> | ttyl |
| 02:27 | <sicking> | rniwa: that might work too |
| 02:27 | <rniwa> | guess I'll post that on whatwg and see what others think |
| 09:54 | <Ms2ger> | http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033136.html |
| 09:54 | <Ms2ger> | http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033257.html |
| 09:54 | <Ms2ger> | So does Opera support script onload? |
| 09:56 | <bga_> | small css proposal. resampling-filter: lanczos | bicubic | linear | ... |
| 09:59 | <zcorpan> | Ms2ger: hmm! |
| 09:59 | <Ms2ger> | I'd look at the code, but you guys are evil ;) |
| 10:01 | <zcorpan> | Ms2ger: seems my testing was bogus |
| 10:14 | <annevk> | "hot mutato" |
| 10:15 | annevk | is trying to work out the component model minutes |
| 10:20 | <asmodai> | Mmm, had SPDY been put forth for an IETF RFC by now (given how Mozilla added it to ff as well in recent builds)? |
| 10:20 | <asmodai> | s/had/has/ |
| 10:23 | <annevk> | "(shouting match--declarative will be there)" |
| 10:23 | <annevk> | So far it seems sufficient people in the room were in favor of a trimmed XBL2 |
| 10:28 | <smaug____> | I missed that meeting, but I was told that Mozilla and Apple had pretty similar ideas, and Google something a bit different |
| 10:29 | <smaug____> | Though, I think someone needs to still figure out sane event handling for shadow trees / bindings |
| 10:29 | <annevk> | From the minutes I just read on public-webapps that appears to be the case, yes |
| 10:29 | <smaug____> | (event retargeting is just quite error prone) |
| 10:30 | <annevk> | Mozilla/Apple participants want a trimmed XBL2; Google wants simpler JS libraries |
| 10:30 | <annevk> | The specifics were not nailed down |
| 10:30 | <annevk> | That is, all the hard questions are still there I guess :) |
| 10:30 | <smaug____> | indeed |
| 10:31 | <annevk> | I proposed a unconference session for TPAC |
| 10:31 | <annevk> | Maybe we can make some progress then... |
| 10:31 | smaug____ | tries to not attend TPAC |
| 10:32 | <smaug____> | too much flying |
| 10:34 | <woef> | on rel="next" and rel="prev" |
| 10:34 | <woef> | Google says: "Send users to the most relevant page/URL—typically the first page of the series." |
| 10:35 | <woef> | Why would they do that and is there any way to step them from going through with it? |
| 11:54 | <annevk> | Curious to see whether this will have any effect: http://infrequently.org/2011/09/things-the-w3c-should-stop-doing/ |
| 11:54 | <annevk> | Seems kind of pointless to suggest XML should be removed as it is unlikely to be removed from browsers, but overall it's a valid point |
| 12:05 | <Neiluj> | Hi |
| 12:07 | <Neiluj> | is there a plan to support other date/time format for inputs ? like <input type="time" format="time-hour:time-minute"/> or <input type="date" format="date-mday/date-month/date-fullyear"/> ? |
| 12:09 | <annevk> | do you mean UI-wise or submission-wise? |
| 12:09 | <annevk> | submission-wise: no |
| 12:10 | <annevk> | UI-wise: vague ideas exist |
| 12:10 | <Neiluj> | what means submission-wise ? what coming out from the form ? |
| 12:10 | <annevk> | yeah, what the server gets |
| 12:10 | <Neiluj> | ok, so no only UI-wise |
| 12:11 | <annevk> | we don't really have a good idea yet |
| 12:11 | <annevk> | at the moment UI is up to browsers |
| 12:12 | <Neiluj> | ok :) |
| 12:12 | <Neiluj> | hope it will come one day, thx :) |
| 12:12 | <smaug____> | hopefully browsers can pickup the "right" UI based on the page's language |
| 12:13 | <smaug____> | similarly to <input type="number"> handling |
| 12:13 | <smaug____> | (where decimal separator can be . or ,) |
| 12:13 | <Neiluj> | but what if the format is not about language convention, like not showing seconds for time inputs |
| 12:14 | <smaug____> | that is indeed some extra hint which UA should get from the page |
| 12:14 | <annevk> | Neiluj, that you can control already using step I think |
| 12:14 | <annevk> | well, showing is another matter I guess |
| 12:14 | <Neiluj> | annevk: indeed, with time, it's ok, that was for the example and that's a trick |
| 12:16 | <Neiluj> | thinking this may be some CSS property responsability actually... |
| 12:16 | <annevk> | on public-webapps⊙wo there is some discussion going on on how we want to allow developers to extend/replace elements with their own implementation |
| 12:17 | <Neiluj> | as it won't change the data but only the UI... |
| 13:45 | <annevk> | For everyone who wants to use Anolis with cross-specification cross-references, it's quite easy: http://wiki.whatwg.org/wiki/Anolis |
| 13:59 | <annevk> | http://shiki.esrille.com/2011/09/es-acid1.html seems Shiki is writing a browser in ECMAScript and it now passes Acid1 |
| 13:59 | <annevk> | that's pretty neat |
| 15:01 | <rillian_> | foolip, we're not having a meeting now, right? |
| 15:11 | rillian_ | guesses not |
| 16:30 | <annevk> | oh Björn had his spiel again about XMLHttpRequest not having a test suite |
| 16:30 | <annevk> | trololol |
| 16:34 | <hsivonen> | I thought you wrote a test suite for XHR |
| 16:35 | <annevk> | yeah Ms2ger pointed that out |
| 16:40 | <smaug____> | oh, test suites |
| 16:41 | <smaug____> | I need to look at my notes about invalid EventSource tests |
| 16:42 | <smaug____> | annevk: but in any case, thanks for writing tests! |
| 16:42 | <annevk> | smaug____, they've been around for a year now... |
| 16:43 | <smaug____> | xhr and eventsource? |
| 16:43 | <smaug____> | do you happen to have tests for xhr.timeout already? |
| 16:43 | <smaug____> | (someone is implementing that) |
| 16:44 | <annevk> | I have not written tests for any of the new features and I don't think I should |
| 16:44 | <annevk> | It's bad to write both the spec and the tests |
| 16:45 | <smaug____> | true |
| 16:52 | <Ms2ger> | annevk, so what should I recommend instead of replaceWholeText? |
| 16:57 | <annevk> | Ms2ger, parentNode.normalize() and then setting data? |
| 16:58 | <annevk> | or maybe just say to use textContent |
| 17:00 | <Ms2ger> | Takk |
| 17:01 | <annevk> | graag gedaan |
| 17:04 | <karlcow> | http://www.onderhond.com/blog/work/rel-next-prev-google |
| 17:14 | <zewt> | "verbose" |
| 17:15 | <annevk> | also seems like what Google is doing is the whole point behind having such attribute values |
| 17:15 | <annevk> | that you can offer different UI |
| 17:19 | <Hixie> | hsivonen: ooh, second time an "assistant-resolved" bug got escalated :-) |
| 17:24 | <annevk> | oh hey |
| 17:24 | <annevk> | deadline coming up |
| 17:24 | <annevk> | http://lists.w3.org/Archives/Public/public-html/2011May/0162.html |
| 17:24 | <annevk> | sort of forgot about that |
| 17:26 | <Ms2ger> | Only 175 for HTML5 |
| 17:27 | <annevk> | 30 bugs to WONTFIX per day :p |
| 17:47 | <annevk> | noticed http://www.w3.org/Bugs/Public/show_bug.cgi?id=13684 (on event handlers and DOM Events) while looking through those bugs; been meaning to write about that so that was nice |
| 17:56 | <annevk> | Oh, it's already text/vtt I see |
| 17:59 | <zewt> | i sort of like the idea of dropping "web" from webvtt, simply because there's nothing about it that's web-specific, and having "web" in there could (minorly) hinder adoption |
| 18:00 | <zewt> | only casually, though, it's already had one name change |
| 18:02 | <zewt> | (on the other hand, "vtt" is slightly less googlable than "webvtt") |
| 18:07 | <annevk> | zewt, we could still call it WebVTT (although I don't think it's a good idea to prefix specifications with random words such as "X" or "Web"), just not have "Web" become an intrinsic part of the format |
| 18:08 | <zewt> | if it's baked into the name of the spec, that's what people will call it, so the file header probably doesn't matter much at that point |
| 18:09 | <zewt> | well, i guess what people end up calling it is out of our hands--if people name the files *.vtt they may call it "vtt" no matter what we do |
| 18:09 | <Hixie> | annevk: I wanted the signature to be "WEBVTT FILE", it's already been reduced to "WEBVTT". I don't think we should go down even further. |
| 18:12 | <annevk> | I guess in the end it's just another string, like XMLHttpRequest |
| 18:13 | <annevk> | (Not that WEBVTT is that bad ;)) |
| 18:13 | <Ms2ger> | WEBVtt? |
| 18:14 | <zewt> | WEBVtt to represent a file format name WebVTT? that's a mind-bender :) |
| 18:14 | <zewt> | named |
| 18:15 | <annevk> | hey you can now search in Google+ |
| 19:18 | <AryehGregor> | So it looks like style="border-width: initial; border-color: initial" is unremovable via CSSOM in WebKit. |
| 19:18 | <AryehGregor> | . . . |
| 19:18 | <AryehGregor> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!doctype%20html%3E%0A%3Cdiv%20style%3D%22border-width%3A%20initial%3B%20border-color%3A%20initial%22%3E%3C%2Fblockquote%3E%0A%3Cscript%3E%0Avar%20div%20%3D%20document.querySelector(%22div%22)%3B%0Adiv.style.borderWidth%20%3D%20%22%22%3B%0Adiv.style.removeProperty(%22border-width%22)%3B%0Adiv.style.removeProperty(%22borderWidth%22)%3B%0Adelete%20div.style.borderWidth%3B%0A%3C%2Fscript%3E |
| 19:26 | <AryehGregor> | https://bugs.webkit.org/show_bug.cgi?id=68551 |
| 19:31 | <GlitchMr> | I would like to see ignoring CAPS LOCK state while using <input type=password>. Caps Lock usually does nothing good on those fields and is annoying :P (because you don't see you write with other case). |
| 19:31 | <GlitchMr> | But then, some might use passwords full of uppercase letters... |
| 19:32 | <zewt> | just mimic WinXP's "AWOOGA AWOOGA you've got caps lock on" tooltip on top of password boxes (if there was a way to detect it, of course) |
| 19:32 | <GlitchMr> | I don't think you could check Caps Lock state using JS |
| 19:32 | <zewt> | thus if there was :) |
| 19:33 | <GlitchMr> | Of course you could write passwords in database in lowercase or just try two passwords with each login (specified password and letter case flipped password), but that would lower the security. |
| 19:33 | <zewt> | (some might argue that showing something like that is the browser's job, though I think that would be a bit visually invasive for browsers to do on every site) |
| 19:34 | <AryehGregor> | GlitchMr, doesn't IE10 alert you if your caps lock key is on when you're typing in password inputs? |
| 19:34 | <AryehGregor> | All browsers should just do that. |
| 19:34 | <AryehGregor> | It's only sensible. |
| 19:36 | <GlitchMr> | Makes sense... |
| 20:13 | <RobbertAtWork> | GlitchMr: Some people have learned to type using caps lock for any sequence of two or more uppercase letters |
| 21:07 | <ojan> | TabAtkins: yt? i'm trying to figure out what to do w/ height:auto on a vertical flexbox. |
| 21:08 | <ojan> | TabAtkins: vertical writing-mode shrinkwraps using the initial containing block as the height |
| 21:09 | <ojan> | TabAtkins: it seems like we should do the same for flexbox |
| 21:32 | <TabAtkins> | ojan, here |
| 21:32 | <TabAtkins> | I agree. |
| 21:32 | <ojan> | TabAtkins: on further thought, i'm going to propose to the wg that the writing-mode spec change |
| 21:32 | <ojan> | TabAtkins: and i think flexbox should match |
| 21:32 | <TabAtkins> | kk |
| 21:34 | <ojan> | TabAtkins: i'll post shortly...but basically, if there is an available height for a height:auto flexbox, i think we should fill it instead of shrinkwrapping |
| 21:34 | <ojan> | TabAtkins: only shrinkwrap in the case of not having an available height and in that case, shrinkwrap using the height of the initial containing block |
| 21:35 | <TabAtkins> | Oh, so <div height=300px><vbox height=auto>...</vbox></div> would make the vbox 300px tall? |
| 21:37 | <mkanat> | As a developer, that's what I'd expect from height:100%, not from height: auto. |
| 21:37 | <TabAtkins> | ojan: ^^^? |
| 21:38 | <TabAtkins> | mkanat: I agree, if that's the behavior he's referring to. |
| 21:39 | <ojan> | TabAtkins: it makes height consistent w/ width |
| 21:40 | <TabAtkins> | ojan: But height isn't consistent with width in general. If you're embedding a vbox into a block element, I'd expect height:auto to work like height:auto does for any other element. |
| 21:40 | <TabAtkins> | (We need the 'fill' value for width/height which gives you the width:auto behavior explicitly, which we could then also use with height.) |
| 22:22 | <annevk> | "At the workshop today" |
| 22:22 | <annevk> | what workshop? |
| 22:23 | <TabAtkins> | The schema.org workshop, presumably. |
| 22:23 | jgraham | can no longer keep up with all the semi-secret meetings |
| 22:23 | <Hixie> | you're not missing anything |
| 22:23 | <Hixie> | (from the whatwg perspective anyway) |
| 22:25 | <Hixie> | can someone teach me what a singular transform matrix's implications are? |
| 22:26 | <Hixie> | wikipedia's math pages are inpenetrable |
| 22:27 | <jgraham> | A simular matrix doesn't have an inverse, so I guess once loses information e.g. by mapping points from an area onto a line |
| 22:28 | jgraham | doesn't know if that is helpful |
| 22:28 | <AryehGregor> | Hixie, it has derivative zero. It's not invertible. Geometrically, it multiplies areas by zero, so in two dimensions, it maps planes to points or lines. |
| 22:28 | <AryehGregor> | Anything specific you want to know? |
| 22:29 | <AryehGregor> | Singular vs. invertible is one of the basic differences you can have with matrices, so there are tons of things to say about it. |
| 22:29 | <Hixie> | if you have a plane and your transform it by a singular matrix, where is the resulting point or line? |
| 22:30 | <Hixie> | i guess it's got zero thickness so it doesn't matter |
| 22:30 | <AryehGregor> | Right. |
| 22:30 | <Hixie> | i'm trying to work out why browsers can't just implement the spec with singular matrices, instead needing some special text for them |
| 22:30 | <AryehGregor> | If it's a regular 2x2 matrix, it will map the plane to either the origin or a line through the origin. If it's an augmented matrix, it transforms affinely instead of linearly, so the point or line can be anywhere. |
| 22:31 | <AryehGregor> | What exactly constitutes "singular" when your matrix's values are floating-points is nonobvious. |
| 22:31 | <dbaron> | by derivative, AryehGregor meant determinant |
| 22:31 | <Hixie> | AryehGregor: yeah that's why i was hoping there'd be a nice way to not answer the question |
| 22:31 | <AryehGregor> | So I did. How embarrasing. |
| 22:31 | <AryehGregor> | embarrassing. |
| 22:32 | <AryehGregor> | Anyway, your questions have veered into the highly practical, so I don't think my expertise will be of much use. |
| 22:32 | <Hixie> | hah |
| 22:32 | <dbaron> | I think it really depends on the wording of the spec whether it needs to make a special case for singular matrices |
| 22:33 | <dbaron> | likewise for code |
| 22:33 | <dbaron> | but there are some things where it's certainly unavoidable |
| 22:33 | <dbaron> | like if we add an API for getting "coordinates in the space of element A" to "... of element B" |
| 22:34 | <dbaron> | if there's a singular transform between them, then there's no answer to the question in one direction (except for a narrow set of points) and lots of answers the other way |
| 22:35 | <dbaron> | likewise, there are a bunch of algorithms that have a "divide by the determinant" step, which doesn't work so well when it's 0. Usually such algorithms don't make any sense to apply to singular transforms anyway. |
| 22:35 | <dbaron> | Hixie, ^ |
| 22:35 | <Hixie> | yeah |
| 22:35 | <dbaron> | but the spec still needs to say what it does (return 0, throw exception, etc.) |
| 22:36 | <Hixie> | well luckily for me i don't think i have anything that returns points or divides anything by anything |
| 22:36 | <Hixie> | however |
| 22:36 | <Hixie> | people have nonetheless asked the question |
| 22:36 | <dbaron> | (e.g., when animating transforms, the fallback case is to decompose the matrix and animate the pieces -- and the decomposition algorithm doesn't work on singular matrices) |
| 22:37 | <dbaron> | asked the question about what? |
| 22:37 | <Hixie> | "what should happen if you have a singular transformation matrix" |
| 22:38 | <Hixie> | e.g. if you call c.scale(0,1); and then c.fill(); with a path |
| 22:38 | <dbaron> | ah, so these are questions about canvas |
| 22:38 | <dbaron> | I think that's easy: nothing. |
| 22:40 | <dbaron> | though if the path was set *before* the scale...? |
| 22:40 | <Hixie> | the path is non-zero |
| 22:40 | <dbaron> | (does the scale affect it?) |
| 22:40 | <Hixie> | the fill is all that is scaled |
| 22:40 | <dbaron> | hmmm, I don't remember canvas well enough to discuss this intelligently |
| 22:41 | <hober> | istm the canvas spec should align with the 2d/3d css transforms specs |
| 22:42 | <Hixie> | if img1 is a mostly green image, in webkit, this is a mostly green rectangle: |
| 22:42 | <Hixie> | c.beginPath(); c.rect(100,100,100,100); c.fillStyle = c.createPattern(img1, 'repeat'); |
| 22:42 | <Hixie> | c.scale(0.000000000000000000000000000000000001,1); |
| 22:42 | <Hixie> | c.fill(); |
| 22:42 | <Hixie> | but if i add one "0" to that number, it no longer paints anything. |
| 22:43 | <Hixie> | because repeating a zero-width image across the plane doesn't make much sense |
| 22:43 | <Hixie> | but what about if the fill is a color? |
| 22:44 | <jamesr_> | if it does nothing, does the globalCompositeOperation still apply? |
| 22:44 | <jamesr_> | if i do c.globalCompositeOperation="copy"; c.scale(0,1); makePath(c); c.fill(); |
| 22:44 | <jamesr_> | is my canvas now empty? |
| 22:45 | <Hixie> | not in webkit |
| 22:45 | <Hixie> | however |
| 22:45 | <AryehGregor> | If we had perfect precision, all this stuff would be well-defined. But some things suddenly behave differently at determinant zero compared to determinant epsilon, and there's no difference with floating-point . . . |
| 22:45 | <Philip`> | I think the reason the spec doesn't return points or divide anything by anything is that it doesn't actually define the algorithms to render things (which can do those things) |
| 22:46 | <Hixie> | if you set it to c.scale(0.000000000000000000000000000000000001,1); |
| 22:46 | <Hixie> | then it is empty |
| 22:46 | <Hixie> | so there's a difference between c.scale(0.000000000000000000000000000000000001,1);, c.scale(0.00000000000000000000000000000000001,1);, and c.scale(0.00000000000000000000000000000000000,1); |
| 22:47 | <Hixie> | that is, c.scale(1e-36,1);, c.scale(1e-37,1); and c.scale(0,1); |
| 22:47 | <Hixie> | Philip`: yeah, i was just noticing that nothing actually says how fill() paints a repeating pattern |
| 22:47 | <Philip`> | Sound like FLT_MIN |
| 22:47 | <Philip`> | *Sounds |
| 22:58 | <AryehGregor> | Philip` or zewt or anyone who might know: how does EBS pricing work if you maintain the volume for less than an integer number of months? It doesn't say whether they round or what. |
| 22:58 | <AryehGregor> | At least that I see. |
| 23:07 | <zewt> | they measure it in "GB-months", which I think means to multiply by the amount of time, eg. 2 GB for two weeks is one GB-month |
| 23:08 | <zewt> | (don't use a petabyte of storage and blame me for the billing if I'm wrong, though) |
| 23:09 | <Hixie> | that sounds equivalent to saying that they average the disk usage over each month |
| 23:10 | <zewt> | i regularly create large temporary volumes for things and delete them after a day or two; i'm sure they don't take the maximum or anything like that |
| 23:12 | <Hixie> | i wonder how often they sample |
| 23:16 | <AryehGregor> | They're providing block devices, not filesystems, so they don't have to sample. They can just record the creation and destruction times of each volume. |
| 23:17 | <annevk> | http://www.reddit.com/r/reddit.com/comments/kn327/wifes_ipad_i_just_wanted_to_play_angry_birds/ hahaha |
| 23:30 | <Philip`> | AryehGregor: http://serverfault.com/questions/197379/amazon-ebs-charges-calculation says hourly |