Confusion between 'id' and 'name'

[ajashton]

This is an issue I ran into in TileMill, and it could be worked around in that project, but it seems like more of a Carto issue.

If a layer is created in TileMill, the MML JSON object for that layer will have an 'id' and a 'name' key each with the same value. The id is what is used to show the layer name in the TileMill layers list, but it seems that Carto actually (confusingly) looks at the 'name' value for the #layer-style selectors. Given that in CSS the # character is used to select the id property, I think that's what Carto should do too.

For example, an MML layer that has been manually edited to have "id": "foo" and "name": "bar" will need the style selector #bar { } in the MSS in order to render correctly. (The TileMill UI instead indicates that you should use #foo { } in the layers list, and the code editor will autocomplete #foo and not #bar.)

[springmeyer]

I also just got confused by this.

As far as TileMill it appears that name and id for a given layer in TileMill are identical fields. Name was added after id by @willwhite in https://github.com/mapbox/tilemill/commit/bfcf397d7fdf4402b770c541566cf1a536efdc9c.

[tmcw]

Not sure what the action here would be - making carto pay attention to id exclusively and instead?

[springmeyer]

That seems right to me (only use id) and then circle back and figure out if/why name is even needed in TileMill

[tmcw]

@willwhite have any tips on why TileMill has both name and id?

[yhahn]

id was added originally because early versions of Backbone required it to be the primary identifier of a model.

name back in the day was mapnik's way of identifying layers and I believe we inherited the convention of referring to layers through it.

If it's possibly to only use id now this would be great all around.

[springmeyer]

ah, makes sense. Should be totally feasible then to use id across the board then. Just that when carto serializes a layer to XML it should do '<Layer name="' + id ...., since yeah, Mapnik expects name for a layer name.

[springmeyer]

/cc @artemp who just hit this so he knows we plan on fixing

[nebulon42]

Regarding backwards compatibility and a smooth transition I would propose the following:
Merge a change that uses name if present and at the same time outputs a deprecation warning which states that name will be removed in carto 1.0.0. If id is present and name isn't, use id, else error. carto 1.0.0 should be reached in the forseeable future.