I am having major issues in IE. This web development exercise involves learning why certain hacks work and others don't. My web page renders ok in Firefox.
The main problem in my web page relates to complexity; emulating position fixed in IE. If I simplify the page, the issues subside, which does not help me learn about web development idiosyncrasies.
The height %1 hack did not alleviate the situation either. Look at the CSS, simple.css, for details.
The three pixel jog presents a major problem on a long page. The information at PIE was helpful, yet did not help me resolve the situation. Again, the main inquiry refers to managing multiple hacks and pinpointing issues within IE. The DOM inspector in Firefox helps, yet I have not found its equivalent in IE. [url]http://www.positioniseverything.net/explorer/threepxtest.html[/url]
Do I have to apply this height hack or dimension hack (hasLayout) to every element on the web page including <p> elements?
The following page is pared down examples for those purists, who prefer a simplified page.
R0bert Neville wrote: > I am having major issues in IE. This web development exercise involves > learning why certain hacks work and others don't. My web page renders > ok in Firefox.
> The main problem in my web page relates to complexity; emulating > position fixed in IE. If I simplify the page, the issues subside, > which does not help me learn about web development idiosyncrasies.
Of course it does. Troubleshooting is exactly that - take styles and/or elements off until the problem disappears. Then deduct which element and/or style caused the problem.
[3px jog]
> Do I have to apply this height hack or dimension hack (hasLayout) to > every element on the web page including <p> elements?
The 1%height hack only needs to be applied to the containing element, which in most cases is the content div.
> The following page is pared down examples for those purists, who > prefer a simplified page.
R0bert Neville <robert_neville...@yahoo.com> wrote: >I am having major issues in IE. This web development exercise involves >learning why certain hacks work and others don't. My web page renders >ok in Firefox.
>The main problem in my web page relates to complexity; emulating >position fixed in IE. If I simplify the page, the issues subside, >which does not help me learn about web development idiosyncrasies.
The situation should have taught you that it's unwise to over complicate things in an attempt to get IE to do stuff that is beyond it's natural ability. Keeping an element in view with position:fixed should never be a requirement for a page to work, just let it scroll in browsers that don't support it.
A document should contain only one level 1 header, not 13.
<a name="top" id="top"></a> is old school coding only useful if NS4 compatibility is a must. <h2 id="top">Definition List Selectors Example</h2> is the modern way.
Don't rely on javascript for anything essential, avoid non standard Ecma/javascript, use capability detection.
Use a width that scales with the text size for layout containers with text, otherwise your site will break if the user zooms the text.
Sizing fonts down to 62.5% of my configured preference results in unreadable text.
There are more browsers than IE and Mozilla, a site published on the www should be constructed to work on most of them.
Don't fix the width of the layout, allow it to flow in the width of the available viewport.
> A document should contain only one level 1 header, not 13.
What are you saying by this statement? Use <H2> instead after the first level one. Interesting point if that's what you mean. Please clarify and include backup reference.
> <h2 id="top">Definition List Selectors Example</h2> is the modern way.
Cool. I like this approach better.
> Don't rely on javascript for anything essential, avoid non standard > Ecma/javascript, use capability detection.
Bah Humbug! Javascript is essential to this document template solution.
> Use a width that scales with the text size for layout containers with > text, otherwise your site will break if the user zooms the text. > Sizing fonts down to of my configured preference results in > unreadable text.
This approach assumes the default browser text is about 16px. Thus 62.5% brings it to 10px, and then it scales up to 12px in the main container. If your resolution is so high, then you probably adjust the text size on most sites anyway. At least, my text scales.
> There are more browsers than IE and Mozilla, a site published on the www > should be constructed to work on most of them.
The solution is client-based. The page is only up on a server for debugging. IE support is only relevant in debugging terms.
> Don't fix the width of the layout, allow it to flow in the width of the > available viewport.
The MainContent container has a max-width and min-width for browsers that follow CSS 2 specifications. I am currently working on a max-width solution in IE. In addition, the simplified page took a fixed width approach for the purist.
>>R0bert Neville <robert_neville...@yahoo.com> wrote: >Some other tips: >> A document should contain only one level 1 header, not 13. >What are you saying by this statement? Use <H2> instead after the >first level one. Interesting point if that's what you mean. Please >clarify and include backup reference.
Have a look at the ISO version of HTML to find out why.
[ISO = International Standards Organisation, officially supported by just about as many countries that you can find as members of the UN]
[...]
>> Don't rely on javascript for anything essential, avoid non standard >> Ecma/javascript, use capability detection.
>Bah Humbug! Javascript is essential to this document template >solution.
You are losing me there.
How on earth are you going to create a web site that will convey the info you want to give me, if you are at the same time saying that in order to do so you want to execute _your_ program code on _my_ system?
Forget that, I'm not interested, my system is under my control, not yours.
R0bert Neville <robert_neville...@yahoo.com> wrote: >> A document should contain only one level 1 header, not 13.
>What are you saying by this statement? Use <H2> instead after the >first level one. Interesting point if that's what you mean. Please >clarify and include backup reference.
A page needs a brief description of it's entire content, this should be provided by a level 1 header. From that follows that multiple level 1 headers is incorrect markup. Search the web if you need references.
>> Don't rely on javascript for anything essential, avoid non standard >> Ecma/javascript, use capability detection.
>Bah Humbug! Javascript is essential to this document template >solution.
That restricts use of the document to environments where you have absolute control over the client's features, the web is not such an environment.
>> Sizing fonts down to of my configured preference results in >> unreadable text.
>This approach assumes the default browser text is about 16px.
A browser's default text size is an unknown, no assumptions should be made about it. Leave the default text size alone or specify 100% and it should work for everyone. If you shrink the default text size down to 62.5% your text will be unreadable for a portion of users.
>If your resolution is so high, then you probably adjust the >text size on most sites anyway.
There need not be a relation to monitor resolution, if there is then no on the fly adjustments are necessary, a simple reconfiguration of the browser's default size suffices.
>At least, my text scales.
Not stuffing up the method to solve a problem you've created is not smart, many people are unaware of how to enlarge text in their browser. The proper thing to do is not create the problem in the first place.
>> There are more browsers than IE and Mozilla, a site published on the www >> should be constructed to work on most of them.
>The solution is client-based.
The real question is do you have absolute control over the clients. Given that you seem to be striving for dual client compatibility, and because you proclaimed this to be a "web development", this does not seem to apply. If this is for a controlled client environment then this group is not the correct platform for your query (note the www in the group's name). Posts to this group are discussed in a www context.
Maybe, I should have included the standard disclaimer. You explain the whole scenario and people scuff at the unwieldy post; if you are too concise, you may not provide them with enough information. Generally, I find a balance between too much and too concise. This approach may mislead some people to assumptions.
STANDARD DISCLAIMER: My project aims at creating a document template and navigation approach for my computing notes. These web pages are for personal usage and will reside on an external hard drive. I will use these documents to help me remember key computing idiosyncrasies. These documents number 100+. The CSS style sheet should allow me to have a consistent format and allow me to update formatting for all documents at once. The documents should be primarily viewable on Firefox; Safari, Opera, IE (distant Third) and Netscape (further distant fourth); and not have any platform specific needs. Thus server side processing like PHP is not desirable. All processing should be client based.
Robert Neville <robert_neville310@.nospa...@hoo.com> wrote: >Maybe, I should have included the standard disclaimer.
That would be unwelcome here since it doesn't say anything about the specific message. What is part of the posting conventions here is to quote something of what you are replying to (trimmed down to a minimum).
>STANDARD DISCLAIMER: My project aims at creating a document template >and navigation approach for my computing notes. These web pages are >for personal usage and will reside on an external hard drive.
Then they are not web pages and strictly speaking off topic for this group.
>I will >use these documents to help me remember key computing idiosyncrasies. >These documents number 100+. The CSS style sheet should allow me to >have a consistent format and allow me to update formatting for all >documents at once. The documents should be primarily viewable on >Firefox; Safari, Opera, IE (distant Third) and Netscape (further >distant fourth); and not have any platform specific needs. Thus >server side processing like PHP is not desirable. All processing >should be client based.
If these documents are for your use only, why the many different browsers? If you need to access these documents using clients installed on systems that are not yours, you then have no control over their configuration and the requirements are pretty much the same as for web documents.
