Fixed widths vs. percentage widths?

Is Vaadin better geared for fixed widths of its components, or do most use percentage widths?

I ask because I have Forms that when I show in my main app (which is actually in a tabsheet, then a splitpanel) and I’m using setWidth(“98%”) for example, I get a screen in which the components use up most of the space allocated to them so that as the browse window is made wider, the fields get wider too.

But if I open that same Form in a popup Window, the fields do not expand/contract with the width of the popup window.

I noted that the popup window is in a DIV that’s actually at the same “level” as my “v-app” DIV, so it’s should otherwise be the same sizes per any of my CSS/styles (that is, I have Form-specific styles, but nothing that is for Form inside of any other component).

So, I was wondering whether my desire to have forms/fields/components widths expand to fit the space given to the browser window is going to be more frustrating than not and whether I’d be better using fixed (albeit somewhat relative) sizes like “20ex” for an input field instead of “98%”.

Is there a big mix in the apps people are developing, or have people found one scheme works more consistently than the other and tend to use it (i.e. pixel-perfect vs. dynamic size layout)?

Hi,

Vaadin is made to support both - this can be a little confusing at times, since you have to remember to make sure your layout hierarchy is also sized appropriately. Which approach to use should totally depend on what’s best in each case from a usability standpoint.

Having said that, it would be very interesting to hear if people have come up with some heuristics for this! (Which was the original question, I guess :slight_smile:

The fields in your forms should certainly expand in the same way in the popup, provided that you have made your layouts expand as well - to me it sounds like you have a layout that is not set to relative size (either that, or it’s a bug…)

Two more points, just ‘for the record’ and for other people reading this (I’m not saying these are wrong in your particular application!):

I could not help noticing you said 98% instead of 100% - though there is nothing inherently wrong with this if it works with your app, you might want to consider 100% + margins, which will for instance make life easier if you have to right-align something (and you’ll end up with the same margin on both sides, which might look better in some cases).

From a usability standpoint, it’s quite often better to make fields sized according to the expected input, so that the field size indicates what is expected, and so that the eye can distinguish between different fields more easily.
Dynamically sized fields can be handy if the input is dynamic too (note that very long rows are hard to read, though).

Best Regards,
Marc

I’ve seen this 98% width/height strategy before in an other Vaadin application too. The reason this was done over there was because the devs wanted borders to the layouts. Now Vaadin’s most basic layouts, HorizontalLayout and VerticalLayout don’t support css borders. The borders make them wider than what they should be, causing unneeded scroll bars, and the 2% left out tries to compensate for that.

In my opinon (as Marc’s I guess) is that you shouldn’t fiddle with the percentages in this way to fix borders/margins/whatever - it’s just a patchup waiting to break down. With the case of borders you can use a layout that support them, like CSSLayout, and have the width as 100%

(sorry for my premature posting before)

You were right… For some reason, I set a HorizontalLayout as the Window’s Panel’s content instead of just using it’s default VerticalLayout.

Yeah, when I look, I can’t figure out why we had 98% in our code. It may have been to compensate for some early issues we had putting a TwinColSelect into a Drawer. I changed the code to use 100%, and I don’t see any adverse issue now. If I find it again, I’ll report back, but it may have been split panels in which the top has a Table at 100% and the bottom has a Form at 100%, with the form containing Drawers at 100% which themselves contained a TwinColSelect at 100%…then there would be times during browser window resizing that the Form would add scrollbars and the Drawer would appear to truncate the right side of the TwinColSelect. I suspect it was a bug in Drawer that has since been fixed.

Agreed. For fields that are known to be have specific lengths, we tend to use things like “5ex” or “5em”, but many of our fields allow for otherwise long strings where if the user makes the browser wider, we want to give them the extra room to use.

You’re probably aware of this but to make sure and for others interested:

You can add ?debug at the end of your url (ie. http://localhost:8080/MyApp?debug) which gives you a small developer window. There’s an “analyze layouts” -button which will tell you if you have relative width components inside components with undefined width. It is very useful to find out why some layout acts in an way it shouldn’t.