Hacker News Reader

Comment by nightpool | Hacker News Reader

Seeing as [nobody seems to have brought it up to them](https://github.com/WICG/sanitizer-api/issues?q=sgml), I'm not surprised that they haven't addressed it.

But, as always, specific & easy-to-use APIs are going to win out over more "fully general" ones. Are you suggesting that everybody learn DSSSL and write queries like

    ((match-element? nd '(section title))
    (format-number-list
    (hierarchical-number '("chapter" "section") nd)
    "1"
    "."))

Simply to be able to safely display some markup? I for one would much rather work on an AST with normal javascript instead of having to learn another DSL.

View on HN

> Are you suggesting that everybody learn DSSSL [...]?

Hell, no ;) Just that they pickup SGML insertion contexts as a concept where to escape what chars when that was known in the late 1970s already (ISO 8879 was published in 1986, but took a loong time through the committees). It's incredibly lame they haven't figured DTD/markup grammars and can only handle hard-coded HTML insertion contexts - one more thing to fall off the cliff as HTML evolves, and unnecessarily so.

OTOH, it always is fun to show HNers what could've would've been using DSSSL/Scheme in browsers ...

This has nothing to do with "escaping what chars when". It's simply a structural whitelist for DOM nodes that prevents JS execution, coupled with a contextual parser that was already available, but a little hard to find. Maybe I'm not understanding your point, because googling for "SGML insertion contexts" doesn't bring up anything that looks relevant, but there are many, many drawbacks that came from using XML to define HTML, and the browser community moved away from it for a good reason. My guess is that SGML had a similar story.

SGML (and its subset XML) lets you declare content models telling a parser what elements to expect below others and in what sequence (regular tree grammar). SGML (but not XML which left that feature out) also allows content inclusions/exclusions allowing or forbidding, resp., a particular element such as <script> to appear anywhere below a node. This, coupled with specific entity expansion and escaping rules into various contexts (into regular or RCDATA text nodes, into attributes, ...) amounts to a system that is agnostic of the particular markup language used. Strictly better than defining "sanitation" or gross PHPesque "safe string" approximations. And the "browser community" (browser cartel) moved away from it when they introduced JavaScript and CSS inlined into HTML (eg to prevent non-script, non-CSS browsers to render those as content, where these never had any reason to appear in content in the first place). Incidentally, script and the piece of garbage that is CSS also marks the end of hypertext systems as decried by TFA. Browsers continue to hang on that crap in the name of backward compat, but really due to the Web having become an insane self-referential ecosystem for job security and lock-in.

Don't let the false narrative of HTML exceptionalism taint your reasoning: markup language are envisioned as a rational technique for authoring, reusing, and preserving text and other documents. Unlike moribund browser tech putting ads and monopolistic media distribution models at the helmet. Soon, there will be only Chrome left, with FF only a token implementation also financed by Google.

The Lisp evangelism team on HN will burn you for that comment :)

The Lisp evangelism team can speak for themselves :)

Reply on news.ycombinator.com