| 07:58 | <mkwst> | tobie: You're in a reasonable time zone, right? :) Do you have a few minutes to help me out with some IDLish questions? |
| 07:59 | <Ms2ger> | Morning |
| 07:59 | <tobie> | mkwst: I can give it a try. |
| 07:59 | <mkwst> | Morning! |
| 08:00 | <tobie> | mkwst: I've got a flu, so bear with me if I'm slow at understanding things. :) |
| 08:00 | <mkwst> | tobie: I'm trying to do a better job explaining the extension model of https://w3c.github.io/webappsec-credential-management/. Today, it does very hand-wavey things in https://w3c.github.io/webappsec-credential-management/#request-credential (step 5 and beyond). |
| 08:01 | <mkwst> | I'd like them to be less hand-wavey. |
| 08:01 | <mkwst> | As a short explanation: |
| 08:02 | <mkwst> | `get()` accepts a dictionary that specifies what kind of objects the developer wants. `{ type1: true, type2: { long: 'list', of: 'filters' } }`. |
| 08:03 | <mkwst> | The current spec converts from the dictionary keys to interfaces more or less by fiat. |
| 08:03 | <mkwst> | And then does some weird things about walking the ancestor tree to figure out whether it can service a request for `type1` and `type2` at the same time. |
| 08:03 | <mkwst> | And then switches on an interface type, which I'm not sure we can actually do. ;) |
| 08:04 | <mkwst> | https://w3c.github.io/webappsec-credential-management/base.html attempts to clarify. |
| 08:04 | <mkwst> | https://w3c.github.io/webappsec-credential-management/base.html#credential-internal-methods defines some internal methods on the interface object exposed by the IDL interface. |
| 08:05 | <mkwst> | And https://w3c.github.io/webappsec-credential-management/base.html#algorithm-request tries to map the dictionary keys to interfaces by walking the interface objects. |
| 08:05 | <mkwst> | step 5ish. |
| 08:06 | <mkwst> | (Sorry to everyone else in the channel who's probably not interested. ;) ) |
| 08:08 | <annevk> | mkwst: you can let IDL handle the initial parsing, and then you need to parse again based on the type parameter |
| 08:08 | <annevk> | mkwst: permissions has a similar setup |
| 08:09 | <annevk> | mkwst: maybe if enough copycats emerge the whole pattern can be uplifted to IDL somehow |
| 08:10 | <annevk> | (Also personally I take interest in all things #whatwg :-p) |
| 08:12 | <tobie> | mkwst: sounds like you got all the info you needed and I can go back to sleep. |
| 08:17 | <mkwst> | annevk: I'm skimming through the permissions spec. It doesn't seem terribly clear to me. |
| 08:18 | <annevk> | mkwst: https://w3c.github.io/permissions/#permissions-interface is the bit I think |
| 08:18 | <annevk> | mkwst: I recommend asking jyasskin |
| 08:18 | <mkwst> | I'll poke him. Thanks! |
| 08:34 | <tobie> | mkwst: if you file an issue somewhere, I'm happy to give it a look too once my cognitive functions are back to normal. |
| 10:23 | <MikeSmith> | zcorpan: I don’t understand https://github.com/html5lib/html5lib-tests/issues/89#issuecomment-287013694 |
| 10:24 | <MikeSmith> | isn’t the “content” string just some internal thing used for html5lib-tests? |
| 10:24 | <zcorpan> | MikeSmith: there should be a line `| content` after <template> |
| 10:24 | <MikeSmith> | per spec? |
| 10:24 | <MikeSmith> | oh the serializer? |
| 10:24 | <MikeSmith> | or what? |
| 10:25 | <zcorpan> | well there is no actual spec for this. but i thought part of the point of parsetree was that it could be copy-pasted into html5lib-tests .dat files |
| 10:25 | <MikeSmith> | ah |
| 10:25 | <MikeSmith> | yeah I guess that’s true |
| 10:25 | <MikeSmith> | make sense |
| 10:25 | <MikeSmith> | so yeah I can add that |
| 10:25 | <zcorpan> | thanks :-) |
| 10:41 | <hsivonen> | zcorpan: sad external legacy Windows software is sad |
| 10:41 | <hsivonen> | zcorpan: I don't have anything smart to say to the node folks about that |
| 10:41 | <hsivonen> | zcorpan: thanks |
| 10:42 | <zcorpan> | hsivonen: yeah. i still don't understand why he prefers utf-16 with BOM over utf-8 with BOM, though |
| 10:42 | <hsivonen> | zcorpan: does the external legacy thing grok UTF-8 with BOM? |
| 10:44 | <zcorpan> | hsivonen: he said that utf-8 without BOM is decoded as "Ansi", but didn't say anything about utf-8 with BOM. It appears he saw the "Unicode" label and decided to stick to that option |
| 10:44 | <hsivonen> | zcorpan: I commented after all |
| 10:45 | hsivonen | goes back to removing UTF-16 output capability from Gecko |
| 10:55 | <annevk> | zcorpan: pointer to this node issue? |
| 10:56 | <zcorpan> | annevk: https://github.com/nodejs/node/issues/11767 |
| 11:00 | <annevk> | mkwst: we have a few HTTP auth tests for XMLHttpRequest |
| 11:00 | <annevk> | mkwst: if you actually remove that functionality those will all have to be adjusted somehow |
| 11:00 | <annevk> | mkwst: I'd be somewhat surprised though if nobody relies on it in the wild |
| 11:01 | <mkwst> | Hrm? |
| 11:01 | <mkwst> | annevk: Sorry, I'm missing context. |
| 11:02 | <annevk> | mkwst: I thought you were planning on making the user/password arguments to open() useless |
| 11:02 | <annevk> | mkwst: per https://github.com/whatwg/fetch/pull/465 |
| 11:03 | <annevk> | mkwst: I just posted a web-platform-tests PR fixing some authentication-related tests that uses that functionality, figured I'd let you know |
| 11:03 | <mkwst> | Got it, sorry. Yes, I am planning to do that. Yes, it will require adjustments to tests. Yes, it might break things. The metrics look low enough that it's worth trying. |
| 11:03 | <mkwst> | Just took me a minute to page that back in, sorry. :) |
| 11:04 | <mkwst> | The stable version of Chrome that's rolling out now has a deprecation message in the console for that kind of usage. Let's see who comes at me with pitchforks. |
| 11:16 | <hsivonen> | annevk: Mozilla's old tree management tools relied on it. TreeHerder doesn't, IIRC. |
| 11:26 | <nox> | zcorpan: Around? |
| 11:26 | <zcorpan> | nox: yes |
| 11:26 | <nox> | zcorpan: https://github.com/html5lib/html5lib-tests/pull/87/files#diff-80f44ad8658d9cc87ce967f7514ebf8dR227 |
| 11:26 | <nox> | zcorpan: How come the template element ends up with a plaintext child? |
| 11:27 | <zcorpan> | nox: https://github.com/html5lib/html5lib-tests/issues/89 |
| 11:27 | <nox> | zcorpan: Thanks! |
| 11:27 | <nox> | zcorpan: Somehow couldn't find it. |
| 11:30 | <MikeSmith> | zcorpan: I am wondering if should I emit “content” even for <template></template> |
| 11:31 | <zcorpan> | MikeSmith: https://github.com/html5lib/html5lib-tests/blob/27724be8d27a1232a8809a55f9c37b69706cb03e/tree-construction/template.dat#L33 |
| 11:32 | <MikeSmith> | ah OK good that makes things easier |
| 11:32 | <MikeSmith> | thanks |
| 11:55 | <MikeSmith> | zcorpan: https://checker.html5.org/parsetree/?parser=html5&content=%3C%21doctype+html%3E%3Ctemplate%3E%3Cplaintext%3Ea%3C%2Ftemplate%3Eb&submit=Print+Tree |
| 11:56 | <zcorpan> | MikeSmith: sweet, thank you |
| 11:56 | <MikeSmith> | thanks for the heads-up |
| 12:08 | <MikeSmith> | annevk: hsivonen you may find https://github.com/bspammer/vimcryption entertaining |
| 13:30 | <annevk> | MikeSmith: heh |
| 14:25 | <jochen__> | hum, so this stash thing in wptserve appears to be super unreliable |
| 14:25 | <jochen__> | when I load a stylesheet that references and image that stashes something |
| 14:26 | <jochen__> | and in the onload handler for the stylesheet (after checking via getComputedStyle to make sure the image was really loaded), and load the image via an xhr again, every few tries, it can't find anything stashed in the server |
| 14:33 | <zcorpan> | jgraham: ^ |
| 14:34 | <jgraham> | jochen__: Can you make a testcase for me to look at? We have some tests using it that I don't think are unreliable, but it could be broken |
| 15:27 | <jyasskin> | mkwst: Sorry permissions wasn't clear. |
| 15:27 | <mkwst> | jyasskin: Sorry I'm dumb! :) |
| 15:28 | <mkwst> | It looks like it's binding things to strings, and it's just not clear to me how that's expected to work from a spec perspective. |
| 15:28 | <mkwst> | But I read it quickly, so I likely missed something important. |
| 15:29 | <jyasskin> | mkwst: Permissions says, here's a mapping of strings to dictionary types. The mapping is held in the base standard, but the dictionaries may be defined in the extension standards. |
| 15:30 | <jyasskin> | mkwst: That's to make it easier to read: you don't have to divine the entire universe of extensions to understand the code. You have the whole set in one place. |
| 15:31 | <jyasskin> | i.e. "the set of interfaces whose inherited interfaces contain Credential." is a clever way to do the same thing, but I think it'll make the spec harder to follow. |
| 15:31 | <jochen__> | jgraham: https://github.com/w3c/web-platform-tests/pull/5160 |
| 15:32 | <jyasskin> | The downside of the Permissions approach is that we have to keep updating the core spec, which is less compatible with the W3C's processes. |
| 15:32 | <mkwst> | jyasskin: In my head, it's simpler, because it's pointing at concepts that exist in IDL, and I wanted to avoid making the spec a registry. |
| 15:32 | <mkwst> | Right, that. |
| 15:33 | <jyasskin> | I think your wording is effective, but it's a COMEFROM label, which I try to avoid. :) |
| 15:34 | <jyasskin> | mkwst: Also, today's my day off for baby care, so I'll be around irregularly. |
| 15:34 | <jochen__> | eh, if intercal can do it, it's ok |
| 15:35 | <mkwst> | jyasskin: I guess I see it as an implicit registry, but I totally get that it's confusing (and I'm not sure I'm using the right IDL language anyway). |
| 15:35 | <mkwst> | jyasskin: Also also, go take care of a baby! They're cuter than me and need more attention. :) |
| 15:36 | <jyasskin> | We don't have a *good* way to do registries yet, so each author gets to pick their least-bad way. |
| 15:41 | <jgraham> | jochen__: OK, ,I'll take a look. Thanks |
| 16:15 | <jgraham> | jochen__: /referrer-policy/css-integration/external-stylesheet.html doesn't exist in that PR? |
| 16:16 | <jochen__> | meh |
| 16:35 | <jochen__> | jgraham: updated the PR |
| 17:03 | <jgraham> | jochen__: Isn't the problem here just that images aren't critical subresources of stylesheets |
| 17:03 | <jgraham> | So when the load event fires the image hasn't necessarily put anything in the stash yet |
| 17:04 | <jgraham> | So your test is racy? |
| 17:04 | <jochen__> | if you look at the console output, you'll see that the heightof the background-image is known before I even start the XHR |
| 17:04 | <jochen__> | that means that the part of image.py the stashes (which happens before I even generate the image) should have completed |
| 17:09 | <jgraham> | jochen__: And yet the logging I have shows |
| 17:09 | <jgraham> | Took data from stash |
| 17:09 | <jgraham> | application/json |
| 17:09 | <jgraham> | Put data in stash |
| 17:09 | <jgraham> | Generated image |
| 17:09 | <gsnedders> | jochen__: that only means it knows the height of the div, not that it has loaded or painted the image |
| 17:09 | <jgraham> | Right, it's probably telling you your font size * line height |
| 17:11 | <gsnedders> | the computed height of the div is totally unrelated to the image I'm pretty sure |
| 17:11 | <jochen__> | hum |
| 17:11 | <jochen__> | zcorpan suggested to use that :) |
| 17:12 | <jochen__> | is there a good way to wait for the image to be loaded? |
| 17:12 | <jgraham> | I agree that gives you a good prior, but even zcorpan is wrong occasionally (it is rumored) |
| 17:12 | gsnedders | isn't entirely sure about behaviour around `content` property here |
| 17:12 | <jgraham> | Well and ::before is an extra layer of complexity |
| 17:12 | <gsnedders> | so the content property makes it a replaced element, but pending the load of the image it has no intrinsic width/height |
| 17:13 | <gsnedders> | so, uh, idk |
| 17:14 | <jgraham> | Anyway the server logs don't support the idea that the loads happen in the order you think |
| 17:23 | <annevk> | This is where you use test.step_yolo |
| 17:23 | <annevk> | I mean test.step_timeout |
| 17:26 | <jgraham> | test.make_intermittent would have been a good and accurate name |
| 17:27 | <annevk> | test.step_on_jugglinmike |
| 21:45 | <Domenic> | What the what https://bugs.webkit.org/show_bug.cgi?id=25893 |
| 21:45 | <Domenic> | (tales from the crypt of time) |
| 22:26 | <noah> | annevk: food for thought, maybe... we have this new library for parsing and canonicalizing urls, and one of the things it does is pull apart parsing and canonicalization into separate steps... i wonder if you think that might be a good idea for the whatwg spec, or if conversely there's some reason why that approach is incorrect |
| 22:26 | <noah> | see https://github.com/iipc/urlcanon/blob/master/python/urlcanon/parse.py and https://github.com/iipc/urlcanon/blob/master/python/urlcanon/canon.py |
| 23:43 | <JakeA> | annevk: Is there anything particular you want us to tackle at the service worker f2f in terms of fetch? I'm going to 'present' the fetch control/cancelation stuff. |