REx_css-tools.xsl lexical analysis failed

[peppobon]

When parsing this css:
@media (max-width: 709px) { h1, h2, h3, h4, h5, h6 { font-size: 1em; } }

Rex throws this error
lexical analysis failed
while expecting [',', 'amzn-kf8', 'amzn-mobi', 'amzn-mobi7', 'and', 'not', 'only', 'or', 'screen']

probably the grammar needs to be updated.

Thanks

[gimsieke]

Yes, the grammar didn’t allow the media query to start with a media feature such as (max-width: 709px), it always expected a media type such as screen. I updated the grammar to be more like the official syntax.

I noticed that Firefox accepts something like not (max-width: 709px), but the grammar (both the official level-3 syntax that I linked above and what I implemented just now) rejects it.

In CSS 3, not is only permitted if it precedes a media type. I think Firefox implements a media query level 4 feature here, and why not. Our CSS grammar aims to support level 3 though.

Please update css-tools and see whether your input will be processed correctly now. And thanks for the bug report!

[peppobon]

Thank you Gerrit,
now it works but I get other grammar errors.

Unfortunately I have a quite complex css used by a client in proprietary epub reader and even when deleting the offending css selectors (for example -webkit-transform: rotate(90deg);) and others) I get the following generic error I cannot trace to a specific css feature

ERROR: Pipeline failed: An empty sequence is not allowed as the value of variable $font-size
ERROR: Underlying exception: An empty sequence is not allowed as the value of variable $font-size

The workaround for me is quite easy and consists in deleting the source css files and then injecting them back into the generated epub along with the relevant manifest entries in a postprocessing pipeline; this works well so I am not asking any fix on your side.

I will open a new issue on the epubtools regarding the possibility to skip the css parsing.