| 01:47 | <a-ja> | mkwst, an idea: https://example.com/.well-known/clear-site-data |
| 04:53 | <mkwst> | a-ja: What would that do? |
| 07:38 | <foolip> | annevk: turns out it's a holiday tomorrow, maybe we can push out some review drafts today? |
| 07:39 | <annevk> | foolip: Domenic did not get back to me on IM |
| 07:39 | <foolip> | annevk: do we need to do them all together? |
| 07:40 | <annevk> | foolip: the plan was to publish the first 5 (lexicographically) |
| 07:40 | <hsivonen> | zcorpan: I am not aware. What's the single page test feature? |
| 07:41 | <zcorpan> | hsivonen: https://web-platform-tests.org/writing-tests/testharness-api.html#single-page-tests |
| 07:42 | <hsivonen> | zcorpan: thanks! |
| 07:42 | <zcorpan> | hsivonen: also see https://github.com/web-platform-tests/wpt/pull/11364 |
| 07:51 | <foolip> | annevk: let's just wait for Domenic to wake up. I think he's in Waterloo, so the usual timezone |
| 07:54 | <annevk> | foolip: yeah, there's no particular rush, but I'll be gone for 3.5 weeks after this week so we'd have to postpone or someone would have to take over |
| 07:55 | <annevk> | foolip: I suspect some ongoing HTML <canvas> PRs might also not land due to that, as they're progressing rather slowly |
| 07:55 | <annevk> | Timezones don't really help when you're not on the same page |
| 07:57 | <foolip> | OK. FWIW, I'll also be out next week and some of the following |
| 15:48 | <domfarolino> | annevk: Hm just saw you and foolip talking about the review drafts/timing of their publication. Was it premature for me to merge the Console one? |
| 15:50 | <Domenic> | domfarolino: nah we were just starting now, it's all good |
| 15:51 | <Domenic> | Need to get https://github.com/whatwg/whatwg.org/pull/210 merged before I feel comfortable blogging about them |
| 15:51 | <Domenic> | But https://console.spec.whatwg.org/review-drafts/2018-06/ is now a thing |
| 15:57 | <Domenic> | Ah good the images worked on console too |
| 16:13 | <domfarolino> | Is the styling (or lack thereof) of the console review draft intentional? |
| 16:14 | <annevk> | domfarolino: yes |
| 16:15 | <annevk> | domfarolino: shared a thing with you for additional context that Domenic will make public in a bit |
| 16:15 | <domfarolino> | Thanks |
| 16:22 | <domfarolino> | Looks good |
| 16:35 | <FND> | hey TabAtkins, domfarolino figured you might be able to confirm this apparent Chrome CSS bug is in fact non-standard behavor: |
| 16:35 | <FND> | https://burningchrome.com/~fnd/_/7dd9ac64-9734-4c1f-951d-e0c214fa26a5.html#s2 |
| 16:35 | <FND> | with `overflow: hidden`, targeting an element via the URI's fragment identifier does not take into account that element's border on Chrome, i.e. vertical scroll position is determined by the element's top padding edge rather than its top margin edge |
| 16:35 | <FND> | by contrast, both Firefox and Safari use the margin edge as expected |
| 16:36 | <TabAtkins> | Hmm, unsure that that's specified anywhere. But I agree the border box is the better behavior. |
| 16:37 | <FND> | thanks, that should suffice for me to file a bug |
| 16:37 | <gsnedders> | yeah, undefined |
| 16:37 | <gsnedders> | pretty sure I remember seeing this reported somewhere previously, FWIW, though who knows if I could find it |
| 16:37 | <FND> | any tips on how to phrase it better? my description seems a little cumbersome, doesn't scan well |
| 16:38 | <FND> | ah, yes, that's the problem exactly :) |
| 16:41 | <domfarolino> | FND Would you expect what you are seeing now, if the box-sixing:border-box was not specified? |
| 16:41 | FND | ponders |
| 16:41 | <domfarolino> | Personally I would, since overflow is hidden |
| 16:42 | <FND> | no, I think I'd expect the anchor to always target the visible top (i.e. margin edge) |
| 16:43 | <FND> | that is, box sizing doesn't seem directly related |
| 16:43 | <FND> | but that's just a naive user's POV, so ... Β―\_(γ)_/Β― |
| 16:44 | <domfarolino> | Hmm. But stuff in an element that "overflows" the main box would probably be considered "overflown" content if the box sizing isn't specifically border-box right? |
| 16:44 | <domfarolino> | (my terminology is likely not up-to-snuff, but hopefully the idea is clear) |
| 16:45 | FND | feels like he's being tested ;) |
| 16:45 | <domfarolino> | IMO, specifying box-sizing:border-box in this case is saying "The border box should be respected and not treated as overflown content" |
| 16:46 | <FND> | so I'm not sure I can answer your question - or even understand your scenario |
| 16:46 | <FND> | perhaps explaining why I used `box-sizing: border-box` helps us along: |
| 16:47 | <FND> | I needed the borders to visualize the test case, but didn't want it to add to the element's height (because 100%) |
| 16:47 | <domfarolino> | Right but that adds another variable |
| 16:47 | <domfarolino> | It seems that an element's border is treated as stuff that overflows the content box, unless the box-sizing is specifically "border-box" |
| 16:47 | <FND> | yes, I get that - so agree the test case can probably be reduced further |
| 16:48 | <FND> | just not sure how (it's been a long day, my brain is depleted) |
| 16:48 | FND | thinks |
| 16:49 | <domfarolino> | So with overflow:hidden, I would expect browsers to not respect a border when accounting for vertical scroll position (assuming the element's box-sizing is the usual content box). However with the box-sizing set to border-box, it should respect it, so I suspect chromium is doing something inconsistent here. I just wanted to make sure i was on the same page as you with the experiment |
| 16:50 | <domfarolino> | FND: I'd say file with something like "Box sizing is not respected in vertical scroll position when box sizing is 'border-box' " maybe? |
| 16:51 | <FND> | I'm not sure whether box-sizing isn't a red herring here |
| 16:51 | <FND> | currently reducing the test case, hang on (gotta run out in a few minutes though :/ ) |
| 16:56 | <FND> | this eliminate the border-box variable, domfarolino: https://burningchrome.com/~fnd/_/736c2586-8642-4c08-af95-ac22f3051d7f.html#s2 - does that help? |
| 16:56 | <FND> | *eliminates |
| 16:58 | <FND> | (apologies for the fugly page... ) |
| 16:59 | <Domenic> | And done: https://blog.whatwg.org/first-review-drafts |
| 16:59 | <domfarolino> | No worries. Yeah that's kinda what I was dong in the DevTools. IMO Chrome's behavior on that page makes sense, but doesn't for the other. |
| 17:00 | <domfarolino> | In other words, vertical scroll position should (again, IMO) be based on content-box when the box-sizing is content box, and border-box when border-box is specified |
| 17:01 | <domfarolino> | Domenic: \o/ |
| 17:02 | <FND> | oh, now I get what you mean, domfarolino - that seems like a good way to phrase the issue too, so shall use that |
| 17:03 | <domfarolino> | Feel free to cc me on issue (domfarolino@gmail) |
| 17:03 | <FND> | will leave it up to the Chrome folks to decide what's desirable, but currently it's inconsistent across browsers |
| 17:03 | <FND> | roger |
| 17:23 | <FND> | domfarolino: it appears I can't CC you, so https://bugs.chromium.org/p/chromium/issues/detail?id=855102 |
| 17:23 | <FND> | gotta run now, thanks for the assistance, much appreciated! |
| 22:20 | <MikeSmith> | TabAtkins: you around? |
| 22:34 | <TabAtkins> | MikeSmith: no longer at my desk for the day, but what's up? |
| 23:35 | <MikeSmith> | TabAtkins: just wanted to say, you rock :) |
| 23:36 | <MikeSmith> | last night in my working directory, I set up the wattsi pipeline with the hightlight server |
| 23:36 | <MikeSmith> | and tested it with the HTML spec build |
| 23:36 | <MikeSmith> | and the result is that in total, the build with the highlighter takes only 27 seconds |
| 23:36 | <MikeSmith> | in my environment |
| 23:37 | <MikeSmith> | which is only an 11 second increase over the build without the highlighter |
| 23:37 | <MikeSmith> | so itβs pretty blazingly fast |
| 23:46 | <TabAtkins> | Hell yeah |
| 23:50 | <TabAtkins> | Four highlights should only cost about 9 seconds run in pure Python, so almost no overhead now, sweet. |
| 23:50 | <TabAtkins> | Now if you could just cache the results of the first run, you can wipe out another 7 or 8 seconds from that. π |
| 23:51 | <Domenic> | \o/ |
| 23:51 | <Domenic> | I would not have thought of the web server solution. Very nice, folks. |
| 23:52 | <TabAtkins> | It looked easier than named pipes, is all that mattered to me.π |