You can clone with
HTTPS or Subversion.
Step to reproduce:
Diffing the CSS output manually, I found out:
progid:DXImageTransform.Microsoft.gradient(startColorstr='#333333', endColorstr='#222222', GradientType=0)
progid:DXImageTransform.Microsoft.gradient(startColorstr=#333, endColorstr=#222, GradientType=0)
Probably what's causing it.
Cheers man, I'll change it to be identical to the less line. Probably me trying to be clever when I was converting the code.
Sorry about not getting back to you on this one, exams in January are slowly drowning me already.
Arf, no problem. I wasn't sure what was causing it anyway.
Can you bump a release soonish?
Aye, I'm hoping to get a release tonight that addresses all the current issues.
I think I've got this fixed now.
enclose startColorstr and endColorstr in single-quotes
(hopefully) fixes #14
sigh thinking about it, this could either be the lack of quotes causing the issue, or the use of shorthand colours.
Let me know if the 1.4.1 release has fixed it, if it's the shorthand colours I'll run round and change them and push 1.4.2.
I want the MSDN compliance Gold® Logo on RailsAdmin's homepage, it would enlarge my penis very much.
Give me an hour, go go go go go.
filter doesn't support the use of named colours, only took me an hour to work it out. fun times. Guess I also have to figure out what's happening to the topbar as well but that's slightly less breaking than those buttons.
Will try and push a new release with the fixes later today.
fix for IE-filter not supporting named colours
Supporting IE7 is more effort than it's worth, surely. should (yet
again) fix #14
That should do the trick, according to my Heroku sample application.
Let me know though, I probably won't be able to push any more changes for the next few days (interview at Oxford) but, like I say, there shouldn't be a problem.
The buttons now look fine, but the toolbar's still broken. (I updated RA demo with 1.4.2 so you can have a look)
Steve Ballmer said I can't have the badge. Bummer.
Looks like the issue is with sass using the smallest representation for a given color, but IE needs the full value. Per the (Sass reference material)[http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html]:
"Compressed style takes up the minimum amount of space possible, having no whitespace except that necessary to separate selectors and a newline at the end of the file. It also includes some other minor compressions, such as choosing the smallest representation for colors. It’s not meant to be human-readable."
I am going to look into the SASS compile options to see if there is anything that can be specified inline to prevent #222222 from being abbreviated to #222, but as a quick fix we included the following inline style in the head section of our layout:
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#333333', endColorstr='#222222', GradientType=0) !important
Then include the topbar-fix class where needed, this class will then override the incorrect filter that SASS compiled.
It fixes the issue with the topbar gradient in IE 7/8.
Yeah, that was the problem I was having with the buttons, SASS will use a named colour representation or a shorthand notation if it can which MS-gradient won't accept.
The solution I had was to knock the blue value down a notch, which has next to no impact on the colour but makes it work. There doesn't seem to be no way of configuring what the default 'format' of the output is, which means we have to make the output in such a way that it can't be shorthanded, or to override it as you are doing. It's evil, but at the same time I see no obvious way around it.
I found a blog article that may be able to work as a solution:
This might make it possible to fix inside of bootstrap-sass itself. I'll try to incorporate offline and see if it works...
Fix Microsoft.gradient issue with SASS asset compilation. Resolves #14.
Cross posted there: sass/sass#231
Thanks @rjackson for the investigation.
Consider this fixed. Finally.