I like this approach that you suggested:
* Hijack the .gwt-Label (and .gwt-HTML while we are at it) css so Label always has that extra top offset (and left offset?) to match. How will this affect other cases of Label and HTML widgets in an app?My other thought was to use the TextField in disabled form, but that gives the user the indication that the value could be edited and maybe it isn't because it depends on a change to another field.
This last one seems the most reasonable, especially if we wired that css to only work when the Label/HTML is already in a FieldLabel, though deeply nested layouts (imagine a composite widget with a label being used as a field - we're back in the land of css inheritance problems) would still have this extra height. This makes the real problem once again clear - TextField/NumberField/ComboBox/DateField are tall, and FieldLabel is built to suit them. How can we modify either side to still be uniform?
Colin, thanks for the input, your comments and insight, as always, is extremely helpful.