| 10:23 | <littledan> | annevk: I think the idea is to tell host environments that they're wrong if they do something like [Unforgeable]. So I'm not sure what it'd mean in practice. https://github.com/Agoric/proposal-preserve-virtualizability |
| 10:25 | <annevk> | littledan: ah, Agoric |
| 10:26 | <littledan> | they did make a positive shoutout to annevk 's work making WebIDL in terms of the JS object model |
| 10:26 | <annevk> | Wait, why are they writing EcmaScript? |
| 10:26 | <littledan> | what do you mean? |
| 10:27 | <annevk> | I thought it was ECMAScript |
| 10:27 | <littledan> | yeah, it is. I guess this could be a PR? But IMO the higher priority PR would be saying exactly what the proposal would mean |
| 10:28 | <annevk> | Oh I see, the whole thing is generally quite sloppy about casing |
| 10:29 | <annevk> | I like how Mark et al first went through great trouble to get ECMAScript to match Host capabilities and now they want to limit what Hosts can do |
| 10:30 | <annevk> | If I had these goals I might put more effort into IDL I suppose |
| 10:31 | <annevk> | In terms of limiting what hosts can introduce and influencing the people that can help with that, it's a good place |
| 10:58 | <littledan> | I'm trying to convince Mark that he should try to build consensus with web people if he wants to influence the web, rather than put prohibitions into the JS spec saying the web is wrong |
| 10:58 | <littledan> | but, sounds like marking [Unforgeable] as legacy would be a good way to influence things, yeah |
| 10:59 | <littledan> | looks like Trusted Types makes pretty heavy use of Unforgeable. Is this what we want? https://w3c.github.io/webappsec-trusted-types/dist/spec/ |
| 11:02 | <annevk> | littledan: dunno, https://github.com/mozilla/standards-positions/issues/20 |
| 11:03 | <annevk> | littledan: I had not looked deeply at the APIs there, mostly on when code would run |
| 11:11 | <littledan> | annevk: This doesn't seem specific to a Mozilla position, so I filed https://github.com/w3c/webappsec-trusted-types/issues/257 |
| 11:12 | <annevk> | littledan: thanks |
| 11:14 | <littledan> | there were some earlier ideas about trusted types which had to do with enforcement of the literal-ness of strings. I really liked that approach. This has evolved into TC39's `Array.isTemplateObject` proposal, which could be used to build a TT policy and set of template tags that checks that strings were literals created with a particular tag. |
| 11:15 | <littledan> | the concern was, restricting entirely to literal strings if the CSP policy is on would be too inflexible to work in practice, so this may be one element of a more detailed policy |
| 11:16 | <littledan> | (and the other concern was a misunderstanding about whether such literal-ness checks would be possible through TC39--I think the current progress of `Array.isTemplateObject` shows that it is possible, but I think this wasn't clear for a while.) |
| 12:38 | <annevk> | andreubotella: I'll take a stab at that string issue |
| 12:56 | <andreubotella> | annevk: I see. I was gonna try and glance at the usages of "length" in some of the specs linked in the wiki. |
| 12:58 | <annevk> | andreubotella: that sounds great |
| 12:58 | <annevk> | andreubotella: I'm mostly leaning towards replacing any usages of string's length with code unit length or code point length and then removing both concepts of length |
| 12:59 | <annevk> | andreubotella: and I guess if we keep the single word length around it will have to mean code unit length as otherwise it's too confusing with JS |
| 13:00 | <andreubotella> | I wouldn't be opposed to just removing both concepts, but I'd prefer keeping length as code unit length. |
| 13:07 | <annevk> | I could go for length and code point length too, let's see what Domenic and Addison think |
| 13:11 | <andreubotella> | Right |
| 14:47 | <domfarolino> | annevk: Thanks a bunch for all of the reviews and design discussions recently. Glad to have lazy load landed! |
| 14:49 | <annevk> | \o/ |
| 16:27 | <annevk> | Domenic: if you have some advice for https://github.com/web-platform-tests/wpt/pull/21146 that'd be cool; I haven't worked a lot with templating before and the whole thing ends up looking rather messy even though there's not a whole lot of duplication left |
| 16:31 | <Domenic> | Will take a look, hmm |
| 16:32 | <Domenic> | In general in tests I favor duplication/explicitness over clever loops/templating |
| 16:36 | <Domenic> | annevk: yeah I guess that would be my advice, is to just have explicit files with the tests (maybe one file per test), instead of using JavaScript to create strings repeatedly. If you really need to then you can write a Python/Node.js script to generate the tests but the actual test files would be easier to understand if they were not templated. |
| 16:36 | <Domenic> | https://testing.googleblog.com/2019/12/testing-on-toilet-tests-too-dry-make.html |
| 16:40 | <annevk> | I don't really agree with that |
| 16:40 | <Domenic> | OK, well, it's kind of standard engineering best practice, but, I'm not going to block tests merging over it. |
| 16:40 | <annevk> | To some extent sure, but verifying for correctness is also relevant over a series of tests |
| 16:40 | <annevk> | And then a loop can help to verify there's no copypasta somewhere |
| 16:41 | <Domenic> | So can code generation, if that's the higher priority than auditability |
| 16:41 | <Domenic> | The point though is that loops without tests are bug-factories |
| 16:41 | <Domenic> | So using them in tests, which are themselves untested, is not great |
| 16:45 | <annevk> | Also, this isn't using loops |
| 16:45 | <Domenic> | True, yeah, I was going to say, loops can be fairly easy to understand... |
| 16:45 | <Domenic> | This templating though, I just have no idea how many tests are being generated. |
| 16:45 | <Domenic> | (Do you?) |
| 16:48 | <annevk> | 18 iirc |
| 16:49 | <annevk> | 5 * 2 for blobs and 4 * 2 for datas |
| 16:49 | <Domenic> | OK, well, I guess if one person understands the tests, that's something |
| 16:51 | <annevk> | heh |
| 16:59 | <Domenic> | annevk: intuitively speaking what does the loop in process a navigate fetch do? Is it following redirects through the location header? |
| 17:14 | <annevk> | Domenic: for HTTP URLs, yes |
| 17:14 | <annevk> | Domenic: non-HTTP in a location is post-loop atm |
| 17:14 | <Domenic> | Cool. I think it'd be a bit clearer if "location URL" was typographically "`Location` URL" |
| 17:14 | <Domenic> | I'll open a fetch issue |
| 17:15 | <annevk> | Domenic: well it’s a type |
| 17:15 | <Domenic> | Isn't it a field of response? |
| 17:15 | <annevk> | Domenic: and Fetch has processed the value |
| 17:15 | <annevk> | Domenic: sure but it’s not the Location header |
| 17:15 | <Domenic> | Yeah I'm just saying "location" is pretty ambiguous, I didn't know you were talking about the location header |
| 17:16 | <annevk> | Okay, add it to the existing refactoring issue for that field? |
| 17:16 | <Domenic> | Meh, I guess if I just clicked on the dfn, it'd be clear enough |
| 17:16 | <Domenic> | Nah I changed my mind, things don't need to be 100% clear for people who are too lazy to click on <dfn>s when they are confused :) |
| 17:27 | <Domenic> | annevk: quick review on https://github.com/whatwg/html/pull/5212 ? littledan already approved so mostly editorial |
| 17:43 | <annevk> | Domenic: you got it |
| 18:04 | <annevk> | Also, agreed that we need to define a user-initiated navigation to a data URL. Maybe the time has finally come to try to sort out again if source browsing context can finally become source document |
| 18:04 | <annevk> | And then also what to do if it's null |
| 18:06 | <Domenic> | That'd be fun :) |
| 18:10 | <annevk> | So much yak shaving around COOP+COEP/Spectre, but yeah, it's mostly good; still a bit scared of history, but I've been thinking of more concretely writing down what browsers are reportedly doing as some kind of model description |
| 18:25 | <Domenic> | I mean these are kind of your favorite yaks to shave; seems good to have an excuse to work on it :) |