Form input text field ff and chrome diff. render

HTML & CSS
1

Hi css experts,
I’m using form with css like following


<div id="live_search">
    <form method="get" id="livesearchform" action="#"> 
         <label class="livesearch_label">Enter query </label> 
         <input type="text" onkeyup="lookup(this.value);" onblur="fill();" id="inputString"  />
				
	<div class="" id="autoSuggestionsList">&nbsp;</div>
				
    </form>			
</div>

My css file look like this


#live_search #livesearchform #inputString,#livesearch_form #livesearchform #ps{
	width:274px;
	height:36px;
	background:left no-repeat url('../_images/live_search_bkd.jpg');
	border:0px;
	padding:0px 10px;
	/*padding:0px 0px;*/
	margin:0px 0px 0 170px; 
	color:white; 
	/* styles in template_style.css */
	}
#live_search #livesearchform#livesearchsubmit{
	position:absolute;
	top:0px;
	right:0px;
	width:245px;
	height:26px;
	background:left no-repeat url('../_images/login_bt.jpg');
	border:0px;
	cursor:pointer;
	}
#live_search label.livesearch_label{
	font-size:18px;
	position:absolute;
	left:0px;
	top:6px;
	color:white; 
}

#live_search under_label.livesearch_underlabel{
	font-size:10px;
	position:absolute;
	left:0px;
	top:6px;
	color:gray; 
}

Now as you can see from above I’m using live_search_bkd.jpg as background for input field. Chrome render this field perfectly, but I have problem on ff. Firefox shows this input field with one line above background image.
how can I solve this ?

Regards,

2

Unable to test right now but have you reset all the margins on the elements?
*{margin:0;}

3

Hi, it’s hard to see what you’re seeing without the images.

However, your background shorthand syntax isn’t quite right - the order of the properties is
background-color background-image background-repeat background-attachment background-position
e.g.

background: transparent url(../_images/login_bt.jpg) no-repeat top left;
4

I’m going to go a bit offtopic and say the form also happens to be invalid and the label needs a “for” attribute to match the id of the text input. And the CSS is waaaay heavier than you need. You really don’t need #longidname #anotherlongidname #anotherelement .class {something} because it’ll make your code hard to read and harder for your to debug.

Just my 2 cents : )

5

Tested locally, Chrome had the same problem on my machine, as did Opera.

Anyways, resetting the margins and padding for all our friends seems to line the “enter query” and background image on #live_search #livesearchform #inputString,#livesearch_form #livesearchform #ps up.

Tested locally in FF, Opera, Safari, Chrome, IE6, IE7 and IE8


* {
margin:0;
padding:0;
}
6

I agree, the specificity weight is to heavy.

7

Anyways, resetting the margins and padding for all our friends seems to line the “enter query” and background image on #live_search #livesearchform #inputString,#livesearch_form #livesearchform #ps up.

I am strongly against removing padding from everything using the * selector and especially when it comes to forms.

If there’s padding on the form itself, it’s safe enough to remove it, but not the submit for example.

8

So am i, but using the universal selector would show the OP what’s going on, so he can use his own method to reset :slight_smile:

Edit:

I should have told the OP that, i guess… But hey, it’s Sunday, even for me lol

9

Using the universal selector effects performance:
http://stevesouders.com/efws/css-selectors/universal.php
http://www.stevesouders.com/blog/2009/06/18/simplifying-css-selectors/

Formal Weirdness:
http://meyerweb.com/eric/thoughts/2007/05/15/formal-weirdness/

10

Thought it was margins :eye:. I was right…

True it does affect performance…but the noticability (butchered that spelling) is not likely.

11

Performance problems would only likely to be on large sites because the selector would have to go over every element, but it can happen.

Didn’t noticed your reply buddy, otherwise i would have kept my yap shut lol

Anyways, as i see it the OP can decide to go with the universal selector or reset along the way and only on the elements he uses :smiley:

12

Luki, it’s fine lol.

Performance problems, even on a very large site would probably still not be very noticable.

The page in question would have to be humongous but then you’d have to ask yourself, is having a page that big really a good idea? If it’s a results page you could use pagination or if it’s just a regular page cut up the content into sections for the user to read. Studies have shown (don’t ask me to quote one because I can’t lol), I think, that longer pages tend to have users exit your site. THey want an answer and they don’t want to read all day to find it.

I might be rambling now so I’ll stop :slight_smile:

13

I fully agree buddy. It’s like those css compression discussions to save loading time. The milliseconds they save are for a user hardly noticeable (maybe if he’s on a medieval connection, it does lol).

And no, you’re not rambling about those studies. I’f i’m not mistaken it’s about 15 seconds a user spends searching for the relevant info. And the info has to be above the fold…

Now, I’M starting to ramble for sure lol

14

“It’s clear that CSS selectors with a key selector that matches many elements can noticeably slow down web pages. The key is focusing on CSS selectors with a wide-matching key selector. This becomes even more important for Web 2.0 applications where the number of DOM elements, CSS rules, and page reflows are even higher.”

I’m curious if anyone (zcorpan/paul) has set up test cases?

15

I don’t think that there are actual figures to back that statement up: the fact that they can slow down a page is a logical deduction but what is ‘noticeably’ ? 1 second, 30 seconds, 1 minute…? And is ‘noticeably’ meant for dial up users, broadband users…?

When we (=web page designers, - developers) usually say that something slows a page down, it’s because we use common sense but mostly it’s not backed up with figures :smiley:

‘You should use sprites for your nav’ “Why?”
“Each one of those images is a separate HTTP-Request, and the more of those, the less efficient your page is.”
‘Makes sense but you have figures?’
“Erhm, no but you can do a google”
:smiley:

(the above is not invented but a discussion i had on a different list)

What i want to make clear is that our gut instinct tells us that it could slow down a page but not how much and if it’s worth trying some method involving more mark up or ‘high tec’ technique :wink:

16

‘Load time difference for universal selector’
http://www.stevesouders.com/blog/2009/06/18/simplifying-css-selectors/

Common sense often derives from various test cases that have been conducted in some form or another.

Figures, what do you mean :confused: ?

Every ms counts :slight_smile:

17

Hey, great link :slight_smile:

8 seconds delay in IE6, FF, Chrome, Safari all way under 2 seconds. To bad the graph jumps from 0 to 2000 ms so i can’t do an accurate estimate on safari and chrome (less the 1 second???)

common sense: not always :slight_smile:
figures: numbers :slight_smile:
ms: subjective :smiley:

18

http://stevesouders.com/efws/css-selectors/universal.php

19

Ah, testing material :smiley:

opera: page load time: 828 ms, reflow 0
safari: page load time: 808 ms, reflow 1
chrome: page load time: 931 ms, reflow 1
FF: page load time: 1134 ms, reflow 793
IE6: page load time: 2187 ms, reflow 1734
IE7: page load time: 2656 ms, reflow 2000
IE8; page load time: 250 ms, reflow 62

Our good friends IE are a bit slow but i’m wondering if a user in the real world would notice the ‘big’ difference. For me, loading and reflow was not that heavy… but i guess that’s something subjective :smiley:

20

I doubt they would notice…not everyone stares at their computer screen avidly while they wait for a page to load. They mess with other open tabs or other open programs.