Improve "design in the browser" capabilities. i.e. pushing CSS/HTML and maybe JS changes made in Dev Tools back to the source files without manual shenanigans in the middle.
I probably waste more time copying CSS / HTML tweak diffs from the browser back into the related source files than anything else with in browser dev tools. Due to the nature of 'losing changes' if I happen to hit refresh or if the page has some automatic polling mechanism I also tend to do this very often as some sort of manual 'save' action.
For example a server side implementation for Rails needs to understand the asset pipeline to know how the final file was created so it can work its way back to the correct file to save changes to. This also means you probably need source map style support for LESS and SASS also. Also to change HTML template files the server side needs to know how the page was constructed so it can find the correct partial / template to save changes to. Which is probably really hard depending on how much state based conditional rendering there is in your templates, maybe the server side caches the last response and associated state to work around this.
I'm the author of http://tin.cr, it tries to solve this exact problem for Chrome Devtools. (someone else mentioned this in this thread).
I've spent some time thinking about the problem. In an ideal world a standardized protocol to push changes to a server would be awesome. I think it's unrealistic though to expect widespread adoption especially for existing frameworks to add code just for doing this. For example, have you ever heard of WebDAV? It was thought up along the same lines and it's virtually dead now.
A better solution for now would be for source maps to tell you the full local path to the original source file. Yes, in a world where we all develop from Chromebook-like devices against files in the cloud, this won't work. We are a long way from that world at the moment.
When I try to install the extension I get the following error: "This application is not supported on this computer. Installation has been disabled." I have a Thinkpad T420s running windows 8 with Chrome Version 25.0.1364.152 m, any idea what's not compatible?
At the moment, it has two big drawbacks compared to those two
* It doesn't support re-compiling Sass, LESS, CoffeeScript, etc. on a file change.
If a browser supported PUTting the modified resource back up to the server, we'd be off to a good start. Server-side frameworks could then add functionality to split the modified resource back into the files that created it.
What about pre-processors (SASS, Less) or templating engines (ERB, Haml, Slim)? That would seem to be a huge task to "un-pre-process" an asset. Going backwards is immensely difficult. These are not easily reversible processes.
Instead, why not make something like IntelliJ/RubyMine/WebStorm/etc.'s Live Edit plugin a native part of the browser. Allow the asset pipeline to tell the browser it has changes available, rather than try to have it regurgitate all the processed assets. That would be relatively easy to add and very straightforward to implement.
Your Live Edit idea is a good one, but I think the assumption about "un-pre-processing" would be part of the pre-processing development tools understanding what was being pushed to them, therefore, the need for an open standard as has been alluded to above.
Love this idea, it would make source modification a piece of cake for every browser-maker to implement. To allow for compatibility, this feature could be activated only when a X-Source-Modification-Enabled (or something) header is present on the original page. The header's value could even be the (relative) endpoint to call!
The simplest middleware that would pop up would be a diff generator. But with source maps, web frameworks could track what exact source files were used.
A lot of these ideas could be supported via a proxy system. Something like charles http://www.charlesproxy.com/ on steroids. If you wanted to edit yahoo.com , you would checkout your local repo, have charles point to the local repo, and then your on the fly css/js fixes would go to your local repo. Yahoo's server wouldn't have to support it.
It seems to me, that with source maps in the browser, the browser should be able to PUT the original source file, with the correct file hierarchy. So, downloading assets.min.js, editing models/Foo.coffee, PUTting models/Foo.coffee.
Isn't that the wrong way around? Instead of pushing to the web server and let it figure out where to put the changes, change the local file (or file on the server, via NFS or such) and push the changes to the browser as well using tools such as swankjs  or, once it's ready, Kite  (that's my pet project).
For higher-level languages like Coffeescript or SASS, run a local compiler on the file or function so you can push the compiled code to the browser.
A nice side effect of this approach is that you can use a real code editor instead of the Notepad-style editor embedded in the browser.
In that regard, my #1 feature request for the Firefox devs is to finish and implement the remote debugging protocol  and, preferably, work with the WebKit devs towards unifying the two protocols.
I've been thinking about this issue a lot over the last year, and it's really as hard as you state (and then some). We ended up having to create our own supersets of the DOM/CSSOM in order to keep track of individual elements/selectors as they are created/removed/changed. I would be very surprised (and pleased) if Mozilla was able to implement this in a way that works without lots of additional/manual inputs. If you think JS source maps are a hard problem to solve, I'd say this one is at least an order of magnitude harder.
My thought is that this is really most useful for CSS and the transformations that SASS/LESS are capable of are relatively mundane in comparison to CS -> JS. In addition I only see this as a tool for development, not something that I would want running in production so you don't have the concerns over increased file size or still supporting minification that you do with source maps, assuming you want source maps in production for error reporting.
I can envision simply using structured CSS comments to pass the needed information to the browser. The browser only needs a structured pushing protocol, baseline comment format, probably handling of comments that indicate file boundaries (used for pushing to the correct resource) and a 'plugin api' to allow plugins to parse other comments in a meaningful way, SASS/LESS could provide a 'Dev tools' plugin to parse the comments and support whatever editing features they wanted. They would also have to support generation of the comments in the preprocessor.
The important bit is a standardized pushing protocol, a standardized way to provide additional mapping information and a standardized 'plugin' style system to allow things like SASS to add to dev tools additional editing support.
Just one theoretical approach, still a ton of work, but I really think there is a lot of developer time spent dealing with this issue so it may well be worth it.
Indeed the ecosystem and support around source maps isn't super easy in total, but I wouldn't call any particular point in isolation particularly difficult. It's just that there is quite a few of them.
Not to mention dragging over text to select it usually results in the entire HTML fragment getting destroyed when Chrome decides that you're actually attempting to drag the text to move it somewhere else.
> It is also broken in that when you do this Chrome rebuilds all the sub elements of what your editing so if there were event hooks or anything like that on the elements they will be gone.
This may not be completely true. In Edit As HTML mode every effort is made to retain the original elements. If you move some tags to another location, the real element (and handlers) should actually be retained.
Still for working on CSS, especially together with LESS or SASS it's quite pleasant.
Also it spams your Firebug console pretty bad.
I wrote a post about a year ago, to open up a discussion about what browser vendors can do to encourage rapid prototyping designing in the browser, by giving them tools for visual design that they would opt to use over software like Photoshop/Fireworks.
I'd love to see more tools that enable rapid prototyping, including the ability to craft CSS in a more visual manner.
Yeah, I think it would really set Firefox above everyone else is if it had its own web IDE (live WYSIWYG and code editing) built right in. It'd have to be a good one and you shouldn't try to force people to use it who don't want to. But I agree with other folks here: We all would kind of like the option to use something like that right in the browser.
It's not always possible to push changes back to LESS or SASS due to ambiguity at which level changes should be applied - if you're editing CSS values. The browser would have to display SASS or LESS in the inspector for what you're suggesting to work.
Chrome Canary (perhaps, the Dev channel, too) supports navigation to CSS selectors, property names and values (Ctrl-click them) in the corresponding Sass resources (the Sources panel). You can edit Sass and save it to disk (right-click the editor, "Save as...").
Now, if you have the "Support for Sass" experiment enabled, you'll see the "Auto-reload CSS upon Sass save" timeout setting to reload re-generated CSS files after "sass --watch in:out --sourcemap" (or equivalent) has updated them on the local disk.
Just being able to hold down a modifier key to move an element up down left and right would be great. You can do this in one dimension at a time at present but to be able to exactly place something would be a tremendous time saver.