@font-face seems to break the css parser

[Glenn Slaven]

We have a customer with this css file http://www.trova.com.au/Content/styles/main.css which has a couple of @font-face directives at the start. That css file never gets rewritten, and when I run the standalone css parser on it it says

Cannot parse unknown @-statement: font-face at byte 10 "...@font-face {

  font-family: "B..."

Ignoring {} block. at byte 11 "...@font-face {

  font-family: "Br..."

Ignoring chars in value. at byte 26 "...face {

  font-family: "Brandon Grotesque..."

Ignoring chars in value. at byte 62 "...sque Regular";

  src: url("/Content/font..."

Ignoring chars in value. at byte 116 "...webfont.eot");

  src: url("/Content/font..."

Ignoring chars in value. at byte 198 "..."embedded-opentype"), url("/Content/font..."

Ignoring chars in value. at byte 287 "...arRg") format("svg"), url("/Content/font..."

Ignoring chars in value. at byte 350 "...off") format("woff"), url("/Content/font..."

Ignoring chars in value. at byte 431 "...ype");

  font-weight: normal;

  font-sty..."

Ignoring chars in value. at byte 453 "...normal;

  font-style: normal;

}

@font-f..."

Cannot parse unknown @-statement: font-face at byte 476 "...ormal;

}

@font-face {

  font-family: "B..."

Ignoring {} block. at byte 477 "...rmal;

}

@font-face {

  font-family: "Br..."

Ignoring chars in value. at byte 492 "...face {

  font-family: "Brandon Grotesque..."

Ignoring chars in value. at byte 525 "...otesque Bold";

  src: url("/Content/font..."

Ignoring chars in value. at byte 579 "...webfont.eot");

  src: url("/Content/font..."

Ignoring chars in value. at byte 661 "..."embedded-opentype"), url("/Content/font..."

Does this explain why the file is never being rewritten on the site. We're running pagespeed v1.7.30.4.  I understood from this release https://developers.google.com/speed/pagespeed/module/release_notes#release_1.1.23.1-beta that unknown @ directives shouldn't break rewriting anymore.   It does rewrite the css file off onto http://s.squixa.net/www.trova.com.au/635332092192070000/Content/styles/A.main.css.pagespeed.cf.tP3y2vPWof.css I assume due to fallback_rewrite_css_urls.  But if you hit the site with http://www.trova.com.au/?PageSpeedFilters=rewrite_css the main.css file doesn't get touched.

--

Glenn Slaven

Principal Engineer

Ph: (02) 9119 0444

M: 0433 826 255

www.squixa.com

[Otto van der Schaaf]

From the docs: "Not all CSS3 or proprietary constructs are parsed. When unhandled syntax is present and the file cannot be parsed completely, the URLs in the CSS can still be rewritten by the fallback_rewrite_css_urls filter. However the CSS will not be minified."

Looking at https://code.google.com/p/modpagespeed/source/browse/trunk/src/third_party/css_parser/src/webutil/css/parser.cc#2234

I think @font-face could indeed could cause css rewriting to fall back to fallback_rewrite_css_urls, as I don't see @font-face amongst the @-rules that are handled. 

--
You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-di...@googlegroups.com.
Visit this group at http://groups.google.com/group/ngx-pagespeed-discuss.
For more options, visit https://groups.google.com/d/optout.