| 09:46 | <zcorpan> | should we add dropzone to Obsolete? |
| 09:48 | <Ms2ger> | Sure |
| 10:02 | <MikeSmith> | yeah |
| 10:24 | <annevk> | JakeA: is there a service worker F2F agenda? Could you put https://github.com/whatwg/fetch/issues/492 on it |
| 10:24 | <annevk> | JakeA: I won't be there, but it seems good to have it discussed |
| 11:00 | <JakeA> | annevk: agreed! Want to look at fetch cancellation too |
| 12:43 | <gsnedders> | where is it spec'd that web fonts block the load event? |
| 12:51 | <gsnedders> | or is that not true any more? |
| 12:55 | <gsnedders> | it seems to be defined through "A resource's critical subresources are those that the resource needs to have available to be correctly processed. Which resources are considered critical or not is defined by the specification that defines the resource's format. |
| 12:55 | <gsnedders> | but nobody has ever asked the CSS WG to define what the critical subresources of a stylesheet are |
| 12:55 | <gsnedders> | AFAICT |
| 12:58 | <annevk> | gsnedders: stylesheet fetching is certainly underdefined |
| 12:59 | <annevk> | gsnedders: I also recall a desire to delay load for fonts though |
| 12:59 | <gsnedders> | annevk: is there an issue anywhere? |
| 12:59 | <annevk> | gsnedders: not sure |
| 13:00 | <gsnedders> | W3C HTML seems to say for CSS only @import is a critical subresource |
| 13:00 | <gsnedders> | I haven't looked in history to see if that was formally in WHATWG HTML yet |
| 13:03 | gsnedders | waits for git blame |
| 13:18 | <gsnedders> | Ah, https://github.com/whatwg/html/commit/89cff9a51f24174c2efca73fa2964e6cd258c541 is the change |
| 13:18 | <gsnedders> | based on https://www.w3.org/Bugs/Public/show_bug.cgi?id=17011 |
| 13:24 | <gsnedders> | which was reassigned to CSS in 2012 by hixie for the sake of defining what its crtiical subresources are |
| 15:02 | <zcorpan> | MikeSmith: https://travis-ci.org/whatwg/html/builds/207366283 |
| 16:12 | <smaug> | foolip: want to start warn about sync XHR too? (I was just reading about >>>) |
| 16:26 | <tobie> | annevk: FYI: you might find some discrepancies in pr-preview between the HTML diff and the GH diff. |
| 16:27 | <tobie> | annevk: I've identified what the issue is (the GH API is doing something weird) |
| 16:27 | <annevk> | tobie: yeah, I think I do every now and then |
| 16:27 | <annevk> | tobie: didn't really get to the bottom of it yet, but also haven't used it much thus far |
| 16:27 | <tobie> | annevk: their support is amazing though |
| 16:27 | <annevk> | tobie: appreciate the heads up |
| 16:28 | <tobie> | annevk: and I now know how to work around it |
| 16:28 | <tobie> | annevk: tracking it here: https://github.com/tobie/pr-preview/issues/3 |
| 16:28 | <tobie> | annevk: a fix shouldn't be too difficult |
| 16:29 | <tobie> | annevk: but it won't be earlier than next week at best |
| 19:35 | <noah_> | hi.. i have a question about this test https://github.com/w3c/web-platform-tests/blame/e32ff14a75f30de31fb1f7ab4e7bd064dfdbfa8a/url/urltestdata.json#L4543 - i think the domain is invalid according to idna2008, so i would expect host parsing to return failure https://url.spec.whatwg.org/#host-parsing |
| 19:37 | <annevk> | noah_: does UTS 46 reject it? |
| 19:40 | <noah__> | annevk: yes, at least https://pypi.python.org/pypi/idna does |
| 19:40 | <noah__> | on the other hand, maybe the whatwg spec should fall back on idna2003 if idna2008 fails, i think that might be what browsers do |
| 19:41 | <annevk> | noah__: hmm, file an issue against URL? I can look next week |
| 19:43 | <noah__> | ok |
| 20:50 | smaug | wonders https://html.spec.whatwg.org/multipage/browsers.html#is-a-registrable-domain-suffix-of-or-is-equal-to |
| 20:51 | <smaug> | why the word registrable there |
| 21:19 | <domfarolino> | In infra (https://infra.spec.whatwg.org/#collect-a-sequence-of-code-points), assume given input string "abc", position pointing to beginning of input, and condition "!= a" what should the algo return? "bc" or ""? |
| 21:20 | <domfarolino> | I assumed it should return "bc", but it seems since first iteration fails the while condition's second part (after then `and`), it will return "" |
| 21:39 | <domfarolino> | actually I think im wrong, it should return "" since we're not collecting ALL codepoints from input that meet a certain condition, just the ones starting at `position` in `input` |
| 21:51 | <Domenic> | domfarolino: definitely "" |
| 21:51 | <Domenic> | the loop breaks once the condition is met |
| 21:52 | <Domenic> | It might be good to add an example |
| 21:59 | <Domenic> | terinjokes: robertkowalski: ping on https://github.com/whatwg/console/pulls :) |
| 21:59 | <terinjokes> | Domenic: i've been getting the emails |
| 21:59 | <terinjokes> | i'm just busy this month |
| 21:59 | <Domenic> | terinjokes: ah ok, no problem |
| 21:59 | <domfarolino> | Domenic: Thanks! yeah I wasn't sure if it was looking for contiguous codepoints that meet a condition or all..makes sense |
| 22:00 | <domfarolino> | Domenic: I had a question the other day about HTML spec and Anne told me you'd be the best person to wait for to ask...it revolves around this algorithm here https://html.spec.whatwg.org/multipage/webappapis.html#uninstantiated-inclusive-descendant-module-scripts |
| 22:01 | <domfarolino> | Is the second condition in step 4 > substep 2 a bit redundant? We should not have to check existence in stack right? |
| 22:02 | <Domenic> | domfarolino: hmm why not? Remember module graphs can contain cycles |
| 22:04 | <domfarolino> | I could be looking at it wrong, but on a graph with cycles I feel that omitting existence checks in `stack` will only change the order of the modules in the returned set, as once they are added to the ID array (marked visited), they will not be re-added once we get to them further down the stack |
| 22:06 | <domfarolino> | I'm trying to come up with an example where omitting existence checks in the stack does not yield a proper DFS |
| 22:07 | <Domenic> | It might be true that it only changes the order, although I imagine it will do redundant work regardless? |
| 22:07 | <Domenic> | Another issue is that while right now the order doesn't matter there have been some contemplated spec changes where it might |
| 22:10 | <domfarolino> | it may do redundant work regardless Im not sure. that makes sense, yeah if order could matter better keep it |
| 22:11 | <domfarolino> | I guess I was looking at it from a perf perspective too, in that existence in a stack may not be ideal to perform a ton, though thats probably irrelevant to focus on in the spec. |
| 22:12 | <Domenic> | Yeah, most likely implementations would be keeping this data in some side structure as they build the original graph |
| 22:14 | <domfarolino> | cool thanks for the info |
| 23:22 | <tobie> | jyasskin: looking at the permission spec. Trying to clean-up the integration of the permission spec in the sensor work, as pretty much everything changed under me. |
| 23:22 | <tobie> | jyasskin: it would be great to see examples of how this can be integrated in specs |
| 23:23 | <tobie> | jyasskin: For example, in the generic sensor spec, I want to check for the permission to use a given sensor. |
| 23:24 | <jyasskin> | tobie: Yes. I'm in a C++ meeting this week and on vacation the next, but I can help with that the next. |
| 23:24 | <tobie> | jyasskin: what language should I use to do that? |
| 23:24 | <tobie> | enjoy the C++ meeting and the vacation. :) |
| 23:25 | <jyasskin> | tobie: There's a term, I think "permission state", to get the current permission state. |
| 23:25 | <tobie> | jyasskin: right, but it's unclear who calls the boolean permission request algorithm |
| 23:25 | <tobie> | or who passes it what arguments |
| 23:26 | <tobie> | my case is a bit complicated, because I have all the logic in one spec |
| 23:26 | <tobie> | and then other specs just basically specify a permission descriptor |
| 23:27 | <tobie> | now it seems I have to move part of this logic in the registry |
| 23:28 | <tobie> | but then I somehow need to split it up between multiple PermissionDescriptors |
| 23:28 | <tobie> | Happy to look when you're back. |
| 23:37 | <jyasskin> | tobie: Only permissions.request() can call the boolean permission request algorithm. |
| 23:38 | <jyasskin> | tobie: for another spec to request a permission, you use https://w3c.github.io/permissions/#requesting-more-permission |
| 23:38 | <jyasskin> | We can try to fix things once I'm back. |
| 23:38 | <tobie> | oh, nice. there they are. |
| 23:42 | <tobie> | jyasskin: so I guess I can just make my revocation algorithm for ambient light sensor in the registry call my revocation algorithm specified in the generic sensor spec, passing sensor type as an argument |
| 23:42 | <tobie> | jyasskin: think I have all I need, now. |
| 23:42 | <tobie> | Thanks |
| 23:42 | <jyasskin> | Sounds reasonable. |
| 23:43 | <tobie> | well, it's a lot of indirection |