conditional defaults

[ansis]

In the renderers we already have different default values for -rotation-alignment based on whether symbol-placement is line or point. This isn't specified in the spec, so it doesn't show up in the documentation and it doesn't appear correctly in studio.

I think it could be a good idea to have symbol-avoid-edges also have a different default for line labels.

@jfirebaugh thoughts on how we should/shouldn't do this?

[jfirebaugh]

Yes, if these cases are necessary we should record them in the spec somehow.

[ansis]

@lucaswoj you've been working on a lot of style stuff in -js recently. Any ideas on how this should be implemented?

[lucaswoj]

I foresee us adding a lot of logic to the style spec in the near future. We should embrace the precedent set by filters and use a lisp-ey syntax.

{
    "default": ["if", ["==", "symbol-placement", "line"], "point", "line"]
}

[lucaswoj]

... hopefully this'll dovetail nicely into future data-driven styling features

[1ec5]

#104 (comment) proposes this conditional syntax as an elegant means for supporting token fallbacks via the has operator. This would make it easier to support fallbacks for nonexistent sprites: an exists operator would be far less magical than the special behavior implemented for icon-image in #104 (comment).

[lucaswoj]

@1ec5 Would the exists operator be specific to sprites?

[1ec5]

It would only be meaningful in relation to properties that deal with sprite names (or URLs once we implement #485). Could we define exists to always resolve to false for other properties?

[lucaswoj]

@1ec5 Would a general icon-exists operator work for the use case you have in mind?

[1ec5]

Yes.

[jfirebaugh]

We dealt with this by adding auto enum values for the properties in question, and documenting how they behave.

In general, conditional defaults add complexity to the implementation and the mental model required to author styles. We should try not to add more.