On Thu, Jul 31, 2008 at 6:25 PM, Brion Vibber brion@wikimedia.org wrote:
Icky... but perhaps no good way around it I guess. :)
The tricky bit is that for HTML mode you want to wrap the "<![CDATA[" and "]]>" bits in comments (/* blah */) so they don't interfere with the JS or CSS code.
Does that necessarily generally work? Bah, this shouldn't be so annoyingly hard...
Yeah, I see the problem. There are two reasonable solutions I see. One:
public static function escapeCdata( $data ) { if( strpos( ']]>', $data ) == false ) { return $data; } return ''; }
Two:
public static function escapeCssForCdata( $css ) { return str_replace( ']]>', ']]\00003E', $css ); }
The first one is potentially annoying, but in both CSS and JavaScript it should be easy to work around the limitation. The second one is maybe nicer for CSS, *except* that I'm not totally sure that it would always work.
I *think* the only place that literal ']]>' would be valid in CSS is comments and string literals. Comments don't matter, and I *hope* that all CSS clients would treat \00003E the same as > in a literal string. Or in a URL, which isn't really a literal string in CSS, is it? Or similar things, I guess . . .
The first way seems to be the most straightforward way to handle it for now. It's unlikely to come up with any reasonable frequency, and when it does it can be worked around by authors. If the second way actually works consistently, it would be nicer for CSS. I doubt anything comparable would work for JavaScript, since who knows where ']]>' could occur? if( x[y[z]]>7 ) {...}