Update for SASS
  • Would it be possible to have a quick update to SASS to support the new (default) SCSS syntax for files ending in .scss?


    Also all the links on the docs page about HAML/SASS are broken.
    http://docs.vaeplatform.com/haml_sass

    I think you want them pointing to.
    http://haml-lang.com/
    http://sass-lang.com/

  • 15 Answers sorted by
  • I got the SCSS syntax working in the Vae Local Preview Environment by dropping the current SASS gem (https://github.com/nex3/sass) into the vender directory. But the asset tag still doesn't recognizes the .scss extension, so I linked up a empty base.sass file and used @import to bring the my .scss files into it. This can work for local development for now. I know it will need to be upgraded on the servers before it can work live.

    I think you will also want to update the Vae Local Development Environment to include newer version of the Compass gem, I would also say you can remove the HAML gem because SASS was split out of it and it looks like you parsing HAML on the server and not locally so I don't think its needed but I could be wrong.

  • This is a bit of a struggle for us because Sass is not necessarily backward-compatible to previous versions, so when we've tried to do upgrades in the past, it has messed up existing sites. (This is also why we hesitate to update PHP.)

    Of course, all hosts deal with this stuff (look at how old the software running on Hostgator is, for example), and we do try to be better than most hosts. I'll see if we can do something on this in the near future.

  • Yah I totally hear you, and I appreciate you talking the time to look into it.

    Here is a thought SASS 3 has what looks like a pretty robust conversion tool that can update the syntax on older files. One way you could handel the migration would be to run sass-convert as a pre-filter before you send it through the SASS engine. I don't think it would need to happen on every request just when the file was updated and needs to be re-cached on the CDN.

    http://nex-3.com/posts/95-awesome-syntax-changes-in-sass-3

  • What I might prefer is to support current .sass files by renaming them to .sass2 and then move the new default .sass and .scss to be the latest Sass 3. I'll see if I can do that in the coming week(s).

    Kevin

  • That's awesome Kevin thanks so much!

  • Wanted to let you know I haven't forgotten about this. I'll see if we can get this done sometime soon.

  • That's awesome! Thanks Kevin.

  • Do you run the css through any other process? It looks like there might be some intelligent minification type stuff going on.

    I'm running into a problem where I have a body selector in two different stylesheets but when it goes through the asset tag and minifies/concatenates the body css selectors get merged and clobber each other.

    Do you know why this might be happening?

  • I diffed the local css against the server generated css and it looks like its actually doing quite a bit. There is some nice optimization like collapsing margin/padding into shorthand notation. But there is a lot of rejiggering selectors and striping out – assumed – unimportant things.

    Here is a link to a screen shot of the diff.

    I'm not kidding when I say it might be the most ridiculous screen shot you have ever seen, its pretty funny. :-)

    http://img11.imageshack.us/img11/7784/cssdiff.png

  • Hey Arron,

    Yes, the <v:asset> tag does a lot to attempt to squish the filesize of your CSS as best as possible. This means removing comments, removing selectors that are invalid, combining, etc.

    I've never seen it outright break something, but if you can create a simple test case of something it's breaking, we can probably fix it up for you quite quick!

    Kevin

  • I got it resolved there was an easy work around I just added a more specific selector in this case.

    I have been using the Html5 Boilerplate [http://html5boilerplate.com/] as a starting point for my projects.

    I did notice it removed some of the things they use for font normalization.

    body { font:13px/1.231 sans-serif; *font-size:small; } /* Hack retained to preserve specificity */

    It removed the asterisk in front of the font-size, which I think is non-standard (probably why it got striped) but used for ie.

    Right now its not a deal breaker - but in the future it would be nice to maybe have options for issues like this.
    Most compressors/compiles have flags you can set for varying levels of compression. I think a compression attribute on the asset tag with the following options would be nice.

    * Level 1. Nothing
    * Level 2. Strip Whitespace and Comments
    * Level 3. Above and flatten properties like margin and padding etc. into short hand.
    * Level 4. What you have now where it rewrites the css.

    I would personally use 3 because I'm probably more paranoid of number 4 then most people. And I totally understand the reason for not implementing edge case feature requests – but it would be a nice option.

  • Hey,

    We just rolled out an update that includes Sass 3 and the latest version of Compass! This also includes support for the .scss file extension.

    Can you give it a try and let me know if it works for you?

    This update is enabled by default for NEW websites, but all existing websites is disabled by default.

    You can enable Sass 3 on this page:
    https://btg.vaeplatform.com/settings/content

    [The update has NOT yet made it into the local development environment, as I'd like to have you test it first, but this should be a matter of just updating the vendored gems.]

    Let me know how it goes.

    Kevin

  • I also added in a new option on the same settings page to disable CSS minification. See if that helps you!

  • I'm seeing a problem not sure if its related to the changes you made.

    It seems like the system is not picking up changes to my stylesheets and recompiling them like it should.

    I can make changes or even remove all the styles from a stylesheet upload the changed/blank file and it still won't reflect the changes on the staging site. (ec.vaesite.com)


    I found a way to force a re-compilation with this undocumented way of splitting up compiled assets into separate groups. (which is awesome by the way, thanks.)
    http://forum.vaeplatform.com/discussion/54/grouping-vasset/

    By default I have my 3 stylesheets linked and there are compiled into one. But if I put one into a new group it will trigger the compilation of everything and then the changes are picked up again.
    Right now this is only I can get it work, but if I remove the group so it goes back to the default the changes are lost and it reverts back to the old stylesheet.

    Not sure 100% whats going but I will do anything I can to help pin point the problem.

    Arron

  • Sorry for the delay -- I didn't see this reply. Can you try direct-linking to the stylesheet without using <v:asset> and see if that helps? (you can link straight to the .sass or .scss file).

    Are you using .scss or .sass? Are you using any form of @includes inside the stylesheet?

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Apply for Membership

In this Discussion