This is more of a "hacker" tip than something for web developers but "Show Page Source" will show you the full raw HTML for any page. Be careful where you use it though as it is illegal in some states.
I think it was meant as a joke reference to a recent news piece where a state agency website had raw personal data in the source code, and 'view source' would show sensitive data (teacher data - names, social security numbers, etc).
I live in Missouri, in the deep Red Ozark Mountains in the SW part of it and I shared an article on that on FB in a local group.
Our Governor really blew it on this one. Folks here will generally stand by their GOP Party and for the most part they never talk about Parson here but this really pissed them off.
I was surprised by the comments and the number of them. They are pissed about the incompetence of those who built the website and quite a bit more so that Parson would try to charge the journalist with a crime for finding it.
Isn't it a little strange that these red-staters don't even know their own name?
The lowercase "party" in my mind removes the redundancy as a class description for the collection of all political parties rather than as part of an abbreviated name for the one in question.
Unlike the "P" which stands for Preproccessor, in PHP.
Edit: whoops, they are both capitalized. Too bad I wrote with an ink pen.
Very annoyingly it doesn't show you the full HTML for the page you're viewing. It does a new HTTP request (I think without cookies at least in Firefox) and shows that. This means you need to use inspect element if you have dynamically generated HTML either from JS or non-idempotent server sides.
"Overrides allow you to store local copies of remote scripts and override them when the page loads. This is great if you have, for example, a slow build process for your whole application and you want to try something out. It is also a great tool to replace annoying scripts from third party web sites without having to use a browser extension."
Overrides are useful not just for "developers". Why is this option hidden away in "Developer Tools".
The biggest "secret" not mentioned here is keyboard navigation. It is incredibly cumbersome to operate "Developer Tools" on a small form factor computer without a mouse.
Here is one solution: In Chrome's, F12 to open Developer Tools, then Ctrl-P then type ">".
Then can scroll all available commands using Up/Down or start typing and use autocomplete to search for commands. Whether this is faster and more effective than pointing+clicking/tapping on tiny screen areas, ticking/unticking tiny check boxes and scrolling around in tiny menus is a question for the reader. Talk amongst yourselves.
For example, to navigate to Overrides, the key sequence is F12,Ctrl-P,">","des",Enter
This all applies to Edge, too. I am also a huge keyboard fan and user and the command menu is incredibly useful. As to bringing Overrides to the main browser interface and not only to developer tools, I'd love to do some more research on that. We are not seeing much use of overrides at all and they are a pretty niche use case. That said, I see far too many people and companies resorting to browser extensions where a snippet or override could do the trick. I guess one of the issues is that they are limited to the user/machine right now and you can't share them in a team.
That said, we have some ideas in the making to bring command menu functionality to the browser URL bar. We'll see how this goes down with non-developer end users. As a interesting fact , which I did mention in the talk, we had a real issue with people accidently hitting F12 and getting developer tools without wanting them and we're still getting daily feedback that people are utterly confused as to what happens to their browser when they open.
"As to bringing the Overrides to the main browser interface and not only to developer tools, I'd love to do some more research on that."
To a curious user who is not a "developer", "Developer Tools" is just more browser options. What tech companies want to everyone to forget is that any person who has no interest in working as a "developer" for a "tech" company can use the exact same software including all of its features as so-called "developers". Whether they choose to do that is their business and their choice, not the tech company's. I know this topic has come up before on HN, many years ago, that using names like "Developer Tools" just drives people away who are not interested in being labeled "developers". Even "Web Development Tools" would be better.
Chromebooks, where the browser is supposed to be seen as the OS (even though it isn't), are another example. There is an artificial classification of people into the categories "user" or "developer" (no such thing as "power users" or anyone who would care to understand how the computer works but not care to invade people's privacy for money). "Developer mode"? Seriously? Making a computer with storage space deliberately scant enough that the buyer is compelled to use "cloud storage", so the tech company can collect more data. Meanwhile "smartphones", a much smaller form factor, sold by the same company have over 10x the storage. Shameful and manipulative.
By operating under the artificial distinction of "developer" vs. "user", then all the stuff that users really should know about, but that the tech company hopes they won't know about, can be communicated under the assumption that the only people who would read it are "developers". Thus, zero effort needs to be made to try to tell "users" how this stuff really works. This arguably makes for more naive, carefree users and makes it easier for the tech company to collect data and serve advertising. And we know that is not what "users" prefer.
"That said, I have seen far too many people and companies resorting to browser extensions where a snippet or override would do the trick."
Right. Extensions, unless self-authored, usually require surrendering control to third parties. Tech companies like that. It is common on HN to see some extension author telling us how many inquiries they get from people looking to (secretly) buy their extensions as a means to get access to access to (unknowing) users. Using extensions, it is less likely that a user will learn anything whereas they would definitely learn from writing snippets and editing their own copies of others' scripts to use as overrides.
Eh, you can't reconcile 'nobody reads all that text on dialog boxes' with 'using names like "Developer Tools" just drives people away who are not interested in being labeled "developers"'. I seriously doubt people care all that much about what menu labels say, as long as they are roughly descriptive. What next, making some menu items pink because women are shown to be less likely to press on them? This way lays madness.
You have a good point about not needing to explain how all that stuff works, because developers are expected to seek out and read documentation and tutorials.
Making tools more accessible in that sense necessarily makes them less powerful, and there is too much dumbing down going on as it is...
Is it possible by now, to assign custom shortcuts in chrome or edge dev tools? Then you could be even faster for your regular commands with keyboard navigation.
It was discussed endlessly in chrome and I stopped following.
I ended up tweaking dev tools by hand (you can just open dev tools for chrome dev tools) - but stopped doing so, because of breaking update changes.
Here's a really obscure one which I've never heard anyone mention, except the first time I heard about it:
In the JS console:
$0
is a reference to the currently-highlighted element in the DOM Inspector (at least this is the case in Firefox, Chrome and Edge, haven't tried others).
Very handy for quickly evaluating or operating on an element you're looking at :)
Author here.
There are even more. $0 is only the current one, but you also have $1 to $4 as a history of the last ones/ I like that $_ is a reference to the last result of what you did in the console.
I documented most here:
https://docs.microsoft.com/en-us/microsoft-edge/devtools-gui...
Nice, that's great to know! Thanks for capturing them on that page. BTW I've followed you on Twitter for years. Always lots of neat tips and interesting topics -- thanks for that! :)
In a similar vein you can right click on any logged value that's pretty printed in color and save it to a global variable to play around with. (console.log("foo", foo) works with this, console.log("foo"+foo) doesn't)
$() and $$() are handy but very annoyingly the first is overridden by any website that installs jQuery globally. IIRC in chrome you then use x$()? I always have to look it up.
$() is obviously inspired by jquery itself, but it has a slightly different semantics than jquery, so ironically jquery can override it.
I am not sure what x$ is.
However, what was not in the article, you can also you $x("/something") for xpath. That can be useful, because for some queries, xpath is easier than CSS selectors, and it is actually far more powerful (except that nobody really knows xpath nowadays).
The $x thing is actually script around `document.evaluate(xpath, document.evaluate, null, XPathResult.ANY_TYPE, null)`, but good luck remembering how to use that stuff... I can never write doc.evaluate on the first try
Not specific to developer tools, but definitely handy for using console.log etc: in JS, an expression can be any comma-separated set of expressions. Every sub-expression is evaluated, the last sub-expression’s value produces the value of the full expression. So for example:
const add = (a, b) => (
a + b
);
produces the same return value as:
const add = (a, b) => (
console.log('adding', { a, b }),
a + b
);
The log call will be evaluated, producing the desired side effect, its return value (`undefined`) is ignored, and otherwise add behaves the same as before.
This can save 100s of paper cuts where you might otherwise rewrite a function or some other expression into a block of statements—in the arrow function case requiring curly braces and a return statement.
Caveats:
- sometimes you need to wrap the expression in parentheses to avoid syntax errors
- it does not work with debugger statements, which have no expression equivalent
> in JS, an expression can be any comma-separated set of expressions. Every sub-expression is evaluated, the last sub-expression’s value produces the value of the full expression.
console.trace() looks nice, except it doesn't work for async functions (i.e., functions that call each other through an event loop), which is how many function calls happen to be coded in practice.
It doesn’t work for callback-based async (including native Promises, but some libraries like Bluebird can help). But it does work for suspending async functions (native async/await, generators)! This also applies to Error#stack and debugger call stacks.
I’m actively moving some projects I inherited from Promise APIs to async/await for this reason.
Native async/await functions use generator functions under the hood, which are an implementation of coroutines. Like all fully-fledged coroutine implementations, generators can suspend execution while preserving the stack by yielding control (hence the `yield` keyword). This requires interpreter (e.g. V8) support.
Desuguared Promise.then can't suspend the stack like that as a normal JS thread must run to completion and cannot yield to the scheduler; instead every call to `.then` pushes the new closure onto the event/microtask queue.
The difference is that an async function suspends on await, and continues to be active in the call stack until it returns. It doesn’t preserve the stack so much as continues to be on the stack. A Promise-returning function returns the Promise value synchronously and then/catch/etc continue from a new stack where they’re resolved.
it'd be nice if there's an async-trace feature, where you get a (ascii?) visualization of the graph of async calls, if given a promise.
It'd have to be able to reach deep into the core of the vm to find out where the promise was created (which might be lost if that info wasn't recorded i suppose), so may not be possible.
> Many things heralded as the best thing since sliced bread in presentations and video tutorials are hardly every opened, let alone used.
This reminds me of something I heard once... that the first half of Portal (the video game) is basically a giant playable tutorial, and that a lot of video games start off with a tutorial disguised as gameplay, and that this is actually pretty pleasant.
The world's gotten pretty good at crafting tutorials disguised as gameplay. Could we do this with dev tools? Has anyone tried to make "VSCode: the game"?
Maybe "tip of the day" popups could be restructured as minigames?
Possible hurdles I can think of off the top of my head:
- a fancy tutorial probably runs into exactly what the author mentions on the next few lines: that adding more documentation doesn't fix things, because most people don't go to the documentation.
- In a game it's very easy to tune the tutorial to what you'll later encounter. A dev tool tutorial... every dev's needs are different. I imagine you'd have to structure it as a tutorial for "core functionality", plus separate tutorials for each extension.
- In the game context, I'm expecting to do certain actions repetitively. This has the side-effect of refining those skills. In a dev context, repetition is often considered a smell (though, I'd argue even in dev work we pick up a lot of little katas without thinking about it).
- Harping on repetition some more... what about the debugging tools that I only need to use once in a blue moon?
Has anyone ever written a set of documentation solely by asking questions on StackExchange? I mean make an outline of exactly how you would do written docs, but pose each one of the sections in the outline as questions. You could have another user designed to be an expert for this app answer the questions.
I'm not trying to game SO for points. I'm trying to head off the fact that nobody reads docs, but will head straight to a web search.
> I'm trying to head off the fact that nobody reads docs, but will head straight to a web search.
Is that why everyone loves SO? I've found it so hard to get questions answered on there. Most answers I find are just regurgitations of documentation, which is just annoying when you are asking about an obscure edge case.
I can't speak for everyone, but...sometimes it's easier to ask a question in a search bar than heading off to the docs and navigating their menus in order to find where in the docs you need to be looking. Maybe SO links come up first, maybe the actual docs do. However, with the back-n-forth exchanges, it is sometimes easier to grok an SO link than dryly written docs. The first example jumping to mind is AWS related questions.
The search bar is more convenient, and sometimes the docs are hard to find. That said, I find a lot of docs are quite easy to read, and often have to take the second step of omitting SO or otherwise restricting the search to docs and kicking myself.
Some documentation is wonderful. I try to use documentation quality as an important consideration when choosing software.
The AWS docs have big issues, but they are similar to the big issues with SO - it's so easy to find old documentation. Also, they are horribly organized.
The web search should ideally show the relevant section of the docs as the first hit.
Actually, it often does for me.
Good search is hard, and adding search to your docs, especially with some fuzziness like synonyms and common typos, is not trivial, unless you defer it to web search.
Is there any way to "narrow" the Elements tab to displaying only a portion of the HTML? For instance to narrow to the "div#content" element such that said element appears as the root of the Elements tab, decluttering the view from the parts of the page irrelevant to what one is working on.
I've been looking for something like this for ages, clicked on the link with enthusiasm thinking it would be a general guide. Whilst the article is I retesting I'm still looking for that cross browser article.
Great article. I might be a bit late to the scene, but to add to the first section, there are also `console.time`, `console.timeLog`, and `console.timeEnd`. Very handy!
Here’s one: in chrome dev tools, hidden behind two menu clicks, you can enable additional tabs including “media”. This is, afaik, the only way to get error messages from video decoding
No, this isn't "a technical PR blog post promoting Windows Edge". It is, as explained in the first sentence, a write-up of a presentation I've given at an event. It is on my personal blog that I've maintained since 2006 and very much my own message.
> This is a talk that I’ve given at CityJS this September. I am a principal product manager for developer tools in Microsoft Edge and these are things I encountered during working on the tools, documenting them and going through user feedback.
Microsoft Edge is a browser based on Chromium and we joined the project quite some time ago, fixing hundreds of bugs, making the developer tools themeable, localisable and accessible to assistive technology. All of these changes have been submitted back to the Chromium core, so that Chrome, Brave and all the other browsers based on the same open source project also benefited from that. We work closely with the Chrome team and share a lot of ideas and plans for the future of the Chromium platform.
We differentiate in the UX of the developer tools, much like all Chromium based browsers differentiate in the interface for the end user.
I spent about 10 hours on the presentation and this morning about 3 hours turning the slides into this blog post. If my goal were to promote Edge, I could have done a much simpler, shorter and to the point post.
If you read the article, you might realise the things we're adding exclusively to the Edge devtools based on user feedback and demands, the focus mode and in-context explanations being one of the efforts, and the deep integration with VS code being another one.
As to whether these things are useful, I think I pretty clearly explained that this is exactly what we'd like people to tell us. Which is why there are several ways to contact the team and provide feedback.
"No, this isn't "a technical PR blog post promoting Windows Edge". It is, as explained in the first sentence, a write-up of a presentation I've given at an event. It is on my personal blog that I've maintained since 2006 and very much my own message."
I am pretty sure, private blog posts promoting your day jobs work, are beneficial to your career as well (and I can imagine it is encuraged). And the language used, "We are open to your feedback and many of the recent changes to the tools are direct results from demands from outside developers" sounds definitely official.
"I spent about 10 hours on the presentation and this morning about 3 hours turning the slides into this blog post. If my goal were to promote Edge, I could have done a much simpler, shorter and to the point post."
And I don't think so, because many people still have a bias against edge, who would have just skipped reading it, if it would be plainly stated, edge only. So burying the promotion inside some general useful tips, combined with what awesome plans you might have for edge dev tools - worked apparently quite well for promotion, but not for clarity.
Basically, what I am missing, was a paragraph like this:
"Microsoft Edge is a browser based on Chromium and we joined the project quite some time ago, fixing hundreds of bugs, making the developer tools themeable, localisable and accessible to assistive technology. All of these changes have been submitted back to the Chromium core, so that Chrome, Brave and all the other browsers based on the same open source project also benefited from that. We work closely with the Chrome team and share a lot of ideas and plans for the future of the Chromium platform."
And more importantly: to differentiate what of your "secrets" work everywhere. And what works only with edge. A normal technical blog post would have covered this, as they are usually neutral.
You are not neutral (and you do not have to be), but just tell me, why edge is superior and what does it do better. But maybe do so clearly.
"If you read the article, you might realise the things we're adding exclusively to the Edge devtools based on user feedback and demands, the focus mode and in-context explanations being one of the efforts, and the deep integration with VS code being another one."
So I did read most of the article, but this is my criticism. Finding out what of your features were edge only, was very hard - as it was not plainly stated. And if you read the comments here, that kind of confirms it. Lots of confusion and general web dev tips mixed with edge only stuff. That limits its usefulness.
I am curious why you can edit Edge dev tools with Edge. There is literally a part of the article where I show that this is possible with a screenshot showing it on my Mac.
I could not "just" edit it like I am used to from chrome - but apparently had to activate a experimental setting. Which you did explain in a video. Not text. I read text.
I still want to understand the issue. The Sources tool is the same in Chrome and in Edge. And if you undock the devtools and you press CMD+Shift+I (or CTRL+I) on either Chrome or Edge you get a second DevTools instance to debug the first one. If you use a workspace, you edit files externally in either Edge or Chrome as they are the same thing. There is no difference in either of these use cases. What use case are you finding where it is different? I'm really confused.
"And if you undock the devtools and you press CMD+Shift+I (or CTRL+I) on either Chrome or Edge you get a second DevTools instance to debug the first one. "
Not for me on a vanilla edge instance. Pressing Ctrl + Shift + I closes the dev tools completly, no matter where the focus is. (on Win 10, german localisation, Edge 95.0.1020.40)
But it works like you describe (and how I know it) on a vanilla chrome dev instance.
So is there maybe some hidden setting, one needs to activate first?
Isn't the point of this article to highlight specific tools? A lot of technical PR blog posts do well on HN. Not as many as technical PR blog people wish they would, but still - if the post contains interesting information, that's what matters. Here's a past explanation about this, in case it's helpful: https://news.ycombinator.com/item?id=20186280, which was an answer to https://news.ycombinator.com/item?id=20186246 ("Is it acceptable to have unmarked advertisements on HN?").
There's also this guideline:
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
In general I do enjoy technical PR blog posts and also in this one I found interesting bits.
What disturbed me was, that the title said "web developer tools secrets", while in the text it is specifically microsoft edges web developer tools.
This style of language I do not like so much. There is too much agenda in it, in my taste. As this seem to imply, there are only one web dev tools - the ones that comes bundled with your windows OS. (Microsoft does have a history)
Now it seems, the edge dev tools are allmost identical to chrome dev tools, so I might have assumed more ill intent, than what was actually there, as most web devs use one or the other.
But it is still not clear to me, what of the posts information apply only to edge for example. What to chrome. And what would also work in firefox. All of them have web dev tools.
As far as my understanding goes (which may not be very far at all), the common base seems to be Chromium. When I want to debug an HTML source (like the one in the article), VSCodium offers me Chrome or Edge as the base browser (none of which I have installed). I wonder why Brave isn't in there, since it's also Chromium-based.
Oh, I think I understand now. You mean when you use the debugger in Visual Studio Code the target browser dropdown only shows Edge or Chrome and not Brave?
That is weird and I wonder if it has something to do that brave hasn't got the CDP methods turned on that allows other software to remotely control it.
In essence, the debugger spawns a new instance of the browser and controls it remotely from VS Code, much like automated test tools do. It would be interesting to hear from Brave if there is interest in showing up there, too.
Oops, seems my last sentence was badly worded. With “in there” I meant the set of browsers offered by VSCodium, not your article. Your article is fine and informative, except that the title makes it seem more general than it actually is.
You might be surprised how limited some otherwise very competent people's understanding of dev tools is. Console being such a primary example probably isn't an accident; tons of people don't know what it's capable of.
I suspect people don't RTFM because frankly there are so many Ms to R. It's overwhelming at times.
Many carpenters can get by without learning little tricks here and there while still being excellent carpenters overall. I think it's the same in software. We tend to focus on doing what we know best, and sometimes that means we skip the odd manual here and there.
Perhaps true. I would extend this to say that RTFM by attaining drips through blog posts that summarizes the M would lead to good competent developers over time, but this exclusive approach would create knowledge gaps (or “secrets”) that would make them excellent developers if they had RTFM otherwise.
Carpentry is an ancient profession, and still respected to this day. Though modern carpentry is a complex profession akin to engineering, it is colloquially viewed as simple enough for laymen to understand its concepts and tools.
Additionally, carpentry as a hobby is relatively popular both for its practicality and its relatively low bar of entry, with much room to develop and expand.
I personally like to find parallels between trades and crafts to help connect my thoughts and experiences to the more abstract world of software. I started my life in carpentry and joinery so it seems to be where my mind finds it’s foundations when thinking in systems and patterns.
In this case TFM is partly composed of >=1 blogs from >1 browser vendors in addition to properties associated with the underlying browser engine which most people don’t directly use or reference by name. No one has actually written T FM.
We'd love to know what we can do better. What are you missing at https://docs.microsoft.com/en-us/microsoft-edge/devtools-gui... ? We lately spent a lot of time re-organising the documentation to cover different use cases, like people wanting introductions or in-depth details getting different starting points. The documenation is even available on GitHub to post issues and ask for features: https://github.com/MicrosoftDocs/edge-developer
I feel bad if my comment came off overly critical. I did see the Edge dev tools docs and they’re substantially better and more thorough than what I’d seen before. I want to recognize that.
I’d need to spend more time looking through the docs to be specific, but the place my comment came from was seeing both Edge and Chrome dev tools docs with a lot deferred but not cross referenced to Chromium, and both having more depth in their respective blogs than dedicated docs.
Admittedly I became accustomed to referencing the various blogs rather than docs, because that’s where I’ve learned the most about the dev tools across the ecosystem.
I’ll definitely spend more time with the mainline docs and give feedback where I think there’s room to improve. Thank you
That’s not true. There are great sources of documentation for anything you use. Scoped down to the specific topic and it doesn’t have to be found in a blog post or stackoverflow answer. Those are the sources that just beat the SEO game.
I want to learn all there is to know about JS. Which/what manual should RTFM? Should I read it front to back completely before attempting to write my first bit of code? Before writing any php, should I read every single word written on php.net?
Docs for programming languages are not written like a book to be read starting with the first page through to the last. Kind of like the bible.
Exploratory clicking on MDN can help. For the language itself, a recent official ES paper. When learning yet another programming language seriously, I’m usually skimming through the standard library symbols to see the spirit of it, because stdlib/lang creators usually know both design and rationale. I also clicked through all of the tabs in a developer console in my browser to see what’s useful there. I doesn’t take up much time, and is much more complete. Personally I’ve never understood the value of these blog posts, because their appearance on your horizon is erratic and unpredictable unlike documentation and exploration, e.g. this article brought nothing new to me despite I’m only 2-3 years into javascript/web (out of much longer swdev career which taught me to educate actively), but ymmw.
My absolutely respectful but straightforward advice is: stop relying on blog posts, just go and click where you didn’t. It’s not a secret sacral knowledge, it’s you being anxious of unknowns of your development tool and of scary docs which are actually your friends.
You should read the manual for the language features and debugging tools you use most. Don’t assume you know everything about Console.log because you use it all the time one way.
Thanks for answering with an ambiguous answer. Of course I don't know everything about anything. That's why search engines were invented. I mean, even O'Reily doesn't know everything else there wouldn't be other authors!
So, which manual am I reading for learning everything there is possible to know about Console.log that will mean I never have to turn to a search engine again (with console related questions)?
For what it’s worth, reading the ECMAScript spec was one of the best things I’ve done to deepen my work as a developer. It doesn’t touch on console commands, but these do:
It’s not that I’m just reading language docs all day, but I’ve found it to be a really productive use of time when I do. It’s a vehicle for discovery that tutorials, SO answers, and blog posts don’t tend to always cover. For instance, I learned about Realms in JS which allow for a distinct global context, and more recently the proposed ShadowRealms API which not only just sounds cool, but allows for some neat isolation if ever you need to run JS in the browser that shouldn’t affect the window (such as a web IDE).
For those who are brave enough to delve into the Shadow Realms:
Point being: there are formal manuals and specifications for every part of the web stack. They can be intensely difficult to grok but are a valuable resource. It’s not fair to say RTFM to every question about the web stack, it’s unreasonable to expect anyone to hold all of that in their brain. Still, these things do exist and have a lot of value.
Thanks. However, that's 4 separate links that you've provided. (R)ead (T)he (F)antastic (M)anual suggests there is one to be referenced. It's not read a manual.
That's kind of the point. When it comes to programming, there is no single manual. You learn some basics, roll up your sleeves, and bang out code. You get to something you're unfamiliar, so you look it up. You learn something new. You go back to bang out code until the next "new". However, this time while searching, you read a different way of doing something you've done in the past that is "more better" or "less incorrect" or "more efficient". The thing to note, is not one of those websites visted and read are the same.
> However, that's 4 separate links that you've provided. (R)ead (T)he (F)antastic (M)anual suggests there is one to be referenced. It's not read a manual.
That’s not what RTFM means and has never meant that. The definition is an angsty way to tell the inquirer to stop bothering whomever and go look it up. The number of sources is irrelevant.
If you’re going to go so far as to change Fuck to Fantastic, then Manual can be changed to Manuals.
> which manual am I reading for learning everything there is possible to know about Console.log that
> will mean I never have to turn to a search engine again (with console related questions)?
Interestingly, I cannot find the console methods in there. Perhaps they are not part of the spec? I remember when Javascript was new (before 2000) it was said that Javascript was unique among languages for not having the concept of input and output.
console is not part of the language, iirc it was first introduced by Firebug - or some similar debugging tool then every other environment implemented something with the same syntax for their environment but slightly differing behaviors since not a part of the standard (of course you can also find things in a standard that vary by implementation, but things that are not in the standard I distrust even more)
