| 00:07 | <jamesr> | Philip`: qq - do you have any canvas 2d tests for globalCompositeOperation=copy and fillText()? |
| 00:07 | <jamesr> | in the suite? |
| 00:07 | <jamesr> | we fail on that currently in WebKit |
| 00:08 | <jamesr> | and implementations might use different logic for their text drawing routines than for other draw calls |
| 00:08 | <Hixie> | oh hey it turns out anyone can get an account, not just those who have sent feedback |
| 00:08 | <Hixie> | wonder when i changed that |
| 00:10 | <Philip`> | jamesr: I don't think so, though I have a note in my write-only todo list about that |
| 00:13 | <Hixie> | ok i've updated the status boxes to have an edit link |
| 00:13 | <Hixie> | also slightly tweaked them |
| 00:15 | <Hixie> | any transition experts in the house? how do i transition from height:0 to height:auto? |
| 00:15 | <jamesr> | lawl |
| 00:15 | <jamesr> | :( |
| 00:15 | <jamesr> | you don't |
| 00:15 | <hober> | heh |
| 00:15 | <jamesr> | you can measure what height:auto would resolve to and then transition from 0 to that value |
| 00:16 | <hober> | Hixie: transitions to or from auto don't work |
| 00:16 | <Hixie> | ok. that's lame. |
| 00:16 | <TabAtkins> | Hixie: Transition max-height from 0 to a mild overestimate of the height. |
| 00:16 | <Hixie> | someone fix that. |
| 00:16 | <TabAtkins> | Yes, it is totally fucking lame. |
| 00:16 | <Hixie> | TabAtkins: hmm, good idea. |
| 00:17 | <Hixie> | ok i hid the ID in the status boxes, it now appears on hover |
| 01:06 | <TabAtkins> | Cross-origin XHR is completely disallowed, right? Even just sending the request, not just receiving the response? |
| 01:09 | <jamesr> | sicking: you there? |
| 01:10 | <sicking> | jamesr: yo |
| 01:10 | <sicking> | TabAtkins: how do you mean? |
| 01:10 | <sicking> | TabAtkins: you can do cross-origin XHR using CORS |
| 01:10 | <TabAtkins> | Right, but outside of that it's disallowed. |
| 01:10 | <sicking> | TabAtkins: which means that you can make the request in many cases without the server opting in |
| 01:11 | <TabAtkins> | sicking: What do you mean? What I'm asking about is using XHR to send data from client->server only, not caring about the response back. |
| 01:11 | <TabAtkins> | (Actually asking about a different API that effectively accomplishes that.) |
| 01:12 | <sicking> | TabAtkins: yup, you can basically do that, as long as you use POST with a limited set of Content-Types |
| 01:12 | <TabAtkins> | Without having to invoke CORS? |
| 01:12 | <sicking> | well, it invokes CORS |
| 01:12 | <sicking> | but CORS doesn't do anything until it start receiving a response |
| 01:13 | <sicking> | since CORS is response-header based |
| 01:13 | <sicking> | note, that you can only do this if your POST is fairly "plain" |
| 01:13 | <TabAtkins> | That's what I thought. So the actual message from client->server gets through regardless. |
| 01:13 | <sicking> | i.e. you can't set any custom headers |
| 01:13 | <sicking> | TabAtkins: yup |
| 01:13 | <TabAtkins> | kk. |
| 01:13 | <sicking> | TabAtkins: just like with <form> |
| 01:14 | <TabAtkins> | All right, cool. |
| 01:15 | <TabAtkins> | (Context is someone pinging me about the feasibility of a built-in bugreporting function, that lets you specify a url to post to, some custom data to send, and a list of UA-provided data that you'd like, so the browser can let the user decide what to send and then post for you.) |
| 01:15 | <jamesr> | sicking: for XHR 'text' can be considered a parsed format |
| 01:16 | <jamesr> | sicking: what happens if the text is encoded in utf-8 and only part of the codepoint sequence (or whatever unicode calls it) is in the most recently received packet? |
| 01:16 | <sicking> | jamesr: then you don't return that character until in the next progress notification |
| 01:16 | <jamesr> | but the idea is the browser could ditch most of the response? |
| 01:16 | <sicking> | jamesr: yup |
| 01:17 | <sicking> | all but the last few bytes |
| 01:18 | <jamesr> | would be nice |
| 01:18 | <sicking> | TabAtkins: just make sure to not even return a error code indicating if the submission succeeded or not |
| 01:18 | <TabAtkins> | Ah, good point. |
| 01:19 | <jamesr> | what happens if you try to set .responseType after receiving a few progress events? it throws an error? |
| 01:19 | <sicking> | yes, that's already the case |
| 07:28 | <zcorpan> | ooooh http://dev.w3.org/csswg/selectors4/#attribute-case |
| 07:36 | <MikeSmith> | Hixie: I don't understand http://html5.org/r/6413 |
| 07:36 | <MikeSmith> | the spec already states that maxlength on input@type=number is not valid |
| 07:37 | <MikeSmith> | so validator.nu currently emits an error for it |
| 07:37 | <MikeSmith> | this change would cause it to emit a warning in addition to an error |
| 07:38 | <MikeSmith> | unless I'm misunderstanding something |
| 07:38 | <MikeSmith> | but http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state lists maxlength under "The following content attributes must not be specified and do not apply to the element" |
| 07:40 | <MikeSmith> | and http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#input-type-attr-summary also indicates that maxlength is now allowed on input@type=number |
| 07:41 | <MikeSmith> | if the intent is to actually make it conforming but obsolete, it seems like those parts of the spec should be changed as well |
| 07:41 | <zcorpan> | MikeSmith: "should not" means it's allowed if you have a good reason |
| 07:42 | <MikeSmith> | OK |
| 07:42 | <MikeSmith> | but if so, those two parts of the spec should be changed |
| 07:42 | <zcorpan> | yeah |
| 07:42 | <MikeSmith> | I don't see how otherwise we can make any changes to the validation behavior |
| 07:43 | <MikeSmith> | I'm post a comment to the bug |
| 09:52 | <zcorpan> | so if i'm reading the spec right it allows <link rel="help shortcut icon" ...> |
| 09:53 | <zcorpan> | does that work in ie? |
| 09:54 | <zcorpan> | i guess it does since hsivonen tested it |
| 09:55 | <GlitchMr> | I will check :P |
| 09:57 | <GlitchMr> | http://glitchmr.pl/private/favtest.php |
| 09:57 | <GlitchMr> | It seems to work under IE9 |
| 09:58 | <GlitchMr> | It also seems to work under Quirks Mode... |
| 09:58 | <GlitchMr> | validator.nu seems to accept such structure and it seems to not cause issues with IE |
| 10:00 | <GlitchMr> | But then, semantically it doesn't make sense |
| 10:00 | <GlitchMr> | How can be shortcut icon helpful? |
| 10:03 | <zcorpan> | heh |
| 10:04 | <zcorpan> | well it must be helpful for something else you wouldn't include it in the first place |
| 10:04 | <GlitchMr> | You can use <link rel="help" href="..."> for help pages for examples |
| 10:05 | <GlitchMr> | example* |
| 10:05 | <GlitchMr> | Many browsers show their help on "About"->"Help" or something like this. Some might have reason to insert help into webpage :P |
| 10:06 | <GlitchMr> | But favicon.ico is helpful by itself (in visual browsers), but it's not help page... |
| 10:13 | <zcorpan> | Hixie: can you make the status boxes increase z-index on hover so you can access ones that are overlapped by other status boxes? |
| 10:26 | <Ms2ger> | Oh hey, I'm below zcorpan in status annotation edits... |
| 10:26 | Ms2ger | goes off to fix that |
| 12:43 | Ms2ger | shoots |
| 16:35 | <dglazkov> | good morning, Whatwg! |
| 16:41 | <TabAtkins> | Alan Gresley just said my head might be filled with crack. ;_; |
| 16:42 | <jgraham> | Is this from the "chocolate teapot orbiting the sun" school of "might"? |
| 16:43 | <TabAtkins> | Not sure. Alan's kinda crazy himself. |
| 16:45 | <Philip`> | TabAtkins: Sounds like you could make a fortune by selling your head |
| 16:46 | <AryehGregor> | TabAtkins, what probability are we talking about here? I mean, not to put too fine a point on it, but that would m -- drat, Philip` beat me to it. |
| 16:46 | <AryehGregor> | I mean, what would that be, a few pounds of crack? What's the street value of that? |
| 16:47 | <dglazkov> | I somehow doubt it's crack. |
| 16:47 | <TabAtkins> | I like my head. If there's crack in there, evidence says that I'm using it to think. |
| 16:47 | <dglazkov> | ah. that's where the old "get cracking" saying comes from. |
| 16:47 | <Philip`> | Heads are nice, but money is nice too, so you have to balance both sides of the argument |
| 16:49 | <Ms2ger> | I mean, half a head would be about as useful, no? |
| 16:49 | <TabAtkins> | I use more than half of my head. |
| 16:50 | <gsnedders> | int a = 5; int *ptr = &a; size_t foo = ptr; <- foo is now the memory address that ptr points to, right? |
| 16:50 | <Ms2ger> | How much of that is just for waste-ink? |
| 16:50 | <Ms2ger> | gsnedders, surely that would warn |
| 16:50 | <TabAtkins> | Ms2ger: Ooh, good point. |
| 16:51 | <Philip`> | gsnedders: I think so, though I'm not sure size_t is guaranteed to be pointer-sized |
| 16:51 | Ms2ger | liked that name |
| 16:51 | <Philip`> | intptr_t is better if you want a pointer-sized int |
| 16:51 | <Ms2ger> | I think gsnedders actually wants = *ptr |
| 16:51 | <Philip`> | That would give foo = 5 |
| 16:52 | <Ms2ger> | Right |
| 16:52 | <Ms2ger> | I knew that! ;) |
| 16:52 | <gsnedders> | Ms2ger: I don't want foo = 5; I want the address that ptr points to. |
| 16:52 | Philip` | has no idea what gsnedders actually wants |
| 16:52 | <Philip`> | Ah |
| 16:52 | <gsnedders> | The memory address of a, effectively. |
| 16:52 | jgraham | doesn't like to think about what gsnedders wants |
| 16:53 | <Philip`> | ptr is already the memory address |
| 16:53 | <Ms2ger> | Why the hell are you trying to stick that into a size_t? |
| 16:53 | <Philip`> | so if you copy it into another variable then it's still that memory address (modulo 2^something) |
| 16:53 | <gsnedders> | Philip`: Okay, that's what I thought. |
| 16:54 | <Ms2ger> | But you do want intptr_t or uintptr_t |
| 16:55 | <jgraham> | Gotta love C and all the million sometime-interchangable, but not safely, types |
| 16:57 | <Ms2ger> | Don't you like C++ more? It has namespaces! |
| 16:57 | <Philip`> | If you want to be like the cool kids you could store the pointer in the NaN space of a double |
| 16:57 | <Ms2ger> | Philip`, ... do you do that? |
| 16:57 | <Philip`> | I'm not cool enough :-( |
| 17:01 | <gsnedders> | Ms2ger: JS engines do, on 32-bit arches |
| 17:01 | <Philip`> | At least SpiderMonkey on 64-bit too |
| 17:02 | <Ms2ger> | JS engines are a mess of their own |
| 17:02 | Philip` | thinks nanboxing and nunboxing would be interesting new Olympic sports |
| 17:03 | <gsnedders> | Philip`: How? Assuming no pointer will be over 53-bits? |
| 17:03 | <Philip`> | gsnedders: 47 bits, I think |
| 17:04 | <gsnedders> | Then what about the other six? Obviously they have to reserve one NaN value as NaN, and it can't be zero (because then it's not NaN but Inf) |
| 17:05 | <gsnedders> | Ms2ger: (The reason why I was using size_t above was because that's what Cython does… although I know it isn't guaranteed to work…) |
| 17:09 | <Philip`> | gsnedders: amd64 only has 48-bit virtual address space, and I think the 48th bit is magic and is always 0 in interesting OSes |
| 17:09 | <gsnedders> | Philip`: Ah. |
| 17:10 | <Philip`> | (http://en.wikipedia.org/wiki/X86-64#Canonical_form_addresses etc) |
| 18:13 | <Hixie> | zcorpan: done (the z-index thing) |
| 18:18 | <Ms2ger`> | People might be somewhat interested in http://lists.w3.org/Archives/Member/w3c-ac-members/2011JulSep/0007.html (MO) |
| 18:53 | <espadrine> | Ms2ger`: There is no locked-up equivalent to that mailing-list, is there? |
| 18:54 | <Ms2ger`> | Hmm? |
| 19:19 | <espadrine> | Ms2ger`: We can't access http://lists.w3.org/Archives/Member/w3c-ac-members/2011JulSep/0007.html |
| 19:19 | <Ms2ger`> | Right |
| 19:20 | <espadrine> | without W3C names |
| 19:20 | <Ms2ger`> | Would've linked to a public copy if there was one |
| 19:21 | <espadrine> | too bad there isn't one |
| 19:24 | <gnarf> | seems to be an error in http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#url-decomposition-idl-attributes regarding the "port" attribute |
| 19:25 | <gnarf> | ooo wait |
| 19:25 | <gnarf> | nvm |
| 19:25 | <gnarf> | read a column header wrong |
| 19:26 | <gnarf> | cancel the alarm!!! |
| 19:26 | gnarf | hides |
| 21:29 | AryehGregor | discovers another person who spells his name Areyeh -- interesting |
| 21:46 | <KevinMarks> | there's now a .ss TLD coming. Who's going to get c.ss ? |
| 22:11 | <karlcow> | http://highscalability.com/blog/2011/8/10/leveldb-fast-and-lightweight-keyvalue-database-from-the-auth.html |
| 22:11 | <TabAtkins> | Ooh, that sounds fun. |
| 22:12 | <karlcow> | wondering if it will show up in Google line of products |
| 22:12 | <karlcow> | ah it's already |
| 22:12 | <karlcow> | "LevelDB is being used as the back-end for IndexedDB in Chrome. For designing how to map secondary indices into LevelDB key/values, look at how the IndexedDB support within Chrome is implemented." |
| 22:14 | <TabAtkins> | Yeah, sqlite has corruption issues when it runs for a long time (not really its fault - its from occasional misplaced writes in other processes). |
| 22:14 | <Hixie> | "misplaced writes"? |
| 22:15 | <TabAtkins> | You know, writes to a dangling pointer or something. Otherwise known as "security vulnerabilities". |
| 22:15 | <Hixie> | how can you cause corruption in another _process_? |
| 22:15 | <Hixie> | don't modern OSes pretty much make that impossible? |
| 22:15 | <TabAtkins> | Dont' ask me. I'm recalling lunchtime conversation. |
| 22:16 | <Hixie> | if the problem is other code in the _same_ process randomly stomping on the space used by the sqlite library, it seems any library would suffer the same problem |
| 22:16 | <AryehGregor> | Hixie, maybe when two processes have the same database file open and one writes to it in a way that's not coordinated with the other, so the other winds up reading garbage somehow? |
| 22:17 | <Hixie> | that'd be a bug in sqlite's locking |
| 22:17 | <AryehGregor> | I thought only one process can open an SQLite database at a time, though. |
| 22:17 | <AryehGregor> | Yeah, I dunno. |
| 22:17 | <TabAtkins> | AryehGregor: It wasn't sqlite's problem directly; it was definitely memory corruption coming from elsewhere. |
| 22:18 | <zewt> | so it's very wrong to say "sqlite has corruption issues" |
| 22:18 | <Hixie> | yeah i don't see why sqlite would be any more at risk than leveldb |
| 22:19 | <Hixie> | but what do i know :-) |
| 22:19 | <zewt> | which I doubt anyone would accept anyway; sqlite should be high on any competent programmer's top-five list of most reliable libraries in the world |
| 22:20 | <karlcow> | the storage library the highest on my list is definitely… my fridge! |
| 22:20 | <karlcow> | every day, a few times a day. |
| 22:21 | <TabAtkins> | zewt: From the conversation I had with a guy working on indexeddb, sqlite made some not-strictly-required architectural decisions that mean that it holds its memory for too long, making it more subject to this kind of corruption. |
| 22:22 | <zewt> | sounds like a very contrived argument |
| 22:22 | <TabAtkins> | I may be misstating things. |
| 22:22 | <TabAtkins> | zewt: I'm not sure what you're trying to imply. We used sqlite. We had regular db corruption. We traced it to a problem with the design of sqlite. |
| 22:23 | <jgraham> | It seems to me that "it's not designed to be a k-v store" might be a god enough reason on its own to think about other solutions for indexeddb |
| 22:23 | <jgraham> | *good |
| 22:23 | <TabAtkins> | I'm not saying sqlite is horrible. I'm saying it didn't suit our needs, so we designed a new one. |
| 22:23 | <jamesr> | i don't think the primary motivation for leveldb was sqlite db corruption bugs |
| 22:23 | <jamesr> | although it may have been one |
| 22:23 | <TabAtkins> | jgraham: Indeed, that too. |
| 22:23 | <jamesr> | jgraham: exactly |
| 22:23 | <zewt> | ... if library X writes to random memory locations and corrupts memory owned by library Y, it is not in any conceivable sense library Y's fault for "holding that memory for too long" |
| 22:23 | <TabAtkins> | jamesr: It was the reason that FileSystem is switching from sqlite to leveldb, at least. |
| 22:23 | <zewt> | "i shot some bullets down the street and someone got hit, it's hit fault for standing there for so long" |
| 22:23 | <Philip`> | Most databases have a separate server process, so only bugs in that process could scribble over the database, whereas SQLite runs in the address space of the host application so it's vulnerable to bugs in any applications that touch the database |
| 22:24 | <TabAtkins> | zewt: Robustness. If Y can avoid a lot of those problems, but it doesn't, then that's a problem. |
| 22:24 | <Philip`> | though LevelDB seems to be embedded in applications too so it'd be just as vulnerable |
| 22:24 | <zewt> | avoid problems caused by unrelated code smashing memory? sorry, that's utter nonsense |
| 22:24 | <gsnedders> | TabAtkins: Why have there not been issues with corruptions with the insane number of other people using SqLite3? |
| 22:24 | <TabAtkins> | zewt: I'm not blaming anybody, so don't treat it as a personal attack. I'm saying that we needed something that didn't stand in the street quite so long. |
| 22:24 | <zewt> | problems caused by code smashing random memory (or whatever) is the fault of that code and that code alone |
| 22:24 | <karlcow> | http://google-opensource.blogspot.com/2011/07/leveldb-fast-persistent-key-value-store.html |
| 22:25 | <TabAtkins> | gsnedders: No clue. Again, I'm relaying lunchtime conversation. |
| 22:25 | <zewt> | i'm not treating anything as a personal attack; i have nothing to do with sqlite development |
| 22:25 | <karlcow> | http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html |
| 22:25 | <zewt> | i'm saying it's a ridiculous, nonsensical reason to change libraries. |
| 22:25 | <Hixie> | either it's a bug in sqlite that should be fixed, or it's a bug in the surrounding code and leveldb would be equally vulnerable, as far as i can tell |
| 22:25 | <jamesr> | no, there were others |
| 22:25 | <TabAtkins> | zewt: If you're shooting bullets into the street, it's your fault when you hit somebody. But if you're relying on something that needs to cross the street, it's better to rely on one that won't spend as long in the crossfire. |
| 22:26 | <jgraham> | Quick to the car metaphors! |
| 22:26 | <TabAtkins> | Car metaphors explains EVERYTHING. |
| 22:26 | <jgraham> | +, |
| 22:26 | <zewt> | changing libraries means whoever's firing the bullets is going to be hitting other things, and it'll be some other random piece of code being broken |
| 22:27 | <TabAtkins> | zewt: ...yes? And with luck, it'll be something that doesn't lose long-term data when it errors out. |
| 22:27 | <Hixie> | luck seems like a rather crappy design philosophy :-) |
| 22:27 | <zewt> | it's just nonsense FUD that'll lead less experienced developers to believe that "leveldb" (whatever that is) is more reliable than sqlite, which is bogus |
| 22:27 | <jamesr> | i'm pretty sure that leveldb is no safer to memory corruption in your process than anything else |
| 22:28 | <Hixie> | yeah i don't see how it could be |
| 22:28 | <TabAtkins> | zewt: Argh, I'm saying, very specifically, that one of *our* teams is running into this problem with sqlite, and is switching to leveldb because it fixes the architectural issue. |
| 22:28 | <zewt> | if you really want to protect from corruption, move your sqlite access into a helper process and proxy SQL commands to it |
| 22:28 | jgraham | thinks that having arguments based on half-remembered lunch conversations using metaphors involving violent death is probably not the road to enlightenment |
| 22:28 | <zewt> | which seems like a much simpler engineering task than changing backends |
| 22:29 | <zewt> | and much more effective |
| 22:29 | <TabAtkins> | zewt: I'm not talking about general engineering advice to the world at large. |
| 22:29 | <Philip`> | The road to enlightenment is strewn with randomly-shot bullets that luckily missed all the databases |
| 22:30 | <TabAtkins> | How true. |
| 22:30 | <jamesr> | since it's a piece of software |
| 22:30 | jamesr | agrees with jgraham and goes back to work |
| 22:30 | <jgraham> | Ah, well in that case I will know to take that one rather than the one paved with good intentions |
| 23:12 | <AryehGregor> | http://html5.org/r/6419 ++ |
| 23:12 | <AryehGregor> | Way too many people get that wrong. |
| 23:12 | <Hixie> | srsly |