Layer Moving in IE Mac

[charlesbucket]

Here is a link to the page:
http://www.studiomoon.com/anselmo_test/home.html

Here is a link to the style sheet:
http://www.studiomoon.com/anselmo_test/css/anselmo.css

I'm building a site that must function correctly in all browsers. In Internet Explorer on the Mac the main content layer changes it's position when the browser window changes size. In all other browsers/platforms the layer remains fixed. This is the last QA issue that I have with this site so please help if you can.

I am using a hack to position the layer in IE/Mac. The first "content_layer" style is the one that the IE/Mac browser reads. The second style is used by other browsers.

Is there something I can add to "content_layer" in order to keep the layer position fixed?

#content_layer {
position: absolute;
width:475px;
height:115px;
z-index:1;
visibility: visible;
margin-left: 211;
margin-top: 155;
font-family: "Helvetica Neue", Helvetica, Verdana, Arial, sans-serif;
font-size: 10px;
line-height: 14px;
font-weight: normal;
color: #000000;
letter-spacing: .5px;
}


/* hidden from IE mac \*/
#content_layer {
position: absolute;
width:475px;
height:115px;
z-index:1;
visibility: visible;
margin-left: 211;
margin-top: 96;
font-family: "Helvetica Neue", Helvetica, Verdana, Arial, sans-serif;
font-size: 10px;
line-height: 14px;
font-weight: normal;
color: #000000;
letter-spacing: .5px;
}
/* end hack */

[jscheuer1]

If that division needs a z-index, I'd try it with position:relative; for IE Mac. If it doesn't need the z-index, just removing the position property may get it. Another thought - the layout of the page doesn't look so involved that it couldn't be rendered in, at least a presentable fashion, without complex styling. That could be the way to go for IE Mac. You might have to give up the rounded corners and/or size adjusting of the left hand box in IE Mac. Unfortunately I have no Mac for testing so, cannot be more helpful.

[charlesbucket]

Thanks for replying John.
This is the first site that I am truly embracing the no table use for design elements, no spacer gifs philosophy. I'm learning a lot about cross-browser issues with css. position:relative places the content in front of the rest of my page so I may have to rethink this content area. I may end up living with the floating layer in this one browser. I'm not allowed to change the design of this page (even slightly) that is the reason for all the complex styling and rounded corners.

[mwinter]

I can't test with IE/Mac either, so I'll also just have to guess a bit, but I do agree that the positioning scheme is most likely the root of the problem.

There are a couple of things to consider. The first is that you don't include units on all non-zero length units. For example, the left margin is 211 what? It could be miles for all the browser really knows. Always include a unit suffix unless the length is zero. The next is that you don't position the element. IE/Mac could well have a bug that occurs when no offset properties are used in conjunction with position: absolute. I don't keep track.

This is the last QA issue that I have with this site so please help if you can.

Sorry, but I disagree. The major problem is that you have an absurdly small font for the body text. If I had to read something that small for little longer than a few minutes, I'd get a terrible headache. There are other issues, too.

• With images disabled, the site become unnavigable as there is no alternative text.
• At larger font sizes, the layout overflows.
• With a viewport approximately 830 pixels wide or less, a horizontal scrollbar is unavoidable with the current implementation. At about less than 745 pixels, content starts falling outside the viewport.
• As you use lengths, rather than percentages, to set font sizes, it is not possible to resize text in IE.

There are also areas of potential improvement to be found in the code.

• You're only hiding one declaration from IE/Mac. There's no need to redeclare every single property in content_layer.
• You might have avoided using layout tables to a large degree, but div soup isn't much better.

I'm not allowed to change the design of this page (even slightly)

You should convince the person who decided that they should rethink that policy. It's not possible to achieve pixel-perfect layouts across a wide range of user agents. It's a waste of time to try. I would think that accessible content is the primary concern. Appearance comes a distant second (there are exceptions).

I'll see about posting more (much) later today.

Mike

[charlesbucket]

I think its funny when a professor tries to pit me against my boss.

[charlesbucket]

I can't test with IE/Mac either

Well without IE/Mac testing my original question is never really answered.

In reponse to the rest of you comments:
1) All units other than zero are now defined as pixels.
2) Adding top and left positioning to the element causes it to move upon window resize in all browsers. This should be avoided.
3) The font in increased one point size. Tough to remember that some people have bad eye-sight.
4) Alternative text has been added to the html code. Do you know of a way to add alternative text to background-images in css?
5) Larger font sizes overflowing the layout remains a concern.
6) The site is designed for optimal viewing at 1024x768 pixel resolution. This is the size that has been determined by my studio as our preferred layout. Due to the ever-increasing size of computer monitors the viewing size has been increased from 800x600 pixel resolution.


I'll respond to the rest of the comments later. (Have to go to lunch!)

[charlesbucket]

7) Not being able to re-size the text in IE is a good thing. If only there was a way to make text-resize not possible in all browsers. Do you know of one?
8) Good point about the hidden declarations. The redeclarations have been reduced to one.
9) Since tables are the devil right now your div soup comment does not offend me. As I use tables less over time my code will get cleaner. Practice makes perfect!

I totally agree with rethinking the policy on changing the design of the page. I have argued that point constantly to no avail. Although if content is always held far above appearence the entire web would look like craigslist.org!

Mike, I hope I did not put a bee in your bonnet. I do find the tone of your posts to be condescending. However your extreme scrutiny is a big help and I'd hate to put your profile on my blocked list.

[mwinter]

I think its funny when a professor tries to pit me against my boss.

I'm not trying to pit you against anyone, but suggesting a course of action that you seem to be attempting by yourself, anyway.

You are aware that titles are related to post count, right?

Well without IE/Mac testing my original question is never really answered.

There's not much I, or anyone else, can do about that. Perhaps with up-to-date Mac emulators, I could run IE/Mac in Windows or Linux, but they either don't exist or require extras that I'm not capable of acquiring.

Adding top and left positioning to the element causes it to move upon window resize in all browsers. This should be avoided.

Were you using percentages to position the element? Movement shouldn't occur otherwise.

The font in increased one point size.

It would be better to leave font size alone, but I suppose it's still an improvement.

Alternative text has been added to the html code.

Remove it from the top and bottom images for that left-hand box. Alternative text should only be used on images that actually have text content, or represent something important (like a graph, etc.) that should be communicated if the image isn't available. Decorative images should have an empty value: alt="".

Do you know of a way to add alternative text to background-images in css?

There isn't one. There are many image replacement techniques, but the ones I've seen are always deficient in some way. Use either img elements, or plain text and background images.

Larger font sizes overflowing the layout remains a concern.

There's not much that can be done about horizontal overflow with the current design. Vertical overflow can be accomodated, but it can produce less than ideal results for some browsers.

The site is designed for optimal viewing at 1024x768 pixel resolution.

The majority of sites shouldn't have either maximum or minimum viewport sizes. It's quite feasible to create fluid layouts, though it can impact on how decorative images are designed (they need to be repeatable in some way, usually).

Due to the ever-increasing size of computer monitors the viewing size has been increased from 800x600 pixel resolution.

Ever-increasing monitors doesn't necessarily correlate with ever-increasing viewport sizes, though. Not everyone uses, or wants to use, maximised browser windows. Toolbars and other chrome features also reduce, significantly in some cases, how much viewing space is available. Mobile devices could also be something to consider in the future.

Not being able to re-size the text in IE is a good thing.

For whom? You or your users? I don't see how preventing the use of an accessibility feature could possibly be considered a good thing unless you're more worried about preserving a fragile layout than providing a decent experience for visitors.

If only there was a way to make text-resize not possible in all browsers. Do you know of one?

No, there aren't any, but there is the reverse. Any decent browser will reject poor choices by an author by forcing a minimum, but it shouldn't come to that.

Since tables are the devil right now your div soup comment does not offend me.

Good. It wasn't meant to. I think you need to detach yourself from your work. A criticism of the latter doesn't in any way infer a personal attack on you. I simply gave a matter of fact assessment.

Some of these issues can be addressed. I've produced a mock-up that provides an accurate reimplementation in Opera 6+, Mozilla 1.3+ (and possibly earlier), and of course Firefox. IE 5.5+ shows a slightly degraded version (no brackets around navigation items on hover). IE 5.01 has its trademark inability to add horizontal padding/margins to inline elements (again, the list items), though that could be worked around with width properties (which it does mistakenly apply). IE 4.01 stacks the list items, but that isn't so bad.

From what I've seen with iCapture, Safari doesn't stretch the full height, but that's a minor issue. I think the problem is that it applies the height: auto declaration, but not the min-height property, so the #wrapper element collapses unlike in other browsers. Without bombarding iCapture with requests, I doubt I'll be able to find a hack that will hide that declaration from Safari alone (the current excessive tampering hinders Opera 6), and I can't use my version of Konqueror as it's thoroughly obsolete. I still have no idea how this might look in IE/Mac.

Just to note, IE doesn't support the min-height property either, which is why height: auto is hidden (primarily) from it. The style sheet featured here uses IE's broken implementation of the height property instead.

With additional features like media queries (defined in CSS 3) and better support of properties like min/max-height/width, it would be easier to pull off a design like this, but it's not exactly something that browsers are suited for.

Although if content is always held far above appearence the entire web would look like craigslist.org!

Where exactly does that kind of fallacious reasoning come from? You aren't the only person to have espoused it. Accessible content (and that example isn't particularly accessible) doesn't mean that every kind of presentational nicety should immediately be done away with. It's a matter of appreciating that designing for the Web isn't the same as designing for a piece of paper, or other fixed-dimension media. Mixed capabilities, viewport dimensions, and available (and appropriate) fonts are just some of the considerations that don't normally feature in graphic design. I'm not saying you're not personally aware of this, but there are many designers that clearly aren't.

Mike

[charlesbucket]

Please do not post to this thread unless you can answer the Internet Explorer/Mac issue. All of this additional posting is a waste of time.

mwinter I have added you to my blocked list and named you as my enemy.

[cr3ative]

Please do not post to this thread unless you can answer the Internet Explorer/Mac issue. All of this additional posting is a waste of time.

mwinter I have added you to my blocked list and named you as my enemy.

If you're going to block people who are trying to help, you will both discourage other people from helping and not recieve any further help from Mike, obviously. Mike is one of the most knowledgeable people on this forum, so it's worth listening.

Sorry for being offtopic, but frankly, your attitude stinks.