<div dir="ltr">Really dumb question, but if you're just talking about the CSS itself (and not the <script> wrappers), why can't you just pass it through wp_filter_nohtml_kses()? </div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Jan 30, 2014 at 12:36 PM, Otto <span dir="ltr"><<a href="mailto:otto@ottodestruct.com" target="_blank">otto@ottodestruct.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">On Thu, Jan 30, 2014 at 11:20 AM, Chip Bennett <span dir="ltr"><<a href="mailto:chip@chipbennett.net" target="_blank">chip@chipbennett.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">It is true that a good custom CSS Plugin will save settings on a per-Theme basis. But the critical criterion isn't whether a Plugin *can* do something; rather, it is whether the *something* is functional or presentational. After all, technically speaking, a Plugin *can* add Theme support for custom headers and custom backgrounds. Should we force Theme developers then to use a custom header/background Plugin, simply because one exists and can accomplish the task?<div>
<br></div><div>Custom CSS is presentational, and specific to the Theme. As such, I believe it falls squarely within the purview of Themes, and if Themes want to provide a custom CSS Theme option, such an option would be appropriate.</div>
</div></blockquote><div><br></div><div><br></div></div><div>Note: Sanitizing CSS is friggin' hard. A mere strip_tags isn't good enough.</div><div><br></div><div class="gmail_extra">The custom CSS module in Jetpack uses csstidy and a few pre-processors, among other things. But the basic sanitization function would look like this:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">function dumb_css_sanitize( $css ) {</div><div class="gmail_extra"><span style="white-space:pre-wrap"> </span>$css = str_replace( '<=', '<=', $css );</div>
<div class="gmail_extra"><span style="white-space:pre-wrap"> </span>$css = wp_kses_split( $css, array(), array() );</div><div class="gmail_extra"><span style="white-space:pre-wrap"> </span>$css = str_replace( '>', '>', $css );</div>
<div class="gmail_extra"><span style="white-space:pre-wrap"> </span>$css = strip_tags( $css );</div><div class="gmail_extra"><span style="white-space:pre-wrap"> </span>return $css;</div><div class="gmail_extra">}</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I named it dumb_css_sanitize because it's kinda dumb. ;)</div><div class="gmail_extra"><br></div><div class="gmail_extra">It allows <= patterns through as LT entities, runs kses over the thing to strip tags, converts the > symbols back from what kses did, and then runs strip_tags over it again, just in case. It's fairly safe in that you couldn't close the style tag with content run through it and therefore get your content parsed as html or script code. Probably.</div>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">This is sort of a minimalistic case. Better to use a real parser if you're going to do that sort of thing.</div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra">
<br clear="all">
<div>-Otto</div><br></div><div class="gmail_extra"><br></div><div> </div></font></span></div></div></div>
<br>_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
<br></blockquote></div><br></div>