Loading Profile...
Integration of Safari's inspection window into Coda?
Would it be practical to use WebKit/Safari's built in inspector pane in lieu of Coda's less feature-rich JS console & DOM inspector? Perhaps folding-in Coda's console.log support? It's already possible to use the pane in Coda... but I suspect there would be a better way to integrate it? Just a thought! :-)
I’m excited
10
people like this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
The best point from everyone
-
This type of inspection would be a great improvement, but I would like more to have something like CSSEdit. I remember watching a presentation on Cabel Sasser's blog about how Panic tried to work out an agreement with MacRabbit on CSSEdit but it eventually fell through. Perhaps this is the reason that the DOM inspector in Coda is (relatively) featureless?
Sometimes it's convenient to simply explore the hierarchy of the DOM tree, which Coda's DOM inspector does well, but it doesn't have all the features I would like. The two features I would like to see the most are exemplified in Firebug and CSSEdit 2.6.
In Firebug, the DOM inspector takes you to the code for that element in the HTML code. Also, like the Safari DOM inspector, it shows you which CSS rules are applied to the element. Again, Safari has this, but I like Firebug's better because it doesn't require right-clicking elements to view their location in the DOM tree. You click on an element, and you can quickly see its location in the DOM hierarchy, or the HTML code from which it was generated.
CSSEdit has more what I'm looking for in an integrated environment like Coda. The entire core feature of CSSEdit is to rapidly style web pages without having to refresh the preview. The crux of this is some new features added in CSSEdit 2.5, which allows you to use the X-ray tool (just an inspector) to click on an element, and see which style rules in the actual CSS document are applied to it. Imagine this: two panes in Coda, one of the page preview, and one of the CSS file. You can click on elements with the inspector, and see a panel (Function viewer, maybe?) with a list of the CSS rules from the CSS document that are applied to the element. Clicking on one of those symbols takes you to the CSS rule in the CSS document itself, rather than requiring you to hunt your way through the CSS file.
This would enhance the amount of integration between each of Coda's panes. Coda is phenomenal in for its integration of its constituent apps into one window, but there's very little in the way of integration between those "apps". I think there is a lot of room to streamline CSS development in Coda. Currently, CSSEdit is the only web development app that I use aside from Coda. This type of integration could be expanded by allowing the user to pick a preview page for JavaScript or CSS (read: drag and drop, I'm aware I can type in a URL). If I drag and drop an HTML file from the file browser onto the preview pane, I would like for it to open that page as preview, not open the file in a new tab. It seems silly to have the preview pane by default just spilling the contents of the JavaScript or CSS file into the preview!
Thanks for the great software, and I'm excited for Coda's future!
I’m confident
4 people think
this is one of the best points
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?This is an awesome idea, as I love WebKit's inspection window. All Coda has is a DOM inspector and a JS error log.
Panic: if you did this, there would be world peace, parades, and unicorns. Pretty-please? :)
I’m excited
-
Inappropriate?This type of inspection would be a great improvement, but I would like more to have something like CSSEdit. I remember watching a presentation on Cabel Sasser's blog about how Panic tried to work out an agreement with MacRabbit on CSSEdit but it eventually fell through. Perhaps this is the reason that the DOM inspector in Coda is (relatively) featureless?
Sometimes it's convenient to simply explore the hierarchy of the DOM tree, which Coda's DOM inspector does well, but it doesn't have all the features I would like. The two features I would like to see the most are exemplified in Firebug and CSSEdit 2.6.
In Firebug, the DOM inspector takes you to the code for that element in the HTML code. Also, like the Safari DOM inspector, it shows you which CSS rules are applied to the element. Again, Safari has this, but I like Firebug's better because it doesn't require right-clicking elements to view their location in the DOM tree. You click on an element, and you can quickly see its location in the DOM hierarchy, or the HTML code from which it was generated.
CSSEdit has more what I'm looking for in an integrated environment like Coda. The entire core feature of CSSEdit is to rapidly style web pages without having to refresh the preview. The crux of this is some new features added in CSSEdit 2.5, which allows you to use the X-ray tool (just an inspector) to click on an element, and see which style rules in the actual CSS document are applied to it. Imagine this: two panes in Coda, one of the page preview, and one of the CSS file. You can click on elements with the inspector, and see a panel (Function viewer, maybe?) with a list of the CSS rules from the CSS document that are applied to the element. Clicking on one of those symbols takes you to the CSS rule in the CSS document itself, rather than requiring you to hunt your way through the CSS file.
This would enhance the amount of integration between each of Coda's panes. Coda is phenomenal in for its integration of its constituent apps into one window, but there's very little in the way of integration between those "apps". I think there is a lot of room to streamline CSS development in Coda. Currently, CSSEdit is the only web development app that I use aside from Coda. This type of integration could be expanded by allowing the user to pick a preview page for JavaScript or CSS (read: drag and drop, I'm aware I can type in a URL). If I drag and drop an HTML file from the file browser onto the preview pane, I would like for it to open that page as preview, not open the file in a new tab. It seems silly to have the preview pane by default just spilling the contents of the JavaScript or CSS file into the preview!
Thanks for the great software, and I'm excited for Coda's future!
I’m confident
4 people think
this is one of the best points
3 Comments Add a comment
This is one of the best points
-
Well said! After an investment in Coda, I find myself constantly going back to my "old" tools - Safari and CSSedit, because they're just hands down better at what they do. Making it worse, I can't seem to automatically update the server from Coda, something YummyFTP did on every save of a document.
A big issue with previewing/debugging/editing is, I think, the one-window design of Coda. Good for some things, terrible for others. You can edit code, or preview, but never at the same time, unless you create a new window, with the full UI, file manager, etc. Completely unnecessary! At the very least, implement panes so we can edit CSS code and preview at the same time! Same goes for debugging, previewing, and editing HTML/JS. -
Thanks for the comment! I agree, some tools are more apt for specific things than Coda. However, I don't really see Coda's FTP philosophy as a hindrance. For one, if you're working on a file that is stored on the remote server, it will update automatically. However, it's merely a difference in workflow. If you're working on local files, you should be either previewing locally, or previewing from a web server running on your local machine. That's why Coda gives you the option to choose a local preview file--otherwise, it would be impossible to preview PHP, Rails, or Django code locally, as they must be processed by the server. Secondly, you should have a separation between your production, staging, development, and local environments. Even if you don't have the full stack, you should have a local environment to work on changes and finalize them before pushing them out to the live server.
-
Thanks for the comment! I agree, some tools are more apt for specific things than Coda. However, I don't really see Coda's FTP philosophy as a hindrance. For one, if you're working on a file that is stored on the remote server, it will update automatically. However, it's merely a difference in workflow. If you're working on local files, you should be either previewing locally, or previewing from a web server running on your local machine. That's why Coda gives you the option to choose a local preview file--otherwise, it would be impossible to preview PHP, Rails, or Django code locally, as they must be processed by the server. Secondly, you should have a separation between your production, staging, development, and local environments. Even if you don't have the full stack, you should have a local environment to work on changes and finalize them before pushing them out to the live server.
-
Inappropriate?I prefer Firebug implementation also
-
Inappropriate?You can simply right click and select "Inspect Element", and the window is there.
