Text Fields not displaying properly on mobile but perfectly on desktop....

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

You phoning doctor: Doc I don't feel so good.Doctor: What seems to be wrong?You: Well, I don't know. I poked and probed a bit. Things seem to be OK. Let me send you a selfie then gimme your best guess.Doctor: After viewing the photo you sent it appears you're sweating a bit. That indicates a fever. Looks like you have the flue. Drink plenty of liquids and get some bed rest.

An hour later you're dead of a heart attack.
****

Would you, or could you count on a doctor's diagnosis based on a photograph?

Setting aside the train wreck the rest of the site is, what with the illegible color contrasts, fixed width layout, design elements that cannot be made elastic, and absurdly undersized fixed metric (px) fonts... Much less the clearing DIV like it's still 2001 and endless pointless presentational use of classes thanks to bloated rubbish like jQuery, mootools and broken CSS methodology... Setting all that aside...

Form elements do not... well... size consistently cross-browser. You are setting a fixed size on them that can't actually scale properly. Biggest problem is though you are trying to size them from the markup -- and that's so arbitrary across browsers you'll never get it right.

A good first step would be to use ACTUAL semantic markup -- since labels and inputs aren't paragraphs, I don't think the form is a subsection of "Project Management Centre" so H3 is the wrong tag... so on and so forth. So step 1, let's drag that markup kicking and screaming into something well-formed and complete; swinging an axe at the garbage you don't need... maybe using some ID's that make sense instead of the gibberish and hard to follow "MERGE2" -- that don't even match the names?!? Get rid of the non-semantic use of STRONG... the NAME attribute on elements that shouldn't have a name like the input[submit]...

Styling the input inside those DIV is a matter of just setting a percentage width in the CSS and centering them with text-align. You'll never be able to get them to have a perfect side-to-side width without ANOTHER wrapping DIV in there, so I say just eye-ball that percentage. At narrower widths it might fall apart, but at that point I'd be stripping the formatting off that outer DIV anyways so it takes less screen space.

Of course, this assumes an elastic layout with em's and percentage measurements, with the desire of the layout being at the very least semi-fluid... something you don't actually have which is why my advice would be to pitch that entire train wreck of inaccessible design in the trash, and start over with semantic markup, separation of presentation from content, and semi-fluid elastic responsive design. (yes, all THREE) -- as what you have right now is NOT an accessible design.

... and all those things I just listed are the stepping stones you should have climbed BEFORE making it responsive, since responsive is quite literally just the next step in accessible design.

Oh, and they were broken here on desktop too -- which stands to reason since I'm a large fonts/120dpi user and you didn't take the elastic behavior of the input's default font size into account.

*** side note *** I wish to hell when you set a INPUT to display:block it actually behaved like a block level element, but NO, that would be too easy. Shocking the only browser engine to actually treat form elements like normal elements is now effectively defunct.

Ok, the more I think on it, the more the double-wrapper approach I think will fit your needs better. I'll use a span so we don't need any extra classes. You style the span, while stripping style off the input. Sounds weird, but a span can be sized in a consistent manner, something a input cannot do.

I added the outline override because webkit/blink's default behavior looks really stupid when we're using SPAN for the border instead of the INPUT itself. It's a sneaky trick, but it works... all the way back to IE 5.5 if need be.

Is unlocked for easy access to the gooey bits and pieces. In the CSS you can see the reset I use, as well as the generic elastic starting point.

Should fluid width to anything you want to put it inside of -- even if you're going to keep the crappy fixed width layout, designing fluid inside the fixed width is usually easier -- ESPECIALLY if you're going to start throwing media queries at it to make it responsive as, well... fluid means it can adjust to your responsive breakpoints automatically.

Pretty much, which is why if that was my project, I'd toss the entire site and start over from scratch. It's filled with "not viable for web deployment" concepts if you actually care about accessibility.

Such brutal honesty . And I love it . Thanks for the detailed explanation deathshadow.

Yeah, I'm aware that a number of elements in the site is archaic and poorly done, and numerous times I've considered re-doing the entire thing, but the owner of the business has no intention of paying to have the site redone after forking out the cash to have the last dev do what he did.

And, against everything I've told them, they insist on keeping the horrendous color scheme, siting that it's the "official" color scheme they're using for future projects. *sigh* So there's only so much I can do at this time. Needless to say, I've a lot of work ahead of me to get things up-to-snuff.

I'll go through everything you suggested later tonight and update the thread accordingly. Thanks again.

but the owner of the business has no intention of paying to have the site redone after forking out the cash to have the last dev do what he did.

People who know nothing about websites do get a bit shy about opening up the wallet after someone ripped them off. You just have to explain to them the last guy ripped them off, and explain HOW they did so.