| 00:08 | <Domenic> | I wonder if Chrome's latest block-small-flash thing blocks it |
| 00:26 | <Jasper> | Is there an adjective or word used to describe a URL intended to be navigated to vs. loaded? |
| 00:26 | <Jasper> | e.g. /foo.css isn't usually intended to be navigated to, and /my-app/#home-page isn't intended to be loaded, per se. |
| 00:27 | <Jasper> | I don't know if there is existing or better terminology for this. |
| 00:30 | <Domenic> | Maybe URL vs. href? |
| 00:30 | <Jasper> | I suppose, yeah. |
| 00:30 | <gsnedders> | Domenic: generically, to try and find spec bugs; in this case, to see if we can get anything useful |
| 00:30 | <Jasper> | There are other ways to navigate but I won't be that pedantic. |
| 00:30 | <Jasper> | I was wondering if there was any distinction between these "classes of resources", or, at the very least, classes of actions. |
| 00:52 | <Domenic> | There are distinct navigate and fetch algorithms (with navigate depending on fetch) |
| 02:21 | <boogyman> | URL paths starting with TR should not be referenced correct? What is the justification behind that? |
| 02:24 | <tantek> | sounds like an FAQ. likely reason: by the time something makes it to TR, there are already bug fixes in the living spec and/or editor's draft, and those should be referenced instead (since they're more up to date) |
| 02:29 | <boogyman> | cheers |
| 13:14 | <annevk> | tobie: I can't run bikeshed on IDL anymore |
| 13:15 | <tobie> | that sounds bad. |
| 13:15 | <tobie> | annevk: do you have a dump you can share? |
| 13:17 | <annevk> | tobie: filed https://github.com/heycam/webidl/issues/233 |
| 13:17 | <annevk> | tobie: doesn't fail on other specs, with fresh bikeshed |
| 13:18 | <tobie> | annevk: wfm right now, but haven't upgraded bikeshed in a week |
| 13:19 | <tobie> | annevk: doing so right now |
| 13:19 | <annevk> | tobie: I think it has to do with an update from last night, where the IDL parser got an update |
| 13:20 | <annevk> | tobie: I guess it triggers on something in the IDL specification |
| 13:20 | <tobie> | annevk: oh |
| 13:20 | <tobie> | sounds fun |
| 13:20 | <annevk> | Someone contributed a patch to Fetch to make use of the new record type |
| 13:20 | <annevk> | That triggered an issue against the IDL parser, then Bikeshed, and now IDL itself |
| 13:21 | <annevk> | Early adopter pain |
| 13:21 | <tobie> | yeah-- |
| 13:22 | <annevk> | One thing I notice is that we haven't really embraced the importance of <dfn> yet and how it sets up a framework |
| 13:22 | <annevk> | We often skim over it in reviews while it's quite an important aspect |
| 13:23 | <tobie> | annevk: yeah. There a pretty big lack of consistency around this. |
| 13:25 | <tobie> | annevk: we should probably agree on some guidelines around this, which should probably be written somewhere |
| 13:32 | <tobie> | annevk: see https://github.com/tabatkins/bikeshed/issues/867 |
| 13:33 | <annevk> | good times |
| 13:40 | annevk | wonders if zcorpan is interested in converting html-differences away from Anolis |
| 13:40 | <annevk> | At this point, we have encoding/html-differences/mimesniff/xhr |
| 14:06 | <tobie> | annevk: jyasskin's on paternity leave. |
| 14:06 | <annevk> | tobie: oh, I guess then we should assume copypasta |
| 14:06 | <annevk> | tobie: since it doesn't make much sense |
| 14:07 | <tobie> | annevk: yeah--this needs cleanup |
| 15:38 | <annevk> | JakeA: async function x() { w(2) }; w(1); x(); w(3) |
| 15:38 | <annevk> | JakeA: any idea why the order is 123? |
| 15:39 | <annevk> | JakeA: async is sync unless you have await? |
| 16:09 | <Domenic> | kind of... |
| 16:09 | <Domenic> | async functions still run their steps synchronously |
| 16:09 | <Domenic> | they just return a promise |
| 16:09 | <Domenic> | and if you put an await inside them then any steps after that await run after the promise settles |
| 16:11 | <JakeA> | annevk: same as the function you pass into the promise constructor |
| 16:12 | <JakeA> | Runs sync |
| 16:12 | <annevk> | okay, so you could kinda use them for event listeners, just invoke preventDefault before you go async |
| 16:27 | <Ms2ger> | annevk, huh, there was a thread on mozilla.dev.platform about that just earlier today |
| 17:17 | <TabAtkins> | tobie: Ugh, sorry, fixed. Would have fixed last night (I learned about it just after I left work), but my laptop's not in a working state at the moment. Sorry again. |
| 17:18 | <tobie> | TabAtkins: np. shit happens. especially these days. |
| 17:19 | <tobie> | TabAtkins: I think annevk lost more time over it than I did. :) |
| 17:19 | <TabAtkins> | My fault for not having adequate test coverage. Definitely mea culpa. |
| 17:19 | <TabAtkins> | Fixing that now, obvs. ^_^ |
| 17:22 | <tobie> | TabAtkins: CI was red though |
| 17:22 | <tobie> | TabAtkins: on master |
| 17:23 | <TabAtkins> | Because I pushed several commits at once, it "broke" on a nonsensical commit, so I figured it was something minor to do with output formatting. I didn't check on it immediately, and then forgot to follow up before I left. :/ |
| 17:27 | <tobie> | TabAtkins: oh, that explains why I was seeing the issue on head, but had to checkout head^^^ to get it working again |
| 17:27 | <TabAtkins> | yup ;_; |
| 17:28 | <TabAtkins> | Need to push every time, I guess. Was just doing some repo cleanup. |
| 17:28 | <TabAtkins> | (I did test that commit, but not with the testsuite - I ran it on DOM, which uses syntax highlighting but not any *WebIDL* syntax highlighting, which is the part that broke.) |
| 18:01 | <annevk> | TabAtkins: oh, why doesn't DOM use IDL syntax highlighting? |
| 18:02 | <TabAtkins> | It has all real IDL, which is highlighted directly; it doesn't invoke the highlighting code to color any example WebIDL. ^_^ |
| 18:02 | <TabAtkins> | It's the "example WebIDL" part that I moved into the new file without moving all of its dependencies. |
| 18:02 | <TabAtkins> | (I was just shifting some code to separate files to reduce the "everything is in __init__" problem a little bit.) |
| 18:03 | <annevk> | TabAtkins: ah okay |
| 18:03 | <annevk> | TabAtkins: btw, given your comments I think I can merge https://github.com/whatwg/encoding/pull/79 right? |
| 18:03 | <annevk> | TabAtkins: and just hope the LINK ERROR will disappear |
| 18:03 | <TabAtkins> | Yeah, go for it. |
| 18:04 | <TabAtkins> | Doing some fiddling right now to make it go away. |
| 18:09 | <annevk> | ta |
| 18:10 | <annevk> | 3 more Anolis documents to go |
| 18:10 | <annevk> | html-differences, which I hope zcorpan will do |
| 18:10 | <annevk> | and xhr / mimesniff |
| 18:10 | <annevk> | I plan on doing mimesniff tomorrow |
| 18:10 | <annevk> | xhr is mostly done, but overloads :/ |
| 18:57 | <tobie> | Domenic: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22859 got me to dig into the WebIDL number types (I misunderstood the issue and new little about how the different number types worked and, tbh, not much more about how numbers are stored). Ended up at https://github.com/heycam/webidl/issues/33, which now makes a lot of sense. |
| 18:57 | <tobie> | Domenic: I could refactor all of those number bindings to something like: |
| 18:59 | <tobie> | https://www.irccloud.com/pastebin/4doiIQ8y/ |
| 19:00 | <tobie> | Domenic: It would make things shorter and clearer and help prepare for something like what you describe in #33 |
| 19:01 | <tobie> | Domenic: I'm not entirely convinced it's useful, though. |
| 19:01 | <tobie> | Domenic: thoughts? |
| 19:09 | <Domenic> | tobie: I think there's value in re-doing the number types to have less repetitive boilerplate |
| 19:09 | <Domenic> | tobie: I'm not sure about that exact formulation but maybe that's the way to go |
| 19:10 | <Domenic> | It simply would make it easier to read and understand what is going on |
| 19:10 | <tobie> | Domenic: yeah, it took me a long time to figure out what was going on |
| 19:10 | <tobie> | Domenic: and that all that repetition was actually repetition |
| 19:10 | <Domenic> | E.g. maybe you don't use the ES operations like bug 22859 says, and just say "return the result of performing a numeric conversion with 2^8 as the upper bound" |
| 19:11 | <tobie> | yeah, not using the ES operations makes it easier |
| 19:11 | <Domenic> | tobie: you may enjoy https://github.com/jsdom/webidl-conversions/blob/master/lib/index.js#L6-L118 |
| 19:12 | <Domenic> | I guess the integer types are where the repetition really happens |
| 19:12 | <tobie> | Domenic: oh, that is really cool |
| 19:12 | <tobie> | Domenic: yes, and well, given how many they are, that's a lot of repetition |
| 19:12 | <tobie> | *there |
| 20:19 | <botie> | rniwa, at 2016-11-09 17:28 UTC, annevk said: if there are any missing custom element or shadow tree tests? |
| 20:40 | <tobie> | Domenic: your long long implementation doesn't seem to match the spec (at https://github.com/jsdom/webidl-conversions/blob/master/lib/index.js#L93-L94). It might be right, but if so, I don't understand why. |
| 20:41 | <Domenic> | tobie: hmm yeah it seems like 32 should be 53 right? |
| 20:41 | <tobie> | Domenic: yes |
| 20:42 | <Domenic> | Filed, thanks |
| 20:42 | <tobie> | Domenic: Any pointers on how a long long work? |
| 20:42 | <tobie> | Domenic: is it storing an exponent? |
| 20:43 | <Domenic> | tobie: what do you mean how it works? |
| 20:44 | <tobie> | Domenic: like what it's using its bits for. |
| 20:44 | <Domenic> | tobie: what bits? Do you mean in browser implementations? They probably just use int64. |
| 20:45 | <tobie> | Domenic: does int64 also loose precision above a certain threshold? |
| 20:46 | <Domenic> | tobie: above 2^63 it starts wrapping around to -2^64 + 1 or something similar |
| 20:47 | <tobie> | Domenic: I'm just trying to understand why we have this weird 2^53 threshold in long long |
| 20:47 | <jsbell> | above 2^53, n + 1 stops making giving integer values |
| 20:47 | <jsbell> | sorry... |
| 20:48 | <jsbell> | above 2^53, n + 1 stops making sense (i.e. n + 1 === n in some cases) |
| 20:48 | <Domenic> | tobie: oh, that's because *in JS* everything is represented with 64-bit float (double), which acts as jsbell says |
| 20:51 | <tobie> | Domenic: so we're just making sure that the number can be represented in JS |
| 20:52 | <Domenic> | tobie: represented as an unambiguous integer, but yeah |
| 20:52 | <tobie> | jsbell: thanks |
| 21:00 | <TabAtkins> | The last unambiguous integer is 2^53-1, mind you. 2^53 is ambiguous, because 2^53+1 is the first "lost" integer, that rounds down to 2^53. |
| 21:04 | <tobie> | Reading up on the number type in ES6. |
| 21:05 | <annevk> | Poor tobie |
| 21:05 | <tobie> | yes, I think I deserve hugs |
| 21:22 | <TabAtkins> | Meh, it's a 64-bit float. Been used for decades. Nothing too fancy. |
| 21:27 | <caitp> | did you ever have to sit through multiple lectures in college about ieee754 floats and their format in school? |
| 21:27 | <caitp> | anyone who does that deserves hugs |
| 21:41 | <tobie> | I took philosophy and English literature in college, with a minor in fine arts. |
| 21:42 | <TabAtkins> | I mean, we def discussed it in Computer Architecture, yeah. Kinda important to know the bit patterns when you're gonna be twiddling them. |
| 21:42 | <tobie> | Yes. Hence reading up. |
| 21:42 | <tobie> | :) |
| 21:43 | <TabAtkins> | Ah, didn't realize you were totally new to them. They're fun, then! |
| 21:43 | <TabAtkins> | 1 sign bit, 11 exponent bits, 52 value bits (really 53, due to the "hidden bit") |
| 21:45 | <astearns> | "last unambiguous integer" is my favorite phrase of the day |
| 21:45 | <astearns> | makes me think of computers just counting up to "lots and lots" and giving up after that |
| 21:46 | <TabAtkins> | I mean, that's how computers work, yeah. |
| 21:46 | <TabAtkins> | For interesting definitions of "giving up". |
| 22:09 | <tobie> | The hidden bit? |
| 22:11 | <tobie> | Oh boy. That looks complicated. |
| 22:15 | <caitp> | the week of that class devoted to this probably gave the coffeeshop an extra 1200$ in revenue |
| 22:16 | <tobie> | :D |
| 22:19 | <TabAtkins> | tobie: The value is always encoded in proper normalized sci-not, where there's only a single, non-zero, digit on the left side of the decimal (like "1.something"). Since this is binary, that digit is guaranteed to be a 1, so there's no need to encode it; we can throw it away and just encode the fractional part instead. Thus we actually have 53 bits of |
| 22:19 | <TabAtkins> | "value", but only encode 52 of them - there's a "hidden bit". |
| 22:19 | <tobie> | Oh. That's it? |
| 22:19 | <TabAtkins> | Yup, that's it. |
| 22:20 | <tobie> | Have you considered teaching? |
| 22:20 | <TabAtkins> | Yes. |
| 22:20 | <TabAtkins> | When I'm done needing money, that's my plan. |
| 22:20 | <tobie> | Yeah. I was going to say something about the pay. |
| 22:21 | <caitp> | tenured positions pay reasonably well, especially if you rise up the foodchain and become a department head or registrar or something |
| 22:21 | <TabAtkins> | My partner chose a low-paying career, so one of us has to stay in a money-making industry. :/ |
| 22:21 | <TabAtkins> | caitp: That's a lot of work, and a lot of time. |
| 22:21 | <caitp> | that is true |
| 22:24 | <tobie> | Yeah. Academia is a long winding road. Wouldn't recommend it as a money making strategy. |
| 22:26 | <jsbell> | *cough* denormalized numbers *cough* |
| 22:28 | <tobie> | jsbell: that sounds funny but I'm not sure why. |
| 22:28 | <TabAtkins> | jsbell: Denormalized numbers are an error case you don't need to worry about. |
| 22:29 | <Domenic> | Added to https://wiki.whatwg.org/wiki/Band_names |
| 22:29 | <TabAtkins> | +1 |
| 22:29 | <jsbell> | TabAtkins: disagree; they show up in JS |
| 22:29 | <TabAtkins> | jsbell: Yeah, they *show up*, but the only consequence is that you end up with less than 53 bits of precision. Not important for learning about doubles. |
| 22:31 | <jsbell> | Just a case where "ays encoded in proper normalized sci-not, where there's only a single, non-zero, digit on the left side of the decimal" stops being true |
| 22:31 | <jsbell> | Oh, and *hugs* all around |
| 22:31 | <TabAtkins> | tobie: For reference, if your exponent is at max-negative, representing a very tiny number very close to zero, the number denormalizes; the hidden bit switches to zero, so you can represent numbers *even smaller* than the exponent suggests. |
| 22:32 | <jsbell> | TabAtkins is indeed good at teaching :) |
| 22:34 | <caitp> | surely your new president elect will support education reforms backed by grants to support higher salaries for new high performing educators, to compete with work in industry, and then you guys can start taking full advantage of that |
| 22:40 | <tobie> | TabAtkins: ok, I guess I see how that makes sense. I also understand why folks would want other number options in JS. |
| 23:03 | gsnedders | can't actually remember that much detail about floats off-hand, ever |
| 23:03 | <gsnedders> | I always have to look it up, always |
| 23:05 | <jyasskin> | annevk: The ability to write {{record}} was intentional, for use in <code>{{record}}<key, value></code>, but being intentional doesn't make it right. ;) |
| 23:06 | <jyasskin> | annevk: leaving "mappings" unexported was unintentional. |
| 23:07 | <Philip`> | Floats are just like fixed-point numbers but more buoyant |
| 23:19 | <gsnedders> | I like whenever Philip` appears to make useful comments. |
| 23:23 | <aklein> | Domenic, annevk: do you recall what particular concern caused Location to override [[SetPrototypeOf]] in https://github.com/whatwg/html/pull/638? |
| 23:25 | <Domenic> | aklein: location can be accessed cross origin so we don't want you to be able to set another origin's location's __proto__ |
| 23:25 | <gsnedders> | is location still relied upon by some plugins to determine origin? |
| 23:28 | <aklein> | Domenic: ah, this just increases the restriction such that you can't even make that modification on the same origin |
| 23:28 | <aklein> | Domenic: sound right? |
| 23:28 | <aklein> | littledan__: ^^^ |
| 23:29 | <Domenic> | aklein: yeah sounds right, annevk or bholley may be able to confirm more. |
| 23:30 | <bholley> | location properties are hoisted onto the instance and frozen because of the plugin issue |
| 23:30 | <bholley> | the cross-origin issue is orthogonal, I think |
| 23:31 | <aklein> | bholley: do you have a link for this "plugin issue"? |
| 23:31 | <bholley> | aklein: not offhand, but you can grep the mailing lists for when it was discussed |
| 23:32 | <bholley> | aklein: https://lists.w3.org/Archives/Public/public-script-coord/2012JulSep/0144.html |
| 23:33 | <aklein> | ah, this must be what gsnedders was referring to above... |
| 23:34 | <gsnedders> | aklein: yes |
| 23:34 | <aklein> | bholley: that explains why toString and href have to be non-configurable non-writable own properties, but it doesn't explain why the prototype has to be frozen... |
| 23:34 | <aklein> | rather its [[Prototype]] |
| 23:35 | <bholley> | aklein: oh true |
| 23:35 | <bholley> | aklein: it might be the cross-origin thing then. I don't remember |
| 23:36 | <Domenic> | Where's that cross origin objects repo with all the history hete |
| 23:36 | <Domenic> | https://github.com/annevk/html-cross-origin-objects/blob/master/lore.txt |
| 23:39 | <aklein> | it totally makes sense that for a _cross-origin_ access [[SetPrototypeOf]] throws |
| 23:40 | <aklein> | but it seems that HTML just specifies Location in such a way that [[SetPrototypeOf]] always fails, even from the same origin |
| 23:49 | <bholley> | aklein: it may be a holdover from how things were done previously, or there may be a reason i'm not remembering - would require some careful considering if there were a reason to change it |
| 23:50 | <bholley> | aklein: note that window has a frozen prototype for other reasons |
| 23:50 | <bholley> | aklein: I don't have the cycles to page it all in right now though :-( |