Less silently fails on parsing jQuery UI Datepicker CSS

[ghost]

Less 1.3 silently fails on processing jquery.ui.datepicker.css from jQuery UI 1.8.20. The section that causes the problem is:

/* IE6 IFRAME FIX (taken from datepicker 1.5.3 _/
.ui-datepicker-cover {
display: none; /sorry for IE5/
display/__/: block; /sorry for IE5/
position: absolute; /must have/
z-index: -1; /must have/
filter: mask(); /must have/
top: -4px; /must have/
left: -4px; /must have/
width: 200px; /must have/
height: 200px; /_must have*/
}

Normally I wouldn't run this file through Less, however I have my reasons in this case.

[ghost]

Seems to be the line:

display/_/: block; /_sorry for IE5/

[ghost]

Fail was in client side processing in Chrome 19.0 on Windows 2008. Less works without the naughty line.

[lukeapage]

Any chance you can retest with the latest source? I've added a test and this works fine in lessc.. if its browser only there are a few specific bugs about browser specific error-reporting and this may be a duplicate of one of those.

[dmcass]

Confirmed error is showing properly with latest, although the test is slightly off (markdown in the comment system is messing up their code snippets).

display/**/: block; /*sorry for IE5*/

I think the real issue here is that the perfectly valid comment between the rule name and the colon is causing less to choke.

[lukeapage]

I looked at implementing this, but it would be a hassle - does anyone care any more?

[seven-phases-max]

I guess if it's really necessary to pass such code through Less then just:

@import (inline) "the-not-less-compatible.css"; 

can do the trick.

[SomMeri]

Fixed.