Spaces and Line Breaks are removed from CSS definitions

My issue is a duplicate of this one. Sorry. Subscribing. Here was my writeup:
http://drupal.org/node/475830

I might also add, that it looks like the code your fix is applied to is meant to strip out multiple white spaces, but actually strips out all whitespaces. Maybe the code should be more like:
$variables['css'] = str_replace(' ',' ', str_replace("\n", '', $css));?

I was having the same issue. I have made the modification suggested by gregarios and now the css in my newsletters looks correct and is interpreted correctly by the mail clients I've tried so far.
Thanks for pinpointing the fix mindgame and gregarios.

I'm bumping this to critical, then... since this is a show-stopper bug and a fix is in this post.

Changing to "needs review" since a patch is attached.

Also see #443964: Skip style sheets with print media

me fail sorry about that

Thanks for the hint.

I didn't check the later patch, but the very first solution seams just fine for mime mail's core module. (Because spaces are part of the CSS selector syntax, removing any of them without semantical parsing seems fatal in any case.)

Which solution is the "very first solution" you are referring to? "Multiple spaces" are not part of CSS in any way.

I'm referring to the one in mindgame's original post: Multiple spaces are not, but single spaces are.

I opened a different case, namely: #581142: truncated mail due to css

My original issue was not css space removement, but much more mail truncation.

Please please read my post and understand that removing any newline is NO solution for SMTP due to RFC limitation of 998 bytes line length.

So finally i see no gain in removing a few bytes such as newlines and spaces, except introducing an incredible amount of potential problems. Instead mimemail should implement line length checks and add them manually or do base64 encoding...

Please simply switch this to the full unmodified css content.

+1 for #10

Please simply switch this to the full unmodified css content.

I'm ALL for that! Please, Allie Micka, or one of the other maintainers...

Good point, Miro.

Here's the patch for the latest dev release (2009-Jun-08):

Here's the patch for the latest dev release (2009-Jun-08):

I think having it remove multiple spaces (leaving all as single spaces) is still a good thing. Leave line-endings though. can you update the patch to reflect what I wrote in the space-removal part of #2?

@gregarios. Here you go. I can't test the patch myself for now. Could you please verify that this works? Thanks, Moritz

The patch in #16 doesn't seem to do anything.

In testing, I tried a few mods myself to see if I could get it to work right. The string you are modifying doesn't seem to do anything at all. Even if I change it to be like the patch in #14, there is no change... all the CSS is still compressed.

I believe the fault lies in the mimemail_compress modules. I've tracked down another somewhat related issue to this, where certain CSS containing links gets corrupted as well:

background-image: url(http://domain.com/image.jpg);
turns into:
background-image:url(http;

Somehow, in the mimemail_compress.inc file, there is code that is reading all colons as CSS seperators, and using the colon in a URL incorrectly, causing it to be corrupted.

I believe all the substitutions with whitespace are also done in the mimemail_compress.inc file as well... could you take a look in it? I tried to spot the defects, but could not due to my lack of enough PHP experience.

UPDATE I believe the string list($key,$value) = explode(':',$def); found in the mimemail_compress.inc file may be to blame for all CSS URL corruption.

gregarios:
This issue is NOT about mimemail_compress. It's about wrong behaviour of plain mimemail.module - without mimemail_compress activated.

After having this basic functionality fixed you might think about enabling mimemail_compress (and also look into depth of much other strange things it does ;-) ) .. You don't need mimemail_compress. I strongly recommend you to add an own mail.css file and get rid of other css definitions that way.

@miro_dietiker:
My mistake... the last patch (in #16) does work.

*whew* Thanks for testing @gregarios

*whew* Thanks for testing @gregarios

As a matter of fact I disabled the CSS Compress module at your suggestion and went with a mail.css file. WAY happier with the results. :-) (Now I wish mail.css could be named differently, but oh well.)

Alas, this has not been fixed in the newest version... and the patch in #16 would appear to not work on this version as well.

The patch needs to be rewritten to work on the same BUG CODE which has been moved to the mimemail.theme.inc file now. Disappointing.

Here we go @gregarios. For future reference: http://drupal.org/patch/create ;)

Thanks omo for the patching help. Your patch works great! Now, how can we get this into alpha2? :-)

Patch works as advertised. Let's move this one in.

For a CSS code cleaning, this line it's better :

$variables['css'] = preg_replace('#\s+#s', ' ', preg_replace('#\s*([:;,\(\)])\s*#s', '$1',$css));

- remove all space before and after CSS separator : ":", ";", "(", ")" and ","
- replace multiple spaces and similar (\n, \r, etc.) by one space

Patch with comment #28

Patch for comment #27:

I don't think we should do any complex css cleanups in here.
Just make it work as minimal as possible. Without need to check complex specific replacements to understand if it works now or if it still doesn't in some specific cases.

Specific advanced cleanups should be integrated the way as css Compressor module does.

#24 works here too. nice work guys

Another duplicate of this issue
#436474: Error with some mail server: 500 Line too long

using patch from comment #28 and work great

@#27,#28

Sorry, but replacing line endings with spaces is wrong
as it can lead to emails that are invalid according to the RFC as pointed out by miro_dietiker
in issue #581142: truncated mail due to css .
Lines are not allowed to become longer than 998 octets.

I just experienced this problem (with the original module) in the real world:
* several mail servers rejected the emails saying it contained a NUL character
(I think that is an artifact of the too long line that got truncated somewhere along the way)
* several web frontends displayed only a mutilated version of the email.

Removing any compression attempt from this preprocess function
fixed the issue for me. So I agree with miro_dietiker (#10 and #29 in particular).

First of all, I'm not on my usual drupal working location so i'm unable to generate a patch here.

If you replace

  $variables['css'] = str_replace(' ','', str_replace("\n", '', $css));

With:

  $css = str_replace("\r", ' ', $css); // change newlines to spaces.  
  $css = str_replace("\n", ' ', $css); // change newlines to spaces.  
  $css = str_replace("\t", ' ', $css); // change tabs to spaces.
  $css = str_replace('  ', ' ', $css); // remove duplicate spaces.
  $css = wordwrap($css, 990); // wordwrap to adhere to RFC821
  $variables['css'] = $css;

It should fix all the issues at hand.

and here it is in patch format ;)

I'm rephrasing this post:

This issue was in no way fixed in this new beta, and it seems inexcusable.

@alexanderpas, in answer to the next post:

Your patch is a great fix for this module, however, the number needs to be reduced to around 700 or so, despite the "standard" because indent spaces that are introduced can take up quite a few spaces before the CSS lines begin. No need to push the envelope anyway IMO.

I changed the 990 to 700 in your patch and it worked very well. 990 caused some lines to be truncated by the server, introducing a "!" into the line endings.

See issue http://drupal.org/node/743150 as many of these issues are being addressed in a bootleg patch.

@gregarios: If you were referring to the 6.x-1.0-alpha2, that is "just" a new security release, doesn't contain any fixes or new features. The beta1? in this #743150: Mime Mail 6.x-1.0-beta1? contains patch from #24 and seems to work just fine. Can you address a problem with that one? Or alexanderpas's workaround would be just better?

The patch in #35 does fix the issue of too long lines, but hardly compresses the css file. We can do more to compress the file. Reduce multiple spaces (3, 4, 5, 6) to a single; Remove comments; remove unnecessary spaces. I found some articles which may be helpfull: http://websitetips.com/articles/optimization/css/crunch/ and http://www.lateralcode.com/css-minifier/

The beta1? in this #743150: Mime Mail 6.x-1.0-beta1? contains patch from #24 and seems to work just fine. Can you address a problem with that one? Or alexanderpas's workaround would be just better?

Both patches work satisfactorily. Neither have problems that I can see. I used the patch from #24 for a long time with no problems, and I'm using the one from #35 right now. But, the one in #35 needs the number to be less -- more like 700 instead of 990.

The patch in #35 does fix the issue of too long lines, but hardly compresses the css file.

I find it easier to just save the mail.css file the way I like it, in a readable-compressed format. Its not like it'll have to be a huge CSS file anyway. Compression can be left to the Mime Mail Compress module, right?

@gregarios: I second that, just like miro_dietiker wrote too. In here we should leave the mail.css as it is. If we agree, can we stick with patch from #24 and mark this as RTBC?

@gregarios: I second that, just like miro_dietiker wrote too. In here we should leave the mail.css as it is. If we agree, can we stick with patch from #24 and mark this as RTBC?

Absolutely.

this patch should fix the issue (stated in #40) of multiple spaces (2,3,4,5 or even more) and i've lowered the wordwrap number (to 700 as suggested #36 and #41), also, it is availble in two variants, the first, doing things step by step, and secondly, doing all in one single preg_replace

A quick note about the patch in #24:
It can be slow, as the replacement pattern also replaces each single space with a single space.

@alexanderpas: The step-by-step variant works as advertised, but the second variant with preg_replace() doesn't handle every new lines.

However, if we don't use the CSS as it is, we could do more (remove comment and unnecessary spaces, etc.) according to the articles found by Sutharsan in #40.

I tested the attached patch with a style sheet formatted like disaster and the result was very nice.

In my opinion we're discussing here about two totally different issues.

First of all: MimeMail is broken - crititally. And we have a very simple fix ti make it work in many many situations.
Remember - The system is pluggable so we don't need to compress, optimize, ... We should do minimum work. If possible standards compliant. For this fix - urgently needed - we don't need to delay anything while discussing about academic optimums.

Second:
We're talking about optimized ways and improvements in css handling. Fine. Those things should be tested with maximum amount of examples and checked very well. For example i'm pretty sure, example #46 will not work perfectly in every case.

Example:
.this_is_a_first_class, .this_is_a_second_class, ..... _this_is_class_number_999 { key: value; }
I'm pretty sure this will result in a too long chunk since ", " is getting replaced with ",". So class lists result in unwrappable results. Generally, i don't see any reason to remove single spaces around formatters for regular cases. This is ugly.

Then about wordwrap: it does no enforcement at 700. This might be ok if transport layer will allow more than 700 characters and unwrappable concatenated things without spaces occur - but this is neither standards compliant nor will this be a stable solution.
I know - if we enforce wordwrap to wrap (4. param = TRUE) it will break css in alien cases. But this is mail. Standard compliance regarding transport layer is hightest priority.

We shouldn't do tricky things here. We'll introduce new problems in yet unknown cases. We can't be semantically perfect since we don't have a semantic css parser - so don't even try to so this in mimemail core.

In my opinion: either trivial solution is ok (known to break for very long lines in css) - or removing double spaces might be OK and applying wordwrap too. Let's move everything else into custom extensions.

@miro_dietiker: As I wrote before I agree with you. IMO: lets stick with the patch from #24 and when we finally have this (among other patches) committed in a new release, we can discuss this in another issue.

RE: #48

I second that.

Some explanation about my choice of wordwrap and the space removal method.

As wordwrap only allows breaks on spaces etc., I decided to change, tabs and newlines into spaces, and only remove duplicate spaces, leaving a single space where used to be a spacing area giving wordwrap enough points where to wrap.

So, basically, the only way you could break the wordwrap step, is when there is a 700+ byte long string in your original CSS without spaces, on a single line.

Advanced methods, like those in #46 and the articles from #40 can, and shouldprobaly, be implemented in the CSS compressor module.

the patch in #24 is not good, since it replaces every single space with a single space, in addition to duplicate spaces, which is completely unneeded and causes slowdown.

reuploading the step-by-step variant of #45, as this seems to be the patch giving the best results, without advanced techniques.

the patch in #24 is not good, since it replaces every single space with a single space, in addition to duplicate spaces, which is completely unneeded and causes slowdown.

Where do you get this data? I've never seen a slowdown from code that can replace instances of itself with itself not handle it smartly by skipping such occurrences automatically. No matter what the replace function is, it must scan all the text it is processing anyway... so why would this create a slowdown when it isn't writing any replacements until it spits out the data at once at the end of it's process? IE: It isn't like a loop that traverses over the text for every character one at a time...

The situation about memory and runtime is much worse than one might expect.

Look at this:
I've wrote some scripts. One setup for time/memory measurement and one script for each replace method.
Input is always a 10*1024*1024*' ,' (30M) sized text containing "space-space-comma" 10M times.
So finally 10M replacements are getting into place. The third is only to compare what happens if we use trivial str_replace which doesn't work for 2+ spaces.
A measurement script that gets run (in this case the first) looks like:

<?php
include('../setup.php');
$out = preg_replace('/\s{2,}/', ' ', $txt);
timedelta($out, "preg_replace /\s{2,}/");

Results:

code:preg_replace /\s{2,}/
outlen:20971520: , , , , ,...
time:2.4961180687
mem:94427080
=====
code:preg_replace / +/
outlen:20971520: , , , , ,...
time:1.7709479332
mem:94427112
=====
code:str_replace 2 > 1
outlen:20971520: , , , , ,...
time:0.435588121414
mem:52484064

So the trivial preg match that matches also single spaces is faster in case of all-double-spaces. That's the cost of the more complex preg.
Now if we make 50% double spaces and 50% single spaces (5M times " , ,,"), see this:

code:preg_replace /\s{2,}/
outlen:26214400: , ,, , ,,...
time:2.42563295364
mem:94427120
=====
code:preg_replace / +/
outlen:26214400: , ,, , ,,...
time:1.82595396042
mem:94427216

Oops... So again... What will happen if we have single spaces only (10M " ,,")?

code:preg_replace /\s{2,}/
outlen:31457280: ,, ,, ,, ...
time:1.71842002869
mem:94427080
=====
code:preg_replace / +/
outlen:31457280: ,, ,, ,, ...
time:1.77724599838
mem:94427112

Oops again. It gets almost the same speed - even if #1 has no more matches! So the regexp interpretation complexity is by far higher than the replacement overhead - if however something like that is measurable.

Interprete it on your own...

I was about to do some benchmarking on this to see clearly. If it comes to speed, I can confirm, the single preg_replace() with / +/i is faster than /\s{2,}/. One preg_replace() would be also faster, instead of the three (or more) str_replace().

Patch in #24 is a working and acceptable solution IMO.

Ok, so in the case of normal emails going out, considering each email is going to have maybe 1/100th of those spaces, each email would save around .001 seconds? lol

I think, we discussed this issue and agreed to stick with #24. Complex workarounds should be discussed in a new issue, after we have a new stable release.

Ok, I'm having issues with the reformatted CSS now in the emails. SOME email clients do NOT like that the CSS does not have a line break after each CSS entry. Removing the stock line breaks then adding line breaks at designated intervals is definitely NOT the way to go. The module needs to leave the CSS alone, so a person's mail.css file remains intact. Place a line-break after each semicolon in the CSS if you must have line breaks.

We need to go back to the way it was done in the patch from comment #24.

SOME email clients do NOT like that the CSS does not have a line break after each CSS entry.

I am using this for a while and the line breaks are intact in the CSS. Can you give us particular details how to reproduce? I would dig deeper into this.

gregarios,
you've simply confirmed that the patch #24 we've considered RTBC was right.
There's no objection and even no need to reactivate the topic.

So, once again:
Back to #24, back to unchanged newlines, back to RTBC.

however, gregarios, can you please provide more details and exact examples about which clients don't accept multiple css statements on one single line? What we really should start is a data collection with information about mail clients and compatibility information. Sending quality mime mails is heavily related to best practice and incompatibility workarounds. Understanding the standards and strictly implementing them is by far not enough to be mass compatible...

I wish I could give examples, but ever since the change I've gotten emails back from some people stating that their emails look wrong, borderline unreadable now since the change, and the only changes I see in the source are the CSS text. About 1 in 500 people complain that they can no longer read the emails because the text is black on black background, which can only happen because of my CSS changes.

Yes... I see... back to #24 for sure fixes it.

Talked with sgabe about this a bit and I'd like to see us keep some basic optimization of css. The patch in #24 is simple enough, but parts of #46 seem like a more correct approach. This is a proposed compromise between the two.

This still performs some css optimization, based on the example provided by Drupal core's css aggregation functions:
http://api.drupal.org/api/function/drupal_load_stylesheet/6

It then also calls the wordwrap function in case there are still long lines from a default css file.

I'd like to commit this ASAP, so I'd appreciate any assistance with testing you can provide! This patch is rolled against HEAD.

#60 is confirmed to be working as advertised. Descendant selectors, child selectors and properties with multiple values are intact. Long lines wrapped at the given width. I can't see any problem.

#60 is confirmed to be working as advertised. Descendant selectors, child selectors and properties with multiple values are intact. Long lines wrapped at the given width. I can't see any problem.

I am confirming that some email clients, like some older versions of Outlook (there are about 10) do NOT like having missing line breaks before each CSS selector.

(As an example — width of code shortened for emphasis)
Some clients do not like:

body { background-color: #fff; } div.aclass { border: 1px solid #ccc; } .bclass { font: 12px
verdana,geneva,sans-serif; } #mainid {width: 500px; border: 2px solid #333; } div.xclass
{ border: 1px solid #444; }

While the same clients will show the CSS correctly if this is how the same CSS looks:

body { background-color: #fff; }
div.aclass { border: 1px solid #ccc; }
.bclass { font: 12px verdana,geneva,sans-serif; }
#mainid {width: 500px; border: 2px solid #333; }
div.xclass { border: 1px solid #444; }

I say leave all line-breaks in. Break it further if you want the "RFC821" compliance, but please don't remove line breaks that are put into the "mail.css" manually.

Attaching a new variant of #60 reffering to gregarios's request with 2 modifications:

1. Ignore new lines and any non-whitespace character.
2. Replace duplicate whitespace and new lines left behind by comments.

Committed to HEAD, thanks sgabe, gregarios and everyone else!

The patch in #63 removes all linebreaks other than the 700-character limit ones.

Here is the actual CSS from my email:

<style type="text/css">
      <!--
      html{height:100%;width:100%;margin:0px;padding:0px;text-align:center;background:#000000 url(http://images.kpbj.com/kpbj_background_email.jpg) no-repeat fixed top center;color:#ffffff;}body#mimemail-body{height:100%;width:100%;margin:0px;padding:12px 0px;text-align:center;}div#center{display:block;height:100%;width:100%;margin:0px;padding:0px;text-align:center;}div#main{display:block;width:634px;text-align:left;padding:0px;margin:0px auto 0px auto;color:#ffffff;}div.bodydiv{color:#000000;}a.mailhead{display:block;font:bold 13px/16px verdana,geneva,sans-serif;color:#000000 !important;text-decoration:none;padding:0px 0px 2px 0px;}div.mailsubhead{display:block;font:italic lighter 10px/12px
verdana,geneva,sans-serif;color:#617279 !important;padding:0px 0px 2px 0px;}div.mailbyline{display:block;font:italic lighter 9px/10px verdana,geneva,sans-serif;color:#999999 !important;text-transform:uppercase;padding:0px 0px 3px 0px;}div.mailcategory{display:block;font:lighter italic 10px/12px verdana,geneva,sans-serif;text-transform:uppercase;color:#660033;}a.mailreadmore{color:#335399;text-decoration:none;white-space:nowrap;}ul.levelone{list-style-type:none;padding:7px 0px 0px 12px;}ul.levelone li{padding:7px 0px 0px 0px;}ul.levelone li br{display:block;margin:2px 0px;}ul.leveltwo{list-style-type:circle !important;padding:1px 0px 0px 20px;}ul.leveltwo li{padding:1px 0px 0px
0px;}span.fieldset{display:block;font-weight:bold;text-transform:uppercase;padding:10px 0px 0px 0px;color:#cccccc;}span.fieldname{font-weight:bold;padding:7px 0px 0px 0px;}div.r1,div.r2,div.r3,div.r4,div.r5,div.r5b,div.r5c{display:block;height:1px;overflow:hidden;border-left:1px solid #2f4a60;border-right:1px solid #2f4a60;}div.r1{background-color:#2f4a60;margin:0px 6px;border-left:0px;border-right:0px;}div.r2{background-color:#6f8292;margin:0px 4px;border-width:2px;}div.r3{background-color:#97a5b1;margin:0px 3px;}div.r4{background-color:#c5ced5;margin:0px 2px;}div.r5{background-color:#eaeef1;margin:0px 1px;height:2px;}div.r5b{background-color:#dce4ea;margin:0px
1px;height:2px;}div.r5c{background-color:#ced8e4;margin:0px 1px;height:2px;}a,input{outline:none !important;}a:link,a:visited{color:#335399;text-decoration:none;}a:hover{color:#000000;text-decoration:underline;}a.active{color:#000000;}
      -->
    </style>

Do not commit.

gregarios,

Can you please re-verify this? I'm not seeing this in testing. Are you using a mail.css?

Jeremiah

Yes. I took 6.x-1.0-alpha2 and applied the patch from #63, which broke the line-breaks from my mail.css file, and added only its own in 700 character lines as seen in the sample in comment #65.

Apparently the patch is stripping all line endings? Maybe you are only allowing Windows line endings? I'm running FreeBSD 6.3 on the server.

Attached is my mail.css file. (with the .css extension replaced with .txt so you could read it from this thread as text.)

This is most definitely not fixed. :-\

Can't we just leave the CSS alone? Its not like the admin isn't the one who created it -- it shouldn't be 90000 characters long anyway!

@gregarios: I think we will not find a solution that can be satisfying in every cases, especially Outlook what is an infernal nightmare anyway, the patch in #63 could be the best scenario and I think will work in most cases.

If the user don't use custom mail.css and the CSS aggregation is on (hopefully is), Drupal core will do this for us with the site's stylesheets. So we are talking about only custom mail.css. If you provide a well-formatted stylesheet the line breaks will be intact. Hence the custom mail.css will be made manually by the users (not included with themes etc.) I assume that everybody can do this.

IMHO we should stick with #63 if there is no other issue, and note it in the documentation that mail.css should be well-formatted, otherwise there can be problems with some mail clients. This can be done in #614782: Update README.txt and additional documentation.

Now I can only attach a formatted version of your mail.css made by an online CSS formatter, but I think it will be enough to do the job. Please test it then report back with your opinion.

I don't see how this will change anything. "Well Formatted" is a matter of opinion, too. I always do my CSS the way you see mine, and I can read it very well that way. So, you're saying that my CSS is to blame for this module stripping out all the line breaks?! Bah.

If the user don't use custom mail.css and the CSS aggregation is on (hopefully is), Drupal core will do this for us

I cannot use the aggregation, because I only need the 20+ lines of CSS that are in my emails, not the entire CSS file from my website. (over 700 lines, formatted the way I DO it -- it would be over 10,000 lines the way your "well formatted" idea is)

Ok, how about this: Have the function strip out ALL line-breaks of any kind. Then have it insert a line-break after every "}" in the CSS. Then have it put in a line-break after every 700 or so characters as a safety as well. Wouldn't that work?

The way I do my CSS is perfectly acceptable and is actually "well formatted" in some circles, too. Wouldn't you rather have compatibility, instead of forcing people to code CSS exactly like you want them too?

I am trying to be a little more constructive here. If we use the CSS as it is the site's stylesheets can break the message without aggregation. So if we don't do anything here, we should make at least the site stylesheet embedding optional: #685574: Optional site's css embedding However, for me the well-line-breaked :D stylesheet seems to be fine. I get your point, of course.

I guess I'm missing something here... isn't CSS aggregation the job of the "mimemail_compress" module? I don't use it, and my site's CSS are not included in the emails at all. I just want my mail.css file to be included with as little destruction of it as possible in the main module's emails. :-)

@gregarios: Attaching new patch against current HEAD. I have tested it with your mail.css and it looked correct. Please give it a try.

The patch to HEAD in comment #73 works perfectly. Thank you.

Here is what my original CSS looks like with it:

<style type="text/css">
      <!--
      html{height:100%;width:100%;margin:0px;padding:0px;text-align:center;background:#000000 url(http://images.kpbj.com/kpbj_background_email.jpg) no-repeat fixed top center;color:#ffffff;}
body#mimemail-body{height:100%;width:100%;margin:0px;padding:12px 0px;text-align:center;}
div#center{display:block;height:100%;width:100%;margin:0px;padding:0px;text-align:center;}
div#main{display:block;width:634px;text-align:left;padding:0px;margin:0px auto 0px auto;color:#ffffff;}
div.bodydiv{color:#000000;}
a.mailhead{display:block;font:bold 13px/16px verdana,geneva,sans-serif;color:#000000 !important;text-decoration:none;padding:0px 0px 2px 0px;}
div.mailsubhead{display:block;font:italic lighter 10px/12px verdana,geneva,sans-serif;color:#617279 !important;padding:0px 0px 2px 0px;}
div.mailbyline{display:block;font:italic lighter 9px/10px verdana,geneva,sans-serif;color:#999999 !important;text-transform:uppercase;padding:0px 0px 3px 0px;}
div.mailcategory{display:block;font:lighter italic 10px/12px verdana,geneva,sans-serif;text-transform:uppercase;color:#660033;}
a.mailreadmore{color:#335399;text-decoration:none;white-space:nowrap;}
ul.levelone{list-style-type:none;padding:7px 0px 0px 12px;}
ul.levelone li{padding:7px 0px 0px 0px;}
ul.levelone li br{display:block;margin:2px 0px;}
ul.leveltwo{list-style-type:circle !important;padding:1px 0px 0px 20px;}
ul.leveltwo li{padding:1px 0px 0px 0px;}
span.fieldset{display:block;font-weight:bold;text-transform:uppercase;padding:10px 0px 0px 0px;color:#cccccc;}
span.fieldname{font-weight:bold;padding:7px 0px 0px 0px;}
div.r1,div.r2,div.r3,div.r4,div.r5,div.r5b,div.r5c{display:block;height:1px;overflow:hidden;border-left:1px solid #2f4a60;border-right:1px solid #2f4a60;}
div.r1{background-color:#2f4a60;margin:0px 6px;border-left:0px;border-right:0px;}
div.r2{background-color:#6f8292;margin:0px 4px;border-width:2px;}
div.r3{background-color:#97a5b1;margin:0px 3px;}
div.r4{background-color:#c5ced5;margin:0px 2px;}
div.r5{background-color:#eaeef1;margin:0px 1px;height:2px;}
div.r5b{background-color:#dce4ea;margin:0px 1px;height:2px;}
div.r5c{background-color:#ced8e4;margin:0px 1px;height:2px;}
a,input{outline:none !important;}
a:link,a:visited{color:#335399;text-decoration:none;}
a:hover{color:#000000;text-decoration:underline;}
a.active{color:#000000;}

      -->
</style>

It's only fixed if it has been committed.

It has been committed.

hi,

where can I find a version of mimemail, where this patch or solution is included?

The only version I can find is
6.x-1.0-alpha2 Download (19.6 KB) 2010-Mar-24
and the patch above is from May 2010.

Checkout the HEAD from CVS.

@DrupalFan2: There is a new alpha3 release - which includes this patch - listed on the project page.

Nice job. Alpha3 seems to work nicely. :-)

Hallelujah! Thanks for your help!

I use this code

// Perform some safe CSS optimizations. (derived from core CSS aggregation)
// Regexp to match comment blocks.
$comment = '/\*[^*]*\*+(?:[^/*][^*]*\*+)*/';
// Regexp to match double quoted strings.
$double_quot = '"[^"\\\\]*(?:\\\\.[^"\\\\]*)*"';
// Regexp to match single quoted strings.
$single_quot = "'[^'\\\\]*(?:\\\\.[^'\\\\]*)*'";
$css = preg_replace(
"<($double_quot|$single_quot)|$comment>Sus", // Strip all comment blocks
"$1", // but keep double/single
$css); // quoted strings.
$css = preg_replace(
'<\s*([@{}:;,]|\)\s|\s\()\s*>S', // Remove whitespace around separators,
'\1', $css); // but keep space around parentheses.
// End the file with a new line.
$css .= "\n";

and my CSS code will have a clean view