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]

Re: IE6, xhtml, scrollbars and you

On Thu, 04 Sep 2003 00:08:08 GMT, "Nobody" <none@nope.ne t> wrote:
[color=blue]
> 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.[/color]

Internet explorer does not claim to support XHTML, so since you cannot
send XHTML with the correct mime-type, you're relying on Appendix C
fixup of XHTML 1.0, and I certainly can't see how that is in any way
"optimal". This is probably the first place to look.
[color=blue]
>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.[/color]

I can't see the javascript question, the correct place would be a
stylesheets group, the solution certainly doesn't rely in javascript.

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

[Nobody]

Re: IE6, xhtml, scrollbars and you


"Jim Ley" <jim@jibbering. com> wrote in message
news:3f5686ba.4 6835515@news.ci s.dfn.de...
| On Thu, 04 Sep 2003 00:08:08 GMT, "Nobody" <none@nope.ne t> wrote:
|
| > 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.
|
| Internet explorer does not claim to support XHTML, so since you cannot

Hmmm. It does switch to "standards mode" when confronted with the XHTML
document type and it does comply with it as far as I can tell. It most
assuredly does things differently in this mode.

| send XHTML with the correct mime-type, you're relying on Appendix C
| fixup of XHTML 1.0, and I certainly can't see how that is in any way
| "optimal". This is probably the first place to look.

XHTML is optimal in numerous ways, not the least of which is that it is far
more compact than the equivalent HTML 4.01. Plus I want to send the best
document that the browser can handle.

The only thing that IE6 did not handle right with XHTML was the stupid
scrollbars. Unthinkable but true.

|
| >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.
|
| I can't see the javascript question, the correct place would be a
| stylesheets group, the solution certainly doesn't rely in javascript.

Sure it does. An object detection solution is what I'm after (if one
exists.) As I stated, I don't believe that CSS can handle this quandary
alone. Perhaps I am wrong.

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

[Lasse Reichstein Nielsen]

Re: IE6, xhtml, scrollbars and you

"Nobody" <none@nope.ne t> writes:
[color=blue]
> 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)[/color]

I assume you mean "overflow:hidde n".
(<URL:http://www.w3.org/TR/CSS2/visufx.html#ove rflow>)

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;}
Remember that in standards mode, the root of the document tree is
document.docume ntElement (corresponds to the html tag), not
document.body.
[color=blue]
> 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[/color]

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.
[color=blue]
> This is based on the simple empirical evidence that the scroll bars
> are still there on IE6 in standards mode,[/color]

It is the standards mode that trips you up, because it doesn't work
as quirks mode.
[color=blue]
> 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.)[/color]

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.
[color=blue]
> 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?[/color]

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).
[color=blue]
> documentElement is the only thing I can think of that indicates standards
> mode and NS6/Mozilla support this AFAIK.[/color]

See above, but yes, documentElement is also a good signal, and Opera
supports it too.

I typically have a statement like:
var root = document.docume ntElement || document.body;
for scripts that are standards/quirks mode agnostic.
(Yey, on topic!)
[color=blue]
> 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.[/color]

<!--[if IE 6]> ... <![end if]-->

<URL:http://msdn.microsoft. com/workshop/author/dhtml/overview/ccomment_ovw.as p>

[color=blue]
> 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.[/color]

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
serverside echo/Response.Write. The only difference is that the server
doesn't rely on Javascript being enabled on the client.
[color=blue]
> There's DirectX stuff (probably is an object detect for that)[/color]

IE specific, so don't bother making the pages containing it generic.
[color=blue]
> and funky colored scrollbars (hey people ask for them)[/color]

And boy, do they get them!
Actually, Opera can support colored scrollbars too.
[color=blue]
> and document margins (Opera did them slightly differently than the
> rest as I recall)[/color]

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.
[color=blue]
> and now this scrollbar thing.[/color]

That is just the difference between standards and quirks mode.
[color=blue]
> 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.[/color]

It's pure CSS, no Javscript needed.
/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit. html>
'Faith without judgement merely degrades the spirit divine.'

[Nobody]

Re: IE6, xhtml, scrollbars and you


"Lasse Reichstein Nielsen" <lrn@hotpop.com > wrote in message
news:ekyx5ple.f sf@hotpop.com.. .
| "Nobody" <none@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 - lrn@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.

[DU]

Re: IE6, xhtml, scrollbars and you

Lasse Reichstein Nielsen wrote:[color=blue]
> "Nobody" <none@nope.ne t> writes:
>
>[color=green]
>>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)[/color]
>
>
> I assume you mean "overflow:hidde n".
> (<URL:http://www.w3.org/TR/CSS2/visufx.html#ove rflow>)
>[/color]

God would have known that it was hidden, not hide. :)
[color=blue]
> There is no overflow on the body element by default, as it hasn't got
> a fixed height.[/color]

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.


The overflow you might want is on the html element:[color=blue]
> html {overflow:hidde n;}[/color]

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.
[color=blue]
> Remember that in standards mode, the root of the document tree is
> document.docume ntElement (corresponds to the html tag), not
> document.body.
>
>[color=green]
>>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[/color]
>
>
> 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.[/color]

Yes and no. It would be quite suicidal not to implement scrolling of
some sort in case of overflow.

"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.[color=blue]
>
>[color=green]
>>This is based on the simple empirical evidence that the scroll bars
>>are still there on IE6 in standards mode,[/color]
>
>
> It is the standards mode that trips you up, because it doesn't work
> as quirks mode.
>
>[color=green]
>> 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.)[/color]
>
>
> 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.
>[/color]

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.

Important and unknown default browser values:

http://www10.brinkster.com/doctorunclear/HTMLJavascriptCSS/BrowsersDefaultValues.html

[color=blue]
>[color=green]
>>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?[/color]
>
>
> 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).
>
>[color=green]
>>documentEleme nt is the only thing I can think of that indicates standards
>>mode and NS6/Mozilla support this AFAIK.[/color]
>
>
> See above, but yes, documentElement is also a good signal, and Opera
> supports it too.
>
> I typically have a statement like:
> var root = document.docume ntElement || document.body;
> for scripts that are standards/quirks mode agnostic.
> (Yey, on topic!)
>
>[color=green]
>>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.[/color]
>
>
> <!--[if IE 6]> ... <![end if]-->
>
> <URL:http://msdn.microsoft. com/workshop/author/dhtml/overview/ccomment_ovw.as p>
>
>[color=green]
>>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.[/color]
>
>
> 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
> serverside echo/Response.Write. The only difference is that the server
> doesn't rely on Javascript being enabled on the client.
>
>[color=green]
>>There's DirectX stuff (probably is an object detect for that)[/color]
>
>
> IE specific, so don't bother making the pages containing it generic.
>
>[color=green]
>>and funky colored scrollbars (hey people ask for them)[/color]
>
>
> And boy, do they get them!
> Actually, Opera can support colored scrollbars too.
>
>[color=green]
>>and document margins (Opera did them slightly differently than the
>>rest as I recall)[/color]
>
>
> Opera followed the CSS recommendation' s appendix A and gave body
> an 8px padding, not a margin like IE.[/color]


Yep. That is even documented also.


Mozilla followed IE for no[color=blue]
> apparent reason.
>[/color]

MSIE margins on the body element is {margin:15px 10px;} while Mozilla's
is {margin:8px;}. God would have known that :)


[color=blue]
>[color=green]
>>and now this scrollbar thing.[/color]
>
>
> That is just the difference between standards and quirks mode.
>[/color]

God only has to set the following declaration

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
date of MSIE 7 for next week. That would be fine :)

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/doctorunclear/Netscape7/Netscape7Section.html

[Lasse Reichstein Nielsen]

Re: IE6, xhtml, scrollbars and you

DU <drunclear@hotR EMOVEmail.com> writes:
[color=blue][color=green]
> > There is no overflow on the body element by default, as it hasn't got
> > a fixed height.[/color][/color]
[color=blue]
> 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.[/color]

Yes, but the point is that the default height is "auto", so you won't get
any overflow.
[color=blue]
> 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.[/color]

"overflow:hidde n" will also work. No scrollbar. Bad choice, but seemed
to be what the original poster wanted.
[color=blue][color=green]
> > of the page. There is no rule that requires the scrollbars on the viewport
> > to correspond to any overflow property.[/color][/color]
[color=blue]
> Yes and no. It would be quite suicidal not to implement scrolling of
> some sort in case of overflow.[/color]

Absolutely. An in some browsers, there is no document model node
corresponding to the viewport, and you can't use a CSS overflow
declaration to change the default browser scrollbars.
[color=blue]
> "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[/color]

Yes. Strictly speaking, that doesn't leave room for turning that
scrollbar off.
[color=blue][color=green]
> > compatability with badly written pages aimed at pre-standard browsers.
> > Not a group you will want your page to be associated with.[/color][/color]
[color=blue]
> 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.[/color]

So will it in quirks mode. That is an IE interface decission.

You can turn it off, but you just have to do it slightly differently
between standardsand quirks mode. In quirks mode, it is the overflow
property of the body that controls it. In standards mode, it is the
overflow property of the html element (documentElemen t) that controls
the scrollbar.
[color=blue]
> Important and unknown default browser values:
> http://www10.brinkster.com/doctorunc...ultValues.html[/color]

Cute :) I see Opera 7.2 still needs to fix their getComputedStyl e for
lengths that are "auto".

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit. html>
'Faith without judgement merely degrades the spirit divine.'

[Lasse Reichstein Nielsen]

Re: IE6, xhtml, scrollbars and you

"Nobody" <none@nope.ne t> writes:

[color=blue]
> Er. It DOES work in quirks mode. Standards mode indeed causes a problem
> with my current coding. Is that what you meant?[/color]

Exactly :)
[color=blue]
> What does that mean? I output a DX-specific style or a background-image
> accordingly to create gradient effects.[/color]

Ah. I was thinking of embedded ActiveX controls that were an important
part of the page. Pure decoration should be safe.
[color=blue]
> Must update database. Opera as of...?[/color]

Mhh, not sure which version of Opera 7. Probably there since the first
official release. The trick is that it is not enabled by default, and
I don't think there is a way to check for it.

Still, the CSS for colored scrollbars won't break anything. So you can
just send it and hope it is enabled.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit. html>
'Faith without judgement merely degrades the spirit divine.'

[Jim Ley]

Re: IE6, xhtml, scrollbars and you

On Thu, 04 Sep 2003 00:38:24 GMT, "Nobody" <none@nope.ne t> wrote:
[color=blue]
>| Internet explorer does not claim to support XHTML, so since you cannot
>
>Hmmm. It does switch to "standards mode" when confronted with the XHTML
>document type and it does comply with it as far as I can tell.[/color]

Certainly, but it's just treating XHTML as html, but then that's all
you're telling it to do, since you're deliberately sending it with the
wrong mime-type.
[color=blue]
>XHTML is optimal in numerous ways, not the least of which is that it is far
>more compact than the equivalent HTML 4.01.[/color]

Utter, utter garbage, HTML 4.01 will almost always be able to me
smaller, the smallest HTML 4.01 doc is tiny compared to XHTML.
compactness certainly isn't an argument.
[color=blue]
> Plus I want to send the best document that the browser
>can handle.[/color]

Appendix C XHTML 1.0 is certainly not that!
[color=blue]
>| I can't see the javascript question, the correct place would be a
>| stylesheets group, the solution certainly doesn't rely in javascript.
>
>Sure it does. An object detection solution is what I'm after (if one
>exists.)[/color]

Javascript does not solve this problem since you cannot know what
browser is executing the javascript, you cannot rely on javascript
executing, and there are better solutions in the stylesheet group.
There's no direct correlation between the problem you have and a
javascript object, so any javascript technique you use even if willing
to accept it will only work when js is enabled will be fragile as it
will be based on knowledge of what objects the browser has as a
co-incidence to the bug, and even if we deal with all existing
browsers, new browsers will almost certainly break it.

ask in a stylesheets group.

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

[Mark Preston]

Re: IE6, xhtml, scrollbars and you

On Thu, 04 Sep 2003 09:31:06 GMT, jim@jibbering.c om (Jim Ley) wrote:
[color=blue]
>On Thu, 04 Sep 2003 00:38:24 GMT, "Nobody" <none@nope.ne t> wrote:
>[color=green]
>>XHTML is optimal in numerous ways, not the least of which is that it is far
>>more compact than the equivalent HTML 4.01.[/color]
>
>Utter, utter garbage, HTML 4.01 will almost always be able to me
>smaller, the smallest HTML 4.01 doc is tiny compared to XHTML.
>compactness certainly isn't an argument.
>[/color]
For once, I disagree with that Jim. XHTML _can_ be a lot smaller.
Doesn't, of course, mean that all page designs in XHTML _will_ be
smaller, but they probably all _could_ be if properly designed.

[Jim Ley]

Re: IE6, xhtml, scrollbars and you

On Thu, 04 Sep 2003 12:11:53 +0100, Mark Preston
<usenet@noemail address.co.uk> wrote:
[color=blue]
>On Thu, 04 Sep 2003 09:31:06 GMT, jim@jibbering.c om (Jim Ley) wrote:
>[color=green]
>>On Thu, 04 Sep 2003 00:38:24 GMT, "Nobody" <none@nope.ne t> wrote:
>>[color=darkred]
>>>XHTML is optimal in numerous ways, not the least of which is that it is far
>>>more compact than the equivalent HTML 4.01.[/color]
>>
>>Utter, utter garbage, HTML 4.01 will almost always be able to me
>>smaller, the smallest HTML 4.01 doc is tiny compared to XHTML.
>>compactness certainly isn't an argument.
>>[/color]
>For once, I disagree with that Jim. XHTML _can_ be a lot smaller.
>Doesn't, of course, mean that all page designs in XHTML _will_ be
>smaller, but they probably all _could_ be if properly designed.[/color]

HTML 4.01 and XHTML 1.0 (which is all that you're allowed to send as
text/html ) are identical in the elements they contain, however html
allows you to leave out elements from the source (they're inserted in
the parser) XHTML does not let you do this. For example the body
element is required to appear in the source in XHTML, it's not in
HTML, a closing p tag is required in XHTML, it's not in HTML. etc.
etc.

So even avoiding SHORTTAG type constructs with their known failure in
browsers we are still smaller HTML simple because we don't need all
those tags.

Jim.

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

[Lasse Reichstein Nielsen]

Re: IE6, xhtml, scrollbars and you

Mark Preston <usenet@noemail address.co.uk> writes:
[color=blue]
> For once, I disagree with that Jim. XHTML _can_ be a lot smaller.[/color]

For the same content, I doubt the few extra required attributes
makes up for HTML's possibility of omitting entire tags.
[color=blue]
> Doesn't, of course, mean that all page designs in XHTML _will_ be
> smaller, but they probably all _could_ be if properly designed.[/color]

Only if the HTML is improperly designed.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit. html>
'Faith without judgement merely degrades the spirit divine.'

[Nobody]

Re: IE6, xhtml, scrollbars and you


"Jim Ley" <jim@jibbering. com> wrote in message
news:3f5703e0.7 8872722@news.ci s.dfn.de...
| On Thu, 04 Sep 2003 00:38:24 GMT, "Nobody" <none@nope.ne t> wrote:
|
| >| Internet explorer does not claim to support XHTML, so since you cannot
| >
| >Hmmm. It does switch to "standards mode" when confronted with the XHTML
| >document type and it does comply with it as far as I can tell.
|
| Certainly, but it's just treating XHTML as html, but then that's all
| you're telling it to do, since you're deliberately sending it with the
| wrong mime-type.

What makes you think I am sending it with the wrong MIME type? I know how
to set the MIME type to whatever I want. That is not an issue. The agent
looks at the doctype identifier to differentiate between standards and
quirks mode. I have noticed that WML does not work with some
emulators/agents unless you set the MIME type properly.

|
| >XHTML is optimal in numerous ways, not the least of which is that it is
far
| >more compact than the equivalent HTML 4.01.
|
| Utter, utter garbage, HTML 4.01 will almost always be able to me
| smaller, the smallest HTML 4.01 doc is tiny compared to XHTML.
| compactness certainly isn't an argument.

You are 100% out of your mind. 1000%.

You get rid of tons of height, width and align attributes for one. Sure you
could just use style sheets with 4.01, but I want my deprecated documents to
work with all older browsers/devices, not just the ones that competently
support CSS. Get it? So when my engine outputs XHTML, it is far more
optimized a download than the HTML 4.01 equivalent.

|
| > Plus I want to send the best document that the browser
| >can handle.
|
| Appendix C XHTML 1.0 is certainly not that!

Not that for what? It certainly is the best thing to send to Gecko browsers
and IE6. Have you lost it? This is all old news.

|
| >| I can't see the javascript question, the correct place would be a
| >| stylesheets group, the solution certainly doesn't rely in javascript.
| >
| >Sure it does. An object detection solution is what I'm after (if one
| >exists.)
|
| Javascript does not solve this problem since you cannot know what
| browser is executing the javascript, you cannot rely on javascript
| executing, and there are better solutions in the stylesheet group.

I never rely on JS executing for anything that matters. That is what the
noscript tag is for! I do know that I cannot tell anything about the
browser unless scripting is enabled. You have to fallback to the LCD when
there is no information available (scripting off.)

| There's no direct correlation between the problem you have and a
| javascript object, so any javascript technique you use even if willing
| to accept it will only work when js is enabled will be fragile as it
| will be based on knowledge of what objects the browser has as a
| co-incidence to the bug, and even if we deal with all existing
| browsers, new browsers will almost certainly break it.

The thread is over anyway. Has been. The question was answered and it was
as I suspected (a style sheet issue.) So why are you heaping more on this
thread?

|
| ask in a stylesheets group.
|
| Jim.
| --
| comp.lang.javas cript FAQ - http://jibbering.com/faq/
|

[Nobody]

Re: IE6, xhtml, scrollbars and you


"Lasse Reichstein Nielsen" <lrn@hotpop.com > wrote in message
news:d6egu6oo.f sf@hotpop.com.. .
| Mark Preston <usenet@noemail address.co.uk> writes:
|
| > For once, I disagree with that Jim. XHTML _can_ be a lot smaller.
|
| For the same content, I doubt the few extra required attributes
| makes up for HTML's possibility of omitting entire tags.
|
| > Doesn't, of course, mean that all page designs in XHTML _will_ be
| > smaller, but they probably all _could_ be if properly designed.
|
| Only if the HTML is improperly designed.

That is what I am getting at. If I output deprecated code (HTML), then I
want it to handle everything prior. So the HTML equivalent of one of my
pages contains all sorts of deprecations like height, width and align
attributes. I just don't want to completely abandon non-CSS agents As long
as I don't get validation warnings (no problem so far), and can reproduce my
content on all known browsers since '93, then I am happy.

The great thing about CGI is that you never have to go back and rewrite all
of your pages (an impossible task of course, yet one that many endeavor to
do) when your philosophy and/or the technology changes.

|
| /L
| --
| Lasse Reichstein Nielsen - lrn@hotpop.com
| Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit. html>
| 'Faith without judgement merely degrades the spirit divine.'

[Jim Ley]

Re: IE6, xhtml, scrollbars and you

On Thu, 04 Sep 2003 12:58:45 GMT, "Nobody" <none@nope.ne t> wrote:
[color=blue]
>
>"Jim Ley" <jim@jibbering. com> wrote in message
>news:3f5703e0. 78872722@news.c is.dfn.de...
>| On Thu, 04 Sep 2003 00:38:24 GMT, "Nobody" <none@nope.ne t> wrote:
>|
>| >| Internet explorer does not claim to support XHTML, so since you cannot
>| >
>| >Hmmm. It does switch to "standards mode" when confronted with the XHTML
>| >document type and it does comply with it as far as I can tell.
>|
>| Certainly, but it's just treating XHTML as html, but then that's all
>| you're telling it to do, since you're deliberately sending it with the
>| wrong mime-type.
>
>What makes you think I am sending it with the wrong MIME type?[/color]

Because internet explorer doesn't render it if you send it with the
correct one, so the only way to get IE to render it is to lie and send
text/html.
[color=blue]
>| Utter, utter garbage, HTML 4.01 will almost always be able to me
>| smaller, the smallest HTML 4.01 doc is tiny compared to XHTML.
>| compactness certainly isn't an argument.
>
>You are 100% out of your mind. 1000%.
>
>You get rid of tons of height, width and align attributes for one.[/color]

You can get rid of those in HTML 4.01 too... XHTML 1.0 is just a
reformulation of HTML 4.01 with a different SGML declaration and a few
bits to become XML based.

So yes you could say your optimised XHTML is less verbose than your
crappily authored HTML, however your optimsed HTML will be even
smaller than your optimised XHTML, simply becuase it allows you to
ignore elements.
[color=blue]
>| Appendix C XHTML 1.0 is certainly not that!
>
>Not that for what? It certainly is the best thing to send to Gecko browsers
>and IE6. Have you lost it? This is all old news.[/color]

Some back up for the assertion, or even a reason why, we know IE does
not support XHTML other than it being tag-soup, we know that mozilla
has bugs with XHTML which it does not have with HTML (it does fine in
tag-soup mode XHTML just like IE, but it's pretty bad in
application/xhtml+xml XHTML)
[color=blue]
>The thread is over anyway. Has been. The question was answered and it was
>as I suspected (a style sheet issue.) So why are you heaping more on this
>thread?[/color]

We're discussing, that's what newsgroups are for, if we just answered
incompetent questions from people who don't know what's on-topic for
the group and then stopped not much would happen.

We're now a long way off-topic, so follow-ups set.

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