| 07:02 | <annevk> | JakeA: oh thanks, I'll add that to our backlog |
| 07:03 | <annevk> | JakeA: best thing we recently finished is Sense8, but unfortunately it got canceled (though there'll be a long wrap up somewhere next year) |
| 07:05 | <JakeA> | I enjoyed the first series of that but haven't watched the extra episode they did |
| 07:25 | <domfarolino> | Anyone know whether or not it is spec'd somewhere that browsers should not block rendering on link tags whose media attributes do not apply to the current UA environment when loading a page? |
| 07:27 | <domfarolino> | https://html.spec.whatwg.org/multipage/semantics.html#processing-the-media-attribute doesn't get specific about it..idk whether or not the idea of renderblocking media is implementation-dependent or something is spec'd |
| 07:40 | <annevk> | JakeA: there's two seasons, and then there's some kind of upcoming long episode |
| 07:40 | <annevk> | JakeA: ah, and the first episode of season two was also a long one |
| 07:41 | <annevk> | domfarolino: all of that is super hand-wavy |
| 07:41 | <annevk> | domfarolino: right tradeoffs are still an area of research I suppose |
| 07:44 | <domfarolino> | annevk: ok makes sense. yeah, reason I asked is bc nightly seems to block rendering on stylesheets loaded from link whose media attr doesn't reflect current environ, where as canary + safari don't block (render screen much quicker) gotcha tho |
| 07:50 | <annevk> | domfarolino: we should probably fix nightly |
| 07:51 | <annevk> | domfarolino: though how exactly it is to be fixed is much less clear of course |
| 07:51 | <annevk> | domfarolino: like do canary + safari even end up populating document.styleSheets in the end with these stylesheets? |
| 07:51 | <annevk> | domfarolino: CSSOM was so poorly done |
| 07:59 | <domfarolino> | annevk: yeah, think I'm gonna make a small repro example...any recommendations on where to ask around about it? |
| 07:59 | <domfarolino> | annevk: canary + safari do populate document.styleSheets after they are loaded btw |
| 08:00 | <annevk> | domfarolino: the only person I can think of for Fx is bz |
| 08:01 | <domfarolino> | annevk: ok perhaps asking around in the slack will be beneficial too or something...you're saying CSSOM was don poorly in FF? |
| 08:01 | <annevk> | domfarolino: no, just done poorly as a thing |
| 08:01 | <domfarolino> | annevk: yeah, seems like something we shouldn't be doing (all this blocking for no reason when other implementations aren't) |
| 08:01 | <domfarolino> | ahhhh |
| 08:01 | <annevk> | domfarolino: the slack? |
| 08:02 | <domfarolino> | annevk: ah, yeah mozilla.slack.com the firefox channel is fairly active though I feel more engineers actually use IRC so it might be the best route yeah |
| 08:03 | <annevk> | oh, maybe I should finally gave and sign up for that, hmm |
| 08:03 | <annevk> | domfarolino: I'd expect #content and maybe #layout to have answers, but not this time of day |
| 08:03 | <annevk> | domfarolino: on Mozilla IRC, not Freenode |
| 08:04 | <domfarolino> | annevk: it's unfortunately fairly spammy IMO butttttt I've gotten some decent information on bugs ive been interested in so yeah pros and cons |
| 08:04 | <annevk> | s/gave/cave/ |
| 08:04 | <domfarolino> | annevk: Gotcha, yeah I'll ask around tomorrow haha |
| 09:23 | <TabAtkins> | domfarolino: There's no particularly good reason to block rendering in that case, but I don't think the blocking behavior is defined anywhere. |
| 09:23 | <TabAtkins> | One does have to be careful, because even if it doesn't apply, scripts might expect the StyleSheet object to exist. |
| 09:24 | <TabAtkins> | But that doesn't have anything to do with the rendering, I wouldn't think. |
| 09:26 | <annevk> | TabAtkins: that's another thing that's poorly defined, whether StyleSheet existing implies the entire stylesheet is present or whether that can be incremental |
| 09:27 | <annevk> | TabAtkins: it's clear the DOM is incremental, but for CSSOM it's all rather vague and undefined? |
| 09:27 | <TabAtkins> | yup |
| 09:27 | <annevk> | I'm sure Glenn Adams will fix it any day now |
| 09:28 | <TabAtkins> | it's zcorpan's responsibility now ^_^ |
| 11:58 | <JakeA> | annevk: I could try to reduce the amount of wrapping in cancellation, but it will leave some points not-cancellable, some which are potentially observable. Eg https://fetch.spec.whatwg.org/branch-snapshots/cancelation/#main-fetch 2.4 is observable through CSP reporting |
| 12:03 | <annevk> | JakeA: hmm, I wonder if it's bad if you can race with mixed content blocking and such, though obviously you already can the moment you hit redirects |
| 12:05 | <annevk> | JakeA: also, maybe we need to rephrase "Run these steps until" somehow to not make it seem like a while loop |
| 12:06 | <JakeA> | annevk: I'll make a branch that only deals with streams and network stuff. I went the other way because it seems weird to call out to CSP for a potentially already terminated fetch |
| 12:06 | <annevk> | JakeA: yeah, I think you're right that that's weird |
| 12:06 | <annevk> | JakeA: so I'm okay with your setup |
| 12:07 | <JakeA> | annevk: Yeah, I'll figure out some working for the |reason| stuff too. I started with "If the fetch terminates with reason |reason|", but it sounds like the |reason| is part of the conditional |
| 12:08 | <annevk> | "Run these steps once and stop if fetch is terminated"? |
| 12:15 | <JakeA> | Yeah, that works |
| 12:18 | <JakeA> | annevk: I don't mind the git blame issue. I'll use it to get a promotion. "I wrote 50% of the fetch spec" |
| 12:18 | <JakeA> | (a colleague was refused promotion because some idiot did a git blame on a project they worked on and decided they hadn't done much on it) |
| 12:19 | <annevk> | JakeA: pretty decent machine learning you got going on there |
| 12:19 | <nox> | JakeA: Next time you show managements the exact same figures, |
| 12:19 | <nox> | JakeA: but as the output of git praise instead. |
| 12:20 | <JakeA> | :D |
| 12:20 | <jgraham> | JakeA: At Google? That's pretty funny. (and also tragic) |
| 12:20 | <annevk> | git: 'praise' is not a git command. See 'git --help'. |
| 12:20 | annevk | is disappointed |
| 12:20 | <jgraham> | annevk: You are thinking of svn |
| 12:20 | <jgraham> | git-annotate is a command |
| 12:21 | <JakeA> | jgraham: yeah, pretty shitty. We did some complaining about it. Hopefully it won't happen again. |
| 12:21 | <annevk> | There should be promotions for leaving behind little technical debt (or just owning up to it for a long time) |
| 12:21 | <nox> | Yeah it's from svn. |
| 12:22 | <nox> | blame|annotate|praise |
| 12:24 | <jgraham> | annevk: And yet Hyatt got a huge payrise/promotion for abandoning us yet leaving XUL and XBL. |
| 12:26 | <annevk> | jgraham: yeah, creation gets rewarded much more than maintaining a pile of hacks, which is why there's also so many new APIs of dubious value and rather little architectural work (some of this is overly simplified and I'm biased) |
| 12:27 | <JakeA> | no I think you're right |
| 12:28 | <JakeA> | also creating stuff in solitude makes it easier when it comes to attribution |
| 13:22 | <JakeA> | annevk: what's the deal with the manual-wrapping in specs? I much prefer allowing the editor to wrap. Makes it easier when searching across the file too |
| 13:22 | <JakeA> | Makes diffs easier too, as you don't end up with loads of lines changing because of a one-word change |
| 13:24 | <nox> | JakeA: This was ambiguous. |
| 13:24 | <nox> | JakeA: The editor, or the editor? :) |
| 13:24 | <JakeA> | haha |
| 13:24 | <JakeA> | yeah |
| 13:24 | <JakeA> | um, I mean the text editor's wrapping feature |
| 13:24 | <annevk> | JakeA: so I don't wrap terms myself (though whatwg/html does) so searching should not be impacted generally |
| 13:24 | <nox> | I could see someone replying to you "well, that's exactly what we do?" passive-aggressively. :P |
| 13:25 | <annevk> | JakeA: and I think the wrapping is for more readable diffs, though it's somewhat terminal-orientated |
| 13:26 | <JakeA> | annevk: ah, so I've been following the whatwg/html rules. I guess I should fix that |
| 13:26 | <JakeA> | annevk: I don't agree that it makes diffs better, unless the diff viewer doesn't support wrapping (which unfortunately includes vscode) |
| 13:26 | <annevk> | JakeA: seems like something we could discuss for a bit in https://github.com/whatwg/meta/issues to see if the tooling is maybe good enough these days that we should just drop it and go with something else |
| 13:27 | <JakeA> | annevk: I guess the main bit of tooling that would need to support it is github |
| 13:27 | <JakeA> | which doesn't right now, although a small CSS change fixes it |
| 13:27 | <annevk> | JakeA: well this is from the days where we mostly used "diff -u p10" or some such (I forgot the exact syntax) |
| 13:28 | <tobie> | JakeA: I find GitHub's split view mostly good enough for this. |
| 13:29 | <nox> | JakeA: I think the argument about diffing is that if you insert a long word on a line, |
| 13:29 | <nox> | you may need to rewrap everything that follows, |
| 13:29 | <annevk> | Yeah, GitHub's diff viewing + tobie's tool might be enough to start giving up on the 100col thing |
| 13:29 | <nox> | and then 10 lines changed instead of 1. |
| 13:29 | <tobie> | JakeA: That said, I favor semantic line breaks of 100 character wrap, tbh |
| 13:30 | <annevk> | Anyway, I recommend someone file an issue if they want to see this changed generally |
| 13:30 | <tobie> | s/of/over/ |
| 13:30 | <annevk> | Against whatwg/meta |
| 13:30 | <nox> | Ah that's the opposite direction, disregard me. |
| 13:30 | <tobie> | nox: semantic line breaks prevent that |
| 13:31 | <nox> | tobie: Yeah that's what I meant. |
| 13:32 | <JakeA> | tobie: huh, I didn't realise the split view now supported wrapping in github. I thought I tried this recently and it didn't. |
| 13:33 | <tobie> | JakeA: I think it mostly works? There might be cases where there's too much change for it to kind of fall apart, though. |
| 13:33 | <JakeA> | seems pretty good |
| 13:34 | <tobie> | good |
| 13:34 | <annevk> | What's really nice about GH is how it highlights the word changes |
| 13:35 | <annevk> | Though unfortunately those don't account for wrapping :/ |
| 13:35 | <wanderview> | JakeA: have the useCache WPT tests landed? |
| 13:36 | <JakeA> | wanderview: https://github.com/w3c/web-platform-tests/pull/5515 - no one seems to want to review it :( |
| 13:36 | <TabAtkins> | JakeA: Semantic linefeeds, yo <http://rhodesmill.org/brandon/2012/one-sentence-per-line/>;. All the benefits of short lines, *plus* you don't have to rewrap a bunch when you change one word. |
| 13:37 | <wanderview> | JakeA: aren't there lots of review comments on there? |
| 13:37 | <wanderview> | I'll look again |
| 13:39 | <JakeA> | wanderview: there were reviews, and I've addressed the comments. Just needs someone to say it's now good to go :D |
| 13:39 | <wanderview> | JakeA: done |
| 13:40 | <JakeA> | \o/ thanks! |
| 13:40 | <wanderview> | JakeA: sorry about that... I could complain about GH UX again I suppose |
| 13:41 | <wanderview> | I guess I'm really used to bugzilla flag system |
| 13:41 | <JakeA> | wanderview: it's my bad, there's a few prs I need to chase |
| 13:43 | <nox> | wanderview: Is that the needinfo thing? |
| 13:44 | <nox> | wanderview: There is https://github.com/pulls/review-requested |
| 13:44 | <wanderview> | nox: needinfo, explicit review flags, a place I can see all flags requested of me |
| 13:45 | <JakeA> | TabAtkins: I've never done that before, but I guess it makes sense. Have you written specs this way before? |
| 13:45 | <TabAtkins> | I write every single spec that way. |
| 13:45 | <TabAtkins> | Check any of the CSS specs I edit. |
| 13:47 | <TabAtkins> | https://github.com/w3c/csswg-drafts/blob/master/css-align/Overview.bs |
| 13:47 | <TabAtkins> | ^^^ for example |
| 13:47 | <jgraham> | wanderview: GH kind of has explicit review flags now |
| 13:48 | <wanderview> | jgraham: yes... but targeted at specific people or just "i want someone to review"? |
| 13:48 | <nox> | Yep it's the link I pasted, |
| 13:48 | <jgraham> | wanderview: Yes |
| 13:48 | <nox> | but there is no unified view for review requests and things assigned to you, for example. |
| 13:48 | <jgraham> | wanderview: (although really targeted at specific people is a pretty bad system for contributors) |
| 13:49 | <jgraham> | (although I guess it has CODEOWNERS now, so that could help) |
| 13:49 | <JakeA> | https://github.com/whatwg/meta/issues/31 issue for removing the 100 column limit |
| 13:52 | <JakeA> | TabAtkins: When are you going to write typeshed so I can write specs in TypeScript and it'll convert them to prose? |
| 13:53 | <wanderview> | jgraham: all I know is that I still don't have a good way to know what PRs people are waiting on me to review... |
| 13:55 | <jgraham> | wanderview: I mean I agree that the GH sisten is not that great |
| 13:55 | <jgraham> | But in-principle looking at https://github.com/pulls/review-requested answers that question |
| 13:56 | <jgraham> | It's just hard to find, and you don't get reminder emails, and it's not integrated with any other data |
| 14:15 | <annevk> | (it's also broken on whatwg/html PRs likely due to the size of the source resource) |
| 14:15 | <annevk> | (reported but no fix) |
| 14:26 | <tobie> | TabAtkins, JakeA: I <3 semantic line feeds. Helps me think. But it seems pretty much everyone else hates them. |
| 14:31 | <wanderview> | anyone have safari handy and could run this test? https://timeout-clamp.glitch.me/ |
| 14:34 | <gsnedders> | wanderview: first result is inconistent (1 to 6 I've observed), second is always 6 |
| 14:35 | <wanderview> | gsnedders: thanks |
| 14:35 | <jgraham> | I find that semantic line feeds make the text harder to read due to the extreme raggedy right edge. It's like someone was trying to write particularly dull freeform poetry |
| 14:35 | <gsnedders> | wanderview: s/first/setTimeout/ |
| 14:35 | <gsnedders> | wanderview: (this is on a laptop on AC power, given throttling might differ) |
| 14:35 | <gsnedders> | wanderview: and Safari TP 36 |
| 14:36 | <wanderview> | gsnedders: thanks, its bound to be noisy... I think 6 is a reasonable answer |
| 14:36 | <tobie> | jgraham: "particularly dull freeform poetry" is an pretty adequate description of spec prose. |
| 14:37 | <tobie> | *accurate |
| 14:38 | <TabAtkins> | jgraham: I find it much easier to read, precisely because the "poetic" nature of it splits up thoughts better. |
| 14:49 | <wanderview> | JakeA: when you are able to land the useCache tests, can you let me know? I want to ask jgraham to do a gecko sync to pull the tests in |
| 14:49 | <wanderview> | or maybe let jgraham know directly since you're in the same timezone |
| 14:50 | <jgraham> | wanderview: Just started a sync this morning, so the timing would be unfortunate if they land this afternoon |
| 14:50 | <wanderview> | we're just waiting to get the tests before landing our implementation of the enumeration |
| 14:51 | <jgraham> | Can probably try to make it work somehow though |
| 14:51 | <wanderview> | jgraham: in theory not much would have changed between this morning and the afternoon if you ran another sync? |
| 14:52 | <JakeA> | I guess someone with the appropriate rights just needs to hit the merge button on https://github.com/w3c/web-platform-tests/pull/5515 |
| 14:52 | <jgraham> | wanderview: Right, might just be possible to mush it in |
| 14:57 | <gsnedders> | if anyone has latest Edge with new-grid enabled in about:flags, what do you get for https://codepen.io/gsnedders/pen/ZJpYBY? |
| 15:03 | <jgraham> | JakeA: Merged, although I didn't notice I should squash rather than rebase, sorry |
| 15:04 | <JakeA> | wanderview: ^ |
| 15:04 | <JakeA> | jgraham: Cheers! Don't worry about the squash thing |
| 15:05 | <wanderview> | JakeA: wasn't there a "failed check" or something from travis? what was that about? |
| 15:06 | <JakeA> | wanderview: it looked like a failure to connect to webdriver, so I assumed (perhaps wrongly?) that it was just a glitch |
| 15:06 | <jgraham> | Yeah I'm not worried about that |
| 15:06 | <wanderview> | ok... I was just curious |
| 15:06 | <jgraham> | On master this PR wouldn't even run those tests |
| 15:06 | <jgraham> | Because it doesn't modify tools |
| 15:07 | <jgraham> | wanderview: Will try to pull those changes in to the sync |
| 15:07 | <wanderview> | jgraham: thanks! |
| 15:13 | <wanderview> | and thanks to JakeA for writing the test! |
| 15:13 | <JakeA> | no problem! |
| 15:41 | <JakeA> | annevk: to handle the service worker parts, I'm thinking of adding an in parallel section in step 17 of https://w3c.github.io/ServiceWorker/#handle-fetch which waits for the fetch to terminate, then queues a task to signal abort on fetchEvent.request.signal – does this sound reasonable? |
| 15:42 | <JakeA> | It means we don't need the message port stuff for the signal, although I'd still like signals to be cloneable for other uses. |
| 16:16 | <annevk> | JakeA: yeah that's probably reasonable |
| 16:17 | <annevk> | JakeA: I vaguely remember wanting to refactor more around streams since Fetch and SW have some duplicate parts, but that's probably separate |
| 16:30 | <annevk> | JakeA: I'll rereview first thing tomorrow |
| 16:31 | <annevk> | JakeA: btw, there's still quite a bit of interest on our side to do multiple boxes at some point with good enough heuristics to avoid the need for persistent storage |
| 16:32 | <annevk> | JakeA: I guess I should sketch something at some point |
| 16:33 | <JakeA> | annevk: interesting! The biggest problem is "tripit" which is low engagement but high importance |
| 16:34 | <JakeA> | But then everything is potentially high importance when you about to get on a flight or a train |
| 16:35 | <annevk> | JakeA: we're thinking about replacing LRU with some kind of score that takes into account recency and first visit |
| 16:35 | <JakeA> | annevk: doesn't that fail the tripit case? |
| 16:36 | <annevk> | JakeA: don't think so, recent visit and long ago first visit would be a high score |
| 16:37 | <annevk> | JakeA: problematic would be long ago first visit and no visit in the last x months/years |
| 16:38 | <annevk> | JakeA: or single recent visit |
| 16:38 | <annevk> | (both recent and first) |
| 16:38 | <JakeA> | annevk: that can happen. Log in January. "Tripit added your December flight" notification in June, user dismisses it. But you still want that "flight changed" notification in November |
| 16:39 | <JakeA> | Or be able to get flight into from the app offline in October etc etc |
| 16:41 | <annevk> | Hmm I guess tripit might be one of the cases that actually needs persistent then |
| 16:42 | <annevk> | Hopefully they'll use it when we ship it |
| 16:43 | <annevk> | I'd expect Netflix and such to also want persistent; it seems they have enough brand to ask the user such a thing and that way they get to control when stuff breaks offline |
| 16:43 | <annevk> | But there's a lot of cases that could be helped by better heuristics and being able to say what it's important relative to other things (if the browser needs to prune) |
| 16:44 | <annevk> | Maybe prune isn't the correct term here, but... |
| 16:47 | <JakeA> | annevk: having both works. We don't show a permission for persistent, we grant it if there's a bookmark added or add-to-homescreen |
| 16:47 | <JakeA> | Which I guess counts as a heuristic |
| 16:47 | <JakeA> | But you can query whether you have it |
| 17:06 | <annevk> | JakeA: yeah I saw, we have a prompt but we might do something like that at some point |
| 17:07 | <annevk> | JakeA: but that still requires the site explaining to the user that they have to do something and keep it that way |
| 17:07 | <annevk> | JakeA: boxes + better LRU might enable sites that don't want any of that (we've mostly heard that from game developers) |
| 17:24 | <jgraham> | annevk, JakeA: Any reason https://github.com/w3c/web-platform-tests/pull/6484 isn't merged? |
| 17:43 | <JakeA> | jgraham: there's no spec yet, but I believe annevk was happy for it to merge anyway |
| 17:43 | <JakeA> | Just needs someone to hit the button |
| 17:47 | <jgraham> | JakeA: Invited you into the org so you can merge your own PRs now :) |
| 17:47 | <jgraham> | (in particular it looks like you want to edit the commit message for that one when you squash, so I'll let you do it) |
| 17:53 | <JakeA> | Ooooo thanks! |