Cross Browser problem fixing for chorme

hey folks,
i m developing a webpage, in which i fixed the cross browser compatibility issues for IE and Firefox (created conditional classes for IE) but when i opened in chorme, its like same as it was in IE before having conditional. how do i fix that in chome, also instead on putting conditional in head are, can i make a sperate css file and import them (i tried but didn’t seemed to work)

As Deathshadow said, how can yo uexpect us to help you if we are in the dark? Sure you have described the issue, but that could be hundreds of things If Chrome has hte same issues as IE, then most likely IE is just not to blame, it’s you :slight_smile:

You say you can’t post the code, or a link. SOL IMO :slight_smile:

Post a link to your site and I’ll take a look at it.

I usually develop for IE last… and use a conditional style sheet for IE. I have never actually had any issues with Chrome so far. It seems like a pretty compliant browser. I always develop using FireFox and then test all other compliant browsers… then IE last.

same here and i was like what happened to chorme

What is the issue? Can you describe it in detail?

don’t have them uploaded yet.

Most likely there is something else at play then :). Link?

i don’t have the pages, right now

i have created inline conditional in page. its applying in IE but in firefox the normal css is working but in chorme. its as it was in IE without conditional

Can you post the inline style.

I am sorry. I think I am a bit confused. :slight_smile:

Let me try to understand…

So you have created a conditional style sheet for IE. Have you linked to it in the head?

When you look at the page in Chrome, the conditional styles are applying to is as well?

@nimpkish i already did in post 1

Without the markup we really can’t help you – but if it’s working in FF and not safari/chrome and you resorted to that IE conditional comment nonsense for IE, I would suspect the very methods used to build the page are at fault relying on broken error correcting behaviors in FF and not on valid code or reliable page construction techniques.

But no code/link/etc, that’s just a wild guess. “and this is why we can’t help you”

I usually leave my ‘for_others’ pages up indefinitely or until the person I did the page for says to take it down – so take your time.

Off Topic:

It no longer sees files linked in the CSS for building pages like “Document size” or “view image information” pages… and since that’s the #1 and #2 things I use the web dev toolbar FOR (since everything else it does I do in Opera)


FF 3.5.4 (I downgraded since 3.6 breaks the web dev toolbar)

Sheeet, it does??

So far I’ve kept 3.6x at bay because of the stolen/missing Properties menu (I use that one) and tab mis-order, but what happened to the toolbar?[/ot]

@deathshadow, thanks i haven’t given it a read as i had been very busy. will those pages be up till weekend? as i will have time to read on weekend n fix my problem?

I ended up writing it two different ways.

First, using div and semantic tags, which meant resorting to some extra background images to faux-columns a few sections. It resorts to a lot of trickery and IE specific behavior files to make up for missing pieces, but for the most part renders as closely cross-browser as you’re going to get without a table:

Looks perfect in IE8 and Opera, is close enough for gov’t work on FF, and isn’t too bad in Webkit based like Chrome and Saffy.

BUT – it relies on extra images, it’s not AS good as we could do appearance wise in legacy IE and Webkit, so I committed a cardinal sin and made a version using tables. Where this differs from your original is that rather than trying to float all those separate tables using non-semantic markup on the fieldsets, I just wrapped all the fieldset in TD set some widths and colspans…

Which ends up less markup and fewer handshakes — yeah, tables take longer to load, RIGHT.

It’s not exactly semantic since this isn’t exactly tabular data, but it’s better behaved with less code; so like many forms I’d probably be willing to look the other way on that – besides one of the definitions of a table is “an orderly arrangement of data into rows and columns” - It could be considered semantic under those terms.

I redid the outer border to only use one image - that same image also used to build the tabs. Again, less files == less handshakes == faster page loads.

The border technique I used is dynamic width capable, so should you want to use it on smaller elements you can.

Because of the fixed width and fixed layout all the fonts had to be declared in PX - I’m not wild about that and that’s an accessibility /FAIL/ but sadly it goes with the territory of forms.

The biggest problem with form elements is that no two browsers treat them the same way, since the specification doesn’t even say how or even IF they are supposed to accept styling. FF won’t let you set the width on input[file], FF adds a fixed px padding you have zero control over, IE adds a fixed EM padding you have zero control over (in addition to any you declare) – One obeys line-height ignoring height, the other obeys height ignoring line-height (damned if I can keep who’s who straight), FF puts border INSIDE the width like the ‘broken’ IE box model when nobody else does (hence a few lines being a hair narrower in FF), in IE, FF and Safari they are all ‘special’ elements treated with their own rules, while Opera treats them as just another inline-block element (THE MOST SENSIBLE APPROACH IMHO!)

So it’s no wonder you were having issues.

As to how both of them work with the labels and inputs - the breaks between them are there only for people viewing with CSS off. You turn the CSS off you still get nice pretty fieldsets. You disable tables ala handheld, you again get a nice formatting.

The labels are set to inline-block so we can put a width on them. Fix the width, and all your input/select/textarea’s line up. Piss simple. The lack of line-breaks would be an issue if not for the inline-block of the next item wrapping, and that’s how the two columns in the top left fieldset are actually formed. I targeted every other ID by name there to add a right-margin to slide the next label over until it lined up with the fieldset below it’s content.

In the DIV version, it uses floats on the div much as you were on your multiple tables. I have a few extra div in there as wrappers to apply faux-columns and float clearing effects as needed. The tricky part is making the right-most column the full height - I could have just done faux-columns there, but getting ‘right’ to line up across all browsers is unlikely. (thanks firefux) so instead I exploit that height:100% on an absolute inside a position:relative container will expand to the parent… in everything but IE6/earlier, but we can use an expression to fake that. This chops off the bottom border of our right column though (100% + 1px border == 100%+2) so I pulled the border off all three columns at that point and used another faux-column image there.

All that extra faux-column crap though is enough to send one screaming back to tables where it’s a lot simpler. I used cellpadding on the table since we can’t trust border-spacing cross-browser, and then just set the widths and colspans on everything and put the desired borders on the TD. This version ended up so simple compared to the other it’s the one I’d recommend even if it is tables for layout. If form elements actually behaved cross browser, then I’d look at the other one.

As with all my examples the directory:

is unlocked for ease of access to the bits and pieces, and it’s valid XHTML strict, would be valid CSS2.1 if not for some vendor specific values, and is tested working in IE 5.5, 6, 7 & 8, Opera 10.54, FF 3.5.4 (I downgraded since 3.6 breaks the web dev toolbar), and the latest flavors each of Saffy and Chrome. Only 5.5 has some minor glitches on the non-table one, but nothing that stops people from using the page (close enough in my book)… the table one renders no different in 5.5 than newer versions.

Any questions, fire away.

Ok, I know you said don’t repost the whole code, but being I’ve thrown away almost 9k of it… Not a whole lot of point of not sharing the rewrite for the markup:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

	content="text/html; charset=utf-8"






<div id="pageWrapper">

	<ul id="breadCrumbs">
		<li><a href="#">Telecompass</a> ></li>
		<li><a href="">SiteLogic</a> ></li>

	<ul id="topMenu">
		<li><a href="../logout.php">LOGOUT</a></li>

	<div id="fauxColumns">

		<div id="sideBar">
				<li class="current"><a href="index.php">Sites</a></li>
				<li><a href="../console/index.php">Console</a></li>
		<!-- #sideBar --></div>

		<div id="content">
			<ul class="topTabs">
				<li class="current"><a href="">Site Information<span></span></a></li>
				<li><a href="Device.php">Device Information<span></span></a></li>
				<li><a href="">Reports<span></span></a></li>

			<div class="borderTop"><div></div></div>

			<form action="site_add_info.php" method="post" enctype="multipart/form-data" class="borderSides">

				<fieldset class="uploadImage">

					<label for="simg">Upload Image</label><br />
					<input type="file" name="simg" id="simg" value="" />


				<fieldset class="generalInfo">

					<legend><span>General Information</span></legend>

					<label for="sid">Site ID</label><br />
					<input type="text" value="" name="sid" id="sid" /><br />

					<label for="sstatus">Status</label><br />
					<input type="text" value="unknown" disabled="disabled" name="sstatus" id="sstatus" /><br />

					<label for="sname">Site Name</label><br />
					<input type="text" value="" name="sname" id="sname" /><br />

					<label for="scat">Category</label><br />
					<input type="text" value="unknown" disabled="disabled" name="scat" id="scat" /><br />

					<label for="salias">Site Alias</label><br />
					<input type="text" value="" name="salias" id="salias" /><br />

					<label for="stype">Type</label><br />
					<input type="text" value="unknown" disabled="disabled" name="stype" id="stype" /><br />

					<label for="spriority">Priority</label><br />
					<input type="text" value="unknown" disabled="disabled" name="spriority" id="spriority" /><br />

					<label for="smaintainer">Maintained By</label><br />
					<input type="text" value="unknown" disabled="disabled" name="smaintainer" id="smaintainer" /><br />

					<label for="sarea">Service Area</label><br />
					<input type="text" value="" name="sarea" id="sarea" /><br />

					<label for="sregion">Region</label><br />
					<select name="sregion" id="sregion">
					</select><br />

					<label for="latitude">Latitude</label><br />
					<input type="text" value="" name="latitude" id="latitude" /><br />

					<label for="Longitude">Longitude</label><br />
					<input type="text" value="" name="longitude" id="longitude" /><br />


				<fieldset class="accessInfo">

					<legend><span>Access Information</span></legend>

					<label for="cname">Contact Name</label><br />
					<input type="text" value="" name="cname" id="cname" /><br />

					<label for="tnumber">Telephone No.</label><br />
					<input type="text" value="" name="tnumber" id="tnumber" /><br />

					<label for="visitfrom">Visit From</label><br />
					<input type="" value="" name="visitfrom" id="visitfrom" class="inwidth" /><br />

					<label for="to" class="tween">To</label><br />
					<input type="" value="" name="to" id="to" class="inwidth" /><br />

					<label for="directions">Directions</label><br />
					<textarea class="direction" name="directions" id="directions"rows="4" ></textarea>


				<fieldset class="location">


					<label for="address">Address</label><br />
					<input type="text" value="" name="address" id="address" /><br />

					<label for="city">City</label><br />
					<input type="text" value="" name="city" id="city" /><br />

					<label for="state">State</label><br />
					<input type="text" value="" name="city" id="city" /><br />

					<label for="pcode">Postal Code</label><br />
					<input type="text" value="" name="pcode" id="pcode" /><br />

					<label for="intersection">Intersection</label><br />
					<input type="text" value="" name="intersection" id="intersection" /><br />


				<fieldset class="information">


					<label for="mlink">Map Site Link</label><br />
					<input type="text" value="" name="mlink" id="mlink" size="50" /><br />

					<label for="lupdate" class="tween">Last Updated</label><br />
					<input type="text" value="" name="lupdate" id="lupdate" /><br />

					<label for="by" class="tween">By</label><br />
					<input type="text" value="" name="by" id="by" /><br />

					<label for="comments">Comments</label><br />
					<textarea class="combox" name="comments" id="comments"></textarea>

				<div class="submitsAndHiddens">
					<input type="submit" id="save" name="save" class="buttons" value="Save" />
					<input type="submit" id="edit" name="edit" class="buttons" value="Edit" />
					<input type="submit" id="export" name="export" class="buttons" value="Export" />


			<div class="borderBottom"><div></div></div>

		<!-- #content --></div>

	<!-- #fauxColumns --></div>

<!-- #pageWrapper --></div>


Very little reason to be needing more markup than that. At most the fieldsets MAY need wrapping div around them if they decide to misbehave. Chops it down from the 14k of the original to 5.8k using the actual PROPER tags for building a form. I didn’t include the footer since I’m assuming a LOT was omitted from that - since I pretty much can assume you deleted a LOT from it. (which probably all needs to be rewritten as well)

I’ll take a stab at the CSS to make that work and new remastered images since those will need to be redone for how I do my coding. I code for fluid even when making a fixed width page – 1) should you change your mind later, 2) I find it actually easier to design for fluid than I do fixed width since that’s what HTML is designed to do. NEVER understood this whole ‘fixed width is easier’ nonsense unless you make design decisions (like the ones on this page) that I don’t consider viable in the first place.

but as you’ll recall I’ve been abandoning javascripted validation and form assists as a waste of bandwidth! It’s funny but for me, it’s less time spent just checking it server side and re-issuing the page than it is having the user download a .js that shouldn’t be needed if the end user isn’t a moron and can actually follow instructions on a form.

Personally, I think it depends on the type of question, the usual suspects re errors, and whether quickly alerting someone that they’ve fux0red the input right away instead of after sending makes sense or not. I believe there are some occasions where it can be beneficial (yes as an extra).

I was thinking on it, though really I’d have to throw out about a third of the LAYOUT and all of the markup - we’re talking total rewrite since 99% of what’s there is unusable/incorrect/over-thought/non-semantic… and I don’t even want to TOUCH whatever the heck is going on there for javascript. - but as you’ll recall I’ve been abandoning javascripted validation and form assists as a waste of bandwidth! It’s funny but for me, it’s less time spent just checking it server side and re-issuing the page than it is having the user download a .js that shouldn’t be needed if the end user isn’t a moron and can actually follow instructions on a form.

I may take a stab at just trying to clean up the markup as an example…