show (route) relation colours in lists and comboboxes

[tyrasd]

Looks like this in the relation-membership section:

The route colour is similarly also shown in the list of search results.

[1ec5]

Should we do any validation on the colour value? As far as I know, the value should be a hex triplet or CSS color keyword, but several other valid CSS color value syntaxes aren’t valid as tag value.

[1ec5]

Also, some lines are identified by a combination of colors, which would likely be tagged as a semicolon-delimited list. We could show just the first, which could be ambiguous in some cases, or we could attempt to display a color swatch for each, or a gradient perhaps.

[Zaczero]

@1ec5
As to your first question, I believe it is unnecessary. In the vast majority of cases, the values are CSS-compliant, and for the rest, I don't think putting in extra work just to handle those would be beneficial. This could be added down the line.

I misunderstood your question during the first read. I can see how users would start using non-standard color values just to make it 'look nice' in the iD. I do support the idea of putting some additional validation for the colors before rendering them out.

Maybe such regex would suffice: ^(#[0-9a-fA-F]{3}|#[0-9a-fA-F]{6}|[a-zA-Z]{3,})$.
It matches either: short hex triplet, hex triplet, or a word with at least 3 characters.
Or, just check how this has been done in the already-existing color field.

---

To your second question, it is a cool idea that is definitely worth noting as an enhancement issue, but I don't think this lack of support should block this PR. It is non-critical, just a nice-to-have. Anyway, I wrote a small code PoC:

function stripedGradient(colors) {
  var colorArray = colors.split(";");
  var colorStops = "";
  var stopIncrement = 100 / (colorArray.length);
  var currentStop = 0;
  
  for (var i = 0; i < colorArray.length; i++) {
    colorStops += "," + colorArray[i] + " " + currentStop + "%," + colorArray[i] + " " + (currentStop+stopIncrement) + "%";
    currentStop = Math.min(currentStop + stopIncrement + 0.001, 100);
  }
  
  return "linear-gradient(180deg" + colorStops + ")";
}

var cssColors = 'red;blue;black';
var gradient = stripedGradient(cssColors);

[1ec5]

Cool, I agree that handling multiple values could be tail work, though your PoC seems well on its way toward a solution.

[Zaczero]

I wonder whether this could be applied to 'normal' color field as well:

If this PR gets merged I can make a new one with adding striped colors support to both of them.

[1ec5]

I misunderstood your question during the first read. I can see how users would start using non-standard color values just to make it 'look nice' in the iD. I do support the idea of putting some additional validation for the colors before rendering them out.

Correct, this was my main feedback. While it would be cool to be able to specify the RGBA or HSLA value of a glass-surfaced bus shelter, I think that would need to start with at least an informal tagging discussion rather than mappers stumbling upon iD’s accidental support for it and latching onto it.