Live data from Hacker News

Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

news.ycombinator.com

181–190 of 360 posts

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#181
post #60

I'm glad you asked! This is a good time for me to bring up something I wrote two years ago: http://news.ycombinator.com/item?id=2024164 I really wish browser makers would do this! Mozilla can lead the way. I am going to post it here for ease of reference: 1) I propose a simple mechanism to guarantee that a resource located at a certain URL is always the same. Similar to how we have https:// blabla, and the user agent…

> 1) I propose a simple mechanism to guarantee that a resource located at a certain URL is always the same (...) You are reinventing ETags.

ETags do not have a built-in system to verify arbitrary hashes of the content from different authorities.

Actually both https and httpc rely on authorities and trust. It's an interesting proposal!

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#182
post #90
post #71

Earlier quoted context omitted.

Firebug has a "disable built in tools" feature that prevents Inspector from loading already.

Btw this is done by opening about:config and setting devtools.inspector.enabled to false

Firebug key is "extensions.firebug.hideDefaultInspector"

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#183
post #76

Personally I find it annoying that is displayed as . I never understood why this is.

This creates separate click areas for "change the name of this tag" vs "add an attribute". I find myself adding classes and attributes often, so I'm a proponent of .

Chrome's tools only show , and the only way to add a class requires two clicks on "tag", and then a click on ">", which is really wonky.

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#184

Earlier quoted context omitted.

(Disclaimer: I'm working on 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…

I'm not sure I would say that JS source maps are a hard problem to solve.

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.

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#186
post #73

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…

(Disclaimer: I'm working on 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…

I tried to enter my email address to get notification of your launch. Nothing happened when I clicked the button (using IE 8)

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#187

Earlier quoted context omitted.

I'm not sure I would say that JS source maps are a hard problem to solve.

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.

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/

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#188
post #73

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…

+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.

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#189
post #169

Thanks for asking. Here are some ideas associated with their pain points in no particular order. 1) I'd like to environment to feel more "dev" when I'm in the debug tools. Ctrl-L should clear the console, C-a should get to the beginning, etc. Ideally, there should be standard console mode (Vim-like, Emacs-like) so programmers can feel more at home while in the firefox console. There should also be a way, maybe a json…

I'd also like to see more readline-like behavior. It's hard to stop entering C-p and C-n to explore the command history, which currently bring up a print dialog/new window.

Currently I hack some limited readline functionality with Pentadactyl, which is probably appropriate given the potential invasiveness of that change. But if we're talking about dream FF dev features-- there you go.

Re: Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?

#190
post #73

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 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.

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.
Post reply on HN