8 ms·

This is a big request: Improve "design in the browser" capabilities. i.e. pushing CSS/HTML and maybe JS changes made in Dev Tools back to the source files wit

by mbell 14y ago

This is a big request: 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. There have been a couple attempts to do this (http://www.cssupdater.com/ http://www.cssupdater.com/ or https://code.google.com/p/backfire/ https://code.google.com/p/backfire/). But, I'd really like to see a standardized protocol for pushing changes to the server such that server side frameworks can implement it appropriately. 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.

sambeau 14y ago
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.
- pbhjpbhj 14y ago
  >You can do this in one dimension at a time at present // In FF dev tools?
pixelcort 14y ago
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.
- btown 14y ago
  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.
  - mbell 14y ago
    My crazy idea is to just use git + some sort of source map style overlay on both ends to track changes and pass them back and forth.
- timdorr 14y ago
  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.
  - pedalpete 14y ago
    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.
- Ironlink 14y ago
  I'd be happy even if this was limited to the local file system! I've already got build and deployment set up, and modifying the web servers seems like a hassle.
- 14y ago
paulrouget 14y ago
A lot of people are asking for that. I guess sourcemap is (part of) what you're describing. We're working with Google on this, and we'll soon have builtin support at least for JavaScript (not HTML/CSS yet).
- kevinSuttle 14y ago
  Something like this, but for all (standard) source files, not just JS. http://remysharp.com/2012/12/21/my-workflow-never-having-to-leave-devtools/ http://remysharp.com/2012/12/21/my-workflow-never-having-to-...
possibilistic 14y ago
This is quite honestly the best new feature we could be given. It's not an easy task, but such a tool could save millions of man-hours. Mozilla guys: if you implement this--even partially--I'll switch back to Firefox in a heartbeat.
nailer 14y ago
+1. I can't even add an element directly in the Chrome dev tools - you can only edit an existing elements HTML and append something after it. My kingdom for a '+' button.
- mbell 14y ago
  You can, sort of. Right click on an element and choose "edit as HTML" and you can add whatever you want, granted it offers no reasonable formatting, its just a wall of text, not even tabs / line breaks. 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.
  - modarts 14y ago
    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.
  - ephemient 14y ago
    My workaround is to click an element, then type into console $0.appendChild(document.createElement('tagName')) but yeah, a [+] button would be nice…
  - deleted 14y ago
    [deleted]
  - nailer 14y ago
    It really seems like you didn't read my post before you replied to it.
  - paulirish 14y ago
    > 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.
the_french 14y ago
If you could somehow get sourcemaps for haml/sass/whatever it would make debugging css/html in the browser so much easier when working with serverside templates.
callmevlad 14y ago
(Disclaimer: I'm working on http://www.webflow.com http://www.webflow.com to try to solve this exact problem.) 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.
- Arelius 14y ago
  I'm not sure I would say that JS source maps are a hard problem to solve.
  - callmevlad 14y ago
    Fair point. However, it has taken years to get to where we are today (CoffeeScript just shipping support, limited browser support), so it doesn't seem to be an easy problem either.
    - mintplant 14y ago
      The delay in CoffeeScript support had to do with the design of the compiler more than anything. CoffeeScriptRedux [1] has had this in for quite some time. [1] https://github.com/michaelficarra/CoffeeScriptRedux/ https://github.com/michaelficarra/CoffeeScriptRedux/
    - Arelius 14y ago
      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.
- codegeek 14y ago
  I tried to enter my email address to get notification of your launch. Nothing happened when I clicked the button (using IE 8)
mnazim 14y ago
+1. I know it's not the main line of discussion here but I wonder how can this feature be leveraged for CSS preprocessors like Less/SASS where CSS reaching the browser is never edited directly. Edit: Gramer and language improvement.
nnnnnn 14y ago
If you're using Chrome, try out: http://tin.cr/ http://tin.cr/ It seems to be at least very similar to what you're looking for!
nc 14y ago
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.
- apavlov 14y ago
  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.
maufl 14y ago
Not perfect but what I did last time I played with backbone: * As I used sass, coffeescript and haml, I used guard (https://github.com/guard/guard https://github.com/guard/guard) to watch the source files and automatically compile them * Used serve (https://npmjs.org/package/serve https://npmjs.org/package/serve) to serve the directory over http, could use python -m SimpleHTTPServer too * Used live.js to pull for changes (http://livejs.com/ http://livejs.com/) As I said it's not perfect though, while CSS changes get applied transparently, changes in javascript will reload the page (you can also watch only for CSS changes). Still for working on CSS, especially together with LESS or SASS it's quite pleasant. Also it spams your Firebug console pretty bad.
ryanackley 14y ago
I'm the author of http://tin.cr 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.
- wamatt 14y ago
  Neat. Out of interest, how does Tincr compare to LiveReload or CodeKit?
  - ryanackley 14y ago
    At the moment, it has two big drawbacks compared to those two * The live reloading doesn't support full refreshes. You can only do live updating inside the running page. Chrome has built-in support for this. Works awesome for css. JavaScript support is a little flaky. * It doesn't support re-compiling Sass, LESS, CoffeeScript, etc. on a file change. I'm actively working on fixing both problems.
- spullara 14y ago
  This was the original intent of the PUT method in HTTP.
- cabbeer 14y ago
  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?
aquanext 14y ago
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.
- vsync 14y ago
  aaaaaaand then we'd be back to SeaMonkey. Not that there's anything wrong with that.
collypops 14y ago
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. Here's the post, for any who are interested: http://blog.colin-gourlay.com/blog/2012/03/how-can-browser-based-development-tools-better-aid-visual-design/ http://blog.colin-gourlay.com/blog/2012/03/how-can-browser-b...
julian37 14y ago
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 [1] or, once it's ready, Kite [2] (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 [3] and, preferably, work with the WebKit devs towards unifying the two protocols. [1] https://github.com/swank-js/swank-js https://github.com/swank-js/swank-js [2] https://github.com/jscheid/kite https://github.com/jscheid/kite [3] https://wiki.mozilla.org/Remote_Debugging_Protocol https://wiki.mozilla.org/Remote_Debugging_Protocol
math0ne 14y ago
Isn't this the kind of thing that webRTC will allow people to create?

by mbell 14y ago

sambeau 14y ago

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.

pbhjpbhj 14y ago
>You can do this in one dimension at a time at present // In FF dev tools?

pixelcort 14y ago

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.

btown 14y ago
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.
- mbell 14y ago
  My crazy idea is to just use git + some sort of source map style overlay on both ends to track changes and pass them back and forth.
timdorr 14y ago
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.
- pedalpete 14y ago
  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.
Ironlink 14y ago
I'd be happy even if this was limited to the local file system! I've already got build and deployment set up, and modifying the web servers seems like a hassle.
14y ago

paulrouget 14y ago

A lot of people are asking for that. I guess sourcemap is (part of) what you're describing. We're working with Google on this, and we'll soon have builtin support at least for JavaScript (not HTML/CSS yet).

kevinSuttle 14y ago
Something like this, but for all (standard) source files, not just JS. http://remysharp.com/2012/12/21/my-workflow-never-having-to-leave-devtools/ http://remysharp.com/2012/12/21/my-workflow-never-having-to-...

possibilistic 14y ago

This is quite honestly the best new feature we could be given. It's not an easy task, but such a tool could save millions of man-hours. Mozilla guys: if you implement this--even partially--I'll switch back to Firefox in a heartbeat.

nailer 14y ago

+1. I can't even add an element directly in the Chrome dev tools - you can only edit an existing elements HTML and append something after it. My kingdom for a '+' button.

mbell 14y ago
You can, sort of. Right click on an element and choose "edit as HTML" and you can add whatever you want, granted it offers no reasonable formatting, its just a wall of text, not even tabs / line breaks. 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.
- modarts 14y ago
  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.
- ephemient 14y ago
  My workaround is to click an element, then type into console $0.appendChild(document.createElement('tagName')) but yeah, a [+] button would be nice…
- deleted 14y ago
  [deleted]
- nailer 14y ago
  It really seems like you didn't read my post before you replied to it.
- paulirish 14y ago
  > 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.

the_french 14y ago

If you could somehow get sourcemaps for haml/sass/whatever it would make debugging css/html in the browser so much easier when working with serverside templates.

callmevlad 14y ago

(Disclaimer: I'm working on http://www.webflow.com http://www.webflow.com to try to solve this exact problem.) 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.

Arelius 14y ago
I'm not sure I would say that JS source maps are a hard problem to solve.
- callmevlad 14y ago
  Fair point. However, it has taken years to get to where we are today (CoffeeScript just shipping support, limited browser support), so it doesn't seem to be an easy problem either.
  - mintplant 14y ago
    The delay in CoffeeScript support had to do with the design of the compiler more than anything. CoffeeScriptRedux [1] has had this in for quite some time. [1] https://github.com/michaelficarra/CoffeeScriptRedux/ https://github.com/michaelficarra/CoffeeScriptRedux/
  - Arelius 14y ago
    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.
codegeek 14y ago
I tried to enter my email address to get notification of your launch. Nothing happened when I clicked the button (using IE 8)

mnazim 14y ago

+1. I know it's not the main line of discussion here but I wonder how can this feature be leveraged for CSS preprocessors like Less/SASS where CSS reaching the browser is never edited directly. Edit: Gramer and language improvement.

nnnnnn 14y ago

If you're using Chrome, try out: http://tin.cr/ http://tin.cr/ It seems to be at least very similar to what you're looking for!

nc 14y ago

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.

apavlov 14y ago
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.

maufl 14y ago

Not perfect but what I did last time I played with backbone: * As I used sass, coffeescript and haml, I used guard (https://github.com/guard/guard https://github.com/guard/guard) to watch the source files and automatically compile them * Used serve (https://npmjs.org/package/serve https://npmjs.org/package/serve) to serve the directory over http, could use python -m SimpleHTTPServer too * Used live.js to pull for changes (http://livejs.com/ http://livejs.com/) As I said it's not perfect though, while CSS changes get applied transparently, changes in javascript will reload the page (you can also watch only for CSS changes). Still for working on CSS, especially together with LESS or SASS it's quite pleasant. Also it spams your Firebug console pretty bad.

ryanackley 14y ago

I'm the author of http://tin.cr 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.

wamatt 14y ago
Neat. Out of interest, how does Tincr compare to LiveReload or CodeKit?
- ryanackley 14y ago
  At the moment, it has two big drawbacks compared to those two * The live reloading doesn't support full refreshes. You can only do live updating inside the running page. Chrome has built-in support for this. Works awesome for css. JavaScript support is a little flaky. * It doesn't support re-compiling Sass, LESS, CoffeeScript, etc. on a file change. I'm actively working on fixing both problems.
spullara 14y ago
This was the original intent of the PUT method in HTTP.
cabbeer 14y ago
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?

aquanext 14y ago

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.

vsync 14y ago
aaaaaaand then we'd be back to SeaMonkey. Not that there's anything wrong with that.

collypops 14y ago

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. Here's the post, for any who are interested: http://blog.colin-gourlay.com/blog/2012/03/how-can-browser-based-development-tools-better-aid-visual-design/ http://blog.colin-gourlay.com/blog/2012/03/how-can-browser-b...

julian37 14y ago

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 [1] or, once it's ready, Kite [2] (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 [3] and, preferably, work with the WebKit devs towards unifying the two protocols. [1] https://github.com/swank-js/swank-js https://github.com/swank-js/swank-js [2] https://github.com/jscheid/kite https://github.com/jscheid/kite [3] https://wiki.mozilla.org/Remote_Debugging_Protocol https://wiki.mozilla.org/Remote_Debugging_Protocol

math0ne 14y ago

Isn't this the kind of thing that webRTC will allow people to create?