The tree view on the side no longer works in Chrome

[isiahmeadows]

Interestingly, this silently fails, without even a console error.

[leobalter]

works for me. Maybe it's cache?

[leobalter]

works for me. Maybe it's cache?

[isiahmeadows]

This was in a newly loaded incognito window, so it can't be that.

[isiahmeadows]

This was in a newly loaded incognito window, so it can't be that.

[bterlson]

@isiahmeadows can you link to the version with the broken toc?

[bterlson]

@isiahmeadows can you link to the version with the broken toc?

[isiahmeadows]

Actually, it's just being super slow for me. Not "not working", just slow. I'll close this.

[isiahmeadows]

Actually, it's just being super slow for me. Not "not working", just slow. I'll close this.

[isiahmeadows]

By any chance, could Bikeshed be modified (semver major) to use JS to reduce the amount of data rendered to the DOM at a time? It's sequential enough it shouldn't be too hard to generate the JS, and it should help the rendering time of the HTML version by a lot.

(This is probably best suggested over there, but ¯\(ツ)/¯)

[isiahmeadows]

By any chance, could Bikeshed be modified (semver major) to use JS to reduce the amount of data rendered to the DOM at a time? It's sequential enough it shouldn't be too hard to generate the JS, and it should help the rendering time of the HTML version by a lot.

(This is probably best suggested over there, but ¯\(ツ)/¯)

[ljharb]

Doing that would make "find in page" not work.

[ljharb]

Doing that would make "find in page" not work.

[bterlson]

I have been looking into this some time, but it's a lot of work. It would break native "find in page" but you can implement the same functionality in JS. It can even be better than native (e.g. server-side find with caching can be much faster on a giant document).

[bterlson]

I have been looking into this some time, but it's a lot of work. It would break native "find in page" but you can implement the same functionality in JS. It can even be better than native (e.g. server-side find with caching can be much faster on a giant document).

[allenwb]

Whatever you do, please make sure it is still usable offline.

[allenwb]

Whatever you do, please make sure it is still usable offline.

[bterlson]

That's a negative. Taking a page from Allo, the spec is now a Web App that only works in Chrome.

[bterlson]

That's a negative. Taking a page from Allo, the spec is now a Web App that only works in Chrome.

[domenic]

I forgot to say earlier, but I also would prefer not lazy-loading or overriding Ctrl+F or any other fancy tricks. The way the spec is now works great. It can be a bit slow to load, but that's OK; that's a fair price to pay compared to the drawbacks of lazy-rendering.

Some kind of secondary URL for a multipage or lazy-rendered version might make sense, like we do for HTML, but I'd like to keep the current architecture as the default. Actually, I'm OK with it even not being the default, as long as it's an option.

[domenic]

I forgot to say earlier, but I also would prefer not lazy-loading or overriding Ctrl+F or any other fancy tricks. The way the spec is now works great. It can be a bit slow to load, but that's OK; that's a fair price to pay compared to the drawbacks of lazy-rendering.

Some kind of secondary URL for a multipage or lazy-rendered version might make sense, like we do for HTML, but I'd like to keep the current architecture as the default. Actually, I'm OK with it even not being the default, as long as it's an option.

[bterlson]

Non-snark reply: certainly! Gh-pages will always just be a static rendering. My comment above is something for a different domain entirely.

[bterlson]

Non-snark reply: certainly! Gh-pages will always just be a static rendering. My comment above is something for a different domain entirely.