Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use 2sp indents in sample YAML files #379

Open
pnorman opened this issue Aug 11, 2016 · 6 comments
Open

Use 2sp indents in sample YAML files #379

pnorman opened this issue Aug 11, 2016 · 6 comments

Comments

@pnorman
Copy link
Contributor

pnorman commented Aug 11, 2016

This isn't an issue with tangrams/tangram per se, but with the examples.

Most of the tangram examples use 4sp per YAML indent. After working fairly extensively with deeply indented YAML, I believe it is worth considering moving to 2sp per indent.

As it is, a fair amount of the line is used by the indentation.

I'd be willing to do a PR, except this touches multiple repos so I wanted comments first.

@meetar
Copy link
Member

meetar commented Aug 11, 2016

Hi Paul! You're absolutely right, for our house styles the spaces add up quickly. Here are my three cents:

  • Four is certainly easier to read for simpler styles
  • Lots of copy-and-pasting goes on between our styles, sticking with a single cross-example indent format facilitates this
  • The example you referenced looks fine on my laptop (with the understanding that YMMV)

I could see converting the house styles, although I don't know that our "import" feature works with differently spaced indents… @bcamper ?

@bcamper
Copy link
Member

bcamper commented Aug 11, 2016

@nvkelso what's your feedback?

I agree that deeply nested rules can be difficult to read (and when creating this syntax I'm not sure I expected the nesting to go this deep! :)

I have also thought of supporting alternative syntax like dot notation (could be backwards compatible). For example:

roads:
   highways:
      links:
         ...
roads:
   ...
roads.highways:
   ...
roads.highways.links:
   ...

This is flatter which helps with deep nesting and can provide better local context as to the layer's parent tree, but it loses some of the spatial indication of hierarchy/inheritance. (An editor like Tangram Play can also provide context of the currently highlighted layer by walking up the tree.)

@nvkelso
Copy link
Member

nvkelso commented Aug 11, 2016

Probably a good idea? Is it a file size concern or about legibility? (I think ZIP packaging addresses the file size.)

On Aug 11, 2016, at 07:06, Brett Camper [email protected] wrote:

@nvkelso what's your feedback?

I agree that deeply nested rules can be difficult to read (and when creating this syntax I'm not sure I expected the nesting to go this deep! :)

I have also thought of supporting alternative syntax like dot notation (could be backwards compatible). For example:

roads:
highways:
links:
...
roads:
...
roads.highways:
...
roads.highways.links:
...
This is flatter which helps with deep nesting and can provide better local context as to the layer's parent tree, but it loses some of the spatial indication of hierarchy/inheritance. (An editor like Tangram Play can also provide context of the currently highlighted layer by walking up the tree.)


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@nvkelso
Copy link
Member

nvkelso commented Aug 11, 2016

I can see the dot syntax being super helpful for styling layer overrides (in an import context), but I'm not sure I'd write most the basic house styles that way.

On Aug 11, 2016, at 07:06, Brett Camper [email protected] wrote:

@nvkelso what's your feedback?

I agree that deeply nested rules can be difficult to read (and when creating this syntax I'm not sure I expected the nesting to go this deep! :)

I have also thought of supporting alternative syntax like dot notation (could be backwards compatible). For example:

roads:
highways:
links:
...
roads:
...
roads.highways:
...
roads.highways.links:
...
This is flatter which helps with deep nesting and can provide better local context as to the layer's parent tree, but it loses some of the spatial indication of hierarchy/inheritance. (An editor like Tangram Play can also provide context of the currently highlighted layer by walking up the tree.)


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@matteblair
Copy link
Member

I like 2 spaces! It's really a matter of personal preference though - YAML can be indented with any number of spaces or tabs, even with different amounts within the same document.

That "dot notation" syntax is very reminiscent of TOML :) However it raises a number of semantic questions and I don't think it could be strictly backwards compatible. The . character is allowed in YAML keys so roads.highways.links could be used as a key in a scene file at present with a very different meaning than the suggested notation.

@pnorman
Copy link
Contributor Author

pnorman commented Aug 11, 2016

I have also thought of supporting alternative syntax like dot notation (could be backwards compatible). For example:

You could do this with YAML anchors and alises. Personally I prefer the structure in the indents and only use anchors and alises to reduce duplication.


Probably a good idea? Is it a file size concern or about legibility?

Purely legibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants