IE6, xhtml, scrollbars and you

[Nobody]

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) 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 (as a side note, Gecko browsers with their notoriously
bug-ridden resize code seem to always screw up when asked to stretch and
scroll divs, even when the page is reloaded on every resize!)

My first thought is to modify the CGI that generates the style sheet as I
already have code that deprecates the document type when hidden scroll bars
are required on IE6 (but not IE5.) This is based on the simple empirical
evidence that the scroll bars are still there on IE6 in standards mode, 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.)

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? It doesn't seem like you could just send both as this would surely
break some older browsers (I know you can do tricks with comments and such,
but that only works for NS4 and maybe IE3 AFAIK.)

documentElement is the only thing I can think of that indicates standards
mode and NS6/Mozilla support this AFAIK.

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.

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. There's DirectX
stuff (probably is an object detect for that) and funky colored scrollbars
(hey people ask for them) and document margins (Opera did them slightly
differently than the rest as I recall) and now this scrollbar thing.

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.

All the best,
Michael Jibbering

[Jim Ley]

On 04 Sep 2003 18:28:41 +0200, Lasse Reichstein Nielsen
<lr*@hotpop.com > wrote:

I have yet to see a browser that makes a difference in its CSS rendering
between XHTML 1.0 Strict and HTML 4.01 Strict.
nor me.
Actually, I have yet to see a browser that supports XHTML and not HTML,
although I can believe that they exist for specialized uses.
XSmiles, DENG, bothl render some XHTML elements within wider XML
situations, but don't necessarily render HTML. XSmiles is even
scriptable...
There is nothing inherent in XHTML that makes it better or worse than HTML
at separating style from content. It just happens that the move away from
physical markup happened about the same time as XHTML.

well it was rediscovered then, it was also being done years before in
viola IIRC.

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[DU]

Nobody wrote:

"DU" <dr*******@hotR EMOVEmail.com> wrote in message
news:bj******** **@news.eusc.in ter.net...
| Lasse Reichstein Nielsen wrote:
| > "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:hid e)
| >
| >
| > I assume you mean "overflow:hidde n".
| > (<URL:http://www.w3.org/TR/CSS2/visufx.html#ove rflow>)
| >
|
| God would have known that it was hidden, not hide. :)

God would be clever enough to marshal an entire newsgroup to solve an
obscure CSS problem (off-topic too!)

Not off-topic at all. Since you arrived in this newsgroup, you've
resorted to name-calling, abrasive remarks, unprovoked, uncalled and
unjustified ad hominem arguments and you even self-proclaimed yourself
as a God by saying:
"You are talking to God when it comes to browser detection and backward
compatibility issues."
In no way these discussion manners are promoting your opinions: it just
discredibilizes you.

Open up your mind a little and be a mite more modest here. We (if not,
an entire newsgroup at *your* service) are answering your questions to
the best of our abilities, you know. Some of the regulars in this
newsgroup are pretty good in their respective fields of expertise, you
see. We all can learn with civilized and moderated tone of discussion.

Counter the arguments, thougths, ideas if you feel justified: don't
attack the people forwarding arguments. Otherwise you're defeating for
yourself and others one of te purpose of newsgroup usenet.
|
| > There is no overflow on the body element by default, as it hasn't got
| > a fixed height.
|
| Since I'm not God ;p I'll risk that the browser default css overflow
| declaration on the body element in all browsers is visible.

Of course it is. And what does that have to do with the price of beans in
Somalia?

|
|
| The overflow you might want is on the html element:
| > html {overflow:hidde n;}
|
| This is debattable. MSIE 6 for windows has the browser default
| overflow:scroll for the root element. So, you would need to use
| overflow:visibl e or overflow:auto instead.

No. Those would do the opposite. We want to hide the scrollbars and though
I haven't yet modified my stuff to use html instead of body, I am quite sure
that will do the trick.

Why would you want to hide the scrollbars if content overflows window
dimensions? In what way is this promoting accessibility to content? I
can understand hiding scrollbars (turning off html {overflow:scrol l;} in
MSIE 6 in standards mode) when content does NOT overflow window
dimensions though.
|
| > Remember that in standards mode, the root of the document tree is
| > document.docume ntElement (corresponds to the html tag), not
| > document.body.
| >
| >
| >>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.
|
| Yes and no. It would be quite suicidal not to implement scrolling of
| some sort in case of overflow.

Unless the style of the document overrides it.

In IE only. Browser viewport does not correspond to any HTML element
which you can style in most non-IE browsers. The root element is not the
viewport in most non-IE browsers regardless of rendering mode.

html {width:1200px; overflow:hidden ;}
will create a vertical scrollbar in Opera 7.20 for users with a 1024x768
or smaller scr. res. It should also create a vertical scrollbar in NS
7.1 and Mozilla 1.4+ but it's not and that is a bug IMO.
|
| "When the viewport is smaller than the document's initial containing
| block, the user agent should offer a scrolling mechanism."
| http://www.w3.org/TR/CSS2/visuren.html#q2
| http://www.w3.org/TR/CSS21/visuren.html#q2
|
|
| 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.
| >
| >
| >> 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.
| >
|
| I think he has a point. The problem is that if there is no content
| overflow, in standard compliant rendering mode, a vertical scrollbar
| will appear... for no reason.

Yes. That is what I am getting at. Except that when using overflow:hidden ,
scrollbars should not appear, regardless of overflow. I use scroll bars on
divs instead. The idea is to take up all available real estate and it works
like a charm in IE and like a slug in Gecko (I quit trying to do this trick
on Gecko-based browsers.)

[snipped]

Because browser viewport (scrollbars appearing or not) is controlled
independently of html elements and css.
|
| html {overflow:auto; }
|
| and then a miracle will happen with the scrollbar. Jesus, I wish God
| could take care of a few thousands bugs in MSIE 6 and make the release

No shit. I already said that in the original post and it was confirmed by
another poster. The thread has been over since yesterday.

I read your original post and all others which followed and did not see
such proposal anywhere.

DU
--
Javascript and Browser bugs:
http://www10.brinkster.com/doctorunclear/
- Resources, help and tips for Netscape 7.x users and Composer
- Interactive demos on Popup windows, music (audio/midi) in Netscape 7.x
http://www10.brinkster.com/doctorunc...e7Section.html

[Nobody]

| old browsers. It's what you send to new browsers that is discussed.
| You chose to send XHTML, and I say that you can send Strict HTML
| instead. With the same CSS code, the two will render identically.
| Using strict HTML can give a smaller result than Strict XHTML.

Why would I send HTML Strict to NS6 or 7. I just don't understand why I
would go backward like that.

|
| > Everything else I want deprecated so that there is
| > no question it will look/feel identical to the XHTML version.
|
| That sounds backwards to me. You want to use as different methods
| as possible, in order to ensure that the results look the same.

I have to use the old appearance attributes with older browsers. There's
just no way around that (ex. IE2) Conversely I use the most modern methods
on newer browsers. And yes they look the same across many platforms and
browsers (far more than if I just sent out strict stuff.)

|
| > For instance, IE2 or NS1 will change the look of my pages if I rely
| > strictly on CSS for layout.
|
| Obviously, since they don't understand CSS at all.
|
| > Why do I care? Because there are millions of browsers out there
| > and you have to have a fallback to support unknown entities and entities
| > that are explicitly unable to comply with the latest and greatest
versions
| > of HTML.
|
| If you meet an unknown browser, what do you send: The deprecated tag soup,
| or standards compliant code? I would chose the latter, since new browsers
| appearing these days will be more likely to support standards than being
| bug compatible with IE 4.

I don't know where IE4 entered into it. You lost me there. But I think
that a totally unknown browser is a quandary. If you send the latest, you
assume that it can support CSS properly. That is quite a leap of faith!

|
| > Can be, but why would I generate such code? For whom?
|
| I don't know. My only beef was with the statement that XHTML gave more
| compact code than HTML. It doesn't, unless you make bloated HTML code.
|
| > What does that mean? The attributes that are deprecated in HTML4.01
usually
| > have a CSS equivalent that will work with XHTML (which makes perfect
sense
| > to me as XHTML seperates style from content, which requires CSS to make
it
| > work.)
|
| XHTML does no such thing.
| XHTML 1.0 Transitional is completely equivalent to HTML 4.01 Transitional.
| It separates no more or less.

Strict vs. loose rather than XHTML vs. HTML. Right.

|
| There is nothing inherent in XHTML that makes it better or worse than HTML
| at separating style from content. It just happens that the move away from
| physical markup happened about the same time as XHTML. It actually started
in
| HTML with the deprecation of tags and attributes used for layout, but
| as the evolution of HTML was moved to XHTML, the fruits of that
deprecation

Right. I know about that. That is why I use HTML4.01 loose as a fallback.
It still validates with the height, width and align attributes.

| (total abandonment of the deprecated parts) only occured in XHTML 1.1.
|
| > So if you want to output table-based layouts (for intance) in XHTML,
| > your CGI must output different styles to handle things like stretching
cells
| > to fit the screen. In HTML, this is done with the width attribute (in
4.01)
| > and the height attribute (invalid even in 4.01, so my fallback layouts
never
| > stretch vertically.) Does that makes sense to you?
|
| Not really.
|
| Maybe one reason is that I don't want pages to look the same in all
| browsers. The web is not paper, and the only type of design that will
| work consistently across as diverse platforms as home computers,
| mobile phones and speech syntesizers, is a fluid one. Call me an
| idealist.

Mine is about as fluid as you can get. It oozes over all available browser
real estate that it can find. My point is that I don't want to lose that
(and other) functionality on browsers that do not support style sheets. It
is bad enough that one stupid bug in Gecko short-circuits these aspirations
on Netscape and Mozilla.

|
| Still, the point was: XHTML is not more compact than HTML. You can
| transform any XHTML page into an equivalent and probably smaller
| HTML page.

But to what end? Shouldn't we be moving forward? I see they now have a
thing called XHTML Basic that will be the next big thing. I suspect my
engine will convert to that in five minutes and be serving XHTML Basic
enabled agents immediately thereafter. I think it is a sound strategy to
keep up with what w3c is proposing. Maybe I'm wrong...
|
| /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.'

[Jim Ley]

On Thu, 04 Sep 2003 17:43:57 GMT, "Nobody" <no**@nope.ne t> wrote:

| old browsers. It's what you send to new browsers that is discussed.
| You chose to send XHTML, and I say that you can send Strict HTML
| instead. With the same CSS code, the two will render identically.
| Using strict HTML can give a smaller result than Strict XHTML.

Why would I send HTML Strict to NS6 or 7. I just don't understand why I
would go backward like that.
Because HTML 4.01 is the only thing you can correctly send with the
mime type text/html without doing obscure Appendix C shenanigans, and
even then certain parts of Appendix C are definitively wrong (it
allows you to use meta to set the charset, ignoring the text/*
default.) Sending XHTML as text/html is a hack, and a difficult one
to justify, since XHTML 1.0 is exactly as expressive as HTML 4.01,
it's just a reformulation.

There's my reasons for not, what are your reasons for, I've still yet
to see any.
If you send the latest, you
assume that it can support CSS properly. That is quite a leap of faith!
Equally the assumption that it supports FONT say is just as much a
leap of faith, new browsers like X-Smiles and DENG, do not support
FONT, but do support CSS...
| Still, the point was: XHTML is not more compact than HTML. You can
| transform any XHTML page into an equivalent and probably smaller
| HTML page.

But to what end? Shouldn't we be moving forward?
Sure, RDF, MATHML, SVG lots of formats full of richer semantic meaning
than HTML all well worth using to mark up content, but XHTML as no
extra semantic meaning, may be useful in the future to integrate with
the above technologies, but certainly not relevant now, and if you
have valid HTML content you can convert it to XHTML any time you want
with TIDY.
I see they now have a
thing called XHTML Basic that will be the next big thing.

Sure, but you won't be able to serve it as text/html, so it's pretty
irrelevant to authoring for web-browsers today.

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[Lasse Reichstein Nielsen]

"Nobody" <no**@nope.ne t> writes:

Why would I send HTML Strict to NS6 or 7. I just don't understand why I
would go backward like that.
Jim Ley has good arguments. I'll just say: It can make shorter code.
I have to use the old appearance attributes with older browsers. There's
just no way around that (ex. IE2)
I have been known to overdo things too, but still ... do you actually
know the person who still uses IE2? I bet there are more people using
W3 (or even the amazing Lynx) as a browser than there are using IE2.
Conversely I use the most modern methods on newer browsers. And yes
they look the same across many platforms and browsers (far more than
if I just sent out strict stuff.)
What is the difference between sending XHTML 1.1 and HTML 4.01 Strict
(using the exact same tags and attributes as the XHTML version), and
using the same style sheets? Can you mention one browser where it
makes a difference?
I don't know where IE4 entered into it. You lost me there. But I think
that a totally unknown browser is a quandary. If you send the latest, you
assume that it can support CSS properly. That is quite a leap of faith!
No more a leap of faith than assuming it supports anything else. I
like to err on the side of standards. Maybe because I want to reward
the browsers that do follow standards.
| Still, the point was: XHTML is not more compact than HTML. .... But to what end?
I never said there was an end. I just said that the statement that XHTML
was more compact than HTML was misleading.
Shouldn't we be moving forward?

Absolutely. I write XHTML too. And often, I don't look back. That is a
luxury I can afford because I don't make money on my pages.

I want the world where I can write to standards and not care what
browser people use. As it is now, I still consider how the page
degrades if standards are not supported well. I don't want the page to
look the same on all browsers. On old browsers, browsers that I want
to be gone from the browserscape, I settle for the page being usable.
I doesn't even have to be pretty. I consider that moving forward.

/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.'