| 00:30 | <TabAtkins> | JonathanNeal: http://dom.spec.whatwg.org/#dom-parentnode-query Got renamed to query/queryAll, but otherwise still there in DOM and planning to stick around. |
| 00:31 | <TabAtkins> | zewt: What are you referring to? |
| 00:34 | <zewt> | find vs. querySelector |
| 00:35 | <TabAtkins> | Those arent' aliases. |
| 00:36 | <TabAtkins> | They are similar, but in the sense that querySelector was a mistake we have to support, and query() is the way we should have designed it in the first place. |
| 00:36 | <zewt> | the last time I saw it, it was "we want to add new features to querySelector, so let's make a new function with a shorter name while we're at it" |
| 00:37 | <zewt> | don't know anything wrong with querySelector that needs a new entry point |
| 00:37 | <TabAtkins> | It's "let's redo querySelector, but with the correct scoping behavior, and allow relative selectors while we're at it, since everyone expects that and it's an obvious feature". |
| 00:58 | <Hixie> | TabAtkins: i think you misread my last comment on the promises thing |
| 00:58 | <TabAtkins> | I miight have. |
| 01:17 | <TabAtkins> | annevk: I'm writing some basic advice for writing async algos in specs at http://wiki.csswg.org/spec/async-algos . I'd appreciate guidance on the right spec language to use for queueing tasks when you need to mutate some observable document state. |
| 01:20 | <TabAtkins> | Hixie: Looking over it again, I'm not sure how I misread your comment. Mind elaborating? |
| 01:36 | <Hixie> | TabAtkins: maybe i misread yours? i was saying that it was not ok that argument-checking turns into a rejected promise. |
| 01:37 | <TabAtkins> | Oh jeez, I missed a "not". Okay, then you're not inconsistent, you're just still wrong and lots of people disagree with you. ^_^ |
| 01:37 | <Hixie> | lots of people agree, too, it looks like |
| 01:38 | <TabAtkins> | Several people who have been closely involved with the work on promises all agree. |
| 01:38 | <TabAtkins> | That is, people who have a strong working and theoretical background on useful coding patterns for this kind of thing. |
| 01:39 | <Hixie> | yeah. so. just so we're clear, i give argument from authority zero weight. :-) |
| 01:49 | <TabAtkins> | Obviously. What I'm saying is that it looks like you're treating this like a personal preference API design issue, and it's not. Those people have good experience in why async APIs are more usable in the wild/in the large when they're designed this way. |
| 01:53 | <TabAtkins> | And they've written down the reasons why, and it doesn't look like you've addressed their arguments. |
| 01:54 | <TabAtkins> | Heck, even I've written down arguments for the "always reject" pattern <http://www.xanthir.com/b4P_0>;, and I didn't even realize it! It wasn't until after Domenic schooled me that I realized my earlier explanations were completely in line with that pattern. |
| 01:55 | <TabAtkins> | Throwing+rejecting is akin to having to wrap both the source and the call site of a function in try/catch in Mauvascript, because some errors get thrown at the source location and some get thrown at the call site. |
| 01:57 | <Hixie> | TabAtkins: you realise i also have good experience in designing APIs, right |
| 01:57 | <TabAtkins> | I thought you just said argument from authority have zero weight! |
| 01:57 | <Hixie> | it doesn't |
| 01:58 | <Hixie> | but your saying "these people have experience" sounds like you're implying "and you don't" |
| 01:58 | <TabAtkins> | Don't read it like that, then, because that's not what I'm saying. |
| 01:58 | <TabAtkins> | It's "this people have experience, but you're treating them like they just have an opinion". |
| 01:59 | <Hixie> | i've made counter-arguments to every argument presented, as far as i can tell |
| 01:59 | <Hixie> | it's either opinion, or they're wrong. :-) i think it's probably opinion. |
| 01:59 | <TabAtkins> | Which continue to be of the form "I believe I can draw a firm line between contract violations and data errors", which is wrong. |
| 02:00 | <TabAtkins> | Alternately, "I believe that the arguments people have made about how difficult and annoying it is to handle both sync and async errors are spurious". |
| 02:01 | <Hixie> | the web api has drawn that firm line for years |
| 02:01 | <Hixie> | decades even |
| 02:01 | <Hixie> | exceptions on one side, 'error' events on the other |
| 02:02 | <TabAtkins> | Oh come now, error events are rare. |
| 02:02 | <Hixie> | yup |
| 02:02 | <Hixie> | exceptions too, actually |
| 02:02 | <TabAtkins> | And it's very easy to argue that the line they draw is arbitrary and bad, and they shouldn't be doing so. |
| 02:02 | <Hixie> | what would that argument look like? |
| 02:03 | <TabAtkins> | (Events also never composed in any meaningful manner, which is the exact scenario being held up as being difficult to handle when you're mixing sync and async errors.) |
| 02:03 | <TabAtkins> | (Unlike promises, where composition is commonplace and expected.) |
| 02:03 | <Hixie> | we're not mixing sync and async errors |
| 02:03 | <Hixie> | the sync errors never happen unless there's a bug |
| 02:03 | <Hixie> | they're a completely different beast than the async errors. |
| 02:04 | <TabAtkins> | Many async errors don't happen unless there's a bug, too. |
| 02:04 | <TabAtkins> | And regardless, having one error-handling path is usually much easier to handle correctly. |
| 02:04 | <TabAtkins> | This is the exact argument made by several people, and by the blog posts you've been referred to. |
| 02:05 | <TabAtkins> | You seem to be claiming that the difficulties those people outline and explain aren't real, or aren't actually difficult to handle. |
| 02:05 | <Hixie> | that argument is totally bogus. it implies that you're (a) going to do anything useful when "handling" an error that's caused by a bug, and (b) that even if you did, it could in any meaningful sense be the same thing as if you were handling a non-logic bug, like a network error. |
| 02:05 | <Hixie> | s/non-logic bug/non-bu error/ |
| 02:05 | <Hixie> | non-bug |
| 02:06 | <TabAtkins> | So you don't understand the argument, then. |
| 02:06 | <TabAtkins> | I suggest looking into it further and trying harder to understand it. |
| 02:06 | <Hixie> | maybe. or maybe you don't understand why it's wrong. :-) |
| 02:07 | <Hixie> | why do i have the burden of trying to convince myself that you're right as opposed to you having the burden to convince yourself that i'm right? |
| 02:24 | <SamB> | TabAtkins: so what useful thing are you going to do in response to one of these bugs? |
| 02:27 | SamB | wonders if TabAtkins has ever seen an async API that he liked |
| 02:28 | <TabAtkins> | SamB: I already did - I adjusted the Font Loading APIs to accord with this. |
| 02:30 | <TabAtkins> | Hixie: Because only one of us is right, and it's me, so it would be counterproductive for new to convince myself that you're right. ^_^ |
| 02:30 | <Hixie> | that seems like an unproductive attitude, if you're serious |
| 02:31 | <Hixie> | i find that convincing myself that other people are right is one of the best uses of my time |
| 02:32 | <SamB> | I meant outside JS stuff |
| 02:33 | <TabAtkins> | Hixie: Less cheekily, I was already on your side, and I was convinced otherwise by reasonable arguments from Domenic. |
| 02:33 | <TabAtkins> | SamB: I have no idea what you're talking about, in that case. |
| 02:34 | <Hixie> | TabAtkins: i've read those same arguments, and i don't see why they are compelling. |
| 02:34 | <SamB> | TabAtkins: you don't know what a non-JS API is? |
| 02:34 | <TabAtkins> | SamB: No, I have no clue what you're asking. |
| 02:34 | <TabAtkins> | I mean, come on, at least *try* for the reasonable explanation for my confusion. ^_^ |
| 02:35 | <SamB> | I was trying to provoke you into revealing more details ;-P |
| 02:35 | <TabAtkins> | Oh! you were referring to bugs in my JS code, not bugs as in GitHub issues. |
| 02:35 | <SamB> | not necessarily your code |
| 02:35 | <TabAtkins> | Right, just JS code in general. |
| 02:35 | <TabAtkins> | I thought you were asking about what I was going to do in response to the github issue. |
| 02:35 | <TabAtkins> | Anyway, same thing you'd do with any try/catch. |
| 02:36 | <caitp> | is this still the promise thing? |
| 02:36 | <TabAtkins> | Yeah. |
| 02:36 | TabAtkins | is home and trying to play Civ now, though. |
| 02:36 | <SamB> | TabAtkins: what's that thing you'd do with any try/catch? |
| 02:36 | <TabAtkins> | Depends entirely on what the code is? |
| 02:36 | <SamB> | and how does it help when someone just screwed up their calls |
| 02:37 | <Hixie> | TabAtkins: specifically, it looks like https://github.com/domenic/promises-unwrapping/issues/24#issuecomment-23979547 canvinced you, but i disagree with the premise of that argument. There is a fundamental difference between the types of errors he's talking about. If you've got a promise for a network-obtained resource, it makes sense that you could deal with "the network is flaky" by e.g. trying again or using a cached resource. But there's no logical thing |
| 02:38 | <Hixie> | ...you could do in response to a SyntaxError, ReferenceError, TypeError, or InvalidStateError. They're just qualitatively different. You don't want all your rejection handlers to deal with this. That's what window.onerror is for. |
| 02:38 | <SamB> | but, like, what are you gonna do with the equivalent of "bad FD" |
| 02:39 | <caitp> | hixie, there is a problem with treating them differently --- those errors which in other languages might be caught at compiletime, can't really be caught at compiletime in js (unless it's a legitimate syntax error that breaks the parser) --- you can only run into them at runtime |
| 02:40 | <TabAtkins> | Hixie: Actually, you often do. It's a common trope in Python, frex, to forgo argument checking and instead just try calling other APIs with whatever you've got, wrapping the call in a try/catch and doing something alternate regardless of what the error is. |
| 02:40 | <TabAtkins> | The same trope applies to JS just as much. |
| 02:40 | <caitp> | and then, if you are going to treat them differently at runtime by making "special" errors uncatchable, then |
| 02:40 | <caitp> | that pretty much throws away the ecma draft |
| 02:40 | <TabAtkins> | If *anything* happens to your network request, you might want to fail over to a cache. |
| 02:40 | <SamB> | TabAtkins: hmm, I think usually you only do that on specific exceptions |
| 02:40 | <TabAtkins> | You might also want to be more sophisticated, and do retries in some circumstances, etc. |
| 02:40 | <SamB> | otherwise you risk really confusing yourself when things go wrong |
| 02:41 | <TabAtkins> | But that's totally already possible. |
| 02:41 | <caitp> | or at least, adds things to it which don't currently exist |
| 02:41 | <SamB> | because you'll never see the exception |
| 02:41 | <Hixie> | TabAtkins: calling an api at random is absurd. if that's the kind of "experience" that is leading to this design, then i can just rest my case here. |
| 02:42 | <TabAtkins> | "at random" is a terrible characterization of what I just described. |
| 02:42 | <SamB> | TabAtkins: what if you never get a request made because you totally flubbed the parameters? |
| 02:42 | <TabAtkins> | SamB: Testing will reveal that, then. |
| 02:42 | <TabAtkins> | Or examining your error logs. |
| 02:42 | <SamB> | how do these logs happen if no exception is thrown? |
| 02:42 | <Hixie> | "hey i don't know if what i've got here is valid for this api, but i'll call it anyway" is not good practice. |
| 02:43 | <TabAtkins> | "Why do I keep making requests to "{keepalive:true}"? Oh, because I swapped the arg order in fetch(). Duh." |
| 02:43 | <caitp> | dude it's the web, it's the land of "not a good practice" |
| 02:43 | <SamB> | no need to make it super easy |
| 02:43 | Hixie | fires up some DA:O instead of trying to explain why we shouldn't be optimising APIs for bad practice |
| 02:43 | <SamB> | I'd rather exclaim that |
| 02:43 | <zewt> | i've never seen duck typing in JS, I think the only time I've called something expecting to catch a low-level exception is for feature detection |
| 02:44 | <zewt> | i rarely even use it in Python |
| 02:44 | <zewt> | that said, any good language should let you catch any runtime error |
| 02:44 | <caitp> | feature detection is a pretty good use case for a world where you have dozens of browsers with different capabilities and configurations |
| 02:44 | <SamB> | the main thing I see that at all resembles what TabAtkins said in Python is that pattern where you catch ImportError and fall back to some other way of doing whatever it is the thing you tried to import was for |
| 02:44 | <caitp> | and in different versions |
| 02:44 | <TabAtkins> | Hixie: Extremely common example: I've got a file handle, which may or may not exist. Checking ahead of time whether it exists is futile, because it might disappear between now and th enext line of code. |
| 02:45 | <SamB> | caitp: you don't usually want to do feature detection asynchronously ... |
| 02:45 | <TabAtkins> | Hixie: Thus the Python idiom is to just call the function assuming the file is there, and handle "file never existed" and "file did exist, but just now disappeared" the same way, in the catch block, unless you have a good reason to differentiate them. |
| 02:45 | <caitp> | no, but i'm not really taking sides in that argument, what I'm saying is that catching things like that can be useful |
| 02:45 | <SamB> | TabAtkins: filehandles don't suddenly stop existing in sane environments |
| 02:45 | <caitp> | and if it's going to work synchronously, why not asynchronously |
| 02:45 | <TabAtkins> | SamB: The file underneath them does. |
| 02:46 | <caitp> | you know, for consistency |
| 02:46 | <SamB> | just saying |
| 02:46 | <TabAtkins> | What are you just saying? Files can get deleted. |
| 02:46 | <zewt> | TabAtkins: "a nonexistant FD" and "a valid FD pointing to a file that doesn't exist any more" are pretty different things |
| 02:46 | <caitp> | this is the web, it's the land of "not a sane environment" :p |
| 02:46 | <SamB> | you people have strange file handles here, is all |
| 02:46 | <TabAtkins> | zewt: In many cases they're identical for your purposes. |
| 02:46 | <SamB> | zewt: I don't think web file handles are much like FDs |
| 02:46 | <TabAtkins> | See: every use of a file handle in Bikeshed. |
| 02:46 | <SamB> | I Think they're more like struct stat |
| 02:46 | <zewt> | can we call your file handle a "filename" for this example? |
| 02:47 | <TabAtkins> | zewt: Yeah, whatever. |
| 02:47 | <TabAtkins> | Same diff for these purposes. |
| 02:47 | <zewt> | it seems like you're describing "open(filename) and catch IOError to see if it fails", which is fine |
| 02:47 | <SamB> | in unix a file doesn't go away just because it's deleted, if you already have a handle to it |
| 02:48 | <SamB> | I never really understood how it works on Windows for sure, since usually you aren't allowed to delete such files in the first place |
| 02:48 | <zewt> | but i'm not sure it's the same case as "open(filename) where filename might be None, and catch TypeError" (eg. duck typing) |
| 02:48 | <zewt> | SamB: ... that's why I established "filename", because that seemed irrelevant |
| 02:48 | <SamB> | yeah sorry |
| 02:49 | <SamB> | just, I can't help ranting about the stupid terminology ... |
| 02:50 | <TabAtkins> | zewt: Yes. |
| 02:50 | <zewt> | anyway, i don't know the particular case well enough to have an opinion, though I can see a distinction between synchronous and async here (can't think of any reason, off-hand anyway, why I'd want to receive a TypeError async; that just means the async task fell over) |
| 02:50 | <SamB> | (back to Python, I only just learned that file() was deprecated, and you're better off if you never switched from open()) |
| 02:51 | <TabAtkins> | You should be using io.open anyway. |
| 02:51 | <TabAtkins> | Returns unicodes automatically, rather than strs. |
| 02:51 | <TabAtkins> | Or use Python3, I guess. ^_^ |
| 02:51 | <SamB> | huh? a file isn't unicode! |
| 02:51 | <zewt> | i want to, but I don't see it happening on the horizon, heh |
| 02:51 | <TabAtkins> | SamB: It is if you're reading text! |
| 02:52 | <TabAtkins> | If your text isnt' in utf-8, what are you doing with your life. |
| 02:52 | <SamB> | I guess a lot of APIs insist on you picking an encoding (possibly raw binary) and sticking with it though |
| 02:52 | <zewt> | (at work, at least) |
| 02:52 | <SamB> | so in that case you'd have to pick at open() time |
| 02:53 | <SamB> | anyway, I found out when working on porting the libstdc++ pretty printers to 2+3 |
| 02:53 | <zewt> | one stupid thing that also impedes my desire to use python 3: print not being a keyword |
| 02:53 | <SamB> | I know, right? |
| 02:54 | <zewt> | like, that's nice and all, but I have years of muscle memory for "print foo" |
| 02:54 | <SamB> | I just wish the REPL had an option to turn it back |
| 02:54 | <SamB> | I don't really care so much in code |
| 02:54 | <SamB> | maybe also for -c ... |
| 02:54 | <SamB> | or was that -e |
| 02:56 | <SamB> | (also when are they going to support proper SIGINT handling?) |
| 02:56 | <caitp> | file a bug on your favourite implementation with an issue tracker |
| 02:57 | <zewt> | if you want a real, serious gripe for Python (and there really are only a few), look at its HTTPS server certificate handling |
| 02:57 | <zewt> | (there isn't any) |
| 02:58 | <SamB> | caitp: I think exarkun already filed it |
| 02:58 | <caitp> | then you know what you have to do |
| 02:58 | <caitp> | get 600 of your closest friends to spam it with "+1" |
| 02:59 | <SamB> | google is silly |
| 03:00 | <KevinMarks2> | I've been reading the anti python 3 rants and they all seem very command line oriented |
| 03:00 | <SamB> | it wants to google for "exar kun python" or "exar kun twisted" |
| 03:00 | <KevinMarks2> | Whereas the python 3 changes seem more Internet oriented |
| 03:00 | <caitp> | autonomously? |
| 03:00 | <SamB> | even though the nick connected with those topics is almost invariably spelled "exarkun" |
| 03:01 | <zewt> | i think there are too many changes in 3 to categorize them |
| 03:01 | <SamB> | caitp: I typed exarkun and that's what came up in the suggestions |
| 03:01 | <SamB> | well, along with some star wars stuff |
| 03:01 | <SamB> | where the one with the space makes sense |
| 03:11 | <SamB> | hmm, guess I misremembered who filed <http://bugs.python.org/issue1054041>; ... |
| 03:15 | <caitp> | looks like thats been open for basically since the dawn of time |
| 05:12 | <Hixie> | TabAtkins: if the contract is "pass me what might be a valid file handle or might not, and i'll act accordingly", then an async response might make sense in that scenario |
| 05:13 | <Hixie> | TabAtkins: if the contract is "pass me a guaranteed valid file handle", then an async response wouldn't make sense |
| 05:15 | <Hixie> | TabAtkins: but if the contract is "pass me what might be a valid file handle" and you pass it a banana, i wouldn't want an async response, because wtf is my async handler supposed to do with that? |
| 05:17 | <caitp> | for Hixie's point, if you can prevent the async operation from ever taking place if it should result in an error, then great, there might be a tiny performance benefit and a better guarantee of correctness. to TabAtkin's point, it means you end up with a lot messier, less reasonable code |
| 05:18 | <Hixie> | it doesn't make the code more messy |
| 05:18 | <Hixie> | nobody is going to be handling these exceptions one way or the other |
| 05:18 | <caitp> | sure they are |
| 05:18 | <Hixie> | in fact it's less messy if the exceptions are sync |
| 05:18 | <Hixie> | since there's no code there |
| 05:18 | <Hixie> | but if they're async you have to at least have an "else, do nothing" clause |
| 05:19 | <caitp> | you're writing a toolkit which people will use which makes some async call --- they want you to set some readonly parameter of an xhr object to some value which isn't supported in that browser yet (such as "json" for responseType in safari) |
| 05:20 | <caitp> | well, not "readOnly" |
| 05:20 | <caitp> | you know what I mean, limited set of allowed values :> |
| 05:20 | <caitp> | anyways, so the library won't want to break your code, because it works perfectly well on other browsers |
| 05:20 | <Hixie> | setting an attribute is a beautiful case of where bad values should be handled by throwing an exception |
| 05:20 | <caitp> | so they will add a bunch of gross error checking |
| 05:20 | <caitp> | and it gets messy and hurts performance |
| 05:20 | <Hixie> | because where the heck would the promise even be given |
| 05:21 | <caitp> | well, this isn't a DOM api example, but I think the same sort of thing applies |
| 05:21 | <caitp> | you're setting a value which browser X doesn't support, but browser Y does |
| 05:21 | <caitp> | it throws --- you have to handle this because you support browser Y |
| 05:21 | <Hixie> | in non-DOM APIs, I can already do what i want, and i don't care how other people write their code |
| 05:22 | <Hixie> | it's the DOM APIs I care about here |
| 05:23 | <caitp> | which is great and all, except that people can and do wrap DOM apis to get more consistent or easier ways to interact with them |
| 05:23 | <caitp> | and have been doing this for a pretty long time now |
| 05:23 | <Hixie> | lots of people wrap DOM APIs in lots of different ways, sure |
| 05:24 | <caitp> | all I'm sayin is, if you need try/catch blocks to get consistent behaviour across implementations, that sucks |
| 05:25 | <Hixie> | can you show me what you think it would look like the way i'm asking for and the way you're asking for? |
| 05:25 | <Hixie> | i'm not sure i understand |
| 05:33 | <caitp> | https://gist.github.com/caitp/c63788b2a308b4b2c56c |
| 05:33 | <caitp> | that's a pretty simple example --- oh, and it doesn't actually accomplish consistent behaviour across browsers |
| 05:34 | <caitp> | i mean, it does get api consistency |
| 05:34 | <caitp> | but for consistent behaviour across browsers you'd need a separate try/catch for each problematic property |
| 05:34 | <caitp> | and a fallback behaviour in the case of an error |
| 05:34 | <Hixie> | this is which case? the case as you want it or the case as i want it? |
| 05:34 | <Hixie> | i'm not sure I really understand this example. |
| 05:35 | <caitp> | i don't really have a strong opinion one way or the other on the promise thing |
| 05:35 | <Hixie> | oh ok |
| 05:35 | <caitp> | but I think in real applications, throwing synchronously for async operations can mean that you have to handle both synchronous and asynchronous errors |
| 05:35 | <caitp> | in many cases |
| 05:35 | <caitp> | and this is messy |
| 05:35 | <Hixie> | i don't understand why you ever have to handle the synchronous errors i'm talking about |
| 05:36 | <Hixie> | if the code is written right, you'll never get them |
| 05:36 | <caitp> | because safari doesn't support a feature that you want to use in your app which works perfectly well on FFos |
| 05:36 | <Hixie> | (i guess except if you're feature-testing, but in that specific case a sync exception is a hell of an easier way to deal with it than an async one) |
| 05:36 | <caitp> | or IE doesn't, or Opera doesn't, or... etc |
| 05:36 | <Hixie> | (sync exception from the browser, i mean) |
| 05:37 | <caitp> | sure, but then you still need to tiptoe around the synchronous errors |
| 05:37 | <Hixie> | there's no tip-toeing dude. you just wrap the call you're unsure about in a try/catch and use the alternative api if it throws. |
| 05:37 | <Hixie> | it's as blunt as it comes. |
| 05:37 | <caitp> | that's tiptoeing |
| 05:37 | <Hixie> | it's as subtle as an axe. |
| 05:38 | <caitp> | okay, let's put it another way, it's going an extra length to evade an error that realistically you shouldn't even have to care about |
| 05:38 | <caitp> | because you're writing tests to verify that your code works as you expect it to |
| 05:39 | <caitp> | you're paying some kid 200k/year to manage your selenium testing infrastructure |
| 05:39 | <Hixie> | what? no, i'm just talking about feature-testing here |
| 05:39 | <Hixie> | try { someHostObject.someAttribute = 'someValueThatMightNotBeSupported' } catch { someHostObject.someAttribute = 'theSadderAlternative' } |
| 05:40 | <Hixie> | that's it |
| 05:40 | <caitp> | yeah i think there are a couple points being made about this and they're getting mixed up a bit |
| 05:40 | <Hixie> | that would certainly explain why i am regularly feeling in this discussion (not just with you) that people are arguing against points i haven't made |
| 05:41 | <caitp> | so, I don't have a strong opinion on it, I could live with synchronous exceptions -- they do win for feature detection |
| 05:42 | <caitp> | but, I think they can still lead to the writing of very messy code, too |
| 05:42 | <Hixie> | (have you seen the kind of code that promises can lead to? they're hardly a panacea either.) |
| 05:43 | <Hixie> | except for feature testing, the code for what i'm proposing is exactly zero lines of code. |
| 05:43 | <Hixie> | and for feature testing, it's simpler with exceptions. |
| 05:43 | <caitp> | definitely--but I think if you mix and match handling errors in rejection handlers as well as synchronous catch blocks, that's kinda sucky |
| 05:43 | <Hixie> | there's no mixing and matching. |
| 05:43 | <Hixie> | you only handle exceptions in the rejection handlers. |
| 05:43 | <caitp> | ideally, asynchronous apis should __always__ be asynchronous |
| 05:44 | <Hixie> | yes, the _APIs_ should always be asynchronous. no objection there. |
| 05:44 | <Hixie> | i'm only talking about how the UA reacts when you do something outside of the API |
| 05:44 | <Hixie> | like typo the method call, get the wrong arguments, pass in an object that's of the wrong type or in the wrong state, etc. |
| 05:45 | <caitp> | don't you think for a dynamic language it's easier to deal with this stuff with tests that don't happen during the runtime of the actual application? |
| 05:45 | <Hixie> | can you elaborate on "this stuff"? |
| 05:45 | <caitp> | checking for things like syntax errors or type errors |
| 05:45 | <Hixie> | yes. |
| 05:46 | <Hixie> | that's my point. |
| 05:47 | <caitp> | but then you're also saying you want to have the same behaviour during runtime, and I'm less sure about that, because the audience of a live application doesn't get much benefit from hearing about how you mistyped something |
| 05:47 | <Hixie> | pretty sure the audience of a live application doesn't care if they hear about it via exceptions or rejected promises |
| 05:48 | <caitp> | they might care because it won't crash their app ;p |
| 05:48 | <Hixie> | but if they hear about it via exceptions, the code will just stop, whereas if they get a rejected promise, the code will continue, likely doing unexpected things (since the code isn't ready to accept this) and corrupting their data. |
| 05:49 | <caitp> | yeah but you just know people are just going to use sweetjs to wrap everything in try/catch blocks so that their precious puppy catalog app doesn't break |
| 05:49 | <Hixie> | we're already past the point where their app breaks |
| 05:49 | <Hixie> | we're just debating how it breaks |
| 05:50 | <Hixie> | notice that nothing that the "all promises all the time" team is proposing will stop ReferenceErrors (where you typo the method name) from being sync |
| 05:50 | <Hixie> | i'm just saying we should have a few more sync exceptions than they are |
| 05:52 | <caitp> | so, this takes us back to the feature-detection thing, because I agree that you shouldn't need to handle exceptions like that (although I know that people will go out of their way to solve the problem the "wrong way" with catch blocks) |
| 05:52 | <caitp> | and this is the case where browser A behaves correctly, and browser B doesn't, and browser C also doesn't, but behaves incorrectly in a different way |
| 05:53 | <caitp> | this would vary from api to api, but if things are going to throw when they really shouldn't, that really sucks |
| 05:54 | <caitp> | and yeah, rejection handlers don't really solve that |
| 05:54 | <caitp> | that's true |
| 07:22 | <krit> | zcorpan: Is there anything that is not addressed on DOMPoint, DOMRect, DOMQuad in http://dev.w3.org/fxtf/geometry/ ? |
| 07:26 | <zcorpan> | krit: don't think so |
| 07:28 | <Ms2ger> | On Ringmark: "we were instructed to take whatever steps were necessary to make Firefox and Opera look as good as possible in those tests so that some kind of partnership might blossom" |
| 07:31 | <krit> | zcorpan: ok, I will ask for a detailed review tomorrow and give a 2 weeks time frame. If there are no bigger concerns, we can move to LC. |
| 07:31 | <zcorpan> | krit: ok |
| 07:32 | <krit> | zcorpan: because we are at it, why does DOMQuad have no CTOR for DOMPoint? http://dev.w3.org/fxtf/geometry/#DOMQuad |
| 07:32 | <krit> | sorry, DOMPointReadOnly as argument I mean |
| 07:32 | <krit> | just has DOMPointInit |
| 07:34 | <zcorpan> | krit: you can pass in such objects and webidl rules convert them to DOMPointInit |
| 07:34 | <krit> | zcorpan: oh cool, didn't know that |
| 07:35 | <zcorpan> | i guess we could put in a few notes about webidl tricks the spec uses |
| 07:35 | <krit> | zcorpan: yes, some examples. Was about to add some today. Would be great if you could add some for DOMQuad or DOMRect where appropriate |
| 07:36 | <zcorpan> | krit: can you file bugs where you want me to add examples? |
| 07:36 | <krit> | zcorpan: hm, I try to :) |
| 07:36 | <zcorpan> | thx :-) |
| 07:44 | <krit> | zcorpan: added 3 bug reports. Think the spec would benefit of examples here. https://www.w3.org/Bugs/Public/buglist.cgi?component=Geometry&list_id=37973&product=FXTF&resolution=--- I can create the graphics for 25904 if you create the example. |
| 07:45 | <krit> | zcorpan: DOMMatrix needs some examples as well of course. Add them today. |
| 07:45 | <zcorpan> | krit: ok |
| 07:45 | <zcorpan> | krit: i can try to look at it next week i think |
| 07:46 | <krit> | zcorpan: maybe I can try to create some examples and give it to you for review |
| 07:48 | <zcorpan> | bbiab |
| 07:49 | <annevk> | Domenic: they do, but you don't really have to queue a task in this case; you want to change state on an object and resolve the promise, and only expose the object's changed state the moment the promise's callbacks are invoked in the microtask queued for that |
| 08:06 | <annevk> | Domenic: TabAtkins: hmm yeah I guess you have to queue a task, seems somewhat sad it cannot be done in that microtask that's already happening anyway |
| 08:17 | <foolip> | annevk: the path to icons is wrong now in e.g. http://html5.org/r/6551 |
| 08:23 | <annevk> | foolip: fixed |
| 08:29 | <annevk> | After a little over three years https://github.com/whatwg/dom/commit/9c2833fe3833d709dd9d66c985131528ff1bd966 it seems we are finally getting to the point where the "Core" part of DOM Level 3 Events is finally made obsolete https://www.w3.org/Bugs/Public/show_bug.cgi?id=25485#c5 |
| 08:38 | <MikeSmith> | hayato: two of the shadow-dom testing PRs at https://github.com/w3c/web-platform-tests/pulls/iseki-masaya have been awaiting review for a couple of months now |
| 08:40 | <hayato> | MikeSmith: Let me review those. Thanks for letting me know that. |
| 08:40 | <MikeSmith> | hayato: thanks much |
| 08:42 | <MikeSmith> | hayato: btw the submitter of those two PRs didn't respond at all to the previous review comment you made on the third one, so I'm not sure it's super likely he'll respond on these. So don't sink a huge amount of time into it. |
| 08:44 | <hayato> | MikeSmith: I got it. Ill see to it. Thank you for your help. |
| 08:54 | <foolip> | annevk: thanks! |
| 09:00 | <annevk> | jungkees: thanks for working on the hooks, will review in a bit |
| 09:01 | <jungkees> | annevk: thanks! |
| 09:01 | <annevk> | jungkees: btw, started working on this: http://fetch.spec.whatwg.org/#fetch-api |
| 09:03 | <jungkees> | annevk: I've seen that and will follow on it |
| 09:03 | <annevk> | jungkees: btw, please make it clear somehow that the Cache API will be generic and needs to work in a document environment as well eventually |
| 09:03 | <annevk> | jungkees: was not clear to the person working on it in Gecko |
| 09:05 | <jungkees> | annevk: JakeA has better idea I think. AFAIK, we intended to enable that in document context during the dicussion |
| 09:05 | <jungkees> | annevk: not for V1 I guess |
| 09:06 | <annevk> | jungkees: JakeA: yeah, but there should at least be a note to that effect |
| 09:07 | <JakeA> | annevk: same for fetch()? |
| 09:12 | <annevk> | JakeA: in Fetch I defined fetch() as being exposed as window.fetch() |
| 09:12 | <JakeA> | ahh cool |
| 09:12 | <annevk> | JakeA: we'll see what implementations say |
| 10:03 | <annevk> | TabAtkins: your guide looks good, might want to coordinate or link to Domenic's version here https://github.com/w3ctag/promises-guide |
| 11:05 | <jgraham> | zcorpan, foolip: Thanks for the help with the WebVTT issues |
| 11:05 | <foolip> | jgraham: np! |
| 11:13 | <krit> | zcorpan: added examples and notes http://dev.w3.org/fxtf/geometry/#DOMQuad |
| 11:14 | <zcorpan> | krit: ok cool. i don't have time to review today, though :-( |
| 13:24 | <zcorpan> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=25894 ... so .... people expecting their feedback to go to /dev/null might explain some of the junk bugs we get |
| 13:27 | <zcorpan> | Hixie: maybe s/Submit Review Comment/Submit Bugzilla Issue/ ? |
| 13:27 | <zcorpan> | or just "Report bug" maybe |
| 13:28 | <annevk> | If that guy had a million discussions about charset, he didn't learn much from it :/ |
| 13:28 | <annevk> | Or gal, I guess |
| 14:24 | <caitp> | they seem upset |
| 14:29 | <annevk> | caitp: so is plural the preferred form? seems so weird |
| 14:29 | <caitp> | ¯\_(ツ)_/ |
| 14:52 | <TabAtkins> | annevk: Except for the part where I said "dunno lol, ask Anne", of course. |
| 14:54 | <annevk> | TabAtkins: yeah so it seems like you might have to queue a task, except that seems somewhat sad since a microtask would happen for the promise already (if there's listeners) |
| 14:54 | <annevk> | TabAtkins: maybe Hixie or Domenic has some thoughts on that |
| 14:54 | <TabAtkins> | Right, if you could align with the promise's microtask it would be nice. |
| 14:54 | <annevk> | Queuing a task would do that btw, it's just not as "quick" |
| 14:57 | <TabAtkins> | Because it's technically two tasks? |
| 15:01 | <annevk> | TabAtkins: because it happens later (e.g. if there's a bunch of other stuff queued) |
| 15:01 | <annevk> | TabAtkins: but that might be okay, the other stuff might be more important |
| 15:02 | <TabAtkins> | Eh, doesn't matter all that much. It's async already, so the exact point in time when the info change becomes visible isn't that important, as long as it happens before promise resolution. |
| 15:02 | <TabAtkins> | So the language is just "queue a (micro?)task to XXX" in the middle of an algo step? |
| 15:10 | <annevk> | TabAtkins: queue a task to set status and resolve promise to y I suppose |
| 15:11 | <annevk> | TabAtkins: note that I still think changing status without having a way to get notified about that is bad, better to leave it unchanged in that case |
| 15:11 | <TabAtkins> | Hm, ok. So just resolving promise normally (no task language) is fine when nothing else accompanies it, but for clarity you should resolve it in the same task that you're setting observable state in, if you're doing so. |
| 15:13 | <annevk> | TabAtkins: otherwise promise observers would get called before the state was changed |
| 15:14 | <TabAtkins> | Oh, because of the task/microtask distinction? |
| 15:14 | <annevk> | Yes, promise thing would happen end-of-current task, whatever that is, and state thing would at best happen next-task |
| 15:15 | <TabAtkins> | Okay. And it's a no-no to explicitly invoke microtasks in async algos, because those are reserved for only a handful of things? |
| 15:17 | <annevk> | TabAtkins: it seems like these days you could queue a microtask |
| 15:18 | <annevk> | TabAtkins: I'd like to know what Hixie thinks about using that |
| 15:21 | <TabAtkins> | That would let me make the state change without delaying promise resolution until the next task |
| 15:22 | <TabAtkins> | Either way maintains the necessary ordering, but resolving the promise on a task is obviously slower. |
| 15:23 | <JonathanNeal> | Is there a polyfill for Element.prototype.queryAll? |
| 15:25 | <annevk> | TabAtkins: it's later, might not be slower overall |
| 15:28 | <TabAtkins> | annevk: Yeah, but chaining "later" multiple times is slower. |
| 15:28 | <TabAtkins> | JonathanNeal: jQuery |
| 15:29 | <JonathanNeal> | TabAtkins: one of those days, huh. :-) |
| 15:29 | <annevk> | TabAtkins: example? |
| 15:30 | <TabAtkins> | JonathanNeal: Being serious. Jq's .find is our .query all. |
| 15:31 | <TabAtkins> | annevk: If you're gonna kick off more async requests, you want those as soon as possible |
| 15:32 | <TabAtkins> | On the other hand, you might be kicking off async requests from event handlers too |
| 15:32 | <TabAtkins> | So I guess it doesn't actually matter. |
| 15:43 | <Hixie> | TabAtkins, annevk: i'm here, not sure i understand the discussion above though (missing some context?) |
| 15:43 | <TabAtkins> | Hixie: I have an algo with an async section... |
| 15:43 | <TabAtkins> | Hixie: In it, I need to make some author-visible state change (set a FontFace's status attribute to "loaded"), and then resolve a promise. |
| 15:44 | <TabAtkins> | Hixie: I think I need to queue a task to do the attribute setting, so it happens at a well-defined time. |
| 15:44 | <TabAtkins> | Hixie: And I should probably also resolve the promise in the task, so there's a well-defined ordering between attribute-set and promise-resolve. |
| 15:44 | <Hixie> | ideally you'd make it happen in the same microtask as the promise is resolved in |
| 15:44 | <TabAtkins> | Hixie: But should I do those operations in a task or a microtask? |
| 15:44 | <Hixie> | er |
| 15:44 | <Hixie> | as the promise callback is called in |
| 15:45 | <TabAtkins> | Yeah, kk. (I was about to correct your terminology. ^_^) |
| 15:45 | <Hixie> | but failing that, this seems like the kind of thing i would use "await a stable state" for |
| 15:45 | <TabAtkins> | So it ideally happens in the same microtask as promise callbacks, before the callbacks are called. I don't think we have prose hooks for that. |
| 15:46 | <TabAtkins> | Hm, interesting. |
| 15:46 | <Hixie> | that lets you build the algorithm pretty neatly, but in the background it's just built with microtasks |
| 15:46 | <Hixie> | basically it lets you designate a set of steps that execute as a microtask while the rest of the algorithm is async |
| 15:46 | <Hixie> | a bit like a synchronised section |
| 15:47 | <TabAtkins> | Example in a spec? |
| 15:47 | <Hixie> | one sec |
| 15:48 | <Hixie> | search for "Failed with elements: Queue a task to fire a simple" |
| 15:48 | <Hixie> | and look at steps 10-20 below that |
| 15:49 | <TabAtkins> | Urg, I gotta load single-page for that. kk. |
| 15:49 | <Hixie> | one sec |
| 15:49 | <Hixie> | i can give you the multipage link |
| 15:50 | <TabAtkins> | Would be nice, since I'm tethering my internet right now. |
| 15:50 | <Hixie> | it's in http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#concept-media-load-algorithm |
| 15:50 | <Hixie> | but ignore the first occurance of stable-state in that algorithm and look for the one i mentioned earlier |
| 15:50 | <Hixie> | because the first one does a confusing fork in the middle of the stable state |
| 15:51 | <Hixie> | and that obscures the point i'm trying to make :-) |
| 15:52 | <TabAtkins> | Okay, cool. I'll recommend using a nested list for that, rather than unicode characters, but this works. ^_^ |
| 15:52 | <Hixie> | well the unicode characters are non-normative |
| 15:52 | <Hixie> | they just make it more obvious where the synchronisation starts and ends |
| 15:53 | <Hixie> | (i recommend being typographically consistent for the readers' benefit) |
| 15:54 | <Hixie> | but sure, it could also be described as a set of steps in a sublist |
| 15:54 | <TabAtkins> | So I think I'd go "Asynchronously await a stable state, then execute the following steps synchronously: <nested-list>". |
| 15:54 | <TabAtkins> | Where <nested-list> is "1. Set font face's status attribute to "loading". 2. Accept the promise with font face.". |
| 15:59 | <Hixie> | make sure if this isn't the end of the algorithm that you also have the "3. Resume the rest of the algorithm asynchronously." |
| 16:00 | <TabAtkins> | Isn't that implied by the end of the list? |
| 16:00 | <Hixie> | someone filed a bug asked for me to spec focusin/focusout, so I filed a bug on a browser asking if we could maybe remove them instead, and the end result is that now I might have to also spec DOMFocusIn/DOMFocusOut. wtf. |
| 16:00 | <Hixie> | TabAtkins: as currently written, no |
| 16:00 | <Hixie> | TabAtkins: (because don't forget, in my case i don't have a nested list) |
| 16:00 | <TabAtkins> | I know that in your case you don't. |
| 16:01 | <TabAtkins> | I suppose being clear about things is fine. Just trying to reduce boilerplate to a minimum. |
| 16:04 | <Hixie> | understood |
| 16:05 | <Hixie> | i think synchronous sections are confusing enough that being overtly explicit each time is probably reasonable |
| 16:09 | <annevk> | Hixie: focus :-( |
| 16:13 | <annevk> | Also, recent emails on UI events :-( |
| 16:14 | <annevk> | "We'll just augment that other spec" |
| 16:21 | <annevk> | Hixie: you still around? Should we talk about cleanup now? |
| 17:50 | <Hixie> | annevk: i've got some time this afternoon, but right now is poor |
| 18:22 | <estellevw> | Is Emotion Markup Language (http://www.w3.org/TR/2014/REC-emotionml-20140522/) something that might be brought into html? |
| 18:24 | <Hixie> | estellevw: what's the use case? |
| 18:25 | <Hixie> | estellevw: are any browsers interested in implementing it? |
| 18:25 | <estellevw> | i don't have one. I was basically wondering if it's something anyone cares about and if I should spend brain cells on it |
| 18:25 | <estellevw> | but if no one has even heard about it, the answer would be no |
| 18:25 | <estellevw> | at least at this time |
| 18:26 | <Hixie> | i've only heard of it in the context of jokes... |
| 18:29 | <estellevw> | ok, thanks. I thought it might be a joke, but too much effort seemed to have been put in it for it to be one, and the date wasn't April 1 |
| 18:33 | <Hixie> | oh i'm sure it was not intended as a joke |
| 18:34 | <Hixie> | not clear what it's relationship to the web is though, even though it happened at the w3c |
| 19:28 | <annevk> | *-Star |
| 19:29 | <annevk> | Oh wrong, WS-* |
| 19:58 | <SamB> | emotionml sounds like a *very* strange idea |
| 19:59 | <caitp> | well you need a way to convey <sarcasm /> |
| 20:08 | <japhet> | i looked for this in the spec, but maybe i missed it.....if a document is loaded via POST, then navigates to a fragment identifier, then a reloaded is triggered, should the resulting request be a GET or a POST? |
| 20:09 | <japhet> | the behavior is explicitly state to be GET for pushState and replaceState, but i didn't see anything for fragment identifiers |
| 20:30 | <TabAtkins> | japhet: You're not changing the resource, so I think it's still POST. |
| 20:30 | <TabAtkins> | annevk_: |
| 20:30 | <japhet> | TabAtkins: that was my best guess, but I figured I should ask before arbitrarily changing blink |
| 20:30 | <TabAtkins> | Updated Font Loading to use the right async language, using language culled from Hixie. Review would be appreciated. |
| 20:30 | <TabAtkins> | japhet: Just guessing here, though. Dunno what the specs might say for it. |
| 20:31 | <TabAtkins> | annevk_: Updated Font Loading to use the right async language, using language culled from Hixie. Review would be appreciated. |
| 20:33 | <annevk> | TabAtkins: tomorrow ok? |
| 20:33 | <TabAtkins> | Yeah, no rush. |
| 20:33 | <annevk> | cool |
| 20:35 | <annevk> | TabAtkins: oh, and just to be clear, tweet about standards is not aimed at you either :-) |
| 20:41 | <TabAtkins> | annevk: Hahaha, I knew that. |
| 20:52 | <sgalineau> | TabAkints: in bikeshed README, 'textual shortcuts for autolinks' link 404s for some reason |
| 20:53 | <sgalineau> | TabAtkins, even |
| 20:53 | <TabAtkins> | Weird, I'll check it out. |
| 20:53 | <sgalineau> | it is; the file is definitely there |
| 20:54 | <TabAtkins> | Man, that's been broken *forever*. |
| 20:54 | <TabAtkins> | Fixed now. |
| 20:54 | <TabAtkins> | Typo in the url. |
| 20:54 | <TabAtkins> | (Missing an "s" at the end of "definitions".) |
| 21:17 | <TabAtkins> | annevk: Any objections to me working on Bikeshedding DOM for you? |
| 21:18 | <annevk> | TabAtkins: no sounds great |
| 21:18 | <annevk> | TabAtkins: not sure about putting promise stuff in DOM though ;-) |
| 21:18 | <annevk> | TabAtkins: but that's also for tomorrow |
| 21:19 | <TabAtkins> | kk |
| 21:22 | <Domenic> | How did HTMLSpanElement come about? /cc Hixie |
| 21:23 | <Domenic> | annevk: I think if DOM defines #concept-throw, it can also define #concept-reject. Although I imagine you prefer to move both of those to WebIDL. |
| 21:24 | <annevk> | Domenic: I do |
| 21:24 | <TabAtkins> | Domenic: You mean like, the historical reasoning for adding the <span> element? Or actually the interface? |
| 21:25 | <TabAtkins> | annevk: I'm fine with both of them being in WebIDL too; all I care is that they both exist *somewhere*, and if putting reject in DOM is the fastest way to get it written down somewhere I can refer to, that's better. |
| 21:47 | <Hixie> | MikeSmith: btw, i see 408s all the time with w3c bugzilla, but never anywhere else. so i do think it's something to do with w3c bugzilla. |
| 22:24 | <Domenic> | TabAtkins: the interface. Given that it adds nothing to HTMLElement, I feel there must be a story there. |
| 22:57 | <TabAtkins> | Yeah, identification. There's sine missteps, but *most* elements have unique interfaces. |