Live data from Hacker News

Foolproof HTML

pumpula.net

41–50 of 110 posts

Re: Foolproof HTML

#41
post #39

Earlier quoted context omitted.

While I also like Lisp syntax, it's nowhere close to the power of SGML as a text format. SGML gives you regular type checking and inference of omitted tags, injection-free content transclusion, user-defined Wiki syntax, parametric template expansion, and pipelined, automaton-based processing/styling. I've just published my slides/paper on this topic at http://sgmljs.net/blog.html .

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…

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.

Re: Foolproof HTML

#42

Earlier quoted context omitted.

Can confirm: Hiccup is really great.

Yes! Check out a site I made to show the world: http://hiccup.space Also if you're interested in a more interactive (i.e. can process data into html), check out http://cljsfiddle.com

Wow, that's a neat library and demonstration. Thank you.

Re: Foolproof HTML

#43
post #17

> 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.

Re: Foolproof HTML

#44

Regarding 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 example, imagine you're restructuring an if-else sequence into a switch statement. You're probably going to change that first "if" to a "switch", then go down changing all the "else"s into "case"s. This is eminently sensible, but an AST-based editor will stop you dead if you try to do this, because the intermediate states are not valid ASTs.

The only system slightly like this I've seen in widespread use is Paredit, which prevents you typing anything that isn't a valid s-expression. This only works because s-expression syntax is so minimal, and most of Lisp's actual syntax is layered on top with macros. Even if you're using Paredit, your spit/slurp/kill operations will produce invalid intermediate code that would fail to compile.

Re: Foolproof HTML

#45

Earlier quoted context omitted.

While I also like Lisp syntax, it's nowhere close to the power of SGML as a text format. SGML gives you regular type checking and inference of omitted tags, injection-free content transclusion, user-defined Wiki syntax, parametric template expansion, and pipelined, automaton-based processing/styling. I've just published my slides/paper on this topic at http://sgmljs.net/blog.html .

The fact that you can do HTML in Lisp is because there is code behind that doing the semantics . What makes you think that those SGML requirements couldn't be done? Sounds to me like about one week's worth of evening hacking.

You're off several orders of magnitude. Implementing SGML is a multi-year effort. You don't have to take my word for it, James Clark has said the same (he has implemented SGML and XML, and also DSSSL, the Scheme-based precursor of CSS and XSLT).

[1]: http://drdobbs.com/a-triumph-of-simplicity-james-clark-on-m/...

Re: Foolproof HTML

#46
post #39

Earlier quoted context omitted.

While I also like Lisp syntax, it's nowhere close to the power of SGML as a text format. SGML gives you regular type checking and inference of omitted tags, injection-free content transclusion, user-defined Wiki syntax, parametric template expansion, and pipelined, automaton-based processing/styling. I've just published my slides/paper on this topic at http://sgmljs.net/blog.html .

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.

Re: Foolproof HTML

#47

It was a nice read, and I like the way the idea was presented. But one thing that stood out to me as kind of odd was the distinction between typing lowercase and uppercase characters. Automatically assuming lowercase to be a "keyword" does not seem like the right idea to me. Most sentences on the web might start with a capital, but not all of them will do. (For example here on HN, you have in the nav bar "new | threa…

This irritated me too. I suppose a shortcut can be added to say "treat the next thing entered as a text element", along with the uppercase shortcut. So the user can type e.g. "!new" and the editor will make a text node with "new" as its content.

Re: Foolproof HTML

#48
post #43
post #17

> 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.

Last time I looked and
 also worked kind of like .

Re: Foolproof HTML

#49
post #39

Earlier 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…

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.

Re: Foolproof HTML

#50
post #18

So when are we going to ever get a replacement for for this deeply flawed technology called HTML?

There are some replacements for different parts of it. Like PDF, and whatever iphones' ui is called for instance.
Post reply on HN