We had XHTML, which didn't allow anything that wasn't properly formed XML. It went nowhere.
Foolproof HTML
51–60 of 110 posts
Re: Foolproof HTML
#52Regarding the 'code without syntax' part: I wrote something that basically does this for any language that you have an EBNF grammar for. It turns the grammar into a graph; wherever your cursor is in the document at a given moment corresponds to some node in the graph; the edges going out of that node are the syntactically valid things you can insert from that point. Unfortunately there is no UI for it atm—though ther…
The problem with these environments is that humans routinely want to write syntactically incorrect code as they transition from one valid program to another. An AST-based editor like this enforces that every intermediate step must parse as a valid program. This restriction makes making changes a massive pain in the ass, because you can no longer take the shortest route from where you are to where you want to be. For…
That's an interesting point. I've heard other people bring up this issue in a vague way, but your example makes it clear why people would have a concern about this.
At the same time, however, I'm not convinced it's a serious issue—it's more important to save work and avoid re-typing the shell of a switch when you have to type it one character at a time. If you're mapping language constructs to single keys (this was the way I went), you can crank out a new multi-block switch statement in a few keystrokes; then (in my editor anyway), you can just drag the code blocks from the if statements into the new structure.
Even better, since the editor has easy access to info about language structure, it could include automatic transformations to transition between structurally similar language constructs.
I think it seems unnatural at first because we're so used to typing characters out one at a time, and it seems like we're throwing that skill out the window when considering an alternate form of editor. I still don't really see an intrinsic limit though.
I'd appreciate any other counter-example you may have (a lot of why I don't continue working on my own project at the moment is concern that these are lurking and I'll only discover them after lots more wasted effort—so if I could definitively rule out that this project is a good idea, that'd be great.)
Re: Foolproof HTML
#53Interesting effort. By the way: Does somebody know a good linter which works on pure HTML, Vue templates (the HTML part), Jinja templates (the HTML part). Searching for this, ideally for VSCode.
Re: Foolproof HTML
#54Earlier quoted context omitted.
In fact, inferring missing close tags is criminally stupid; when such a situation is diagnosed in any of the *ML languages, it should be loudly diagnosed. Early in the web history, browsers tried to out-do each other in guessing what broken HTML means and render it. That led to a nasty situation of everyone having to emulate everyone else's bugs and hacks.
Like it or not, it's enshrined in the specification of HTML5.
It's actually been a standard part of HTML from the very start. It's got nothing to do with browser guessing and it's not new to HTML 5.
To give a concrete example for tannhaeuser's point, consider this document:
…
…
Then we get to the DOM tree. It's got several implied start and end tags, so the tree itself looks like this:
html
head
title
…
body
p
…
Re: Foolproof HTML
#55I made a Scalatags library that lets you write your HTML templates in-line in your Scala code (or Scala.js), similar to React's JSX but without the XML syntax:
div(
h1(id:="title", "This is a title"),
p("This is a big paragraph of text")
)
Although this ties it to the Scala language, it does not tie you to a particular platform: the templates can run on the JVM, in the browser with Scala.js, and even in the new scala-native LLVM backend.
The fact that the chosen language is statically typed means you get "basic" level validation right-off-the-bat thanks to the compiler:
http://www.lihaoyi.com/scalatags/#WhyScalatags
Basic typo-detection, enforcing things are properly nested, anti-XSS-enforcement, along with all the other "standard" IDE features: jump-to-definition for your sub-templates (which are just functions), use of arbitrary code within your templates (not unlike JS-X), etc.. Also, the fact that your templates are compiled into bytecode/JS at build time rather than interpreted and re-implementing scope management and variable-bindings and such in user-land code at runtime, means the templates are really very fast.
All this comes "for free", since your templates are code like any of the other code you write, and are handled by the IDE and optimized by the compiler in the same way.
The downside, of course, is that templates are code and thus cannot be provided safely by third parties, similar to React's JS-X
Re: Foolproof HTML
#56If to focus on something close to source code editing then why not to simplify html itself a bit?
Sciter's HTML parser supports shortcut constructs like:
woo!
woo!
===
===
Re: Foolproof HTML
#57> If you have a good strategy for validating your template files, I'd love to hear it! Use S-expression syntax instead of SGML syntax, i.e. instead of: content write ((tag attr value ...) content) and use Lisp to process it. It's actually quite straightforward. You can apply it to XML as well. Everything actually ends up looking a lot prettier this way. See http://weitz.de/cl-who/ for an example of an implemented sys…
Yes! This is what I like about JSX/React - you're actually writing the markup as function calls/data structure so invalid syntax is immediately obvious as missing a closing parentheses for a function call.
I'm not sure how React/JSX highlights the markup issues. The clarity that Jade/YAML syntax provides is hard to achieve with the clumsy looking React/JSX spaghetti code that facebook has sold to frontend devs.
Re: Foolproof HTML
#58Earlier quoted context omitted.
There is a one-to-one correspondence between (correct) SGML and S-expressions so your claim that S-expressions are "nowhere close to the power of SGML" cannot possibly be true. It might be true that the tools available for processing S-expressions as markup are not as powerful as the tools for processing SGML, but that is not a limitation of the syntax . BTW, when you say "inference of omitted tags" did you mean "inf…
Re tag inference: no I mean both start- and end-tag inference, like HTML does. It's explained in my linked paper, and it's not for "covering up design flaws". I think you're making quite strong conclusions here considering your lack of knowledge of SGML.
We're talking about syntax here. Start-tag inference is not syntactic. There is no way to tell if there's a missing start tag in:
Re: Foolproof HTML
#59> If you have a good strategy for validating your template files, I'd love to hear it! Use S-expression syntax instead of SGML syntax, i.e. instead of: content write ((tag attr value ...) content) and use Lisp to process it. It's actually quite straightforward. You can apply it to XML as well. Everything actually ends up looking a lot prettier this way. See http://weitz.de/cl-who/ for an example of an implemented sys…
Interesting, but you would still have to account for the inconsistencies of html, like: - Standalone, non-closed tags , , , , , etc. - Proper encoding or quoting of [ " ' &] in html attributes - tags and CDATA Probably lots more as well. Not rocket science of course, but you would want a tool where you have some confidence they've covered all of these things.
> Not rocket science of course
And it depends on whether you're parsing or rendering. Rendering is much easier than parsing. But even parsing is nonetheless a solved problem :-)
Re: Foolproof HTML
#60Earlier quoted context omitted.
Like it or not, it's enshrined in the specification of HTML5.
It's actually been a standard part of HTML from the very start. It's got nothing to do with browser guessing and it's not new to HTML 5. To give a concrete example for tannhaeuser's point, consider this document: … … This is a completely correct, valid HTML document. The first thing to notice is that it's not a tree made up of elements. That first line is not a tag, and isn't part of the DOM tree. Then we get to the…
> you can't represent all valid HTML documents as S-expressions, at least not in the convenient way people assume
Of course you can. Here is how to express your example as an s-expression:
((:!doctype html) (:title "This is the title") (:p "..."))
Here it is being rendered by CL-WHO:
? (princ (html ((:!doctype "html")) (:title "This is the title") (:p "...")))
This is the title
...