"Lasse Reichstein Nielsen" <lr*@hotpop.com > wrote in message
news:ek******** **@hotpop.com.. .
| "Nobody" <no**@nope.ne t> writes:
|
| > Okay, you are all so smart in here. Answer me this:
| >
| > IE6 in standards mode doesn't seem to hide scrollbars on the body
element
| > (overflow:hide)
|
| I assume you mean "overflow:hidde n".
| (<URL:http://www.w3.org/TR/CSS2/visufx.html#ove rflow>)
Type-o. Long day.
|
| There is no overflow on the body element by default, as it hasn't got
| a fixed height. The overflow you might want is on the html element:
| html {overflow:hidde n;}
Yeah, I figured that.
| Remember that in standards mode, the root of the document tree is
| document.docume ntElement (corresponds to the html tag), not
| document.body.
Right. That makes sense.
|
| > Ain't this a quandary. I have it in my head that I need to
| > specify html instead. The scrollbars do hide on Gecko browsers though,
so
| > there is definitely a disagreement among browser developers on how to
| > implement scrollbars
|
| There is no standards governing the browser interface, only the rendering
| of the page. There is no rule that requires the scrollbars on the viewport
| to correspond to any overflow property. So yes, there is disagreement.
|
| > This is based on the simple empirical evidence that the scroll bars
| > are still there on IE6 in standards mode,
|
| It is the standards mode that trips you up, because it doesn't work
| as quirks mode.
Er. It DOES work in quirks mode. Standards mode indeed causes a problem
with my current coding. Is that what you meant?
|
| > so the optimal document
| > type (XHTML strict) cannot be used. So I could just change this to
| > output an html style (rather than a body style) for IE6 and lose the
| > deprecation (it wouldn't be needed at this point.)
|
| You should not make new pages to quirks mode. It is there for backwards
| compatability with badly written pages aimed at pre-standard browsers.
| Not a group you will want your page to be associated with.
No doubt about it. I spent a lot of time to re-tool my engine for XHTML and
everything was great in IE until I upgraded to IE6 and noticed this problem!
|
| > So the question is this. Given that CGI-based processing of browser
| > versions for these kinds of tweaks is taboo, what would you check on the
| > client side before dynamically generating the style for the body and/or
html
| > element?
|
| What do you want to detect?
|
| In IE, Mozilla and Opera 7, you can check for standards mode with the
| document.compat Mode string. It either responds "CSS1Compat " for
| standards mode, or "BackCompat " in IE and Mozilla and "QuirksMode " in
| Opera 7. (Mozilla also has an "almost standards mode", but I don't
| know how it is reflected in the compatMode string).
Cool! That is what I was looking for. I might not need it for the
scrollbar problem at this point, but that could be useful for other things.
|
| > documentElement is the only thing I can think of that indicates
standards
| > mode and NS6/Mozilla support this AFAIK.
|
| See above, but yes, documentElement is also a good signal, and Opera
| supports it too.
Right.
|
| I typically have a statement like:
| var root = document.docume ntElement || document.body;
That makes sense. I think I have a similar tidbit buried deep in my code
somewhere.
| for scripts that are standards/quirks mode agnostic.
| (Yey, on topic!)
|
| > IE Conditional comments perhaps? I would hate to hard-code a test for a
| > browser version number into the actual document (for obvious reasons),
but I
| > guess it is an alternative if the browser version is exposed to these
| > things.
|
| <!--[if IE 6]> ... <![end if]-->
|
|
<URL:
http://msdn.microsoft.com/workshop/a...ccomment_ovw.a
sp>
Okay. I thought as much. Thanks for the confirmation. I don't need it for
the scrollbar problem anymore, but thanks anyway.
|
|
| > I don't see any other way to deal with a situation like this than with
| > server-side code that looks at the browser's version number and makes
the
| > necessary adjustment. And there are lots of little differences like
this
| > that just don't seem to have viable client-only solutions.
|
| Anything you can detect on the server, you can do better on the client.
| With document.write, you can emit code on the client just as your
But my database of client capabilities is on the server. That is why I
generate my CSS files with CGI. Not needed in this example, but there are
some things that are not detectable (a silly example would be colored scroll
bars.)
| serverside echo/Response.Write. The only difference is that the server
| doesn't rely on Javascript being enabled on the client.
|
| > There's DirectX stuff (probably is an object detect for that)
|
| IE specific, so don't bother making the pages containing it generic.
What does that mean? I output a DX-specific style or a background-image
accordingly to create gradient effects. I do this on the server as it
checks the database to see which version of IE started support for this
feature. The end result is a page that is portable and generic. The style
sheet dynamically generates each time the page is loaded, so it all works
out well. What's the problem?
|
| > and funky colored scrollbars (hey people ask for them)
|
| And boy, do they get them!
| Actually, Opera can support colored scrollbars too.
Happy happy joy joy!
Must update database. Opera as of...? One of the cool things is that once
these things are supported they generally stick around for the life of the
browser.
|
| > and document margins (Opera did them slightly differently than the
| > rest as I recall)
|
| Opera followed the CSS recommendation' s appendix A and gave body
| an 8px padding, not a margin like IE. Mozilla followed IE for no
| apparent reason.
And pissed me off for a few hours one night like you wouldn't believe.
Interestingly enough, it appears that they were right. I don't think that
tidbit would have helped me at the time.
|
| > and now this scrollbar thing.
|
| That is just the difference between standards and quirks mode.
|
| > Oh well. If there is a definitive client-only answer to all of this
then I
| > would love to hear it! Otherwise, any thoughts on the #$@% scrollbars
is
| > appreciated.
|
| It's pure CSS, no Javscript needed.
Yeah as long as I can send both (body and html) without breaking any
browsers. I think I may have my CSS process send one or the other depending
on the document type.
| /L
| --
| Lasse Reichstein Nielsen -
lr*@hotpop.com
| Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit. html>
| 'Faith without judgement merely degrades the spirit divine.'
Thanks a lot. I knew somebody else had to have seen (and dealt with) some
of these same oddities. It's a small world after all.
