Barry~

The columns on your page are actually behaving as expected. I think there may be some confusion regarding fit to content versus flexible width division behavior.

Column 1 uses flexible width with a minimum width of 500 pixels. It taking up 800 pixels meets the minimum width of 500. Minimum width neither specifies a max width nor a preset width. 

Columns 2 & 3 use fit to content which means it wraps to the content of the values, without consideration of the size of the label, in setting column size. The label wraps as needed.

You noted that the labels should not wrap but this is how it was designed. This may not be ideal so I can definitely suggest taking the width of the label into account as an improvement to how Skuid operates now. Currently, if there is a large label and a small column based on the content of the column, the label will wrap. 

Thanks!
Karen

Karen,

If the columns are responding as designed, and we want to respond differently, then this is an idea, correct?

Matt~

Sure! Can you specify how you would like the columns to respond?

Thanks!
Karen

Hi Karen - 

Thanks for the info.  I see you’ve already changed this to an Idea but I’d like to revisit your points above before we change this to an idea as opposed to a problem.  

As Matt infers above and as I described in my OP here and in the original issue, “fit to content” is not behaving as a user would expected it to behave.

1) Flexible Width With a Minimum Width - I understand that this configuration does not specify the final width of the column and as long as it meets the minimum, it is correct. The fact that it’s flexible means it can take up the remaining space, whatever is available.  In the sample page, this results in 880px on a 1600x1200 screen.  We’re good on this one in principle.  That said, it’s taking up 880px when it should be taking up less than 880px and that leads us to…

2) Fit to Content - The configuration for this is at the Column level.  The Column is a “wrapper” for the label/value pair of the Field Editor.  Given that the configuration is at the Column wrapper level, it should fit all of the content inside of it.  “All” of the content includes both the label and the value, not just the value portion.  If the configuration were on the Value column itself or if the setting read “Fit to Value(s)”, then it would make sense to ignore the label but since the label is part of the content inside of the Column, it should be included.

To me, this is a problem and should be corrected in one of two ways:

1) Change the “Fit to Content” setting to “Fit to Value(s)” and create a new idea for adding a “Fit to Content” option that would include the label portion; OR
2) Include the label as “content” since it is inside of the column

#2 would of course be preferable since I would hazard a guess that most users would want and expect this to be the behavior.

Understood that the design might have been to not include the label but this is very misleading when the setting is “Fit To Content”.  “Fit to Content” should fit everything inside, ignoring the label which is part of the content does not produce the behavior a user would expect nor what the setting name implies will be done.

Look forward to your thoughts.  Thanks!

Hi~

We took another look at this.

This is currently how it works:

• The space a label takes up is defined as 40% of the parent div. 


• I was mistaken about how Fit to Contents works: it adjusts itself based on everything in the parent div (both label and contents) not just the contents of the cell. 


• Wrapping occurs when you have a label that is much larger than the data to be displayed, causing the parent to expand but limiting the label to the 40%.

Hi Karen - Thanks for taking another look at this, it makes much more sense now. The 40/60 hardcoded split of label/value has bitten me in the past and I’ve had to write css rules to override the default %. I think what might make the most sense here is to add a feature to Field Editor to provide more control over how the label/value columns are positioned. Here’s what I’m thinking - Expose a property for a field editor that allows the following choices: 1) Specific Width - This would provide two properties to specific % values for label & value columns 2) Fit to Content - This would use responsive layout to determine width of label & value column similar to what a HTML table does or what the Responsive Grid with two columns both with Flexible width would do To provide for backwards compat, the default would be “Specific Width” with 40/60 split A solution of this nature would provide the following benefits: 1) Fully backwards compatiable 2) Provide a declaritive solution within the builder to specify % for label/value which would avoid the need to write custom CSS rules (I have a ton of these currently) 3) Provide a solution to the problem specific in my OP so that columnsets can use field editor with Fit to Content to provide a 100% responsible layout all the way down to label/value Please discuss internally and let me know if you think something like this would be viable. If so, I’ll create a new idea post with this enhancement request. Matt - Would something like this solve your use case as well? Any thoughts?

Consider this my vote for Barry’s idea.

After thinking through this some more, I think it makes sense to have a separate property for Label Column and Value Column and provide all three options - Specific Width (default 40 / 60), Fit to Content and Flexible Width.  In short, make the field editor itself behave just like two separate columns in a Responsive Grid providing for a fully responsible layout.  

Karen - Look forward to yours and the teams thoughts.  Thanks!

The question with flexible width, is how do you handle the label/value combination when they are bigger than the column/editor’s max? Do you wrap just the label? Does the value for that pair appear beneath the label?

I would see it as two separate columns constrained to the width of the containing element (typically a div).  It would behave just like a Responsive Grid with two columns both set to Flexible Width would.  Typically you wouldn’t have both label & value columns set to Flexible Width but offering all 3 options on both columns gives you the flexibility to control the behavior.

Hi guys~

Thanks for your input and for helping us understand how it would be helpful to modify the existing features to support what you need better. I’ll change this to under consideration for the team to look further into for a future release. 

Karen

Hi Karen -

Finding things via search within the community is difficult enough and the idea we’re now discussing is buried way down in this thread.  

Since this post has a title that doesn’t relate to the idea that we’ve now landed on, I think its best to close this issue out and start a new idea that has a title and description for the idea itself.

I’ve created a new idea at https://community.skuid.com/t/add-support-for-responsive-layout-to-field-editor?rfm=1&……  For those that would like to see this, feel free to vote there!