css-scrollbar-properties, DOCTYPE and InternetExplorer 6.0
Peter Rohleder
don't work in InternetExplorer if I use the document-type
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
If I use <html> without any setting of the document-type the
css-scrollbar-settings work.
If I prefix "<!DOCTYPE..." with
<?xml version="1.0" encoding="iso-8859-1"?>
it also works.
I'm curious about the answer
Peter Rohleder
Matthias Gutfeldt
Doctype Switch is the answer. scrollbar properties are not a part of the
CSS specification, therefore I guess IE6 ignores them in standard mode.
See this here for a general explanation:
<http://gutfeldt.ch/matthias/articles/doctypeswitch.html>
And here are the specifics for Internet Explorer 6:
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html/cssenhancements.asp>
Matthias
Jukka K. Korpela
> Doctype Switch is the answer.
Maybe, but I'm not sure of the question.
> scrollbar properties are not a part
> of the CSS specification, therefore I guess IE6 ignores them in
> standard mode.
If I test
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<title>doctype test</title>
<style type="text/css">
textarea { scrollbar-base-color: red; }
body { font-size: medium; }
</style>
foo
<textarea rows="5" cols="20">
</textarea>
I get a red scrollbar, even though IE is apparently in "standard" mode
(since it shows "foo" in normal font - if I remove the doctype, IE goes
to "quirks" mode and treats normal as bigger than normal).
But the OP might have something else on the page that triggers some
oddity. Actually, if I change red to 'red', making the style sheet
syntactically malformed (color keywords shall not be quoted), then
IE 6 stops using red color in "standard" mode but keeps using it in
"quirks" mode.
So apparently in quirks mode, IE 6 deliberately applies broken parsing,
and this might not be specifically related to particular _properties_.
(Depending on one's attitude, intentionally broken parsing might be
called "liberal", "practical", or "friendly".)
> And here are the specifics for Internet Explorer 6:
> <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dn
> ie60/html/cssenhancements.asp>
I thought I had seen it before and wondered where the _information_
about the effects of "quirks" mode was, but it seems it's now there in
some detail. The page carries a 2004 vintage denotation at the bottom,
so maybe it has been enhanced, or maybe I just hadn't realized it has
quite some details.
Some of it is pretty funny, though:
"Note When you switch on standards-compliant mode, the white-space
property applies only to block-level elements, such as a DIV element.
When standards-compliant mode is not switched on, and with Internet
Explorer 5.5, this property applies to all visible elements."
That would mean conformance to CSS 2.0 as written, ignoring the so-
called "Errata", and ignoring the CSS 2.1 draft and all the statements
that apologize for the situation. The white-space property was probably
always _meant_ to apply to all elements. On the other hand, IE 6 does
just the opposite of what the document claims, since
<span style="white-space: pre">foo bar</span>
is displayed as "foo bar" in "standards" mode, "foo bar" (in larger
font) in "quirks" mode.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Alan J. Flavell
> (Depending on one's attitude, intentionally broken parsing might be
> called "liberal", "practical", or "friendly".)
Or "dangerous", since it's a basic compatibility requirement of CSS to
work when unsupported styles are ignored (and how can a browser
possibly know whether something that doesn't parse might be some new
CSS+ property that it doesn't yet support?); whereas guessing at the
meaning of something that doesn't parse has been causing disasters
right from the early days of quasi-CSS support in IE3.* - but somehow
the lessons never seem to get learned.
[f'ups narrowed]
Steve Fulton
> Peter Rohleder wrote:
>> Can anybody explain me why the setting of the css-scrollbar-properties
>> don't work in InternetExplorer if I use the document-type
>>
>> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
>> <html xmlns="http://www.w3.org/1999/xhtml">
>>
>> If I use <html> without any setting of the document-type the
>> css-scrollbar-settings work.
>>
>> If I prefix "<!DOCTYPE..." with
>> <?xml version="1.0" encoding="iso-8859-1"?>
>>
>> it also works.
>>
>> I'm curious about the answer
>
> Doctype Switch is the answer. scrollbar properties are not a part of the
> CSS specification, therefore I guess IE6 ignores them in standard mode.
In quirks mode, IE use styles applied to the body element for the canvas; in
standards mode, it uses styles applied to the html element. Try the following
rules in IE in standards mode and notice which borders enclose the scrollbars.
html { border: solid 2px red; }
body { border: solid 2px blue; }
"Who Moved My Canvas?"
<http://msdn.microsoft.com/library/en-us/dnie60/html/cssenhancements.asp#cssenha
ncements_topic4>
--
Steve
All truth passes through three stages. First, it is ridiculed. Second,
it is violently opposed. Third, it is accepted as being self-evident.
-Arthur Schopenhauer
Jukka K. Korpela
> "Note When you switch on standards-compliant mode, the
> white-space property applies only to block-level elements, such as
> a DIV element. When standards-compliant mode is not switched on,
> and with Internet Explorer 5.5, this property applies to all
> visible elements."
It seems that this simply nonsense and not the opposite of truth, as I
first thought, after having tested with white-space: pre only.
I think the difference between "quirks" and "standards" mode is simply
that white-space: pre is ignored in "quirks" mode, irrespectively of
whether it's specified for a block level or an inline element. If I use
white-space: nowrap, it works in both modes and for both types of
elements.
And this is effectively what the Microsoft document says right before
the paragraph I quoted. That paragraph might actually reflect just
someone's idea of what should have been done. (Or maybe the feature was
in fact implemented, then removed.)
--
Yucca, http://www.cs.tut.fi/~jkorpela/