02:02
<Krinkle>
Domenic: (/me puts foot in mouth) Did you try the PDF? :)
02:03
<Krinkle>
the single page version actually renders quite quickly in Firefox these days. I'm impressed.
05:41
<TabAtkins>
I usually know the section I'm looking for, so multipage is way way better for me 90%+ of the time
05:42
<TabAtkins>
(most of the time it's just Ctrl-F for "X ele" and then root around near there)
07:21
<MikeSmith>
twitter poll could be useful
11:30
<PiersW>
I only ever use the single page version, because of ctrl-f. But that doesn't mean the default can't change.
11:37
<annevk>
https://twitter.com/annevk/status/1313805658588938240
11:38
<annevk>
tune in tomorrow for the results
11:39
<annevk>
I wanted to include "Cover-to-cover, multiple times, then backwards at least once, and finally by picking random sections from the contents list and following all the cross-references." but it went over the character limit
11:44
<JakeA>
annevk: I hacked together a version of the single-page HTML spec that uses content-visibility to defer layout https://html-spec-with-c-v.glitch.me/
11:44
<JakeA>
In Chrome, it takes the initial layout time from 50s down to 400ms
11:46
<annevk>
JakeA: I saw that tweet, what kind of changes would be required?
11:49
<JakeA>
annevk: wrap sections of the spec in an element (probably all h2 sections and h3 sections?), then give them `content-visibility: auto; contain-intrinsic-size: 1px 5000px;` - ideally the 5000px should be a rough height of the element, which is used before layout is done properly. I guess you might use a different number for the h2 sections vs h3.
11:49
<JakeA>
I don't know if it's ready to go yet. I'm finding issues with in-page links sometimes not working. But I'm filing bugs as I find them.
11:49
<annevk>
Hmm, wouldn't that be a function of font size?
11:50
<JakeA>
And page width yeah, but it really doesn't matter if it's wildly wrong
11:50
<annevk>
Anyway, sounds interesting and I believe Domenic has been thinking about using more structural elements
11:50
<JakeA>
The more wrong the value is, the more the scrollbar will jump when layout is computed properly
11:51
<JakeA>
But meh, scrollbars are jumpy on native mobile for the same reasons
11:51
<annevk>
I see, that sounds rather janky
11:52
<annevk>
But interactive sooner is nice of course
11:52
<JakeA>
It's a tradeoff yeah. If you wanted accurate values I guess a build system could generate them for various widths? But I don't think it's a big deal vs the gains
11:52
<JakeA>
Scrolling remains smooth etc etc
11:53
<annevk>
JakeA: what if you gave it a calc()?
11:53
<annevk>
vw * some em size
11:54
<annevk>
Might still go wrong depending on unusual constructs, so hmm
11:54
<JakeA>
yeah that might give you more accurate values. Although you're either having to calculate that at build time, or come up with a generic value for all sections, which will still be massively out for some sections
11:55
<JakeA>
Since some sections of the spec are short, some are massive
11:55
<JakeA>
But… the scrollbar jumps around in the HTML spec already as it's loading. This is just doing it later
14:08
<tobie>
annevk: I have no trace of your latest update to 5953.
14:09
<tobie>
annevk: I'm not sure what's up.
14:09
<Domenic>
The scrollbar was pretty unusable in the c-v version for me... Like, I couldn't scroll down.
14:10
<tobie>
annevk: I have a hunch, though. Can you try deleting the log dump from the PR body?
14:11
<tobie>
annevk: it seems rather large, and I found an unattributed "Error: request entity too large" in the logs
14:11
<annevk>
tobie: looking
14:13
<annevk>
tobie: I elided the log and left everything else
14:13
<tobie>
annevk: OK, saw the error again here.
14:14
<tobie>
annevk: so you're clearly triggering that error
14:16
<annevk>
tobie: so that's something on your end or can GitHub not deal?
14:17
<tobie>
annevk: no, no, that's the pr-preview app itself (well the underlying Express framework, really).
14:17
<tobie>
annevk: Thanks for helping identify the problem.
14:17
<tobie>
annevk: now I have no idea what the solution is. :)
14:17
<tobie>
annevk: will research.
14:17
<annevk>
thanks!
14:18
<annevk>
I'm somewhat surprised we didn't hit this before, maybe we generate somewhat longer logs these days
14:19
<tobie>
annevk: it doesn't seem to be related to the log, really.
14:19
<tobie>
annevk: can you run it one last time?
14:23
<annevk>
tobie: you got it
14:24
<tobie>
annevk: right so that is just the payload size is an issue.
14:25
<tobie>
annevk: ok, so it's not solved for now.
14:25
<annevk>
tobie: what payload though? The size of OP?
14:25
<tobie>
yes
14:25
<tobie>
:D
14:26
<annevk>
tobie: does it also include all the revisions?
14:26
<annevk>
And how does that explain it not triggering again upon new commits?
14:26
<tobie>
annevk: no, it includes the update and the prior version.
14:26
<tobie>
annevk: so you had to run it twice to get rid of the log.
14:41
<tobie>
annevk: increased the limit from 100kb to 5mb.
14:41
<tobie>
annevk: this should do the trick
14:41
<tobie>
annevk: lmk if you still have the issue.
14:43
<annevk>
tobie: was that also the problem for IDL though?
14:43
<annevk>
tobie: I updated OP of https://github.com/whatwg/html/pull/5953 again to see if PR Preview does a thing now
14:44
<tobie>
annevk: biab
16:22
<annevk>
tobie: seems it’s still stuck
16:46
<tobie>
annevk: I managed to include a typo in a 12 character change.
16:47
<tobie>
Should be fixed now.
16:47
<tobie>
(No comment and apologies.)
16:59
<annevk>
ta, trying once more
17:25
<annevk>
tobie: I guess it seems to work, but it doesn't build for some reason
17:25
<annevk>
tobie: that might be a different problem though
17:32
<Domenic>
annevk: yeah, old PRs need rebasing
17:33
<annevk>
ah good
19:42
<Domenic>
annevk: thoughts on merging https://github.com/whatwg/html/pull/5889 , or waiting for further review?