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 Thu, 04 Sep 2003 00:08:08 GMT, "Nobody" <no**@nope.net> 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
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.
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.

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

[Nobody]

"Jim Ley" <ji*@jibbering.com> wrote in message
news:3f***************@news.cis.dfn.de...
| On Thu, 04 Sep 2003 00:08:08 GMT, "Nobody" <no**@nope.net> 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.javascript FAQ - http://jibbering.com/faq/
|

[Lasse Reichstein Nielsen]

"Nobody" <no**@nope.net> 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:hidden".
(<URL:http://www.w3.org/TR/CSS2/visufx.html#overflow>)

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:hidden;}
Remember that in standards mode, the root of the document tree is
document.documentElement (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. 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.
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.compatMode 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).
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.

I typically have a statement like:
var root = document.documentElement || document.body;
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/author/dhtml/overview/ccomment_ovw.asp>

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
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.
and funky colored scrollbars (hey people ask for them)
And boy, do they get them!
Actually, Opera can support colored scrollbars too.
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 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.
/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.'

[Nobody]

"Lasse Reichstein Nielsen" <lr*@hotpop.com> wrote in message
news:ek**********@hotpop.com...
| "Nobody" <no**@nope.net> 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:hidden".
| (<URL:http://www.w3.org/TR/CSS2/visufx.html#overflow>)

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:hidden;}

Yeah, I figured that.

| Remember that in standards mode, the root of the document tree is
| document.documentElement (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.compatMode 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.documentElement || 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.

[DU]

Lasse Reichstein Nielsen wrote:

"Nobody" <no**@nope.net> 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:hidden".
(<URL:http://www.w3.org/TR/CSS2/visufx.html#overflow>)

God would have known that it was hidden, not hide. :)
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.
The overflow you might want is on the html element: html {overflow:hidden;}
This is debattable. MSIE 6 for windows has the browser default
overflow:scroll for the root element. So, you would need to use
overflow:visible or overflow:auto instead.
Remember that in standards mode, the root of the document tree is
document.documentElement (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.

"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.

Important and unknown default browser values:
http://www10.brinkster.com/doctorunc...ultValues.html

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.compatMode 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).

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.

I typically have a statement like:
var root = document.documentElement || document.body;
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/author/dhtml/overview/ccomment_ovw.asp>

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

and funky colored scrollbars (hey people ask for them)

And boy, do they get them!
Actually, Opera can support colored scrollbars too.

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.

Yep. That is even documented also.
Mozilla followed IE for no apparent reason.

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

and now this scrollbar thing.

That is just the difference between standards and quirks mode.

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/doctorunc...e7Section.html

[Lasse Reichstein Nielsen]

DU <dr*******@hotREMOVEmail.com> writes:

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.
Yes, but the point is that the default height is "auto", so you won't get
any overflow.
This is debattable. MSIE 6 for windows has the browser default
overflow:scroll for the root element. So, you would need to use
overflow:visible or overflow:auto instead.
"overflow:hidden" will also work. No scrollbar. Bad choice, but seemed
to be what the original poster wanted.
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.
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.
"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
Yes. Strictly speaking, that doesn't leave room for turning that
scrollbar off.
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.
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 (documentElement) that controls
the scrollbar.
Important and unknown default browser values:
http://www10.brinkster.com/doctorunc...ultValues.html

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

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

[Lasse Reichstein Nielsen]

"Nobody" <no**@nope.net> writes:

Er. It DOES work in quirks mode. Standards mode indeed causes a problem
with my current coding. Is that what you meant?
Exactly :)
What does that mean? I output a DX-specific style or a background-image
accordingly to create gradient effects.
Ah. I was thinking of embedded ActiveX controls that were an important
part of the page. Pure decoration should be safe.
Must update database. Opera as of...?

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 - 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 00:38:24 GMT, "Nobody" <no**@nope.net> 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.
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.
Plus I want to send the best document that the browser
can handle.
Appendix C XHTML 1.0 is certainly not that!
| 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.
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.javascript FAQ - http://jibbering.com/faq/

[Mark Preston]

On Thu, 04 Sep 2003 09:31:06 GMT, ji*@jibbering.com (Jim Ley) wrote:

On Thu, 04 Sep 2003 00:38:24 GMT, "Nobody" <no**@nope.net> wrote:

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.

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]

On Thu, 04 Sep 2003 12:11:53 +0100, Mark Preston
<us****@noemailaddress.co.uk> wrote:

On Thu, 04 Sep 2003 09:31:06 GMT, ji*@jibbering.com (Jim Ley) wrote:

On Thu, 04 Sep 2003 00:38:24 GMT, "Nobody" <no**@nope.net> wrote:

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.

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.

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.javascript FAQ - http://jibbering.com/faq/

[Lasse Reichstein Nielsen]

Mark Preston <us****@noemailaddress.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.

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

[Nobody]

"Jim Ley" <ji*@jibbering.com> wrote in message
news:3f***************@news.cis.dfn.de...
| On Thu, 04 Sep 2003 00:38:24 GMT, "Nobody" <no**@nope.net> 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.javascript FAQ - http://jibbering.com/faq/
|

[Nobody]

"Lasse Reichstein Nielsen" <lr*@hotpop.com> wrote in message
news:d6**********@hotpop.com...
| Mark Preston <us****@noemailaddress.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 - 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 12:58:45 GMT, "Nobody" <no**@nope.net> wrote:

"Jim Ley" <ji*@jibbering.com> wrote in message
news:3f***************@news.cis.dfn.de...
| On Thu, 04 Sep 2003 00:38:24 GMT, "Nobody" <no**@nope.net> 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?
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.
| 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.
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.
| 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.
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)
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?

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.javascript FAQ - http://jibbering.com/faq/

[Nobody]

"DU" <dr*******@hotREMOVEmail.com> wrote in message
news:bj**********@news.eusc.inter.net...
| Lasse Reichstein Nielsen wrote:
| > "Nobody" <no**@nope.net> 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:hidden".
| > (<URL:http://www.w3.org/TR/CSS2/visufx.html#overflow>)
| >
|
| 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!)

|
| > 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:hidden;}
|
| This is debattable. MSIE 6 for windows has the browser default
| overflow:scroll for the root element. So, you would need to use
| overflow:visible 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.

|
| > Remember that in standards mode, the root of the document tree is
| > document.documentElement (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.

|
| "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.)

|
| Important and unknown default browser values:
|
http://www10.brinkster.com/doctorunc...wsersDefaultVa
lues.html
|
| >
| >>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.compatMode 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).
| >
| >
| >>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.
| >
| > I typically have a statement like:
| > var root = document.documentElement || document.body;
| > 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>
| >
| >
| >>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
| > 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.
| >
| >
| >>and funky colored scrollbars (hey people ask for them)
| >
| >
| > And boy, do they get them!
| > Actually, Opera can support colored scrollbars too.
| >
| >
| >>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.
|
|
| Yep. That is even documented also.
|
|
| Mozilla followed IE for no
| > apparent reason.
| >
|
| MSIE margins on the body element is {margin:15px 10px;} while Mozilla's

Not really what I was after there. The point is that I had set the padding
in Opera to 0px to achieve what margin:0px does in IE. Who knows why?

| is {margin:8px;}. God would have known that :)

He does. Thanks. Now go and be prosperous.

|
|
|
| >
| >>and now this scrollbar thing.
| >
| >
| > That is just the difference between standards and quirks mode.
| >
|
| 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

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

| date of MSIE 7 for next week. That would be fine :)

I thought that was out. Have to call down to Hell and ask Bill Gates what
the holdup is!

[Nobody]

"Lasse Reichstein Nielsen" <lr*@hotpop.com> wrote in message
news:fz**********@hotpop.com...
| DU <dr*******@hotREMOVEmail.com> writes:
|
| > > 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.
|
| Yes, but the point is that the default height is "auto", so you won't get
| any overflow.
|
| > This is debattable. MSIE 6 for windows has the browser default
| > overflow:scroll for the root element. So, you would need to use
| > overflow:visible or overflow:auto instead.
|
| "overflow:hidden" will also work. No scrollbar. Bad choice, but seemed
| to be what the original poster wanted.

It is a bad choice perhaps because overflow:auto would in theory work the
same way (my content always has a height of 100% and scrolls by itself.)
However, I only drop this style off if I am also sending the styles to make
the div's scroll, so there is no real danger. I have also experienced
numerous issues with 1px that hangs off the end of the page for no reason
(usually an IE bug.) And figure what the hell? If I can hide the
scrollbars of the root element then I can show them on child elements.

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

If you can hide 'em on the root element, then you can show them on the div's
inside. This is pretty iron-clad. Plus I check for IE on the server anyway
(using my own method that actually gives me a user-agent from a
script-enabled client.) Clearly if you turn scripting off on of these
pages, the scrolling goes back to the norm (no problem there.)

|
| > "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
|
| Yes. Strictly speaking, that doesn't leave room for turning that
| scrollbar off.
|
| > > 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.
|
| So will it in quirks mode. That is an IE interface decission.

It DOES work in quirks mode. overflow:hidden on the body element hides the
scrollbars. So you lost me here...

|
| 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 (documentElement) that controls
| the scrollbar.
|
| > Important and unknown default browser values:
| >
http://www10.brinkster.com/doctorunc...wsersDefaultVa
lues.html
|
| Cute :) I see Opera 7.2 still needs to fix their getComputedStyle for
| lengths that are "auto".

Thank heavens I don't use that. Too new. I suspected there might be issues
there.

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

[Lasse Reichstein Nielsen]

"Nobody" <no**@nope.net> writes:

You are 100% out of your mind. 1000%.
Why not exaggerate a bit?
You get rid of tons of height, width and align attributes for one.
Those were deprecated in HTML 4, so you are using HTML 4.01
Transitional. You could also use XHTML 1.0 Transitional, the two are
equivalent in expressibility. It is only the syntax that is slightly
different (and backwards compatible for tag-soup browsers).
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?
Ye, that explains your deprecated pagess. But it doesn't explain why
you don't use non-deprecated HTML instead of XHTML, because that would
be smaller (if size is an issue).
So when my engine outputs XHTML, it is far more optimized a download
than the HTML 4.01 equivalent.

The HTML 4.01 Transitional version is *not* equivalent. An HTML 4.01
Strict version might be equivalent, and would probably be smaller
than XHTML.

You can send anything you want, I just argue against the statement
"XHTML is smaller than HTML". Equivalent pages can be made smaller
in HTML. Using HTML attributes in HTML and CSS in XHTML is not
giving equivalent pages.

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

[Nobody]

"Lasse Reichstein Nielsen" <lr*@hotpop.com> wrote in message
news:zn**********@hotpop.com...
| "Nobody" <no**@nope.net> writes:
|
| > You are 100% out of your mind. 1000%.
|
| Why not exaggerate a bit?
|
| > You get rid of tons of height, width and align attributes for one.
|
| Those were deprecated in HTML 4, so you are using HTML 4.01
| Transitional.

For older browsers, yes.

You could also use XHTML 1.0 Transitional, the two are
| equivalent in expressibility. It is only the syntax that is slightly
| different (and backwards compatible for tag-soup browsers).

That's why I use the HTML 4.01 for older browsers. Strictly for backwards
compatibility.

|
| > 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?
|
| Ye, that explains your deprecated pagess. But it doesn't explain why
| you don't use non-deprecated HTML instead of XHTML, because that would
| be smaller (if size is an issue).

Because it would cause things to look differently on browsers that do not
competently support CSS.

|
| > So when my engine outputs XHTML, it is far more optimized a download
| > than the HTML 4.01 equivalent.
|
| The HTML 4.01 Transitional version is *not* equivalent. An HTML 4.01

What do you mean by equivalent? I mean that it looks the same in the
browser.

| Strict version might be equivalent, and would probably be smaller
| than XHTML.

I could see sending html strict to IE4 maybe. Why would I want to send it
to old browsers though? Everything else I want deprecated so that there is
no question it will look/feel identical to the XHTML version. For instance,
IE2 or NS1 will change the look of my pages if I rely strictly on CSS for
layout. 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.

|
| You can send anything you want, I just argue against the statement
| "XHTML is smaller than HTML". Equivalent pages can be made smaller
| in HTML.

Can be, but why would I generate such code? For whom? What would be the
benefit? If your agent can't handle the latest stuff, then I just send HTML
4,01. It is safe and easy. I can flip a switch on my engine to send HTML
strict if there are browsers that would really groove on it and if the size
of the files dropped significantly. Something to think about anyway.

Using HTML attributes in HTML and CSS in XHTML is not
| giving equivalent pages.

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.) 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?

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

[Lasse Reichstein Nielsen]

"Nobody" <no**@nope.net> writes:

Because it would cause things to look differently on browsers that do not
competently support CSS.
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.

Actually, I have yet to see a browser that supports XHTML and not HTML,
although I can believe that they exist for specialized uses.
What do you mean by equivalent? I mean that it looks the same in the
browser.
So does a large gif image. By equivalent, I mean similarly structured,
the same elements in the same order.
I could see sending html strict to IE4 maybe. Why would I want to send it
to old browsers though?
Nobody said you should change your deprecated HTML that you send to
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.
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.
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.
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.

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
(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.

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.

/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 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.javascript FAQ - http://jibbering.com/faq/

[DU]

Nobody wrote:

"DU" <dr*******@hotREMOVEmail.com> wrote in message
news:bj**********@news.eusc.inter.net...
| Lasse Reichstein Nielsen wrote:
| > "Nobody" <no**@nope.net> 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:hidden".
| > (<URL:http://www.w3.org/TR/CSS2/visufx.html#overflow>)
| >
|
| 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:hidden;}
|
| This is debattable. MSIE 6 for windows has the browser default
| overflow:scroll for the root element. So, you would need to use
| overflow:visible 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:scroll;} 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.documentElement (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.net> 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.javascript FAQ - http://jibbering.com/faq/

[Lasse Reichstein Nielsen]

"Nobody" <no**@nope.net> 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.'