I have a text input:
<input id="csv-filename" type="text" name="csv-filename" placeholder="Select a CSV file">
I have placed a label above it for a different control:
<label id="trial-csv-label" for="trial-csv">Select a CSV file</label>
Both the input and the label have identical width, height, and positioning, and the label has a higher z-index and no opacity. This is a workaround for an IE bug, which is the only reason I've created such a monstrosity.
The problem I am having is that, in IE only, a click on any part of the label which does not have text clicks through to the underlying input. (Or possibly another way of putting this is that the width of the label does not seem to stretch the full width of the input, but if you give the label a bit of opacity and an outline you see that's not really the case and you can still click through on the non-text parts of the label.) This should not be happening.
I have attempted to stop propagation, but that is not working, and I don't believe this is a propagation issue anyway.
Any ideas?
I have found this to be an IE issue that can be solved using a transparent image as the background, sometimes happens on links too.
note that I have also found that IE sometimes doesn't like the usual 1x1 transparent gif - if this happens then make it 50x50 and it should work
My goal is to create an element with hidden overflow and an ellipsis, except I want the characters on the LEFT side to be hidden and the ellipsis also to be on the left. This works for most browsers:
CSS:
#mydiv {
overflow:hidden;
white-space:nowrap;
text-overflow:ellipsis;
direction:rtl;
}
HTML:
<div id="mydiv">foobar foobar foobar</div>
Which, when #mydiv is narrower than its contents, should come out as something like:
...obar foobar
However, from what I can tell (and fair warning to anyone else who tries this, since I've seen the direction:rtl solution in several other places), the ONLY major browser that does this correctly seems to be Firefox. Safari and Google Chrome will both place the ellipsis to the left of the text, but then truncate on the right anyway, like this:
...foobar foob
IE9 and Opera get downright confused. IE truncates on the right AND makes the text overlap the ellipsis. Opera, by far the most creative, will make the overflow visible on individual words for a while (as the element gets narrower, that is), then start truncating the leftmost word, but from the right. It also fails to render the ellipsis and, in one experiment I did, even moved a ™ character all the way to the left. Really. So "foobar foobar foobar™" becomes this:
™foob foobar
As an additional note, one (extremely annoying) potential option for webkit browsers might be to set -webkit-rtl-ordering:visual which truncates on the left BUT also literally renders the characters in reverse order:
...boofraboof
So by browser- or some-kind-of-obscure-feature-sniffing one could theoretically set that property and reverse the element's text dynamically.
Is there a simple cross-browser workaround, or even a complex, JS-based one?
There are JS/Jquery based solutions to your problem. The one caveat is they are more expensive. If you are not making a bunch of changes on your page then the following solutions should work just fine.
Dotdotdot:
http://dotdotdot.frebsite.nl/
ThreeDots
http://tpgblog.com/2009/12/21/threedots-the-jquery-ellipsis-plugin/
Edit: Just to be clear, I'm seeing the same problems that you have mentioned.
Please view the following fiddle in Firefox and you will see that the line of text in the textarea is getting cut off mid way through because of the long file name, but in IE and Chrome, the line goes the entire width of the textarea and only wraps once it has reached the end. I would like to achive this same behavior in Firefox and have tried everything I can with my limited CSS skills to make it work to no avail so thought I would stop pulling my hair out and come to the pros for some help.
Fiddle: http://jsfiddle.net/yGuAy/1/
No values of word-wrap: and text-wrap: seem to work for me. However, you can omit your problem by using dashes instead of underscores in links.
If you play around with the textarea width property and font-size you can reach a desirable outcome.
JsFiddle Example
By adding style of dimension in textarea it works-
<textarea cols="70" rows="3" style="width: 675px; height: 30px;">http://www.example.com/some_dir/another_dir/some_really_long_and_complex_file_name.ext</textarea>
But this is temporary solution but can not figure out why is it so with firefox.I think problem is with " / " in url .If i removes it works but same i don't know reason.
I think the firefox is considering the last part of the string
/some_really_long_and_complex_file_name.ext
to be one single word (which is true), which may be longer than the horizontal space available in the text area, so it simply puts the the last part in the next line. So if you try increase the width of the text area it will fit horizontally.
I've got a simple textarea in a form and for some reason when I click in the textarea to begin to type, it centers the first line. I can hit backspace until it lines up at the start of textarea but I don't know why it's doing that. I've Googled and can't seem to find a reason why it would do this. Here is my jsfiddle for it:
http://jsfiddle.net/4cVkn/
I've tried text-align:left in numerous places (inline HTML and CSS) and it doesn't seem to change anything. It seems like it should be a simple fix, thanks for the help.
It isn't centred, it just has a default value of a series of space characters.
Put </textarea> immediately after the start tag instead of filling it with whitespace.
The default content of a text area is the content between its tags. Your source has something like:
<textarea name="bio">
</textarea>
so the initial value of the text area is the newline and the spaces used for indentation – the characters you can backspace over.
To get rid of them, close the tag immediately:
<textarea name="bio"></textarea>
Aside: the kind of form layout you're going for should probably be done using tables – at least until the various shiny new CSS3 layouts are better supported. Your avoiding them actually made the code less readable what with all the <br/>s.
I have the following textarea in a table:
<table width="300"><tr><td>
<textarea style="width:100%">
longstringlongstringlongstringlongstringlongstringlongstringlongstringlongstringlongstringlongstringlongstringlongstringlongstring
</textarea>
</td></tr></table>
With a long string in the textarea, the textarea stretches out to accommodate it in one line in IE7, but retains its 300px width in other browsers.
Any ideas as to how to fix this in IE?
Apply the width to the td, not the table.
EDIT: #Emmett - the width could just as easily be applied via CSS.
td {
width: 300px;
}
produces the desired result. Or, if you're using jQuery, you could add the width through script:
$('textarea[width=100%]').parent('td').css('width', '300px');
Point being, there's more than one way to apply a width to a table cell, if development constraints prevent you from applying it directly.
#Peter Meyer, Jim Robert
I tried different overflow values, to no avail.
Experimenting with different values for the wrap attribute and the word-wrap style also wasn't fruitful.
EDIT:
#dansays, seanb
Due to some awkward application-specific constraints, the width can only be applied to the table.
#travis
Setting style="word-break:break-all;" sort of worked! It still wraps differently in IE7 and FF. I'll accept this answer if nothing better comes up.
Another hacky option, but the only option that works for me - none of the other suggestions on this page do - is to wrap the textarea in a single cell table with a fixed table layout.
<table style="width:100%;table-layout:fixed"><tr><td>
<textarea style="width:100%">longstringlongstringlongstringlongstringlongstringlongstringlongstringlongstringlongstringlongstringlongstringlongstringlongstring</textarea>
</td></tr></table>
Another very hacky option, if you are stuck with a lot of constraints, but know what the surrounding dom will look like:
style="width:100%;width:expression(this.parentNode.parentNode.parentNode.parentNode.width +'px')"
not pretty, but does work in IE7.
Using jquery or similar would be a much neater solution, but it depends on the other constraints you have.
did you try...
overflow: hidden;
??
I'm not sure if it should be in the table of the textarea... experiment a bit
IE also supports the word-break CSS 3 property.
The overflow property is the way to go. In particular, if you want the extra text to be ignored, you can use "overflow:hidden" as a css property on the text.
In general, when a browser has an unbreakable object, such as a long string without spaces, it can have a conflict between various size constraints - those of the string (long) vs its container (short). If you see different behavior in different browsers, they are just resolving this conflict differently.
By the way, there is a nice trick available for long strings - the <wbr> tag. If your browser sees longstringlongstring, then it will try to fit it in the container as a single, unbroken string -- but if it can't fit, it will break that string in half at the wbr. It's basically a break point with a implicit request to not break there, if possible (sort of like a hyphen in printed texts). By the way, it's a little buggy in some versions of Safari and Opera - check out this quirksmode page for more.
I've run into this problem before. It's related to how HTML parses table and cell widths.
You're fine setting 300 as a width as long as the contents of the element can never exceed that (setting a div with a definite width inside and an overflow rule is my favorite way).
But absent a solution like the above, the minute ANY element pushes you past that width, all bets are off. The element becomes as wide as it has to to accommodate the contents.
Additional tip - encase your width values in whatever set of quotes will nest the value properly (<table width='300'). If someone comes along and changes it to a %, it will ignore the %, otherwise.
Unfortunately, you're always going to have trouble breaking strings that do not have 'natural' breaks in IE, unless you can do something to break them up via code.
For solve this issue you use space in your text,and you too use this code
overflow:hidden
Give the width in pixels.this should work properly
or, how about:
overflow: scroll;
Edit:
I actually tested this. I think the behavior is such because the width is on the table, which I believe (I have nothing to back this up) I read long ago that the table width is a suggested width, but can be expanded to accommodate its content. Not sure. I know if you use a <DIV> rather than a table, it works. Additionally, if you apply the 300 pixel width to the containing <TD> element as opposed to the <TABLE> element, it works as well. Also, the overflow: scroll does nothing! :P
Nice, funky IE behavior, for sure!
Best thing I could find to make it work, a little hacky:
wrap textarea with <div style="width:300px; overflow:auto;">
might want to play around with the overflow value