feat: Parse light-dark() CSS function by extracting the first argument and add tests.

[tacshi]

Closes #900

Added support for the CSS light-dark() function to handle SVGs exported from Draw.io with dark mode support. Previously, usvg failed to parse light-dark() and fell back to black, making text invisible on dark backgrounds.

Already tested in Zed

[tacshi]

@Its-Just-Nans Can you review this PR? I came here to fix a bug from Zed. Thanks.

[Its-Just-Nans]

@Its-Just-Nans Can you review this PR? I came here to fix a bug from Zed. Thanks.

Hi,

Maybe you should add an option to usvg::Options for the current theme and choose the light-dark value based on the option?

Note that I'm not a maintainer of resvg, only a contributor so, this is just a suggestion, but maybe not the best idea

---

Edit: there is the color-scheme css props that can be in usvg Options

[tacshi]

@Its-Just-Nans Can you review this PR? I came here to fix a bug from Zed. Thanks.

Hi,

Maybe you should add an option to usvg::Options for the current theme and choose the light-dark value based on the option?

Note that I'm not a maintainer of resvg, only a contributor so, this is just a suggestion, but maybe not the best idea

Edit: there is the color-scheme css props that can be in usvg Options

Suggestion applied.

[RazrFalcon]

In general, a low-level attribute parsing is done at the svgtypes level. It also has necessary parsing utilities to simplify resolve_light_dark implementation.

Yes, it's technically not a "SVG type", but that's how resvg is "layered".

But if it is too much work, you can just add // TODO: move to svgtypes before resolve_light_dark.

[tacshi]

In general, a low-level attribute parsing is done at the svgtypes level. It also has necessary parsing utilities to simplify resolve_light_dark implementation.

Yes, it's technically not a "SVG type", but that's how resvg is "layered".

But if it is too much work, you can just add // TODO: move to svgtypes before resolve_light_dark.

Submitted: linebender/svgtypes#59

[LaurenzV]

Thanks for the PR. However, while this might work for those tests, I'm not sure whether this is the right approach unfortunately. Firstly, I think it's a bit too hacky that we resolve light-dark by building a new string that replaces it with the evaluated value (if I'm understanding it correctly). I also don't think that we should try to parse light-dark recursively, as this doesn't make a whole lot of sense (but the problem here is more generally that we don't have a generalized mechanism for handling functions).

If I'm understanding correctly, we are also attempting to parse light_dark for every single declaration, which seems a bit wasteful to me, even if it probably won't have a noticeable performance impact.

I think the proper approach would be to support parsing light-dark inside of svgtypes when resolving paints, since light-dark essentially needs to be treated like a color. However, I need to look into it more when I find some time. Other suggestions are welcome.