| > There has never been any particular virtue in HTML being an SGML vocabulary. No one that mattered (which mainly means browsers) cared about SGML You can care about browsers, I care about documents and that they can be read and understood in a couple decades still. Preferably without kissing the ring of an ad company. Defining your own vocabularies and SGML is also directly mentioned in the paper being discussed. SGML lets you define your own custom language and mapping to HTML as output/rendering language without further tools. > SGML is a hideous, complex beast that no one wants to work with As opposed to what? The web platform specs covering all of HTML, CSS, and JS roughly a thousand times the size of the SGML spec? Have you actually studied SGML or implemented a parser for a markup language, or are you repeating what you've heard elsewhere? > And the current HTML parser is the best thing since sliced bread and my favourite popular file type spec by a large margin despite its size, because it’s clear, unambiguous, and implementable. Which version of WHATWG HTML5? Oh, WHATWG don't bother versioning their phone-book sized specs. And parsing breaks all the time; eg. current head doesn't contain the param element anymore (as content of the object element still in the spec) which however requires that no end tag is specified, hence a parser for current WHATWG HTML will fail hard in the presence of param elements (similar story with legacy elements such as keygen). Then there are new "boolean attributes" being introduced all the time requiring special rules/markup declarations ... With respect, the argument isn't particularly relevant anyway as those specs aren't aimed at folks having difficulties following a formal language spec/grammar but need procedural step-by-step instructions instead. |