| 01:42 | <roc> | hmm |
| 05:26 | <zewt> | youtube is using onmouseup events for link clicks in search results instead of onclick : | |
| 05:27 | <zewt> | inspires something less than hope when major sites can get something so basic so horribly wrong |
| 06:23 | <heycam> | when was svg/mathml support first added to the html parser? |
| 07:02 | <nessy> | zewt: I think they are simple <a> tags around the clickable text - I don't quite follow what the problem is |
| 07:03 | <zewt> | select text in the search results; release the mouse and it treats it as a click |
| 07:39 | <zcorpan> | heycam|away: somewhere between 2007-10-26 and 2009-10-27 |
| 07:40 | <zcorpan> | heycam|away: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014372.html |
| 08:03 | <hsivonen> | Are IANA registries versioned? |
| 08:08 | <heycam> | zcorpan, thanks |
| 08:19 | <tantek> | hsivonen, you mean like wiki pages? not that I've ever seen. |
| 08:53 | hsivonen | disagrees with Hixie characterizing transparent content models by "simply" |
| 09:04 | <nessy> | zewt: that's not what happens to me, strange. What browser version and platform are you on? |
| 10:10 | <annevk> | zewt: the problem with UTF-16 is that it is ingrained in many APIs (which I suppose is not really UTF-16 per se, but rather the 16bit code unit system we have) |
| 10:10 | <annevk> | zewt: so it comes up all the time |
| 10:10 | <annevk> | zewt: whereas legacy encodings is not really an implementation issue, it is a platform issue |
| 10:11 | <annevk> | both are bad and like you I don't think we can fix the 16bit code unit mess |
| 10:11 | jgraham | doesn't see the value of arguing whether UTF16 or legacy encodings are the worse issue when everyone involved thinks they are both bad |
| 10:12 | <annevk> | the point is that one is worse for the platform and the other is worse for implementors |
| 10:12 | <annevk> | hsivonen was arguing the implementor point, zewt the platform point |
| 10:16 | <hsivonen> | jgraham: there's really no point arguing which is worse. my main point was that when someone implies UTF-16 is OK for interchange, the credibility of what they otherwise say about encoding problems goes down |
| 10:18 | <michel_v_> | imho, utf16 was a naive solution, like "extended ascii" sets |
| 10:23 | <zcorpan> | now why hasn't firefox implemented MessageChannel yet? |
| 10:24 | <annevk> | smaug____ thinks it's too complicated |
| 10:24 | <annevk> | not sure if that's the actual reason |
| 10:25 | <zcorpan> | -_- |
| 10:25 | <zcorpan> | i'd say, too late to bikeshed that api |
| 10:29 | <hsivonen> | creepy. I can see my what I've searched on Android Market in the logs Android keeps on my device |
| 10:30 | <hsivonen> | seems like a bad idea to dump request URLs in a log file |
| 10:30 | <annevk> | kennyluck: thanks for sending that email btw, if I hadn't thanked you already; lets hope site-comments agrees :) |
| 10:47 | <annevk> | AryehGregor: so there's no special pages for such operations on the wiki? |
| 10:47 | <annevk> | AryehGregor: mkay |
| 10:56 | <smaug____> | MessageChannel and ports etc are horrible |
| 10:56 | <smaug____> | but that isn't the reason why it hasn't been implemented in FF |
| 10:56 | <smaug____> | bent might know more about the implementation |
| 10:57 | <smaug____> | or the reasons to not implement it |
| 11:00 | <zcorpan> | i agree that ports are confusing |
| 11:01 | <jgraham> | Why are they confusing? Or what's the better solution? |
| 11:01 | jgraham | is curious because he used a port-like API for something unrelated |
| 11:02 | <zcorpan> | i couldn't think of a better solution when we implemented ports (and workers) in opera, and i haven't come up with a better solution now, either |
| 11:04 | <zcorpan> | not sure why, maybe it's unnatural to have stuff going on in multiple places (windows or workers), and it's not always clear in the spec what's happening where |
| 11:04 | <smaug____> | and some ports aren't working etc |
| 11:04 | <smaug____> | (I mean if the port has been sent to elsewhere) |
| 12:01 | <annevk> | http://blog.whatwg.org/weekly-encoding-woes |
| 13:07 | <annevk> | we should have a shorthand for "If this throws an exception, re-throw the exception and terminate these steps." or make it the default somehow |
| 13:08 | <jgraham> | Ecmascript just makes it the default |
| 13:09 | <jgraham> | I mean that is how exceptions work in general so it is very surprising that it is not like that by default in specs |
| 13:09 | <jgraham> | "If an algorithm is defined to “throw an exception”, execution of the algorithm is terminated and no result is returned. The calling algorithms are also terminated, until an algorithm step is reached that explicitly deals with the exception, using terminology such as “If an exception was thrown…”. Once such an algorithm step has been encountered the exception is no longer considered to have occurred." |
| 13:30 | <hsivonen> | hmm. why do Opera Mobile and Opera Mini disagree about the viewport width in em on the same device? |
| 13:31 | <hsivonen> | more curiously still, why does Opera Mobile disagree with Opera Mobile Emulator launched with the profile for the device in question? |
| 13:31 | <hsivonen> | kinda defeats the point of the emulator |
| 13:32 | <Velmont> | hsivonen: They are quite different though. Maybe it's because presto version is different, or because Mini is just quite different. |
| 13:32 | <Velmont> | Wow, that was a bad sentence. :-) |
| 13:33 | <annevk> | http://blog.mozilla.com/dherman/2011/12/01/now-thats-a-nice-stache/ is kind of interesting in the context of whether we should have chaining in our APIs |
| 13:33 | <annevk> | I'm flip flopping again I think to "no" |
| 13:34 | <hsivonen> | whoever does QA on Opera Mobile Emulator might be interested in comparing http://hsivonen.iki.fi/test/width-in-em.html with Opera Mobile on the actual devices that the emulator claims to emulate |
| 13:35 | <hsivonen> | I see a discrepancy between Galaxy Tab 10.1 on the emulator vs. real device |
| 13:36 | <hsivonen> | (I tested portrait mode) |
| 13:38 | <hsivonen> | Velmont: there's no inherent reason why Opera Mini and Opera Mobile on a given device should consider the view port to have a different width measured in ems by default |
| 13:38 | <hsivonen> | sure, Mini and Mobile could simply have a different default font size |
| 13:38 | <hsivonen> | or a different device pixel to CSS px ratio |
| 13:39 | <hsivonen> | but neither of those needs to arise from the architecture differences |
| 13:52 | <annevk> | http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#mutation-methods |
| 13:52 | <annevk> | and e.g. the end of http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#element IDL if you want to see the IDL syntax |
| 13:53 | <jgraham> | annevk: You need to explain wht a macro is |
| 13:54 | <jgraham> | Also, it isn't yet clear why it needs to be a macro rather than a function that returns node |
| 13:54 | <annevk> | that bit doesn't really matter |
| 13:54 | <annevk> | I suspect it will change over time |
| 13:55 | <jgraham> | Fair enough, but you introduced a new and confusing spec construct :) |
| 13:55 | <annevk> | well you grasped what it did within 1 minute |
| 13:56 | <annevk> | and I'm targeting you with this text, so I'm not too worried |
| 13:56 | <annevk> | I need to write some domintro boxes too |
| 13:56 | <hsivonen> | When Galaxy Tab 10.1 is in the portrait mode, Firefox Aurora, the default browser and Opera emulator think it's 50em wide. Opera Mobile think it's 40em wide and Mini thinks it's 30em wide |
| 13:57 | <hsivonen> | big differences in defaults |
| 13:57 | <jgraham> | Well in this case yeah. But only because it was so simple that it wasn't really needed :) |
| 13:57 | <jgraham> | hsivonen: Sounds like it could be a bug, but I'm not really sure who to talk to |
| 13:57 | <zcorpan> | annevk: webidl is confusing as it is. don't make it worse. :) |
| 13:57 | <annevk> | <dfn> names are just names |
| 13:57 | <annevk> | zcorpan: suggestion? |
| 13:58 | <zcorpan> | annevk: use overloading |
| 13:58 | <annevk> | we have used this construct before, just with other names, not sure what works best |
| 13:58 | <annevk> | zcorpan: doesn't work |
| 13:58 | <hsivonen> | jgraham: the Mobile vs. Mobile Emulator discrepancy intuitively has to be a bug |
| 13:59 | <annevk> | m(X...); m(A...); != m(X | A...) |
| 13:59 | <annevk> | ; |
| 14:00 | <zcorpan> | annevk: what's the difference? |
| 14:02 | <zcorpan> | the latter can mix X and A ? |
| 14:02 | <annevk> | zcorpan: correct |
| 14:02 | <annevk> | zcorpan: see https://www.w3.org/Bugs/Public/show_bug.cgi?id=14188 |
| 14:03 | <annevk> | I'd be happy with better syntax |
| 14:03 | <annevk> | A | X... is not especially clear |
| 14:03 | <annevk> | I guess you could do (A | X)... but that's even worse |
| 14:08 | <zcorpan> | void append(Node or DOMString... nodes) |
| 14:10 | <annevk> | Document or DocumentType or DOMString |
| 14:10 | <annevk> | I guess that could work |
| 14:10 | <annevk> | suggest it in the bug |
| 14:12 | <zcorpan> | done |
| 14:33 | <annevk> | http://wasteaguid.info/ haha |
| 14:36 | <jarek> | is there any way to have the same DOM node displayed in two different places? |
| 14:37 | <jarek> | in javascript objects are copied always by reference, it would make sense if we could have several elements on the screen that reference to the same DOM object |
| 14:38 | <jarek> | s/it would make sense/it could make sense |
| 14:39 | <annevk> | that would have to be a CSS feature |
| 14:39 | <annevk> | CSS creates the render tree, not the DOM |
| 14:39 | <jarek> | annevk: yeah, I have already told about -moz-element() |
| 14:40 | <smaug____> | you can use an element as a background |
| 14:40 | <jarek> | s/have/was |
| 14:40 | <jarek> | sorry for typos |
| 14:40 | <smaug____> | yes, -moz-element |
| 14:40 | <jarek> | but there is nothing like this on other browsers |
| 14:41 | <smaug____> | jarek: if the element itself would have two representations, element.style would be strange |
| 14:41 | <smaug____> | or computedStyle |
| 14:41 | <smaug____> | jarek: file bugs to get -moz-element like functionality to other browsers |
| 14:42 | smaug____ | doesn't remember if CSS WG is spec'ing -moz-element |
| 14:48 | <david_carlisle> | annevk: "My collegae Karl " |
| 14:52 | <annevk> | thanks |
| 14:52 | <annevk> | there's so many red in technical posts it's hard to spot the real mistakes sometimes |
| 14:55 | <jgraham> | You obviously meant to write collage, reflecting him as the sum of many pieces of his environment |
| 14:57 | <annevk> | heh, Karl would approve of that |
| 14:58 | <annevk> | next time I'll just go with friend |
| 14:58 | <annevk> | much easier to spell |
| 15:25 | <zewt> | annevk: we were talking about utf-16 as an interchange format, not about utf-16 as an API format, FWIW; anyway yeah both cases suck :) |
| 15:37 | <bga> | http://stackoverflow.com/questions/1257818/javascript-distributed-computing |
| 15:37 | annevk | wonders where ms2ger is |
| 15:38 | annevk | will patch the innerHTML spec |
| 15:48 | <jgraham> | annevk: Maybe Ms2ger is having unplanned downtime |
| 15:55 | <hober> | miketaylr: ok, we're at bocoup; thanks! :) |
| 15:55 | <miketaylr> | hober: cool! say hi to rick et al. |
| 15:55 | <hober> | will do |
| 16:09 | <annevk> | do we need to say something about this (UTF-32) in HTML: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1370.html |
| 16:09 | <annevk> | though I suspect that if nobody supports UTF-32 it's more likely the content is mislabeled |
| 16:11 | <Hixie> | as far as HTML is concerned, UTF-32 is a myth |
| 16:12 | <annevk> | more and more browsers treat it as such too these days |
| 16:12 | <annevk> | I guess I'm not going to worry about it |
| 16:20 | <zewt> | oh god, is the "other glenn" really trying to insist that browsers should support utf-32 |
| 16:24 | <annevk> | I wish it was public who ran for the TAG |
| 16:25 | <jgraham> | It's funny-sad that it isn't |
| 16:26 | <annevk> | every time people come up with some supposedly never changing technology it either has changed already or is going to change in the future |
| 16:26 | <Hixie> | who does the voting? |
| 16:26 | <annevk> | so funny |
| 16:27 | <annevk> | last example: UTF-8 |
| 16:27 | <annevk> | Hixie: AC |
| 16:27 | <Hixie> | k |
| 16:36 | <annevk> | zewt: I wonder if you're just replying to him to make it clear there's a different saner Glenn too :p |
| 16:38 | <jgraham> | Hehe, I wondered the same :) |
| 16:39 | <Philip`> | Or they'll think he's talking to himself and clearly even more insane |
| 16:41 | <jgraham> | Maybe he is insane and the two Glenns are different parts of his personality. Insane, but not creative enough to invent unique names. |
| 16:43 | <zewt> | believe me, if I was saying the things this guy did, I'd use a different name |
| 16:43 | <zewt> | did/does |
| 16:54 | <Hixie> | where is this? |
| 16:55 | <annevk> | "json" thread |
| 18:29 | <rniwa> | annevk: are you still there? |
| 18:40 | <bga> | http://mobile.twitter.com/bga_/status/143761739056553984 |
| 19:37 | <AryehGregor> | araghhahgh. I cannot believe how broken Google Docs' text selection implementation is. |
| 19:37 | AryehGregor | is glad he never tried to spec Selection.modify() |
| 20:19 | <Ms2ger> | jgraham, s/unplanned downtime/life/, sorry |
| 20:20 | <Ms2ger> | Also, s/#orthogonalApi/#uselessAcademia/ |
| 20:30 | <zewt> | gross, IE also supports utf-32, not just webkit |
| 20:31 | <zewt> | it's just a bit pickier (doesn't work if there's no doctype) |
| 20:35 | <zewt> | (ff8 interprets it as utf-16, in a sort of confusing way--the intervening nulls aren't rendered as a replacement character, so it looks like it's being rendered as plaintext) |
| 21:02 | <zewt> | (apparently ie and webkit will also autodetect utf-32; sometimes I hate the web) |
| 21:02 | <Velmont> | But do anyone really use it... |
| 21:03 | <zewt> | no idea (but it seems like everything that can be used, gets used) |
| 21:04 | <Velmont> | zewt: Well, but Mozilla is killing sync xhr2, and breaking a ton in that. |
| 21:04 | <zewt> | er, what? |
| 21:04 | <zewt> | "you can't do that" heh |
| 21:04 | <Velmont> | zewt: Can't do what? |
| 21:04 | <jgraham> | I doubt they are planning to kill sync ahr |
| 21:04 | <jgraham> | *xhr |
| 21:04 | <zewt> | yeah i seriously doubt it |
| 21:05 | <jgraham> | Just in new contexts |
| 21:05 | <zewt> | blocking new features from sync xhr, but not breaking existing support |
| 21:05 | <jgraham> | i.e. when you want xhr 2 features suddenly the sync options doesn't work |
| 21:05 | <zewt> | (rather, sync-xhr-in-the-ui-thread) |
| 21:05 | <jgraham> | right |
| 21:05 | <zewt> | (an important distinction) |
| 21:05 | <jgraham> | Killing UTF-32 seems relatively easy |
| 21:05 | <jgraham> | by comparison |
| 21:06 | <Velmont> | jgraham: sync xhr2, - not sync xhr. :-) |
| 21:06 | <zewt> | jgraham: maybe, but IE and WebKit both have their niche sets of effectively-browser-specific pages that might make those vendors hesitant to remove it |
| 21:06 | <zewt> | well, by comparison, yes |
| 21:06 | <jgraham> | I can even sort of imagine microsoft doing it in their standards more |
| 21:06 | <jgraham> | *mode |
| 21:06 | <jgraham> | I can't iamgine apple agreeing to it though |
| 21:07 | <jgraham> | Velmont: right, but that won't break a ton of pages I expect |
| 21:07 | <zewt> | but not autodetecting UTF-32 might be easier to do (than removing it outright) |
| 21:07 | <jgraham> | If it does they won't do it |
| 21:07 | <jgraham> | They have market forces just like everyone else |
| 21:07 | <Velmont> | jgraham: Don't you think? Well, I've used sync xhr with cors a looot :-) |
| 21:07 | <zewt> | currently, the spec doesn't actually allow autodetecting UTF-32, but two browsers do it, which means there's currently a mismatch |
| 21:08 | <jgraham> | Velmont: Breaking a ton of TCs is not like breaking a ton of websites |
| 21:08 | <zewt> | (OtherGlenn made a useful observation--UTF-32 will trigger UTF-16 detection before it gets anywhere near the heuristic detection later) |
| 21:08 | <Velmont> | jgraham: Hrmf. |
| 21:08 | <jgraham> | Unless they are acid tests. And even then we eventually manage to get people to change the test :) |
| 21:10 | <zewt> | i'm not personally worried about browsers being off-spec with utf-32 detection, since real utf-16 files don't begin with U+0000, just a nice thing to get settled some day |
| 21:24 | <gsnedders> | I'd rather we detected UTF-32 properly and then failed |
| 21:24 | <gsnedders> | Like, gets treated the same as any other unknwon encoding, instead of trying to treat it as UTF-16 |
| 21:26 | <zewt> | i don't really care either way, only about the spec/implementation mismatch |
| 22:09 | <Hixie> | i wonder why kris is asking about html4 things on www-html |
| 22:10 | <Ms2ger> | Because it's stable? |
| 22:11 | <Hixie> | i mean, what is he using the answers for |
| 22:12 | <Ms2ger> | I don't think I want to know |
| 22:12 | <karlcow> | TMI |
| 22:14 | <tantek> | historical research? |
| 22:15 | <karlcow> | biologist? |
| 22:28 | <zewt> | i suppose i deserve my time being wasted when i violate my own waste-of-time-thread guidelines |
| 22:35 | <tantek> | self-correcting feedback loops are appreciated. :) |
| 22:45 | <annevk> | rniwa: am now |
| 22:48 | <annevk> | rniwa: main benefit would be smaller mutation record objects I suppose, but that is probably not much of an issue anyway if you store them in a smart way |
| 23:05 | <rniwa> | annevk: hm... but it's just some IDL attributes, right? |
| 23:05 | <rniwa> | annevk: doesn't seem like a big deal to have a few extra properties |
| 23:07 | <annevk> | just doesn't seem very clean |
| 23:20 | <annevk> | zewt: we're gonna solve the problem by not making UTF-32 an encoding label |
| 23:21 | <annevk> | zewt: i.e. "utf-32" is the same as "abacadabra" |
| 23:22 | <zewt> | annevk: that doesn't help unless WebKit and IE are willing to drop UTF-32 support (whether at the autodetect level or entirely) |
| 23:23 | <zewt> | if they are, then it's easy |
| 23:24 | <annevk> | there's not much we can do about proprietary extensions |
| 23:26 | <zewt> | but if they won't remove that, then there's not much point to the spec shaking its fist more loudly at utf-32 |
| 23:26 | <zewt> | either way the spec and implementations will differ |
| 23:28 | <annevk> | the spec just makes some recommendations because we're in a transition |
| 23:28 | <annevk> | and because encodings are poorly defined at best |
| 23:28 | <annevk> | I have some ideas on how to do better, but I haven't written down an actual spec yet |
| 23:29 | <zewt> | i mean, currently ie and webkit differ from the spec at step 4 (step 4--if you get there--says utf-32 must be detected as utf-16, those browsers don't do that); explicitly forbidding utf-32 as a supported encoding would just change where those browsers differ from the spec |
| 23:29 | <zewt> | (step 4 being the BOM header step) |
| 23:30 | <zewt> | nothing wrong with being more explicit, of course (it's a lateral move, not a step back) |
| 23:32 | <annevk> | UTF-32 is pretty much forbidden |
| 23:32 | <annevk> | unless you have a very good reason to support |
| 23:32 | <zewt> | but in practice, that's not the case :( |
| 23:33 | <zewt> | (webkit + ie) |
| 23:33 | <annevk> | I don't really expect implementations to catch up with all the details of the specification within a couple of years after it was introduced |
| 23:33 | <annevk> | that almost never happens |
| 23:34 | <annevk> | it took half a decade for the HTML5 parser to gain some support |
| 23:34 | <zewt> | sure, if you think that they'll eventually be willing to remove utf-32 outright, that's fine (even if it takes a few years) |
| 23:34 | <annevk> | pretty close to a decade now for <input type=date> and that's still in its infancy |
| 23:35 | <annevk> | oh yeah, I expect them to remove support for it eventually |
| 23:35 | <zewt> | i don't know if the utf-32 support is purely "we implemented it with everything else and don't really need it" or actual legacy compat |
| 23:35 | <zewt> | which is the real question there, of course |
| 23:36 | <annevk> | just like I thought in 2008 that Microsoft would turn around eventually and implement XHR + CORS |
| 23:36 | <zewt> | eventually implementing something and eventually removing something are different beasts, though, as you know better than I :P |
| 23:37 | <Philip`> | Or "we don't know if there's actual legacy compat, but the tiny possibility of problems outweighs the tinier gains of removing support" |
| 23:39 | <erlehmann> | gains of removing support? |
| 23:39 | <annevk> | in the end Microsoft will want to comply with the standards of the platform |
| 23:39 | <annevk> | and if the standards say that "utf-32" does not mean shit, they will play |
| 23:39 | <erlehmann> | you are a very optimistic fellow. |
| 23:39 | <zewt> | interop, closer to consistency of encoding detection between browsers (as long as you don't hit the heuristic/locale steps), helping utf-32 die |
| 23:40 | <AryehGregor> | Is *anyone* trying to implement the encoding detection spec? Does anyone know if it's actually implementable? |
| 23:40 | <annevk> | erlehmann: it's what has happened in the decade I've been involved time and again, but sure, nothing is certain |
| 23:40 | <annevk> | AryehGregor: Opera implemented it, I believe |
| 23:41 | <erlehmann> | annevk, i'm looking forward to vorbis support then. in 2017, when i don't need it anymore, because the mp3 patents … hmm. probably are still going to be out there somewhere, lurking. |
| 23:42 | <zewt> | time for mickey mp3 laws |
| 23:42 | <annevk> | in the end Microsoft ships a browser like anyone else, and browsers are driven a lot by what developers want, and they want browsers to work the same way |
| 23:42 | <erlehmann> | annevk, if large inconsistencies like CSS weirdness and media formats happen to work for them, i do not believe small inconsistencies have any chance unless they actually drive it. |
| 23:43 | <annevk> | they might not move as fast as the others, but they have <canvas> now, they have full CSS 2.1 support, etc. |
| 23:43 | <zewt> | well, at least there's some evidence that they're willing to make breaking changes to their own legacy compat (eg. read-only event objects) |
| 23:43 | <erlehmann> | funny, developers i know constantly tell me browsers are driven by what browser companies want. that is some nice loop ;D |
| 23:43 | <annevk> | all the things we thought were not going to happen back when we started with the WHATWG in 2004 |
| 23:43 | <erlehmann> | IE has <canvas>? wow. long time no see. |
| 23:43 | <annevk> | so maybe I'm pretty optimistic, but there's some history to support it |
| 23:44 | <zewt> | annevk: supporting new features and breaking existing ones are different classes, though; i don't think adding support for Canvas is evidence for making breaking changes (though as I said, there's at least some evidence for that) |
| 23:44 | <erlehmann> | annevk, you may be right after all, because killing off UTF-32 slowly is almost as good as killing it off fast. |
| 23:45 | <WeirdAl> | it's been 7 years of WHATWG? That deserves a "wow" of its own. :) |
| 23:45 | <erlehmann> | so it might not matter if they care much, if they do at all. |
| 23:45 | <annevk> | zewt: the HTML parser was a breaking change |
| 23:45 | <annevk> | zewt: CSS 2.1 was a breaking change |
| 23:45 | <annevk> | zewt: a lot of things were breaking changes, for pretty much every browser we've had those |
| 23:46 | <zewt> | modulo quirks mode, though (though I pretty much ignore the details of that, being fortunate enough to not have horrible legacy stuff to maintain) |
| 23:46 | <annevk> | ah yeah, IE10 breaks its own quirks mode! |
| 23:46 | <annevk> | to be more compatible with the other browsers |
| 23:46 | <annevk> | that should be a good sign that UTF-32 will go away :) |
| 23:47 | <zewt> | dunno, as always we'll see :) |
| 23:47 | <zewt> | far from the biggest problem plaguing charsets, so I'm not chewing my fingernails over it either way |
| 23:47 | <AryehGregor> | IE10 implements appcache? I thought that was broken and no one wants to use it. |
| 23:51 | <annevk> | I think everyone just wants more out of it |
| 23:51 | <annevk> | (to put it somewhat simply) |
| 23:57 | <bga> | http://code.google.com/chrome/extensions/trunk/experimental.socket.html |
| 23:58 | <AryehGregor> | :( http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/webkit_glue.cc?r1=111877&r2=111876&pathrev=111877 |