Drop constants and color-ops from v8

[jfirebaugh]

No description provided.

[jfirebaugh]

Deep breath. Constants are gone from the editor. Do we want to drop them from the spec and renderers?

[lucaswoj]

Just had a good chat with @tmcw, @nickidlugash, and others about this.

It sounds like there's a good case for removing constants and color ops from the v8 spec because

• app doesn't support constants or color-ops
• the current implementation of color-ops hasn't been tested in the wild ("unused code is broken by default")
• changing the spec for color-ops after they have been released would create headaches
• removing / restoring color-ops from gl-js or gl-native only involves ~10 LOC
• we don't want to lose any information when importing / exporting styles from app (i.e. if color-ops were in the spec but not supported in app)
• no styles currently use color-ops

[lucaswoj]

Ref #38

[lucaswoj]

I think the right way forward is to remove both constants and color-ops from v8. We might want to work them into a future release.

[lucaswoj]

• Remove constants
  • JS
  • Native (Remove constants and color ops mapbox-gl-native#2046)
  • Spec
  • Styles
• Remove color ops
  • JS
  • Native (Remove constants and color ops mapbox-gl-native#2046)
  • Spec
  • Styles

[mb12]

@jfirebaugh What is the reason for this change? Does that mean we have to start inlining a constant that is used in multiple places in the style.json? For e.g. it is better to refer to a constant like this via a meaningful name rather than inline it.

    "@motorway_casing_width": {
      "base": 1.2,
      "stops": [[5, 0.4], [6, 0.6], [7, 1.5], [20, 22]]
    },

[jfirebaugh]

@mb12 We are keeping the style spec tightly focused around the core features needed by the renderers and by our online style editor (launching publicly soon). Constants don't fall into either of those categories. If you are editing styles by hand and want to use constants, you can use a preprocessing step with a tool like https://github.com/screee/screess.