Last modified: 2011-03-13 17:46:05 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T5588, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 3588 - CSS comments are corrupted to a space or a non-breaking space
CSS comments are corrupted to a space or a non-breaking space
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All Mac OS X 10.4
: Lowest major (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/Template...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-02 22:15 UTC by Michael Zajac
Modified: 2011-03-13 17:46 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Michael Zajac 2005-10-02 22:15:04 UTC
This is a new behaviour.  All CSS comments in inline CSS within wikitext, or inline CSS entered in a template are 
changed to either a single space character, or to the numeric entity for a non-breaking space (seemingly at 
random, both appear in the same web page).  This breaks CSS comments, including perfectly valid workarounds 
for browser bugs.

Example: this completely breaks the behaviour of [[en:Template:IPA]] and several others, which work around a 
font-rendering problem in MSIE/Windows, and appear in the English Wikipedia literally thousands of times.  
This template, containing only correctly-formed CSS, gives MSIE a font specification for rendering 
pronunciation in the [[en:International Phonetic Alphabet]].  Then it provides a second declaration ("font-family: 
inherit;") which hides the first spec from all other browsers.  But MSIE ignores the second spec because of a 
rendering bug. [http://www.dithered.com/css_filters/css_only/property_space_comment.html]

To see the effects of this bug, view the article on [[en:IPA]] using Firefox or Safari, and notice how IPA text is 
rendered in different fonts, depending on what you have installed at the system.

More info at [[en:Template talk:IPA#This is annoying...]].
Comment 1 Michael Zajac 2005-10-02 22:15:45 UTC
PS: Can someone make bugzilla not add stupid text wrapping to all my postings here?
Comment 2 Brion Vibber 2005-10-03 05:14:09 UTC
This is not a bug in MediaWiki, but a deliberate change in the works to improve security 
by avoiding MSIE's CSS parser bugs.

Resolving WONTFIX.
Comment 3 Michael Zajac 2005-10-03 15:36:19 UTC
Is there any documentation about this feature?

1) Why does it delete perfectly valid CSS?

2) Why does it randomly substitute a plain space or the entity for a non-breaking space: " "?  This 
must be a bug.  It breaks display in Firefox and Safari: just look at what it's done to [[en:IPA]: IPA text shows 
up randomly in two different fonts if you have the right (wrong) set of fonts installed.

3) Does this affect code in templates or all wikitext?  Does it affect external style sheets, like monobook.css?

Thanks.
Comment 4 Michael Zajac 2005-10-03 15:38:42 UTC
Typo: I meant to type " " and link to [[en:IPA]].
Comment 5 Michael Zajac 2005-10-03 16:07:17 UTC
Clarification: the new feature takes valid CSS comments, and ''sometimes'' converts them to a numeric HTML entity, 
rendering the style sheet invalid, and potentially breaking its display in all browsers.
Comment 6 Brion Vibber 2005-10-03 20:01:48 UTC
http://www.w3.org/TR/CSS1#comments
http://www.w3.org/TR/REC-CSS2/syndata.html#comments

The CSS1 spec defines comments as equivalent to whitespace, and the CSS2 spec says 
comments can appear anywhere between tokens and their contents don't affect the 
rendering (which is to say, equivalent to whitespace)

1) It doesn't; it strips comments and replaces them with whitespace to preserve valid 
CSS parsing, thus avoiding cases where IE's incorrect parsing is unsafe and can be 
used for cross-site scripting attacks.

2) Only a space is ever added. A postprocessing step later on may be adding the non-
breaking space if it's near punctuation such as a colon; if that's a problem it is 
likely to occur whereever you have such spaces in any wiki text, including in style 
attributes, and is not new behavior. Can you confirm?

3) Style attributes on all wikitext.
Comment 7 Michael Zajac 2005-10-04 14:41:29 UTC
1) Sounds reasonable.

2) Well, something is adding the numeric entity for a non-breaking space, sometimes.  Have a look at the source code of 
<http://en.wikipedia.org/wiki/IPA>.  Template:IPA is used 447 times on the page.  100 of those occurrences have the 
empty comment turned into a plain space, 347 of them have "&#160;" added in the middle instead, breaking the CSS.  

Either it sometimes puts in a Unicode non-breaking space (U+00A0) which gets converted to an entity later, or some post-
processing is sometimes adding the entity on its own.  Either behaviour is wrong, so please reopen this bug.

3) So it looks like this construction will work fine if I put it into monobook.css.  An even better solution would be to find 
someone with access to MSIE-specific style sheets, and avoid exploiting browser quirks.  Since we have a workaround, this 
bug is not urgent.

Thanks.
Comment 8 Michael Zajac 2005-10-04 15:38:53 UTC
I've changed [[en:template:IPA]], so it is no longer affected by this Mediawiki bug.  
Comment 9 Mark A. Hershberger 2011-03-13 17:46:05 UTC
Changing all WONTFIX high priority bugs to lowest priority (no mail should be generated since I turned it off for this.)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links