And yet firebug is still the better console. Why do fancy things like tilt and this input box have priority over getting basic things like the console output under control?
I have a good reason for wanting this to land "earlyish" – to encourage the creation of more commands and full command access to the tools. If the command line is there and seeded with a few commands, people will start adding more (both for built-in tools and add-ons)
Agreed. They need to solidify the core console experience before putting in these extra features. It feels wrong having to install Firebug to get a decent element inspector / console when there's already one build in.
Vimperator and Pentadactyl have had something like this for some time and I've found it really useful. This feature of course goes a little above and beyond and it looks really exciting. Congrats Mozilla!
No, it does not. I've been casually following the development of GCLI (formerly known as "Cockpit") for a while now. It started as a debugging component of the Ace editor.
I've had so much hope in Ubiquity; let's hope this will get a nicer model for writing extensions and a "package" manager (I'd love something like Sublime2 has).
Firefox has a package manager, but Ubiquity didn't. Instead you embedded some meta tags in your webpage pointing out the Ubiquity extensions and following that page you'd get an installation.
I saw this and thought the exact same thing! Super excited to test it out upon release.
The other nice thing about FF for devs is that Chrome is a little too robust sometimes. I've had some egregious errors in my markup and Chrome still manages to do what I intended. But then it's broken on every other browser.
As far as I've experienced, anything that runs perfectly in FF runs perfectly in Chrome. But the reverse is not true.
They should both be using the html5 parser now, so "errors" should be well defined rather than browser dependent. Could be a bug in the implementation.
I do wish it had better integration with the web console though. It just seems strange when you pop-up the web console tab to have a JS prompt for entering javascript directly above a Browser prompt for controlling the browser.
It'd be nice if you could just go into a javascript entry mode on the browser prompt itself and see the output appear in the web console. Even something as simple as adding a javascript command where the argument passed into the command is javascript would be useful (perhaps someone could create an add-on that does this)
I'm loving this. It didn't seem like the most useful feature when I first heard about it, but it seems pretty well implemented. (Using the current nightly).
The pagemod and inspect commands seem super useful. I hate having to click around an inspector to find the thing I want -- "inspect #foo > h3" just seems so much easier.
If you have to interface with HTML or CSS directly and frequently while writing your application, then you want to make sure your HTML and CSS are super clean and maintainable. But, as PG has said before, HTML can be treated like object code! There was once a time when everyone had to write super clean and maintainable assembly code, but now you rely on a compiler.
Ever look at compiler generated assembly code? It's quite scary!
I find that a shortsighted attitude by PG. Web pages shouldn't be just a black box to present to the user. They should be structured documents that is flexible and malleable, so that the user or third parties can filter, adapt and enhance the content.
In this case it's naive redundant and inefficient object code. Tables and BR unless you're targetting pre-css browsers aren't really necessary. But I can be wrong. Anyway it's still more work and output that needed.
I can't figure out how to expand nodes in their inspector though. I had to bring up the source to find out what selector I should use. You should be able to do it both ways.
I don't understand what this does that can't already be done a hell of a lot better with the combo of firefox/firebug and the web developer toolbar?
What is the value proposition here? Perhaps I'm missing something but it just looks like a CLI interface over the top of JavaScript (as opposed to the GUI/CLI approach with firebug - which is a far more scaleable approach).
Is this thing going to need 1000 plugins installed within the plugin just to offer the same functionality as firebug?
I didn't understand the 3d view of web pages either and their GUI for their version of firebug is completely inferior (even though it looks fancier).
Looks are not everything.
Why has any of this stuff even been allowed to be prioritised over core browser performance and functionality.
It is a sad state of affairs to see what Firefox has devolved into compared to how it was in its glory days.
It would be nice if the command line supported a shell-like language that would allow you to easily parameterize and script these Firefox commands. So instead of running one command at a time, you could create files that ran commands sequentially, iteratively, etc. There could even be syntax that sets variables to the values of arbitrary JavaScript expressions (which would give you access to any DOM attribute, for example).
JavaScript, and most contemporary languages for that matter, would be pretty poor choices for such a use case. In particular, the concern here is the need for a language that is commands first and expressions second. It's an analogous situation to template languages. Consider Ruby's erb, for example. It's like you took Ruby, made String interpolation the default, and provided an escape hatch to get to full Ruby, not just the limited interpolation subset.
In the case of tcl, you invert C functions (or another language with C-style calling conventions) to be callable by default as commands. You then have the [expr ...] escape hatch to toggle back to the non-default programing mode, that gives you expressions, arithmetic, and other general purpose programming language features.
I'd really love to see a Tcl++ type thing. It would be super cool if applications could easily drop a console, like this one from Mozilla, into their app. Bonus points if it comes complete with a help system, UI, completion, etc.!
There's a bug in bugzilla for that. Also, I think you'll find that the whole issue of "common phone screen resolutions" is actually painfully complicated. The iPhones, for example, report their resolution as half the actual resolution (in each dimension).
You can resize the view port to whatever size you want, even in Firefox 15. The resize handle is a little dark in 15, though.
(This is way off the topic, but I am way too curious to ignore and couldn't satisfy my curiosity myself, so) Is the title of the article getting rendered differently (different font) than in other pages, in Google Chrome?
The FF dev tools offer a very different experience compared to Chrome. I am curious about the rationale between having different views for web inspector & debugger.
I am on Aurora/Ubuntu. The binding for the Debugger (Ctrl-Shft-S) doesn't seem to work for me and the Dev toolbar has no way to open the debugger view.
Not just programmers. AutoCAD has had this kind of interface always, and it is absolutely the best/fastest way for power users to make drawings. Integrating nicely textual commands, prompts and mouse usage works very well there.
Looking at proficient Excel users (I always claimed if my ex-wife got a basic course in operating systems principles, she would write one in Excel in a week :) = they tend to do everything by keyboard, and not in terms of shortcuts or chords, but entering commands. I also worked in a printing shop, and people working in layout program such as InDesign all day, would do everything by keyboard also - entering coordinates, align constraints, style names - and they were only slowed down by having to navigate all those little input boxes.
I also worked for a couple of years editing video in non-linear editing programs (Media 100, Premiere), and boy does this work get repetitive at times. I would have loved to have the ability to do things programmatically.
So, I think any power user could benefit from a command line driven interface in applications like those. Photoshop, non-linear video editing, computer aided design, layout, word processing, and even web browsing - I could see this option used by all kinds of people.
Neat, but "console clear" to clear struck me. A bit verbose, no? After years of "cls" (aliased on unix) I might not bother with the number of keystrokes required.
ctrl-l in most terminals will also clear the screen. Ideally they'd apply most of the features from GNU readline which IMO is the de facto source for 'standard' shortcuts on unixen.
It's a little bit confusing, but "console clear" is typed at the developer toolbar, not from within the console. The dev toolbar could hook into multiple things you'd want to clear, so that's why it's 'namespaced' that way.
You can just type clear() if you're focused on the webconsole.
I save ESC2J to a file and my "cls" is simply another file consisting of
cat file1
in my PATH. Only because sometimes printf or some other way to print ESC's might not be available.
The idea of starting up X11 so I can start the super-sized code complexity experiment that calls itself "Firefox", all just to get to a command line struck me. The fact they are calling the approach at Mozilla as "responsive design" I found insulting.
Are they in denial about just how big and complex Firefox is? This is not how you attain responsive design.
They identified the Mozilla home page as an example of responsive design, not Firefox. The feature being demonstrated with that example was the ability to "resize" the browser window to see how a page built with "responsive design" in mind would be rendered with, say, a mobile device with a smaller screen. Pretty useful, if you ask me.
Definitely. I just wish they would make some changes so that we can use the "70's style command line" more with Firefox. In other words, options and arguments we can pass to Firefox (the xulrunner app) via the Linux/BSD/OSX/Windows commandline.
For example if I have Firefox running in Xvfb it would be nice to be able to issue remote commands (an early version of Mozilla did have something like this if I recall correctly: -remote), such as the commands they are implementing for this "graphical command line". It would be convenient to easily dump screenshots to image files without having to run something like Crowbar.
Anyway at least they are starting to acknowledge that not everyone uses a mouse or prefers using a trackpad over hitting keys. I mean keys as tactile buttons, not images of onscreen keyboard, like the iPhone or iPad.
I fail to understand why this phrase is offending you so badly.
Let’s look at a more interesting example. The current design of
mozilla.org is a responsive design. I want to see how the headings
will show up on a smaller screen. If I’ve been working on the page, I
would likely know some of the IDs and structure used in the page, so
I could enter a command like:
"Responsive design" is a fairly established noun in the web design world. This is an article about new developer features in a web browser. Inside the context of the sentence, it's obvious they're talking about how a web page is constructed.
This is how web devs use "responsive design". It's being used by a web dev, in an article for other web devs. You might find it slightly confusing, but that's your problem, not theirs.
OS programmers and corn farmers use the word "kernel" to mean two different things, is this also a crime against nature?
the meaning is similar in both contexts you mention.
indeed if we asked someone who did not know what an "os kernel" was, they might think of the meaning they do know: e.g., the innermost part of a seed of a cereal or nut
and they might guess based on what they know.
have you ever heard the phrase "the computer program has become non-responsive"
e.g. a graphical web browser such as Firefox
Mozilla developers are not committing "crimes against nature". But nonetheless they do create some annoyances that millions of people have to endure. That's not the developers' problem, it's the users' problem. Some might search for solutions to the annoyances. Such solutions could be quite valuable to users. They might read things that are meant for "web developers" because that is where the annoyances come from. They are created by web developers.
Guess what, a responsive layout responds to media/container size variations, just like a computer program responds (or stops responding in your example) to user or system signals.
Why is everybody always black and white about everything?
Regular human language is multimodal, with words, explicit gestures like pointing, and body language layered over both of these (Though most geeks are deaf when it comes to the latter).
Which is easier, "Look at that [finger pointing at target]" or "Look at that strange thing on your 2 o'clock"? We have many options and we use what's best in each circumstance.
I would say it's more like this: a mouse is good for letting a user access features whose parameters they do not know off the top of their head. It allows the UI to act as a feedback loop between the human and the computer so that the human can incrementally guide the computer to do what they want. A command line is more effective when the user knows exactly what they want done and can recall immediately how to do it.
"Not knowing the parameters" can come in two main forms. The first is when the user simply may not have used the feature enough to be able to instantly recall all of the parameters needed and how they should be set. For example, a print dialog displays three or four commonly tweaked parameters to a user, and gives easy access to as many as several dozen more advanced parameters. This is far more useful than a CLI would be, except perhaps to a very small minority of users.
The other form is when you may know what the parameters are, but need feedback to choose them correctly. For example, resizing a window is well-suited to a mouse. Obviously you know that the four parameters are the height and width of the window, but few people can glance at their screen and say "Oh, I need this window to be 348 pixels wide now".
Could you explain what you mean? Seems to me that the mouse is best at expressing nouns - well, the things you see on screen...I'm obviously misunderstanding.
It maybe iconic, however, it's a horrible device for pointing from the point of health and ergonomics. And even with all the improvements, I've never seen a mouse handled more accurately than a proper trackball (see Logitech M570). Of course, that depends on the user.
It sounds extreme, by I personally believe that mice destroy the wrists of programmers - that's one of the reasons why we love programs and interfaces with tons of keyboard shortcuts - along with being faster, it's easier on the wrists.
In addition, good keyboard controls can make or break many programs. If you take a look at a program in the adobe suite, you'll normally notice two things. First, that using the program with the mouse generally involves awkward mouse manoeuvrings. However, keyboard shortcuts can eliminate 90% of this.
Third, do you personally recommend using a trackball? I've been experiencing some mild wrist pain lately and am looking for something better than a mouse.
Just look at this example side by side and tell me which one you prefer: http://i.imgur.com/tKr87.png