WebPutty: CSS editing goes "boink"
blog.fogcreek.com
blog.fogcreek.com
Not sure how I feel about the inclusion of the link/script tags in order to make this work but it all seems geared to someone who maybe has their own blog or very low-trafficked site and this would be their alternative to editing the files on the live server.
Any site I've ever worked on I've always had atleast 2 environments, a local environment and a live environment. Any company I've ever been a part of has had at least 3 environments (sandbox/qa/live) and it's very common to have a dev and staging environment on top of those as well. The reason you have a minimum of 2 environments is so that you can do all of your testing without breaking the live environment, which is what this tool seems to ignore.
"You can always export a pretty-printed version of your website’s CSS at any time (both the preview and published versions)."
See my other post, I believe you have not understood their product very well.
They also give you the option of hosting your CSS file on their servers, which is why you'd need the link to that CSS file.
It's all explained on their website which you might not have read/understood, or maybe I am missing something.
As a web developer working on quite a few projects, this tool seems great, although I can't have them hosting CSS for internal projects.
The hosting of your CSS files on their servers is also not suited for a development environment that has more than 1 environment, as I would not want to be editing files that are on a live server on a regular basis without first making those changes locally (and possibly checking them into an SCM of some sort first) because my css would quickly become out of sync across environments.
May I ask, the projects that you work on, do you have more than 1 environment that you use and do you collaborate with any other developers on these projects?
As far as working on teams, they're "thinking about how to expose your CSS in a versioned way so that you can keep it in Mercurial (with Kiln!), or Git, or whatever other version control software you might be using". Perhaps you're right, it's better to wait until that is implemented if you have that kind of setup.
EDIT: I've started testing it, and you can add other admins and editor users for sites, very nice.
Seems like a Web Putty browser plugin would help preserve the "local transparent editing a la Firebug" use case. Transparent meaning, no edits to your existing HTML required to demo different CSS stylings. Or am I misunderstanding this?
Doing the same thing with WebPutty would take maybe a dozen lines of code. I'm assuming anyone with multiple environments can make it happen in their language/framework of choice.
We're also releasing this very early, for a Fog Creek project, to see what people think. It might be that this becomes a desktop tool using something like Titanium, or we might try to integrated version control into it as an alternative to publishing. As such, we're open to suggestions and feedback.
We actually did look into getting Mercurial (which is what we use internally and what we provide via Kiln) up and running in AppEngine, which has been done before, but was just beyond the scope of the first phase of the project.
And I agree, I don't think we'd ever host FogBugz's or Kiln's CSS with it on AppEngine, but I do really want to be able to use the editor and SCSS with those projects, so we'll be keeping an eye towards making that more natural.
I think there is a lot of changes that can be done to make this a better solution. But as it stands if being used by a small company I can see some merits.
However, I would be cautious about putting something in a beta stage on any site with enough value.
1) Coda has real-time CSS editing built-in, and you can relatively easily fire up multiple windows to edit in a "real" editor (if you consider Coda a real editor) and view changes in real-time as you type
2) CSSEdit does one better -- you can edit using their editor and see changes in key-by-key realtime in their preview window. OR, and this is how I've settled on working, you can edit files using the editor of your choice (MacVIM, for example) and still see changes instantly upon save in their preview. So it reduced the need to reload the browser (saving half the steps). Now it's just a matter of make changes, Cmd-S (or however you save in your editor of choice) and it's all updated in real-time.
That's a fairly consequential thingee to have on a server with availability independent of one's own.
If folks want I'll OSS code for this, although at a dozen lines in Rails it is barely worth typing git clone...
Does SASS offer a solution for this?
http://blog.httpwatch.com/2010/02/10/using-protocol-relative...
...and the unfortunately double-loading bug for CSS files in IE7/8 here:
http://www.stevesouders.com/blog/2010/02/10/5a-missing-schem...
The "scientific progress goes boink?" line is from the duplicator story (which I can't find). The duplicator is the cardboard box on its side, which is obviously completely different from the transmogrifier. And if you turn the opening to the top, it's a spaceship!
For example, the article says that you have to do a lot of tweakage with the element inspector. This isn't 100% the case and I think that paints Firebug in a less than positive light. The element inspector is a really useful tool but you're just not restricted to that.
There's a CSS tab next to the HTML tab. This presents the full stylesheets to you pretty printed, editable like you would an inspected element. I can often author a lot of CSS in this window in:
a) A much shorter space of time. b) Less amounts than I usually would.
Why point a? When you can see the CSS changing in real-time, you don't have to constantly refresh. Yes, there are ways to reload CSS and I use them often but it's not quite live like Firebug is. The second point is pretty much for the same reason: since you're making the changes in real time you can see exactly what changes what. This makes it less likely to over-step, in which you could be writing redundant CSS.
Firebug has it's downsides, such as it's clunky way of editing with pretty printing. There's also how it assumes the formatting of your CSS. You can use it in a similar way to an editor too but this removes pretty printing. Another big thing is the ability to lose work on refresh if you're not careful.
I can indeed live with the above. I don't think there are many instances where I would like to add in extra assets. I am quite a forgetful person.
Either way, the issues with Firebug can be patched over and I'm certain can be fixed. I don't think linking additional JS and CSS can easily be rectified with this.
What could be missed is the publish feature but not exactly ideal in a fair few number of situations.
This is from somebody who has to work on a lot of static websites and restrictions insist on pure CSS and HTML.
In a static environment, you can just compile the SASS to CSS before you deploy, or you can use WebPutty and have us host it for you.
A firebug inspired element inspector may be a good thing. I think jumping straight to the line of CSS rather than the separate, filtered window would be a great idea. I'd really love that.
Another thing, but less important, would be auto-complete. Either that or ways to expand ZenCSS abbreviations. This would push my productivity to the moon.
Another thing I was thinking of hacking on to Firebug (when I find out how) is selector hinting. The way this would work is, when you type a selector, the available ones are given to you, much like method hints in IDEs. This would be very useful to me at least. There have been many times when I've needed to know a particular hierarchy/id name/class name and found myself having to reference elsewhere.
To host CSS would be a social/pointy-haired-boss issue but I could make necessary recommendations. In any sense, I love the work that has been done.
This is my more constructive feedback :)
We've considered embedding Firebug Lite, since it gets you most of the inspect stuff you'd want for CSS editing. We may still add it.
Autocomplete is also high on the list of features, we just ran into some problems with CodeMirror 2.
1. Add a <meta> refresh tag to refresh the page once per second. Alternatively, with one line of JavaScript you can refresh even more frequently, e.g. immediately after "on load".
2. Bonus: Use a tiling window manager such as WMII, which automatically adjust the size of your editor window if you resize your browser window, and vice versa. That way, you get some kind of "split mode" and don't have to struggle with resizing multiple overlapping windows.
In summary, using auto-refresh + tiling window manager resulted a big increase in comfort for me. Not only during CSS development.
A bit off-topic, but related: If your target runs in the command line, the Unix command "watch" is a perfect auto-reloader:
watch --interval=0 your-app
watch --interval=0 php run-tests.php
It's a really great app. Forget about the GUI css editing view and switch to the code only view, and enjoy live updating, and x-ray inspection.
[1]: If you use a Mac.
1. They also provide a hosted CSS service with minimizing 2. They support scss
I even made a thread on reddit webdev about it yesterday: http://www.reddit.com/r/webdev/comments/itqy1/is_there_a_fir...
For my rails work flow, I don't really see the need for this product.
Besides, competing with Joel sounds like fun.
You hit refresh and those changes are gone.
I see the value of this for alot of one-person development shops or front-end devs that do a lot of client design work.
Your client calls you, "Hey, this thingy here isn't lining up right"
"click. click. publish"
"refresh the page"
"ohhh....how did you do that?" (Client amazed)
But, this is---for me---a one time thing, after I've made all the changes I want and things look great. It makes the CTRL-S, Alt-Tab, Reload procedure that was originally described only need to happen once, instead of lots of times in rapid succession.
We were thinking more like modeling putty or spackle for the web. Oh well :)
Slightly off-topic, why is there a 350k image file that's dynamically resized (smaller) and only there for decoration. Slowed page load considerably for me (I'm having problems with my connection mind you). Pretty but way off optimal IMO.
It would be even more useful to use it with localhost, however, since I develop on my local computer and then upload the finished code to the server.
https://github.com/ooyala/livecss
It's far simpler in that it just reloads your CSS continually. We use it all the time at Ooyala to put our favorite text editor and a web browser side-by-side and hack away.
Was looking forward to it just editing my css file I have stored locally on disk, so I could review the changes and commit to source control.
Vogue auto-reloads your css and you can still use your editor of choice (vim, emacs, textmate, notepad).
less.app auto-compiles your less whenever it changes. Similar tools exist for sass, stylus, and whatever other superset of css you prefer.
Doesn't seem to work as advertised in Chrome (dev channel).
Not bad, but I was never able to really get into CSSEdit, which is sort of what I imagine it to be similar to. A lot of missing editor features - or maybe it just not being vim.
My biggest gripe here is that I have to trust someone else to host my CSS. I just can't do that.
I guess I was hoping for a better CssEdit and it wasn't.
Its extra work, but you can publish the exported CSS with your site.
I did read that quote, though.
That said, if you could send us a bug report at webputty@fogcreek.com or via https://webputty.fogbugz.com/?pg=pgPublicEdit we'll take a look and see what we can do.
If you want to host it yourself, you can use WebPutty to edit it, and then use the export link (page with a green arrow coming out of it) to get out the compiled CSS.