255117 - microsoft.com - MSDN (now only MSDN2) code samples are garbled because <pre> tag is made useless by "white-space: normal;" CSS rule

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[Andreas Kunz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803

Starting 1-2 days ago, the MSDN code samples at least in the .NET Framework
Class Library look really unreadable.

This is caused by the following css rule in dtue.css:

PRE {
	WHITE-SPACE: normal; 
}

"white-space: normal;" is the opposite of "white-space: pre;" (which itself acts
just like <pre>).
So why would someone sane add the "white-space: normal;"-rule to a <pre>
element? The only reason I can think of is that he favours a browser that does
NOT honor this css rule and wants to exclude all the others.
Current Opera is also affected.

Reproducible: Always
Steps to Reproduce:
1. Go to given URL
2. Look at the code sample
Actual Results:  
Code looks garbled, no line breaks there.

Expected Results:  
Code should look formatted properly.

To solve the problem locally for yourself, add the following style rule to the
userContent.css file in your profile's chrome folder:

pre {
   white-space: pre !important; 
}

This makes <pre>'s be formatted like they are meant to be.

Comment 1

[Andreas Kunz]

I contacted microsoft about the problem via:
"MSDN Online: Send web site suggestions, requests, comments and feedback"
and will post any answer I get here.

Comment 2

[Andreas Kunz]

Attachment: testcase

This testcase shows a <pre> element with all kinds of "white-space" style
attached.

IE 6 does render them all identical which means it either ignores or does not
know the white-space style, at least for the <pre> element.

The CSS 1 specification (http://www.w3.org/TR/REC-CSS1#white-space) says an
user agent may use its default white-space value of each element instead of the
one supplied by the page - if it only complies to CSS1 core. 
This seems to be what IE does.

But this bug report is not about IE bugs or IE CSS conformance, but about the
bug in the msdn web site. And in my eyes this bug is clearly there because I
see no sane reason to have this style rule.

Comment 3

[Andreas Kunz]

Got this response from Microsoft:

> Please be informed that this is a known issue with the MSDN Library when
> viewed with browsers other than Internet Explorer. Improved performance
> across all browsers is a major consideration in future improvements of
> the MSDN site.

Heh, I wonder why they inserted this (IMHO absolutely nonsensical) css rule,
then... I'll answer their mail...

Comment 4

[OstGote!]

This bug should be blocking bug 114158.

Comment 5

[Ryuichi KUBUKI]

*** Bug 255474 has been marked as a duplicate of this bug. ***

Comment 6

[Martijn Wargers (dead)]

*** Bug 256453 has been marked as a duplicate of this bug. ***

Comment 7

[Lars]

> To solve the problem locally for yourself, add the following style rule to the
> userContent.css file in your profile's chrome folder:
> 
> pre {
>    white-space: pre !important; 
> }
> 
> This makes <pre>'s be formatted like they are meant to be.

I cant seem to find this userContent.css file. (all I can find is the
userContent-example.css file in the defaults\profile\US\chrome folder) Where is
it supposed to be?

(I'm using firefox 0.92 and XP)

Comment 8

[Andreas Kunz]

Lars:
Just create the file yourself (e.g. rename the example file).

Comment 9

[Bill Mason]

*** Bug 257805 has been marked as a duplicate of this bug. ***

Comment 10

[Curtis Porter]

ChromEdit is a handy extension that makes placing the workaround CSS code easier
for those who might be less comfortable/familiar with the locations of the files:

http://extensionroom.mozdev.org/more-info/chromedit

Comment 11

[Bill Mason]

*** Bug 258590 has been marked as a duplicate of this bug. ***

Comment 12

[Bill Mason]

*** Bug 259355 has been marked as a duplicate of this bug. ***

Comment 13

[Bill Mason]

*** Bug 259489 has been marked as a duplicate of this bug. ***

Comment 14

[tommyjb]

(In reply to comment #3)

I e-mailed Microsoft myself about this and here is the latest reply I've received:

> Hello Tom,
> 
> Thank you for writing back and providing additional information regarding the
> problem you have reported.
> 
> We will be contacting you once we have fixed the samples.

I take this to mean that they'll contact me once they've fixed the erroneous
code samples.

I'll post here if they e-mail me again...

Comment 15

[Martijn Wargers (dead)]

*** Bug 260852 has been marked as a duplicate of this bug. ***

Comment 16

[Phil Ringnalda (:philor)]

*** Bug 264883 has been marked as a duplicate of this bug. ***

Comment 17

[tommyjb]

(In reply to comment #14)

I received another e-mail:

 I have discussed your concern with our Web team and they told me
that the issue requires a site-wide revision of MSDN Online
code. This revision would adversely impact other features of content performance.

At this time, there is no final decision to make the adjustment to the site code.

However, improved functionality across all browsers is a
major consideration of the next major MSDN Online update.

I apologize for the inconvenience. 

Comment 18

[Andreas Kunz]

How can the insane css rule

PRE {WHITE-SPACE: normal;}

be fundamental to the MSDN site???
And how can changing it to "WHITE-SPACE: pre;" require a site-wide revision and
adversely impact the site?
Sorry, but this answer smells like just a lie.
I've been using the MSDN site intensely during the last months with this
corrected css rule and I haven't seen ANY adverse impact - and surely no impact
that is as adverse as making the whole site unusable!!

Comment 19

[tommyjb]

Latest reply from Microsoft:

> We are investigating an alternative solution that may repair the problem; as
yet > there is no time table for its implementation, but we are actively pursuing a
> resolution.

P.S.: My e-mails to them have been influenced by your comments here, Andreas, so
if you would like me to send a reply from yourself, that's fine.

Comment 20

[web]

Hmm, the code samples look okay now.  It seems that they changed dtue.css to:

pre {
white-space: pre-wrap;       
white-space: -moz-pre-wrap;  /* Mozilla, since 1999 */
white-space: -pre-wrap;      /* Opera 4-6 */
white-space: -o-pre-wrap;    /* Opera 7 */
word-wrap: break-word;       /* Internet Explorer 5.5+ *//* css-3 */
}

Should this bug be closed?

Note that the MSDN2 code samples appear broken, but this is probably because
Firefox doesn't support "white-space: pre-wrap;".

Comment 21

[Andreas Kunz]

Well, msdn2 has the <pre> rule from
http://msdn2.microsoft.com/library/shared/ddueml.css: 

pre
{
/*	margin: 0px 0px 0px 0px; */
	white-space:normal;
	word-wrap:break-word;
	word-break:break-all;
}

There's still this nonsensical "white-space:normal;" and this doesn't work in
any Gecko product I have, while in the original msdn pages there is the
-moz-pre-wrap rule that seems to work fine with Firefox as well as Seamonkey (I
don't know of any differences between them wrt stylesheets anyway).

So what to do with this bug? It's still a problem in the Microsoft web site, but
now only a sort of "beta" web site as I understand it. I'll let this bug open
and correct example URL and add "MSDN2" to the summary. 
So now let's contact the msdn2 team...

For easy reference: the old URL (original msdn) was
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemWindowsFormsGroupBoxClassTopic.asp
new msdn2 one:
http://msdn2.microsoft.com/library/6fawty39.aspx

Comment 22

[web]

Yes, but the pre tags for the source code have the includeSC class, which has
the following CSS style:

.includeSC
{
	background: gainsboro;
	font: 100% Monospace, Courier New, Courier;
	color: #000066;
	white-space:pre-wrap;
	word-wrap:break-word;
	word-break:break-all;
}

If I understand the CSS spec correctly, the white-space: pre-wrap; here should
override the white-space: normal; on the pre element.  Is this bug now a
duplicate of 230555?

Comment 23

[Martijn Wargers (dead)]

*** Bug 273958 has been marked as a duplicate of this bug. ***

Comment 24

[Felix Miata]

font: 100% Monospace, Courier New, Courier;

I wonder if putting in courier twice was intentional? ;-)

Comment 25

[Felix Miata]

*** Bug 278917 has been marked as a duplicate of this bug. ***

Comment 26

[Kevin Brosnan]

*** Bug 279129 has been marked as a duplicate of this bug. ***

Comment 27

[Kevin Brosnan]

*** Bug 279630 has been marked as a duplicate of this bug. ***

Comment 28

[Erik Fabert]

*** Bug 280349 has been marked as a duplicate of this bug. ***

Comment 29

[:Gavin Sharp [email: [e-mail]]]

*** Bug 280349 has been marked as a duplicate of this bug. ***

Comment 30

[Dan Erikson]

*** Bug 280892 has been marked as a duplicate of this bug. ***

Comment 31

[Frank Wein [:mcsmurf]]

*** Bug 285459 has been marked as a duplicate of this bug. ***

Comment 32

[Kevin Brosnan]

*** Bug 288021 has been marked as a duplicate of this bug. ***

Comment 33

[Frank Wein [:mcsmurf]]

fixed, MSDN made a IE-only CSS rule out of it:
    <!--[if IE]><style>pre { white-space: normal; }</style><![endif]-->