| 00:15 | <MikeSmith> | a-ja: in browsers? |
| 00:16 | <a-ja> | MikeSmith, in validator |
| 00:21 | <MikeSmith> | dunno but probably less costly than some other things I’m already doing |
| 00:26 | <a-ja> | MikeSmith, fwiw, i've been thinking about a possible change to outline messages...another time, earlier in the day |
| 00:28 | <a-ja> | basically re sectioning elements without headings but with aria labelling |
| 00:30 | <MikeSmith> | ah ok |
| 00:42 | <TabAtkins> | Hm, WebIDL seems to say that I can't put [Exposed] on an interface *and* on that interface's members, but then how am I supposed to say "all the members are exposed per A, but this one in particular is instead exposed per B"? |
| 00:42 | <TabAtkins> | Does this mean I'd have to instead manually add [Exposed] to *every single member*? |
| 00:56 | <TabAtkins> | (Relevance: in Typed OM we want to expose all of our interfaces widely, but restrict the methods that involve CSS parsing to only be available in Window.) |
| 00:57 | <jyasskin> | TabAtkins: I haven't checked this, but can you put the less-exposed ones on a separate partial interface? |
| 01:00 | <TabAtkins> | Hm, both the algorithm and some following requirements imply that a member can have a different exposure set from the interface it's a part of. |
| 01:40 | <TabAtkins> | Yeah, I think this is a WebIDL bug - it contradicts itself in implications. |
| 01:44 | <TabAtkins> | Oh nm, that restriction is solely about members of *partial* interfaces - [Exposed] on a partial is implicitly putting it on all the members. So, not relevant to me, but also doesn't seem necessary. Still filing a bug. |
| 04:14 | <TimothyGu> | TabAtkins: re array methods on Typed OM collections, what's the best case scenario? i.e., what should calling cssNumericArray.map() return? (a CSSNumericArray or just Array? should the type of the value returned from the map() callback be cast to CSSNumericValue?) |
| 04:15 | <TimothyGu> | if returning an Array is okay then [LegacyArrayClass] + indexed getter would work, no? |
| 04:16 | <TabAtkins> | Right now, it throws because undefined is not a function. ^_^ |
| 04:16 | <TabAtkins> | For the rest, I don't have a strong opinion, but JS *does* have support for good Array subclassing now, such that .map() could return your subclass. |
| 04:17 | <TimothyGu> | yeah that's why I said "should" |
| 04:17 | <TabAtkins> | But it's probably fine to just return an Array too, since the subclass doesn't do anything additional, and our inputs are all `sequence<>`. Only downside would be that you couldn't directly assign to the attribute, when present. |
| 04:18 | <TimothyGu> | TabAtkins: hmm, is typed om implemented in any browser? If so I'd like to test something |
| 04:18 | <TabAtkins> | Well, hm, I'm lying. It would be bad if `(new CSSUnparsedValue(["one"])).map(x->x)` returned an Array. |
| 04:19 | <TabAtkins> | It's behind a flag in Blink right now. |
| 04:19 | <TimothyGu> | TabAtkins: yeah it seems like different collections want different semantics for array methods |
| 04:20 | <TabAtkins> | Sometimes maybe. But returning the same class as you started with seems pretty universally good, and supported by JS now. |
| 04:20 | <TabAtkins> | If you really want an Array you can wash it thru `[...foo]`, after all. |
| 04:20 | <TimothyGu> | TabAtkins: how about type casting though? I assume you would want to force the result of map() to whatever element type is in the original collection? |
| 04:21 | <TimothyGu> | TabAtkins: do you know what flag it is in Chrome? |
| 04:21 | <TabAtkins> | Yeah, that would presumably cause an error to be thrown during the implicit construction of the new value. |
| 04:21 | <TimothyGu> | Experimental Web Platform features? |
| 04:21 | <TabAtkins> | Precisely *when* the error is thrown (immediately after the callback returns a bad value, or when the callback is totally done) is an open question which needs to be answered, but whose answer is probably not important. |
| 04:22 | <TabAtkins> | Yeah, that's the flag. |
| 04:22 | <TimothyGu> | Okay, I'm looking into this |
| 04:23 | <TabAtkins> | .push(), etc would also typecheck for you. Basically everything would indirect thru your constructor or your indexed setter, both of which should have the types you want. |
| 04:23 | <TabAtkins> | TimothyGu: I forget what browser you work for. ^_^ |
| 04:24 | <TimothyGu> | TabAtkins: I'm a first-year undergrad |
| 04:24 | <TimothyGu> | lol |
| 04:24 | <TabAtkins> | ah, kk |
| 04:24 | <TimothyGu> | I'll intern at Google this summer though |
| 04:24 | <TimothyGu> | (Chrome) |
| 04:24 | <TabAtkins> | +1 |
| 04:27 | <TimothyGu> | TabAtkins: question: why did y'all decide on rest params for CSSUnparsedValue's constructor instead of a sequence<>? |
| 04:27 | <TimothyGu> | seems kinda odd when basically everything else takes a sequence |
| 04:27 | <TabAtkins> | I think we didn't have any particular reason, but since it's inconsistent with CSSTransformValue we should harmonize those two. |
| 04:28 | <TimothyGu> | TabAtkins: yeah, should I file a ticket or is that a known issue? |
| 04:28 | <TabAtkins> | file issue plz |
| 04:33 | <TimothyGu> | TabAtkins: https://github.com/w3c/css-houdini-drafts/issues/618 |
| 04:34 | <TabAtkins> | danke |
| 04:34 | <TimothyGu> | de nada |
| 05:08 | <annevk> | TabAtkins: interface exposed a,b meber exposed a should work; does for XHR at least |
| 05:09 | <TabAtkins> | Yeah, discovered that it's fine, the paragraph I was confused about only applied to *partial* interfaces. |
| 05:13 | <TabAtkins> | annevk: Do you have some examples of indexed getters/setters on the platform? I need to see what current ones do when you get/set an index that doesn't have an associated value. |
| 05:14 | <annevk> | We don’r use those anymore; they’re to be renamed legacy |
| 05:19 | <TabAtkins> | That's cool and all, but until we actually resolve the array-like issue I'm still using them, and would like to be consistent with the rest of the platform. |
| 05:20 | <TabAtkins> | (Turns out engines all special-case indexed getters/setters and run them much more efficiently than a general proxy would.) |
| 05:20 | <TabAtkins> | (I'd love to make them legacy and get something better, they're so manual and frustrating, when so much of it should be automatic.) |
| 05:24 | <annevk> | You cannot be consistent if you refuse to be so… |
| 05:26 | <TabAtkins> | I can't be consistent with something that's nonexistent, either! |
| 05:26 | <TabAtkins> | Looks like getters all return null, per the DOM spec. None of these have setters. :/ |
| 05:27 | <TabAtkins> | (It's been almost a year since the last time I said "hey, my spec has three array-likes, sure would be good to make IDL support that properly", and nothing's happened since then, so don't try and shame me about this.) |
| 05:29 | <annevk> | Saying it’s somebody else their problem is a little weird |
| 05:30 | <annevk> | And you got ample feedback there too about the platform not doing this |
| 05:30 | <TabAtkins> | No, I got pushback from *you* about this, while Boris supported it. Yay for contradictory advice! |
| 05:31 | <annevk> | Domenic pushed back too |
| 05:31 | <annevk> | TC39 would push back too |
| 05:31 | <TabAtkins> | Sure. I don't think counting 2 vs 1 is reasonable here? |
| 05:32 | <TabAtkins> | Nah, TC39 explicitly supported integer catchalls several years back, and I've gotten feedback that they're just fine perf-wise in engines. |
| 05:32 | <annevk> | Maybe we should bring it up with the TAG? |
| 05:32 | <annevk> | I doubt TC39 did that, pointer? |
| 05:32 | <TabAtkins> | (Nobody ended up *doing* anything about it in TC39, but we still have the records with several people enthusiastically supporting, including several current members.) |
| 05:33 | <TabAtkins> | It was linked in the WebIDL issue, let me go get it. |
| 05:34 | <TabAtkins> | https://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1346.html |
| 05:34 | <TabAtkins> | (follow the thread linked from that message) |
| 05:35 | <annevk> | The outcome of that discussion was to stop doing live lists |
| 05:35 | <TabAtkins> | Yes? That's correct and a good conclusion. |
| 05:35 | <TabAtkins> | As I've said multiple times, I'm not doing live lists. |
| 05:36 | <annevk> | So why not return arrays then? |
| 05:37 | <TabAtkins> | :deep breath: I'm repeating myself, but: because they're not arrays. They're other objects with branding concerns, which have restrictions on what types of objects they contain, and sometimes have useful methods hanging off of them that are only reasonable for their specific type. |
| 05:38 | <annevk> | Anyway, I think to be more productive I should study what you are trying to do in more detail. It’s been a while. |
| 05:38 | <TabAtkins> | Luckily for you, I just posted an update about that: https://github.com/heycam/webidl/issues/345#issuecomment-361814861 |
| 05:38 | <annevk> | It seems you could enforce validation when setting though. That’s how everything else works. |
| 05:39 | <annevk> | Cool, I’ll check it out later today |
| 05:39 | <TabAtkins> | No (a) I can't do that easily (it would be both more expensive *and* would delay catching errors for no author benefit), and (b) that's *not* how everything else works, every single other thing in WebIDL typechecks eagerly as soon as you set a value. |
| 05:40 | <TabAtkins> | foo.bar = "something invalid" throws immediately; foo[1] = "something invalid" should too. |
| 05:41 | <TabAtkins> | foo("something invalid") throws immediately, but if the brand check succeeds we generally depend on the object being correct, and don't do recursive type-checking by hand. (I'd be interested if you could find an instance of such manual recursive type-checking.) |
| 05:42 | <annevk> | Eg Headers constructor |
| 05:43 | <TabAtkins> | That's in Fetch? |
| 05:43 | <annevk> | Yes |
| 05:47 | <TabAtkins> | Ah, that's not an example of such. (a) it's not recursive, it just checks *one* layer down in the passed sequence, and (b) it's just papering over a deficiency in WebIDL that prevents you from explicitly saying that you take a `map-sequence<ByteString, ByteString>`, so you're having to manually roll that check; all it does it verify that each item has precisely two entries. (Besides the length-checking, the actual |
| 05:47 | <TabAtkins> | type-checking is still done automatically for you by IDL.) |
| 05:48 | <TabAtkins> | (And that's captured in https://github.com/heycam/webidl/issues/324 too; there are questions about what to do with map-sequence<> as a return type, but as an argument type it's nice and simple.) |
| 06:55 | <annevk> | MikeSmith: are you logging URLs too? |
| 07:08 | <TabAtkins> | tobie: Yo, would you take a PR for `pair-sequence<>`? Looking at `sequence<>`, it looks pretty easy to spec. |
| 07:12 | <tobie> | TabAtkins: I didn’t read up on the thread, but if there’s consensus and implementor interest, sure. |
| 07:14 | <TabAtkins> | I'll write it up and we'll see. I think there's only one consumer at the moment - `Headers` - because the only maplike I'm in charge of isn't currently constructable. |
| 07:15 | <TabAtkins> | Hm, about that: Domenic, annevk, we generally want *all* objects to be constructable, right? I've got nothing against making StylePropertyMap constructable, you just can't *do* anything with manually constructed instances (all attributes of that type are `readonly`). |
| 07:17 | <annevk> | TabAtkins: https://github.com/w3ctag/design-principles/issues/44 |
| 07:17 | <annevk> | TabAtkins: so generally yes, with some exceptions |
| 07:18 | <annevk> | TabAtkins: if it's not useful I wouldn't add a constructor |
| 07:18 | <TabAtkins> | Hm, that's for using constructors vs factory methods. |
| 07:18 | <TabAtkins> | kk |
| 11:42 | <lgrahl> | Hey everyone! I've seen ricea's comment on data channel streams (https://github.com/w3c/webrtc-pc/issues/1732#issuecomment-361843997) and was wondering how passing a readable stream to the send method would look like if I were to write in chunks... do you have an example for that? |
| 11:43 | <lgrahl> | Basically, my question is how the examples (https://github.com/w3c/webrtc-pc/issues/1732#issuecomment-357442429) would have to be rewritten for providing a readable stream on a send call. |
| 12:07 | <annevk> | lgrahl: if you construct your own RS you can push stuff in that the data channel would then read |
| 12:07 | <annevk> | lgrahl: that is how upload fetch() works, but not yet implemented |
| 12:08 | <lgrahl> | annevk: I'd be interested in how that would look like if I don't have a readable stream beforehand (so, I need to construct one of my own) |
| 12:08 | <annevk> | lgrahl: it does not use WS since ideal WS usage requires the underlying buffer, which would require a callback of sorts and was not feasible impl wise |
| 12:11 | <lgrahl> | annevk: Okay... but that means constructing a writable stream on RTCDataChannel and writing into that is theoretically more effizient with BYOB (once we have that for writable stream)? |
| 12:11 | <lgrahl> | jeez, that German thrown into there... *efficient :) |
| 12:11 | <annevk> | lgrahl: could not find a quick example, but https://streams.spec.whatwg.org/#rs-constructor has a description |
| 12:12 | <annevk> | lgrahl: if the impl could give you access to the networking layer’s buffer, yes, but not sure how feasible that is given framing and such |
| 12:13 | <annevk> | lgrahl: I suspect some piping will be necessary |
| 12:14 | <annevk> | Fetch should probably have an example for this |
| 12:14 | <lgrahl> | annevk: I worked on the FF data channel implementation and yeah that should be possible if I'm not mistaken. So, would you rather say we should go for .createWritableStream instead of .send(myReadableStream)? |
| 12:15 | <annevk> | lgrahl: or make send() return it; is synchronous acceptable though? |
| 12:16 | <lgrahl> | It's only sync so far. |
| 12:16 | <annevk> | lgrahl: I mean getting sync access to the buffer |
| 12:17 | <lgrahl> | I'm not sure what you mean by that |
| 12:18 | <Ms2ger> | Argh |
| 12:19 | <annevk> | lgrahl: I’m prolly mistaken and it’s not an issue |
| 12:19 | <lgrahl> | Returning a writable stream on .send() would be an idea but I'm not a fan of it because I think it creates an awkward API. Also, .send would have to know when it should return a writable stream. |
| 12:20 | <annevk> | Ms2ger: wb |
| 12:21 | <annevk> | lgrahl: it does seem a little weird if this can get away with using WS, but not fetch() |
| 12:21 | <annevk> | lgrahl: curious what ricea and yhirano__ think |
| 12:22 | <annevk> | lgrahl: fair re send(); be good to keep the name relatively short though |
| 12:23 | <lgrahl> | Ideas welcome :) |
| 12:23 | <Ms2ger> | annevk, I'd actually written some more tests for that createImageBitmap PR you reviewed, but I forgot to commit |
| 12:23 | <Ms2ger> | Boo, git |
| 12:24 | <annevk> | Ms2ger: happy to review |
| 12:24 | <Ms2ger> | Coming up in a minute |
| 12:24 | <annevk> | Ms2ger: was planning on writing more too for that PR |
| 12:24 | <annevk> | Ms2ger: now I figured out Blob is similar to <img> |
| 12:25 | <Ms2ger> | I'll try to find time to do a closer review, but not sure I'll be able to |
| 12:25 | <lgrahl> | aneevk: My current idea was to just throw buffers into the WS (which are then consumed) and hope you come up with a good idea for BYOB writer. Wouldn't that work for fetch too? |
| 12:26 | <Ms2ger> | Probably some of these tests should run in workers too |
| 12:27 | <annevk> | lgrahl: then it’s not better than RS iirc, but really need the others for that discussion |
| 12:27 | <annevk> | Ms2ger: hopefully junov can help with that |
| 12:32 | <lgrahl_> | Freenode is flaky for me... |
| 12:32 | <lgrahl_> | annevk: It's not better but it would allow us to switch later without breaking API. But yeah, it's a good idea if you discuss this together. Ping me if you need me. |
| 12:36 | <annevk> | lgrahl_: I'm hoping ricea will just chime in, I'm not super invested in this |
| 12:37 | <annevk> | lgrahl_: I'm reading through https://github.com/yutakahirano/fetch-with-streams/issues/30 though to figure out why fetch() uses RS again (a lot of the stuff in the beginning isn't it I think) |
| 12:39 | <lgrahl_> | annevk: Okay. I'll grab lunch in the meantime. :) |
| 12:44 | <annevk> | lgrahl_: good plan; https://github.com/yutakahirano/fetch-with-streams/issues/30#issuecomment-95161858 seems like the conclusion |
| 12:45 | <annevk> | lgrahl_: basically even with WS there's no guarantee you get the actual final buffer/sink for fetch() |
| 12:45 | <annevk> | lgrahl_: and additionally for fetch() WS became awkward due to how Request works |
| 13:07 | <Ms2ger> | annevk, is a video with data URL src cross-origin? |
| 13:21 | <lgrahl_> | annevk: Cheers. I don't understand these points entirely (lack of spec knowledge I guess) and so I'm not sure this would apply to data channels, too. |
| 13:23 | <lgrahl_> | annevk: It really confuses me that readable streams are used by both ends. so I'm surprised by this (at least in terms of terminology). |
| 13:29 | <lgrahl> | annevk: Also, if I come back to the low-level use, creating a writer from a WS and passing chunks into it is easy. But constructing a RS and feeding chunks into it seems tedious because you need to write your own RS object (unless I missed something). |
| 13:33 | <Ms2ger> | Test works and passes right away... What'd I do wrong? :) |
| 13:37 | <annevk> | Hmm, lgrahl disappeared |
| 13:37 | <annevk> | Ms2ger: it shouldn't be |
| 13:37 | <annevk> | Ms2ger: (re data: URL) |
| 13:37 | <annevk> | Ms2ger: data: URLs are only an opaque origin (cross-origin) when they instantiate a realm |
| 13:38 | <Ms2ger> | Okay, thanks |
| 13:40 | <Ms2ger> | This is getting a little annoying... Every test I try to write just passes in Chrome :) |
| 13:41 | <annevk> | Ms2ger: have you done zero-width/height SVG inside a Blob yet? |
| 13:41 | <Ms2ger> | No |
| 13:42 | <annevk> | Although I'm not sure Chrome would fail that |
| 13:43 | <annevk> | Ms2ger: can you help out with https://github.com/w3c/web-platform-tests/pull/9194 btw? |
| 13:43 | <Ms2ger> | Yeah |
| 13:43 | <Ms2ger> | Not just now, though :) |
| 13:45 | <lgrahl> | annevk: Jeez, was I gone again? :X |
| 13:47 | <lgrahl> | Changed some settings and hope Freenode is less flaky now... |
| 13:48 | <annevk> | lgrahl: you mean new RS(impl) is tedious? I guess it's a little more work than the equivalent writer |
| 13:49 | <annevk> | lgrahl: I think the main question is when you invoke write() can you ensure that writes to the outgoing buffer that the data channel uses or do you need to consume it somehow first before passing it on |
| 13:49 | <annevk> | lgrahl: but again, best to ask in the issue thread from ricea et al |
| 13:50 | <annevk> | lgrahl: it's a bit unfortunate the issue is getting sidetracked so much; seems everyone has to learn anew that it's about a single message (me included) |
| 13:57 | <Domenic> | TabAtkins: I find it a bit frustrating that whenever we ask you to do something moderately complicated in your API design, such as keeping consistency with other multimaps, or using arrays instead of proxies, or accepting a pair-sequence, you try to push back and say this really is Web IDL's job to figure out for you. Yes, maybe in an ideal world Web IDL would do more, but we're not there yet, so in the meantime it |
| 13:57 | <Domenic> | would be good if you were able to accept advice without saying it's not your problem. |
| 13:58 | <TabAtkins> | (1) Your multimaps already aren't consistent with each other, or with Maps. That's somewhat of a problem, and in the issue about it I've been exploring the space a bit and figuring out what the consistent subset we actually need to work with is. Surprise, different things are sometimes different; trivial consistency is the hobgoblin, etc. |
| 13:59 | <Domenic> | annevk: lgrahl: using writable stream for sending data is ideal; Fetch not doing that is really unfortunate stemming from some early design choices about the lifecycle of Request/Response objects. But I think Till from Mozilla is still interested in changing that if possible, even if just by adding writable stream sugar to save people the all-too-common pattern of creating an identity transform stream, piping to its |
| 13:59 | <Domenic> | writable end, and sending the readable end to fetch |
| 14:00 | <annevk> | Domenic: I thought there were also some concerns around being actually able to have the highest performance solution rather than something that has to pipe? |
| 14:00 | <Domenic> | annevk: yeah those are Till's concerns, writable streams are more easily performant because piping can hide all the implementation details |
| 14:00 | <TabAtkins> | (2) "Arrays instead of proxies" has been a bugaboo for years; we just super disagree about some fundamental aspects here, and I'm not willing to give up on it. "Just use arrays" means accepting a pretty major inconsistency with every other aspect of WebIDL-mediated APIs, and results in a noticeably worse/awkwarder authoring experience. Finally, the "use arrays, not proxies" position that you and Anne present is |
| 14:00 | <TabAtkins> | *not* universal; see my frustration in the relevant WebIDL thread when I'm trying to work around y'all's issues and Boris is like "lol, just use the proxy thing, that's why it's there, dunno what their problem is". |
| 14:01 | <annevk> | Domenic: that's not what I was trying to say 😃 |
| 14:01 | <annevk> | Domenic: I thought the problem was that implementations could not expose the actual underlying buffer to WS |
| 14:01 | <annevk> | Domenic: but also, none of this has shipped, so maybe we should revisit |
| 14:02 | <annevk> | Domenic: I think it can still fit with Request/Response if body is a callback |
| 14:02 | <Domenic> | annevk: Ah right about accurate desiredSize, yeah, that may not be perfectly possible, but it's already not possible with the pass-a-ReadableStream design |
| 14:02 | <lgrahl> | Sorry guys, I'm getting disconnected all the time but I check the logs, so just ignore this is happening. |
| 14:02 | <lgrahl> | annevk: Yeah, I think new RS is a bit tedious... also when it comes to terminology because both sides use readers now. pipeTo isn't used... all of this seems awkward to me. |
| 14:02 | <lgrahl> | annevk: My understanding is that if I don't use BYOB mode, then I always hand out buffers I cannot reclaim (thus, they are implicitly consumed). So, if I create a non-byob reader for a data channel message, then the implementation hands out buffers that it cannot reclaim. On the other side, if I use a normal writer, I cannot reclaim buffers handed out by calls to .write. Correct me if I'm wrong. |
| 14:02 | <lgrahl> | annevk: Yes, people ask the same question over and over again in the issue... ;) |
| 14:02 | <TabAtkins> | (3) Dunno what you're talking about with the pair-sequence thing. I'm saying that pair sequences are currently very awkward to write *and* read in WebIDL, and it'd be better to have it be a named concept. I then today offered to *write the WebIDL text for such a feature*. The more map-likes that appear on the platform the more valuable this will be; spec authors will work around it (or get things subtly different, |
| 14:02 | <TabAtkins> | because it's awkward) otherwise. |
| 14:02 | <annevk> | Domenic: no, I'm also not talking about Content-Length |
| 14:03 | <Domenic> | annevk: well that's the only way I can see WritableStreams exposing the buffer |
| 14:03 | <Domenic> | TabAtkins: I've given up long ago on convincing you, especially on these issues, but I'm hopeful you'll notice this pattern in your behavior for the future. |
| 14:04 | <Domenic> | And who knows, maybe the TAG will save us from these APIs |
| 14:04 | <TabAtkins> | So seriously, pretending that I'm pushing back or complaining "whenever we ask you to do something moderately complicated" is an incorrect and frankly insulting characterization of this; look at all the other complicated API surface I've happily written and accepted elsewhere. |
| 14:07 | <Ms2ger> | Hmm |
| 14:07 | <annevk> | Domenic: I had this notion in my head that doing WS properly was too hard and UAs would have to pipe/consume anyway and couldn't get the developer-provided bytes/memory close enough to the metal |
| 14:08 | <Ms2ger> | If I call createImageBitmap with video whose src is a cross-origin URL which redirects to a same-origin URL, is the result origin-clean? |
| 14:08 | <annevk> | Domenic: but maybe the only issue is Request being too early and a callback being a little awkward |
| 14:08 | <annevk> | Ms2ger: it should not be |
| 14:09 | <Domenic> | annevk: it's been a while but the latter is all I remember. You might be right. I'd be interested to get Till and wanderview in a room :) |
| 14:09 | <Domenic> | room-slash-GitHub-thread |
| 14:09 | <Ms2ger> | I'll let you file another bug on Gecko, then :) |
| 14:09 | <annevk> | Ms2ger: hmm, maybe this is an enshrined side channel leak |
| 14:10 | <annevk> | Ms2ger: it probably is as if you did this via <iframe> it'd just work, unfortunately |
| 14:10 | <Ms2ger> | I would really prefer if it's origin-unclean, because I have no idea how to do the other thing in WebKit :) |
| 14:11 | <annevk> | Ms2ger: it would be better, but if it's not consistently so I don't think it's better |
| 14:11 | <annevk> | Ms2ger: and I kinda doubt it's consistently so |
| 14:11 | <annevk> | This might be a bug in Fetch too, not sure if I tried addressing it yet |
| 14:14 | <wanderview> | Domenic: annevk: I feel like I put all my reasons for wanting ReadableStream in the github issue before... if there is a new proposal to add some WritableStream approach for populating a body, then I'd be happy to look at it... but an abstract "replace ReadableStream with WritableStream" doesn't make sense to me |
| 14:15 | <annevk> | TabAtkins: I think the main problem I have with your argument is that Boris disagreeing with TC39 doesn't mean it's okay. If you convinced TC39 (as a whole), fine, but otherwise I'm really not sure why we'd revisit this |
| 14:15 | <wanderview> | Domenic: annevk: I still feel anything added here would end up being the equivalent of ReadableStream + an IdentityTransformStream in the implementation... and its better to let script choose the size of the buffer in the IdentityTransformStream |
| 14:17 | <annevk> | Domenic: https://github.com/yutakahirano/fetch-with-streams/issues/30#issuecomment-95161858 suggest it did have something to do with the actual sink being hard to get to |
| 14:17 | <TabAtkins> | annevk: And as I said earlier (and linked you to, and said last year when I last visited this issue...) TC39 *is* okay with this, or at least was okay with it several years back. In the meantime, the primary argument against ("proxies are slow") turns out to be irrelevant, as Boris explained, because all engines optimize integer catch-alls, due to there being several common APIs that use them. |
| 14:17 | <annevk> | wanderview: does https://github.com/yutakahirano/fetch-with-streams/issues/30#issuecomment-95161858 accurately summarize your view? |
| 14:18 | <annevk> | wanderview: I'm wondering whether or not it translates to WebRTC data channels |
| 14:18 | <TabAtkins> | This is what keeps annoying the heck out of me - y'all keep trying to shut it down with "you can't do it, it's slow, TC39 won't allow it", and, uh, both of those are wrong. And I've explained why they're wrong and documented it and gotten other Web Elders with relevant experience to agree. |
| 14:18 | <Ms2ger> | annevk, https://github.com/w3c/web-platform-tests/pull/9313 should be uncontroversial; https://github.com/w3c/web-platform-tests/pull/9314 is for the last thing I mentioned, but no hurry to review it for me |
| 14:18 | <Domenic> | TabAtkins: that linked thread *definitely* does not reflect "TC39 is OK with this". At most, it contains Brendan saying "we should keep working on this". TC39 as a whole detests new exotic objects. |
| 14:18 | <wanderview> | annevk: the issue is that Request is something that is disconnected from the data sink... if the WebRTC data channel thing does not use a Request then it doesn't have that problem IMO |
| 14:19 | <TabAtkins> | Brendan, Mark, Maciej, Jonas... |
| 14:19 | <Domenic> | It also predates ES6 being finalized and our modern understanding of exotic objects. |
| 14:19 | <Domenic> | Only one of which is on TC39 these days |
| 14:19 | <wanderview> | annevk: I still prefer ReadableStream stylistically as it gives you better default back pressure... but I don't think thats a blocker |
| 14:20 | <annevk> | TabAtkins: I don't think that 2009 thread accurately reflects TC39's view on this |
| 14:20 | <annevk> | TabAtkins: in particular catchalls happened and array-likes never did |
| 14:21 | <annevk> | TabAtkins: and their Map/Set didn't end up with indexed getters/setters either, even though they are ordered and could |
| 14:22 | <annevk> | TabAtkins: so I think that if you want to push this through, you have to do more due diligence; e.g., make a proposal to TC39, get it progressed |
| 14:22 | <Domenic> | +1 |
| 14:23 | <TabAtkins> | The more general solution that solves more problems ended up getting specced, that's not a huge surprise. ^_^ And with that, catch-alls *do* exist, and engines happen to much better-optimize catchalls limited to integer-key gets/sets, so the slower version of what I'm asking for is already possible in userland, and the faster version is possible and already-existing in browserland. |
| 14:23 | <annevk> | wanderview: right, but if body were to take a callback that we invoked the moment we hook up the sink, that would work, right? |
| 14:24 | <Domenic> | The problem with proxies isn't just that they're slow, it's that they're exotic. |
| 14:24 | <TabAtkins> | (I dunno why one would assume that getting a map/set by index is relevant here. They're ordered, but as a side detail. Getting map/set values by index isn't a common feature in any major language.) |
| 14:24 | <annevk> | TabAtkins: possible yes, but Proxy-style APIs are discouraged |
| 14:24 | <Domenic> | Using normal arrays is the non-exotic pattern that we use for all TC39 APIs |
| 14:24 | <wanderview> | annevk: could we add it as an additional thing? sure... should we remove the straightforward "provide a ReadableStream body" approach with that? I don't think so |
| 14:25 | <wanderview> | annevk: I think its very complicated and quite frankly does not reflect what we do in the browser at all |
| 14:25 | <Domenic> | wanderview: I think that myself and Till believe that the current API will not be "straightforward" in the future when everyone's using transform streams and piping things around |
| 14:26 | <TabAtkins> | (it's 1:30am here and we're continuing to relay the exact same points that were made last year without any further reflection or budging, so i'm gonna go to bed) |
| 14:26 | <wanderview> | Domenic: I guess I'm curious to hear what Till's concern is... AFAIK he defered to someone else to integrate this into the network and DOM layers, so I'm not sure exactly what aspect he is concerned about |
| 14:27 | <Domenic> | wanderview: yeah definitely, I'd love to hear your two's conversation. It might be more ergonomics and disconnected from the actual networking, not sure. |
| 14:27 | <annevk> | wanderview: I also heard out-of-band he'd like to have WS here |
| 14:28 | <annevk> | Maybe we should just set up a call |
| 14:28 | <wanderview> | annevk: I'd be interested to know if he has actually looked at what that would take to implement in our stack... I have I don't think it would be any different than ReadableStream+Transform... just less control for script |
| 14:29 | <Domenic> | Why less control? You can always introduce your own intermediate buffers |
| 14:29 | <wanderview> | Domenic: annevk: internally we use an nsIInputStream which is our native equivalent of a ReadableStream... for probably the last decade |
| 14:30 | <wanderview> | Domenic: because you can't control the buffer size the browser inevitably has to introduce to convert from your WritableStream to its internal mechanism |
| 14:30 | <Domenic> | wanderview: if the browser uses 0, then you can control it |
| 14:30 | <wanderview> | Domenic: the idea that content script is going to use a WritableStream to feed directly into the operating system buffer is just not realistic in a multi-process browser architecture, IMO |
| 14:32 | <annevk> | So that would be true for data channels too, I think, although lgrahl thinks otherwise (and probably knows) |
| 14:32 | <wanderview> | annevk: Domenic: anyway, if we want a WritableStream as a second way to feed the Request.body, I'm ok with that but not sure we would implement in firefox... I feel pretty strongly Request.body should be able to take a ReadableStream as we've agreed in the past |
| 14:32 | <Domenic> | :-/ |
| 14:32 | <wanderview> | annevk: webrtc is very different, implementation-wise |
| 14:32 | <annevk> | I see |
| 14:33 | <wanderview> | Domenic: annevk: how do you propose to handle the upload cloaning issue with a WritableStream body? |
| 14:33 | <wanderview> | as in, a POST request is redirected and has to provide the body a second time |
| 14:36 | <annevk> | wanderview: don't we reject for streams anyway? |
| 14:36 | <annevk> | wanderview: I thought opting into streams meant opting out of redirects, unless it was a 303 |
| 14:36 | <wanderview> | annevk: well, we haven't even shipped streams yet... but yes, we don't support Request streams right now |
| 14:36 | <wanderview> | annevk: oh, you mean in the spec? I wasn't aware of that restriction |
| 14:36 | <annevk> | wanderview: yes, per Fetch |
| 14:37 | <annevk> | wanderview: otherwise you'd have to buffer the entire thing, taking away all the memory optimizations |
| 14:37 | <Domenic> | It seems we actually could support it with the writable stream version, as you'd just call the body function a second time |
| 14:37 | <annevk> | Domenic: you just created a minor security hole |
| 14:38 | <Domenic> | drrr |
| 14:38 | <wanderview> | I don't know why we can ship ReadableStream body first before trying to eek that last 1% of optimizations out with a complicated WritableStream API |
| 14:38 | <wanderview> | ^can^can't |
| 14:38 | <annevk> | I'm not opposed to shipping RS FWIW |
| 14:38 | <Domenic> | (aside: the fact that arr[-0] and arr["-0"] are different really freaks me out. I did not know that before today.) |
| 14:39 | <annevk> | I was just interested again in the rationale around WS |
| 14:39 | <annevk> | Domenic: same |
| 14:39 | <annevk> | Domenic: since yesterday or so I've been worried about being unclear about -0/+0 throughout the platform |
| 14:40 | <annevk> | Domenic: it helps somewhat that unsigned in IDL means it's normalized, but still, there's a lot of signed things |
| 14:40 | <Ms2ger> | No need to worry about that... We most definitely are unclear about it everywhere :) |
| 14:40 | <annevk> | Ms2ger: so you're saying we're consistent? I do like consistency |
| 14:41 | <Ms2ger> | The signed integers shouldn't have negative zero at all, but who knows if that's actually written down |
| 14:41 | <annevk> | Part of the problem is that we haven't really agreed on what a number in a specification means |
| 14:41 | <annevk> | But BigNum might solve that, so I'm excited for BigNum |
| 14:43 | <Domenic> | Hmm so far the internet is coming out quite strong in favor of getting the answer right https://twitter.com/domenic/status/958711529070710785 |
| 14:44 | <lgrahl> | Btw. I don't get the argument of buffer size control. Isn't that what .desiredSize on WS is good for? |
| 14:46 | <wanderview> | lgrahl: can you set desiredSize on a WS you did not create? |
| 14:46 | <annevk> | Domenic: r+ for https://github.com/w3c/web-platform-tests/pull/9306? |
| 14:47 | <lgrahl> | wanderview: No but in the proposed API, RTCDataChannel creates the WS for me and it knows how much buffer space there is. The user can still decide to ignore it. |
| 14:48 | <wanderview> | lgrahl: ok, but a user could control the buffer space if they created a Transform... if they wanted to size it exactly for their chunks, etc |
| 14:49 | <wanderview> | lgrahl: anyway, I don't have any opinions on webrtc API use of ReadableStream vs WritableStream |
| 14:50 | <lgrahl> | wanderview: I haven't really looked at transforms yet. You mean in case the user *requires* a specific chunk size for some transformation? |
| 14:50 | <wanderview> | other than I think default back pressure mechanism is nicer with ReadableStream and lots of examples in node.js with people getting back pressure wrong with push-style streams... but I won't fight that issue |
| 14:51 | <wanderview> | lgrahl: when I say a Transform I mean a buffer that exposes a WritableStream end to fill the buffer and a ReadableStream end to read from the buffer... so if an API only takes ReadableStream, but you want to use a WritableStream for some reason, you can use this thing to convert... it would just let you control the size of the buffering taking palce |
| 14:53 | <lgrahl> | wanderview: Alright, transforming from WS to RS. |
| 14:54 | <lgrahl> | wanderview: You guys are the experts but from the outside, it just looks really weird to have WS and then use RS for pretty much everything. |
| 14:54 | <wanderview> | lgrahl: I usually call it a "pipe", but folks in streams spec like to call it an "identity transform" |
| 14:56 | <lgrahl> | wanderview: What annevk and I wanted to find out is whether there's a reason why we shouldn't go for WS for RTCDataChannel. To me, it originally looked like the way to go. |
| 14:57 | <wanderview> | lgrahl: I mean, the other reason to go with ReadableStream is you will get adoption faster since more browsers will ship ReadableStream before they ship WritableStream |
| 14:58 | <wanderview> | lgrahl: but like I said, I'm not really involved with webrtc, so I'm not going to fight you all using WritableStream |
| 14:58 | <wanderview> | maybe it will work great and it will be the use case used to encourage more WritableStream usage elsewhere |
| 15:00 | <annevk> | wanderview: note that https://github.com/whatwg/encoding/pull/127 uses WS too |
| 15:01 | <wanderview> | annevk: yea, I think transformation things like that make the most sense for WS... wfm |
| 15:02 | <lgrahl> | wanderview: Other than a little API clumsiness (.send(RS) just looks nicer than .createWritableStream()), I haven't seen anything that would be a big blocker to use WS in data channels. But to be honest, I haven't understood all of your points in the issue and stuff like easier backpressure support in RS because I'm just not that deep into the streams spec. |
| 15:04 | <wanderview> | lgrahl: well, with a pull-style stream like ReadableStream you get automatic back pressure... if the consumer isn't ready for more data they just stop reading |
| 15:05 | <wanderview> | lgrahl: with a push-style stream like WritableStream the source has to understand the signal that says "please stop sending data right now" and back off... its not super hard to implement, but historically its something that people get wrong... and they end up queuing a bunch of data in temporaries and stuff |
| 15:06 | <lgrahl> | wanderview: Okay, I get that. |
| 15:11 | <lgrahl> | wanderview: I mean, it's a tradeoff, right? And I personally believe it's not too much to ask for the sink implementation to get this right to provide a (at least to me) more appealing way to write data to it. But still, you're the experts regarding streams, so if there are other concerns... let me know. I don't want to create an API that sucks in the end. :) |
| 15:15 | <wanderview> | lgrahl: using an API that takes ReadableStream allows the sink to get it write... exposing a WritableStream is asking the person pushing the data to get it right... AFAICT anyway |
| 15:33 | <lgrahl> | wanderview: I'm not really sure what the user of a WS writer can get wrong. Granted, when using a WS the user cannot reclaim the buffer (at least not until we have BYOB writers), so this *is* a gotcha. But IIRC you already have a way to claim a buffer somehow, so this could maybe be used? |
| 15:43 | <annevk> | lgrahl: looking at some examples it seems rather trivial to ignore backpressure |
| 15:47 | <wanderview> | of course ReadableStream is not immune either if you have to adapt a push source you don't control into a ReadableStream... but you are kind of out of luck there |
| 17:43 | <Domenic> | surma: FYI I'll work on the separate-section thing myself since it ties into clarifying some stuff that came up while chatting with lgrahl. |
| 17:44 | <Domenic> | Would be happy to get your review though :) |
| 17:49 | <surma> | Domenic: sg! Happy to review :D |
| 18:26 | <Mek> | blah, trying to figure out what cross-origin requests to blob URLs browsers actually allow... firefox seems to allow nothing (at least nothing I've tried so far), which seems reasonable. But chrome allows some no-cors fetches as well as some navigate fetches (but not all in either case)... |
| 18:27 | <Mek> | (the spec seems to allow all no-cors and navigate fetches though, which definitely doesn't match implementations) |
| 18:29 | <annevk> | Mek: I don't think I carefully considered blob loading and just grouped them with other things |
| 18:30 | <annevk> | Mek: also yeah, whenever you look into something ill-defined and go, "how does this actually work?", it's always bad news |
| 18:31 | <annevk> | When there's enough vagueness in a standard to allow for observable differences, there will be plenty of those |
| 18:31 | <annevk> | When the standard is solid, but there are no tests, same deal |
| 18:36 | <Mek> | yeah... that definitely matches my experience with these things... |
| 18:47 | <Mek> | actually writing a test to determine of a no-opener window.open succeeded or not is kind of annoying... |
| 18:59 | <wanderview> | Mek: BroadcastChannel() to a cross-origin iframe that forwards to its parent maybe? |
| 19:07 | <Mek> | yeah, that's what I'm thinking too |
| 19:08 | <wanderview> | Mek: won't work in webkit, but I guess neither would SharedWorker |
| 20:36 | <smaug____> | whaat, is Garrett Smith back |
| 20:38 | <smaug____> | is it possible to block a github user from commenting on issues? |
| 20:46 | <jyasskin> | smaug____: Yes, if you're an org admin: https://help.github.com/articles/blocking-a-user-from-your-organization/ |
| 20:47 | <smaug____> | aha |
| 20:47 | <jyasskin> | smaug____: There's also the milder https://help.github.com/articles/locking-conversations/ |
| 20:48 | <smaug____> | https://github.com/w3c/webcomponents/issues/713#issuecomment-362062221 is something requiring blocking, I think |
| 20:48 | <smaug____> | and hopefully such comment can be removed |
| 20:49 | <smaug____> | MikeSmith: ^ |
| 21:40 | <Mek> | does window.onload firing guarantee that any iframes in that window have also finished loading? |
| 21:41 | <Mek> | (and finished executing sync javascript that sets document.domain) |
| 21:44 | <gsnedders> | Mek: yes |
| 21:46 | <gsnedders> | Mek: see a bit below https://html.spec.whatwg.org/#iframe-load-event-steps |
| 21:46 | <gsnedders> | Mek: the paragraph beginning "When the iframe's browsing context's active document is not ready for post-load tasks" |
| 21:47 | <Mek> | gsnedders: I think that's about the iframes load event itself, not the load event of the window containing the document containing the iframe, right? |
| 21:48 | <Mek> | although it isn't clear if "the iframe's browsing context" is the browsing context inside the iframe or the browsing context the iframe lives in... |
| 21:49 | <gsnedders> | Mek: the end of the sentence |
| 21:49 | <gsnedders> | oh wait no you're right |
| 21:50 | <Mek> | the spec would be clearer if it actually refered to "the iframe's nested browsing context", rather than being vague about which exact browsing context it is talking about... |
| 21:50 | <Mek> | but yeah, an iframe no delaying the load event of its parent document would explain some (very infrequent) flakiness I'm seeing in some tests in chrome |
| 21:51 | <gsnedders> | it definitely /should/ AFAIK |
| 21:51 | <gsnedders> | per what browsers do |
| 21:54 | <gsnedders> | Mek: like this is exactly what the warning where I linked is about |
| 21:54 | <gsnedders> | wait no |
| 21:54 | <gsnedders> | kjdfkdfgkhfdg |
| 21:54 | <gsnedders> | can someone dig me out of this hole? |
| 21:56 | <gsnedders> | Mek: I think in the text I linked to by "the iframe must delay the load event of its document" means "the owner document of the iframe" rather than the one in the iframe? |
| 21:57 | <Mek> | I'm not sure... |
| 22:00 | <Domenic> | I am pretty sure that's what it means, but wow, that is unclear. |
| 22:00 | <Domenic> | Even just "its node document" would help me. |
| 22:02 | <gsnedders> | Domenic: see I went from thinking that was what it meant to being unsure to thinking that was what it meant *and I know what the behaviour should be*. |
| 22:02 | <Mek> | yeah, that text could definitely use some clarification... |
| 22:02 | <gsnedders> | and if someone who knows what the correct behaviour per-spec is can't figure out what the spec says… |
| 22:03 | <Mek> | it does seem like generally chrome does indeed delay the outer onload till the iframe is loaded. But I'm definitely getting (rare) flaky test failures where it seems like outer code waiting for onload runs before the inner iframe has had a chance to set document.domain. But maybe that's just a bug in chrome. |
| 22:04 | <gsnedders> | Mek: the web definitely relies on it |
| 22:07 | <Domenic> | Filed https://github.com/whatwg/html/issues/3436 for those who want to follow along |
| 22:09 | <Mek> | thanks |
| 22:33 | <MikeSmith> | smaug____: thanks for the heads-up |
| 23:31 | <TabAtkins> | Domenic: omg, where did you get your twitter header from? |
| 23:31 | <Domenic> | Hmm some Marvel comic... which one was it... |
| 23:33 | <Domenic> | I want to say Ant-Man? |
| 23:35 | <Domenic> | Yeah here we go http://readcomiconline.to/Comic/The-Astonishing-Ant-Man/Issue-5?id=34226#9 |
| 23:43 | <TabAtkins> | Ahahaha, two panels later is gold too. So good. |