Open florbraz opened 11 years ago
Came here to say this as well. Sass support would make this insanely useful for me. Though I imagine it would be tougher to implement.
Couldn't it be based on the way Chrome DevTools does Sass integration in its experiment now, using source maps?
http://bricss.net/post/33788072565/using-sass-source-maps-in-webkit-inspector http://www.html5rocks.com/en/tutorials/developertools/revolutions2013/#toc-sass-debugging
No. Source maps are good for viewing things, but not for editing. Whenever you change something in SASS or generated CSS, source map become invalid and have to be re-generated again.
SASS Support (SCSS) would make this Tool useful to us.
Not sure if this is the right place to say it, but I also add my vote on Sass support. Thanks.
+1
++1 :)
As much as I love the idea and appreciate work was done, I obligated to say that without SASS/LESS/Stylus support it simple can not be integrated into real work process (as rails/frontend developer I haven't seen vanila-CSS based project for years - even the small public projects is worth using some kind of pipeline) and tend to be more like fun and impressive experiment - but not the real tool. I simply can not afford to trade off the power and maintainability of preprocessors on any kind of not-a-contact-page projects today.
So: +1 for kickstarter project, as soon as it brings SASS support (my vote is for Stylus actually, but SASS seems more real :)
+1 for Sass/Scss
+1! :)
+1
Stylus would be great too!
+1 . With Sass/Scss support, this will be insanely useful in my everyday projects.
+1 for Sass/Scss!
+1
+1
Not sure any more +1's are needed as obviously this would be awesome and is highly desired.
Is any work being done on implementing SCSS/SASS though?
I don't know enough about web inspector and suspect my input is trivial, like telling fire gods how to rub sticks together. But it seems like maybe you could overlay a user identified SASS file over the CSS in inspector, or ass a new tab and then recompile the SASS to CSS in javascript (I'm assuming there is a JS based SASS compiler, I've only ever used one for LESS).
Even without preprocessor support this is pretty awesome though. Thanks.
Re-compilation of SASS doesn’t makes sense for LiveStyle. It will be yet another LiveReload/CodeKit/etc.
The goal of LiveStyle is to make a truly live (without any re-compilation) and bi-directional development. I’m finishing Milestone 1 release of LiveStyle right now and the next Milestone 2 will be focused on enabling and improving LESS and SCSS experimental support. At least you can use it for basic bi-directional live tweaking together with tools like grunt-livereload
, e.g. make simple tweaks with LiveStyle and make full re-compilation/page reload on file saving.
Live editing with Sass makes a lot of sense, im using http://usetakana.com/ for that. But I see your point about the bi-directional thing being anything but trivial.
Thanks Sergey. The bi-directional aspect of LiveStyle is what I find compelling so I look forward to it. I've been a little confused over SCSS/SASS/LESS support. Does LS currently support SCSS? I know it was in a demo somewhere, but I wasn't clear if that was real or there were limits to what it could do. Maybe it's obvious and I just haven't tried, but it seems totally undocumented.
SCSS is just an experiment I made for demo video to show the power of LiveStyle engine. It is disabled because it wasn’t tested enough and may actually break your code. It will be enabled and improved in Milestone 2
I'd like to +1 scss support. I also understand why you can't add recompilation to LS (out of tool focus) nor can't use sourcemaps so will not expect so soon for sass projects. On other hand, is awesome for plain css ones!
padding
property in DevTools, it’s source does not exists in SCSS so it can’t be mapped at all.Yeah, probably anything related to sass would have to rely on re-compiling/sass/compass stuff.
Maybe the way to make LS work would to code something to act as a plugin for compass for e.g., where it's watch
would act bi-directional - that is - instead of:
Would be:
This way LiveStyle would only need to keep working as is, editing final .css
.
Don't know if sass/compass can predict the changes based on last sass-cache and do inverse compilation.. We gotta ask nex3 and chriseppstein for that.
+1
+1
+1
1 mas! Would love to have this!
+1
+1
Waiting for LS Milestone 2, diff/re-compiling is not so hard, but performance is a big problem.
FYI, performance is much better if you're using libsass rather than the Ruby-based compiler.
@sergeche Any update on this? I'm not seeing a dev branch or anything for this. Just curious if SCSS/SASS support is being worked on or still just "some time in the future"?
Working on it. LiveStyle is based entirely on Emmet so I have to finish v1.1: https://github.com/emmetio/emmet/issues?milestone=1
Great! TY for the update!
+1
+1
Nice work!Waiting for SASS~
+1
+1
+1
+1
+1
+1
+1
+1
+1
I still can't see how that is going to work. Unless you make chrome understand scss, and this way, the plugin wouldn't even need a update.. How you gonna make it bi-directional? Source maps allows you to know the original SASS (less,etc) file resource you need to edit, but how to to the opposite direction? Recompile/remap every save sounds not possible.
+1
+1