Improve HTML rendering performance

[kanashimia]

Couple lines of CSS cut page loading and resize times by 100 times (on my machine).

Description of what content-visibility is: https://web.dev/articles/content-visibility Basically browser now doesn't render/layout invisible sections. As a downside it makes scrollbar jump around slightly when you scroll the page, as browser recalculates the layout.

Section size was calculated using the following JS code:

const getAverage = (arr) => arr.reduce((p, c) => p + c, 0) / arr.length getAverage(Array.from(document.querySelectorAll(".sect1").entries().map(([idx, el]) => el.getBoundingClientRect().height ))) getAverage(Array.from(document.querySelectorAll(".sect2").entries().map(([idx, el]) => el.getBoundingClientRect().height )))

---

This is useful for single page HTML spec with all extensions specifically.

Scrollbar jumping can be improved by specifying different intrinsic size for each section, or with some JS code, but I reasoned that it doesn't really matter much.

[CLAassistant]

All committers have signed the CLA.

[oddhack]

By "invisible" do you mean, not currently appearing in the browser window?

[kanashimia]

By "invisible" do you mean, not currently appearing in the browser window?

Yes, you can read more about it on that link.
With this change browser now assumes that invisible sections have dimensions of contain-intrinsic-size.
So that is why scrollbar cursor jumps when browser actually calculates the size of the sections.

[kanashimia]

Converted to a draft for now as there is a problem that if you open a page through URL with #anchor it doesn't jump to it, which is very important.
It works if you click on the link in the nav strip or press enter on an already opened URL in the search bar, so it is a problem only on the initial load or after reload. Not sure why is that but probably can hack around it with JS.
I will investigate this later, after the holidays. Merry Christmas!

[oddhack]

Converted to a draft for now as there is a problem that if you open a page through URL with #anchor it doesn't jump to it, which is very important. It works if you click on the link in the nav strip or press enter on an already opened URL in the search bar, so it is a problem only on the initial load or after reload. Not sure why is that but probably can hack around it with JS. I will investigate this later, after the holidays. Merry Christmas!

I have some WIP to turn the VU sections into collapsible blocks and auto-expand them when landing on them via a #anchor, via a JS fragment run on pageshowHashEvent, so there is very possibly another interaction here as well. Not ready for turning into an MR yet but wanted to give you a headsup.

[oddhack]

Also to note, getting this stuff working cross-browser and cross-platform is a right pain. Safari in particular seems to handle some of this stuff less robustly / inconsistently with desktop browsers. What you're doing here appears pretty straightforward but how it will interact with the layout algorithms and assumptions in different browsers needs to be established.

[kanashimia]

I found the issue, it was very simple, the problem was in that <script> that does loading indicator, I tried removing that script tag before, but didn't notice that it was working after that because there was a delay before jumping to the tag, heh.
I was able to fix the issue by navigating to the anchor manually after the content is loaded:
document.getElementById(window.location.hash.substring(1))?.scrollIntoView();

There is still a problem that content may shift slightly after you refresh the page, but it is a minor issue, that may be a browser bug.

I have some WIP to turn the VU sections into collapsible blocks and auto-expand them when landing on them via a #anchor, via a JS fragment run on pageshowHashEvent, so there is very possibly another interaction here as well. Not ready for turning into an MR yet but wanted to give you a headsup.

Thanks for a heads-up, that will need to be tested too indeed. I think for collapsible sections it may be better to set content visibility to none instead of auto, and trigger them to visible in JS, it should also help with scrollbar junk as everything that is collapsed has zero size anyways... now that I think about it <details> should automatically do that in chromium without any JS.

Actually if every big section was collapsed there wouldn't be any scrollbar jumping at all, and navigating the page would be easier, that is worth considering. At least collapsing .sect1 section should be ok, for .sect2 it may be annoying.

Also to note, getting this stuff working cross-browser and cross-platform is a right pain. Safari in particular seems to handle some of this stuff less robustly / inconsistently with desktop browsers. What you're doing here appears pretty straightforward but how it will interact with the layout algorithms and assumptions in different browsers needs to be established.

Yes, content-visibility is a new feature so it also needs to be tested in older browsers, I think there were couple of bugs with it before in chromium.
I tested that it works on recent chromium and firefox desktop, but need to check mobile versions and webkit based browsers too.
Viewing vulkan single page spec on mobile devices was pretty much unusable before, it can crash the browser even, I think this change will help in that aspect.

@oddhack I also have a question, that khronos.css is only used in single page documents, right? Just so I wont break anything else.

[oddhack]

I'm not sure how you mean "single page documents"? It's used in the HTML artifacts created out of the repository, but not in the Antora site at docs.vulkan.org, which has a different styling system, if that answers the question.