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);
}
Related
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.
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");
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
I have an HTML textarea:
<textarea>
Some text
Another text in another line
BOOM
Hello there.
</textarea>
I want to be able to vertically scroll to the word BOOM so that it is visible (it doesn't matter on which line it appears).
Is this possible?
There's actually a way to do this using window.find() and some variation for IE browsers.
Here's what I came up with so far:
var gotoText = function(text) {
function iefind(string) {
var txt = document.body.createTextRange();
if (txt.findText(string)) {
txt.scrollIntoView();
txt.collapse(false);
}
}
if(!window.find) { // ie
iefind(text);
return;
}
// a double window.find() for backwards and forward search
if(!window.find(text, false, true)){
window.find(text, false, false);
}
};
$('textarea').animate({ 'scrollTop': 30 });
of course 30 is working for my own example with my cols and rows. so find the the right value for yourself.
Note to self:
There is no way of calculating the scroll height which a particular word is at however if you set a fixed value as your css line-height then you can see the story from the point of view that of boom is on for example the 4th line then its scroll height value is 4x (x:line-height)
but i can't really right now be bothered to check how good that will work when someone zooms in the browser. but worth a try for you as you have the case.
But how do I know that BOOM is 30 from the top?
Create a <div>, add it to the page and style it with exactly the same font, white-space, dimensions, border, padding and overflow as the <textarea> object. Wrap the ‘BOOM’ in a <span>, and measure the position of the span relative to the position of the div.
(This isn't a lot of fun.)
It's possible with some javascript!
Even if I'm late I hope it can be usefull to someone else!
I published an answer here:
http://blog.blupixelit.eu/scroll-textarea-to-selected-word-using-javascript-jquery/
It works perfectly with jsut one needed rule: Set a line-height n the css of the textarea!
It calculate the position of the word to scroll to just by doing some simple mathematic calculation and it worked perfectly in all my experiments!
Feel free to ask me anything you need about the code!
I'm looking for a technique (javascript, CSS, whatever ???) that will let me control the amount of a string that is displayed. The string is the result of a search (and therefore not initially known). A simple Character count approach is trivial, but not acceptable, as it needs to handle proportional fonts. In otherwords if I want to limit to say 70 pixels then the examples below show different character counts (9 and 15) both measuring the same:-
Welcome M...
Hi Iain if I've ...
If you look at Yahoo search results they are able to limit the length of title strings and add ellipsis on the end of long strings to indicate more.
(try site:loot.com wireless+keyboard+and+mouse to see an example of Yahoo achieving this)
Any Ideas?
Perhaps the CSS property overflow: hidden; can help you, in conjuntion with width.
Using a span with fixed width, overflow-x:hidden and white-space:nowrap would be a start.
To get the elipsis in a cross browser scenario will be difficult. IE has text-overflow:elipsis but that is non-standard. This is emulated with -o-text-overflow in Opera. However mozilla doesn't have this. The yahoo Javascript APIs handle this.
Yahoo does this server-side, the truncation and elipsis ('...') is returned in the HTML. Presumably this is done on a character count, and if thats not an option for you then server-side is out.
Other than overflow: hidden I'm not sure CSS can help you here. You could measure the width of the containing element using Javascript, and truncate the text based on that. This could be used in conjunctin with overflow:hidden; so the text elements don't just resize all of a sudden, but you may have to extract the text and add a temporary element onto the page somewhere to do the measurement. Depending on the number of elements to truncate this might not work very well.
Another slightly hacky option is to measure the width of an element containing the letter 'W', then do a character count and truncate if (char_count * width_of_w) > desired_width.
You can use text-wrap: none; to stop text wrapping onto new lines, although this is a CSS3 property and last I checked was only supported by IE (imagine my shock when I found that one out!).
For a cross-browser pure-CSS solution, take a look at Hedger Wang's text-overflow:ellipsis prototype, here:
http://www.hedgerwow.com/360/dhtml/text_overflow/demo2.php
In CSS: .class-name{
width: 5em;
white-space: nowrap;
text-overflow: ellipsis; }
Hope it can help you.