| 00:57 | <TabAtkins> | jyasskin: Sounds like what you want is the thing I'm calling a "ReactiveValue" in http://www.xanthir.com/b4PV0 |
| 00:58 | <TabAtkins> | An object Stream which exposes its current value synchronously. |
| 00:58 | <TabAtkins> | Object streams, uh, don't exist yet tho. |
| 01:02 | <wanderview> | TabAtkins: thats a great way to leak windows if someone send a DOM object through a stream |
| 01:50 | <TabAtkins> | Uh, no more so than literally any other way of communicating values? |
| 02:36 | <wanderview> | TabAtkins: it keeps the value around forever until another value is produced in the stream, no? I've seen this used carelessly to distribute "window closed" events which of course always leaked the last window that was closed |
| 02:37 | <wanderview> | I had to change our event channel things in our addon-sdk to hold their last value weakly to avoid these leaks: https://bugzilla.mozilla.org/show_bug.cgi?id=1267693 |
| 03:29 | <jyasskin> | TabAtkins: Yep, ReactiveValue<boolean> sounds right for this use case. The API needs to avoid sending values until someone subscribes though. |
| 03:34 | <jyasskin> | Although the API for ReactiveValue is bigger than I think would be useful for watching availability |
| 05:46 | <Domenic> | jyasskin: doesn't look great to me? In particular it seems like those would work better as something like PresentationAvailability.request("...").then(...)? But I dunno maybe in that domain there are actually two separate concepts of request and availability that are important, as seen by the start/reconnect methods? |
| 08:16 | <WisdomSky> | hi |
| 08:16 | <botie1> | hi, WisdomSky |
| 08:34 | <tobie> | Thoughts on dropping the " (Second Edition)" suffix from the Web IDL spec title? (Seems obvious to me—it should be a living standard—but there might be some backstory I'm not aware of here.) |
| 08:35 | <tobie> | ^ annevk |
| 08:36 | <tobie> | (as you're the only one awake right now.) |
| 08:36 | <annevk> | tobie: fine with me |
| 08:36 | <annevk> | tobie: the whole distinction never made much sense to me |
| 08:36 | <tobie> | ta |
| 08:36 | <tobie> | good |
| 08:37 | <annevk> | tobie: should also remove "Latest Version:" as it's not actually the latest version and maybe clean that header up in general |
| 08:37 | <tobie> | annevk: yeah, that's easier to do manually (there's a bunch of manual changed queued once all the automated things are done) |
| 08:37 | <tobie> | *changes |
| 08:38 | <annevk> | cool |
| 08:38 | <tobie> | nearly there |
| 08:38 | <annevk> | tobie: did someone get around to reviewing things yet? |
| 08:38 | <tobie> | oh yeah--heycam filed something like 30 issues |
| 08:38 | <annevk> | oh nice |
| 08:38 | <annevk> | that's very quick, excellent |
| 08:38 | <tobie> | well, that's a question of perspective |
| 08:38 | <tobie> | :D |
| 08:39 | <annevk> | heh |
| 08:40 | <tobie> | annevk: one of the last things I want to check it the dfn stuff you mentioned. |
| 08:41 | <tobie> | what precisely is the DOM spec relying on to do all of the linking to WebIDL? |
| 08:41 | <tobie> | annevk: does it map bikeshed behavior 1:1? |
| 08:42 | <annevk> | tobie: basically bikeshed has some kind of "dfn contract" |
| 08:42 | <annevk> | tobie: Shepherd, some "global" tool that indexes specs, uses that contract for cross-spec links |
| 08:42 | <annevk> | tobie: IDL implements that "dfn contract" for some terms today |
| 08:43 | <annevk> | tobie: other specs rely on IDL doing that |
| 08:43 | <tobie> | so if I go by: https://github.com/tabatkins/bikeshed/blob/master/docs/dfn-contract.md, I'm good? |
| 08:43 | <annevk> | tobie: yeah |
| 08:44 | <annevk> | tobie: the main thing that's important is that stuff that has data-dfn-for="" and such today, has data-dfn-for="" / for="" going forward |
| 08:44 | <tobie> | annevk: ok, that's informally what I followed. Just want to write a bunch of test that verifies this, now. Thanks. |
| 08:44 | <annevk> | tobie: note that in your source you can spell it the shorter for="", bikeshed should handle the rest |
| 08:44 | <annevk> | tobie: the other data-* also have shorthands |
| 08:45 | <annevk> | tobie: should all be specified in "dfn contract" |
| 08:47 | <tobie> | annevk: yes, I think I got those mostly right. There might be a couple of corner cases though. I'll write a bunch of tests. |
| 08:47 | <tobie> | Easier to fix them now than later. |
| 08:50 | <annevk> | On the other hand, will be much easier for folks to contribute with bikeshed |
| 09:44 | <zcorpan> | annevk: fyi https://github.com/plinss/widlparser/issues/17 |
| 10:54 | <annevk> | Ta |
| 10:54 | <annevk> | Could maybe use underscore hack, but… |
| 11:56 | <zcorpan> | mkwst: wonder why github is highlighting this? https://github.com/w3c/webappsec-csp/commit/bb49255376c3f485831c9ce90c710157cd12c507#diff-117d6498d2aa8019cc0abf5eeb87a9faR3513 |
| 11:57 | <mkwst> | Looks like I missed a `. https://github.com/w3c/webappsec-csp/commit/bb49255376c3f485831c9ce90c710157cd12c507#diff-117d6498d2aa8019cc0abf5eeb87a9faL3486 |
| 11:58 | <mkwst> | Somewhere. Or maybe GitHub is nuts? :) |
| 11:59 | <mkwst> | A problem is that this document really isn't HTML. It's mostly HTML. |
| 11:59 | <zcorpan> | looks like github's syntax highlighter is incredibly confused |
| 12:00 | <mkwst> | And HTML syntax highlighters aren't thrilled with the mix of markdown and HTML. |
| 12:00 | <mkwst> | Somewhere on my list is to go through the doc and consistently use the new bikeshedisms that have cropped up over the last year. |
| 12:04 | <mkwst> | I think the real issue here is that I have unclosed elements in the document on purpose. |
| 12:05 | <mkwst> | https://github.com/w3c/webappsec-csp/blob/master/index.src.html#L3441 <-- |
| 16:19 | <jyasskin> | mkwst: I think you could write that as < to unconfused github. |
| 16:20 | <jyasskin> | *unconfuse |
| 16:23 | <TabAtkins> | tobie: Ideally you convert down to the minimal Bikeshed representation - <dfn data-dfn-type=foo> just becomes <dfn foo>, all the other <dfn data-dfn-*="bar">s become <dfn *="bar">. |
| 16:24 | <TabAtkins> | If a data-dfn-* is on an ancestor of some <dfn>s, it converts down to dfn-* (have to be able to distinguish between the dfn-* and link-* set when it's not on a <dfn> or <a>). |
| 16:29 | <tobie> | TabAtkins: I think I got the first part mostly right. |
| 16:29 | <tobie> | I'm not sure I understand the second part nor it if applies to WebIDL. |
| 16:31 | <TabAtkins> | <dfn data-dfn-for=Foo>bar</dfn> can be written as <dfn for=Foo>bar</dfn> in Bikeshed. |
| 16:31 | <TabAtkins> | You *never* need to type a data- prefix for any of Bikeshed's attributes in an actual Bikeshed document. |
| 16:32 | <TabAtkins> | And for <dfn> and <a>, you can omit the whole data-dfn- and data-link- prefix, because it's obvious. |
| 16:36 | <tobie> | Yes. Got that part. What I didn't get: what are data-link- prefixes and how does the ancestor system works |
| 16:36 | <tobie> | TabAtkins: ^ |
| 16:37 | <TabAtkins> | Oh, autolinking technically runs off of data-link-* attributes, identical to the data-dfn-* attributes. You just never see them, because they're *only* useful in Bikeshed documents, where you never have to write them. ^_^ |
| 16:37 | <TabAtkins> | But you can put the dfn/link attributes on an ancestor element and they'll apply to all the <dfn>/<a> descendants (unless overridden). |
| 16:38 | <TabAtkins> | And when you do so, you can omit the data- prefix, but need to keep the dfn- or link- part (so you can put both <dfn> and <a> in a block and not have them both receive the same defaults, as that's rarely useful). |
| 16:39 | <tobie> | OK, I get it. |
| 16:43 | <tobie> | TabAtkins: if you read XSLT: https://github.com/tobie/webidl/blob/c84a0f7/WebIDL-bs.xsl#L350-L382 |
| 16:43 | <tobie> | I think that covers all but the ancestor cases. |
| 16:44 | <TabAtkins> | Looks good to me. |
| 16:44 | <tobie> | Which I think WebIDL doesn't have (but will check). |
| 19:26 | <smaug____> | mounir: ping |
| 20:56 | <jyasskin> | Domenic: I'm translating the Presentation pattern to "navigator.bluetooth.getAvailability()..then(avail => ...)", and then avail.value holds whether the user has any bluetooth adapter at all. Are you suggesting that we should put a requestBluetooth() function in front of requestDevice(), and have it fail if there's no adapter? How would it behave if the user |
| 20:56 | <jyasskin> | then unplugged the adapter? Or plugged the first one in? |
| 20:58 | <Domenic> | jyasskin: I don't really understand the second idea, so it's probably not what I'm suggesting :) |
| 20:59 | <Domenic> | jyasskin: To me the biggest question is whether availability needs to be its own class (with a .value property) or not. The weird thing in the presentation API was separate request and availability classes |
| 20:59 | <jyasskin> | :) If Presentation spelled their thing PresentationAvailability.request("...").then(...), how would folks sign up to be notified if availability changed? |
| 21:00 | <Domenic> | I think I see. Putting it on whatever their "navigator.bluetooth" is seems reasonable to me. |
| 21:00 | <Domenic> | navigator.bluetooth.onavailable = ..., or even navigator.bluetooth.whenAvailable.then(...) |
| 21:01 | <jyasskin> | With just onavailable, how do we get the initial value? |
| 21:02 | <jyasskin> | whenAvailable as a Promise doesn't work well because we also want to eagerly say "no" if no adapter's available. |
| 21:02 | <jyasskin> | We could do a Promise<boolean> and put the onavailable at the top level. |
| 21:02 | <Domenic> | jyasskin: yeah that last is what I was thinking |
| 21:03 | <Domenic> | This is indeed, as Tab mentioned, an instance of a more general concept we see a lot |
| 21:03 | <Domenic> | inputEl.value/inputEl.oninput, etc. |
| 21:03 | <jyasskin> | Ok, I'll follow https://xkcd.com/927/ and do what you're suggesting. :) |
| 21:03 | <Domenic> | I guess the question is whether this should be a synchronous getter or promise getter for the initial thing |
| 21:04 | <jyasskin> | We want a promise getter for the initial thing so we don't have to send it to every renderer. |
| 21:05 | <jyasskin> | With the event, I think we need a new event type so it can transmit the value? I don't really want to make folks do getAvailability().then(...) inside the event handler. |
| 21:06 | <Domenic> | Seems true... I'm a little surprised we don't have a generic ValueEvent, ick. |
| 21:11 | <jyasskin> | I can specify ValueEvent in WebBT. ;) |
| 21:11 | <jyasskin> | Domenic or TabAtkins: do you know of any frameworks that have implemented this pattern? I think what we really want is a kind of event listener that's guaranteed to fire with an initial value. TabAtkins' ReactiveValue has a whole bunch layered on top of that, but we don't really need the complexity. |
| 21:12 | <TabAtkins> | I mean, th epoint of having a stream is that there's a ridiculous amount of great stuff you can do with the combinators once you get a good ecosystem going. Same with promises - any individual usage is typically okay with something smaller than a Promise. |
| 21:12 | <TabAtkins> | Benefit is that the value/time dependency is reified and manipulable. |
| 21:12 | <Domenic> | jyasskin: not really; people usually use something more general and just shoehorn this in. They are called "signals" in https://github.com/kriskowal/gtor/ and in my presentation https://vimeo.com/132786072 |
| 21:17 | <jyasskin> | That's fair. I'm worried about specifying too much up front, especially in a spec that's not specifically focused on reactivity primitives. What's the minimum subset? Just availability.forEach(callback), where callback is guaranteed to be called once with the current value? |
| 21:18 | <Domenic> | oof, I would not... I would just specify ValueEvent, onavailable, and getAvailability().then(aBool => ...) |
| 21:18 | <jyasskin> | Domenic: SGTM |
| 21:45 | <TabAtkins> | Yeah, I'd def stay simple with this until we get something useful actually specced. |
| 22:26 | <jyasskin> | TabAtkins: Somehow [[!DOM#constructing-events]] is producing the text "DOM Standard §constructing-events" despite https://dom.spec.whatwg.org/#constructing-events. I think DOM's in Shepherd. Have I done something dumb? |
| 22:27 | <jyasskin> | (That should be "[[DOM#constructing-events]]") |
| 22:27 | <TabAtkins> | Oh phew, I was like "how the HELL" |
| 22:27 | <TabAtkins> | And no, probably not your fault. Doing some final testing on something right now, will get to this in a sec. |
| 22:27 | <jyasskin> | TabAtkins: Thanks! |
| 22:28 | <TabAtkins> | (I noticed something similar on a CSSWG spec today.) |
| 22:32 | <jsbell> | Do we have a "Encodings for web standards dorks" doc that explains JS's strings are 16-bit code units (and JS's various string/character handling FUNctions), DOMStrings are 16-bit clean not UTF-16, fun edge cases to be aware of, when USVString is appropriate, etc etc? I think our collected knowledge is just strewn across notes in places like WebIDL and TAG notes, but maybe someone's consolidated it? |
| 22:33 | <jsbell> | Told a new developer "make sure to test with \uDC00\uD800" and he found a bug in Firefox. :P |
| 22:46 | <jyasskin> | TabAtkins: Could you add https://w3c.github.io/fingerprinting-guidance/ to Shepherd? |
| 22:47 | <botond> | TabAtkins: what does a bright pink highlight mean in a Bikeshed source? |
| 22:47 | <TabAtkins> | jsbell: https://simonsapin.github.io/wtf-8/ ? |
| 22:47 | <jsbell> | TabAtkins: That too. :) |
| 22:47 | <TabAtkins> | botond: I just use it for highlighting headings, to make the section breaks more obvious in the Sublime minimap. |
| 22:49 | <botond> | TabAtkins: but not markdown-style headings, apparently |
| 22:49 | <TabAtkins> | Yeah, as I said the other day, I haven't updated the highlighting styles in a long while. Latest revision predates markdown-style headings being valid. |
| 22:53 | <TabAtkins> | jyasskin: Done. Give it a few for those to filter into the db. |
| 22:53 | <jyasskin> | TabAtkins: Thanks! |
| 23:24 | <TabAtkins> | Aw dang, Status metadata now emits a proper error message when you're in a new group and try to use a W3C status. |
| 23:25 | <TabAtkins> | This was a lot of work, but it's *super* helpful to the user now, which makes me happy. The previous failure state was terrible and confusing. |