| 00:06 | <annevk> | rniwa: the current attribute change concepts are sufficient? is that what you were saying? |
| 00:11 | <rniwa> | annevk: yes! |
| 00:11 | <rniwa> | annevk: thanks for making that change |
| 00:11 | <rniwa> | annevk: now I can refer to those concepts in my spec |
| 00:11 | <annevk> | cool |
| 00:12 | <annevk> | I wonder when people are doing the analysis for the style="" attribute |
| 00:12 | <rniwa> | annevk: https://github.com/rniwa/undomanager/blob/master/undomanager.html already has reverting algorithm for node data replacement and inserting/removal of a node |
| 00:12 | <rniwa> | annevk: what do you mean by |
| 00:12 | <rniwa> | analysis? |
| 00:12 | <annevk> | whether or not we should exclude it by default |
| 00:13 | <rniwa> | annevk: oh, right. |
| 00:13 | <rniwa> | annevk: you can probably just reply to that thread on public-webapps |
| 00:14 | <annevk> | the mutation observer thread you mean? |
| 00:14 | <annevk> | I guess I will do that, but I should probably study the API a bit more and how it ties together to see whether I have any more questions |
| 00:15 | <annevk> | I got a pretty good understanding in SF, just need to work it out in text to see if there's something missing |
| 00:15 | <annevk> | (such as attribute namespace prefix changes...) |
| 00:16 | <ojan> | annevk: my intuition is that we should exclude style be default as well. rafael isn't a huge fan of adding more warts to the API, but he doesn't seem totally opposed to it if the benefits are large enough. |
| 00:16 | <ojan> | s/be/by |
| 00:18 | <annevk> | yeah |
| 00:18 | <annevk> | maybe we should omit attributeNamespace if sicking is serious about removing namespaced attributes... |
| 00:21 | <sicking> | annevk: someone needs to run statistics first |
| 00:22 | <sicking> | annevk: and we have to jump through some hoops to make xlink:href and xmlns... work |
| 00:22 | <annevk> | yeah I wasn't quite sure how you were planning on doing that |
| 00:23 | <annevk> | just not introducing new attributes like that works for me |
| 00:33 | <jamesr_> | roc, it looks like https://wiki.mozilla.org/NPAPI:AsyncDrawing overlaps really heavily with the ppapi drawing model. did you look at the latter? |
| 01:04 | <roc> | yes |
| 01:05 | <roc> | Pepper forces you to buy into the whole Pepper model, which no-one really wants to do (other than Google obviously) |
| 01:28 | <gsnedders> | I guess IE will use the HTML5 modes, based upon the HTML5 logic, unless the mode opts into a specific mode or is on compat. list |
| 01:30 | <gsnedders> | Because then their Native HTML5 impl is more complete, and more code runs using their Native impl. |
| 02:19 | <TabAtkins> | jwalden: Does the new FF background-sizing rules match what Image Values says? If not, we should discuss this on the list, to see what needs to be changed in the spec. |
| 02:26 | <MikeSmith> | hober: looks like we don't have a bugzilla.w3.org domain yet, but we do have bugs.w3.org (just not actually configured to anything it seems) |
| 02:26 | MikeSmith | fires off a mail to systems team |
| 02:30 | <jwalden> | TabAtkins: not sure; I've been busy with JS stuff lately and haven't been looking at image values recently |
| 02:32 | <TabAtkins> | jwalden: Okay. Reading through the irc logs, looks like we do match up. |
| 02:33 | <jwalden> | that would have been my guess, but there is substantial complexity here |
| 02:33 | <jwalden> | and we don't do the image sizing stuff outside background-image yet, either |
| 02:34 | <jwalden> | I am almost tempted to go back and do that, sometime |
| 02:34 | <jwalden> | fix one thing and suddenly you feel guilted into implementing the whole thing :-) |
| 03:55 | <MikeSmith> | is http://lists.w3.org/Archives/Public/www-archive/2011Nov/0047.html just a bug in Firefox? |
| 03:55 | <MikeSmith> | or is there some ambiguity or deficiency in the spec that needs to fixed? |
| 03:56 | <MikeSmith> | «Firefox bug: "Worker" load ignores Content-Type version parameter» |
| 05:14 | <rniwa> | annevk: yt? |
| 05:59 | <hsivonen> | hmm. how do I send the Windows key to VirtualBox guest on Ubuntu so that Unity won't capture it? |
| 06:00 | <MikeSmith> | I see the ACM's document licensing policy are also out of sync with the community they're supposed to be serving |
| 06:00 | <MikeSmith> | https://plus.google.com/109706986708019547706/posts/Mz8tYYBLzEx |
| 06:05 | <MikeSmith> | the bug-filing UI that Dimitri Glazgov has on http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html is nice |
| 06:07 | <hsivonen> | IE10 added TTML support, too :-( |
| 06:08 | <hsivonen> | fragmentation that could have been avoided |
| 06:08 | <hsivonen> | cool that they implemented WebVTT, though |
| 06:18 | <MikeSmith> | hsivonen: I don't understand what they actually implemented as far as TTML |
| 06:18 | <MikeSmith> | e.g., did they implement character styling? |
| 06:19 | <MikeSmith> | and if so, how? what spec is the support based on? since there's not actually any spec that defines how to use TTML with HTML <video>.. |
| 06:19 | <MikeSmith> | or in browsers at all |
| 06:23 | <MikeSmith> | http://www.rfc-editor.org/authors/rfc6455.txt close to final publication |
| 06:23 | <MikeSmith> | wonder where Michael Carter is these days |
| 07:10 | <MikeSmith> | http://msdn.microsoft.com/en-us/library/hh673566.aspx#ttml |
| 07:14 | <hsivonen> | MikeSmith: wow. Is that all they implemented of TTML? |
| 07:14 | <MikeSmith> | seems so |
| 07:14 | <hsivonen> | radical subsetting |
| 07:14 | <MikeSmith> | yeah, in the docs, they make it clear that it's just a subset |
| 07:29 | <zcorpan> | it seems a bit weird that bugs can go from RESOLVED NEEDSINFO to TrackerRequest |
| 07:47 | <hsivonen> | is it important for Web compat that lines don't wrap when text/plain is loaded into a browsing context whose view port is narrower than the lines? |
| 07:47 | <hsivonen> | what bad stuff would happen if browsers started line wrapping text/plain? |
| 08:05 | <MikeSmith> | webgl on android http://www.theverge.com/2011/11/29/2599183/surprise-sony-ericssons-android-2-3-update-included-webgl |
| 08:06 | <MikeSmith> | hsivonen: ascii art? |
| 08:10 | <Hixie> | really? to test IE10 I still have to install an entire OS? |
| 08:10 | <Hixie> | sigh |
| 08:29 | <hsivonen> | fwiw, Mozilla has already shipped WebGL on Android. (lacking in game-ready performance, though) |
| 09:57 | <smaug____> | annevk: FYI, MutationCallback has handleMutations, not handleEvent |
| 09:57 | <smaug____> | annevk: FYI, MutationCallback has handleMutations, not handleEvent |
| 09:57 | <smaug____> | (I didn't know that MutationObserver API has been copied to DOM4) |
| 09:58 | <annevk> | it doesn't in WebKit afaik |
| 09:58 | <annevk> | that callback thread didn't get quite resolved |
| 09:59 | <smaug____> | It does in Gecko and in the Google Docs version of the API |
| 09:59 | <smaug____> | (my patch for Gecko hasn't landed yet) |
| 10:01 | <annevk> | when I discussed it with the guys at Google they didn't like handleMutations |
| 10:01 | <annevk> | so I left it at handleEvent and raised that issue on the list |
| 10:01 | <annevk> | I guess it should be renamed handleMutations given the outcome of that discussion |
| 10:02 | smaug____ | needs to say Google guys again that they are wrong :p |
| 10:21 | <mib_ngqf8w> | hi |
| 10:23 | <mib_ngqf8w> | is this the right place to talk about globalCompositeOperation and "copy" in particular? |
| 10:24 | <jgraham> | It's not a bad place |
| 10:25 | <mib_ngqf8w> | I think the spec about it is not clear and some browser are imlpementing in a way and some in another way |
| 10:26 | <mib_ngqf8w> | and I think one of the way is useful in real-world uses and the other is useless |
| 10:28 | <mib_ngqf8w> | and the useless way could be emulated while the opposite needs no crossbrowser unusual tricks |
| 10:28 | <Philip`> | The spec is precise about what it intends (though that's not the same as "clear") - effectively the whole canvas should be cleared and then the new shape drawn on top, since that's how the drawing model works |
| 10:30 | <mib_ngqf8w> | the fact is I'm trying to draw curves with different opacities inside it - to draw with tablet pressure |
| 10:31 | <mib_ngqf8w> | but each curve is one opacity so I'm trying to emulate it with "copy" |
| 10:31 | <mib_ngqf8w> | but if copy is not what I hope it is there is not a good way to get tablet pressure in canvas |
| 10:33 | <Philip`> | Can you get it to clip to the shape you're wanting to fill, before drawing with 'copy', so that it won't affect pixels outside that shape? |
| 10:34 | <mib_ngqf8w> | "destination-out" + "copy"? |
| 10:38 | <Philip`> | I mean like 'drawYourPathOutline(); ctx.save(); ctx.clip(); ctx.globalCompositeOperation = "copy"; ctx.fill(); ctx.restore();' |
| 10:45 | <mib_ngqf8w> | thanks you Philip. I hope it could work |
| 10:46 | <mib_ngqf8w> | the fact is I'm trying to have a blurred curve (using shadows) with tablet pressure |
| 10:46 | <mib_ngqf8w> | maybe the clipping could create problems with the blur around each line |
| 10:48 | <mib_ngqf8w> | could be possible to propose a spec about a line with different opacity, shadow and color and size for each "node" of the curve? |
| 10:52 | <mib_ngqf8w> | and gradations of the nodes proprieties on the lines between the nodes |
| 11:10 | <mib_ngqf8w> | ok. I'll return to talk about that when there are less people sleeping |
| 11:11 | <mib_ngqf8w> | bye |
| 12:04 | <gsnedders> | Anyone looked into the IE10pp4 quirks mode? |
| 12:06 | <gsnedders> | Seems to expose modern objects, and use the AAA for parsing. |
| 12:09 | <zcorpan> | wonder what their strategy is these days |
| 12:14 | <Philip`> | Does the new quirks mode apply to typical doctypeless pages with no special markers or flags or anything? |
| 12:15 | Philip` | wonders if they just decided that failing to support HTML5 features in new sites that forgot to include a doctype is a greater compatibility concern than changing behaviour on old sites that didn't include a doctype |
| 12:16 | <Philip`> | (and since they seem to be promoting HTML5, it's better to break old sites than to break the new sites they're telling everybody to write) |
| 12:16 | <gsnedders> | Philip`: Typical DOCTYPEless pages |
| 12:17 | <gsnedders> | Not hit IE5 Quirks yet |
| 12:18 | <Philip`> | x-ua-compatible ie=5? |
| 12:18 | <gsnedders> | Yeah, I'm guessing that'll trigger it |
| 12:18 | <gsnedders> | But what's curious is whether they have magic. |
| 12:22 | <gsnedders> | I mean, this basically means unless you end up blacklisted or opt-in to an old mode, you're running per HTML5 |
| 12:53 | <annevk> | wow really? |
| 12:53 | <annevk> | that's pretty awesome |
| 13:24 | <wilhelm_> | This kind of pixel densities make CSS media queries … interesting: http://www.anandtech.com/show/5002/toshiba-releases-61-display-with-resolution-of-2560x1600 |
| 13:25 | <zcorpan> | gsnedders: about time for a quirks spec, then |
| 13:32 | <kennyluck> | www.whatwg.org is down ??? |
| 13:33 | <wilhelm_> | No. |
| 13:34 | <kennyluck> | hmm… just checked downforeveryoneorjustme.com and it's indeed just me. |
| 13:39 | <zcorpan> | "The beta (a.k.a. "aurora") of Firefox 10 ..." - html5weekly |
| 13:44 | <hsivonen> | wilhelm_: I worry that someone ships a browser that doesn't do the right thing with device pixel to CSS pixels ratio and UA sniffing ensues |
| 13:44 | <hsivonen> | zcorpan: I guess the channels haven't been communicated well enough... |
| 14:03 | <annevk> | zcorpan: setTimeout(0) is what you are asking for |
| 14:06 | <zcorpan> | annevk: that's not without problems |
| 14:07 | <annevk> | you'll need to elaborate |
| 14:07 | <annevk> | also on use cases |
| 14:07 | <zcorpan> | setTimeout(0) waits 4ms per spec |
| 14:08 | <annevk> | i thought that the first was queued immediately |
| 14:08 | <annevk> | not sure if the spec matches reality |
| 14:09 | <zcorpan> | so the last time i abused window.postMessage was when i did a study on SRT |
| 14:10 | <jgraham> | I thought setTimeout only had a lower limit if it was called from another timer |
| 14:13 | <zcorpan> | yeah |
| 14:49 | <karlcow> | http://blog.bluevia.com/2011/11/30/dan-appelquist-joins-bluevia-to-lead-product-management/ |
| 15:02 | <hsivonen> | I didn't see this coming: http://lists.w3.org/Archives/Public/www-style/2011Nov/0782.html |
| 16:02 | <paul_irish> | http://movethewebforward.org/ is launched. an initiative to get more involvement in standards and such from the larger webdev population. pull requests and issues welcome. :) |
| 16:15 | <jgraham> | paul_irish: Nice |
| 16:16 | <timeless> | hsivonen: wow |
| 16:17 | <smaug____> | paul_irish: you could mention that html5rocks.com is mainly webkit or chrome thingie |
| 16:17 | <paul_irish> | i thought i did |
| 16:17 | <smaug____> | the name html5rocks is quite misleading |
| 16:17 | <paul_irish> | there is that... :) |
| 16:17 | <timeless> | misleading names on the web?! |
| 16:17 | <timeless> | how can that be! |
| 16:18 | <smaug____> | paul_irish: "updates.html5rocks.com - short news, tips, and tricks about HTML5" |
| 16:18 | <smaug____> | should be perhaps: "updates.html5rocks.com - short news, tips, and tricks about webkit" |
| 16:23 | <timeless> | +1 |
| 16:23 | miketaylr | still prefers html5r0cks.com |
| 16:24 | <timeless> | miketaylr: nice |
| 16:26 | <smaug____> | paul_irish: should you mention http://caniuse.com/ ? |
| 16:26 | <drublic> | paul_irish: there is no mention of the server-names in the "Ask for help"-irc section i think |
| 17:07 | <divya> | drublic: for free node? |
| 17:08 | <divya> | i see. it was there, but got removed. |
| 17:08 | <drublic> | divya: yes. and for mozilla too |
| 17:09 | <drublic> | divya: the channel-list was different yesterday i guess :D |
| 17:11 | <divya> | drublic: pushed. it might take about 10 mins |
| 17:11 | <drublic> | divya: cool! :) |
| 17:19 | <drublic> | divya: short question: what's the best way to request the status of a bug in opera? send a mail? |
| 17:20 | <divya> | ask me :) |
| 17:20 | <drublic> | k |
| 17:20 | <drublic> | mom |
| 17:20 | <divya> | :P |
| 17:22 | <drublic> | divya: bug-id DSK-350419, it's not possible to use opera next for me as it breaks all the time. but i'd love to test some features sometimes |
| 17:31 | <divya> | drublic: ah its a P1 bug! |
| 17:31 | <divya> | which means it is most likely going to be fixed asap. the problem is with hw accell |
| 17:31 | <divya> | if you can go to opera:config and disable HW Accell it should be better |
| 17:31 | <drublic> | divya: ah cool! |
| 17:32 | <drublic> | hehe. it's not possible to navigate there I think :D |
| 17:32 | <divya> | oh? |
| 17:32 | <drublic> | good to know that it will be fixed soon. |
| 17:32 | <divya> | drublic: you can d/l the latest snapshot it seems stabler to me |
| 17:33 | <drublic> | the "over-accelleration" starts on click |
| 17:33 | <divya> | yeah but you can type opera:config in the addressbar? |
| 17:33 | <drublic> | i've got build 1155 |
| 17:33 | <divya> | drublic: the latest desktop blog post has link to 1174 |
| 17:33 | <drublic> | divya: right |
| 17:33 | <divya> | which is far more stabl |
| 17:34 | <drublic> | just saw it |
| 17:34 | <drublic> | divya: looks better now |
| 17:34 | <drublic> | but still buggy… |
| 17:34 | <drublic> | anyway |
| 17:34 | <drublic> | thank you very much for letting me know |
| 17:34 | <divya> | no problemo! |
| 17:35 | <drublic> | any plans to open the bugtracker for everyone? |
| 17:36 | <drublic> | divya: works great with hardware accel turned off :) |
| 17:37 | <divya> | drublic: yes we are trying. the bug tracker is like 7 years old or more! |
| 17:37 | <divya> | so getting them public is an uphill task. |
| 17:37 | <drublic> | divya: that's awesome! |
| 17:37 | <divya> | and we need resources :P |
| 17:37 | <drublic> | divya: right… |
| 17:38 | <drublic> | but great to see some movement :) |
| 17:39 | <divya> | :) |
| 18:00 | <rniwa> | AryehGregor: yt? |
| 18:53 | <rniwa> | hi everyone |
| 18:53 | <rniwa> | undomanager discussion is moving from #developer @ mozilla |
| 18:53 | <ehsan> | alright |
| 18:54 | <ehsan> | rniwa: I'm here |
| 18:54 | <rniwa> | sicking: could you repost your proposal here/ |
| 18:54 | <rniwa> | so that others can understand what the heck we're going to talk about |
| 18:54 | <ehsan> | AryehGregor: we're discussing the undo manager spec |
| 18:54 | <sicking> | writing it up |
| 18:54 | <rniwa> | sicking: great. |
| 18:57 | <WeirdAl> | bad idea #7: why not just have two interfaces: TransactionWithReapply and StandardTransaction? |
| 18:57 | <zewt> | any luck with the undo selection state problem? |
| 18:57 | <WeirdAl> | let the stinking transaction itself define what it wants |
| 18:58 | <rniwa> | zewt: I think I'm just going to ignore Mac case for now. |
| 18:58 | <rniwa> | zewt: since now automatic transaction has reapply/unapply method |
| 18:58 | <zewt> | which case is that? |
| 18:58 | <rniwa> | zewt: author can fix it if needed |
| 18:58 | <rniwa> | zewt: deleted content is selected |
| 18:58 | <rniwa> | on Mac |
| 18:58 | <rniwa> | WeirdAl: transaction is duck-typed |
| 18:59 | <rniwa> | WeirdAl: but that's sort of my proposal as well: let transaction define what it wants |
| 18:59 | <zewt> | as long as deleted content that was selected before it was deleted comes back selected |
| 18:59 | <rniwa> | WeirdAl: read my thread titled "Re-introducing AutomaticDOMTransaction interface to decouple automatic transaction from UndoManager" |
| 18:59 | <WeirdAl> | I am a couple days behind on email |
| 18:59 | <rniwa> | zewt: the problem is that it's near impossible to correctly detect what has been deleted |
| 19:00 | <sicking> | make automatic transactions have three functions implement/unapply/reapply ("implement" to be bikeshedded later) |
| 19:00 | <sicking> | make manual transactions have three functions apply/unapply/reapply |
| 19:00 | <sicking> | when a transaction is passed to the undo-manager, it checks if it has a "implement" method. If it does it knows that it's a automatic transaction. It records meta-data indicating that it's an automatic transaction and then calls implement. While implement is running it records the DOM mutations performed. |
| 19:00 | <sicking> | when a transaction is passed to the undo-manager which *doesn't* have a "implement" method, it knows that it's a manual transaction. It records meta-data indicating this and then calls apply. |
| 19:00 | <sicking> | When undoing a automatic transaction it undoes the DOM mutations and calls the unapply method if it exists. |
| 19:00 | <sicking> | When undoing a manual transaction simply calls the unapply method if it exists. |
| 19:00 | <sicking> | When redoing a automatic transaction it redoes the the mutations and then calls reapply if it exists. |
| 19:00 | <sicking> | When redoing a manual transaction it reapply if it exists or apply otherwise. |
| 19:00 | <zewt> | if you select a block in FF, delete it, then undo, it comes back selected; that's pretty important, IMO (restoring the actual state before the delete) |
| 19:01 | <rniwa> | sicking: we have isAutomatic so this works the way you just said more or less. |
| 19:01 | <ehsan> | rniwa: right |
| 19:01 | <rniwa> | sicking: btw, we should probably rename "apply" to execute or something like that |
| 19:01 | <sicking> | *possibly* we can make all calls to apply provide a argument indicating if the calls is due to an original application, or due to a reapplication. Indicated though a bool or string (i don't care which :) ) |
| 19:01 | <ehsan> | which is along the lines of what I was talking about on moznet |
| 19:01 | <rniwa> | sicking: it's really confusing to name a method "apply" in JS |
| 19:01 | <sicking> | rniwa: sure, i'm fine with whatever names |
| 19:02 | <rniwa> | zewt: hm... |
| 19:02 | <rniwa> | zewt: didn't know that case :( |
| 19:02 | <ehsan> | can someone explain to me why we need to call apply when redoing an automatic transaction at all? |
| 19:02 | <rniwa> | zewt: we need some way to communicate that information back to UA though |
| 19:02 | <sicking> | rniwa: the point is to have different function names for automatic and manual transactions |
| 19:02 | <zewt> | (i don't have any new ideas, was just wondering if anyone else has had any) |
| 19:02 | <rniwa> | zewt: when a random node is removed from the document, we have no way of knowing that it should be selected upon undo |
| 19:02 | <rniwa> | sicking: hm... okay. |
| 19:03 | <sicking> | rniwa: that makes it more ok to not call the "apply"/"implement" method if reapply isn't there when reapplying a automatic transaction |
| 19:03 | <rniwa> | sicking: true |
| 19:03 | <sicking> | rniwa: technically it also removes the need for the isAutomatic flag. But we can keep it to make it more explicit (rather than looking for a "implement" method) |
| 19:04 | <rniwa> | sicking: well i guess if we use two different names, then we don't need isAutomatic flag |
| 19:04 | <rniwa> | sicking: to avoid a confusion like what if we had both apply and isAutomatic: true |
| 19:04 | <sicking> | rniwa: indeed |
| 19:04 | <rniwa> | sicking: or has implement but isAutomatic: false |
| 19:04 | <rniwa> | that's just annoying |
| 19:04 | <rniwa> | sicking, ehsan: okay, that sounds like a viable option to the problem at hand |
| 19:05 | <rniwa> | sicking: on the other hand, I still like the idea of reintroducing AutomaticDOMTransaction interface |
| 19:05 | <rniwa> | sicking: the main rationale behind is that being able to revert DOM changes seems useful even outside of undomanager |
| 19:06 | <rniwa> | sicking: this feature tied to undomanager; i.e. UA can only revert DOM changes if it's part of undo stack |
| 19:06 | <rniwa> | makes it really hard to use besides undo/redo |
| 19:07 | <WeirdAl> | rniwa: can you repost the link to the current spec, please? |
| 19:07 | <sicking> | rniwa: yeah... so i guess we could make AutomaticDOMTransaction take an object with "implement"/"unapply"/"reapply" and returns an object with "apply"/"unapply"/"reapply" |
| 19:07 | <jgraham> | rniwa: (AryehGregor is likely busy shopping for his wedding dress, or whatever it is one does before a wedding) |
| 19:07 | <rniwa> | jgraham: rniwa.com/editing/undomanager.html |
| 19:07 | <sicking> | rniwa: however I would ask what the use cases are |
| 19:07 | <rniwa> | sicking: right. |
| 19:07 | <zewt> | unclickable url D: |
| 19:07 | <WeirdAl> | got it |
| 19:07 | <rniwa> | sicking: so even in an app that uses manual transactions |
| 19:08 | <rniwa> | sicking: there might be cases where they decide to use automatic transaction internally |
| 19:08 | <sicking> | rniwa: without an undomanager there's a bigger risk that someone tries to undo changes on a DOM that looks differently than the "after" state |
| 19:08 | <sicking> | rniwa: true |
| 19:08 | <rniwa> | sicking: yeah but that's okay because the spec precisely defines when and how reverting DOM changes is done |
| 19:08 | <rniwa> | zewt, jgraham: http://rniwa.com/editing/undomanager.html |
| 19:09 | <rniwa> | sicking: see 3.1.1. http://rniwa.com/editing/undomanager.html#reverting-dom-changes |
| 19:09 | <sicking> | rniwa: it's ok in the sense that it'll be consistent. I'll probably result in surprising behavior for the page though |
| 19:09 | <sicking> | rniwa: for the page author that is |
| 19:09 | <rniwa> | sicking: right, but I think that's okay |
| 19:09 | <rniwa> | sicking: it's same thing as mutation observers |
| 19:09 | <rniwa> | sicking: or any other APIs that interact with DOM |
| 19:10 | <sicking> | rniwa: ok |
| 19:10 | <rniwa> | sicking: but I see your concern though |
| 19:10 | <zewt> | if I mention vim's undo trees, will people throw vegetables at me |
| 19:10 | ehsan | is rather ambivalent about adding AutomaticDOMTransaction back |
| 19:10 | <sicking> | rniwa: i feel like ehsan. |
| 19:10 | <rniwa> | zewt: I've considered those cases when we initially thought about collaborative editing |
| 19:10 | ehsan | throws some vegteables at zewt |
| 19:10 | WeirdAl | thinks that no matter what, there's got to be some non-normative sections explaining the rationales |
| 19:11 | <rniwa> | zewt: but it turned out that it's such a complex feature that I might need to get a Ph.D. in that topic first before I can make any sensible API for it. |
| 19:11 | <zewt> | seems like undo is plenty complex anyway :) |
| 19:11 | <rniwa> | WeirdAl: yeah, I'll have to do that at some point |
| 19:11 | <sicking> | rniwa: one option is to do the API I just proposed. And possibly add AutomaticDOMTransaction later. |
| 19:12 | <sicking> | rniwa: implementation-wise that'll be easy. If/when we add AutomaticDOMTransaction, just use that to wrap any transaction object passed which has a "implement" method |
| 19:12 | <rniwa> | sicking, ehsan: so one thing I want to accomplish by reintroducing the interface is to de-couple automatic transaction from undomaanger |
| 19:12 | <rniwa> | sicking: so that undomanager can just focus on calling apply, unapply, and reapply and don't need to be aware of what kind of transaction it's applying |
| 19:13 | <rniwa> | sicking, ehsan: this allows us to add new types of transactions in the future more easily |
| 19:13 | <ehsan> | rniwa: I'm not sure why that's valuable |
| 19:13 | <sicking> | rniwa: the goal being to make things easier implementation-wise, specification-wise or user-wise? |
| 19:13 | <rniwa> | sicking: all. |
| 19:14 | <sicking> | rniwa: i don't see how it helps |
| 19:14 | <rniwa> | sicking: I think it's conceptually easier to understand that undomanager just calls apply, unapply, and reapply. |
| 19:14 | <rniwa> | sicking: and then we have this special interface that creates an transaction with UA auto-tracking changes |
| 19:14 | sicking | wants to point rniwa to an article on orthogonality that he recently read |
| 19:14 | <rniwa> | sicking: I had an opportunity to talk to some developers + other UA implementors at TPAC |
| 19:15 | <rniwa> | sicking, ehsan: and got an impression that undomanager doing the magical thing is quite confusing to a lot of ppl |
| 19:17 | <ehsan> | rniwa: that sounds to me like a problem which can be fixed by documentation |
| 19:17 | <ehsan> | not by adding more to the spec |
| 19:17 | <rniwa> | sicking, ehsan: nice thing about re-introducing the interface is that it eliminates the need for apply method altogether |
| 19:17 | <ehsan> | impl-wise that's not gonna simplify much either |
| 19:17 | <ehsan> | just one if statement most likely ;) |
| 19:17 | <ehsan> | rniwa: how would it do that? |
| 19:18 | <sicking> | rniwa: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1147.html |
| 19:18 | <rniwa> | ehsan: because if the interface is responsible for keeping track of DOM changes |
| 19:18 | <rniwa> | ehsan: those DOM changes can happen outside of the undomanager |
| 19:18 | <rniwa> | ehsan: the interface can then just supply special unapply/reapply methods to be used by undomanager |
| 19:19 | <rniwa> | ehsan: there was no need for apply method for manual transaction from the beginning |
| 19:19 | <rniwa> | the only reason we have 'em is to be consistent with automatic transactions |
| 19:19 | <zewt> | pretty hard to take someone seriously who's arguing against orthogonal design. heh |
| 19:20 | <sicking> | rniwa: http://www.artima.com/intv/ruby2.html <-- better formatted |
| 19:20 | <ehsan> | rniwa: let me think about this a bit |
| 19:20 | <zewt> | (that also explains a lot about why ruby is so ... uh, bad) |
| 19:21 | <rniwa> | sicking: thanks for the article |
| 19:21 | rniwa | reads |
| 19:21 | <rniwa> | sicking, ehsan: de-coupling apply from undomanager also eliminates the need for special-casing changes outside of the undo scope |
| 19:22 | <rniwa> | sicking, ehsan: because now authors can just make changes outside of the transaction before adding it to undo manager |
| 19:22 | <rniwa> | sicking, ehsan: so automatic transaction can now focus on just reverting whatever DOM changes made inside "implement" method |
| 19:23 | <rniwa> | sicking, ehsan: we don't even need complicated sanity-checks in "transact" because transact does nothing but adds the entry to the undo stack. |
| 19:23 | <rniwa> | it simplifies so many things in so many levels |
| 19:24 | <sicking> | rniwa: I don't see that it implements things for the implementor at all. *worst* case I'd use the automatic transaction object internally. But I think i can even make it better than that and use an internal abstraction |
| 19:25 | <sicking> | rniwa: for authors it does give them another tool, which could be useful I agree |
| 19:25 | <sicking> | rniwa: but it also means that they have to do more typing since the undomanager won't wrap the automaticDOMTransaction ctor automatically, they have to type it out. |
| 19:26 | <WeirdAl> | typing is cheap :p |
| 19:27 | <sicking> | WeirdAl: and yet one of the big complaints about the DOM is that it uses too long function names for everything |
| 19:28 | <zewt> | if that's the biggest complaint someone has about an API, the API must be really good |
| 19:28 | <rniwa> | sicking: true. it does require more typing specially after your proposal about renaming apply to implement for automatic transaction |
| 19:28 | <rniwa> | sicking: we used to have isAutomatic so the increase wasn't so bad. |
| 19:29 | <ehsan> | rniwa: I'm not sure if I understand this correctly: "the interface can then just supply special unapply/reapply methods to be used by undomanager" |
| 19:30 | <rniwa> | ehsan: i.e. the interface "wraps" the author-supplied unapply/reapply so that when undoManager calls unapply/reapply |
| 19:30 | <rniwa> | ehsan: it can do the work to revert DOM changes made by the author |
| 19:32 | <ehsan> | rniwa: dunno, it still doesn't seem like a large improvement, but I don't wanna stall this discussion :) |
| 19:32 | <WeirdAl> | rniwa: would a face-to-face of interested parties in the spec be a good idea anytime soon? |
| 19:33 | <WeirdAl> | attendance not mandatory :) |
| 19:34 | <rniwa> | WeirdAl: you mean for undo manager? |
| 19:34 | <WeirdAl> | yes |
| 19:34 | <rniwa> | ehsan, sicking: I think I like Jonas' idea about renaming apply to implement for automatic transaction |
| 19:35 | <WeirdAl> | I've been interested, but not able to devote a lot of time to the spec |
| 19:35 | <rniwa> | ehsan, sicking: I really disliked isAutomatic flag so it's a huge improvement over the current spec. |
| 19:35 | <rniwa> | ehsan, sicking: but I still think re-introducing the interface is a good idea. maybe I should let you sleep on it and maybe you'll agree with me :) |
| 19:35 | <sicking> | rniwa: like i said, as long as we do that i'm happy. I can live with also adding the AutomaticDOMTransaction, but I don't feel the immediate need |
| 19:36 | <rniwa> | sicking: ok. |
| 19:36 | <WeirdAl> | commit, backout, reapply? :p |
| 19:36 | WeirdAl | is kidding |
| 19:36 | <rniwa> | sicking: I guess I should go talk with other folks before making the change. |
| 19:36 | <ehsan> | rniwa: I agree with sicking |
| 19:36 | <rniwa> | sicking: so by "also adding the interface", you mean that transact on undomanager still accepts duck-typed object |
| 19:36 | <rniwa> | sicking: before it being applied? |
| 19:37 | ehsan | assumes yes |
| 19:37 | <sicking> | yes |
| 19:37 | <rniwa> | WeirdAl: hm... i guess we'd have to figure out when everyone's free |
| 19:37 | <rniwa> | WeirdAl: also, it might be a good idea to do it after I post it on public-webapps |
| 19:37 | <WeirdAl> | weekends work best for me, and I am in the SF Bay Area |
| 19:37 | <rniwa> | which I'm hoping to happen in the next couple of weeks |
| 19:37 | <rniwa> | woot woot! |
| 19:38 | <rniwa> | ehsan, sicking: okay. let's push back on re-introducing the interface for now and propose the rename |
| 19:38 | <WeirdAl> | knowing me, I'll probably rehash some of my other points about the spec :) |
| 19:38 | <rniwa> | ehsan, sicking: since the rename seems like a very good solution to the problem at hand |
| 19:39 | <rniwa> | sicking: would you like to post it yourself on whatwg or should I do it on behalf of you? |
| 19:39 | <rniwa> | WeirdAl: ok. |
| 19:39 | <sicking> | rniwa: it would be awesome if you could post it |
| 19:40 | <rniwa> | sicking: ok, will do. |
| 19:40 | <rniwa> | sicking, ehsan: thanks for your time! |
| 19:40 | <ehsan> | rniwa: so should I hold off on looking at the email discussions? :) |
| 19:40 | <rniwa> | ehsan: I'll post it in the next 10-20m |
| 19:40 | <ehsan> | great |
| 19:40 | <ehsan> | thanks :) |
| 19:42 | <rniwa> | sicking, ehsan: btw, instead of [(implement, apply), unapply, reapply], can we do [(executeAutomatic, execute), executeUndo, executeRedo] ? |
| 19:42 | <rniwa> | or can we do [(executeAutomatic, execute), undo, redo] ? |
| 19:43 | <ehsan> | I guess it's a good sign that we can now focus on bikeshedding? ;) |
| 19:43 | <rniwa> | I really want to avoid using the name "apply" for the said reason. |
| 19:43 | <rniwa> | ehsan: yeah. we've been bikeshedding a lot on those method names. |
| 19:43 | <ehsan> | fwiw I would avoid names with "automatic" in them |
| 19:44 | <ehsan> | since I was never quite convinced that "automatic transaction" is a good name ;) |
| 19:44 | <rniwa> | ehsan: hm... |
| 19:44 | <ehsan> | but I will mostly hold off on bikeshedding ;) |
| 19:44 | <rniwa> | ehsan: but since it's called automatic DOM transaction now, let's stick with automatic for now |
| 19:44 | <rniwa> | ehsan: if you have a better alternative, I'm more than happy to discuss it |
| 19:44 | <WeirdAl> | native? :) |
| 19:45 | <WeirdAl> | built-in? |
| 19:45 | <rniwa> | WeirdAl: it used to be managed. |
| 19:45 | <WeirdAl> | esoteric? |
| 19:45 | <ehsan> | rniwa: I don't really :( |
| 19:45 | ehsan | has always been bad with names |
| 19:46 | rniwa | uses his editorial power to make the rename! |
| 19:46 | ehsan | envies rniwa's powers ;) |
| 19:47 | <rniwa> | sicking, ehsan: so the conclusion is to get rid of the apply's argument, right? |
| 19:47 | WeirdAl | sticks his pinky into his lip, and plots a nefarious plot to destroy the spec |
| 19:47 | <WeirdAl> | into... one hundred BILLION bits! |
| 19:48 | <rniwa> | oh wait, no. that's not what sicking said. |
| 19:50 | <rniwa> | WeirdAl: my spec is forged in Mount Doom. I'm not sure if the destruction is possible. |
| 19:50 | <WeirdAl> | :D |
| 19:51 | <WeirdAl> | so are you now Sauron? |
| 19:55 | <ehsan> | rniwa: wait, is it not? |
| 19:55 | <ehsan> | sicking? |
| 19:55 | ehsan | is totally confused now |
| 19:56 | <rniwa> | ehsan: I think sicking suggested that we'll have implement, unapply, reapply for automatic transaction and then apply([mode]), unapply, reapply for manual transaction |
| 19:57 | <sicking> | rniwa: yes |
| 19:58 | <sicking> | rniwa: though i think the mode isn't critical. But seems useful |
| 19:58 | <sicking> | rniwa: and we can have it as a string since people seem to prefer that |
| 19:58 | <rniwa> | sicking: yeah, but not sure if this is a net win. |
| 19:58 | <rniwa> | sicking: the API is getting more complicated :( |
| 19:59 | <sicking> | rniwa: i can live with dropping it |
| 19:59 | <rniwa> | sicking: ok. |
| 19:59 | <sicking> | rniwa: it's mostly a (very small) burden for implementors. Authors can ignore it, JS ignores any extra arguments passed to a function |
| 20:00 | <rniwa> | sicking: right, but I'd like to keep the API simple as possible. |
| 20:00 | <sicking> | worst case we can add it back if people hack it in themselves by carrying extra state |
| 20:00 | <rniwa> | sicking: yeah, I guess we can figure out when we do the initial impl. in gecko & webkit. |
| 20:00 | <ehsan> | agreed |
| 20:00 | <sicking> | rniwa: well.. when people start to use it |
| 20:00 | <rniwa> | sicking: i'm thinking of writing some demo app to see how the current API works. |
| 20:01 | <sicking> | rniwa: cool |
| 20:02 | <rniwa> | sicking: so are you okay with getting rid of the argument? |
| 20:02 | <rniwa> | sicking: should we still rename the function to implement? |
| 20:03 | <rniwa> | sicking, ehsan: anyway, Jonas' response posted on whatwg |
| 20:08 | <espadrine> | About movethewebforward.org: I'm maintaining an effort to show a very fast sum-up of the new stuff added in the latest version of web specs, over at https://github.com/espadrine/New-In-A-Spec |
| 20:08 | <espadrine> | Love to get pull requests! |
| 20:24 | <paul_irish> | espadrine: should like.. publish this is a blog with a feed or something i think |
| 20:24 | <paul_irish> | the information is supervaluable but folks don't look for spec updates in a github repo :) |
| 20:24 | <espadrine> | paul_irish: probably ^^ |
| 20:24 | <espadrine> | I'll make a script to publish this automatically |
| 20:28 | <tsenart> | paul_irish: you can https://github.com/espadrine/New-In-A-Spec/commits/master.atom |
| 20:29 | <paul_irish> | i know that it's possible..... |
| 20:29 | <paul_irish> | but that's not exactly the same as more of a blog type setup |
| 20:29 | <tsenart> | ah you're talking about discoverability.. |
| 20:29 | <tsenart> | sure |
| 20:29 | <paul_irish> | ya and friendliness |
| 20:29 | <tsenart> | makes sense |
| 20:30 | <divya> | espadrine: you can use octopress :) |
| 20:31 | <espadrine> | paul_irish, tsenart: what dns name should I take? |
| 20:31 | <espadrine> | divya: I'm looking at octopress right now... ;) |
| 20:31 | <tsenart> | espadrine: use gh-pages |
| 20:31 | <tsenart> | :) |
| 20:31 | <divya> | well you can point a domain to ghpages |
| 20:31 | <divya> | webstandardupdates.com? |
| 20:31 | <divya> | specupdates? |
| 20:32 | <espadrine> | divya: very nice! |
| 20:33 | <divya> | :) |
| 20:33 | <jankeromnes> | espadrine: what about mothereffinspecupdates? |
| 20:33 | <divya> | NO |
| 20:33 | <divya> | can people stop mothereffing shit |
| 20:33 | <jankeromnes> | divya: just kidding |
| 20:33 | <divya> | it would be much appreciated by the undersigned |
| 20:33 | <espadrine> | sorry, fathereffingspecupdates ^^ |
| 20:33 | <divya> | :) |
| 20:34 | <divya> | :)) |
| 20:35 | <espadrine> | divya: I'm actually tempted both by webstandardupdates.com and specupdates.com ^^ |
| 20:35 | <divya> | hahaha |
| 20:36 | <divya> | specupdates is smaller but could also be read as spe cup dates |
| 20:36 | <divya> | :P |
| 20:36 | <espadrine> | XD |
| 20:40 | <Philip`> | espadrine: html5updates.com, for the latest news about CSS3 and geolocation and all that stuff |
| 20:43 | <espadrine> | Philip`: looks nice! but it isn't quite what I'm trying to do |
| 20:44 | <espadrine> | I'm trying to give people a very fast diff between the latest version of a spec and the previous version |
| 21:04 | <annevk> | sicking: you'll have to provide more details on how exactly text decoding in combination with chunked and progress events are supposed to wkr |
| 21:04 | <annevk> | work* |
| 21:04 | <sicking> | annevk: like HTML parsing |
| 21:04 | <gsnedders> | hsivonen: Official word is there in a comment now, quirks/no-quirks based upon HTML5, except for X-UA-Compatible, and Compatibility View. |
| 21:05 | <annevk> | sicking: ? |
| 21:05 | <sicking> | annevk: you expose the parts that you "parsed" (here, decoded), and wait for more data before exposing the parts you haven't yet parsed (decoded) |
| 21:05 | <annevk> | how do you know what to decode? |
| 21:05 | <zewt> | i wonder if buffering incremental data might cause interop problems (and if so, whether they could be prevented) |
| 21:06 | <sicking> | annevk: how do you mean? |
| 21:06 | <zewt> | line buffering would avoid it entirely, but wouldn't always be wanted |
| 21:06 | <annevk> | you get some bytes and an encoding |
| 21:06 | <annevk> | how do you go from there |
| 21:06 | <annevk> | that's not really clear to me |
| 21:06 | <annevk> | and even less clear to me is where that is currently defined |
| 21:07 | <zewt> | annevk: HTML incremental decoding must define that, right? (even if it's not quite what's wanted here, it'd be a place to start) |
| 21:07 | <annevk> | it doesn't actually since the details are not exposed |
| 21:08 | <sicking> | annevk: you decode as many bytes as you can using the encoding |
| 21:08 | <zewt> | it should be pretty straightforward for UTF-8; harder to handle it for the general case |
| 21:08 | <zewt> | (to define, I mean) |
| 21:08 | <sicking> | annevk: conceptually, any bytes that you can't decode, you store away |
| 21:09 | <sicking> | annevk: and prepend to the next hunk of bytes that you get to decode |
| 21:09 | <annevk> | sicking: plus you assume the byte stream is always encoded per the encoding |
| 21:09 | <sicking> | annevk: huh? |
| 21:09 | <zewt> | well, you still want error handling (replacement for bad UTF-8 sequences, etc) |
| 21:10 | <zewt> | (except for incomplete UTF-8 sequences, which would just be deferred for more data) |
| 21:10 | <annevk> | that does seem reasonable, but I'm not sure any of that is defined |
| 21:10 | <annevk> | I guess that should be in the encoding spec... |
| 21:11 | <annevk> | sicking: that does indeed mean that for the non-arraybuffer case .loaded is a mismatch |
| 21:11 | <annevk> | but that's prolly not too bad |
| 21:12 | <sicking> | annevk: yeah, that always been true for responseText |
| 21:12 | <zewt> | i'd expect ProgressEvent.loaded to represent the underlying stream anyway, not the high-level, decoded strings |
| 21:19 | <zewt> | i still wonder about buffering, though; it probably wouldn't be hard for scripts to accidentally depend on the buffering behavior of a particular browser |
| 21:20 | <zewt> | i suppose browsers shouldn't actually buffer data (that is, send an event immediately as soon as no more data is available to read), but you'd get the same effect from different MTUs, etc |
| 21:56 | <espadrine> | http://espadrine.github.com/New-In-A-Spec/ is really ugly right now, I'll make it prettier tomorrow ;) |
| 21:59 | <TabAtkins> | espadrine: Ooh, useful! Thanks! |
| 22:01 | <espadrine> | ;) |
| 22:03 | <Philip`> | espadrine: Oh, I didn't realise there was already an html5updates.com - I was just suggesting it as a name for your site :-) |
| 22:03 | <rniwa> | zewt: was it you who wanted to have an informal meet ups for undo manager? |
| 22:03 | <AryehGregor> | jgraham, fortunately, my bride is the one who has to pick a dress, not me. I have to get men's clothing, but that's amazingly easier. |
| 22:04 | <divya> | ooooooooooo espadrine!!! |
| 22:04 | <divya> | FAST STUFF |
| 22:05 | <espadrine> | ^^ |
| 22:05 | <rniwa> | AryehGregor: hi |
| 22:05 | <AryehGregor> | rniwa, hi. |
| 22:05 | <rniwa> | AryehGregor: what do you feel about the discussion on your feedback thread |
| 22:05 | AryehGregor | hasn't looked at anything spec-related in a week |
| 22:05 | <espadrine> | Philip`: would have been a nice name too ;) |
| 22:05 | <rniwa> | AryehGregor: about isReapply being problmatic when wealways call reapply |
| 22:06 | <AryehGregor> | I'm getting married in twelve days, so I'm a little distracted by other things. |
| 22:06 | <rniwa> | AryehGregor: ok. |
| 22:06 | <rniwa> | AryehGregor: I'm preparing my spec to be implementation-ready |
| 22:06 | <AryehGregor> | Okay, good. |
| 22:06 | <rniwa> | AryehGregor: I guess I'll leave as is then |
| 22:06 | <jgraham> | AryehGregor: You're not scottish then :) |
| 22:06 | <rniwa> | AryehGregor: we can always amend later |
| 22:06 | <AryehGregor> | k. |
| 22:07 | <rniwa> | jgraham: what did you think of the spec? > undomanager |
| 22:07 | <AryehGregor> | jgraham, I'm about as non-Scottish as one can get, but what specific thing were you thinking about? |
| 22:07 | <jgraham> | rniwa: I haven't read it closely yet |
| 22:07 | <jgraham> | AryehGregor: Kilts |
| 22:07 | <rniwa> | jgraham: ok. |
| 22:07 | <AryehGregor> | (The name "Gregor" comes from my grandfather changing his name from Silverman to avoid discrimination.) |
| 22:08 | <AryehGregor> | What's so hard about kilts? Get one with your clan's pattern or something and you're all set, right? |
| 22:08 | <jgraham> | AryehGregor: I ws going more with the kilt=dress thing which you can use to wind up scottish people ;) |
| 22:09 | <jgraham> | (also I didn't actually think you were Scottish) |
| 22:09 | <AryehGregor> | Surely a kilt is more like a skirt, if anything. |
| 22:09 | <jgraham> | Well yes |
| 22:10 | <rniwa> | I guess picking a dress will be tricker if bride and broom come from different countries or practice different religions |
| 22:10 | <zewt> | rniwa: nope |
| 22:10 | <rniwa> | zewt: hm... I'm wondering if there's a big demand |
| 22:10 | <jgraham> | I you marry a broom you have bigger problems |
| 22:10 | <rniwa> | zewt: if there are only 2-3 ppl interested, then I'd just have a bar conv. |
| 22:10 | <AryehGregor> | Fortunately, Orthodox Jews are only allowed to marry other Orthodox Jews, so that's not a big problem. |
| 22:11 | jgraham | wonders if genetic diversity is a big problem |
| 22:12 | <rniwa> | jgraham: oops, I meant to say groom*, not broom |
| 22:12 | <jgraham> | rniwa: :) |
| 22:12 | <rniwa> | I always get those two confused for whatever reason |
| 22:12 | <AryehGregor> | jgraham, it can be. Tay-Sachs disease is a serious issue. It's common for religious Jews to undergo testing for recessive genetic disorders before getting married. |
| 22:12 | <AryehGregor> | (Both my fiancée and I did, no conflicts.) |
| 22:13 | <jgraham> | Interesting |
| 22:15 | <rniwa> | I hear there's bio-tech companies that can tell you whether a couple is likely to have a child with some chronic disease or not. |
| 22:16 | <rniwa> | apparently ppl go to those places and "check things out" before they get engaged |
| 22:17 | <AryehGregor> | rniwa, yep. Basically they just test if you're a carrier of various recessive genetic disorders. |
| 22:20 | <jgraham> | Disappointingly "Jewish Genetic Disorders: A Layman's Guide" doesn't seem to be available in the libraries of Europe. |
| 22:21 | <jgraham> | You can buy it at amazon.de though |
| 22:21 | Philip` | wonders how long it'll be before you can choose your partner based on the genetic expectation of the children's attractiveness or intelligence |
| 22:21 | <AryehGregor> | Tay-Sachs is the one everyone talks about. If you get two copies of the gene, your brain turns into fat by the time you're eight or so. |
| 22:22 | <AryehGregor> | Philip`, if you buy evolutionary psychology, that's sort of what everyone tries to do already. |
| 22:22 | <Philip`> | AryehGregor: Humans are rubbish at computing DNA combinations in their heads, though |
| 22:23 | <jgraham> | I'm not sure that intelligence is heavily selected for |
| 22:23 | <AryehGregor> | Philip`, no, they just use approximations that trade off a great deal of accuracy for drastically higher efficiency. |
| 22:24 | <jgraham> | By which I mean, it is unclear to me that people with a large choice of sexual partners go for more intelligent ones a disproportiante amount of the time |
| 22:24 | <rniwa> | Philip`: i'm not sure if that's really desirable |
| 22:25 | <jgraham> | Compared with their prospenity to go for more physically attractive ones |
| 22:25 | <rniwa> | Philip`: you might be a perfect match to someone genetically but your personality, etc... may not match well. |
| 22:25 | <jgraham> | rniwa: (I don't think Philip` said it was *desirable*) |
| 22:25 | <AryehGregor> | jgraham, it varies culturally. The Jewish ideal as recorded in the Talmud and medieval rabbinic texts is that women should marry the greatest Torah scholar they can, and men should try to marry the daughter of a great Torah scholar. That's heavily correlated with intelligence. |
| 22:25 | <rniwa> | jgraham: I think it depends. |
| 22:26 | <AryehGregor> | Someone or other theorizes this led to Jews becoming smart. I didn't make this up, I think a Wikipedia article says it, so it's probably true. |
| 22:26 | <Philip`> | AryehGregor: I bet it was a Torah scholar who came up with that rule |
| 22:26 | <rniwa> | jgraham: I have a hypothesis that a lot of women tend to go with the intelligent ones whereas a lot of men go with pretty ones. |
| 22:26 | <AryehGregor> | Philip`, admittedly, yeah, rabbinic texts tend to be written by Torah scholars. |
| 22:26 | <jgraham> | AryehGregor: Is it borne out by how they actually act? I mean if I were a scholar recording cultral ideals, I might claim the same thing |
| 22:26 | <jgraham> | Oh, Philip` already said that |
| 22:27 | <jgraham> | rniwa: That might be true. |
| 22:28 | <AryehGregor> | jgraham, not completely, but in a lot of Jewish communities today, yeah, to a large extent. I dated girls who made sure to emphasize how many of their male relatives were studying Torah. In certain Orthodox communities, any man who's not studying Torah full-time has no chance of finding a respectable woman who will marry him. |
| 22:28 | <AryehGregor> | In other communities, not so much. |
| 22:28 | <jgraham> | There is probably data somewhere, but it is never easy to work out what to search for or whether the study is worthless |
| 22:29 | <AryehGregor> | Data about what? |
| 22:29 | <jgraham> | About rniwa's hypothesis |
| 22:30 | <AryehGregor> | Oh, that. |
| 22:30 | <TabAtkins> | AryehGregor: An alternate (or perhaps complementary) hypothesis was the fact that the money-handling professions were relegated to Jews in Europe for several centuries. |
| 22:31 | <gsnedders> | AryehGregor: Well, the daughter of a great Torah scholar may not themself be intellifent. |
| 22:31 | <gsnedders> | (wrt correlation with intelligence) |
| 22:32 | <Philip`> | If all the men are spending all their time studying the Torah, does that mean that all the useful work has to be done by the women? |
| 22:33 | <mkanat> | I think that's partially why the ideal is to be studying the Torah, because it's an ideal one would have to strive for--not all the men could spend all their time doing it. |
| 22:34 | <mkanat> | Unless they had been very successful in life--or, I suppose in a large enough community, if they were the rabbi. |
| 22:35 | <AryehGregor> | TabAtkins, money-handling doesn't require a lot of intelligence, though. |
| 22:35 | <AryehGregor> | gsnedders, intelligence has a large genetic component, so there'll be a correlation. |
| 22:36 | <AryehGregor> | Philip`, bingo! In places like Lakewood, New Jersey, all the men study Torah full-time while their wives work. And also take care of ten children. |
| 22:36 | <mkanat> | This is super off-topic, but genetic links to intelligence are more correlation than causation. |
| 22:36 | <TabAtkins> | AryehGregor: It requires math skills, which is something that Jews are traditionally considered good at. |
| 22:36 | <AryehGregor> | And they live in poverty and are supported by as much government aid as they can scrounge up. |
| 22:36 | <AryehGregor> | TabAtkins, moneylending doesn't require much math. A little, but nothing special. |
| 22:36 | <jgraham> | mkanat: [citation needed] |
| 22:37 | <mkanat> | AryehGregor: But it does require a meticulous attention to detail. |
| 22:37 | <mkanat> | jgraham: That was more or less my sentiment. ;-) |
| 22:38 | <AryehGregor> | mkanat, IQ is generally reported to have fairly high heritability, say 0.4 to 0.6 or something. I don't quite get what heritability means, but it tends to be computed based on things like "identical twins separated at birth have more similar IQs than fraternal twins not separated at birth, so genetics seems to be awfully important". |
| 22:38 | <Philip`> | Correlation is correlated to causation |
| 22:38 | <jgraham> | It's not realy clear why being left to money handling professions for a few hundred years would make you more intelligent as a population |
| 22:38 | <AryehGregor> | http://en.wikipedia.org/wiki/Heritability_of_IQ |
| 22:38 | <paul_irish> | o |
| 22:39 | <mkanat> | jgraham: The culture of Judaism has a very strong focus on education. |
| 22:39 | <jgraham> | It would be very surprising if a particular part of biochemisty wasn't inherited |
| 22:39 | <TabAtkins> | jgraham: Assuming that money-handling professions have their success correlated at least somewhat with mathematical intelligence, then it seems reasonable that such a trait would be encouraged in the population. |
| 22:39 | <jgraham> | TabAtkins: It isn't really clear that a few hundred years would make much difference |
| 22:39 | <jgraham> | (maybe it would, I don't know) |
| 22:39 | <AryehGregor> | jgraham, you can have tons of selection in a few hundred years, if the pressure is strong. |
| 22:40 | <TabAtkins> | jgraham: When you're mostly doing selection, and have a sufficiently isolated population, that's an adequate number of generations. |
| 22:40 | <AryehGregor> | For instance, skin color tends to adjust to climate within 1000 years, IIRC. |
| 22:40 | <jgraham> | Right, but how strong would the pressure be? |
| 22:40 | <jgraham> | Everyone needs somebody to do less skilled jobs |
| 22:40 | <jgraham> | So it's not like all the less intelligent people are going to starve |
| 22:41 | <TabAtkins> | jgraham: That's kind of the beauty of this just-so story - European Jews were part of the wider European population, but only bred among themselves. |
| 22:41 | <AryehGregor> | If everyone is trying to marry the biggest scholar, potentially very strong. Because then the scholars get the wives who have the biggest dowries (medieval Europe, remember) and get to provide very well for their kids. |
| 22:41 | <mkanat> | AryehGregor: This is somewhat relevant when you talk about genetic research: http://www.ploscompbiol.org/article/info%3Adoi%2F10.1371%2Fjournal.pcbi.1002240 |
| 22:41 | <rniwa> | jgraham: traditionally, men with lots of wealth tend to have lots of kids |
| 22:42 | <AryehGregor> | mkanat, well, yes, medical studies tend to be mostly complete garbage. |
| 22:42 | <rniwa> | jgraham: just because they can afford them |
| 22:42 | <AryehGregor> | There's a better reference for that. |
| 22:42 | AryehGregor | looks it up |
| 22:42 | <AryehGregor> | mkanat, http://www.theatlantic.com/magazine/archive/2010/11/lies-damned-lies-and-medical-science/8269/ |
| 22:42 | <mkanat> | AryehGregor: Ah yeah, I think I read that article. :-) |
| 22:42 | <AryehGregor> | (yes, it's a popular article, I didn't read the studies it's based on, so sue me) |
| 22:43 | <AryehGregor> | I think anyone who's had personal exposure to actual academic research realizes it's mostly garbage that people are shoving out the door by hook or by crook so they can get more publications on their CV and get ahead in the tenure rat-race. |
| 22:43 | <jgraham> | Sure, I'm not suggesting that it is impossible to evolve a noticable change in average intelligence in a few hundred years |
| 22:43 | <rniwa> | jgraham: so on top of selection by their partners, there might be additional pressure which is that more intelligent ones will have lots of decendents |
| 22:43 | <jgraham> | I am just noting that without any sort of model or running th numbers, it is very far from obvious that it is a workable explaination |
| 22:44 | <AryehGregor> | rniwa, historically, no one had much choice in how many kids they had -- it was determined by how early you married, how many women you married (for men, if polygyny is allowed), and whether/how soon you remarried upon your spouse's death. |
| 22:44 | <AryehGregor> | jgraham, there was some guy who studied it. |
| 22:44 | AryehGregor | looks it up |
| 22:44 | <AryehGregor> | Of course: http://en.wikipedia.org/wiki/Ashkenazi_Jewish_intelligence |
| 22:44 | <rniwa> | AryehGregor: well rich guys used to have many wives |
| 22:45 | <AryehGregor> | Link to study that I never read: http://harpending.humanevo.utah.edu/Documents/ashkiq.webpub.pdf |
| 22:45 | jgraham | notes that today it is strongly correlated with how poor you are |
| 22:45 | <AryehGregor> | rniwa, not in Europe. The Church didn't allow polygyny. |
| 22:45 | <AryehGregor> | (nor did European Jews, although Middle Eastern Jews did, like the surrounding Muslims) |
| 22:45 | <rniwa> | AryehGregor: i guess that's true in the dark ages |
| 22:46 | <AryehGregor> | rniwa, from early medieval times up to the present day. |
| 22:46 | <rniwa> | AryehGregor: that's on principal. |
| 22:46 | <AryehGregor> | Well, men had mistresses, that's true. |
| 22:46 | <AryehGregor> | Not multiple wives, but unofficially, yeah. |
| 22:47 | <mkanat> | jgraham's right; there's a TED talk on this. |
| 22:47 | <rniwa> | AryehGregor: e.g. Chinese government prohibits polygyny but polygyny has become a status quo in China from what I've heard. |
| 22:47 | <jgraham> | AryehGregor: That paper is quite long and doesn't have any graphs. |
| 22:47 | <AryehGregor> | Especially the really wealthy and powerful. |
| 22:47 | <rniwa> | AryehGregor: right. |
| 22:47 | <rniwa> | AryehGregor: mistresses is probably more accurate. |
| 22:47 | <AryehGregor> | But as far as Ashkenazi Jews go, note that being a great Torah scholar is going to be highly correlated with marital fidelity. |
| 22:47 | <AryehGregor> | jgraham, that's why I read three sentences of the Wikipedia article instead. |
| 22:48 | AryehGregor | reads a whole section |
| 22:48 | <gsnedders> | AryehGregor: In the early Church, under the Roman empire, polygyng was common |
| 22:48 | <AryehGregor> | It looks like the paper focuses more on what TabAtkins suggested. |
| 22:48 | <AryehGregor> | gsnedders, the really really early Church. |
| 22:49 | <gsnedders> | Common is untrue, really. Unusual, but not rare. |
| 22:50 | <AryehGregor> | http://en.wikipedia.org/wiki/Polygamy_in_Christianity |
| 22:51 | <AryehGregor> | Polygamy can never be really "common". I mean, at most 50% of the men in any population can practice it, typically. |
| 22:51 | <AryehGregor> | It was only ever doable for a wealthy minority. |
| 22:51 | <gsnedders> | Certainly Luther didn't frbid it in the Luteran churches, AFAIK |
| 22:51 | <gsnedders> | (To take a more recent case) |
| 22:51 | <jgraham> | AryehGregor: The wikipedia article is actually very interesting |
| 22:52 | <jgraham> | So much so it should probably be deleted :p |
| 22:52 | <gsnedders> | But certainly now it is rare |
| 22:52 | <AryehGregor> | gsnedders, the Wikipedia article suggests it was condemned by the early Catholic Church, but some Protestants reconsidered it. |
| 22:52 | <AryehGregor> | The Bible doesn't actually say anything against it, so it's natural that the Protestants would want to throw out the restriction -- sola scriptura, right? |
| 22:54 | <jgraham> | I am pretty sure pretty sure there are examples of cultures that practice what I will call "cooperative" or many-to-many polygamy |
| 22:55 | <gsnedders> | AryehGregor: Depends very much on the Protestant sect |
| 22:56 | <AryehGregor> | Polyandry of any kind is very uncommon, because a) women don't get any more children (or any other obvious benefit) by marrying multiple men, and b) people won't know who their father is, which will (among other things) discourage fathers from supporting children who may or may not be theirs. |
| 22:56 | <AryehGregor> | On the other hand, polygyny is pretty common, because it allows wealthy men to have more children while also supporting their multiple wives to higher standards than they'd have gotten as the sole wife of a poorer person. |
| 22:56 | <gsnedders> | AryehGregor: Many Protestants broke off from the Catholic Church at different times, often for specific reasons, so only changed what affected their specific reason to break off |
| 22:58 | <gsnedders> | AryehGregor: sola scriptura only happened in a relatively small number of cases, though many smaller sects joined with ones who had been through more radical transformations |
| 22:59 | <jgraham> | AryehGregor: http://www.sciencedaily.com/releases/2010/11/101110161930.htm?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+sciencedaily+%28ScienceDaily:+Latest+Science+News%29&utm_content=Google+Reader claims that in some regions it has been common |
| 23:00 | <AryehGregor> | Well, it's far less common than polygyny, anyway. |
| 23:00 | <AryehGregor> | Polygyny is more the rule than the exception, as far as I know. |
| 23:02 | <gsnedders> | Most of the polyamourous couples I know are polyandric (well, not truly, as they aren't married) |
| 23:02 | <othermaciej> | polyandry tends to occur in societies with a severe shortage of women (e.g. ones that severely undervalue daughters and therefore practice female infanticide) |
| 23:02 | <jgraham> | Note that for women there is a benefit to having children by multiple partners; you are increasing the genetic diversity of your offspring |
| 23:03 | <jgraham> | Which is an "obvious benefit" |
| 23:03 | <AryehGregor> | Not really. |
| 23:03 | <AryehGregor> | It doesn't increase your expected number of offspring much, if at all. |
| 23:03 | <jgraham> | From an evolutionary point of view it is |
| 23:03 | <AryehGregor> | (I mean total descendants) |
| 23:03 | <jgraham> | Sure it does |
| 23:04 | <AryehGregor> | How? |
| 23:04 | <AryehGregor> | If some plague kills everyone without gene X, you shouldn't care whether one of your two husbands has gene X, or if you only have one husband with a 50% chance of having gene X. |
| 23:04 | <jgraham> | If you pick one partner who happens to give you children that are all infertile you get 0 grandchildren. If you pick two partners and only one has that problem you get some grandchildren |
| 23:05 | <AryehGregor> | Look at the expected values, though. |
| 23:05 | <AryehGregor> | If you pick one partner and they have a 50% chance of their children all being infertile, it's the same expected number of grandchildren as if you marry two men and one has the problem. |
| 23:06 | <AryehGregor> | On the other hand, if you have only one husband and he's confident all your children are his, he'll probably be a lot happier to support them, which makes a big difference. |
| 23:06 | <mkanat> | In fact, I'd have to guess (without doing the math) that you'll have better generic diversity across and entire race with monogamy. |
| 23:06 | <mkanat> | *genetic |
| 23:06 | <AryehGregor> | Especially in agricultural societies, where men have all the wealth and women need all the help they can get from their husbands. |
| 23:07 | <jgraham> | You never care about "across the entire race" |
| 23:07 | <jgraham> | You only optimise for your own grandchildren |
| 23:08 | jgraham | is too tired to reason through the maths at the moment |
| 23:08 | <jgraham> | and should indeed be sleeping |
| 23:09 | <jgraham> | But it would seem surprising if having more genetic diversity in your offspring was a bad thing |
| 23:10 | <AryehGregor> | I don't think genetic diversity matters for this purpose. |
| 23:10 | <AryehGregor> | It should be all the same whether you actually have diversity, or you have random-picked homogeneity. |
| 23:11 | <jgraham> | I am going to try the sleeping thing :) |
| 23:22 | <erlehmann> | AryehGregor, polythings can be common if they are not exclusive. |
| 23:24 | <erlehmann> | >"In some Amazonian cultures, it was bad manners for a husband to be jealous of his wife's extramarital partners," |
| 23:24 | <erlehmann> | in fact, i consider jealousy a bad character trait |
| 23:25 | <gicode> | AryehGregor: Do you know if the DOM4 spec for Range will eventually include getBoundingClientRect and/or the mutation APIs like modify/extend that are part of Selection? |
| 23:25 | <AryehGregor> | gicode, I think getBoundingClientRect might already be specced elsewhere. |
| 23:25 | AryehGregor | looks |
| 23:26 | <AryehGregor> | CSSOM View. |
| 23:26 | <AryehGregor> | http://dev.w3.org/csswg/cssom-view/#extensions-to-the-range-interface |
| 23:26 | <AryehGregor> | extend() doesn't make any obvious sense for Range, because there's no concept of a focus or anchor. |
| 23:26 | <AryehGregor> | So I don't see how you'd figure out which direction to extend. |
| 23:27 | <AryehGregor> | modify() is an unholy mess and I'll be grateful if anyone can come up with a usable spec for that as a Selection method, forget about Range. |
| 23:27 | <gicode> | AryehGregor: Thanks, I wasn't aware of that section in the CSS spec |
| 23:28 | <AryehGregor> | CSSOM View, not CSS. |
| 23:29 | <gicode> | AryehGregor: Sorry, CSSOM View :-) For the modify/extend, the main thing I am looking for is an implementation of Unicode Text Segmentation |
| 23:29 | <AryehGregor> | That's not relevant to extend(). |
| 23:30 | <AryehGregor> | For modify(), I'm pretty sure browsers currently implement it using voodoo magic, not Unicode Text Segmentation. |
| 23:31 | <gicode> | Yay, magic! Thanks for the heads up. |
| 23:32 | <AryehGregor> | That's why I stopped trying to spec it. |
| 23:32 | <AryehGregor> | WebKit made it up and Gecko copied it. I didn't look, but I suspect WebKit reused whatever internal code they happened to have lying around that did vaguely the right thing. |
| 23:32 | <rniwa> | gicode: what about unicode text segmentation? |
| 23:32 | <AryehGregor> | Getting it correct would probably require a great deal of work, because there are going to be like four billion subtle special cases where you want it to do magic. |
| 23:33 | <AryehGregor> | It depends on layout, too, which is fun. |
| 23:33 | <gicode> | rniwa: Specifically iterating over words (rather than space delimited tokens) |
| 23:33 | <rniwa> | gicode: modify works on visual text but all you get is DOM-based selection |
| 23:33 | <gsnedders> | AryehGregor: IIRC, we should use Unicode Text Segmentation |
| 23:33 | <AryehGregor> | Moving one line down needs to figure out where the cursor is visually and where it will go. |
| 23:33 | <AryehGregor> | gsnedders, does Opera implement modify()? |
| 23:33 | <rniwa> | gicode: oh, sure, you can do that using modify. |
| 23:33 | <gsnedders> | Or am I forgetting things? |
| 23:34 | <rniwa> | gicode: selection.modify will be much more useful once we can just instantiate it |
| 23:34 | <rniwa> | gicode: e.g. (new Selection).modify(~~) |
| 23:34 | <AryehGregor> | The definition of "word" varies by platform, as well as language. |
| 23:34 | <rniwa> | AryehGregor: right, that's why we need a method like modify in order to iterator over |
| 23:35 | <rniwa> | AryehGregor: we should add a constructor to DOMSelection so that ppl can just instantiate it |
| 23:35 | <gicode> | rniwa: If you instantiate one, what is it selecting? |
| 23:35 | <rniwa> | AryehGregor: modify and some other methods become much more useful |
| 23:35 | <rniwa> | gicode: nothing |
| 23:35 | <rniwa> | gicode: it's an non-visible object like range |
| 23:35 | <gsnedders> | AryehGregor: Okay, no |
| 23:36 | <rniwa> | gsnedders: in CJK, you can't reliably separate words |
| 23:36 | <rniwa> | gsnedders: since there are no word seperators |
| 23:36 | <rniwa> | gsnedders: you need to use dictionary-based heuristics |
| 23:39 | <AryehGregor> | rniwa, per spec, the interface is called Selection, not DOMSelection, BTW. |
| 23:39 | <gsnedders> | rniwa: Right, but USA #29 provides non-locale aware algorithms |
| 23:39 | <AryehGregor> | (there's no window.Selection in WebKit for some reason) |
| 23:39 | <rniwa> | gsnedders: I don't think it's really useful |
| 23:39 | <gsnedders> | *UAX |
| 23:40 | <rniwa> | gsnedders: in general, unicode ppl don't get CJK. |
| 23:40 | <rniwa> | especially C and J |
| 23:40 | <rniwa> | gsnedders: there are quite few Unicode-haters in Japan at least. |
| 23:40 | <gicode> | AryehGregor: In Chromium, Range seems to have all the selection APIs |
| 23:40 | <AryehGregor> | gicode, that's weird. |
| 23:41 | <AryehGregor> | Uncaught TypeError: Object has no method 'extend' |
| 23:41 | <AryehGregor> | Doesn't seem like it to me. |
| 23:42 | <gicode> | AryehGregor: Ah, yea. I saw expand and got confused. |
| 23:43 | <AryehGregor> | WebKit has lots of made-up nonstandard methods on Range and Selection. It's annoying. |
| 23:43 | <AryehGregor> | Some of them aren't useful, either, like setBaseAndExtent(). |
| 23:43 | <AryehGregor> | (= collapse() followed by extend()) |
| 23:46 | <rniwa> | AryehGregor: so... I've recently learned that base != anchor and extent != focus |
| 23:46 | <AryehGregor> | Really? |
| 23:46 | <rniwa> | AryehGregor: yeah |
| 23:46 | <AryehGregor> | That's even more confusing. |
| 23:46 | <rniwa> | AryehGregor: when you double-click a word |
| 23:46 | <rniwa> | AryehGregor: base and extent stays at where you clicked |
| 23:46 | <rniwa> | AryehGregor: whereas focus/anchor will be at the end and the beginning of the word |
| 23:46 | <AryehGregor> | I'd file a bug asking that this nonstandard stuff be removed, but somehow I suspect the answer would be "no, lots of WebKit-specific stuff depends on it, we should just standardize it instead". |
| 23:48 | <rniwa> | AryehGregor: yeah... |
| 23:48 | <rniwa> | AryehGregor: but nobody knows the difference |
| 23:48 | <rniwa> | AryehGregor: so maybe we can at least hide it from Web-facing API |
| 23:48 | <AryehGregor> | That would be nice. |
| 23:48 | <AryehGregor> | It seems like unnecessary complication. |
| 23:49 | <rniwa> | AryehGregor: I tend to agree but then I'm not the one who added that feature |
| 23:49 | <rniwa> | so we probably need to talk to whoever knows about this stuff |
| 23:49 | <AryehGregor> | If Gecko is willing to remove multi-Range Selections, WebKit should be willing to make sacrifices too. :) |
| 23:55 | <rniwa> | AryehGregor: I tend to agree but then webkit has a lot of companies involved so it's hard for me to make a call. |
| 23:55 | <AryehGregor> | Right. |
| 23:56 | <rniwa> | AryehGregor: we can probably start from spitting out console messages |