Thanks for the report, I suspect that this is a syntax we cannot currently 
parse. Is this a CSS3 syntax? Or is it also a CSS2 syntax?

When we get a find a CSS file we cannot parse correctly, we do not try to do 
anything with it, to make sure we don't break it.

border-radius is a CSS3 property, but it has been (more or less) finalised:
http://www.w3.org/TR/2010/WD-css3-background-20100612/#the-border-radius

I've also identified some other (proprietary) CSS3 styles that aren't
being recognised by your parser.  They're a bit more complicated:

- background gradients

  fieldset {
    background: -webkit-gradient(linear, 0 80%, 0 100%, from(white), to(#eee));
    background: -moz-linear-gradient(top, white 80%, #eee);
  }

  input[type=submit] {
    background: #f7fafc -webkit-gradient(linear, left top, left bottom, from(#fff), to(#dae6f1));
    background: #f7fafc -moz-linear-gradient(top, #fff, #dae6f1);
  }

- input placeholder formatting for WebKit

  input::-webkit-input-placeholder {
    color: #ababab;
  }

The parser does recognise the Mozilla equivalent, with a single colon:

  input:-moz-placeholder {
    color: #ababab;
  }

Thanks. Our parser is not yet CSS3 capable. But we'd like to improve that. 
These examples are helpful to keep around for when we get a chance to look into 
this.

And if you happen to find that any of your styles get broken by CSS 
minification, please open a new bug for them.

I've run tests on a selection of our style sheets and collected the lines that 
weren't being parsed into a single file (attached).  Barring any typos, they 
should all be valid syntax.

Issue 120 has been merged into this issue.

From Maksim, common things that we can't parse:

1)  The star hack. This looks like:
*width: 500px;  --- it's discarded by normal parsers, but handled as
width: by some IE versions.
Extremely common.

2)  Some browser-proprietary property values:
cursor: hand; cursor: col-resize; cursor: not-allowed; (IE)
display: -moz-inline-box; display: -moz-inline-stack; (Gecko)

3)  IE filter mess:
_filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='http://t.douban.
com/pics/nav/ui_sl_bn.png',
sizingMethod='scale');
filter:alpha(opacity=60);
filter:Alpha(Opacity=0);
filter:mask();

4) Some CSS3 stuff --- I think there is an issue on that already?
rgba() color syntax (semi-common, and @font-face with  src:local()
[only saw it once]

5) There is also an another parser hack, that looks like this:
margin-top: 8px\9; --- not sure what to make of it.

Trunk revision r449, allowed many proprietary values (like -moz-foo-bar). More 
coming.

Star hack (http://en.wikipedia.org/wiki/CSS_filter#Star_hack) supported in r459.

Parse CSS3 Pseudo-elements with :: like body::selection in r462.

Parse generic functions in r468.

Ex: -webkit-gradient(linear, 0 80%, 0 100%, from(white), to(rgb(123, 47, 104)))

Parse Microsoft proprietary syntax in r473.

Ex: filter:progid:DXImageTransform.Microsoft.Alpha(Opacity=80)

From bug 220:

-webkit-transition-property:opacity,-webkit-transform;

Notice the comma.

See: https://developer.mozilla.org/en/CSS/-moz-transition-property
and http://www.webkit.org/blog/138/css-animation/

We also don't parse parameterized pseudo-selectors:

div:nth-child(1n) { color: red }

Progress report on this:

 - we continue to add capability to our css3 parsing and it's improved but it's
   a moving target.

 - we have another plan to optimize CSS files that have unrecognized constructs in them, leaving the unrecognized constructs as literals

Also, most of the cases we cannot parse are actually illegal CSS, using hacks 
to target specific browsers. If we cannot preserve those hacks, we fail to 
parse the document.

I'm experiencing a problem where mod_pagespeed does not seem to be processing 
some CSS files, and I suspect it may be because of this issue. The only reason 
I can think of (mentioned in this issue) is rgba(). Is that implemented yet? Is 
there any way to tell why mod_pagespeed is not processing these files? I have 
been unable to find any logs pertaining to this, and no documentation for how 
to adjust log levels etc. or whether this is even possible.

With the newest versions of mod_pagespeed, you can set "LogLevel debug" in 
Apache and this will print context to where the CSS parser failed to parse CSS 
files. It's not the nicest user interface, but I can help you interpret the 
result if it's not clear.

rgba() should be working with the most recent release (see 
http://code.google.com/p/modpagespeed/source/browse/trunk/src/net/instaweb/rewri
ter/css_filter_test.cc#389). To get the most up-to-date info on what is and is 
not parsed, see good_examples and fail_examples here: 
http://code.google.com/p/modpagespeed/source/browse/trunk/src/net/instaweb/rewri
ter/css_filter_test.cc#145 and examples and parse_fail_examples here: 
http://code.google.com/p/modpagespeed/source/browse/trunk/src/net/instaweb/rewri
ter/css_filter_test.cc#247

Several updates have been pushed into the CSS parser to allow it to pass 
through troublesome constructs verbatim when we cannot parse them.

Since this bug was reported a lot of improvements were made to the CSS parser, 
however CSS3 is still not a ratified standard so it's difficult for us to claim 
we support it (and we're not even close to be honest).

We now pass through many non-standard constructs verbatim so we can still 
optimize the remainder of the file; hopefully this is sufficient to handle CSS3 
files until the standard is ratified.

Marking this fixed for now. If a specific construct is discovered that we are 
not handling, please paste it specifically.

From issue 407:

If you create a stylesheet with the below content, the CSS isn't processed.

@font-face {
 font-family: 'RokkittRegular';
 src: url('fonts/rokkitt-webfont.eot');
}

@media queries are problematic as well.

@media (max-width: 800px) {
   #main #content {
     margin: 0 7.6%;
     width: auto;
 }
}

[Fri Mar 30 13:48:28 2012] [info] [mod_pagespeed 0.10.21.2-1381 @21277] 
http://foo.com/:19: CSS parsing error in 
http://foo.com/wp-content/themes/theme/style.css

Using mod_pagespeed 0.10.21.2-1381

I'm uncomfortable with release-noting this as fixed.  I think we should do a 
more thorough job of (a) skipping over unrecognized constructs and (b) handling 
 media-tags properly since they seem to be common before marking this as 
'fixed'.

Another way of measuring this is whether we can properly rewrite the css for 
commonly used UI packages.

Hi,

Following CSS3 syntax is also causing pagespeed to barf

-webkit-transition: border linear 0.2s, box-shadow linear 0.2s;
     -moz-transition: border linear 0.2s, box-shadow linear 0.2s;
      -ms-transition: border linear 0.2s, box-shadow linear 0.2s;
       -o-transition: border linear 0.2s, box-shadow linear 0.2s;
          transition: border linear 0.2s, box-shadow linear 0.2s;

not sure if this is a know issue. Listing it here anyway. 
I got latest source code from trunk and compiled it and ran the parser against 
the css file.

Let me know if you need anymore details

Thanks! 

Another one

    -webkit-box-shadow: inset 0 1px 0 rgba(255, 255, 255, 0.1), 0 1px 0 rgba(255, 255, 255, 0.1);
       -moz-box-shadow: inset 0 1px 0 rgba(255, 255, 255, 0.1), 0 1px 0 rgba(255, 255, 255, 0.1);
            box-shadow: inset 0 1px 0 rgba(255, 255, 255, 0.1), 0 1px 0 rgba(255, 255, 255, 0.1);

This makes me think it could be an issue with css properties which take 
multiple set of values.

Hi yeshwanthgreddy, note that we will still successfully rewrite CSS files 
which contain these CSS3 constructs.

We fail to parse them, but we are able to recover and pass those sections 
through verbatim.

As you point out, the reason these cause problems is that they have 
comma-separated values (in addition to space-separated values, the CSS2 
standard).

Hi sligocki,

Its true that it recovers from parse errors but it clears all the pagespeed 
cache each time it encounters a parse error. This is being further amplified in 
a clustered env and causing pagespeed to behave as if it was the first pass and 
loosing all the optimizations. I tried turning off rewrite_css, inline_css, 
outline_css filters and enabling just move_css_above_scripts,move_css_to_head 
in config but does seems to work. It still is trying to parse the files and 
failing every 5mins. Is there any way we can turn parsing of css files but just 
combine and cache them?

This should NOT be clearing your pagespeed cache every time there is an error. 
However, it will fail to combine CSS files if they have unparseable regions 
(like the ones you specified). I don't think there is any way to disable this 
behavior, sorry. But it is not clear to me why you think it is clearing your 
cache each time. Could you explain this in a little more detail. A link to your 
site would also help me to understand.

We have changed the log level on our servers and tailed the log file for 
"error" and were running ruby script to hit the page 300 times, get the output 
and scrape the html output for speedified (copy righted :) ) objects and output 
the count and this would run every 20s and we have been seeing a pattern that 
every 5mins when it polls to check for the changes it would throw an parse 
error in the log and the count for speedified object count to go to 1 or 2. 
This is behind a load balancer across 2 servers internally.

We have enabled pagespeed on one of our pages on production on a clustered env 
and were testing it at http://www.webpagetest.org/  and we are seeing for every 
10 passes we are seeing atleast 3-5 calls failing to use pagespeed 
optimizations. 

Here is the url you can hit: http://www.phoenix.edu/beta.html

This behavior is unrelated to this bug. I have forwarded this to the 
mod-pagespeed-discuss email list.

Hi sligocki,

Thanks for looking into the issue and forwarding it to mod-pagespeed-discuss 
email list. Now how do I get hold of the discussion thread though? I have 
searched and could not find one.

Oops, didn't actually press send :/ You should get the email now. Here's the 
discuss list (you need to be a member to reply): 
https://groups.google.com/forum/?fromgroups#!forum/mod-pagespeed-discuss

Summary was: Parse CSS3 and common proprietary syntaxes

CSS3 is not a finalized standard so we cannot really close the bug as 
previously summarized.  We are now scoping this bug down to support of CSS3 
media tags, which we believe were responsible for the most of the issues with 
our parser. 

Once this is fixed, further CSS issues should get a new bug.

CSS @media queries should now be parsed and minified.

Using the new Beta mod_pagespeed microsoft progid works but this media query 
fails: "@media only screen and (max-device-width: 1024px)".

Was it meant to work?

This will work as of v23, which has been branched now in SVN but is not yet 
released.  We're working on it.

Great!

Should it work using the beta rpm?

When will the next release be?