Skip to content

Instantly share code, notes, and snippets.



View GitHub Profile
import sys, os
dir = sys.argv[1]
entries = os.listdir(dir)
total_interfaces = 0
total_interface_members = 0
total_overflow = 0
View hasTag usage in KumaScript
26:var containsTag = page.hasTag;
27:var hasTag = page.hasTag;
197: if (hasTag(aPage, 'Experimental')) {
201: if (hasTag(aPage, 'Non-standard') || hasTag(aPage, 'Non Standard')) {
205: if (hasTag(aPage, 'Deprecated')) {
209: if (hasTag(aPage, 'Obsolete')) {
228: if (hasTag(aPage, 'Obsolete')) {
View Interactive examples and shadow

Interactive examples architecture and the shadow DOM

In our interactive examples architecture, examples are built as complete separate pages, served from their own domain, like this: When we include them on MDN, we do it by creating an iframe in the MDN page, that contains the interactive examples page. So the interactive example is in its own isolated world, separate from the rest of the page.

This has some advantages. One is security: we don't have to worry much about what the example code is doing, because it can't get access to the rest of the page. So we don't really have to vet contributions much for security. Another is just isolation: if we do things in the interactive example they won't "escape" into the page. For example, in the JS interactive examples we redefine console.log() to make it write to the example's output pane, but we don't want that change to affect code running in the MDN page.

There are also some disadvantages

import sys, re
from os import walk, path
dir = sys.argv[1]
threshold = 20
for (dirpath, dirnames, filenames) in walk(dir):
for filename in filenames:
View Many H3 headings : 34 : 30 : 42 : 22 : 22 : 25 : 30 : 36 : 21 : 21
View gist:dc2d6b9a66edb6319c86837cd2a6f82e
37:{{page("/en-US/docs/Web/API/ProgressEvent", "Properties")}}
37:{{page("/en-US/docs/Web/API/ProgressEvent", "Properties")}}
38:{{page("/en-US/docs/Web/API/ProgressEvent", "Properties")}}

In 2021 the Open Web Docs team, with help from Mozilla, the W3C, and the wider web docs community, converted the authoring format for MDN Web Docs - all 11,000 pages of it - from HTML to Markdown. In this post we'll talk about why we did it, how we did it, and how it turned out.

HTML soup

Before 2020 MDN was a Wiki, and contributors edited pages using a web-based WYSIWYG HTML editor. This made it easy to make casual contributions: people could edit text and apply simple formatting, like bold or code, without having to edit the underlying HTML. But a WYSIWYG editor is not well-suited to more complex edits, and authors often had to edit the underlying HTML source directly. Also, because the underlying source was hidden by default, HTML cruft, like <span id="486uw3y3"> crept into the source, often from authors pasting HTML from another rich editing environment into the MDN WYSIWYG editor.

In 2020 MDN replaced the old Wiki with a new platform in which the source for the docs was stored in a GitHub


Report from 10/24/2021, 10:23:08 AM

All unhandled elements

  • div.hidden (369)
  • td (74)
  • table.fullwidth-table.standard-table (66)
  • tr (31)
  • kbd (26)
  • table.standard-table (8)
  • th (4)
  • table (3)
View web-media

Report from 10/14/2021, 4:45:17 PM

All unhandled elements

  • tr (676)
  • th[scope="row"] (628)
  • table.standard-table (103)
  • td (77)
  • th[scope="col"] (60)
  • td[style="vertical-align: top;"] (47)
  • th[rowSpan="2"][scope="row"][style="vertical-align: bottom;"] (16)
  • th[colSpan="4"][scope="col"][style="text-align: center;"] (15)

Report from 10/14/2021, 3:14:56 PM

All unhandled elements

  • tr (14)
  • th[scope="row"] (10)
  • td[rowSpan="3"] (6)
  • table.standard-table (3)
  • td[rowSpan="5"] (3)
  • td[rowSpan="2"] (2)
  • th[rowSpan="2"][scope="row"] (1)

Details per Document