Yeah, we’re still working on finalizing the proper structures of certain types of pages, as part of an effort to bring everything into line. It’s coming, slowly, as we’re able to make time between writing about web standards.
I’m in the middle of work on an update to the wiki platform such that when you choose to create a new page, you get asked what type of page you want to add, and after clicking the “New page” button from there, you’re given an editor pre-populated with the template for the page you’re creating.
Longer term, we want to look into ways to automatically start reference pages pre-built with basic content generated by scanning WebIDL files, but that’s a much more intricate project.
Yes, it needs some work. It’s slow, and it’s a little bit flaky in places. It’s generally pretty impressive given the somewhat haphazard way it was built over time, but it could use a rebuild now that we have a better idea how it’s being used.
Agreed. That’s a good idea. You should feel free to file a bug and suggest this.
Yeah, there’s a bug on this already.
Yeah, the filters are pretty slow. Keep in mind you can set yourself up a custom bookmark that has the filters already in place to save time, like this link, which pre-configures your dashboard to look only at English pages in the Web documentation that were changed in the past week:
All APIs, on the other hand, are meant to be documented using the InterfaceName.methodName() or InterfaceName.propertyName syntax for their page titles. There are mistakes here and there and they need to be fixed; we try to do it as we spot them.
We also have some older pages which use different structures entirely, and those need to be updated once we finalize the current design rules (we’re very close now).
Yeah, there are some inconsistencies and errors here and there. One way we’re trying to get that cleared up is by introducing the MDN content linter extension for Firefox. I would like to see us integrate a tool like it directly into the editor eventually.
(FWIW, headings shouldn’t have a
We tinker with doing things like this at times. I think you could totally write one but it would need to go through some testing, such as by running it on a local clone of MDN (which is thankfully totally possible!).
This was a conscious decision made long ago. We’re a site that documents the web. Not using HTML to document the web is not exactly a strong sign of support. Plus back when we made the decision, MediaWiki did not work well for us, as it broke certain types of code sample boxes and the like.
I personally agree with you on this. I get that there are benefits to having the macros/templates on GitHub (tests and the like to help avoid problems being introduced) but the down side is I think much greater. I have macro changes that I need in order to complete my work that have been languishing for weeks or months in some cases because nobody wants to review intricate macro changes and they don’t want to push them to production without a thorough review because of the risks of breaking something when changing a widely used macro. Yeah, there’s a risk there, but killing entire projects because nobody can invest the time in the review sort of breaks the entire system, I think.
I have at least four or five projects that were deliverables of mine that have been stalled for substantial amounts of time due to not being able to get macro changes into production.
I also agree that the number of steps involved in making even small changes to things like browser compatibility data are tedious to say the least. The system we have for storing the data in JSON and such is actually brilliant and I think is going to do great things for us, but the workflow as it stands is horrible.
I’d love forever the person who creates a really nice visual editor for our JSON data stores, complete with schema support to produce a custom UI and to validate the data before submitting a PR for me.