Hmm, it seems like we backed off the "everything should be snapped to the grid" idea we used to have.  https://folio.googleplex.com/chrome-ux-specs-and-sources/Chrome%20browser%20(MD)/Secondary%20UI%20Previews%20and%20specs%20(exports)/Spec#%2FSPEC-secondary-UI-07c-layout.png no longer mentions that.

Maybe the answer is that we just don't snap anything to the grid and close this.  Because if we want to snap to the grid, then some of the different offsets mentioned in that above page don't work AFAICT.

->bettes to clarify the intended rules and if we can get away with no grid snapping anywhere, which seems to be what the current general rules show.

Raising priority since general questions like this should be figured out soon

It's unclear to me if a decision here is necessary to move forward with v1 of Harmony. We've discussed this offline, but failed to record anything on a bug. 

Taking http-auth as the example (e.g. http://httpbin.org/basic-auth/user/passwd ).

Current state:
 * There is fixed padding between the max-length label and the start of the textfield column

Possible alternatives:
 1. The length of labels in a textfield stack "round up" to the next multiple of 16 (then add fixed padding)
 2. Snap-to-grid for GridLayout (this bug), a more general fix if we need this round-up/snapping behaviour in other situations


If the spec decision is that we are happy with "Current State" for phase 1, then there's nothing to do (yet).

If we just want textfield stacks to round up, we can do the simpler fix (i.e. (1.), above)

If this grid/width snapping is a more general problem for Harmony layout logic (now or in phase 2), then we should explore this further.

Deleted: Screen Shot 2017-08-17 at 10.06.29 пр.об..png 32.5 KB

	Screen Shot 2017-08-17 at 10.06.29 пр.об..png 32.5 KB View Download

Thanks Trent. I think alternative #1 is a good place to start with. It's unclear to me how much of a problem this will be for the entire system, so I hesitate to sink more time into alternative #2 if it's not going to give us much. 

Do we need alternative #1?  I honestly think it will make things look worse than our current behavior, by making the space between labels and textfields appear random to the user (the user can't see where the 16 DIP grid would be that the textfields are effectively being snapped to).  It's also more annoying to code.

I really want us to say we're happy with this as-is, forever, and close.

->bettes to clarify the rationale for why alternative #1 is an improvement over the current state.

The screenshot in #6 LGTM. 
The canary implementation of http://httpbin.org/basic-auth/user/passwd LGTM. 

So my presumption of how we got there is alternative #1. 

If that's not the case, then I don't understand the debate we're having and we should discuss in-person. 

Decision from the meeting today: no snap-to-grid, we'll just use harmony layout units (and similar) for padding between wherever one column of elements end and the next starts.