search

KhronosGroup / Vulkan-Site

Vulkan Documentation Project framework for integrated documentation site with spec, proposals, guide, and more
Other
25 stars 2 forks source link

New site UI appears to be doing server path-dependent rendering #35

Closed oddhack closed 1 year ago

oddhack commented 1 year ago

I put the latest build from main up at https://docs.vulkan.org/spec/latest/index.html, including a variety of UI changes and some markup fixes. There is something weird going on with the SVG logo that's clobbering part of the main document UI / sidebar navigation. But the particularly weird thing is, compare with https://docs.vulkan.org/newer/spec/latest/index.html - this is literally exactly the same files (I symlinked site/newer -> full-path-to-site on the webserver) and it does not show this behavior. Neither does it show when looking at the files locally on my workstation via file: URLs in the same browser.

@gpx1000 are you seeing this as well? The site/ hierarchy is supposed to be entirely self-contained AFAIK. I tried it in two different browsers and also a Chromium instance with no caching, and the behavior is consistent for me.

SaschaWillems commented 1 year ago

I'm not seeing any issues. Both pages look the same for me with three different browsers.

Can you add a screencap?

oddhack commented 1 year ago

Chromium guest instance, no history/cache, a few seconds ago

foo

oddhack commented 1 year ago

There are no caching (or other) proxies running on my machine and I don't know what else could be interfering here.

SaschaWillems commented 1 year ago

That's odd. But it looks like the image doesn't respect the surrounding element's max-height setting of 4.5rem. So we either could explicitly set that height for the image's css or simply use a smaller image. Could also be related to #17.

oddhack commented 1 year ago

The particular CSS fix is only relevant once we can establish why I'm seeing this behavior and you are not. My phone does not show it so that's helpful, though the UI is presented wildly differently on a 43" 4K monitor and a cheapo Android phone. I still suspect some sort of caching issue but no clue what it is.

marty-johnson59 commented 1 year ago

FWIW, I see the same problem - both on my PC (Chrome browser) and my phone (Safari).

KhronosWebservices commented 1 year ago

Probably a Cloudflare caching issue. I've disabled cloudflare for now and you should see the live data after a force refresh in the browser.

oddhack commented 1 year ago

@KhronosWebservices thanks. That's just what I'm seeing, looks good now. Is this something we could have caused or just Cloudflare having a bad day? The way I expect these updates to generally work is to extract the new zipfile on top of the webserver storage but if there's something we could do to let Cloudflare know to invalidate its caches that could be added to the process.

marty-johnson59 commented 1 year ago

Yep, working fine for me too. I think we're ready to have folks start kicking the tires. I'll shoot out an email to the WG..

KhronosWebservices commented 1 year ago

@oddhack Cloudflare has a very sticky cache, not ideal for websites in development. Once live you can either wait for the cache to expire, under an hour I believe, or, we could find out how to manually invalidate the cache from the cli on the server. The latter is how other CMSs handle cloudflare on updates.

SaschaWillems commented 1 year ago

So I guess the age-old trick of adding a random (or increasing) version number to the css script path (aka "Cachebusting") doesn't work with Cloudflare?

KhronosWebservices commented 1 year ago

@SaschaWillems Of course, forgot about invalidating via the name, that should also work. Either version the css name with gulp/yarn when you build the assets, or add ? param to it. HTML is a different story, as it will cache those pages too.

gpx1000 commented 1 year ago

Sorry was asleep for all this.

It looks like the original problem was it was still caching the CSS changes. The original version of the CSS depends upon using text as the first child and doesn't set a height other than the first child. So when it went from text to graphic and that graphic is say to 100% width you get the explosion. The updated CSS sets the max-height property on the image first child to 1.5rem if memory serves. Can probably increase that but I didn't spend a lot of time on figuring out how much height we should allow it. Just needed to restrict it's upper bounds to something kind of sensible. Whenever we do the night mode, we can give it a new setting.

As for caching, that entire conversation makes total sense to me. In addition given it's CSS quite a few browsers will do local caches and might not get the latest immediately either. But it sounds like it's all sorted now.

On Wed, Sep 20, 2023, 8:32 AM Khronos Group Web Services < @.***> wrote:

@SaschaWillems https://github.com/SaschaWillems Of course, forgot about invalidating via the name, that should also work. Either version the css name with gulp/yarn when you build the assets, or add ? param to it. HTML is a different story, as it will cache those pages too.

— Reply to this email directly, view it on GitHub https://github.com/KhronosGroup/Vulkan-Site/issues/35#issuecomment-1727962761, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA5IAYYI5FQO77MWJC664HTX3MECFANCNFSM6AAAAAA47X4XUI . You are receiving this because you were assigned.Message ID: @.***>

oddhack commented 1 year ago

@KhronosWebservices could you look into invalidating the Cloudflare cache from CLI? That sounds like it might be the least effort way to deal with this - whenever pushing a site update, also run that tool.

oddhack commented 1 year ago

Closing in favor of followon action #42.