We're trying to detect if an element is overflowing using this simple Javascript code:
this.clientWidth < this.scrollWidth
This works perfectly on Chrome/IE but on Firefox it fails in until there's too much overflowing.
The example can be seen here: http://colnect.com/en/coins/countries#-1;yemen
This page show a list of countries. We do vertical centering of the text if it fits in a single line. If it's too long for one line (which is why we want to detect the overflow), we change it so the text appears in two lines.
In this attachment you can see what happens on Firefox (depending on the width of your window). When the overflow isn't "big enough", it's not detected even though CSS has clearly added the ellipsis for it so it IS overflowing. First 4 "countries" shown are correct (the 4th even broke into two lines) but the others are not.
To recreate, simply start resizing your Firefox window slowly until you see where this breaks.
Any ideas? A different way to detect overflow?
Try this:
if you want to keep full name then, just remove text-overflow:ellipsis; from the selected class or id.
if you want to keep name in one line and no ... in last position, then set white-space: nowrap !important;overflow: hidden; in selected class
In my Firefox browser: (with center align and without text-overflow:ellipsis;)
(with center align and with text-overflow:ellipsis;)
you can choice any one.
I've noticed two things with your website. You are using white-space:nowrap and you have a transition: all on the cell class. I changed those to white-space:normal and disabled the transition and it worked fine with the wrapping.
The reason i disabled the transition is that I found that sometimes it takes a moment to change the text and break it to two lines :)
Give it a try and let me know if that works.
...also keep in mind that having an ellipsis for overflown elements may force the ellipsis to appear because it might be larger in width than the last character. I have encountered some times where without ellipsis the whole text could be shown, while using ellipsis removed my last character.
Please try this CodePen sample.
<div id='mydiv'>Some relatively long line of text to test an interesting question about Firefox behavior.</div>
<br><br><br>
<div id='dbgmsg'></div>
#mydiv {
width: 33%;
border: solid 1px gray;
white-space: nowrap;
overflow: hidden;
}
$(document).ready(function insertAds() {
function printWidthes(){
var clientWidth = $('#mydiv').get(0).clientWidth;
var scrollWidth = $('#mydiv').get(0).scrollWidth;
$('#dbgmsg').html("clientWidth = " + clientWidth + "<br>scrollWidth = " + scrollWidth);
}
$(window).resize(function(){
printWidthes();
});
printWidthes();
});
I've tested it on the latest Firefox version (35.0.1) on Window 7 and its behavior is absolutely correct. When the div size is less than the text size by even only one pixel then clientWidth becomes less than scrollWidth.
Try to test it on your computer; probably you have different Firefox version that causes the problem. BTW, did you saw that the numbers are wrong in debugger / print or it's just your guess? May be your site works wrong because any other reason?
I think this may be related to a (now resolved) bug in firefox.
Perhaps a different way of determining the scrollWidth and clientWidt is the answer (as brilliantly stated in why scrollwidth doesnt work) :
Apparently by hiding the element before reading the scrollWidth gives a different value than when visible.
element=document.getElementById("my_div");
var scrollWidth = $(element).css("overflow", "hidden")[0].scrollWidth;
alert('clientWidt h = ' + element.clientWidth + ', scrollWidth = ' + scrollWidth );
$(element).css("overflow", "visible");
Related
So I am working on a web app, and this is my layout. The divs use
overflow: hidden;
text-overflow: ellipsis;
white-space: nowrap;
This visually is fine, and is also fine in a JSFiddle. But with the ability to make very long names has issues in the web app. This issue comes from the fact that it isn't technically removing the overflown text. It (as you would think with the word "hidden") hides it. How would you go about detecting overflown text in the ".Name" element and removing it? I would like to keep the same look and rules. Just the text that is hidden is removed.
LINK - https://jsfiddle.net/t29ffzan/12/
The issue is that not all letters take up the same amount of space as each other. For instance I and M where M (guessing) is ~ 3x as big as I. See this explanation.
However, you can guess and get close but there's still no guarantee.
$('.Name').each(function() {
let text = $(this).text();
let width = $(this).parent('.Box').outerWidth();
let fontSize = 18 - ( 18 * 0.35 ); // Hardcoded from CSS
let count = width/fontSize;
text = text.substr(0, count);
$(this).text(text);
});
This fiddle is a working example of the above and uses the font-size in the CSS and removes ~ 35% to allow for more characters but depending on the actual letters uses the results may vary widely.
You could use a fixed width font as all the characters should take up the same amount of space. However, results still aren't going to be perfect.
Your best bet is the limit the character count when the name is created instead of having to go back and try and parse it after the fact.
For anyone that comes to this post, max-width: 40ch; worked best for me.
I am calculating the width of all the elements with a class, on desktop this works fine(all total width is 2862) and I get an exact figure. On mobile however all elements are seen to have the same width(290px) causing the overflow of the scroll to take up 2 lines.
var daywidth = 0;
$(".timetable-day").each(function(){
daywidth += $(this).outerWidth();
});
jsfiddle: https://jsfiddle.net/7j8kskf0/
I have tried width, outerwidth and this.offsetWidth(normal javascript) and I don't know what is causing this problem. Any help would be great.I am using bootstrap 3.
The code you posted here is working on Android & iOS.
See for yourself: http://pascha.org/test/test.php
Your Problem must be somewhere else.
Possible thoughts:
In bootstrap some classes expand to 100% width on mobile browsers.
I think you may have used one of these classes.
OR You have changed some style for mobile output and dont remember;-)
The solution I found from this was to give the timetable-inner/inner scroll div a min-width of 3000px in css, then modify the javascript:
$(".timetable-inner").css("min-width", daywidth + "px");
This works as expected. The space gives all the elements the ability to go on the same line then the JavaScript shrinks the div.
I am trying to figure out whether an element has ellipsis. I am using this stackoverflow answer.
When I test on IE the scrollWidth is always greater than offsetWidth. Even if there are no ellipsis, the scrollWidth is 1px greater than the offsetWidth. Works fine of Chrome, as expected.
Please check this example. This will give you different values on IE and Chrome.
Is this happening due to a bug in IE? Is it a known issue? And is there a work around?
Do you mean a an actual text ellipsis or a css one?
If text it may be better to parse the element's text for three dots at the end. Something like this:
function hasEllipsis(text){
var regex = /\.\.\.$/;
return regex.test(text);
}
Question: Is there a scenario where getBoundingClientRect and window.getComputedStyle would differ in width or height?
I just found a inconsistent width (see under) in IE when a element has box-sizing where window.getComputedStyle returns the wrong value.
So I thought about overriding just width and height with values from getBoundingClientRect but not sure if there are cases where that would fail.
Example of the problem (broken in IE): http://jsfiddle.net/bwPM8/
var box = document.querySelector('.box');
var gBCR_width = box.getBoundingClientRect().width; // always 200
var wGCS = window.getComputedStyle(box).width; // 200 some browsers, 160 in IE
Yes, there are several differences between these two functions.
getBoundingClientRect() will return a text rectangle object that encloses a group of text rectangles (the union of the rectangles returned by getClientRects() for the element, i.e., the CSS border-boxes associated with the element). The latter, getComputedStyle(), will return the computed CSS style of that element, after applying all CSS.
Therefore the resulting width and height can be drastically different.
For instance, by simply applying a transform to that element you already change the width that is returned by getBoundingClientRect():
http://jsfiddle.net/epW3c/
Moreover, even if you add a border or padding to your element, the width and height will be different in both cases.
Depending on the version of IE you're testing this on, you might be experiencing the infamous Internet Explorer box model bug which causes the interpretation of the dimensions of the element to be wrong. Make sure you're not running your page in quirks mode by adding the doctype properly.
In IE the CSS padding: 10px; cause overflow and that gives you extra size of the computedStyle..
Also IE calculates Borders separately from the object.
This sums up the answer with difference of 40px
Now with overflow:hidden; OR box-sizing: border-box; that cause value go in minus so will become 200px - 40px = 160px.
Note: Here if we remove overflow:hidden will not make any difference as the box-sizing:border-box cause the design not to grow further from defined height and width.
I have generate another fiddle 1 (without padding) which gives
'computedValue : 180px'
And with Border:0px the fiddle 2 give results
same as in other browser..
I hope this clears what causes what in IE(IE has its own mind that sometimes cause pain to developers)
IE 9 is behaving quite strangely for me. I've got a page font-size changing control that saves the users setting and then in the document ready sets the body font-size to that size. It works fine, the issue is, when a page with dropdowns loads, in IE 9, sometimes the text is cut off.
I've simplified the code down to this jsfiddle to demonstrate.
http://jsfiddle.net/z6Paz/3/
the html:
<select id="theSelect" name="theSelect" >
<option value="2" >Letter ( 8.5 x 11" )</option>
<option value="3" selected='selected'>A4 ( 8.27 x 11.69" )</option>
</select>
the css:
select
{
font-size:1em;
width:240px;
}
and the javascript:
var userPrefSizeOffset = 2;
$(function(){
var currentFontSize = $('body').css('font-size');
var currentFontSizeNum = parseFloat(currentFontSize);
$('body').css('font-size', currentFontSizeNum + userPrefSizeOffset);
});
has anyone come across this strange behaviour? is there a simple fix?
It does not happen in IE 8, or firefox, or safari, or chrome.
Select boxes in IE suffer from a long and unfortunate history of extraordinary bugs.
In the days of IE6, the select box was a windowed OS control—a wrapper for the Windows Shell ListBox that existed in a separate MSHTML plane from most other content.
In IE 7, the control was rewritten from scratch as an intrinsic element rendered directly by the MSHTML engine. This helped with some of the more prominent bugs, but some of this unhappy legacy remains. In particular: after a select box is drawn, changes via the DOM do not always propagate as one might expect.
Here, each option in the select list is drawn to exactly the right width for the text it contains when the control is first rendered. When you increase the text size of the page, IE correctly propagates the change to the control itself but does not adjust the width of the options, so text starts overflowing to the next line:
You can fix this by forcing a repaint of the select box. One way to do this is to append a single space character to the select element:
$('select').append(' ');
Alternatively, you could change the style attribute:
$('select').attr('style', '');
Of these, the .append() strategy has the fewest potential side effects and enforces better separation of style and behaviour. (Its essential impact on the DOM is nil.)
Seems IE9 issue. As a workaround, you can refresh the font-size css of select.
if(jQuery.browser.msie)
$("select").css("font-size", "1em")
Example.
http://jsfiddle.net/z6Paz/16/
Try using the % for scalability. See here for some documentation of em vs %: http://kyleschaeffer.com/best-practices/css-font-size-em-vs-px-vs-pt-vs/
It seems that expressing the font size in EMs is the cause. change to pixels and it's fine. This is probably a bug in IE 9.
This is my first reply to a question, but I found this page because I have had the same problem.
I noticed that just by adding anything to the value in the Dev Toolbar, the text appeared, so what we did was add then remove some white space, which is working perfectly.
Here's the area of our code that did the job:
$('select').children().each(function() {
$(this).html($(this).html() +' ');
$(this).html($(this).html());
});
I hope that helps someone in the future