Lazy-loading CSS fails in IE

Wow, nice work on the diagnosis. Subscribing.

This could cause problems in drupal, when a module has multi step forms, each step is loaded via ajax and one of those steps uses a javascript functions with dependencies on css files(for example the jquery ui widgets). But I'm sure there are other issues...

I'd say it's generally troublesome if the ajax system needs to add-in additional CSS via ajax_render(). We ran into this issue with the Rules UI as it caused the data-selection autocomplete to fail in IE.

Subscribing

subscribing

Subscribing

@fago how did you fix this? I am sure there are other modules that fix this now too?

This also affects IE9

Looking at this issue, I think an approach to take would be to create a new 'add_styles' ajax command. Which runs either appends the style or runs .addImport("test.css"); on any import declarations if that function exists.

We can then replace the $extra_commands[] = ajax_command_prepend('head', $styles); with that command.

If someone agrees with this general approach I'll see if I can get something working.

I have attached a module which serves as a test harness for this issue.

Patch added. It creates a new add_css command which will add css to the head and then use addImport on any import statements in the css that was added if the function exists.

I've tested using the test case I added on ie6-9 and it seems to work but further testing would be appreciated.

Thanks for the patch! Here are a couple really minor notes on code style:

+++ b/includes/ajax.incundefined
@@ -1204,3 +1204,24 @@ function ajax_command_restripe($selector) {
+* This method will add css via ajax in a cross browser compatible way.

Minor point, but we probably want "cross-browser" hyphenated.

+++ b/includes/ajax.incundefined
@@ -1204,3 +1204,24 @@ function ajax_command_restripe($selector) {
+* This command is implemented by Drupal.ajax.prototype.commands.add_css()
+* defined in misc/ajax.js.

Can we add an @see to ajax.js at the end of the docblock?

+++ b/includes/ajax.incundefined
@@ -1204,3 +1204,24 @@ function ajax_command_restripe($selector) {
+*

There's an extra blank line here (which we'll want to keep if we add that @see after it.)

+++ b/misc/ajax.jsundefined
@@ -616,7 +616,25 @@ Drupal.ajax.prototype.commands = {
+  ¶

Trailing whitespace.

Also, note that the Drupal 8.x patch will need to be rerolled, because the core directory structure for Drupal 8 has now changed. (For more information, see #22336: Move all core Drupal files under a /core folder to improve usability and upgrades). When the patch has been rerolled, please set the issue back to "Needs Review."

Tagging as novice for the task of rerolling the Drupal 8.x patch with the cleanup described above.

If you need help rerolling this patch, you can come to core office hours or ask in #drupal-gitsupport on IRC.

assigning this to me for a reroll

Rerolled with the suggestions from #13 and some additional path changes in code comment blocks.

Thanks @reglogge!

Nice catch on the path corrections. However, since those don't specifically target this bug, we should open a separate (documentation) issue for them and roll a separate patch. See: http://webchick.net/please-stop-eating-baby-kittens

+++ b/core/misc/ajax.js
@@ -616,6 +616,23 @@ Drupal.ajax.prototype.commands = {
+   * Use the proprietary addImport method if available as browsers which
+   * support that method ignore @import statements in dynamically added
+   * stylesheets.

This wraps early, i.e. before 80 chars.

28 days to next Drupal core point release.

New patch with a fix for #17 and removing the path corrections.

bot...

+++ b/core/includes/ajax.incundefined
@@ -1204,3 +1204,25 @@ function ajax_command_restripe($selector) {
+/**
+* Creates a Drupal Ajax 'add_css' command.
+*
+* This method will add css via ajax in a cross-browser compatible way.
+*
+* This command is implemented by Drupal.ajax.prototype.commands.add_css()
+* defined in misc/ajax.js.
+*
+* @param $styles
+*   A string that contains the styles to be added.
+*
+* @return
+*   An array suitable for use with the ajax_render() function.
+*
+* @see misc/ajax.js
+*/

Mmm, it looks to me like the indentation is off here. There should be a space before the stars. Did I just not notice it before? Sorry. :(

Also, did you open that followup by any chance with your other fixes? You can link it here for reference.

27 days to next Drupal core point release.

Not quite sure how or why I assigned this to myself.

Fixed formatting as mentioned in #20.

Adding correctly named file.

I tested a workaround for Drupal 7 while I was working with CTools and vertical tabs that relied on the same conditional code (see hack below).

I am slightly concerned about the use of regex, but I don't think there is a better alternative since the input is being fed by drupal_get_css(). Is it possible to overload addImport() with bogus data? Otherwise this looks good to me.

  drupal_add_library('system', 'drupal.vertical-tabs');
  drupal_add_js('
    if (document.styleSheets[0].addImport) {
      document.styleSheets[0].addImport(' . DRUPAL_ROOT . '/misc/vertical_tabs.css);
    }  
  ', 'inline');

Tagging,

#23 looks pretty good, don't have IE to test though. Maybe sepgil can confirm ?

Tagging for manual testing.

Ahem.

#23: lazy-loading-css-ie-1071818-22.patch queued for re-testing.

Rerolled for Drupal 8.x.

Thanks anthbel!

+++ b/core/misc/ajax.jsundefined
@@ -616,6 +616,22 @@ Drupal.ajax.prototype.commands = {
       .removeClass('odd even')
       .filter(':even').addClass('odd').end()
       .filter(':odd').addClass('even');
+	 },

Looks like there's a small indentation issue here. We'll want to fix that, then assuming the patch passes testbot, we can try to test it manually again.

Corrected the indentation.

Fixing the whitespace in a docblock. (Not changing the wording on account of #1337022: [policy, no patch] Create/adopt JavaScript docs standards compatible with a JS documentation parser.)

Now let's get some manual testing in all versions of IE, and also confirm that there are no regressions in other browsers. If someone could post explicit steps to reproduce the bug, that would help. Thanks!

Thanks for the re roll.

XJM there is a minimal module in #11 which demonstrates the bug. It should be self explanatory.

+++ b/core/misc/ajax.jsundefined
@@ -616,6 +616,24 @@ Drupal.ajax.prototype.commands = {
       .filter(':even').addClass('odd').end()
       .filter(':odd').addClass('even');
+  },
+  /**
+   * Command to add css.

Looks like an empty line is missing there.

Silly JavaScript.

I attempted a manual test using the module in #11.

1. Fresh install of 8.x-dev
2. Install and enable the module in #11
3. Navigate to /test1071818
4. Click "Test Issue" link

I then got sent to a page full of JSON at /test1071818/test:

[{"command":"settings","settings":{"basePath":"\/","pathPrefix":"","ajaxPageState":{"theme":"bartik","theme_token":"hL6gVpPUzHmLE_zf1mCgC6h6RKtu545LqQ-JmW3Refo"},"overlay":{"paths":{"admin":"node\/*\/edit\nnode\/*\/delete\nnode\/*\/revisions\nnode\/*\/revisions\/*\/revert\nnode\/*\/revisions\/*\/delete\nnode\/add\nnode\/add\/*\noverlay\/dismiss-message\nuser\/*\/shortcuts\nadmin\nadmin\/*\nbatch\ntaxonomy\/term\/*\/edit\ntaxonomy\/term\/*\/delete\nuser\/*\/cancel\nuser\/*\/edit\nuser\/*\/edit\/*","non_admin":"admin\/structure\/block\/demo\/*\nadmin\/reports\/status\/php"},"ajaxCallback":"overlay-ajax"}},"merge":true},{"command":"insert","method":"append","selector":".region-content .content","data":"\u003Cdiv class=\u0022issue_pass\u0022\u003E\u003Ch3\u003EPass\u003C\/h3\u003EThis should be shown if the issue is fixed in this setup.\u003C\/div\u003E\n \u003Cdiv class=\u0022issue_fail\u0022\u003E\u003Ch3\u003EFail\u003C\/h3\u003EThis will be shown if the issue is not fixed in this setup.\u003C\/div\u003E","settings":null}]

Testing the module in IE6-8, the browser tried to download the JSON-containing file instead of showing it in the browser. Applying the patch in #36 didn't make a difference in any browser I tested in.

My impression from looking at the test module code is that the pass/fail is supposed to be displayed in-browser. I attempted clearing my cache as well with no change.

Perhaps we can clarify how the test module is supposed to work and any other necessary configuration that may be required.

Rerolled the module in #11, because of the change in Drupal 8 core directory structure.

Applied #36 and tested with #38 on IE7 and IE8. Results attached.
Have not found an impact on chrome and FF.

Tested for in safari and opera, both passed. I daresay RTBC.

Let's give nod_ a chance to sign off on this before it goes in, assigning to the new JavaScript maintainer!

Actually I've been stalking this one for a while :D

There is a leaking var in there. Otherwise this looks good, I'm doing a few more tests and I'll send a patch later.

Ok so there are several issues here.

• a couple of leaking vars.
• @import is only used for unaggregated CSS, which is the uncommon use case (production last way longer than development) so it is only useful if response.data has @import somewhere.
• regex way too complicated. there is no need to check for weird import statement, we generate the markup, if it's somehow overriden, the add_css command will need to be overriden anyway. With a minor addition to the markup (two \n) we can use the multi-line mode of regxp, speeding this thig way up: http://jsperf.com/drupal-import-regxp benchmark needs ie testing but i'm confident it'll be the same.

Here is an updated patch, I don't have IE but that should work fine :)

+++ b/core/misc/ajax.js
@@ -616,6 +616,25 @@ Drupal.ajax.prototype.commands = {
+  /**
+   * Command to add css.
+   *
+   * Uses the proprietary addImport method if available as browsers which
+   * support that method ignore @import statements in dynamically added
+   * stylesheets.
+   */
+  add_css: function (ajax, response, status) {
+    // Add the styles in the normal way.
+    $('head').prepend(response.data);
+    // Add imports in the styles using the addImport method if available.

1) Had to read the description twice to parse it, and after parsing, I think (or hope) I get what it tries to tell, but the actual text is not proper English.

2) I do not understand why the styles are added both in the normal way and with the proprietary method. The JSDoc description should also clarify and explain why that is done.

3) The inline comments within the function body could use some better wording, too.

Lastly, "CSS" in comments should always be all-uppercase.

+++ b/core/misc/ajax.js
@@ -616,6 +616,25 @@ Drupal.ajax.prototype.commands = {
+    if (/@import/.test(response.data) && document.styleSheets[0].addImport) {
+      var match, importMatch = /^@import url\("(.*)"\);$/igm;
+      while (match = importMatch.exec(response.data)) {
+        document.styleSheets[0].addImport(match[1]);

1) It looks like the check for document.styleSheets[0].addImport is the primary and much faster condition, so it should come first.

2) It looks like we're performing two different regex matches on the response.data, whereas the initial is less specific, but the actual one is not very complex either, so we should just perform the actual/second one.

3) I'm concerned about any possible false-positives of this manual parsing. Did anyone investigate this? If so, the results of that could deserve an inline comment.

4) Has this been tested with inline CSS returned by the server?

@nod

@import is only used for unaggregated CSS, which is the uncommon use case (production last way longer than development) so it is only useful if response.data has @import somewhere.

Is this the case when drupal_add_css us used in an ajax command?

@sun
does this read better?

This command is used to add css in ajax commands. In most cases this is simply adding the CSS to the head. But some browsers ignore @import statements when this is done. In these cases this function will detect the existence of a proprietary addImport method to add the import style sheets.

Here is for the code:

1. that's true, changed
2. also true, I supposed the multiline wouldn't work but boy I was wrong.
3. it's unlikely, do you have something in mind? this regex is treating each line as a different string so ^ and $ can be used to check for start and end of pattern.
4. Inline CSS? like actual rules, not just import statements? it's only @import that IE needs help with he can deal with inline css just fine otherwise.

Haven't touched at comments

Patch looks good to me. Needs more eyes though.

I think Firefox 10 may be throwing a JS error on this now where it wasn't before in previous versions (I think, I can't test anymore). Or maybe it's Firebug?

Couldn't reproduce the firefox10 bug. But doing a quick test in IE showed it was no longer working.

The regex was being used for a test and not being reset for the loop. This should now be fixed in this patch.

Ooops. Attaching correctly named file.

Sorry for spam. This should work.

The patch in 52 passed testing in FF and Webkit browsers.

The patch in #52 works for Chrome v19 and IE 8

learing stuff on regxp is always fun :)

so using string.search(regexp) will give the same result as regexp.test(string), but without messing with the search index and it's faster too :) http://jsperf.com/drupal-import-regxp/3

needed a reroll after the doc change too.

Sorry, but what I meant was this.

And I don't really care for performance of IE, as long as it requires dirty workarounds like this.

That said, this needs to be tested against IE10, as Microsoft announced that they removed/resolved the stylesheets limitations, so the regular/standard way should work in IE10, too -- however, the addImport method might still exist, as Microsoft tends to keep quirks around, and so in turn, we need to make sure that stylesheets don't get imported twice.

You can't use regexp like that in JS. To have access to the substring you have to use .exec(), .match() gives you the whole thing.

Your patch doesn't work for me.

Ok here are some testing results for IE9:

First install
1) Downloaded & installed latest D8 --dev
2) Downloaded & installed #38 test-rig
3) Cleared cache on server and browser
4) Loaded /test1071818
5) Clicked on 'Test' and got ' Fail This will be shown if the issue is not fixed in this setup.'
6) Downloaded & patched http://drupal.org/files/core-js-IE-addimport-1071818-55.patch
7) Cleared cache on server and browser
8) Loaded /test1071818
5) Clicked on 'Test' and got 'Pass This should be shown if the issue is fixed in this setup.'

Second install
1) Downloaded & installed latest D8 --dev
2) Downloaded & installed #38 test-rig
3) Cleared cache on server and browser
4) Loaded /test1071818
5) Clicked on 'Test' and got ' Fail This will be shown if the issue is not fixed in this setup.'
6) Downloaded & patched http://drupal.org/files/drupal8.ajax-css-ie.56.patch
7) Cleared cache on server and browser
8) Loaded /test1071818
5) Clicked on 'Test' and got 'Fail This will be shown if the issue is not fixed in this setup.'

So for IE9 at the moment it appears that:
- core-js-IE-addimport-1071818-55.patch works
- drupal8.ajax-css-ie.56.patch does not work

Cheers

The patch in 56 fails in IE8

Thanks Dig1 and NROTC_Webmaster!

Can we settle on #55 so we can finish manually testing this on all browsers and versions of IE, and get this bugfix in?

Tested patch in #55 on IE10 and IE10PP4, I get pass in both platforms.

Issue still occurs without patch, so they haven't fixed this particular issue even in IE10.

Personally I think the #55 patch should be RBTC, but I have had to much of a hand it it to change status myself.

Cross referencing with #1461322: Fix AJAX add_css – insert the needed CSS assets after the already-inserted ones

The patch in #55 still prepends scripts to the head.
If we are replacing ajax_command_prepend with a new command (ajax_command_add_css), we may as well 'get it right' in that new command?

Changes like that should probably be done in followup issues, I think, but as it's JS I don't know the full implications. It merits its own, separate discussion (probably in the linked issue). This issue is specifically about resolving the bug, whereas the other issue needs discussion and consensus before we'd go forward with it. Thanks!

I agree that the discussion about that subject should take place in the ticket for it.

However, the code that is causing that issue in the first place will be completely removed by the patch in #55 and replaced with new code that still implements the weird behaviour.

If we are replacing the code anyway, why not try to squash two issues in one patch?
The only change to the patch in #55 would be appending the lazy loaded styles to the head instead of prepending them.

The alternative would be:

• Commit this patch
• Update other issue referring to the new code and that the bug still lives in it
• Wait for a while until that issue is RTBC
• Only then fix the other issue (perhaps a few months from now)

May as well benefit from the current momentum?

Thanks @kristiaanvandeneynde. My perspective is that this is a major bug that has a complete, existing solution. The other is not. In general, I don't think it's wise to postpone major bugs on non-major tasks.

If the JavaScript needs to be changed, I don't know enough to evaluate the proposed changes, but much of the "current momentum" as you call it is from people working on this issue during core office hours, which I facilitate. However, I am not going to keep spending people's time re-testing it over cleanups that don't change the functionality.

Untagging. Retag when this patch is ready for testing that needs to precede an RTBC.

@kristiaanvandeneynde
Unfortunately this patch is very near consensus and being RBTC, compounding two issues will potentially take much longer to work on and decide if it is even needed. Trying to include it in here is more likely to kill the momentum rather than getting two issues resolved.

I can understand that it looks strange but it means that both issues get proper discussion in isolation.

Just out of interest have you tried patch #55 you may find that it resolves the issue you have. Prepending or Appending in IE will still fail without this patch.

I think append vs. prepend warrants a separate discussion, and therefore, issue, and not be combined here. One problem with append is that it would mean module CSS potentially overriding theme CSS. Maybe it's better than the current prepend, but to me, it's not yet obvious that it is, and if it is, that it can be backported to D7, so let's hash that out there without derailing this bugfix.

Remove tag that was added in error.

(is this a novice issue?)

Fixing crosspost. @nod_, please let me know when this issue is ready for testing again! Thanks.

Novice was also for the manual testing. :)

#55 is good for review and «works for me»™ on IE7–9, unless sun has something to say about it.

+++ b/core/includes/common.inc
@@ -3347,7 +3347,7 @@ function drupal_pre_render_styles($elements) {
-            $element['#value'] = implode("\n", $import_batch);
+            $element['#value'] = "\n" . implode("\n", $import_batch) . "\n";

If this is necessary for the JavaScript to work, then we need to add a test to ensure someone doesn't come along and try to remove those seemingly unnecessary newlines. A code comment also wouldn't hurt.

Otherwise, I'm +1 for this, but am not qualified to RTBC it.

Tagging per #72.

The point of line breaks are to make the javascript regex very simple. I'm not particularly good at writing doc and comments, i'll let that to someone else :)

before the code returned by the add_css command was like that:

<style>@import url("url/file1.css");
@import url("url/file2.css");
@import url("url/file3.css");
@import url("url/file4.css");</style>

To dramatically simplify the regex the string returned needs to be like that:

<style>
@import url("url/file1.css");
@import url("url/file2.css");
@import url("url/file3.css");
@import url("url/file4.css");
</style>

now we can use the multi-line flag of javascript regex, treating each line (separated by \n) as a completely different string. That means we can use ^ and $ on one line at a time. We don't have to worry about style tags since they'll never match the regex.

Updated #55 with comments based on #74.

That comment looks good. Thanks @NROTC_Webmaster.

So now we just need an automated test that confirms that the $element['#value'] begins and ends with a linebreak.

Let's see what bot says

Cool, CSS newline test passes. The new ajax_command_add_css fails though.

Is this bug present on Drupal 7? I'm having the same troubles with css injection on IE 7-9. If so, will the patch backported to D7 core?

Thanks!

You should really turn css aggregation on Maxtorete, it's good for your site and should get rid of this issue.

@nod_ I don't think aggregation will always get rid of this issue.

@maxtorete yes this is an issue in D7. And the patch should be backported.

it will unless you're adding @import in some custom inline CSS. and even then it might be picked up anyway.

help on the test is welcome btw :)

Since there were so many changes surrounding psr-0 this had to be rerolled. Doesn't fix the problem yet but at least the patch can be applied cleanly again.

#84: core-js-IE-addimport-1071818-84.patch queued for re-testing.

Don't have time to deal with it.

Bug is fixed by the patch, the new tests needs some fixing.

I'm going to take a look at the tests.

I did some manual testing using the test module in #38 . The JavaScript change introduced back in #55 breaks the test module (failure message is displayed) in IE 6-8, IE 9 still tests fine. The patch I'm attaching here is still broken in IE 6-8.

I tested with these steps:

1. Did a checkout of 8.x at commit 3c78ca4.
2. Installed and enabled the module from #38 .
3. Applied the patch in #52 .
4. Cleared cache.
5. Ran through tests (click "Test Issue" link on /test1071818) in IE 6-9, all passed.
6. Removed the changes from #52 .
7. Applied the patch in #55 .
8. Cleared cache.
9. Ran through tests (click "Test Issue" link on /test1071818) in IE 6-9, only IE 9 passed.

The patch here adds to ajax_forms_test.module to allow the new add_css command to be tested, and corrects the expected return in the add_css test.

Also removed an extra newline introduced in #84 .

Edit: linkified comment numbers.

#91: 1071818-91.patch queued for re-testing.

Just searched and found #1655422: Random test failures in SearchCommentTest, so I'm thinking the failure was unrelated.

Much better. Now we need to fix this in IE 6-8.

I thought Drupal 8 is dropping support for IE 6?

Yes, for D8, we only need this to work on IE8. For a D7 backport though, it needs to work on IE6 and 7.

Right, thanks for clarifying that @effulgentsia!

Took the JS code from #52, please retest. If it works rtbc it please :)

Thanks @nod_! I just did manual testing in IE 6-9, they all passed now. I think I'm a bit too close to the issue to RTBC though.

Removing the "Needs tests" tag.

nah it's fine, it's an edge case anyway. Thanks for giving this the last push it needed :)

RTBC since #99 successfully tested the patch and it's green.

I confess I don't know fully what's happening here, but it seems like a decent bug fix and comes with tests and has buy-in from the right people.

Committed and pushed to 8.x.

This will need a backport to D7.

Backported to D7. I had to change the test assertion for the newlines within <style> tags in CascadingStylesheetsTestCase::testRenderFile() (see #74). This assertion needed to be revised because in D7 <style> tags have a type="text/css" attribute added by default.

Re-tested in IE 6-9 with the test module in #11, all passed.

#103: 1071818-103-tests.patch queued for re-testing.

I just tested this in IE9. I tried it both via adding commands directly to the ajax commands array, and calling drupal_add_css and letting ajax_render() add the command. In both cases the add_css ajax method was called, and even passed through to the line document.styleSheets[0].addImport(match[1]); with the correct CSS file, but the file was either never actually loaded, or did not properly apply.

Can we get another confirmation for the result in #105? I used the test module in #38, and the patch in #103 passed in IE 6-9.

Patch still applies cleanly to 7.x.

I meant the test module from #11 (before the /core change).

#103 works for me (IE 8)

It works fine in IE8 until you turn CSS aggregation on.

works for me on IE 7 and 8

#103: 1071818-103.patch queued for re-testing.

Rebased (and updated) for 7.x-dev.

Thanks @gielfeldt. This needs another reroll.

I am uploading the test module from #38 as a patch for easier testing (it can also be tested via simplytest.me).

Ahem, here is the actual patch for the test module :)

I will look at that.

Patch in #113 is fine. Does not need rerolling.

Uppdated test code in #114 for 7.x.

The test fails for current 7.x for IE 8. The test pass for IE10.

After applying patch in #113 the code works also for IE8.

New patch for latest dev

The patch in #119 applies successfully and completely breaks ajax.js :

  add_css: function (ajax, response, status) {
    // ...
  }

  /**
   * Command to update a form's build ID.
   */
  updateBuildId: function(ajax, response, status) {

At the end of the add_css function, there should be a "," or the JS object is broken and can't be parsed. I wish there was a test that can catch this problem.

The patch in #119 applies successfully and completely breaks ajax.js

I've attached a patch addressing this for now. But we should add some tests.

At the end of the add_css function, there should be a "," or the JS object is broken and can't be parsed. I wish there was a test that can catch this problem.

I agree. However, I had problems with jslint and gave up ...

I can say that the patch #121 works for me, for some pretty complex Drupal installations, but I don't know how the patch works, and I haven't actually reviewed it, so I won't mark it RTBC.

#121 is a good port from D8 from my review of it.

@MiroslavBanov can testify that it is working for his Drupal installations.

I'm not certain what is the best way to test this though. We don't do a lot of work with Windows & haven't experienced this Lazy Loading issue that I'm aware of.

This was committed to D8 2 years ago. This should be easy to mark RTBC. I'd just like to have a clear sense of what I'm testing.

Its easy enough to reproduce:

1. Install:
   • link 1.2
   • linkit 3.1
2. Create a linkit profile with settings:
   • Profile type: Fields
   • Search plugins: Node
   • Insert plugin: Raw URL
   • Insert paths as: Raw paths
3. Create a Link field, with this linkit profile enabled for it.
4. Generate some content.
5. Use the linkit autocomplete in IE8 and despair.

See linkit profile autocomplete with and withot patch #121:

I'm going ahead and marking this RTBC, before the reason for this patch is completely dead.

Re-setting RTBC status.

What is the deal with all this status change? The patch is green, but the there are messages that it "fails testing". Is this because of some problem with the testbot?

Yes, it is. See #2246867: Intermittent "test did not complete due to a fatal error" failures when testing Drupal 7 patches.

like #125 I hope that this patch gets committed before it becomes obsolete.

#121 green

please commit soon, the testbot is constantly reverting this to "needs work". See #140.

Committed to 7.x - thanks!

Fixed the following on commit:

--- a/modules/simpletest/tests/common.test
+++ b/modules/simpletest/tests/common.test
@@ -664,7 +664,7 @@ class CascadingStylesheetsTestCase extends DrupalWebTestCase {
     // Verify that newlines are properly added inside style tags.
     $query_string = variable_get('css_js_query_string', '0');
     $css_processed = "<style type=\"text/css\" media=\"all\">\n@import url(\"" . check_plain(file_create_url($css)) . "?" . $query_string ."\");\n</style>";
-    $this->assertEqual(trim($styles), $css_processed, t('Rendered CSS includes newlines inside style tags for JavaScript use.'));
+    $this->assertEqual(trim($styles), $css_processed, 'Rendered CSS includes newlines inside style tags for JavaScript use.');
   }