The future of MDN: a focus on web docs
blog.mozilla.org
blog.mozilla.org
Nobody is arguing that we should be taking snippets and examples verbatim and use them 100% of the time without understanding them, just that there is value in having those snippets and examples available.
I know damn well how arrays work in javascript, from how they are implemented and what structures they use in memory at smaller sizes all the way up to the difference between a missing element in a sparse array to a dense array with an undefined value in it.
But sometimes I just want the snippet from MDN that "densifies" a sparse array. I know how it works, I can re-write it myself if needed, but I know that the one on MDN works and I won't hit any unexpected edge case because I forgot about some arcane bullshit thing.
Not to mention that when I'm first learning a new language or syntax I personally do MUCH better seeing examples of the code and being able to step through them to get the basics down (where I can then dive deeper into the system to understand the edge cases, hopefully with examples themselves to make sure I get the point).
MDN is a wiki. People who want to contribute documentation or examples do so. Sometimes they make mistakes. Sometimes they're suffering from Dunning-Kruger. It is unreasonable to assume that the example will work and will not have unexpected edge cases.
It's the best resource I know on the web, which is I recommend it, and why I've contributed to it, but it's a wiki. Caveat emptor. (Caveat lector?)
There's a lot of technology to understand and absorb, and I'll take any tool I can get to help me.
I find one of the first things I do when approaching non-trivial new features is to sketch out an example and then step through the example by adding a few strategically placed breakpoints. The breakpoints allow me to examine both the execution flow and the internal state of the various objects associated with the new feature.
Both Chrome and FF support the handy 'debugger' statement, which you can place directly in your code and which acts as a breakpoint when you run the code with devtools open.
Edit: Apparently the debugger statement is standardized! Neat. Didn't realize that. Thanks MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
I'd like relevant examples. It's incredibly frustrating to look at an MDN snippet to see code that no sane human would ever write. Self-executing closures that return callbacks inside for-in loops, initialization code that still checks readyState, code that avoids more than one function for no obvious reason...MDN can be a real crap-shoot. Hell, I'd be happy if they would name their variables sensible things instead of trash like `numFoo`.
TBH, that's why actual documentation is there. Examples can never really cover everything something can [or cannot] do.
Let's search for "rfc 1855". The first item is indeed the original plain text source, unfortunately without links or anything:
- https://www.ietf.org/rfc/rfc1855.txt
But the second hit is a third-party source, that doesn't provide much over the plain text version. It doesn't even contain the RFC contents directly. I can't imagine anyone seriously linked to that page, let alone that so many are doing it to push it to the second place:
- https://www.rfc-editor.org/info/rfc1855 ... wtf?!
Moreover, the RFC authors group itself, the IETF, already provides a beautiful HTML representation, with links and everything:
- https://tools.ietf.org/html/rfc1855
But you won't find that in the first 10 hits. Not even in the first 50 hits, for that matter. You will find it, however, if you click at the third item, which is the corresponding Wikipedia entry:
- https://en.wikipedia.org/wiki/Etiquette_in_technology
The very first item in the "External links" section points to tools.ietf.org.
Given the prominent low-quality links to w3schools, rfc-editor and so on, I'm asking myself if Google is actively harming Mozilla and IETF. Maybe not harming, but being ignorant. These issues are known for years. If they want to be the best possible search engine, why don't they do anything about these widely known issues? I understand that they'd rather fix their algorithms than adding special rules for IETF, but then, they should have analyzed their algorithms how they can be tricked by low-quality sites. And fix that. Meanwhile, years have passed and nothing changed.
Maybe we should introduce a new search engine:
"Second-Order Wikipedia"
It would work like this:
1. Look up the search terms in Wikipedia articles
2. For each hit, show the Links of all articles' "External Links" sections.
- https://tools.ietf.org/html/rfc1855 (html version)
- ietf.org/rfc/rfc1855.txt (text version)
- rfc1855.net (another html version which is more readable than the ietf's)
- datatracker.ietf.org/doc/rfc1855/ (information about the history of the rfc)
- https://www.rfc-editor.org/info/rfc1855 (useless)
This is one of the clearest examples yet of why I prefer duckduckgo these days. Even if it might partially be just because less SEO is targeted at them.
https://developers.google.com/speed/pagespeed/insights/?url=...
I think it's likely someone will go through old RFCs and convert them too.
- ietf.org/rfc/ <- this is a static version that IETF has
- rfc-editor.org <- this is the RFC Editor's official site - I think you used to be able to download stuff through FTP, and the site looked like an FTP site until recently; in some sense this is really the canonical URL for RFCs which the RFC Editor publishes
- tools.ietf.org/html/ <- this is mostly Henrik Levkowitz' work - he's working directly on datatracker.ietf.org and has for many years, I think there was a plan to have datatracker.ietf.org contain HTML versions but I don't know the status
- datatracker.ietf.org <- this is the dynamic (Django-based) site that tracks lots of stuff about the working groups and meeting and documents - the source is open so you can look at it if you like - honestly I think this is the best place to link as it gives an increasing amount of context, although tools.ietf.org/html/ is definitely the nicest way to read the contents
https://www.searchenginejournal.com/all-wikipedia-links-are-...
They're looking for "how to do <something>", not for the docs.
!mdn <search query>
and get the MDN search results page.You can also do the same for stuff like
!gweek <search query>
And get google results limited to the last week (or StartPage ones if you swap the g for and s).It's amazing.
I've used these a lot in the past, but switched to DDG's bangs largely because it was such a pain to change browsers/devices, and none of them ever worked for me on mobile. DDG's bangs are still a little unwieldy (! isn't a very convenient character to type, especially on mobile), so an alternative would be nice. For now though, the consistency everywhere far outweighs any other advantages of the in-built browser feature.
Opera, yes.
Unfortunately the UI isn't too great -- on desktop, the suggestions between the awesomebar show you that a keyword search will happen (just like when you type something matching an open tab it tells you that it will switch to tab unless you hit the down arrow to choose something else). On mobile there is no such indication, but hitting enter after typing the keyword followed by the query still works fine and does the keyword search thing.
I might try to fix that.
This isn't limited to just MDN you can use it for Youtube, and other sites that support the query search string.
If you are having trouble finding the settings in Chrome to get to then simply
hit the 3 dots on the top right > settings > then at the top bar search for 'search' > Under the Search heading there will be a button labeled 'Manage Search Engines' click it > and read the article to see how to set it up.
If you have visited MDN before it will show up in the lower section. All you need to do is change the middle text box to mdn and save. otherwise the last box will need to be https://developer.mozilla.org/en-US/search?q=%s&w=3&qs=plugi... the first box is just a label used to display the search name you can leave it at default.
happy searchin!
Not saying that people shouldn't do it. Just offering a possible simpler alternative to be tested as well
You can use !g for google, !a for amazon, !mdn for MDN, !so for Stack Overflow, etc etc. If you want to search an even vaugely popular site, you can probably just type !domain and DDG will search it.
For example: http://mdn.io/flexbox
Admittedly, I don't use it, but cool that it exists!
It's possible the name change is for SEO reasons. Although they shouldn't need to; Google really ought to swallow their competitive pride and make MDN one of their previewed snippet sources, or else create their own webdev documentation source of equal or better quality.
There are a lot of documentation, code completion etc type things out there that currently rely on manual updating (eg Tern.js) or scraping (eg devdocs.io) to maintain this kind of data. It'd be good if there was a canonical source.
They should keep an endless cookie or whatever to never serve me anything besides English.
(the language of the browser itself is irrelevant)
It's embarrassing how many steps you have to take do this. Why not honor my OS settings huh...
Thanks for the heads up though, I'll do some more digging and see if I can manage to change it.
Perhaps: Settings -> Show advanced settings (sigh) -> Language and input settings
Tack för hjälpen!
At the time it most certainly was not doing any type of IP geolocation; your browser's Accept-Language header was how we initially determined the language to show you.
Edit: And it still does only use Accept-Language. Here's the code:
https://github.com/mozilla/kuma/blob/a3ad0dbb286fd45affdf1ae...
Not that google listens but they are a huge offender in this area.
If there are people who think it is, they can do it, but I just want to read everything in English when it comes to programming.
So what does Mozilla do? Make their great documentation even better, and enrich the development community.
These choices by the Mozilla foundation might be unrelated. However, if things go south, I hope the community remembers who is consistently advocating for it.
This change would allow numerous improvements such as up-to-date, relevant examples, issues and pull requests for discussions and improvement etc.
Discussion is done via mailing list.
Last time I tried to edit an obvious error in the page the edit button led to a page telling you to create a ticket in bugzilla.
https://secure.php.net/manual/en/function.htmlspecialchars.p...
https://secure.php.net/manual/en/function.preg-replace.php#u...
https://secure.php.net/manual/en/function.header.php#usernot...
Unfortunately, it may have been politics between some of the companies that prevented a real success.
The good news is that we will revive the web platform on WebPlatform.Com as part of OpenDomain - anyone that wants to participate is welcome!
Source: I was part of that community for more than a year (first as a translator, than as a topic-driver).