| 08:19 | <botie> | mkwst, at 2018-11-08 06:08 UTC, MikeSmith said: the Origin Policy bug, added comment at https://bugs.chromium.org/p/chromium/issues/detail?id=901477#c14 with NetLog dump attached |
| 09:03 | <mkwst> | MikeSmith: Thanks for that. It was quite helpful in debugging the issue. There's a patch out to address the problem, just waiting on a review. |
| 09:11 | <annevk> | Anyone around that can quickly review https://github.com/whatwg/fetch/pull/828? It's very short |
| 09:23 | <annevk> | MikeSmith: ta! |
| 09:27 | <MikeSmith> | annevk: cheers |
| 16:13 | <fserb> | annevk: but that was the whole point, no? |
| 16:14 | <fserb> | annevk: I was trying to lay out all the IDL changes, to see if people would have a problem with that. |
| 16:15 | <fserb> | of course, I'm assuming that the non IDL changes are relatively obvious, given the IDL changes. |
| 16:15 | <annevk> | fserb: how is anyone supposed to implement from an IDL sketch what Chrome would end up shipping? |
| 16:15 | <fserb> | they are not. |
| 16:16 | <fserb> | we are doing the spec work anyway |
| 16:16 | <fserb> | but if they agree with the IDL changes |
| 16:16 | <fserb> | we can move forward with the spec work |
| 16:16 | <fserb> | it's more of an OK to the roadmap |
| 16:16 | <annevk> | fserb: it sounded like you wanted to ship if they agree to IDL changes, which isn't really something I'm familiar with |
| 16:17 | <annevk> | fserb: at least per WHATWG process it's agreement on a concrete a change |
| 16:17 | <fserb> | what do you meant by that? |
| 16:17 | <annevk> | fserb: https://whatwg.org/working-mode#changes |
| 16:18 | <fserb> | I don't see how what I said goes against what's there. |
| 16:19 | <fserb> | I putting forward a proposed IDL, followed by a bunch of actual spec changes with tests and implementation bugs. |
| 16:19 | <fserb> | it doesn't say anything about shipping does it? |
| 16:20 | <fserb> | like |
| 16:20 | <fserb> | maybe I'm missing something |
| 16:20 | <annevk> | fserb: so some time ago you wrote here "Could you help me get some feedback from other browsers? It would unblock the intent to ship on Chrome." |
| 16:21 | <fserb> | yes. |
| 16:21 | <annevk> | fserb: perhaps I misunderstood and you elided a bunch of steps in between |
| 16:21 | <fserb> | well, I won't stop doing the spec changes. |
| 16:21 | <annevk> | fserb: but that came across as if the spec changes wouldn't be done first |
| 16:22 | <fserb> | ahn |
| 16:22 | <fserb> | gotcha |
| 16:22 | <fserb> | so you are saying that you don't want chrome to ship before all the spec changes are landed, is that it? |
| 16:22 | <fserb> | but is that a thing? |
| 16:22 | <annevk> | fserb: I think normally it's much more concrete what will ship, yes |
| 16:22 | <fserb> | I mean, if the chrome API owners are comfortable with the public support around something, why wouldn't that be enough? |
| 16:22 | <fserb> | I mean |
| 16:22 | <annevk> | fserb: and we try to make that even better over time |
| 16:23 | <fserb> | if the spec work is considered trivial; |
| 16:23 | <fserb> | I see |
| 16:23 | <fserb> | "more concrete" than the IDL changes. |
| 16:23 | <fserb> | hmmmmm |
| 16:23 | <fserb> | okey |
| 16:23 | <annevk> | Yeah, this needs an actual processing model, how the various numbers end up allocated in different color spaces, etc. |
| 16:23 | <fserb> | I was under the impression that, for this particular change, if we agree on the IDL changes, the rest is relatively trivial - in the sense that is more "spec work" than actual changing the meaning of something. |
| 16:24 | <fserb> | (we are not doing color spaces here, btw) |
| 16:24 | <fserb> | (is JUST higher precision backing storages) |
| 16:24 | <fserb> | but if that's not the case, then I agree with you |
| 16:25 | annevk | looks again |
| 16:25 | <annevk> | fserb: wide gamut isn't different colors? |
| 16:26 | <fserb> | kinda, but not really. What we want to spec out is: you can create a backing storage with float16, in which case you are by default in extended SRGB color space. |
| 16:27 | <fserb> | Which means: from 0-1.0 behaves exactly like the current SRGB. |
| 16:27 | <fserb> | and outside that, well, it behaves like extended SRGB. |
| 16:27 | <fserb> | so it does have a different color space |
| 16:27 | <fserb> | but it's just a natural extension of the current one. |
| 16:28 | <fserb> | eventually we will work on a second step for this, which would be actual color space selection (P3, etc..). But the problem is: the color space selection thing is much more controversial. |
| 16:28 | <annevk> | fserb: but ImageData would presumably have a different layout? |
| 16:28 | <annevk> | fserb: and you'd have to define what happens if you putImageData from a different layout onto this backing and such |
| 16:29 | <fserb> | what do you mean by layout? |
| 16:29 | <annevk> | fserb: I'd also think we want to extend the ImageData constructor and not createImageData() |
| 16:29 | <annevk> | fserb: u8 vs u16? |
| 16:29 | <annevk> | f16 |
| 16:29 | <fserb> | but we did extend the constructor, no? |
| 16:29 | <fserb> | we did both. |
| 16:30 | <annevk> | sorry, yes, my bad |
| 16:30 | <annevk> | I guess I'm not sure on createImageData(), if we consider that historical at this point |
| 16:30 | <fserb> | I'd be fine with that. |
| 16:31 | <annevk> | fserb: and CanvasPixelFormat has float16 but there's no such primitive in the web platform (other than IDL maybe) |
| 16:31 | <fserb> | yes. |
| 16:31 | <fserb> | I'm up to change that too, if we have a better suggestion on how to surface this. |
| 16:33 | <fserb> | (I'm updating the bug with some of the answers here) |
| 16:36 | <fserb> | (For the ImageData layout, it's sort of what we mean by typedef (Uint8ClampedArray or Uint16Array or Float32Array) ImageDataArray;, right? |
| 16:36 | <annevk> | yeah I had missed that, my bad |
| 16:36 | <annevk> | what's unclear is how the numbers are filled in, but I suppose you can imagine to some extent |
| 16:37 | <fserb> | specially in the non obvious cases (when you ask for something different than the backing storage). yes. |
| 16:37 | <annevk> | I guess if things go beyond 255 that's somewhat clear (if that's how wide gamut works), but it's not clear for transparency for instance |
| 16:44 | <annevk> | fserb: in general what ends up being important for features in terms of web compat is how they behave in edge cases, so that's why when judging features to impl it helps a lot if those are crystal clear; if not you basically have to reverse engineer to compete, which is no fun (a lot of what WHATWG defines is exactly such reverse engineering to allow engines |
| 16:44 | <annevk> | to compete) |
| 16:46 | <fserb> | I can see that. |
| 16:48 | <fserb> | but I feel like the edge cases are easier to change after an initial release (on Chrome side, at least). And moving forward to ship on chrome would mean, in practice, that if we go forward today it goes to stable in 3 months, right? |
| 16:48 | <fserb> | so what I thought was: oh, if we agree on the overall plan, those edge cases I can fix as the come. |
| 16:50 | <fserb> | and the reason I try to go this way |
| 16:50 | <fserb> | is because I thought it would remove pressure from the whatwg reviews |
| 16:50 | <fserb> | but I don't know... if it makes you uncomfortable, it's maybe not worth it |
| 16:53 | <fserb> | that said, even if we don't ship right now on Chrome, I think having an overall tracking bug with the roadmap is useful |
| 17:02 | <Domenic> | I think the question is really whether, *for other canvas implementers*, it's obvious how to implement from the IDL. For annevk and me, it's not so obvious, so it seems like you're underdefining the feature in a way that makes it hard to evaluate. But maybe for people with their head in the canvas realm, it's clear. |
| 17:04 | <annevk> | fserb: yeah, the tracking issue is helpful |
| 17:04 | <annevk> | fserb: in general it seems a bit weird to me how canvas features often appear to be discussed elsewhere already |
| 17:04 | <annevk> | fserb: but maybe that wasn't the case for this |
| 17:07 | <annevk> | Domenic: I'd like to think I know a fair bit about canvas, but maybe not |
| 17:07 | <annevk> | Domenic: in other news, I'm on track towards removing most "(ignoring parameters)" in Fetch, maybe even all, but I really need to leave it for today |
| 17:07 | <Domenic> | Well, maybe not at the color spaces and backing store level, is what I meant? I certainly don't :) |
| 17:07 | <Domenic> | \o/ |
| 17:08 | <annevk> | Domenic: I've been trying to describe the backing store more formally, but left it unfinished as there was some other stuff blocking it |
| 17:08 | <Domenic> | Ah nice OK, I guess just me then |