Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Find a way optimizing performance of SVG in doc page without loosing CSS style inheritance inside SVGs #3858

Open
actionless opened this issue Sep 26, 2023 · 6 comments
Labels

Comments

@actionless
Copy link
Member

actionless commented Sep 26, 2023

description TBD

as @Elv13 proposed a way, it could be having JS snippet which would be manually re-setting style for img tags with svg-s, instead of using object tag

@actionless actionless added the doc label Sep 26, 2023
@actionless
Copy link
Member Author

cc @raven2cz adding you to the thread since you were also recently working on the doc page, mb you'll have more ideas of how it could be done

@actionless
Copy link
Member Author

i also wanted to reference this page as the one, on which the problem is the most reproduciable, however right now it have some other problem with SVG, i'll look into it later on as well:

https://awesomewm.org/apidoc/core_components/client.html

2023-09-26--1695726916_1446x1096_scrot

@raven2cz
Copy link
Contributor

I've been bothered for quite some time that when building 'awesome', it's primarily the SVG images that are generated/optimized. Stop me now, but I think we're not using those CSS details at all right now, and there were some issues when I tested it back then. In the end, I went with a color inversion approach that tries to find suitable shades globally based on a given skin.

Now I'm not sure if I'm using any of that CSS at all. But I have noted in my notes that the whole generation could be discarded. I haven't looked in detail. Do we even need that entire 'arsenal' that's there now?

@Elv13
Copy link
Member

Elv13 commented Oct 10, 2023

I haven't looked in detail. Do we even need that entire 'arsenal' that's there now?

Yes, it's needed. The part that take time is converting the unit test into images, not the pass that find/replace the colors, that's nearly instantaneous.

Now I'm not sure if I'm using any of that CSS at all.

Yes, high contrast modes and other accessibility features use it. See how the svg text is blue here when high contrast is enabled

image

It would be black on black if it was using <img. Black on black is not acceptable. Color inversion is not acceptable either for accessibility reasons (and because it looks wrong).

For firefox, you can try this without enabling system wide accessibility by selecting this:

image

@raven2cz
Copy link
Contributor

The CSS will have to be preserved in a way that still allows for the described changes.

About inversion. There's some function there now; it's not exactly inverting, but it's a trick to calculate an estimate of the colors for that dark skin.

Alright. So what will be the goal?

@Elv13
Copy link
Member

Elv13 commented Oct 10, 2023

Alright. So what will be the goal?

Ideally I would like for the high contrast and firefox custom color scheme to keep working. Keeping the CSS color inheritance would be a big plus if we want to make "full" themes in the future (Nord, Dracula, GitHub, etc) with support for all images.

Right now the pages are slow to load due to using <object instead of <img. This is mostly a problem for the awful.client page, which has by far the most images. If we could use JS to get the best of both world, this would be great. An alternative would be to somehow inject the image size at build time and lazy-load them, but I think that's more work (I am not a web dev).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants