I've got a JS-generated fill-in-the-gap text/cloze and I'm having trouble adjusting the text boxes to the right size.
But unlike others I'm in the position of knowing exactly what the user will/should enter.
So, if I have a gap _______________ like this, I want the input to be exactly 4 characters wide. However, maybe since I'm using a proportional font (and that won't change), the width is always too large (even for a succession of capital Ds which are pretty wide).
So, what do you suggest? I tried setting the width with size, CSS width in em (too big) and ex (too narrow even for xxes).
I could calculate the width of the actual word (the one that needs to be filled in) a hidden span element, but that seems inelegant.
Is there a way to make the browser have a more accurate guess at the width of the input when I'm using a proportional font?
Monospaced Font
The best results I've seen came through using a monospace font:
<input type="text" size="4" style="font-family:monospace" />
Online Example: http://jsbin.com/epagi/edit Rendered neatly in Firefox, Chrome, Safari, and IE.
If you're using a variable-width font, you would have to use scripting to get a better guess as to what the expected width would be, but as you said, this isn't very elegant.
Variable-Width Font
I tried to work up a reasonable-simple solution for variable-width fonts, but ultimately you will need to see if it fits your project or not.
Basically what I did was set the text-transform of particular inputs to uppercase to get a semi-consistent expectation for how wide something will be when filled out with text. I then applied a classname that indicated the field should be auto-sized, and how many chars we're expecting: sizeMe-4. Using jQuery, I collected all of these inputs, and split this classname to get the number of chars expected.
I extended the String object to include a repeat method which allows me to easily create a string of the expected size, and add it to an ad-hoc span element to get the width. This width was then retroactively applied to the initial input element. The span is then discarded.
Online Demo: http://jsbin.com/epagi/2/edit
For convenience, here's the code:
<input type="text" name="pin" maxlength="4" class="sizeMe-4"
style="text-transform:uppercase" />
--
String.prototype.repeat = function(num) {
return new Array( num + 1 ).join( this );
}
$(function(){
$(":input[class^='sizeMe']").each(function(){
var size = Number($(this).attr("class").split("-").pop());
var newW = $("<span>").text( "X".repeat(size) ).appendTo("body");
$(this).width( $(newW).width() );
$(newW).remove();
});
});
Mootools
In case anybody stumbles upon this, in Mootools I just created a span containing the to-be-filled-in gap text and used these methods from Mootools More (they guarantee invisibility which is pretty important for a cloze.
$('gapsize').measure(function(){return this.getComputedSize()});
Related
An input element can have a size attribute that determines how many characters its width can hold, which is a neat feature in scenarios where the number of characters is fixed for certain types of input. For example the phone number, credit card number, customer ID number etc. In such cases it's more convenient to just put the size attribute on the input field than having to dig into the style sheet and define a width for each of them.
However, when putting the size attribute it does not take into account letter-spacing. If I want my numbers to be more spread apart, they overflow the input width. Is there any way I can specify the size of an input field taking into account letter spacing and potentially other things affecting text size?
HTML:
<input size="5" placeholder="#####"/>
CSS:
input { letter-spacing: 1em }
See this JSFiddle for the output. Notice that the placeholder text overflows the input field.
Note that this failure to account for letter-spacing when determining size happens in Chrome but not FF.
Try settingletter-spacing to set kerning between characters. This is honored when you change the size attribute.
input {
letter-spacing: 0.25em;
}
http://jsfiddle.net/RhwBG/
You can widen it dynamically using onkeypress.This might be helpful
Adjust width of input field to its input
I would like to do a trimming of the text that I need to display in box on a web page.
The known parameters are Font Family, Font Size, the number of characters to display and the actual text and of course the width of bounding box.
I need to calculate where to trim the source text and where to put "..."
I have an idea but it is not too fast.
If there exist some other way to do the trimming maybe in CSS I would like to know it and I can accept it as a solution too.
You cannot calculate this ahead of time. You need to position the actual text in the browser and measure the output. You can do this off-screen using a negative text-indent if needed.
There are plug-ins for jQuery that can set an ellipsis based on a fixed-sized container with overflow.
See: http://archive.plugins.jquery.com/plugin-tags/ellipsis
So long as you don't need to support older browsers, you could use this simple css:
text-overflow:ellipsis;
http://www.w3schools.com/cssref/css3_pr_text-overflow.aspenter link description here
Taken directly from W3Schools:
Definition and Usage The size attribute specifies the width of an
input field.
For <input type="text"> and <input type="password">, the size
attribute defines the number of characters that should be visible. For
all other input types, size defines the width of the input field in
pixels.
So..
If that is true why is my field <input type="text" size="2"/> wide enough to display 5 CAPTIAL MMMMM's ?
The same "erroneous" information is specified in the HTML4 Spec, the HTML5 spec, Sitepoint, Mozilla Developer Network, and Microsoft's MSDN library. So it isn't just W3Schools' fault.
Anyway, while the specs say that the size attribute should be the number of characters visible, most web browsers have settled on using the number of em units, meaning the width of the character of the capital M.
To specify the width precisely in pixels, or any unit of your choice, use the CSS width property.
To answer your updated question: it's the width of the capital M in the default font size as applied by CSS styling to the text box, but the font size of the text inside the text box is usually smaller.
Want to make a set number of characters fit inside the box? You'll have to switch to a fixed width font.
The problem is that the size = x attribute isn't in pixels... rather, it denotes the very approximate size that the <input /> element must be to hold x characters. So, for example, <input size=2 /> should display a input box that can hold 2 characters.
Unfortunately, this varies from font to font (esp. variable width fonts), and so you will likely observe that setting the size attribute to 2 will in fact render an input box with the size of 5 or something like that. If you use a monospace font, though, size=2 should render a text field that can hold exactly 2 characters... or at least get close.
However, to set the width of an <input> element in pixels, ems, etc., try using the width CSS property instead:
<input type="text" style="width:20px" />
The above example will make the input width exactly 20 pixels wide, excluding borders and/or padding.
You can't take that literally, as that is not possible.
The width of the element is based on the size attribute and the font size used, but it won't fit that number of characters exactly, because that is not possible.
All characters doesn't have the same width, so the characters llll will easily fit in an input with size="4", but the characters mmmm won't.
Also, there is some extra space added, so an input with size="2" will not be twice as wide as an input with size="1".
What's used as an average character width might depend on the browser. I tested in Firefox, and I haven't found any character that matches exactly, but the character * matches that average width pretty well.
The answer is that, unless using a fixed width font, the browser can't accurately determine the width of two characters. I think your two character field would probably fit two "m"s side-by-side.
As far as the correctness of w3schools, the following is from the W3C:
size = cdata [CN]
This attribute tells the user agent the initial width of the control. The width is given in pixels except when type attribute has
the value "text" or "password". In that case, its value refers to the
(integer) number of characters.
http://www.w3.org/TR/html4/interact/forms.html#edef-INPUT
The other/outer css class may affect the size or inline CSS.
My case is:
when using an outer div with a class "input-group", the size or inline style will not work at all. Removing this class of "input-group" if possible will make it work.
<div class="input-group">
<input type="text" class="form-control" required style="width:20px">
</div>
In actionscript 3, my TextField has :
CSS styling
embedded fonts
textAlign : CENTER
autoSize : CENTER
... when italics are used the very right character gets slightly cut off (specially caps).
It basically seems that it fails detecting the right size.
I've had this problem before but just wondered is there a nice workaround (instead of checking textWidth or offsetting text etc.)?
Initialize your textField as you always do, using multiline, autosize, htmlText...
Then do this little trick :
// saving wanted width and height plus 1px to get some space for last char
var savedWidth = myTextField.width + 1;
var savedHeight = myTextField.height + 1;
// removing autoSize, wich is the origin of the problem i think
myTextField.autoSize = "none";
// now manually autoSizing the textField with saved values
myTextField.width = savedWidth;
myTextField.height = savedHeight;
Not that it is much comfort to you, but Flash sometimes has trouble with this seemingly simple task. CSS styling of html TextField was a nice addition but it has caused headaches for text-rendering. In fact I very rarely use CSS for styling text for that reason. I can only imagine that combining bold, italic and normal type faces within the HTML causes Flash to get some of the width calculations wrong which causes autoSize to set the mask a tiny bit short. I hope very much that the new text rendering engine in Flash Player 10 will finally fix these issues (it certainly looks better in theory).
So my solution is never to use HTML with the exception being when I require <a> links in my text ... and there are even some tricky text shifting issues there. In those cases I avoid mixing different font weights and font styles within the same text field. All other cases I use TextFormat directly on TextField.
I suppose if you can't get out of your current architecture (for some reason) you could try adding to the end of your html encoded strings. Or you could manually set the width of the field and not rely on autoSize (as you have mentioned). But if you keep on the CSS/HTML route you may find another new and painful limitation just when you don't want it.
I've had issues with TextField masks behaving differently in the Flash preview, and in the actual browser plugin. Usually, and this is strange to me, it would appear more correctly in the browser. Have you tried running the swf in a browser to see if the problem is actually an annoyance rather than a permanent problem?
I had said this:
My in-ideal approach to solving this is to attach a change event to the TextField which always adds a space after the last character of the field. And then to remember to trim this space off when using the value.
But that didn't take into account that this probably doesn't have a change event and that it's an HTML rendered text field. To add a trailing space in the HTML text field throw in an again, that's not really fixing the problem.
I have a page that visually has two fields right on top of each other, but are actually in two different forms.
In Firefox, they appear to have the same width. In IE (IE6, IE7, IE8) they appear with different widths.
Here's a sample, I think the problem is the lack of "size="
<input id="fieldid" type="text" name="fieldname" value="" />
When you do this (without a size), what is the size?
I found some docs on HTML3 and HTML4...
but could not get a clear idea if what the default value should be.
From playing with Firebug in Firefox 3.0, it looks like it is 20 in Gecko.
In IE, it looks variable, based on some other conditions I do not understand.
UPDATE:
I did try to compare the two form's characteristics further, but was unable to isolate the variable. I did hack the file to make the both use set size=20, but the widths are still different (although less than before).
In IE6 and 7 it also appears to be 20. Without knowing more about your test conditions or results, it's difficult to say why you are experiencing "variable" default sizes.
The "size" attribute will always be rendered relative to the font size set in style. E.g. "20" at size 10 font is different than "20" at size 20 font, since "size" is relative to character widths. If you want a hard/static width, use the width css property.
Default size is 20.To increase size use "size"