Determining the best width

[SteveTheTechie]

Reference issue #717, comments 2 and 8.

Here is the essence of how I automatically determine a "best width" that will accommodate all the select options... Essentially a hidden clone of the menu is produced that is used for measuring. The clone is set up specifically to allow the container div to assume the smallest width needed to accommodate the widest option.

Determining a single option height allows us to just multiply the number of options by the native select's size attribute to determine a menu height.

This is not perfect-there is room for improvement. In particular, whether or not options can be wrapped should be set via a new option. Wrapping affects the width and the appearance.

Also, the measuring can be a bit slow. If we had a reliable way to quickly determine the widest option then we could just make a dummy menu clone with that single option for measuring which would be faster. This is an approach that I not yet explored.

	// Added to allow automatic menu sizing,  8/17/2014, Steve James
	// Reference: http://stackoverflow.com/questions/1472303/jquery-get-width-of-element-when-not-visible-display-none
	// 		http://stackoverflow.com/questions/5903112/is-it-really-impossible-to-make-a-div-fit-its-size-to-its-content
	
	_measureMenu: function() {			
		// width: auto needed to reset width when dialogs 
                //    containing multi-select are re-opened.  
		// Display: inline-block needed to force width to best fit.
		
		// Make the hidden clone for measuring...
		var $clone = this.$menu.clone()
                                 .appendTo('body')
                                 .css({visibility:'hidden',width:'auto',display:'inline-block'})
                                 .find('ul')
                                 .css({display:'inline-block'})
                                 .end()
                                 .show();
				
		// Find outer height of a hidden menu item before we display menu.																											
		this.optionHeight = $clone.find('label').outerHeight();																																	
		
		// Find best width of hidden menu before we display it; 20 is for scroll bar		
		this.menuWidth = Math.max($clone.find('.ui-multiselect-header').width(),
                                         $clone.find('.ui-multiselect-checkboxes').width()) - 20;
		$clone.remove(); 
	},

[SteveTheTechie]

I am currently digging into this again after several years. Getting reliable measurements of DOM elements can be a real challenge at times. Some of the relevant understandings that I have gained over time and via recent research:

1. Measurements can only be obtained from elements that take up space in the page layout. Elements with display:none (hidden) do not occupy space and therefore heights and widths will be zero for those elements. This is why if you look carefully, dimensions of the menu are obtained after the menu is opened (shown). Thus, the point in time when you take measurements is a relevant and important consideration. In the case of this widget, I have to wonder about how the time for animations may affect getting correct measurements.

2. Hidden elements can be measured by displaying them or by setting visibility:hidden. visibility:hidden means that space is allocated in the layout but the elements are not shown. (so you could see blank spots in the layout) One way to address this is to either temporarily move or clone them to the end of the body, out of view, sort of like what I do above.

3. jQuery appears to do some "magic" in some cases to get and set dimensions of even hidden elements. My understanding is that, in reality, jQuery actually just monkies with the DOM in some cases to force a situation where it can actually get a usable measurement. For example, it may temporarily change the css display setting to make an element visible, or it may insert a dummy div just for measuring. The jQuery methods can cause reflow lags... these can be significant depending on what is being measured. I suspect that some of the relevant "magic" is similar to what is covered in the following: https://stackoverflow.com/questions/1473584/need-to-find-height-of-hidden-div-on-page-set-to-displaynone

4. However, even though jQuery has some creative ways of getting / setting measurements, they are not perfect, and they have changed with different jQuery versions. This means that any thing that uses the jQuery measurement methods may have jQuery version dependencies and may get different results depending on which jQuery version is used. As an example, take a look at the following:
   different result of width() and height() since jQuery 3.0 jquery/jquery#3193

[SteveTheTechie]

My thoughts on how to improve this widget re: measurements.

1. Measure / set dimensions once only and cache the computed results. If a cached value is detected, either use it to set dimensions (in some cases) or avoid redundantly setting measurements that do not need to be set again. Certain types of callbacks or events may invalidate the cache, which forces the values to be recalculated on the next open. Additionally, the relevant measurement functions may take a recalc parameter, which forces the cached values to be recalculated.

2. The _setMenuHeight function currently iterates and sums the heights of all menu items. This is totally unnecessary, particularly with the size option I am adding to use the native select's size attribute for vertically sizing the menu. The key insight is that once the loop has determined that the summed height of the examined menu items exceeds either option height setting or if the number of examined items equals the native select's size attribute (if size option being used), the the loop can abort. The only purpose of the loop is to determine what height is needed to contain "# items shown=size attribute" or if the actual height summation is less than the specified option height. For large numbers of options, being able to abort the vertical size summation loop is an optimization that allows the menu to be opened with a bit less of a delay.

3. The _getMinWidth function uses the parent's outer width in its percentage calculation. Shouldn't it be the inner width, which is based on element.clientWidth? I thought that percentage dimensions were based on the client area, but maybe I am mistaken?

4. We need an option to allow or prevent text wrapping. In my experience, text wrapping is a source of some problems with this widget. Wrapping is not handled by the css.

5. We need a way to get a "best fit minimum width", which is what my cloning method tries to do. "Best fit minimum width is the minimum width required to show all the list items without needing horizontal scrolling. Horizontal scrolling is not really set up in the css (no overflow-x setting) anyway. In my fork, I have a minWidth "auto" option, which triggers the determination of "best fit minimum width".

[SteveTheTechie]

_getOuterWidth & _getOuterHeight functions (no jQuery version dependencies)... notice that they can also handle hidden elements:

_getOuterWidth: function(el, withMargins) {
	if (!el) 
		return null;
	 
	var el_style = window.getComputedStyle ? getComputedStyle(el) : el.currentStyle;	// el.currentStyle is IE-compatible		 
	if (el_style.display === 'none' || parseInt(el_style.maxWidth, 10) == 0)
		return this._unHide4Dims(el, this._getOuterWidth, withMargins);
		 
	var width = el.offsetWidth || 0;
	if (!!withMargins)
		width += parseInt(el_style.marginLeft) + parseInt(el_style.marginRight);
	
	return width;		 
 },
 
 _getOuterHeight: function(el, withMargins) {
	if (!el) 
		return null;
	 
	var el_style = window.getComputedStyle ? getComputedStyle(el) : el.currentStyle;	// el.currentStyle is IE-compatible		 
	if (el_style.display === 'none' || parseInt(el_style.maxHeight, 10) == 0)
		return this._unHide4Dims(el, this._getOuterHeight, withMargins);
	 
	var height = el.offsetHeight || 0;
	if (!!withMargins)
		height += parseInt(el_style.marginTop) + parseInt(el_style.marginBottom);
	
	return height;		 
 },
 
 // Temporarily unhides hidden elements to allow dimensions to be obtained.
 // Reference: https://stackoverflow.com/questions/1473584/need-to-find-height-of-hidden-div-on-page-set-to-displaynone
_unHide4Dims: function(el, fxn, withMargins) {
	 if (!el) return null;
	 
	var el_style = window.getComputedStyle ? getComputedStyle(el) : el.currentStyle;	// el.currentStyle is IE-compatible
	var el_display = el_style.display;
	var el_position = el_style.position;
	var el_visibility = el_style.visibility;
	
	el.style.position = 'absolute';
	el.style.visibility = 'hidden';
	el.style.display = 'block';
	
	var dim = fxn.call(this, el, withMargins) 
	
	el.style.display = el_display;
	el.style.position = el_position;
	el.style.visibility = el_visibility;
	
	return dim;
}

[SteveTheTechie]

Measurement to-do's (some are done in my "pre-PR" code):

• 1. Implement caching of dimensions and a way to invalidate the caching.

• 2. Rework the _setMenuHeight function.

• 3. Confirm whether the measurement of outer height of the native select for % calc should instead be an inner height basis.

• 4. Implement a text wrapping option and a way to manage it.

• 5. Implement a minWidth: 'auto' option and a way to determine best fit width. (maybe cloning method)

• Your thoughts?

[mlh758]

I was going to say 1 might be a bit heavy if we can avoid it given the improvements of the others, but if you've already implemented it then fair enough.

2. I certainly agree, it would probably reduce the menu open time of that 5,000 item list in the speed test substantially since it would stop much sooner.

3. I wasn't even aware of the existence of clientWidth. I was using outerWidth because everything else in here was using it so it kept things consistent internally with the widget. It's also what people seemed to expect. However, it would seem reasonable to size the percentage based on the actual element box rather than grabbing the outer boxes of margin and padding as well.

4. Useful to have, should be in a separate issue though.

5. What would be an expected algorithm for a sane minimum width in 90% of cases? Maybe let this parameter be a function instead so the developer can pass it in at their discretion?

[SteveTheTechie]

I did a test with your gist code wherein I wrapped the native select in a 250px wide div with a 1px red border, then set the minWidth option of the multiselect to be '100%'.

When I do this with the current code, the right edge of the button obscures the red right border of the div.

If I change from using outerWidth of the parent to using innerWidth in getMinWidth(), no overlap happens and the button fits horizontally perfectly.

Therefore, I conclude from this test that my assertion is valid that innerWidth should be used instead of outerWidth for % widths.

Before I had a hunch... now with this test it is proven, and I will make the change.

This completes item 3 above.

[mlh758]

I appreciate you doing the test first. Thanks for making the change.

[SteveTheTechie]

@mlh758 : I request that we collaborate on this a bit. There are a number of subtle nuances to consider in setting / determining widths that factor into this. It is not that difficult... just a number of things to factor in.

1. I can kill text wrapping now for the menu... I essentially have an option for that in my WIP code and can see it working.
2. There is a good bit of CSS that factors into the width--you cannot get around that. For example, the jQuery UI ui-state-hover class adds 4px width to each menu item everytime you hover on an item. (2px for l/r border and 2px for l/r padding) Thus, a 4px minimum "fudge factor" is needed to account for this. The bolding of the hovered text also adds width, so some factor would have to be added for that, also. If you do not account for it, the width of the hover highlight is too short.
3. The extreme test case that helps is setting minWidth = 0 in the options. This is a nonsense value, but it does force the menu width to be set to whatever the minimum button width is. This is a narrow width that helps see the effect of shutting off the text wrapping in the menu.
4. The minimum required width of the menu can really only be determined once the menu is opened, since widths of hidden elements cannot be reliably determined. To get a proper "minimum" value, the text wrapping must be shut off.
5. The menuWidth option overrides whatever minWidth is determined and sets the menuWidth directly. This kind of makes the minWidth option pointless and redundant in that case. Also, I wonder if this could result in a menu that is a different size than the button... Isn't that stylistically bad?
6. Here are some questions:

a. Should the button width and the menu width be aligned and equal? (I tend to think so.)

b. Right now, the menuWidth option is not checked when setting the button width. If the button and menu are supposed to be equal width, I would think you would check the menu width when setting the button width.

c. Why are two width options needed? Since some string parsing of minWidth is already being done, couldn't we just have a menuWidth option, and have '>=150' mean 150px is a minWidth or '>=50%' is a minWidth? Alternatively, a setting of 150 (number or string) would just be a fixed menu width.

d. When I look at the Harvest Chosen widget options https://harvesthq.github.io/chosen/, it allows setting a fixed % width. I think that would be good also.

e. This really just ends up being a case of keeping the button width in sync with the menu width if the intention is to keep them equal. You set the button with either a fixed menu width or the minimum button width needed, and if no fixed menu width, then you determine a best menu width on the first menu open (and cache it) and adjust the button width w/ that.

[mlh758]

Your first 5 points I'll have to think about a little bit, but I can answer a couple of the questions now:

a. I don't necessarily think so. The button only really needs to accommodate the header links and whatever message is displayed for checked items (3 of 6 selected for example). The menu can be much wider. Useful if a form doesn't have a lot of space, or you want to put several selects in a row.

b. This is because of the assumption in a, that a wider menu could be useful. I'm open to challenging this assumption, more modern widgets like Chosen and Select2 seem to keep the button and menu the same width.

c. This is a good idea that could help simplify the options. We could even leave a lot of the internal code the same and just process the width option first and setting the minWidth and width options appropriately.

d. This would pair well with c since a lot of the same logic can be used.

e. It seems like we would need to have the menu visible first, then adjust the button's width, then hide the menu rather than waiting until the first opening. Otherwise the button's width would change after the first time the widget was opened and that would be surprising. Unless I'm misunderstanding.

There seems to be two options for getting the measurements:

1. Clone the menu somewhere like you suggested earlier, take the measurements, and apply them to the widget. The downside is that this can be expensive.

2. Start with the menu open, then close it (unless autoOpen is true) once measurements are done. The downside here is that with long lists the menus would probably be briefly visible to the user before hiding.

It seems like it might be a good idea to drop the multitude of width options and go with a menu and button that are the same width at all times. The minWidth option, from this perspective, seems like a bandaid to deal with wide options on a narrow button whose width was determined independently of the menu. If the button's width is determined based on the menu a minimum width seems less necessary. You would just need a width option to override the calculations if you wanted consistently sized buttons in a form. This is where text wrapping or ellipses might come back into play.

[SteveTheTechie]

a. I don't necessarily think so. The button only really needs to accommodate the header links and whatever message is displayed for checked items (3 of 6 selected for example). The menu can be much wider. Useful if a form doesn't have a lot of space, or you want to put several selects in a row.

b. This is because of the assumption in a, that a wider menu could be useful. I'm open to challenging this assumption, more modern widgets like Chosen and Select2 seem to keep the button and menu the same width.

I have to wonder if the "groupColumns" option maybe comes into play for this to allow sufficient menu width--I do not know if Chosen or Select2 have a comparable option. This option was not in my original fork of a couple years ago, and I did not originally understand it. I have since fiddled around with it a bit... Even though the layout was a bit jarring to look at first, I now think it is an innovative layout, and I can see where it could be useful.

c. This is a good idea that could help simplify the options. We could even leave a lot of the internal code the same and just process the width option first and setting the minWidth and width options appropriately.

d. This would pair well with c since a lot of the same logic can be used.

Ok, I will move in the direction of a single, unified width option then.

e. It seems like we would need to have the menu visible first, then adjust the button's width, then hide the menu rather than waiting until the first opening. Otherwise the button's width would change after the first time the widget was opened and that would be surprising. Unless I'm misunderstanding.

I think you got it. However, I am not sure how obvious the button width change would be... it depends on how much of a change.

Also, you have kind of sold me on not necessarily keeping the button width the same as the menu width, particularly for the sake of the groupColumns option.

Also, you are correct that doing a clone to check width is expensive. That is why I continued to use fixed width options even after I had created an "auto" width option. However, the auto width is useful for cases where options are added dynamically and the native select's parent element does not constraint width or in cases where I just was lazy (lol) and did not want to figure out a good width.

[SteveTheTechie]

The following looks interesting:
https://stackoverflow.com/questions/5429372/how-to-set-width-of-li-based-on-its-longest-contents-width

However, I do think outerWidth() needs to be used as opposed to css('width')... this is in one of the comments on this page if you dig deep enough.

Also found the following:
https://codepen.io/cssgrid/post/matching-width-to-content-with-intrinsic-sizing

[mlh758]

Meanwhile, block level elements fill the width of their container by default. What if we want the width of a block-level container to be determined by its content? Here's where intrinsic sizing comes in, currently supported by all browsers except IE & Edge.

Ah Microsoft...

One advantage we have is that we already have to process all the options in the select to build out the option list. Assuming we go down the route of not hiding the menu until after it is built, this would let us take a measure of each element and essentially keep a running maxWidth as we build the menu. Once it's done we can apply that to the button and menu, plus the fudge factor you mentioned earlier if necessary.

Also, you have kind of sold me on not necessarily keeping the button width the same as the menu width, particularly for the sake of the groupColumns option.

You should have let me let you talk me out of it! If we want to keep the menuWidth option we could just apply that to the menu after determining the menu/button width via the algorithm.

[SteveTheTechie]

What about maybe having both buttonWidth and a menuWidth options? If only one is set to a value (vs null), then the implication could be that both are set to the same as appropriate. We could support % widths on the buttonWidth, but probably not on the menuWidth. (since by design, it pops up and overlays content)

If we support using '>=150' or similar for each, this would be clearer than a minWidth option which is kind vague about what width the minimum applies to.

You are correct that we could maybe do a width determination as we build the option list. However, keep in mind that the content must be visible (in the visible layout) to get dimensions and that could factor in. Another confounding challenge that I am aware of is that the parent elements of whatever you are measuring can have an impact on the determined width. (e.g., if the parent element's width constrains the child element's width) This is why if you measure a clone, it should be appended to the body so that the width is not constrained.

Let me do a bit more research and fiddling on this. I know that this is something that has been handled by others... I just need to find the approach.