fix: align stack order with color domain

[basbroek]

PR Description

This PR addresses long-standing issues (dating back to 2016) related to misalignment between the order of stacked marks and the domain in the color encoding. It potentially closes #1734, #6203, and #9496.

Proposed Solution

A new method has been added to the unit parser to check if a color domain is defined in the unit. If a domain is present and no custom order is set, additional encoding is injected to ensure that the color order of the mark matches the order in the legend.

Note

This is my first contribution to the project. If my code doesn't meet the project's standards or if the process I followed is incorrect, I apologise. I'm happy to refactor, feedback is very welcome!

Examples

Below are examples of specs rendered with the current code (left) and the same specs rendered with the proposed solution (right). All specs share this color encoding: "scale": {"domain": ["B", "A", "C"], "range": ["red", "blue", "green"]}

[nicolaskruchten]

(This is a very exciting PR, thank you for pushing on this!)

[domoritz]

Thank you.

[domoritz]

I think we can use stringValue from utils here.

[basbroek]

Yes, that makes sense, I have updated the code.

[basbroek]

Actually, I have a question regarding stringValue. If I understand correctly, its purpose is to escape problematic Unicode characters in strings, like explained here. So I changed my code to:

const orderExpression = `indexof(${stringValue(domain)}, datum['${stringValue(field)}'])`;

However, specs with problematic Unicode characters break the script anyway, as the following example shows: open it in the editor.

To avoid this, I think escaping or removing those characters could be handled earlier in the process. For example, this quick and dirty solution in the main compile function seems to work:

let spec = normalize(inputSpec, config);
spec = JSON.parse(
  JSON.stringify(spec)
    .replaceAll('\u2028', '')
    .replaceAll('\u2029', '')
);

Do you agree? If so, I would be happy to dig into this, though I assume that would be best handled in a separate PR?

[domoritz]

Yeah, separate pull request. We don't really try to deal with bad characters in Vega-Lite except for a few cases that have come up.

[domoritz]

Thanks for the pull request. I thought the build already included all the changes but I missed a few critical issues. Can you fix them in a follow up pull request or should I revert the pull request for now?

• In chore: build #9643 you can see that we include _year_sort_index in the accessibility description, which doesn't really make sense.
• We seem to be sorting legends in examples where we have a color scale based on bins. We shouldn't really need to do that since in that case the color order is set and not dynamic. See a179516#diff-19db8933e9f1958a1a6b1b2279c1ba4351e32f8dba97bccf898d273eba0a3eb1 for example which doesn't really need to have the sort index. We should only add the sort index when it's needed.

[basbroek]

@domoritz Thanks for your feedback. I have opened a new PR. I hope this will fix both issues.