| 10:31 | <smaug____> | specs don't have 80 chars per line in source rule? |
| 10:32 | <smaug____> | I wonder why, especially given how bad tools github has for reviewing |
| 10:32 | <annevk> | smaug____: 100 generally, these days |
| 10:32 | <smaug____> | ah |
| 10:32 | <annevk> | smaug____: though that's for WHATWG |
| 10:32 | <annevk> | no idea what anyone else is doing |
| 10:33 | <smaug____> | is it possible to see a raw diff of a commit ? |
| 10:34 | <annevk> | smaug____: if you have a GitHub URL you can append ".diff" I think |
| 10:34 | <annevk> | smaug____: or maybe ".patch", not sure |
| 10:34 | <Ms2ger> | Both work |
| 10:34 | <annevk> | hah |
| 10:35 | <smaug____> | what kind of url |
| 10:35 | <annevk> | smaug____: a commit or PR URL, e.g. https://github.com/whatwg/dom/pull/397.diff |
| 10:36 | <smaug____> | oh, after pr |
| 10:36 | <smaug____> | after commit didn't seem to work in this case |
| 10:36 | <annevk> | smaug____: hmm yeah, weird |
| 10:37 | <Ms2ger> | Probably fallout from the new review feature |
| 10:37 | <Ms2ger> | Still works on real commit URLs like https://github.com/whatwg/dom/commit/6b7621282c2e3b222ac585650e484abf4c0a416b.diff |
| 10:39 | <annevk> | smaug____: notice that if you just want unified, you can also enable that https://github.com/whatwg/dom/pull/397/files?diff=unified |
| 10:39 | <annevk> | smaug____: see the "Unified" and "Split" buttons next to "Review changes" |
| 10:40 | <smaug____> | I just want wider area to look at the changes |
| 10:41 | <annevk> | smaug____: sounds like you should get a bigger monitor |
| 10:41 | <smaug____> | annevk: github UI has the changes in middle of the page |
| 10:41 | <smaug____> | tons of white space on left and right |
| 10:42 | <smaug____> | perhaps the UI has some way to make it look different ? |
| 11:01 | <annevk> | smaug: for the "Split" view it seems to take up as much space as it can for me, though I don't have my browser fully maximized |
| 11:01 | <annevk> | smaug: "Unified" does indeed seem rather poor |
| 12:11 | <tobie> | annevk: familiar with the distinction between named and regular constructor in WebIDL? |
| 12:12 | <tobie> | annevk: the former require a [[Call]] prop which seems strange. |
| 12:12 | <tobie> | annevk: as for example, `Image()` throws, while `new Image()` doesn't. |
| 12:14 | <annevk> | tobie: they are like constructers, but basically are factory methods that require new |
| 12:15 | <tobie> | annevk: well why don't they instead have a [[Construct]] prop? |
| 12:16 | <tobie> | annevk: the only named constructor I can think of right now is Image. |
| 12:16 | <tobie> | annevk: what are examples of other ones? |
| 12:17 | <tobie> | annevk: I'm not sure what "factory method that requires new" actually mean. |
| 12:18 | <annevk> | tobie: Audio is another one |
| 12:18 | <tobie> | annevk: right |
| 12:19 | <tobie> | annevk: I'm trying to understand what the differences are between named and non-named constructors beyond their identifier |
| 12:19 | <annevk> | tobie: if you used [[Construct]], would they not become Image instances rather than HTMLImageElement? |
| 12:19 | <tobie> | annevk: you're asking me? :D |
| 12:20 | <annevk> | tobie: that is why I would expect them to be different |
| 12:20 | <tobie> | annevk: I'll look it up in the ES spec |
| 12:20 | <tobie> | annevk: I think you're right in that's were the critical difference is. |
| 12:21 | <tobie> | annevk: I'n not sure [[Call]] works though |
| 13:08 | <Ms2ger> | Also Option() |
| 13:10 | <tobie> | Ms2ger: oh, right. |
| 13:11 | <tobie> | I'm trying to understand what NewTarget is precisely in the ES spec-- |
| 13:11 | <Ms2ger> | Oh yes, that's weird |
| 13:11 | <tobie> | it's a reference to the constructor when using [[Construct]], |
| 13:12 | <tobie> | But then it only seems to be used to set the [[Prototype]] of the created object? |
| 13:12 | <Ms2ger> | https://tc39.github.io/ecma262/#sec-built-in-function-objects may be useful? Dunno |
| 13:13 | <tobie> | well, for some value of useful, certainly |
| 13:14 | <tobie> | "the [[Construct]] newTarget parameter provides the NewTarget value." |
| 13:17 | <tobie> | ^ so now I know. |
| 13:19 | <annevk> | I was someone would write a NewTarget explainer. I keep forgetting how it works |
| 13:19 | <annevk> | And that it's not passed around as value isn't helping |
| 13:20 | <tobie> | don't get me started on that second comment |
| 13:21 | <annevk> | jochen__: interested in fixing https://github.com/whatwg/html/issues/2282? |
| 13:21 | <annevk> | jochen__: or are you still stuck outside? ☃️ |
| 13:28 | <jochen__> | no, they let us back in :) |
| 13:28 | <jochen__> | sure, can do |
| 13:29 | <jochen__> | I also promised ms2ger a test for this :/ |
| 13:29 | <Ms2ger> | You did? |
| 13:35 | <jgraham> | Ms2ger: sssh |
| 13:36 | <jochen__> | https://github.com/whatwg/html/pull/583#issuecomment-176751740 |
| 13:36 | <Ms2ger> | Hah |
| 13:36 | <Ms2ger> | Well, where is it? :) |
| 13:37 | <jochen__> | good question |
| 13:39 | <jochen__> | do we have a cross browser way that would somehow allow for accessing a document cross origin? |
| 13:40 | <jochen__> | i thought firefox revokes access to the document if I pass it same origin and then use document.origin to change the current realms origin |
| 13:40 | <annevk> | jochen__: through document.domain you can access it |
| 13:41 | <annevk> | jochen__: when the documents are same origin-domain, but not same origin |
| 13:41 | <jochen__> | oh, so the access won't be revoked? |
| 13:43 | <annevk> | jochen__: you're thinking of another scenario, where documents are same origin, but then you revoke access in one of them by setting document.domain |
| 13:44 | <tobie> | Domenic: trying to figure out the difference between NamedConstructors and regular ones. LMK if you're around to chat about it later on. |
| 13:45 | <tobie> | Domenic: there's also discrepancies as to how the different vendors implement the spec. |
| 13:46 | <tobie> | Domenic: e.g. Image.prototype === HTMLImageElement.prototype, which per spec should be true. |
| 13:46 | <tobie> | Domenic: and isn't in Blink. |
| 13:48 | <annevk> | jochen__: https://dump.testsuite.org/js/documentdomain.htm is the one you're thinking of |
| 13:56 | <gsnedders> | I'm having system fonts completely fail to work on Firefox on Linux. New and old profiles. The only things that work are the generic keywords (serif, sans-serif, etc.). Any ideas? |
| 14:13 | <jgraham> | gsnedders: This doesn't seem like a channel where people are particularly informed about Firefox Linux fonts |
| 14:15 | <gsnedders> | jgraham: no, but it's not obvious where is. the support channels are equally useless, and it's in principle a support request and hence off-topic for the dev channels |
| 14:16 | <jgraham> | gsnedders: And yet it's a reasonably technical question that probably only someone who knows something about font lookup will be able to help with |
| 14:17 | <jgraham> | I'm going to assume that your reason for caring is to do with CSS tests |
| 14:17 | <jgraham> | Therefore it's a dev question |
| 14:20 | <gsnedders> | Yes. Though is does coincidentally answer why Firefox has been using different fonts for everything for years. :) |
| 14:31 | <JakeA> | annevk: random thought: Has enough time passed, from the bad old IE days, to do something with the return value of event handlers? For instance, service worker events could pass the return value to event.waitUntil, meaning service worker event listeners could be async functions |
| 14:36 | <annevk> | JakeA: event handlers already do something with the return value |
| 14:38 | <JakeA> | annevk: I still suck at reading specs. https://dom.spec.whatwg.org/#concept-event-listener-inner-invoke is the best I could find in terms of a "call" point for listeners |
| 14:39 | <JakeA> | I couldn't see the return value being used |
| 14:39 | <annevk> | JakeA: event handlers are not event listeners |
| 14:39 | <annevk> | JakeA: an event handler is something like "onclick" |
| 14:40 | <annevk> | JakeA: their processing model is defined in HTML |
| 14:40 | <tobie> | Anyone can help me locate examples of callback interfaces with constants? |
| 14:41 | <JakeA> | annevk: ohhh, wasn't aware that was the difference in terminology! I guess I meant "listener" rather than "handler" |
| 14:41 | <annevk> | tobie: NodeFilter |
| 14:41 | <tobie> | WebIDL claims all interfaces should have a name prop. Seems dubious for callback interfaces |
| 14:41 | <tobie> | annevk: ta |
| 14:42 | <tobie> | So maybe not dubious. |
| 14:42 | <annevk> | JakeA: so you want onfetch() and addEventListener("fetch", ...) to be different with respect to return values? |
| 14:42 | <annevk> | JakeA: I mean, they already are somewhat, but this would really throw that in people's faces |
| 14:43 | <annevk> | JakeA: it's also a little weird since you have multiple listeners |
| 14:44 | <JakeA> | annevk: yeah, I see the problem. The same could be done for handlers. A little hacky though. |
| 14:44 | <annevk> | can have* |
| 14:44 | <annevk> | JakeA: handlers already have a return value that maps to preventDefault() |
| 14:44 | <JakeA> | annevk: it should be fine for multiple listeners. It wouldn't make sense for respondWith, but waitUntil makes sense |
| 14:45 | <JakeA> | annevk: yeah, it would be an exception to that, that's why it's a bit hacky |
| 14:45 | <JakeA> | Probably shouldn't try and make it work for onfetch |
| 14:45 | <JakeA> | if at all |
| 14:45 | <annevk> | JakeA: this is one of the arguments I put forward at some point as to why service workers should maybe not reuse EventTarget, but that got dismissed |
| 14:46 | <annevk> | JakeA: everyone was in a rush to ship... |
| 14:46 | <JakeA> | annevk: yeah, I saw media sessions used something different, which is a bit odd |
| 15:15 | <Domenic> | tobie: named constructors are just weird factory functions |
| 15:15 | <annevk> | Domenic: that explanation did not help when I tried it |
| 15:15 | <tobie> | Heh |
| 15:16 | <Domenic> | They're like... `function Image(x, y) { if (!new.target) { throw new TypeError("you didn't call me with new"); } return useUAMagicToCreateNewImage(x, y); }; Image.prototype = HTMLImageElement.prototpe;` |
| 15:16 | <Domenic> | They're pretty unrelated to constructors |
| 15:16 | <Domenic> | I'd definitely put them in the legacy bucket |
| 15:16 | <tobie> | Oh. |
| 15:17 | <annevk> | When are we going to prefix all legacy things with Legacy? |
| 15:17 | <Domenic> | It's just so much churn... |
| 15:17 | <Domenic> | For all dependent specs |
| 15:17 | <Domenic> | Maybe we need a platform-wide IDL index first |
| 15:17 | <tobie> | Yes! |
| 15:17 | <annevk> | Well this one is only used by HTML |
| 15:17 | <Domenic> | Although usually leaning on bz doing a Gecko code search works pretty well |
| 15:18 | <Domenic> | Oh really? |
| 15:18 | <Domenic> | That's kind of nice |
| 15:18 | <annevk> | Named getters is only a couple of specs |
| 15:18 | <annevk> | I think the churn is pretty manageable these days because of Gecko code search and GitHub PRs |
| 15:18 | <Domenic> | tobie: looking at the spec it seems the new.target check is not in the spec? |
| 15:18 | <Domenic> | not sure if that's a spec bug or what |
| 15:19 | <Domenic> | Huh I guess Gecko and Blink require new |
| 15:19 | <tobie> | Yeah, the whole area needs cleanup, frankly. |
| 15:19 | <Domenic> | OK I'll start filing a few bugs |
| 15:20 | <Domenic> | What's a platform object constructor that Edge would actually have... |
| 15:20 | <Domenic> | events |
| 15:21 | <tobie> | I would have hoped we could have one algorithm for construction, not two. |
| 15:22 | <Domenic> | One of the bugs i"m about to file is to rename the feature so you don't think that it's related to construction |
| 15:22 | <tobie> | Well, you still need to construct the returned object, don't you? |
| 15:22 | <Domenic> | No |
| 15:22 | <Domenic> | You need to use UA magic to create it |
| 15:23 | <Domenic> | i.e. call the algorithm supplied |
| 15:23 | <tobie> | ... |
| 15:24 | <tobie> | The blink implementation is all weird, btw. |
| 15:25 | <Ms2ger`> | What'd you expect from a browser? :) |
| 15:25 | <tobie> | Image.name returns HTMLImageElement |
| 15:26 | <tobie> | Image.prototype === HTMLImageElement returns false. |
| 15:26 | <Domenic> | https://github.com/heycam/webidl/issues/276 |
| 15:27 | <tobie> | Sorry, Image.prototype === HTMLImageElement.prototype returns false. |
| 15:28 | <tobie> | Oh, you saw those. |
| 15:28 | <Domenic> | Other bugs filed https://github.com/heycam/webidl/issues/275 and https://github.com/heycam/webidl/issues/277 |
| 15:29 | <tobie> | I'll write the tests. |
| 15:29 | <Domenic> | \o/ |
| 15:32 | <Domenic> | new.target is just "the target of the new operator" BTW. So in `new X()`, `new.target === X`. In `Y()`, `new.target === undefined`. |
| 15:32 | <Domenic> | This gets interesting when super-construction is involved |
| 15:33 | <Domenic> | so if you do `class X extends SuperX { constructor() { super(); } }` |
| 15:33 | <Domenic> | then inside `SuperX`'s constructor, `new.target === X` still |
| 16:08 | <annevk> | Domenic: oh, so you can make the Super branch on subclasses? Okay |
| 16:08 | <annevk> | Domenic: I think I sorta new this, but I keep forgetting since I haven't written any code with it yet and we don't have actual subclassing in IDL yet |
| 16:09 | <annevk> | Domenic: e.g., it seems feasible to allow subclasses of some IDL-defined classes that don't rely on too much branding, but we haven't really gotten there it seems |
| 16:09 | <annevk> | Domenic: I guess we have custom elements |
| 16:14 | <tobie> | Domenic, annevk: While, we're at it, we do agree that callback interfaces, when they show up because of constants, should: have a name prop, a length prop of 0, a prototype === Function.prototype, and throw both when called and constructed? |
| 16:17 | <tobie> | Domenic: I'm kind of confused about the relationship between [[Call]], [[Construct]] and NewTarget. I imagined that if NewTarget was not undefined, you'd be calling [[Call]], but from NamedConstructors it seems this isn't the case. |
| 16:18 | <tobie> | Domenic: frankly, the ES spec isn't being super helpful here. |
| 16:18 | <Domenic> | I don't remember the latest agreement on callback interfaces |
| 16:18 | <Domenic> | NewTarget is defined for both [[Call]] and [[Construct]] |
| 16:19 | <Domenic> | [[Construct]] almost always just delegates to [[Call]] |
| 16:19 | <Domenic> | I think the spec was updated for callback interfaces so probably whatever's there is what was agreed on |
| 16:21 | <Domenic> | Hmm I guess [[Construct]] delegating to [[Call]] is not quite right |
| 16:21 | <Domenic> | But they use the same algorithm for all built-in functions |
| 16:21 | <Domenic> | Just NewTarget is undefined for [[Call]] |
| 16:21 | <Domenic> | https://tc39.github.io/ecma262/#sec-built-in-function-objects |
| 16:22 | <tobie> | so then how can we only have a [[Call]] on NamedConstructors? |
| 16:22 | <tobie> | see: https://github.com/heycam/webidl/issues/275 |
| 16:26 | <tobie> | Domenic: ^ |
| 16:26 | <Domenic> | Why do you think we only have [[Call]]? |
| 16:27 | <Domenic> | Hmm I see I guess the spec does kind of imply that |
| 16:27 | <Domenic> | Will file an issue |
| 16:28 | <tobie> | Domenic: Well, we don't even need [[Call]] if calling without NewTarget needs to throw. |
| 16:29 | <tobie> | Domenic: we don't have it for regular constructors either, so… |
| 16:29 | <Domenic> | You always need [[Call]] |
| 16:29 | <Domenic> | Otherwise typeof is not "function" |
| 16:30 | <tobie> | oh. So constructors should have one too. |
| 16:31 | <tobie> | Domenic: see what I mean. This is all very confusing. |
| 16:31 | <tobie> | :) |
| 16:31 | <Domenic> | Constructors do have one |
| 16:31 | <Domenic> | https://github.com/heycam/webidl/issues/278 |
| 16:32 | <tobie> | Domenic: implicitely. But they're explicit for NamedConstructors |
| 16:32 | <tobie> | Domenic: hence my confusion |
| 16:33 | <Domenic> | Yeah |
| 16:33 | <Domenic> | It seems to me like constructors were updated and named constructors were not |
| 16:33 | <tobie> | Domenic: well "hence" is maybe a bit exaggerated. Let's simply say it didn't help. :) |
| 16:33 | <Domenic> | :) |
| 16:33 | <tobie> | Domenic: yeah, I'm actually to blame for that. Partially. |
| 16:37 | <tobie> | So I was hoping to close webidl#135. The result? #135 is still open, and now I also have: #275, #276, #277, #278 and a headache. |
| 16:39 | <Domenic> | heh :-S |
| 16:39 | <nox> | tobie: But now you can fall asleep faster, |
| 16:39 | <nox> | tobie: "1 WebIDL ticket, 2 WebIDL tickets, 3 WebIDL tickets, ...". |
| 16:39 | <tobie> | nox: hehe |
| 16:48 | <tobie> | Domenic: why can't we express calling NamedConstructor with: Construct (NamedConstructor, args, InterfaceObject) ? |
| 16:49 | <Domenic> | tobie: I don't understand what that means |
| 16:50 | <tobie> | Domenic: referring to the Construct abstract operation in ES |
| 16:50 | <Domenic> | What does "calling NamedConstructor" mean? |
| 16:51 | <tobie> | fair question :) |
| 16:51 | <Domenic> | It also seems unlikely to work since e.g. HTMLImageElement just throws when you use Construct() on it |
| 16:51 | <Domenic> | Image() and Image(x, y) have an algorithm that uses UA magic to create HTMLImageElement instances |
| 16:51 | <tobie> | I meant this: new Image() -> Construct(Image, [], HTMLImageElement) |
| 16:51 | <Domenic> | That's circular |
| 16:52 | <Domenic> | new Image() *means* Construct(Image, [], Image) |
| 16:52 | <Domenic> | Which calls Image.[[Construct]]([], Image) |
| 16:52 | <Domenic> | So now we need a definition for Image.[[Construct]] |
| 16:53 | <Domenic> | hopefully not one that just calls Image.[[Construct]] again |
| 16:54 | <tobie> | What syntax do you even use to do Construct(Foo, [], NotFoo) ? |
| 16:54 | <Domenic> | It's impossible |
| 16:55 | <Domenic> | Oh no |
| 16:55 | <Domenic> | It's super() |
| 16:55 | <tobie> | Domenic: Oh! That why |
| 16:55 | <tobie> | *That's |
| 16:55 | <tobie> | Now I get it. |
| 16:56 | <Domenic> | super() <-> Construct(SuperclassConstructor, [], ConstructorNewOperatorWasAppliedTo) |
| 16:56 | <tobie> | Thanks |
| 16:56 | <Domenic> | \o/ |
| 16:57 | <tobie> | So that solves a similar problem to the one we have, except not the one we have for which we prefer UA magic. |
| 16:57 | <Domenic> | I guess? |
| 16:58 | <tobie> | Alright. Thanks. I'll put this to rest and try to come with a coherent whole. |
| 18:16 | <tobie> | What's up with the HTML-specific extended attributes? |
| 18:28 | <Domenic> | They exist? They're nice? |
| 19:29 | <TabAtkins> | gsnedders: Does html5lib emit parse errors at all? |
| 19:30 | <TabAtkins> | gsnedders: (Context: https://github.com/tabatkins/bikeshed/issues/905) |
| 19:34 | <jgraham> | TabAtkins: It can I think, unless that got removed at some point, but I wouldn't trust them to be correct |
| 19:57 | <gsnedders> | TabAtkins: yes. they've not been udpated in forever and we ignore the tests for them. |
| 19:57 | <gsnedders> | TabAtkins: parser.errors, IIRC |
| 20:02 | <tobie> | Domenic: https://html.spec.whatwg.org/multipage/dom.html#htmlconstructor |
| 20:04 | <tobie> | Domenic: https://html.spec.whatwg.org/multipage/scripting.html#cereactions |
| 20:04 | <Domenic> | Yes, I know what they are. |
| 20:04 | <Domenic> | They exist and are nice. |
| 20:04 | <Domenic> | That's what's up with them? |
| 20:05 | <Domenic> | We'll probably add [Reflect] at some point so we can stop with the repetitive prose |
| 20:05 | <tobie> | Oh, misread your previous comment. |
| 20:07 | <tobie> | I was just wondering if there were specific plans with them. |
| 20:13 | <Domenic> | Not that I know of; they're working pretty well as-is. |
| 20:17 | <tobie> | Domenic: cool |
| 20:18 | tobie | didn't know about them and so was rather surprised. |
| 20:31 | <tobie> | Domenic: thoughts about https://github.com/heycam/webidl/issues/279? |
| 20:32 | <Domenic> | tobie: matching the majority of browsers seems good yeah |
| 20:34 | <Domenic> | Where is the ES binding for callback-interfaces-with-constants defined? |
| 20:37 | <tobie> | Domenic: it's sort of scattered |
| 20:38 | <Domenic> | They're so gross |
| 20:38 | <Domenic> | So far I found https://heycam.github.io/webidl/#es-interfaces but not "name" |
| 20:38 | <tobie> | Domenic: last paragraph of https://heycam.github.io/webidl/#es-constructible-interfaces |
| 20:39 | <Domenic> | Ugh |
| 20:39 | <tobie> | yea |
| 20:39 | <Domenic> | I guess that heading is what's confusing |
| 20:39 | <Domenic> | "Interface object call/construct behavior" might be more reasonable |
| 20:39 | <Domenic> | Or maybe "Interface objects as functions" |
| 20:40 | <Domenic> | Wait so all interface objects should have a "length" defined somewhere |
| 20:40 | <Domenic> | Not just callback interfaces |
| 20:40 | <Domenic> | Oh I see |
| 20:40 | <Domenic> | There's an algorithm box around the "non-callback interfaces get a length determined like this" section |
| 20:42 | <tobie> | Yeah, I was thinking about refactoring the whole thing |
| 20:42 | <tobie> | they all need length, name and proto |
| 20:45 | <Domenic> | So the new way to do this is to explicitly create the things and add them to the global object |
| 20:46 | <Domenic> | See https://heycam.github.io/webidl/#es-namespaces |
| 20:46 | <Domenic> | Or, for how to create functions, see https://heycam.github.io/webidl/#dfn-attribute-getter |
| 20:49 | <Domenic> | I guess the "add them to the global object" step is not yet revamped |
| 20:49 | <Domenic> | Maybe do that last |
| 20:49 | <Domenic> | None of this really seems necessary to solve https://github.com/heycam/webidl/issues/135 though |
| 20:52 | <tobie> | yeah? |
| 20:53 | <tobie> | Domenic: I wasn't too sure how to go about this |
| 20:55 | <tobie> | adding these as Asserts to constructor and NamedConstructor bindings? |
| 21:00 | <Domenic> | tobie: oh, no, I was thinking just add a new section (e.g. "creating objects") that states basically what the bug states |
| 21:01 | <Domenic> | Maybe it defines "new object" or something |
| 21:02 | <Domenic> | Maybe Interface definition language > Interfaces > Creating instances of interfaces ? |
| 21:03 | <Domenic> | Oh or maybe just a paragraph or so in https://heycam.github.io/webidl/#idl-objects |
| 21:04 | <tobie> | Domenic: got it |
| 21:57 | <Domenic> | annevk: I've lost track of what I'm on the hook for for URL reviews. Let me know what's left. It seems like things are still kind of in the negotiation phase? |
| 22:05 | <tobie> | TabAtkins: any plans for https://github.com/tabatkins/bikeshed/issues/812? |
| 22:14 | <Domenic> | tobie: re https://github.com/tabatkins/bikeshed/issues/812#issuecomment-255341823, I hear XSLT has this thing called processing instructions... ;) |
| 22:14 | <TabAtkins> | Boooooooo |
| 22:15 | <tobie> | :D |
| 22:28 | <smaug> | Why BodyInit uses UVString |
| 22:29 | <smaug> | USVString |
| 22:29 | <smaug> | that looks like a bug to me |
| 22:31 | <smaug> | annevk: still awake? |
| 22:31 | <tobie> | smaug: making the prose about when to use UVString is on my todo list: https://github.com/heycam/webidl/issues/84 |
| 22:32 | <tobie> | smaug: oh, that's in fetch? |
| 22:32 | <smaug> | yes |
| 22:33 | <smaug> | it didn't use to |
| 22:33 | <smaug> | it was taking DOMString |
| 22:33 | <tobie> | smaug: don't mind me, then. |
| 22:33 | <smaug> | it is after all just random data |
| 22:34 | <smaug> | ah, it is converted to utf8 anyhow |
| 22:35 | <smaug> | right right, makes sense |
| 22:35 | <tobie> | smaug: I guess it just means it'll turn whatever string is thrown its way into an UVString. |
| 22:35 | <tobie> | smaug: yeah, what you said above |
| 22:37 | <tobie> | smaug: relevant bit in WebIDL is https://heycam.github.io/webidl/#es-USVString |