| 07:57 | <sangwhan> | If I understood the intention correctly - transform streams are only intended to be used to build linear (non-branching) transformation pipelines, is this correct? |
| 07:58 | <sangwhan> | e.g. not this: https://upload.wikimedia.org/wikipedia/commons/5/55/ArquitecturaPipeAndFilter.jpeg |
| 08:33 | <annevk> | sangwhan: afaik they have an input and output, but what you do inside is up to you |
| 08:33 | <annevk> | sangwhan: so you could tee the input, do something, and then combine it again before sending it onward |
| 08:35 | <sangwhan> | annevk: okay, so tee then doing two parallel transforms is supposed to work? |
| 08:36 | <annevk> | sangwhan: I mean, I don't see why not? But I'm very far from an expert |
| 08:38 | <sangwhan> | annevk: Neither am I - trying to figure out how to combine the two later |
| 08:40 | <sangwhan> | I guess you just read from two and do your thing, I think I'm slowly making sense out of this now |
| 08:40 | <annevk> | sangwhan: yeah, that's how I'd think of it too |
| 08:42 | <sangwhan> | annevk: thanks, think I can probably scrub that off the list now :) |
| 09:50 | <annevk> | MikeSmith: interested in helping gathering data on h1/hgroup? https://github.com/whatwg/html/issues/83#issuecomment-360415905 |
| 09:51 | <MikeSmith> | annevk: hai |
| 09:51 | <MikeSmith> | Steve pinged me about that too |
| 09:52 | <MikeSmith> | will add some use counters to the checker |
| 09:52 | <annevk> | <3 |
| 09:54 | <annevk> | Ms2ger: is https://github.com/whatwg/html/issues/3323#issuecomment-360413258 an argument for WebKit's behavior? |
| 09:54 | Ms2ger | looks what webkit does |
| 09:54 | <annevk> | Ms2ger: I don't really understand what you mean by it |
| 09:54 | <Ms2ger> | Yes |
| 09:55 | <annevk> | Ms2ger: but 300/150 is not the maximum size in WebKit, so it's not logical rounding |
| 09:55 | <tantek> | wait hgroup is still a thing? |
| 09:55 | <annevk> | Ms2ger: it looks much more like trying and then falling back to a default |
| 09:55 | <annevk> | tantek: euh yes? |
| 09:56 | <Ms2ger> | annevk, 300x150 is the size of the canvas argument |
| 09:56 | <annevk> | Ms2ger: ah okay, so what does WebKit do if the <canvas> is too large? |
| 09:57 | <Ms2ger> | Throw RangeError, I think |
| 09:57 | <Ms2ger> | Lemme check if there's a test for that |
| 09:59 | <Ms2ger> | Oh no, InvalidStateError (not sure why) |
| 09:59 | <Ms2ger> | http://w3c-test.org/2dcontext/imagebitmap/createImageBitmap-invalid-args.html ("createImageBitmap with an oversized canvas source.") |
| 10:12 | <annevk> | Ms2ger: I see, if you do eager clipping the WebKit behavior makes some |
| 10:16 | <Ms2ger> | I think that makes the most sense, but I'm happy whichever way you go, as long as it's clear :) |
| 10:29 | <annevk> | "As long as it's clear" such a high bar |
| 10:55 | <Ms2ger> | It's canvas, so I'll settle for "sorta clear" ;); |
| 11:19 | <jgraham> | Trasparent black? |
| 11:32 | Ms2ger | covers jgraham in transparent black |
| 14:32 | <annevk> | tobie: I think you don't understand, the idea is that you pay the W3C: https://www.w3.org/support/ |
| 14:33 | <annevk> | tobie: that's how you become a friend, not by doing unpaid work |
| 14:34 | <tobie> | annevk: oh boy. What is this even |
| 14:35 | <annevk> | tobie: it's a way to get even more enraged on Twitter |
| 14:36 | <annevk> | tobie: this reminds me of how you get a certificate for being a chair, but not even a thank you for tons of editing/review work |
| 14:37 | <jgraham> | tobie: Less helpfully, it's "As if on cue", not "queue". Isn't English wonderful. |
| 14:37 | <jgraham> | You get a certificate? |
| 14:37 | <jgraham> | hahahaha |
| 14:39 | <tobie> | jgraham: arg. I had doubts about that when I wrote it. should have checked. |
| 14:41 | <tobie> | also I blame data structures. |
| 14:44 | <tobie> | This is all sangwhan's fault for tweeting about this in the first place. |
| 14:45 | <nox> | annevk, tobie: MFW we don't even remember what's an identifier |
| 15:01 | <tobie> | nox: I'm not super I follow. :-/ |
| 15:01 | <tobie> | *super sure |
| 15:01 | <nox> | tobie: https://github.com/whatwg/html/issues/3238#issuecomment-360486782 |
| 15:02 | <tobie> | nox: oh! |
| 15:02 | <tobie> | nox: we can easily tweek that rule |
| 15:02 | <nox> | Can we twerk the rule? |
| 15:03 | <nox> | Anyway, yeah we can definitely change WebIDL, I was just stating its current state. |
| 15:03 | <tobie> | me and spelling aren't friends today |
| 15:04 | <tobie> | nox: sure. But sometimes it's a lot harder to do so. For that particular case, it's actually really simple. |
| 15:05 | <tobie> | nox: given the current state its an artificial subset of what the grammar supports |
| 15:05 | <tobie> | nox: *is |
| 15:05 | <nox> | tobie: Yep yep. |
| 15:06 | <nox> | tobie: Also, I enjoy how Edge's WebIDL parser seems to be waaaaay more liberal than any other. |
| 15:06 | <tobie> | nox: I'm not sure I actually want to hear about that. |
| 15:06 | <nox> | tobie: Oh no I'm not saying it's a bad parser, |
| 15:06 | <nox> | just that they didn't seem to have implemented a lot of artificial constraints from the spec. |
| 15:07 | <tobie> | nox: neither was I implying that's what you were saying. |
| 15:07 | <tobie> | nox: I'd just like not to have interop parsing issues between different WebIDL implementations. |
| 15:08 | <nox> | tobie: Found what I had in mind: https://github.com/whatwg/html/issues/775#issuecomment-190851825 |
| 15:08 | <nox> | "legacycaller getter (HTMLCollection or Element)? item((unsigned long or DOMString) nameOrIndex);" YOLO |
| 15:12 | <tobie> | 🙈 🙉 🙊 |
| 15:14 | <Ms2ger> | nox, what's disallowed about that? |
| 15:14 | <nox> | Ms2ger: Can't combine legacycaller and getter (IIRC, not sure I remembered that part well), and a getter argument type must be unsigned long or DOMString, it can't be an union of them, or be anything else. |
| 15:15 | <Ms2ger> | Oh, fair |
| 15:15 | <nox> | Ms2ger: But yeah, it does sound weird, |
| 15:16 | <nox> | their parser and the semantics they give to WebIDL are cleaner, but it's not like we are going to change all existing parsers and toolchains for the sake of the orthogonality of features. |
| 18:58 | <annevk> | Domenic: tobie: if you want to refer to the JavaScript value of something that passed as "any" across the boundary, what's the pattern for that? https://github.com/whatwg/html/pull/3370#pullrequestreview-91552683 |
| 18:58 | <annevk> | Domenic: tobie: the conversion it does at the moment seems wrong, since there's no conversion afaik, there just exists a JS value |
| 19:35 | <Domenic> | annevk: tobie and I talked about making this more explicit last week. We think maybe requiring explicit coercion makes the most sense even for types that are just 1-1 containers like any or interface types. |
| 19:36 | <annevk> | Domenic: ok, I guess I’ll leave this then |
| 19:36 | <Domenic> | We'd make this explicit by defining "corresponding IDL value" and "corresponding ECMAScript value" or similar. |
| 19:37 | <Domenic> | Right now there are several handwavey phrases used inside the Web IDL spec. Outside that spec I guess most people use conversions. |
| 19:38 | <annevk> | Allowing an IDL any to be passed to dict extraction might be nice too |
| 19:38 | <annevk> | And I guess using Type() on IDL any is wrongish too |
| 19:38 | <annevk> | Need to reverse those steps |
| 19:40 | <Domenic> | I argued a bit for allowing implicit interchange between those types. But I realized I am biased because I work a lot in spec areas that are on the boundaries. So for most people allowing implicit treatment as either would be confusing. |
| 19:42 | <annevk> | sg |
| 21:20 | <lgrahl> | Hey everyone. :) |
| 21:20 | <lgrahl> | annevk: ping |
| 21:21 | <annevk> | Heya, I hope Domenic can help you out as I’m about to sleep 💤 |
| 21:21 | <lgrahl> | Okay, no worries. |
| 21:22 | <lgrahl> | Domenic: ping |
| 21:22 | <Domenic> | What's up? |
| 21:22 | <lgrahl> | Have you had a look at the data channel streams discussion lately? |
| 21:24 | <Domenic> | I've been trying to follow, although I haven't had time to really digest. My main impression is that you all know more about the data channel domain than I do, and in the streams domain you seem to be pretty on track as well, so I'm positive :) |
| 21:24 | <lgrahl> | That's good for starters. :) Do you have an idea what Harald is on about (https://github.com/w3c/webrtc-pc/issues/1732#issuecomment-360507120)? I'm quite puzzled... |
| 21:25 | <lgrahl> | Is there something related to Blob I have not seen so far? |
| 21:25 | <Domenic> | Hmm |
| 21:26 | <Domenic> | I mean they're vaguely related in that both blobs and streams allow you to not hold the data all in memory at one time? |
| 21:26 | <Domenic> | It almost feels like a wrong-thread though, weird. |
| 21:27 | <lgrahl> | I thought maybe you're familiar with Blob as well and there's some way to get a stream out of a Blob... even though I can already see that it would fail on the receiver side with the current API. |
| 21:28 | <lgrahl> | Because it really is a chicken-egg problem: How do I know what the user wants to do with the data (in form of a Blob) before it's complete. |
| 21:30 | <Domenic> | Ah, there is a hacky way to convert blob to stream actually |
| 21:30 | <lgrahl> | What would really help me is a side-by-side comparison of streams vs. Blob. I think that should do as a viable response to that comment. Do we have something like that somewhere? Thinking of stuff like backpressure, ... |
| 21:30 | <Domenic> | (new Response(blob)).body |
| 21:31 | <lgrahl> | Ah sure, using the body mixin. |
| 21:31 | <Domenic> | I guess we don't have that preexisting, because they're really different... you can't actually get at the data in the blob without using FileReader which is a huge mess... |
| 21:31 | <lgrahl> | Yeah, it is and it's also really, really slow. |
| 21:33 | <lgrahl> | (In case you're interested how slow in comparison: https://jsperf.com/dc-reassembly) |
| 21:35 | <lgrahl> | Okay, so we don't have that... but is there a short document that emphasizes the advantages of streams in comparison with what we have in browsers at the moment? |
| 21:41 | <lgrahl> | What I have in mind is: Handling backpressure on both sides (I'm not actually sure the term 'backpressure' is applicable to both sides), low-level API when needed, high-level API when possible (pipeTo), ... and I'm sure there are other advantages I haven't considered, yet. |
| 22:08 | <lgrahl> | Domenic: Ping (still there?) :) |
| 22:09 | <Domenic> | lgrahl: sorry, in meetings for the next while |
| 22:09 | <Domenic> | https://github.com/whatwg/streams/blob/master/Requirements.md and https://github.com/whatwg/streams/blob/master/FAQ.md might be somewhat helpful |
| 22:10 | <Domenic> | https://streams.spec.whatwg.org/#intro and the following section probably should help too |
| 22:10 | <Domenic> | But in the end we might be missing exactly what you describe, which is good feedback and we should fix... |
| 22:11 | <lgrahl> | Cheers! I'll have a look at these. |
| 22:15 | <Domenic> | (ricea ^) |
