PDA

View Full Version : Problems with ie and positioning in regards to other browsers.



Anissa
11-17-2011, 11:59 AM
I am coding a site for someone who owns an hvac business, and is admittedly a bit techno slow. His laptop only has ie, and so much of the coding is centered around making the site look right in ie, but it is noticeably off on the other four browsers. How do I fix this (http://www.americanfreedom-hvac.com/)?

(http://www.americanfreedom-hvac.com/)I really need some advice here.

keyon
11-17-2011, 01:00 PM
This is exactly why I hate using css to position objects on a page. Although there's probably some code/script you could add to the header somewhere to make your css behave similar in different browsers, that gets way too complicated for my taste. This is a fairly simple website we're talking about. Have you considered using a 2-column table (gasp from css fanatics) or just using a Wordpress blog? I suspect this project isn't worth you spending more time than you already have on that stylesheet.

weegillis
11-17-2011, 05:29 PM
@keyon: While your advice may be good, it is never useful to turn our backs on a problem that CAN be solved. Tossing out the baby with the bath water is such a cop out. CSS is not as much trouble as some would have us believe.

@OP: First thing I notice is that your page is loading 'html5forie.js' when the document is sporting an HTML 4.01 doctype. Switch to an HTML5 doctype and see what happens, then. Possibly nothing, possibly the page will look the same as what the other browsers are rendering.

I would recommend taking the 10px margin property away from the body, and apply it to the container. Apply 'text-align: center;' to the body, and 'text-align: left;' to the container. This will help center the container on any display wider than 960px.

SE's will have a big time issue with 'color: #000000;' paired with 'background: #000000;' on the body. Really big NO-NO. If nothing else, go with WHITE text on BLACK bg as a starting point, then set colors on inner containers.

One other giant issue that stands out is the raft of negative margins, huge left margins, and so on. What you might need to do is scale back the style sheet to the bare basics and work on the positions without all the CSS3 stuff, for now. Copy the sheet you have, save it as 'temp.css' and load it into the page in place of the main sheet. Delete as much as possible that is not absolutely necessary to the layout.

Comment out any properties with negative margins, followed by everything that even has a margin. Scale right back to just the float properties (making sure their corresponding elements have a width specified). Look through all your width properties and visualize where they are relative to the left edge of the container. Add up the widths. Together they should not exceed 99% of the container width.

Remove all padding, especially left and right. Go with margins on inner elements, instead. This eliminates a lot of spacing problems.

It is a lot of work trying to find where the problem is, and there really isn't an easier way than to strip the CSS bare and build it up again. At least then you know where you stand.

Anissa
11-17-2011, 07:18 PM
@OP: First thing I notice is that your page is loading 'html5forie.js' when the document is sporting an HTML 4.01 doctype. Switch to an HTML5 doctype and see what happens, then. Possibly nothing, possibly the page will look the same as what the other browsers are rendering.



Are you saying that I don't need the .js file for HTML 4.01? If not, will I be able to take out completely without any ramifications, or will I have to put in another .js file? I am trying to avoid HTML 5. I tried it once and had nightmares.

sooo... the container needs to look like this:


.container {
margin: 0px 10;
width: 960px;
}


instead of



.container {
margin: 0px auto;
width: 960px;
}
?

weegillis
11-17-2011, 08:28 PM
Close, but no. Try this:



body {
text-align: center;
}
.container {
margin: 10px auto;
text-align: left;
}


Something of note: 0 (zero) is undefined, and so therefore has no defined unit in CSS. Zero is just zero. However, any non-zero number MUST have a unit, else it will be ignored. Thus,
0px 10 might render for the zero value (ignoring the unit) but will not be able to interpret the '10'. If this rule even makes it through the parser, it will probably look like '0 0'.

Eg. .someclass { margin: 0 10px; }
Will assign top and bottom margins of zero, and left and right margins of 10px.

.someclass { margin: 10px auto; }
Will assign top and bottom margins of 10px, and left and right margins equal. In most browsers this is enough to center this element, horizontally. In others, not. This is why I specify 'text-align: center;' in the body. One way or another, we get the child elements of the body to be centered.

Anissa
11-18-2011, 12:03 AM
Thank you for that. I will definitely fix that.

And the .js? Do I still need it in 4.01?

weegillis
11-18-2011, 01:06 PM
Thank you for that. I will definitely fix that.

And the .js? Do I still need it in 4.01?

No. As we can see below, all this script does is create elements that are unknown to IE 8 and below.


/*** CSS VQS Angels' Muse HTML5forIE.js ***/
document.createElement('abbr');
document.createElement('article');
document.createElement('aside');
document.createElement('audio');
document.createElement('bb');
document.createElement('canvas');
document.createElement('datagrid');
document.createElement('datalist');
document.createElement('details');
document.createElement('dialog');
document.createElement('eventsource');
document.createElement('figure');
document.createElement('footer');
document.createElement('header');
document.createElement('hgroup');
document.createElement('mark');
document.createElement('menu');
document.createElement('meter');
document.createElement('nav');
document.createElement('output');
document.createElement('progress');
document.createElement('section');
document.createElement('time');
document.createElement('video');
I hope the OP isn't adding credentials to every borrowed script. Not very impressive to the informed.
VQS Angels' Muse

The above elements are known to IE 9, and later, so this conditional comment need not filter versions newer than IE 8

<!--[if IE ]><script src="html5forie.js"
type="text/javascript"></script>
<![endif]-->

But you said you hate HTML5. Better run and hide--it's here to stay; and, it is after all, just HTML with a new hat, purse, shoes and gloves. Old HTML still behaves exactly as it always did. Change your doctype and see for yourself.

Anissa
11-18-2011, 04:41 PM
I had nightmares with it last year when I first bought the book to do my own site, and no one could help me because they didn't know how to. I may try it again, but when I design my own site once more, and not when I am doing a site for someone else. I like to use my own stuff for a guinea pig experiment. :)


I hope the OP isn't adding credentials to every borrowed script. Not very impressive to the informed.

I didn't realize that was there. crap. Is it anywhere else? I need to fix that.

weegillis
11-19-2011, 05:13 PM
I had nightmares with it last year when I first bought the book to do my own site, and no one could help me because they didn't know how to. I may try it again, but when I design my own site once more, and not when I am doing a site for someone else. I like to use my own stuff for a guinea pig experiment. :)



I didn't realize that was there. crap. Is it anywhere else? I need to fix that.

Which book? The SitePoint one, "HTML5 & CSS3 for the Real World" (Goldstein/Lazaris/Weyl)?


Unlike changes to CSS3 and JavaScript, where additions are only supported when
browser makers actually implement them, there’s no need to wait for new browser
versions to be released before using HTML5’s syntax. And when it comes to using
the new semantic elements, a small snippet of JavaScript is all that’s required to
bring older browsers into line.When you mentioned book, this one came to mind. When it was being written last year it was fairly cutting edge, and written in the vein of 'slight uncertainty of where HTML is going' (my paraphrasing). Last May it was still not talked about much in lay circles.

Opening the book again, six months later, I'm finding that, (a) it makes more sense now that I've had some of my own struggles with site revisions; and, (b) it refers to things as 'might be' in that time reference, which are more or less coming to pass in this, the present one. This is, really encouraging, as is the fact that it is coming up more in lay conversation, so I recommend going back to that book, if it was the one, or go back to the book you started with and take a fresh start, discounting your own experience or opinions of others for the moment.

After having got your feet wet, I believe even your new client will be in favor of making his site 'future safe' rather than depending upon quirky old methods. The benefits far outweigh the temporary setbacks you and he might experience in the short term.

Anissa
11-20-2011, 07:23 PM
"Visual Quickstart Guide CSS3" Jason Cranford Teague

weegillis
11-21-2011, 11:29 AM
"Visual Quickstart Guide CSS3" Jason Cranford Teague

Will look it up. It is worth noting that CSS3 and HTML5 are not actually 'a set'. The two specifications are completely independent of one another, neither actually needing the other.

The CSS3 spec extends the style sheet selectors and properties list, and will work in any browser that supports CSS. This doesn't mean that all the features will work, but the newer CSS won't break any older browser's ability to render what it can.

HTML5 is also just plain old HTML, with a few additional elements and a few slight rule changes on some of the older ones. ln browsers that do not support them, the new elements (i.e., new tags) can be helped along with shims and polyfills, or not. Newer content will degrade gracefully owing to HTML5's backward compatibility.

We've always encouraged learning of both HTML and CSS on concurrent timelines, and this is still the case. Just remember to keep each in their own distinct context. Learning one does not necessarily require, nor preclude learning the other. By the same token, learning CSS3 will not make us any more knowledgeable about HTML5 and vice versa. By keeping in step with both evolutionary paths, we extend our own overall ability to meet newer challenges. Same story as always.

Anissa
11-25-2011, 03:20 PM
I will take another look at the book. I will play around with it on my website before I put it on a client's to make sure I have to down.

Um... One more question...

I have this code.



<form id="emailform" class="cssform" action="MAILTO:someone@example.net? subject=Request for Service Call" method="post" enctype="text/plain">

<p>
<label for="user">Name</label>
<input type="text" name="Client Name" value="" />
</p>

<p>
<label for="emailaddress">Email Address:</label>
<input type="text" name="email address" value="" />
</p>

<p>
<label for="contactnumber">Contact Number:</label>
<input type="text" name="phone number" value="" />
</p>

<p>
<label for="comments">Address:</label>
<textarea id="comments" rows="3" cols="25"></textarea>
</p>

<p>
<label for="date1">1st choice of date:</label>
<input type="text" name="1st requested date" value="mm/dd/yyyy" />
</p>
<p>
<label for="date2">2nd choice of date:</label>
<input type="text" name="2nd requested date" value="mm/dd/yyyy" />
</p>
<p>
<label for="comments">Best Time of Day:</label>
Morning: <input type="radio" name="time" value="morning"/> Afternoon: <input type="radio" name="time" value="afternoon" /> Evening: <input type="radio" name="time" value="evening"/><br />
</p>

<p>
<label for="comments">Reason for Contact:</label>
<input type="radio" name="type" value="emergency"/> Emergency Service
<input type="radio" name="type" class="threepxfix" value="service call" /> Service Call
<input type="radio" name="type" class="threepxfix" value="estimate" /> Estimate
<input type="radio" name="type" class="threepxfix" value="other"/>Other
<textarea id="other" rows="3" cols="25"></textarea>
</p>
<div style="margin-left: 400px;">
<input type="submit" value="submit"><input type="reset" value="reset" />
</form>

How do I fix it to make it place a subject in the email window? I have been trying, but I can't seem to get to work.

weegillis
11-25-2011, 05:00 PM
As you'll see on this page, W3.ORG/../forms.html (http://www.w3.org/TR/html4/interact/forms.html#h-17.3), 'subject' is not an attribute of the form element.

You'll need to include an INPUT element with TYPE="HIDDEN" (my capitalization). Include a NAME attribute with value "SUBJECT" and a VALUE attribute with value "Reader request from %page", where %page could be the URI of the page the form is located on, just as an example.

Eg.

<input type="hidden" name="subject" value="Reader request from reader_requests.html" />


This will submit the desired subject line along with the other user entered data from the form. The sender will not see it, but all of your submission mail will contain the value data.

If generating your page in PHP, you will be able to include server side variables in your HTML expression, whether interpolated within the subject value, or inserted as PHP within the static HTML.

Eg.

// cache current page URI
$current_page = $_SERVER['REQUEST URI']; // or, $current_page = $_SERVER['PHP_SELF'] to exclude the query string

// Interpolated

$str = "<input type=\"hidden\" name=\"subject\" value=\"Reader request from $current_page\" />\n";
echo $str;

// inserted as PHP

<input type="hidden" name="subject" value="Reader request from <?php echo $current_page; ?>" />


Side Note: It is recommended that you configure your CGI (Perl) or PHP form handler with a predefined list of submission recipients so that you don't expose this information over the web. Displaying this information in your form action attribute (or input recipient attribute) leaves you open to spambots, as well as other methods of form abuse, usually by machines that have all day to hammer away at your forms.

JavaScript can be deployed client-side to insert a dynamic URI based on the location bar of the browser, but the PHP solution will contribute to better client performance.

JavaScript (especially poorly written) can soak up a lot of processor power, slowing down page loads. If using a client side script, be sure to test in lots of browsers. User benefit is the deciding factor. If it benefits the user, or adds to the user experience then scripting isn't such a bad thing. But if not, then expect it to be a hit on performance.