ColumnSet rendering issues - As of 8.15.1 which contained SKUID-1948

Questions
1

This is a continuation from https://community.skuid.com/t/columnset-not-rendering-according-to-display-properties?rfm… which has now been closed so I can no longer update it there.

Skuid 8.15.1 contained SKUID-1948, however there appears to still be an issue with ColumnSets rendering properly.

Column labels are still wrapping when set to “Fit to Content”, two identical columns are rendered differently and the 1st column takes up more space then necessary.

Note - Repro below uses Stock Lightning Design Theme

Steps to reproduce:

  1. Create page from XML below
  2. Preview page picking an account

Expected Behavior
Column #1 - Should only require 500px (its minimum)
Column #2 - If there is enough horizontal width on display (my test case is 1600x1200) the column should appear next to Column #1 and neither the label nor the value should wrap. If there is not enough width, the column should go to the next line and label/value should not wrap
Column #3 - Same as Column #2

Actual Behavior
Column #1 - Takes up 800+ px
Column #2 - Label wraps
Column #3 - Label wraps

Screen Shots

Page XML

<skuidpage unsavedchangeswarning="yes" personalizationmode="server" showsidebar="true" showheader="true" tabtooverride="Account">    <models>
        <model id="Account" limit="1" query="true" createrowifnonefound="false" sobject="Account" adapter="" type="">
            <fields>
                <field id="Name"/>
                <field id="CreatedDate"/>
            </fields>
            <conditions>
                <condition type="param" enclosevalueinquotes="true" operator="=" field="Id" value="id"/>
            </conditions>
            <actions/>
        </model>
    </models>
    <components>
        <pagetitle model="Account" uniqueid="sk-3hKWSH-70">
            <maintitle>
                <template>{{Name}}</template>
            </maintitle>
            <subtitle>
                <template>{{Model.label}}</template>
            </subtitle>
            <actions>
                <action type="delete"/>
                <action type="clone"/>
                <action type="share"/>
                <action type="savecancel" window="self"/>
            </actions>
        </pagetitle>
        <basicfieldeditor showsavecancel="false" showheader="true" model="Account" mode="read" uniqueid="sk-3hKWSH-71" buttonposition="" layout="">
            <columns layoutmode="fixed">
                <column verticalalign="top" width="100%">
                    <sections>
                        <section title="Basics" collapsible="no">
                            <fields>
                                <columns layoutmode="responsive" columngutter="4px" rowgutter="4px">
                                    <column verticalalign="top" ratio="1" minwidth="500px" behavior="flex">
                                        <sections>
                                            <section title="New Section" collapsible="no" showheader="false">
                                                <fields>
                                                    <field id="Name" valuehalign="" type="">
                                                        <label>FiddlyFooFunFiddlyFoo</label>
                                                    </field>
                                                </fields>
                                            </section>
                                        </sections>
                                    </column>
                                    <column verticalalign="top" behavior="fit">
                                        <sections>
                                            <section title="New Section" collapsible="no" showheader="false">
                                                <fields>
                                                    <field id="Name" valuehalign="" type="">
                                                        <label>FiddlyFooFunFiddlyFoo22222</label>
                                                    </field>
                                                </fields>
                                            </section>
                                        </sections>
                                    </column>
                                    <column verticalalign="top" behavior="fit">
                                        <sections>
                                            <section title="New Section" collapsible="no" showheader="false">
                                                <fields>
                                                    <field id="Name" valuehalign="" type="">
                                                        <label>FiddlyFooFunFiddlyFoo22222</label>
                                                    </field>
                                                </fields>
                                            </section>
                                        </sections>
                                    </column>
                                </columns>
                            </fields>
                        </section>
                    </sections>
                </column>
            </columns>
        </basicfieldeditor>
    </components>
    <resources>
        <labels/>
        <css/>
        <javascript/>
    </resources>
    <styles>
        <styleitem type="background" bgtype="none"/>
    </styles>
</skuidpage>
2

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

3

Karen,

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

4

Matt~

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

Thanks!
Karen

5

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!

6

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%.
So a 100 char label and a 10 char content would cause the cell to expand to fit a 110 char data set but restrict the 100 char label to only 40% of that space.

This is not something that we are planning on changing programmatically at this time, but it can be worked around by overriding the 40% label constraint in CSS if you know you are going to be using very large labels relative to data.

Sorry for the confusion!

Thanks!
Karen

7

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?

8

Consider this my vote for Barry’s idea.

9

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!

10

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?

11

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.

12

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

13

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!