| 03:59 | <xfq> | the "Participate" and "Tests" headers of the DOM Standard look weird |
| 03:59 | <xfq> | there are unclosed parens |
| 03:59 | <xfq> | is it a known issue? |
| 04:10 | <MikeSmith> | xfq: hmm yeah, something broken there |
| 04:13 | <MikeSmith> | maybe a regression in bikeshed |
| 04:13 | <MikeSmith> | the source just has this: |
| 04:13 | <MikeSmith> | !Participate: <a href=https://github.com/whatwg/dom>GitHub whatwg/dom</a> (<a href=https://github.com/whatwg/dom/issues/new>new issue</a>, <a href... |
| 04:14 | <MikeSmith> | !Tests: <a href=https://github.com/w3c/web-platform-tests/tree/master/dom>web-platform-tests dom/</a> (<a href=https://github.com/w3c/web-platform-tests/... |
| 04:16 | <MikeSmith> | ,,, |
| 04:16 | <MikeSmith> | and I can’t reproduce it locally |
| 04:16 | <MikeSmith> | but then my bikeshed isn’t the latest |
| 04:21 | <MikeSmith> | hmm just updated my bikeshed to the latest but I still can’t reproduce this |
| 04:21 | <MikeSmith> | xfq: file a DOM spec bug? |
| 05:35 | <xfq> | MikeSmith: Infra (13 September 2017) also has this issue, but URL (18 September 2017) doesn't |
| 05:35 | <MikeSmith> | interesting |
| 05:36 | <MikeSmith> | I have no idea what the cause might be |
| 05:36 | <MikeSmith> | maybe annevk will |
| 05:36 | <xfq> | the closest issue I can find is: https://github.com/tabatkins/bikeshed/issues/1097 |
| 05:36 | <annevk> | Bikeshed issue |
| 05:37 | <annevk> | We just need to generate new copies |
| 05:37 | <xfq> | so just triggering Travis will solve this issue? |
| 05:38 | <annevk> | I suspect so |
| 05:38 | <TabAtkins> | Yup, dom just happened to last generate in the few hours when the bug was present. |
| 05:38 | <annevk> | I can look at it in a couple of hours |
| 06:54 | <annevk> | Domenic: are worklets JavaScript modules? |
| 06:54 | <annevk> | Domenic: I wonder if we resolved that already |
| 07:10 | <annevk> | We did: https://drafts.css-houdini.org/worklets/ |
| 08:06 | <annevk> | JakeA: would be good to have a thumbs up/down from you on https://github.com/whatwg/fetch/pull/527 |
| 08:06 | <annevk> | JakeA: mostly about the service worker selection for worklets part |
| 08:07 | <annevk> | jungkees: same goes for you, if you have the time |
| 08:08 | <jungkees> | annevk: thanks for the notice. I'll check it out |
| 08:34 | <JakeA> | looking now |
| 08:56 | <annevk> | mkwst: I guess you're okay with https://github.com/whatwg/fetch/pull/527 going with distinct destinations for the different worklet types? |
| 08:56 | <annevk> | mkwst: it seems a little safer to just mark them differently from the outset |
| 09:15 | <mkwst> | annevk: Yes. Totally fine with that. We can always reduce granularity in the future if we feel the need, but starting with more specific data seems right. |
| 10:21 | <nox> | In https://html.spec.whatwg.org/multipage/media.html#concept-media-load-algorithm, |
| 10:21 | <nox> | Shouldn't the step '⌛ Otherwise the media element has no assigned media provider object and has neither a src attribute nor a source element child: set the networkState to NETWORK_EMPTY, and abort these steps; the synchronous section ends.' also set the delaying-the-load-event flag back to false? |
| 10:24 | <annevk> | foolip: ^^ |
| 10:27 | <JakeA> | Btw, TabAtkins landed <script type=idl> in Bikeshed which avoids the need to escape < & >. Also works better with syntax highlighting |
| 10:27 | <JakeA> | https://tabatkins.github.io/bikeshed/#idl |
| 10:27 | <gsnedders> | hmm, who do we know who is still at Opera and can help us find stuff? both test-related (either by finding stuff around or in VCS history or bugs) and looking up bugs? |
| 10:28 | <foolip> | nox: yes, that would make sense, can you file an issue? |
| 10:28 | <nox> | foolip: Ok. |
| 10:29 | <annevk> | gsnedders: bratell/jl? |
| 10:29 | <annevk> | gsnedders: mstensho? |
| 10:30 | <annevk> | gsnedders: rune |
| 10:30 | <gsnedders> | ah, true, they're all still there |
| 10:31 | <nox> | foolip: https://github.com/whatwg/html/issues/3065 |
| 10:39 | <nox> | foolip: Failing to set it back to false in Servo made /html/semantics/embedded-content/media-elements/loading-the-media-resource/resource-selection-invoke-play.html timeout, |
| 10:39 | <nox> | and I don't really understand why, hah. |
| 10:40 | <nox> | Do tests time out if we don't fire the load event, in general? |
| 10:55 | <JakeA> | annevk: what's the correct way to hook an event handler up to its associated event? |
| 10:55 | <JakeA> | I've seen it done a few different ways |
| 10:55 | <JakeA> | And none of them are done in https://dom.spec.whatwg.org/#aborting-ongoing-activities, so I should fix that |
| 11:12 | <jungkees> | annevk: a dictionary object passed from JS also has its own realm, right? |
| 11:13 | <jungkees> | annevk: if I want to pass that onto an algorithm goes in parallel, would it be a good practice to convert it to a internal struct? Or would just passing it as-is be okay? |
| 11:17 | <Ms2ger> | I don't know if ES already defines the realm for arbitrary objects |
| 11:18 | <gsnedders> | nox: testharness.js tests? |
| 11:31 | <annevk> | jungkees: it’s converted to an IDL dictionary at the boundary which has no Realm so should be fine |
| 11:32 | <nox> | gsnedders: Yes. |
| 11:33 | <annevk> | jungkees: the only somewhat weird thing is passing dictionaries across "in parallel" boundaries |
| 11:34 | <annevk> | jungkees: I think that should be okay, provided you don't mutate it, but at some point we need to document how that works |
| 11:37 | <gsnedders> | nox: no, it shouldn't matter |
| 11:38 | <jungkees> | annevk: yeah, currently "run a worker" also takes a dictionary from the main thread and access it inside the worker thread |
| 11:38 | <nox> | gsnedders: Well, that is weird then. |
| 11:39 | <nox> | gsnedders: /html/semantics/embedded-content/media-elements/loading-the-media-resource/resource-selection-invoke-play.html times out locally if I don't account for https://github.com/whatwg/html/issues/3065 |
| 11:40 | <nox> | And it's not a test case that times out, but the whole test. |
| 11:40 | <annevk> | jungkees: ah, good to know |
| 11:41 | <annevk> | jungkees: I suspect we don't want to formalize it too much right now, first figure out what all the various usage patterns will be and what kind of issues arise |
| 11:41 | <annevk> | jungkees: still very early days for "in parallel" |
| 11:41 | <gsnedders> | nox: will look in a few mins |
| 11:41 | <jungkees> | annevk: okay. I don't think there are many cases for dictionary indeed |
| 11:42 | <jungkees> | annevk: a tricky part that I encountered is.. I'd want to pass a struct to an internal algorithm |
| 11:43 | <jungkees> | annevk: and that struct should somehow carry information in a dictionary given from JS |
| 11:44 | <jungkees> | annevk: I'm not sure if I can set an item in a struct to a dictionary itself. Would that make sense? |
| 11:44 | <jungkees> | annevk: otherwise, I'll need to convert the dictionary to a struct only for a reason to pass that along |
| 11:44 | <annevk> | jungkees: that's fine |
| 11:45 | <jungkees> | annevk: sounds good :) |
| 11:45 | <annevk> | jungkees: again, at some point we should be more clear on the rules and all the various types, but structs holding IDL types should be okay |
| 11:45 | <jungkees> | annevk: okay |
| 11:51 | <gsnedders> | nox: how much is this blocking you btw? |
| 11:53 | <nox> | gsnedders: It's not. I'm just very confused why it would happen. Pay me no mind. |
| 11:55 | <gsnedders> | nox: ack |
| 15:17 | <wanderview> | JakeA: sorry if I'm being confusing... I don't really want FetchEvent to be a unique snowflake... but I thought there were objections from other people (annevk?) to more widely observing the state of event handlers |
| 15:18 | <wanderview> | JakeA: it would be nice to have some common api to "enableEvent('fetch')" or "disableEvent('message')", etc |
| 15:20 | <JakeA> | wanderview: I'm not against that API, although I worry about the amount of state we're adding to service workers. Maybe it's fine. But with the Facebook case I'm wondering if we went too narrow with navigation preload, and perhaps we should make it just fetchPreload, where "navigation" is an option |
| 15:20 | <JakeA> | Trying to understand their problem better |
| 15:22 | <wanderview> | JakeA: I don't fully know their use cases, but it feels like some of the problem is that things are just not optimized well in browsers well for what they want... not sure I want to add too many weird apis to work around problems that might get resolved as we fix perf issues |
| 15:23 | <JakeA> | wanderview: agreed |
| 15:23 | <JakeA> | wanderview: once we understand the problem fully, we'll be in a better position to decide if this is a Chrome-world problem, or something that can never be fast and we need to offer another path |
| 15:24 | <wanderview> | JakeA: I don't think FF is immune to these problems either |
| 15:25 | <wanderview> | JakeA: we've started collecting SW start times more explicitly: https://mzl.la/2wh9v2G |
| 15:25 | <wanderview> | 95-percentile is kind of crazy |
| 15:26 | <wanderview> | oh wait... thats the submissions line |
| 15:26 | <wanderview> | https://mzl.la/2wg5qfe |
| 16:37 | <jyasskin> | I wish *.specs.whatwg.org would redirect to *.spec.whatwg.org. |
| 17:28 | <annevk> | wanderview: I generally think that's a bad thing, but for service workers that ship has sailed |
| 17:28 | <annevk> | jyasskin: file an issue at https://github.com/whatwg/misc-server/issues/new? |
| 17:29 | <annevk> | jyasskin: should be doable, although maybe we should wait for let's encrypt to support wildcards |
| 17:29 | <jyasskin> | annevk: Thanks for the pointer. |
| 19:28 | <nox> | Is it just me or everything about the fetching of the poster frame of video elements has some hand-waving? |
| 19:29 | <nox> | I expected it to be piggy-backing the wording on the image element in some sort. Not just "If an image is thus obtained, the poster frame is that image. Otherwise, there is no poster frame." |
| 20:54 | <tobie> | foolip: hoping onto irc as this will be easier to solve if we're sync |
| 20:54 | <tobie> | foolip: so what I think you should do is merge the WICG PR first. |
| 20:54 | <foolip> | tobie: here I am |
| 20:55 | <foolip> | I can't do that, need someone with write access to that repo |
| 20:55 | <tobie> | foolip: oh. :D |
| 20:55 | <foolip> | cwilso: ^ |
| 20:56 | <tobie> | cwilso: this is https://github.com/WICG/admin/pull/36 |
| 20:56 | <foolip> | or perhaps yoav? ^ |
| 20:57 | <foolip> | tobie: do the BIGNAMES need to be globally unique? |
| 20:57 | <tobie> | foolip: yes |
| 20:57 | <foolip> | huh, well OK |
| 20:58 | <tobie> | foolip: AND they need to persist from update to update |
| 20:58 | <foolip> | Then what'll we do with the old one? Delete it manually? |
| 20:59 | <tobie> | foolip: moving stuff from org to org is super rare, so we're in mostly unchartered territories, here. |
| 20:59 | <tobie> | foolip: we'll probably need to do it manually |
| 20:59 | <foolip> | ok, but wicg->w3c must be pretty common? |
| 20:59 | <tobie> | maybe? |
| 20:59 | <foolip> | tobie: is most wicg stuff just not in specref, given the short biblio.json there? |
| 21:00 | <tobie> | foolip: I dunno |
| 21:00 | <tobie> | foolip: it might be that most don't need to be referenced until they move to W3C |
| 21:01 | <jyasskin> | foolip: WICG is recent, so it could be that you're one of the first to do that migration. |
| 21:01 | <foolip> | jyasskin: the first whatwg->wicg for sure, yes |
| 21:01 | <foolip> | but it seems like wicg things in general just aren't added to specref, unless I'm missing something |
| 21:02 | <tobie> | foolip: for context, specref is massive ball of scotch tape + band aid |
| 21:02 | <foolip> | tobie: and here I am trying to build something robust and cool on top of it |
| 21:02 | <tobie> | foolip: for which I have pretty much not time |
| 21:02 | <foolip> | tobie: https://foolip.github.io/day-to-day/ is the thing |
| 21:03 | <tobie> | foolip: there's a whole bunch of pretty robust things built on top of specref |
| 21:03 | <foolip> | tobie: how can I filter for "real" specs, is that an unsolved problem? |
| 21:03 | <tobie> | foolip: define "real" |
| 21:04 | <foolip> | tobie: specs that define CSS properties, IDL or HTTP headers |
| 21:04 | <tobie> | that's not going to happen |
| 21:04 | <tobie> | :D |
| 21:04 | <foolip> | Uh, which would make ecmascript not a real spec I guess |
| 21:04 | <tobie> | BUT, if you're working on something wpt-related |
| 21:05 | <foolip> | tobie: it is wpt-related, and the non-trivial bit if figuring out which directories in wpt correspond to each spec |
| 21:05 | <jyasskin> | foolip: Have you talked to TabAtkins? Shepherd has a list of at least CSS and IDL-providing specs. |
| 21:05 | <tobie> | foolip: that should be rather trivial |
| 21:05 | <tobie> | foolip: as the tagging there is Specref-based |
| 21:06 | <cwilso> | *wakes up* |
| 21:06 | <cwilso> | foolip: merged |
| 21:06 | <tobie> | cwilso: ty |
| 21:06 | <foolip> | cwilso: thank! |
| 21:06 | <TabAtkins> | foolip: Ooh, that day-to-day thing is cool |
| 21:06 | <foolip> | TabAtkins: glad you like it, trying to make it not suck and then include many more specs |
| 21:07 | cwilso | was literally off getting coffee. :) |
| 21:07 | <foolip> | TabAtkins: ignoring specs that nobody probably cares about isn't entirely trivial it seems. would sheperd help? |
| 21:07 | <TabAtkins> | foolip: To check for things defining CSS or IDL, you can always pull the Bikeshed datafiles and read over the definitions to see what specs define them. |
| 21:07 | <TabAtkins> | Or use Bikeshed directly, so you can use its parsing/etc. |
| 21:08 | <tobie> | foolip: if you know the directory of a test in wpt, then you know its specref id |
| 21:08 | <TabAtkins> | Oh yeah, and I do have a dfn type for headers, so that should theoretically work too. |
| 21:08 | <foolip> | TabAtkins: yes, I am cloning all the repos anyway, could probably work it out somehow |
| 21:09 | <foolip> | tobie: there are exceptions that I'm having to deal with, like webrtc-pc vs webrtc, and HTML's many directories |
| 21:09 | <TabAtkins> | You can just iterate thru the refs, checking if they're a dfn type you want to care about, and collecting the specs they're associate with. Then you can check the spec db to get their URLs. This doesn't translate over into GitHubs, tho. |
| 21:09 | <foolip> | TabAtkins: iterating over shepherd, you mean? |
| 21:10 | <foolip> | I'm now working from something that guesses the git URL from the spec's URL, which I think will work with very few exceptions |
| 21:10 | <TabAtkins> | Nah, over Bikeshed's db. |
| 21:10 | <tobie> | foolip: well obviously the webrtc folks are doing their thing |
| 21:10 | <foolip> | tobie: it was probably the right name once upon a time |
| 21:10 | <tobie> | foolip: in which case it should still be in specref |
| 21:11 | <foolip> | tobie: maybe? |
| 21:11 | <TabAtkins> | Boot up a reference manager (check cli.py, under the `command == "refs"` section, for how to do that), then call `.queryRefs(type="property")`/etc. |
| 21:11 | <foolip> | tobie: are you only using biblio.json and similar, or also crawling around github orgs for new repos? |
| 21:11 | <TabAtkins> | The specs db is in ReferanceManager.specs, it's just a dictionary of spec names => spec info; it'll match up with the `spec` data field in the refs. |
| 21:12 | <tobie> | foolip: not doing crawling |
| 21:13 | <tobie> | foolip: just poking the different ref sources hourly |
| 21:14 | <foolip> | tobie: mkay, well it mostly works, so thank you :) |
| 21:15 | <tobie> | foolip: for ref, here's the code that handles the labeling for wpt: https://github.com/tobie/ganesh/blob/master/lib/metadata/raw-labels.js |
| 21:16 | <tobie> | foolip: should probably include webrtc-pc in there |
| 21:17 | <Mek> | of course wpt labels aren't exactly the same as specs (in particular for a bunch of stuff that is defined in whatwg html, but in separate wpt directories) |
| 21:17 | <foolip> | tobie: hmm, looks like a wpt dir -> shortname mapping? |
| 21:18 | <tobie> | foolip: yes |
| 21:18 | <tobie> | Mek: yeah-that's sort of subar |
| 21:18 | <foolip> | tobie: I guess I could start from wpt and work out what specs they belong to, but doing it the other way also allows me to discover specs with no wpt dirs, which I could then rectify |
| 21:18 | <tobie> | subpar |
| 21:19 | <foolip> | basically I'm going for a 1 spec repo + dir => many test repo + dir mapping |
| 21:20 | <foolip> | (css is all one repo, hence the +dir) |
| 21:20 | <foolip> | we'll see, hacking away |
| 21:20 | <tobie> | foolip: css is organized by shortname within that repo |
| 21:20 | <foolip> | tobie: well, with the complication of versioned directories |
| 21:20 | <tobie> | they all match, iirc, gsnedders fixed them |
| 21:21 | <foolip> | which is also a complication for the specs themselves of course |
| 21:21 | <tobie> | foolip: I've given up on trying to make sense of how the CSSWG organizes its work |
| 21:21 | <tobie> | (Sorry Tab) |
| 21:21 | <foolip> | TabAtkins: please tell us it's actually very simple to understand :) |
| 21:22 | <TabAtkins> | Not a clue, ask fantasai and gsnedders I guess. |
| 21:22 | <foolip> | TabAtkins: ha, gsnedders just rants about versioned directories like me, no help there |
| 21:22 | <foolip> | I guess it's down to fantasai |
| 21:22 | <TabAtkins> | Oh wait, is this about WPT specifically, or just our spec organization in general? |
| 21:23 | <tobie> | Sort of both |
| 21:23 | <foolip> | TabAtkins: I was just building my little toy, the only thing I want to do with it now is map specs to tests |
| 21:23 | <tobie> | and additionally whether and how they map |
| 21:24 | <foolip> | although another thing I'd like to do is find specs that don't link to wpt and fix those |
| 21:24 | <foolip> | if they all did then I'd have my mapping right there |
| 21:24 | <tobie> | foolip: well if they have tests elsewhere, no one runs them so… |
| 21:24 | <tobie> | foolip: outside of ES + WebGL(?) |
| 21:25 | <foolip> | tobie: wasm too |
| 21:25 | <foolip> | and yes, webgl is still external |
| 21:25 | <tobie> | wasm has a spec? |
| 21:25 | <tobie> | :D |
| 21:25 | tobie | ducks |
| 21:25 | <foolip> | tobie: dunno, when I go look for it I usually find things aimed at web developers |
| 21:26 | <TabAtkins> | tobie: There is a spec, yes. It's currently written in some tool intended for Python library documentation. |
| 21:26 | <foolip> | https://webassembly.github.io/spec/ |
| 21:26 | <tobie> | TabAtkins: I know, we've just added more legacy stuff to WebIDL for it |
| 21:26 | <TabAtkins> | I and some wasm folks tried our damnedest to make it be in Bikeshed, but apparently Andreas has the final say for some reason, and he demanded it. |
| 21:28 | <tobie> | foolip: if the goal is to move everything to wpt, which imho it should be, then you shouldn't incentivize folks to do their own thing on the side by helping them out with tooling |
| 21:28 | <tobie> | foolip: unless there are very good reasons to do so, obv |
| 21:30 | <tobie> | foolip: so I work up from wpt and eventually manually add stuff that's not in it for good reasons |
| 21:30 | <tobie> | foolip: but that's just my $.02 |
| 21:32 | <foolip> | tobie: I'm actually not convinced that wpt should devour everything, or at least not be the source of truth for everything |
| 21:33 | <foolip> | tobie: because v8 is a separate project from chromium, and I think they should be able to change test262 together with their code |
| 21:33 | <tobie> | foolip: yeah test262 doesn't belong in wpt |
| 21:33 | <foolip> | tobie: which could mean mirroring in one wpt directory into v8, but mirroring test262 itself would also work |
| 21:34 | <tobie> | foolip: not sure about wasm and/or WebGL |
| 21:34 | <tobie> | foolip: these three exceptions can work for all I care |
| 21:34 | <tobie> | foolip: and can be handled manually |
| 21:34 | <tobie> | (imho) |
| 21:34 | <foolip> | tobie: once the infrastructure around wpt is compelling enough I doubt we'll be accumulating more exceptions |
| 21:35 | <tobie> | foolip: agreed |
| 21:54 | <foolip> | tobie: where should I report bugs in https://www.w3.org/2002/01/tr-automation/tr.rdf? |
| 22:03 | <tobie> | foolip: sysreq⊙wo |
| 22:03 | <foolip> | tobie: thanks |
| 22:13 | <tobie> | foolip: alright; merged and closed a bunch of things |
| 22:14 | <tobie> | foolip: gave you commit rights to the repo and now going back to webidl mixins |
| 22:14 | <foolip> | tobie: awesome, I'll try not to delete it |
| 22:15 | <tobie> | nothing gets merged to heroku unless the test suite is green |
| 22:16 | <tobie> | foolip: so the risks of you doing anything bad beyond wasting my time are pretty low |
| 22:16 | <foolip> | tobie: I'll have to apply myself then |
| 22:19 | <tobie> | foolip: disabling travis isn't rocket science, so… |