Opacity property is not like the others

[migurski]

Opacity (and related comp-op) operates on a layer as a whole. However, it’s specified inline with the rest of the rules, which is confusing. This sort of thing shouldn’t work, or should perhaps throw a warning:

#foo[bar=1] { opacity: 0.2 }
#foo[bar=2] { opacity: 0.8 }

My experience has been that opacity gets set just once, for the whole layer, and I’m not sure how to predict which one would win in this case.

These properties should probably be specified on layers in the .mml file instead.

[springmeyer]

I agree that we should consider warning or throwing with "sorry opacity should only be set once per style" for the style you've provided because its not clear which wins.

But they are not exactly layer options, so I think they make more sense where they are, despite potential ambiguity, than in the mml. opacity ,comp-op, and image-filters are Style level properties, so in the case that multiple styles are used against a single layer (like when using ::attachments) it does make sense to allow opacity to be set twice like:

#countries {
  ::outline {
    line-color: #85c5d3;
    line-width: 2;
    line-join: round;
    opacity:.5;
  }
  polygon-fill: #fff;
  opacity:.1;
}

Would produce:

[migurski]

Thanks, I’ll keep this in mind when I use opacity in the future.

[springmeyer]

@tmcw - do you think it is actionable to throw if one of these style level options is detected twice inside a single attachment?

[migurski]

(also thanks for the attachments pointer—I’ve always found that feature of Carto confusing so I don’t use it and don’t reach for it when I should)

[tmcw]

@tmcw - do you think it is actionable to throw if one of these style level options is detected twice inside a single attachment?

Might be a little tricky, but seems possible.

[gravitystorm]

I'd prefer it to not throw, and to let you set the option twice. The cascading rules of CSS should be clear, that defining the same value for the second time simply overrides it.

I think that keeping the cascade might be useful when making customisations to large third-party styles - perhaps you want to track an upstream style but override one or two settings in a separate mss file (making it easier to pull in updates). Throwing if opacity is defined twice would prohibit that approach, and it's not clear why we'd treat style-level rules differently from symbolizer-level rules in any case.

[migurski]

I’d prefer it if style rules didn’t throw either, but we have here a style rule that’s not really a feature-based style rule at all. Does it belong in Carto in the first place?

[springmeyer]

logging for later reflection: as per my comment at g12n/cardboardMap@a7d37bc#commitcomment-3823331, it looks like when two image-filters are applied they are concatenated. the last should likely win, but needs more thought.