| 01:25 | <TabAtkins> | Hm, how do I indicate in WebIDL that a method can return undefined? |
| 01:28 | <TabAtkins> | Ah, looks like "void" works, like (void or FooType)? |
| 01:30 | <TabAtkins> | No, that doesn't work, hrm. I'm trying to replicate the behavior of Map.get(). |
| 01:47 | <KiChjang> | isn't it just FooType? |
| 01:47 | <KiChjang> | with the question mark that is |
| 01:50 | <TabAtkins> | KiChjang: No, that allows null, which is a very different value. ^_^ |
| 01:51 | <KiChjang> | ugh |
| 01:51 | <TabAtkins> | Yeah, per https://github.com/heycam/webidl/issues/60 the only way to do it currently is to write the type as `any`. ;_; |
| 01:52 | <TabAtkins> | (So I've done that, followed by a comment that it's really `(undefined or CSSStyleValue)`.) |
| 03:32 | <TabAtkins> | Another webidl question: I have an interface, [Exposed] to globals A and B. The interface is maplike, and I override the definition of one of the maplike methods, but only mark it as [Exposed=A]. Does this mean that B sees the interface with the *default* version of the method, or does it not see the method at all? |
| 03:32 | <TabAtkins> | tobie, domenic, annevk : ^^^ |
| 03:58 | <Domenic> | I was under the impression that you could not override a maplike's map methods |
| 03:58 | <Domenic> | "Maplike interfaces must not have any interface members named "entries", "forEach", "get", "has", "keys", "size", or "values", or have any inherited interfaces that have members with these names. Read–write maplike interfaces must not have any attributes or constants named "clear", "delete", or "set", or have any inherited interfaces that have attributes or constants with these names." |
| 03:59 | <Domenic> | I see, but read/write can override clear/delete/set |
| 04:00 | <Domenic> | Per the letter of the spec it appears your exposed is completely ignored https://heycam.github.io/webidl/#es-map-clear |
| 04:00 | <Domenic> | Well, no, I maybe am misinterpreting... |
| 04:00 | <Domenic> | So you declare something with (e.g.) a clear identifier |
| 04:00 | <Domenic> | So the default does not get installed |
| 04:00 | <Domenic> | But then nothing else gets installed |
| 04:00 | <Domenic> | So I guess the method doesn't exist? |
| 04:00 | <Domenic> | This is going to need serious tests though |
| 04:03 | <TabAtkins> | Oh, hmmmm, I need to get IDL fixed to allow overriding of get(). (Because I'm implementing a multimap, so the map entries are string->list<Foo>, but .get() needs to return a single Foo.) |
| 04:04 | <TabAtkins> | (Or we just need to put multimaps into IDL.) |
| 04:15 | <Domenic> | I think you just want to not use maplike, like the other 2-3 multimaps in the platform |
| 04:22 | <TabAtkins> | I found URLSearchParams, is there another? |
| 04:23 | <TabAtkins> | And it would be sad to lose maplike; StylePropertyMap is *more* map-like than URLSearchParams, even. (The underlying representation of SPM is a map of key->list<val>, while the underlying repr of USP is list<key->val>.) |
| 04:24 | <TabAtkins> | map<key, list<val>> vs list<(key,val)>, rather. |
| 04:25 | <TabAtkins> | In any case, we should *at minimum* enshrine multimap as an example in WebIDL, to make sure that we don't diverge definitions - StylePropertyMap is currently making set() and append() n-ary, while URLSearchParams doesn't. |
| 04:25 | <TabAtkins> | (I opened an IDL issue for this, https://github.com/heycam/webidl/issues/514) |
| 04:42 | <Domenic> | Yes, it would be good to match URLSearchParams and FormData, and e.g. not make those n-ary |
| 04:42 | <Domenic> | set() should override entirely |
| 04:53 | <TabAtkins> | set() *does* override entirely, but it lets you set multiple values in one (rather than having to call .set(), then .append() several times). |
| 04:53 | <TabAtkins> | (It also moves the value to the end of the map, which URLSearchParams does *not* do.) |
| 04:58 | <TabAtkins> | (For the list<(key,val)> semantics, setting in-place does often make more sense, and if you're setting in place, it makes less sense to also append additional values. But for map<key, list<val>> semantics, setting multiple at once makes complete sense.) |
| 05:42 | <annevk> | Headers is roughly key,list-val but still uses the same pattern |
| 05:43 | <annevk> | Although, maybe that’s not entirely true; it’s pretty special |
| 09:49 | <annevk> | Where did this gem originate from? https://twitter.com/antimattur/status/957912859127762945 |
| 17:09 | <wanderview> | JakeA: are you around? |
| 17:12 | <wanderview> | hmm, nm |
| 18:46 | <Domenic> | annevk: it came from https://twitter.com/mattur/status/957976107499905027 |
| 18:47 | <guest271314> | Hi |
| 18:50 | <guest271314> | Relevant to https://github.com/whatwg/fetch/issues/665, what is the purpose of passing a MIME type to toDataURL()? |
| 18:53 | <nox> | https://github.com/whatwg/fetch/issues/665#issuecomment-361333540 |
| 18:54 | <nox> | A data URL contains a MIME type, e.g. data:text/html,hello |
| 19:03 | <guest271314> | Does the toDataURL() concept ignore the validity of the MIME type as to the actual type of the input file? |
| 19:04 | <guest271314> | Is the validity of the data URL output not a concern of this particular processor, that is toDataURL()? |
| 19:34 | <annevk> | guest271314: Fetch is not defining the whole operation |
| 19:35 | <guest271314> | That does not answer the questions |
| 19:35 | <annevk> | guest271314: it would how to generate a data: URL string, that’s it |
| 19:35 | <annevk> | guest271314: the HTML spec would produce the relevant bits for the given MIME type |
| 19:37 | <annevk> | Domenic: yeah, saw that; I don’t really understand what’s going on |
| 19:39 | <guest271314> | What section of the HTML spec gets the MIME type of the file? If that is the case what is the purpose of passing a MIME type argument to toDataURL()? Or, am possibly misinterpreting the concept, here? That is, the HTML spec does get and set the MIME type internally, the user does not pass a MIME type as argument to the function; the function is not exposed to users at large? |
| 19:40 | <annevk> | The function is not exposed, no |
| 19:40 | <annevk> | The MIME type generator that is |
| 19:40 | <annevk> | data: URL generator* |
| 19:51 | <guest271314> | @annevk Where is the algorithm to get the MIME type from the input? |
| 19:52 | <annevk> | There is no such thing? |
| 19:54 | <guest271314> | annevk: Is that what https://github.com/whatwg/fetch/issues/665 is intended to achieve? |
| 19:55 | <annevk> | No |
| 19:56 | <guest271314> | Then what is the purpose and intended outcome of that issue? |
| 19:56 | <annevk> | It’s an algorithm to create a data: URL |
| 19:57 | <annevk> | Having that more clearly defined is the goal |
| 19:59 | <guest271314> | Ok. Although a MIME type is not required for a valid data URL the issue at some point will address the topic of getting the MIME from the input, yes? |
| 20:01 | <annevk> | No |
| 20:01 | <annevk> | There is no such thing |
| 20:01 | <annevk> | There is elsewhere in the platform, but not applicable here |
| 20:02 | <guest271314> | What is applicable here? |
| 20:02 | <annevk> | This only takes a MIME type so it can be in the generated data: URL |
| 20:02 | <annevk> | It’s basically passed through as-is |
| 20:03 | <guest271314> | Why omit validating that the MIME type matches the actual file type? Does that validation occur somewhere else in the procedure? Or, are developers on their own? |
| 20:04 | <annevk> | I’m gonna call it a day. Hopefully it’s clearer when the PR is written at some point |
| 20:08 | <guest271314> | annevk: Hope is meaningless. Though you have tried and am certain the contributors to the PR will perform due diligence. Cheers |
| 22:59 | <JakeA> | wanderview: on leave this week, but I can take a sneaky look at stuff from my phone |
| 23:04 | <jyasskin> | JakeA: No, bad Jake. Be on vacation! ;-) |
| 23:08 | <JakeA> | jyasskin: haha I've let my laptop run out of battery as a way to enforce holiday |