Hi Guys,

We're investigating Prince as a possible way to generate our transaction documents.
We write most of our CSS code with the LESS preprocessor.

Currently the LESS parser expects any vendor-specific directives to begin with a dash, and will treat anything both not matching that pattern and not in the non-vendor-specific whitelist as a variable, causing it to choke on Prince's directives.

Would it be possible to allow the setting of Prince directives (and properties) with -prince-foo in addition to the existing prince-foo syntax?

Thanks for your time.

Yikes, that sounds a little brittle, as new CSS properties get added all the time. Can you run a quick sed s/prince-/-prince-/ in the meantime?

While I agree the LESS parser should be more forgiving, and it's not a huge pain to put a workaround in our build process, and, as I'm sure you're already aware, the spec doesn't really take a strong position on it, most vendors who have implemented extensions named with their prefix have chosen to also use the leading dash style. It seems like the kind of thing that could eventually merit a breaking change.

This is something we have put off for many many years, as we have long believed that it was wrong-headed, and that the browser vendors would eventually realise that fact, which they now seem to be doing.

I don't think it ever made sense to use vendor prefixes for features already in the CSS specification, like the transform property. For features that are not in the specification and never will be, like our @prince-pdf rule, adding a leading dash would be needlessly ugly, and does not even comply with CSS syntax. Since CSS already has well-defined behaviour for skipping unrecognised at-rules, the leading dash is not even necessary.

So from my point of view, fixing the LESS parser is both easier and a more suitable solution for this problem.

Seems like the latest LESS handles @prince-pdf just fine (1.7).

Pulse Energy

Edited 23 Apr 2014 by wachunga

Yay!