Issues with css optimization on WebKit browsers

  • Hello and thank you for Autoptimize,

    I’m having some trouble and I’m hoping you can be of assistance.

    You can reproduce the issue by installing the BuddyPress and bbPress plugins and then opening the BuddyPress registration page (“/register/” by default) in a WebKit browser like Safari (or Midori if you’re on Linux or Windows).

    Without the bbPress plugin, the page looks fine and when you submit the empty registration form (registrations must be allowed in WordPress options for the form to show), error messages will appear in bright red boxes. With the bbPress plugin activated, when you submit the empty form, the red boxes will be missing. There are some other visual changes as well, but this one is the most noticeable.

    Now, I know I can exclude bbpress.css from optimization, which fixes these display issues, but since this isn’t the only issue I’m having with WebKit and Autoptimize, I’m suspecting this may be symptomatic of a more general problem. This was the first instance I managed to isolate enough for you to easily reproduce.

    I have noticed that both bbPress and BuddyPress enqueue their css for media type screen and I found your post on fixing css media types impacting autoptimized css order. I used the autoptimize_filter_css_tagmedia filter, mentioned in that post, to set the media type of bbpress.css to “all”, just to test whether that might help. It didn’t. Instead it messed up the layout of the whole page for some reason (tested with vanilla TwentySeventeen and a custom child theme of TentyFifteen). But again, only for WebKit. It looks just fine in Firefox.

    It would seem that WebKit css processing differs in some important way from other engines. Since WebKit, especially as Safari (and Safari Mobile), make for a significant percentage of web browsers, it might be worth looking into this.

    BTW, the issue was also present in the upcoming Autoptimize 2.2 when I last tested it.

    Thanks in advance.

Viewing 8 replies - 1 through 8 (of 8 total)
  • Thread Starter Markus Echterhoff

    (@mechter)

    I found a bug in the css minify library used by AO to be responsible for this. A bug report has been filed and the issue should be resolved eventually.

    I’ve been emailing with Frank, and with the help of some friendly people with Apple devices, we have discovered that Safari 5 and 9.1 are affected, but that Safari 10 appears to successfully compensate for the malformed css.

    I’m marking this issue as resolved. Thanks again.

    Plugin Author Frank Goossens

    (@futtta)

    for those who’d like to know details, the problem is that -webkit-text-size-adjust: none; is optimized to -webkit-text-size-adjust:none; which seems to break in Safari < 10.

    Now whether this is a bug in minifier(s) or in Safari is a discussion I won’t get into just yet (I’ll leave that to Tubal & MrClay ?? ), but here’s a small filter-based workaround Markus (not tested, but pretty straightforward anyway;

    add_filter('autoptimize_css_after_minify','fixWebkitTextSizeAdjust');
function fixWebkitTextSizeAdjust($cssin) {
    return str_replace('-webkit-text-size-adjust:none;','-webkit-text-size-adjust: none;',$cssin);
}
    Thread Starter Markus Echterhoff

    (@mechter)

    Since a colon separates two css entities, I’d say it’s a WebKit bug. The question is whether the minifiers should add a workaround or just wait for the old WebKit versions to die out.

    We’ll see. Thanks for the nifty filter!

    Thread Starter Markus Echterhoff

    (@mechter)

    A quick heads-up for anyone encountering this issue. During minification, the semi-colon is stripped for the last declaration of a block, so you can’t rely on its presence (in the case of bbPress, it’s the only declaration of that block).

    This filter works (don’t forget to delete your Autoptimize cache):

    add_filter( 'autoptimize_css_after_minify', 'fixWebkitTextSizeAdjust' );
function fixWebkitTextSizeAdjust( $cssin ) {
    return str_replace( '-webkit-text-size-adjust:none', '-webkit-text-size-adjust: none', $cssin );
}
    Plugin Author Frank Goossens

    (@futtta)

    good catch ??

    Thread Starter Markus Echterhoff

    (@mechter)

    I’ve done a little more digging.

    The problematic space character does not seem to be required by css, so contrary to my initial assessment, this does not appear to be a bug with the minification library, but rather, in line with my second conclusion, a WebKit bug, that may be useful for css minifiers to account for (I’ve filed bug reports for three php minifiers, maybe they’ll add a workaround).

    So I’ve taken a closer look at WebKit. I couldn’t find anything on the WebKit bug tracker, but I was able to compile WebKitGTK+ 2.4.10 (the version my affected Midori 0.5.11 is using), and confirm the bug with the included “mini browser”. However, the mini browser of the most recent WebKitGTK+ version (2.16.1) segfaults, and a random intermediate version didn’t compile at all. Since compiling WebKitGTK+ takes a rather long time, and the bug has apparently been fixed in the WebKit version used by Safari 10, and I’ve got a functioning workaround for older WebKit browsers, I think I’m done with this one. ??

    Plugin Author Frank Goossens

    (@futtta)

    that sure is an impressive amount of bug-hunting for one little missing space @mechter, congrats! ??

    What Frank said. Quite impressive you dug that deep to discover this bug in WebKit.

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘Issues with css optimization on WebKit browsers’ is closed to new replies.