Last modified: 2011-03-13 17:46:05 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...]].
PS: Can someone make bugzilla not add stupid text wrapping to all my postings here?
This is not a bug in MediaWiki, but a deliberate change in the works to improve security
by avoiding MSIE's CSS parser bugs.
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: "&#160;"? 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?
Typo: I meant to type " " and link to [[en:IPA]].
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.
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.
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 " " 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.
I've changed [[en:template:IPA]], so it is no longer affected by this Mediawiki bug.
Changing all WONTFIX high priority bugs to lowest priority (no mail should be generated since I turned it off for this.)