| 02:27 | <MikeSmith> | Domenic: > Otherwise a network attacker could trick browser vendors into implementing CORS wrong |
| 02:27 | <MikeSmith> | isn’t that what we /TR is for? |
| 02:27 | <MikeSmith> | (rimshot) |
| 06:52 | <mathiasbynens> | littledan__: Looks like Yang already answered while I was asleep. The TL;DR is https://mathiasbynens.be/notes/es6-unicode-regex#impact-i which is admittedly very subtle in the spec |
| 06:53 | <mathiasbynens> | littledan__: Thanks for the heads-up! Don’t hesitate to CC me on bugs like this. |
| 08:40 | <Ms2ger> | annevk, hey |
| 08:40 | <annevk> | MikeSmith: SW kinda depends on Fetch and HTML though, which is why it often comes up here, not too standalone I'd say |
| 08:41 | <Ms2ger> | Is it safe to pass a DOMString to https://encoding.spec.whatwg.org/#utf-8-encode ? |
| 08:42 | <MikeSmith> | annevk: I meant standalone in terms of having started from slightlyoff’s own github account rather than a particular org |
| 08:43 | <annevk> | Ms2ger: no |
| 08:43 | <annevk> | Ms2ger: encoding library is expects scalar values |
| 08:43 | <annevk> | s/is// |
| 08:44 | <annevk> | MikeSmith: oh |
| 08:44 | <slightlyoff> | MikeSmith: had it been available at the time, we'd have used WICG instead of my private github repo |
| 08:44 | <slightlyoff> | and we are using the W3C process |
| 08:44 | <MikeSmith> | ok |
| 08:45 | <Ms2ger> | I suspected as much |
| 08:45 | <Ms2ger> | https://github.com/whatwg/html/issues/970 |
| 11:57 | <annevk> | mounir: any plans to update the Permissions API? |
| 11:58 | <annevk> | mounir: and maybe provide a PR for Notifications API so they're actually linked and use the same permission store? |
| 11:58 | <annevk> | mounir: none of the issues I raised a year ago have moved much it seems, that's not very encouraging |
| 11:58 | <annevk> | mounir: I'm now trying to fix some outstanding issues with Storage, and the Permissions API spec is still in a broken state |
| 12:04 | <annevk> | TabAtkins: Shepherd should start indexing https://w3c.github.io/permissions/ |
| 12:32 | <JakeA> | annevk: I guess storage also includes the service worker registration? |
| 12:47 | <mounir> | annevk: jyasskin has been helping recently, I think he might have a few PR you would be interested in |
| 12:47 | <mounir> | annevk: sorry for the slow progress, it's a side project |
| 12:59 | <annevk> | JakeA: yeah it must |
| 12:59 | <annevk> | JakeA: we need to make sure all storage stuff like that is layered on top of this, so that box operations affect all of them at once |
| 13:00 | <annevk> | JakeA: and we need to also make it clear which things are distinct |
| 13:00 | <annevk> | JakeA: e.g., permissions and credentials are clearly stored separately |
| 13:01 | <JakeA> | Hadn't considered that about permissions, but yeah, makes sense |
| 13:32 | <annevk> | JakeA: mentioned them in https://storage.spec.whatwg.org/#infrastructure |
| 13:59 | <JakeA> | perfect, cheers! |
| 14:03 | <annevk> | I wonder if an email client can detect an out-of-office email and forward those to trash |
| 14:04 | <annevk> | E.g., I have a hard time caring mkwst will not reply to my email today, even though he just replied to the same thread |
| 14:04 | <mkwst> | Hrm? |
| 14:04 | <annevk> | mkwst: I got an autoresponder from you |
| 14:05 | <mkwst> | Hrm. That should be off. I got back in this morning. |
| 14:05 | <mkwst> | Off now. Sorry. Off by one. :/ |
| 14:06 | <mkwst> | What email do you have a hard time caring about? |
| 14:06 | <mkwst> | Sorry. I've been out for a week, and I'm not at all on top of things. |
| 14:06 | <mkwst> | (If you're missing something from me, tell me. :) ) |
| 14:07 | <annevk> | mkwst: just your autoresponder emails, I care about the others |
| 14:07 | <mkwst> | You don't have a deep desire to know whether or not I'm on vacation? |
| 14:08 | <mkwst> | I thought that was a universal human need. |
| 14:08 | <annevk> | mkwst: that explains why you work for Google |
| 14:08 | <mkwst> | No, Google wants to know whether _you_ are on vacation. |
| 14:10 | <jgraham> | Eventually gmail will just automatically provide autoresponder emails like "Sorry, mkwst is by a pool in Vegas right now. He lost $10,000 this morning and so won't be responding to your email soon." |
| 14:12 | <mkwst> | Delighting users, one autoresponder at a time. |
| 14:30 | <TabAtkins> | annevk: ReSpec'd, so all the definitions are worthless. Every one of them will be a "dfn"-type definition, unexported. And they duplicate several terms from other specs (luckily those are unexported too). |
| 14:37 | <annevk> | TabAtkins: hmm, maybe jyasskin can convert it to bikeshed |
| 14:39 | <jyasskin> | annevk: I won't override the editors on that, but I am volunteering to help edit Permissions, in which case converting to Bikeshed is the price. |
| 14:41 | <annevk> | jyasskin: since "the editors" haven't been doing much for a year I think you should be fine |
| 14:41 | <jyasskin> | annevk: https://github.com/w3c/permissions/pull/66 has the basics for extending permissions from other specs. I'm just assuming the "partial enum" problem is solved. |
| 14:42 | <annevk> | jyasskin: I don't care much about that, I actually think it's better if permissions is the registry so it keeps a coherent view on all permissions |
| 14:42 | <annevk> | jyasskin: what I mostly care about is primitives to hook into around the permission storage that actually work, i.e., that take a permission name and an origin, and things like that |
| 14:43 | <jyasskin> | https://rawgit.com/jyasskin/permissions/allow-choosers/index.html#dfn-get-a-permission-storage-identifier takes a name and a settings object. |
| 14:45 | <annevk> | jyasskin: that looks a little better |
| 14:45 | <annevk> | jyasskin: are you actively working on this? If that's the case I'm happy to review tomorrow |
| 14:45 | <jyasskin> | I'm looking at this as an incremental improvement. There's a bunch left to fix, but I can't tackle it all in one PR. |
| 14:46 | <jyasskin> | Yes. |
| 14:46 | <annevk> | Yeah understood |
| 14:47 | <jyasskin> | What do you suggest I do to get commit access? Mail you, mounir, marcos, and Dom? |
| 14:48 | <annevk> | jyasskin: MikeSmith can usually arrange that |
| 14:48 | <annevk> | jyasskin: no need to email me, I don't have power in /w3c |
| 14:48 | <jyasskin> | I'd mail you for the endorsement. ;) |
| 14:48 | <annevk> | hah |
| 15:22 | <zcorpan> | i might be able to give you commit access |
| 15:28 | <TabAtkins> | jyasskin: It doesn't need to be fully Bikeshedded, just have its definitions upgraded. But Bikeshedding is always nice, of course. ^_^ |
| 15:29 | <jyasskin> | Bikeshedding makes everything so much easier. |
| 15:30 | <annevk> | Including reviewing the document, ReSpec still FOUCs |
| 15:31 | <MikeSmith> | jyasskin: made you a pusher |
| 15:31 | <jyasskin> | MikeSmith: Thanks! |
| 15:31 | <MikeSmith> | cheers |
| 15:47 | <jyasskin> | TabAtkins: You don't have any tidy-like tool for .bs files, do you? |
| 15:48 | <TabAtkins> | No, but I've been wanting to design one. |
| 15:48 | <TabAtkins> | Feel free to open an issue on me with some suggestions for things you want linted/formatted. |
| 16:48 | <annevk> | jyasskin: btw, I think ideally we have fairly simple hooks here |
| 16:49 | <annevk> | jyasskin: e.g. "If permission for "notification" and /notication/'s origin is "granted", ..." with "permission" being something you define |
| 16:50 | <annevk> | (sorry about the double " quotes) |
| 16:50 | <jyasskin> | "permission" being something the notification API defines, or the permissions API? |
| 16:50 | <annevk> | jyasskin: the permissions API |
| 16:51 | <annevk> | jyasskin: ideally the Notifications API no longer has to define "permission" at all, since it can defer to the Permissions store for that now |
| 16:51 | <jyasskin> | annevk: We have enough kinds of permission, and enough data associated with permissions, that I'm not sure there can be a single unified definition. The ones that are simply boolean should definitely be able to just reference Permissions, but others are more complex. |
| 16:52 | <annevk> | jyasskin: yeah, I guess this would only work for the simple ones |
| 16:52 | <annevk> | jyasskin: and for the others you'd have to do something complex, although I'm still not entirely convinced more complex ones are a good idea |
| 16:53 | <jyasskin> | annevk: My example here is Bluetooth, of course. If we want it to fit into the API, we need to be able to store a list of devices, and be able to query that list. |
| 16:53 | <jyasskin> | It looks like media was already going that direction in the spec, but without any rigor. |
| 16:54 | <annevk> | too many editors that don't care about design |
| 16:55 | <jyasskin> | Eh, whatever the cause, we have to look for the right design now. |
| 16:55 | <annevk> | or maybe they don't care about details? It's not entirely clear to me what's missing, but there's certainly lots of messes being created at all times, and few bineg solved |
| 16:55 | <annevk> | being* |
| 16:56 | <annevk> | jyasskin: but yeah, if we could have a very basic get/set framework for boolean permissions that'd be great |
| 16:57 | <annevk> | jyasskin: although maybe I should first review your work, since it seemed you had some interesting things around cleanup and such too |
| 16:57 | <jyasskin> | Mhmm. Right now, I have https://rawgit.com/jyasskin/permissions/allow-choosers/index.html#geolocation and friends explicitly specify the whole permission interface, but it'd be easy to define a "boolean permission" shorthand for them. I was waiting to see how many there actually were. |
| 16:58 | <annevk> | There's also some potential disagreement |
| 16:58 | <annevk> | E.g. I think "persistentstorage" is boolean, but I don't think everyone at Google agrees |
| 17:13 | <jyasskin> | annevk: This inclines me more toward letting individual specs define their own permissions, instead of trying to centralize those debates through the Permissions editor. |
| 17:13 | <jyasskin> | Having the enum centrally, and then link to the definitions in each spec, could work well. |
| 18:05 | <annevk> | Yeah, maybe |
| 18:05 | <annevk> | Depends a bit on the particulars I suppose |
| 19:38 | <annevk> | TabAtkins: it seems that lacking a newline after <pre><code class="lang-javascript"> actually influences parsing: https://storage.spec.whatwg.org/#introduction |
| 19:38 | <annevk> | TabAtkins: if I add a newline locally the wrapping is correct |
| 19:38 | <TabAtkins> | It absolutely does. Bikeshed is very opinionated about the structure of your <pre>, so it can tell in a reasonable way what you "indent" is, and correct it in the output HTML. |
| 19:39 | <annevk> | (with the if statement appearing on the next line, and "navigator.storage.persistent()," too) |
| 19:39 | <annevk> | That seems very wrong |
| 19:39 | <TabAtkins> | That way you don't have to put your <pre> contents flush with the left edge, messing up your HTML indentation, like you have to do in normal HTML. |
| 19:39 | <annevk> | Oh well |
| 19:40 | <TabAtkins> | It's not wrong. It's a particular choice to make sure your input documents look good; without it, your input documents contain ugly formatting hacks that aren't necessary *anywhere else* in HTML. |
| 19:40 | <annevk> | I wish bikeshed would use custom elements for this kind of stuff |
| 19:40 | <TabAtkins> | You either lack indentation, or use funky comment hacks, both of which are terrible. |
| 19:40 | <annevk> | Changing the meaning of existing HTML elements is super confusing |
| 19:41 | <TabAtkins> | Perhaps easier to put yourself in the mindset that Bikeshed's input format is not, technically, HTML, but a language close to it. ^_^ |
| 19:41 | <TabAtkins> | (People are generally *happy* when they run into this bug, because as soon as they learn the *right* thing, they can start formatting their <pre> contents *naturally* instead of the hacky bullshit way they were doing so previously.) |
| 19:42 | <TabAtkins> | (This is something I should lint for, tho.) |
| 19:42 | <jyasskin> | More, happy once we've gotten used to it and realize the benefits. We're all grumpy when we hit it the first time. I think I filed a bug. |
| 19:42 | <annevk> | All I want is a maintained Anolis with automatic xref... |
| 19:42 | <annevk> | I don't really have a need for all this magic that bites me every time |
| 19:43 | <annevk> | But it's easy enough to get used to adding a newline |
| 19:44 | <TabAtkins> | I really am genuinely sorry you got really used to the mannerisms of a preprocessor nobody's willing to use anymore. |
| 19:46 | <annevk> | Well the thing is, Anolis is basically HTML, no magic |
| 19:46 | <annevk> | And Wattsi is quite similar |
| 19:46 | <TabAtkins> | Most users are new to this stuff, so it's easier for them to learn. Less things to unlearn. |
| 19:46 | <TabAtkins> | I'm def sympathetic. |
| 19:46 | <TabAtkins> | (Your willingness to work with Anolis-style xrefs was truly heroic, they're a *ton* of typing.) |
| 19:46 | <annevk> | It's mostly bikeshed I think that parses Markdown before HTML and such |
| 19:47 | <annevk> | Typing isn't really the work though when writing specs |
| 19:48 | <jyasskin> | It's not really the work in programming either, but we still look for concise languages. |
| 19:49 | <annevk> | True, I think actually ecmarkup might be even better than bikeshed, but it probably lacks cross-spec cross-references |
| 19:49 | <TabAtkins> | Like, typing isn't the WORK work, but it's still a lot of work, and minimizing that is ideal. |
| 19:49 | <TabAtkins> | I think Domenic passes things through both Bikeshed *and* ecmarkup? I've got plans for integrate ecmarkup's shorthands when I have some downtime. |
| 19:50 | <annevk> | And I think we want something ecmarkup like long term given that's what ECMAScript is in and everything else descends from that, in a way |
| 19:50 | <annevk> | TabAtkins: yeah, Domenic has some special setup for Streams |
| 19:50 | <annevk> | Maybe the future is there somewhere |
| 19:50 | <TabAtkins> | "All specs should be like ECMAScript" is something that very few people would be able to get behind, I think. The precision is nice, but it's *impossible* to read unless you're deeply skilled in spec-ese. |
| 19:51 | <annevk> | And yeah, definitely want to explore this a bit too at some point, maybe after shadow DOM / custom elements |
| 19:51 | <TabAtkins> | But anyway, nothing good about ECMAScript is related to the processor. |
| 19:52 | <TabAtkins> | annevk: All I care about is that any new processors people work on, interoperate in their definitions model. |
| 19:52 | <annevk> | TabAtkins: 1) I think ECMAScript is getting better 2) We'd still have IDL to help us out, just in a more ECMAScript-y way |
| 19:52 | <annevk> | TabAtkins: yeah, should maybe see if we can make some easy wins with Wattsi with respect to that |
| 19:52 | <TabAtkins> | https://github.com/tabatkins/bikeshed/blob/master/docs/dfn-contract.md is the dfn contract |
| 19:53 | <annevk> | Anyway, bedtime, ttyl |
| 19:53 | <jyasskin> | TabAtkins: Is there a spec for the API to query the dfn database? |
| 19:53 | <TabAtkins> | bikeshed refs --help |
| 19:54 | <jyasskin> | Hm, for another tool to use? I guess that's https://api.csswg.org/shepherd/ |
| 19:54 | <TabAtkins> | Ah, tool-usable. |
| 19:55 | <jyasskin> | My thought is that ecmarkup or Anolis should be able to query the same database. |
| 19:55 | <TabAtkins> | Yeah, that's it. Note that Bikeshed does a *bunch* of post-processing on that data. |
| 19:55 | <TabAtkins> | jyasskin: Yeah, everyone sharing the same db is what we want. |
| 19:56 | TabAtkins | is still considering taking over the spidering in an independent project, a la SpecRef, so people can see it more easily and help out. |
| 19:58 | <TabAtkins> | Off to lunch, bbiab if this discussion continues. |
| 20:03 | <Domenic> | FWIW I'm currently (between TC39 speeches) trying to make Streams use more Bikeshed features. We'll see how well that integrates with the ecmarkup parts... |
| 20:04 | <Domenic> | As of this morning it basically only used <dfn>s and <a>s to link between them. Now trying to mark up classes/constructors/methods/properties and {{link}} to them and such. |
| 20:58 | <zcorpan> | I use f.lux which makes the screen emit less blue light in the evenings, which is nice but it also makes me kinda colour blind: links in whatwg specs look exactly like the surrounding text |
| 21:00 | <zcorpan> | that seems like something we should fix. not just for me but also for people who are actually color blind |
| 21:35 | <Domenic> | TabAtkins: if I add {{EventTarget}} in an example section I get a normative reference to DOM. How can I make it non-normative? |
| 21:36 | <TabAtkins> | Domenic: Hm, if it has a parent with class=note or class=example, it should get marked as non-normative. |
| 21:36 | <Domenic> | TabAtkins: it doesn't though; it has a nearby <p><em>This section is non-normative.</em></p> |
| 21:37 | <TabAtkins> | Ah, so I"m not looking for that yet. I'm open to increasing the set of things that it looks for, as long as we can do so safely. |
| 21:37 | <TabAtkins> | Would you be opposed to adding a class to the heading, for example? |
| 21:38 | <Domenic> | TabAtkins: yeah that'd be OK... I'd also accept <a idl nonnormative> or something |
| 21:38 | <TabAtkins> | (The warnings you mention aren't safe; it's not clear how large their scope is in a machine-detectable way.) |
| 21:38 | <TabAtkins> | Yeah, I can just expand it to look for a class="non-normative" on it or an ancestor, if you want. |
| 21:39 | <Domenic> | 👍 |
| 21:39 | <Domenic> | I'll file an issue? |
| 21:40 | <TabAtkins> | No need, committing now. |
| 21:40 | <Domenic> | \o/ |
| 21:40 | <Domenic> | TabAtkins: also is there a way to turn off ignored vars checking? I couldn't find it in the docs. |
| 21:40 | <TabAtkins> | Entirely? Not right now, no. |
| 21:56 | <jochen__> | does somebody know why the payments API uses "objects that can be passed through JSON.parse(JSON.stringify()) without loss of data instead of SerializedScriptValue? |
| 22:02 | <TabAtkins> | Lack of knowledge? |
| 22:03 | <Mek> | I don't think SerializedScriptValue is a thing in specs. You probably meant structured cloneable? |
| 22:04 | <Mek> | but I was wondering the same thing, and guessed that it might be because that data gets passed to possibly external native code, which is easier with json rather than arbitrary structured cloneable data |
| 22:04 | <Mek> | but the spec could still allow more, since the various payment providers will have to define their own valid subset of data anyway |
| 22:08 | <jochen__> | well, it's a thing in IDL, isn't it? |
| 22:09 | <Mek> | I don't think so |
| 22:09 | <jochen__> | mhm |
| 22:10 | <jochen__> | so whatever it is in spec-speak, afaik all browsers can serialize the history.state object to disk |
| 22:10 | <Mek> | at least HTML uses "any" in IDL and "StructuredCloneWithTransfer" for postMessage |
| 22:10 | <jochen__> | and that's a SerializedScriptValue in Blink & WK |
| 22:11 | <jochen__> | ok, fair enough |
| 22:11 | <Mek> | same for history.state |
| 22:12 | <Mek> | but yes, I agree that payment request should use any/structured cloneable in the spec (although the implementation in blink will likely still not be able to use SerializedScriptValue due to implementation details of SerializedScriptValue) |
| 22:20 | <Domenic> | It depends on if they ever want to e.g. send something over HTTP |
| 22:20 | <Domenic> | In which case structured-cloneable doesn't make sense |
| 22:25 | <jochen__> | dunno |
| 22:26 | <jochen__> | if you want a wire format, you should specify a wire format |
| 22:27 | <Domenic> | JSON seems good |
| 22:27 | <jochen__> | i'm not saying it's not |
| 22:28 | <jochen__> | it's just odd that the wire format is defined implicitly by messing with the IDL |
| 22:53 | <Domenic> | TabAtkins: given https://github.com/whatwg/streams/blob/better-spec-hygeine/index.bs#L34-L43 I cannot figure out why %Uint8Array% and friends appear in the index at https://streams.spec.whatwg.org/commit-snapshots/62d8cae22d91df2626c50ae3238e077d6b583dad/#index-defined-elsewhere, but WebSocket does not? |
| 22:58 | <Domenic> | Hmm structured clone also isn't showing up |
| 23:01 | <TabAtkins> | Domenic: That... is a good question. |
| 23:01 | <TabAtkins> | Log an issue? |
| 23:01 | <Domenic> | yeah |
| 23:05 | <TabAtkins> | Domenic: Oh, those anchors don't have a "spec" declared. |
| 23:05 | <Domenic> | TabAtkins: hmmm is this because of the conflicting definitions from different specs things? |
| 23:05 | <Domenic> | i.e. why does ES not have this problem |
| 23:05 | <TabAtkins> | Because you specified "spec" for those anchors. |
| 23:06 | <TabAtkins> | Line 37 |
| 23:06 | <Domenic> | TabAtkins: oh, duh, ok thanks! |
| 23:06 | <TabAtkins> | There's still something weird/unusable here. I'll need to figure out what needs doing. |