CSS parser: incorrectly handing polybuild output

[ebidel]

When Polybuild crushes element CSS and removes whitespace, custom property rules end up running into each other. Unfortunately, this causes our parser's regexing to start ignore rules. The issue can be seen when you have two --var in a row (one won't do it).

top: 400px;--paper-fab-background: var(--paper-green-500);--paper-fab-keyboard-focus-background: var(--paper-green-700);

putting as space in between properties works:

top: 400px; --paper-fab-background: var(--paper-green-500); --paper-fab-keyboard-focus-background: var(--paper-green-700);

http://jsbin.com/wayoholaxi/edit?html,output - you'll see top: 400px is ignored

cc @azakus

[ebidel]

@sorvell @azakus wdyt? This blocks usage of polybuild. I'd really like us to start recommending that as a one-stop-shop tool.

[Nick-Ewer]

Any solution for this? We're using polybuild and I'm having issues when doing the same thing.

[TimvdLippe]

Just stumbled on this issue. #2662 has been merged which touches another var() issue. @ebidel can you confirm/deny it is fixed now? Else I can take a look again on how to fix the regex.

EDIT: I am looking into this issue right now.

[dfreedm]

@JeremybellEU No worries. PRs don't run in Safari or IE because we run those on SauceLabs and keep the credentials encrypted. Travis only decrypts the credentials when the PR or branch is on the same origin.

[dfreedm]

Most of the time, that should be enough. Styles are annoying though...

[dfreedm]

Ugh, looks like this line https://github.com/Polymer/polymer/blob/master/test/unit/custom-style.html#L258 became top: 12px;; in Safari

[TimvdLippe]

Hm, could you maybe escape the { and similar characters in the regex and try again? So:
/(?:^[^;\-\s\}]+)?--[^;\{]*?:[^\{\};]*?(?:[;\n]|$)/gim. Seems really weird if Safari would parse this differently.

[dfreedm]

Nope, that doesn't work.
I've tried rebasing this patch against 1.2.3 to see if anything else that was merged could be a problem, but it looks isolated to this commit.

[TimvdLippe]

Urgh, maybe it is best to revert the PR for now and someone with Safari can investigate the issue. I can only guess at this point, since Safari can not be installed on Linux... It is now causes failed builds on subsequent PRs