src/js/tooltipster.js
function() {
		
		this.__forceRedraw();
		
		var tooltipBcr = this.__$tooltip[0].getBoundingClientRect(),
			result = { size: {
				// bcr.width/height are not defined in IE8- but in this
				// case, bcr.right/bottom will have the same value
				// except in iOS 8+ where tooltipBcr.bottom/right are wrong
				// after scrolling for reasons yet to be determined.
				// tooltipBcr.top/left might not be 0, see issue #514
				height: tooltipBcr.height || (tooltipBcr.bottom - tooltipBcr.top),
				width: tooltipBcr.width || (tooltipBcr.right - tooltipBcr.left)
			}};
		
		if (this.constraints) {
			
			// note: we used to use offsetWidth instead of boundingRectClient but
			// it returned rounded values, causing issues with sub-pixel layouts.
			
			// note2: noticed that the bcrWidth of text content of a div was once
			// greater than the bcrWidth of its container by 1px, causing the final
			// tooltip box to be too small for its content. However, evaluating
			// their widths one against the other (below) surprisingly returned
			// equality. Happened only once in Chrome 48, was not able to reproduce
			// => just having fun with float position values...
			
			var $content = this.__$tooltip.find('.tooltipster-content'),
				height = this.__$tooltip.outerHeight(),
				contentBcr = $content[0].getBoundingClientRect(),
				fits = {
					height: height <= this.constraints.height,
					width: (
						// this condition accounts for min-width property that
						// may apply
						tooltipBcr.width <= this.constraints.width
							// the -1 is here because scrollWidth actually returns
							// a rounded value, and may be greater than bcr.width if
							// it was rounded up. This may cause an issue for contents
							// which actually really overflow  by 1px or so, but that
							// should be rare. Not sure how to solve this efficiently.
							// See http://blogs.msdn.com/b/ie/archive/2012/02/17/sub-pixel-rendering-and-the-css-object-model.aspx
						&&	contentBcr.width >= $content[0].scrollWidth - 1
					)
				};
			
			result.fits = fits.height && fits.width;
		}
		
		// old versions of IE get the width wrong for some reason and it causes
		// the text to be broken to a new line, so we round it up. If the width
		// is the width of the screen though, we can assume it is accurate.
		if (	env.IE
			&&	env.IE <= 11
			&&	result.size.width !== env.window.document.documentElement.clientWidth
		) {
			result.size.width = Math.ceil(result.size.width) + 1;
		}
		
		return result;
	}
function() {
		
		this.__forceRedraw();
		
		var tooltipBcr = this.__$tooltip[0].getBoundingClientRect(),
			result = { size: {
				// bcr.width/height are not defined in IE8- but in this
				// case, bcr.right/bottom will have the same value
				// except in iOS 8+ where tooltipBcr.bottom/right are wrong
				// after scrolling for reasons yet to be determined.
				// tooltipBcr.top/left might not be 0, see issue #514
				height: tooltipBcr.height || (tooltipBcr.bottom - tooltipBcr.top),
				width: tooltipBcr.width || (tooltipBcr.right - tooltipBcr.left)
			}};
		
		if (this.constraints) {
			
			// note: we used to use offsetWidth instead of boundingRectClient but
			// it returned rounded values, causing issues with sub-pixel layouts.
			
			// note2: noticed that the bcrWidth of text content of a div was once
			// greater than the bcrWidth of its container by 1px, causing the final
			// tooltip box to be too small for its content. However, evaluating
			// their widths one against the other (below) surprisingly returned
			// equality. Happened only once in Chrome 48, was not able to reproduce
			// => just having fun with float position values...
			
			var $content = this.__$tooltip.find('.tooltipster-content'),
				height = this.__$tooltip.outerHeight(),
				contentBcr = $content[0].getBoundingClientRect(),
				fits = {
					height: height <= this.constraints.height,
					width: (
						// this condition accounts for min-width property that
						// may apply
						tooltipBcr.width <= this.constraints.width
							// the -1 is here because scrollWidth actually returns
							// a rounded value, and may be greater than bcr.width if
							// it was rounded up. This may cause an issue for contents
							// which actually really overflow  by 1px or so, but that
							// should be rare. Not sure how to solve this efficiently.
							// See http://blogs.msdn.com/b/ie/archive/2012/02/17/sub-pixel-rendering-and-the-css-object-model.aspx
						&&	contentBcr.width >= $content[0].scrollWidth - 1
					)
				};
			
			result.fits = fits.height && fits.width;
		}
		
		// old versions of IE get the width wrong for some reason and it causes
		// the text to be broken to a new line, so we round it up. If the width
		// is the width of the screen though, we can assume it is accurate.
		if (	env.IE
			&&	env.IE <= 11
			&&	result.size.width !== env.window.document.documentElement.clientWidth
		) {
			result.size.width = Math.ceil(result.size.width) + 1;
		}
		
		return result;
	}
function ( ) { this . __forceRedraw ( ) ; var tooltipBcr = this . __$tooltip [ 0 ] . getBoundingClientRect ( ) , result = { size : { // bcr.width/height are not defined in IE8- but in this // case, bcr.right/bottom will have the same value // except in iOS 8+ where tooltipBcr.bottom/right are wrong // after scrolling for reasons yet to be determined. // tooltipBcr.top/left might not be 0, see issue #514 height : tooltipBcr . height || ( tooltipBcr . bottom - tooltipBcr . top ) , width : tooltipBcr . width || ( tooltipBcr . right - tooltipBcr . left ) } } ; if ( this . constraints ) { // note: we used to use offsetWidth instead of boundingRectClient but // it returned rounded values, causing issues with sub-pixel layouts. // note2: noticed that the bcrWidth of text content of a div was once // greater than the bcrWidth of its container by 1px, causing the final // tooltip box to be too small for its content. However, evaluating // their widths one against the other (below) surprisingly returned // equality. Happened only once in Chrome 48, was not able to reproduce // => just having fun with float position values... var $content = this . __$tooltip . find ( '.tooltipster-content' ) , height = this . __$tooltip . outerHeight ( ) , contentBcr = $content [ 0 ] . getBoundingClientRect ( ) , fits = { height : height <= this . constraints . height , width : ( // this condition accounts for min-width property that // may apply tooltipBcr . width <= this . constraints . width // the -1 is here because scrollWidth actually returns // a rounded value, and may be greater than bcr.width if // it was rounded up. This may cause an issue for contents // which actually really overflow  by 1px or so, but that // should be rare. Not sure how to solve this efficiently. // See http://blogs.msdn.com/b/ie/archive/2012/02/17/sub-pixel-rendering-and-the-css-object-model.aspx && contentBcr . width >= $content [ 0 ] . scrollWidth - 1 ) } ; result . fits = fits . height && fits . width ; } // old versions of IE get the width wrong for some reason and it causes // the text to be broken to a new line, so we round it up. If the width // is the width of the screen though, we can assume it is accurate. if ( env . IE && env . IE <= 11 && result . size . width !== env . window . document . documentElement . clientWidth ) { result . size . width = Math . ceil ( result . size . width ) + 1 ; } return result ; }
Returns the size of the tooltip. When constraints are applied, also returns
whether the tooltip fits in the provided dimensions.
The idea is to see if the new height is small enough and if the content does
not overflow horizontally.

@param {int} width
@param {int} height
@returns {object} An object with a bool `fits` property and a `size` property
@public
Returns the size of the tooltip . When constraints are applied also returns whether the tooltip fits in the provided dimensions . The idea is to see if the new height is small enough and if the content does not overflow horizontally .