Width of <input type="text"> issues

HTML & CSS
1

It has been a while since I have had to work with CSS. I got a job doing PHP and Ruby a while back.

However, my boss asked if I could do HTML/CSS and I replied, “sort of.”

I am still developing fixed layouts since my skills in HTML and CSS are minimal.

2column | Test Page

looks good in firefox/IE8/Safari however…

<div id=“sign_in”> is 14 px wider in chrome/opera when compared to firefox/IE8/Safari

This is strange since I specified ’ size=“18” ’ for the <input type=“text”>

Is there a way that I can have the <input> text boxes the same size (width) across ALL browsers?

same thing goes for the LOGIN button, 6px wider in chrome/opera when compared to firefox/IE8/Safari

I would like the “sign_in” div to be the same width for all browsers so that it aligns nicely down the right side with the rest of the content for the page

I tried to keep the markup and styling as simple as possible and streamlined as possible so it downloads superfast.

If there are any serious, glaring problems someone can see with my markup or styling I would appreciate any advice.

Thanks :blush:

2

Yes, with CSS. Try something like this:

.input_sect input {
width: 136px;
}
3

Thanks for the help this time Ralph and before as well :). I have a good memory.

Anyway, I did what you told me, but it completely destroys the layout. I think it has something to do with all the “float: left” that i am implementing, but for some reason when I insert that styling it doesn’t simply just set the width, but it explodes into chaos. I was trying to mimic the facebook login look to show someone I have the potential to get better with HTML/CSS.

4

Hm, yes, a few other things need to be adjusted too, but that’s the way to set consistent sizes, anyhow.

5

This is strange since I specified ’ size=“18” ’ for the <input type=“text”>

That size is based on a user default font setting, which means it’ll be different per browser/OS/user.

I’d advise not using “size” attributes for stylistic size settings. Ralph’s example using px in CSS is indeed the only hope you have of making something the exact pixel-width in all browsers, so for making things “look” the same, I’d use that.

Here’s what size is good for: when you need to suggest to the user what kind of data you’re expecting. Getting users to fill in forms with the right information in the right format in the right field, the FIRST time, is herding cats, since the moment someone sits down behind a computer and starts filling out a form, their IQ automatically drops by 10 points, even if they are a rocket surgeon. It’s just one of those Laws, man.

So size, if it’s sitting in the HTML, should be related to the content, not the styling. So I use it to give users a hint hint nudge nudge on approx how much data I’m expecting them to give me.

Since the size attribute is linked to user font sizes, and esp since Opera makes input incredibly retardedly tiny compared to other stuff on the page, I take how many characters I’m expecting at most and add 2 or 3 to that to get my size.

So if I’m looking for a middle initial, I might get at most 6 characters (someone may have more than one middle initial, and they may separate them with dots, so M.K.L. is likely to be the most I’d receive), so I’ll do
<input type=“text” name=“mi” id=“mi” size=“8” value=“”>
and then I’d still go ahead and check in Opera and Chrome on two OSes to make sure I’m not still in some danger of cutting off characters unnecessarily. If I am, maybe I’ll increase it to 9.

So, HTML size attribute to give hints to users on what kind of content goes in there… CSS, most likely in px units for setting hard, stable widths.

Though, if you use px, you might wanna test how the form behaves if the user needs to do text-enlarge and/or zoom. It very well may break.

6

The size attribute just sets it to some arbitrary width based on the browser settings. It doesn’t guarantee the same width between browsers and it has nothing whatever to do with how much data it can display.

As you can see from the following three capital M’s might be about the same width as eleven lowercase i’s and the size to have all of those visible might be 4 or 5. Just because the size is 5 doesn’t mean someone can’t type 500 characters into the field though - the maxlength attribute restricts how much can be entered irrespective of the width.

MMM
iiiiiiiiiii

7

Thanks everyone!

I did what Stomme poes said and stripped the size=“18” out of the <input> since it has nothing to do with styling and only content.

What ralph.m said about setting the exact width in pixels seems to work, but I had to change it up a little so it didn’t blow up in my face.

Instead of:

.input_sect input {
width: 136px;
}

I just put the width styling in the:

div.input_sect {
float: left;
margin-right: 14px;
width: 134px;
}

This seems to work a little bit better as it doesn’t explode into madness, but for some reason ALL the browsers are not recognizing the margin-right: 14px.

It looks really strange with no right margin.

Man… I was meant to be a boring scripter. This is why I gave up on front-end stuff… I just suck. I don’t know how you front-end specialists memorize all those lil browser tricks.
I’m gonna tell this guy to get another front-end guy because I now believe front-end is more maddening and more difficult than back-end scripting. All those little things that require experience unlike back-end which is pretty straightforward.

I have been staring at this for about an hour. If anyone who has ninja like skills in CSS can easily spot the problem please help me. Thank you.

The original is here:
2column | Test Page

The updated site is here:
2column | Test Page

8

I don’t know how you front-end specialists memorize all those lil browser tricks.

By spending 8 hours a day for months staring at it.

This seems to work a little bit better as it doesn’t explode into madness,

It’s doing a fine job exploding into madness over here (FF3.6.22/Ubuntu Linux with slightly enlarged fonts and no javajunk) : )
Looking at version 2, what I’m seeing is this:

the form itself isn’t containing the stuff inside it, because the stuff inside it is floated

the divs inside who are floated do indeed have the right margin, but it’s not having any effect because

the inputs inside still don’t have any CSS width set, but they were set to “display: block”. So they are like totally way wider than the divs so I can’t see the margin doing anything.

If I were you I’d do this:

First, set a fugly background colour (#f00) on the form and make it enclose its floats by arbitrarily giving it some reasonable width (in px to start) and adding overflow: hidden on it. This is temporary for testing.

Now give each div a different fugly background colour (#FF0).

For foos and giggles give the labels fugliness too (#0F0) just so you can see where they are.

Now set px widths on the inputs themselves, something much smaller than the widths you’ve set on your divs (who cares if it’s ridiculously small at this point, you just want to make sure they cannot pop out of these divs).

Now if the form has a width that’s not wide enough for those two divs to fit side by side, you should get one underneath the other. If you wanted them side by side, increase the width of the form until they all fit that way.

That ought to get you started and once you have fugly eye-burning background colours on these things you’ll find dealing with floats and junk just got way easier.

Now when you get stuff sitting where you want it, you’ll have to decide if you want to keep the overflow: hidden and width on the form (if you wanted email and password fields stacked on top of each other then I believe you will want the width, but then the floating of the divs isn’t necessary so overflow could still be removed), so maybe we’ll just see where you are after you try the testing stuff. : )

9

As a quick fix, why not just give the input a width too:

#emailid {width: 134px;}
10

Thanks ralph, it actually did help a little bit, but this thing has to be ripped down to it’s foundation and rebuilt again. I might not be a front-end guy in the future, but I’ll be damned if I’m gonna give up on this particular problem.

So I’m gonna fall back and analyze carefully what Stomme poes has taught me and see if I can rebuild it more soundly.

I will be back in a week probably with a better version of the form… I have some scripting work to catch up on or I get fired (good motivation).

Anyway, I’m just curious, but do you think the 1rst version, although not consistent across all browsers, is good enough to go with? I’m just curious what you guys think and I would never submit that to my boss and think I would still have a job… LOL.

11

I’d say no. Better to be in control of what you get, even if it’s not the same in each browser.

12

I have learned that some UAs add padding to their INPUTS. This means that when you set a width, you could be adding it to the UAs default padding. Try including the INPUT tag in your reset CSS. ( input text will look awfully tight after that and you will have to add padding, but at least you will know exactly how much you added and make your calculations for computed size based on that fact.

13

Or just explicitly state padding values on the inputs.

14

^I’d rather do this, simply because you never know when a UA will LET you add padding back in from 0.

I am still burned from back when Opera did not let me add padding back in to select dropdowns. I haven’t bothered to check if it still does this, because I stopped using * to reset padding to 0 on anything.

So I’d rather try someInput {padding: whatever;} so that whoever doesn’t allow me to do that still at least has whatever default padding they came with.