I'm not totally certain there is a reasonable fix for this - what is happening is that the Label is shorter than the TextField, so while they both start drawing at the top, the Label stops drawing sooner (due to less borders, etc), so doesn't level off as far down. If the Label class was something within GXT, we could always force exactly the same margin/border/padding as the TextFields get, but I'm not sure that even this would be reasonable.

It seems plausible that the FieldLabel could force its label text to be drawn even with the bottom of the widget it is given, but this would doubtlessly cause issue with Textarea, DualListField, and other tall fields when the labels are too far down to make sense.

Instead, what about making a Label class with CSS to give it the same offsets above and below that we expect to see in a TextField and the like?

Without measuring very precisely, this seems to get most of the way there:

Code:

line-height: 18px;
padding: 2px 5px;

However, this will push the label text back to be even with the contents of the TextField - ironically, this makes it appear out of place, since it has no white border around it.

Is there a GXT widget I could use instead of GWT's Label/HTML? Since it seems that GXT doesn't play well with GWT components in certain containers (this isn't the first time), maybe GXT needs a Label and HTML alternative.

We don't have one tailormade for this purpose - the top offset is one problem, and the left offset is another, so even when you get the top right, it is hard to make the left _look_ right.

In the past, I've just used another TextField and disabled it so it is clear it cannot be edited, but it still gets the basic decoration and is legible. The consistency with other fields makes it appear that it belongs, and the styling makes it clear that it cannot be modified.

I'm open to suggestions on how to generally resolve this. Here are our basic options:
* Make FieldLabel always measure its child, and if below a certain height, explicitly position it. This will make all FieldLabels take longer (measuring is somewhat expensive, and realigning is really expensive), resulting in poorer performing forms
* Add a LabelField - just a Label, plus a top offset. Do we modify Checkbox/Radio also then, so they are taller in all cases? What other ramifications will this have?
* 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?

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?
* Textarea/DualListField should be too tall, should have the label not align to the text
* TextField/NumberField/ComboBox/DateField are just right, and should have their bottom align to the bottom of the field label
* Checkbox/Radio/Label/HTML are too short, but the label should still align to the bottom of their first line.

I'm open to suggestions on how to generally resolve this. I'd also be open to adding a new wrapper widget that provides the same basic top/left offsets that TextField etc get (though such a solution still needs to acknowledge the left offset inconsistent appearance).

* 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?

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?

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.

Colin, thanks for the input, your comments and insight, as always, is extremely helpful.

Exact top offset and annoying left offset details notwithstanding, here's a quick example of what such an appearance could look like, starting with a straightforward subclass, and concluding with the fine-tuning css discussed earlier:

You'll need to add the following to the CSS file on the line above the CSS class definitions defined above:

Code:

@external .gwt-HTML, .gwt-Label;

Otherwise the HijackingStyle interface will not be valid. I.e., it will expect methods for each of the two class names "gwt-HTML" and "gwt-Label."

Once added, the code works fine. I did notice that I had to play with the padding a bit to make it look right. Try it in a test app in dev mode using Firebug so you can easily play with the values without too much pain.