Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Foolproof HTML

pumpula.net

Post reply on HN
Print view View original

71–80 of 110 posts

Re: Foolproof HTML

#71

Post by tannhaeuser »

lisper wrote: post #58
tannhaeuser wrote: post #46

Earlier quoted context omitted.

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: End-tag inference is semi-syntactic. You can tell that the following might have a missing end tag: But the previous example definitely does not.

SGML/HTML tag inference is guided by content model declarations, eg.
tells SGML that the html element should contain a head element, followed by a body element. "O O" (capital letter O for omission) are tag omission indicators (in this case meaning that both the start- and the end-element tags for html can be omitted).

This is covered in depth in the linked paper/slides (in fact, covering JimDabell's example exactly).

Re: Foolproof HTML

#72

Post by pg314 »

TylerE wrote: post #32
icebraining wrote: post #14

Earlier quoted context omitted.

Seems similar to HTML generation libs in Lisp, except with indentation instead of parenthesis.

Yes, and here at least, I think indentation is a BIG win over parenthesis.

I disagree. When you want to move a block of code around, it makes it too easy to make mistakes. Or if you want to add e.g. a div around a bunch of other elements, you need to be very careful with the indentation.

I've worked with both: s-expression based syntax and whitespace-sensitive syntax. I'll take s-expression based syntax any time. Have you used both?

Re: Foolproof HTML

#73

Post by joe-user »

JimDabell wrote: post #69
lisper wrote: post #60

Earlier quoted context omitted.

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

No, you're confusing HTML documents with their parsed DOM. The example you gave is different HTML to the example I gave.

Although the HTML he (lisper) gave is different in that it has the closing

tag, I'm failing to see any case where this is bad or would result in different behavior from your example. To be clear, he seems to be talking about rendering HTML only, not parsing it. Wouldn't both your example and his have the same parsed DOM? Am I missing something?

Re: Foolproof HTML

#74

Post by JimDabell »

joe-user wrote: post #73
JimDabell wrote: post #69

Earlier quoted context omitted.

No, you're confusing HTML documents with their parsed DOM. The example you gave is different HTML to the example I gave.

Although the HTML he (lisper) gave is different in that it has the closing tag, I'm failing to see any case where this is bad or would result in different behavior from your example. To be clear, he seems to be talking about rendering HTML only, not parsing it. Wouldn't both your example and his have the same parsed DOM? Am I missing something?

You sometimes need more control over the actual HTML document than that; for instance to work around browser bugs or for efficiency. But if you are only interested in the semantics, then it's still not an adequate representation of the document. How would you, for instance, add an attribute to the body element? If you're dealing with a semantic representation like a DOM library would give you, then this would be trivial, because the body element would be part of the model you are working with. But the body element doesn't exist in that S-expression. You'll have to manually insert it, which involves further domain-specific knowledge embedded in your code.

Basically, it's stuck in-between two states doing neither correctly. It doesn't represent the actual HTML document, and it doesn't represent the parsed document structure. It's an alternative model of the HTML document that serialises to something that would be parsed in an equivalent way. I'm sure that's useful in a whole bunch of different situations, but it's not as simple as "S-expressions can do everything HTML can, in a convenient way".

S-expressions are great, and very useful. But they aren't the right tool for every situation. HTML is an odd markup language that only appears simple superficially, with all kids of irregular corner cases creeping in when you dig into the details. S-expressions would be a great fit if HTML were as simple as it appears on the surface, but it's not.

Re: Foolproof HTML

#75

Post by kevin_thibedeau »

thangalin wrote: post #21

The article describes Markdown[1], basically. In my opinion, content should be written once and transformed to any format[2], including ConTeXt[3], docx, HTML, EPUB, or plain text. But here's a puzzler. Every software developer defines and uses variables. If variables are so powerful, why do WYSIWYG word processors lack the ability to quickly and easily insert variable definitions?[4] In the screenshot, the left-hand…

Variables are pretty easy to work with in Word though they've been a little harder to get to since 2007.

Re: Foolproof HTML

#76

Post by tannhaeuser »

JimDabell wrote: post #74
joe-user wrote: post #73

Earlier quoted context omitted.

Although the HTML he (lisper) gave is different in that it has the closing tag, I'm failing to see any case where this is bad or would result in different behavior from your example. To be clear, he seems to be talking about rendering HTML only, not parsing it. Wouldn't both your example and his have the same parsed DOM? Am I missing something?

You sometimes need more control over the actual HTML document than that; for instance to work around browser bugs or for efficiency. But if you are only interested in the semantics, then it's still not an adequate representation of the document. How would you, for instance, add an attribute to the body element? If you're dealing with a semantic representation like a DOM library would give you, then this would be triv…

I agree, and I'd also like to add that I find general discussions about s-expr vs markup (as well as JSON vs XML years ago) pointless.

Markup is meant as a text format for content authors that can be parsed into a hierarchical structure, rather than as general-purpose data representation syntax, even though XML is being frequently (ab-)used for this purpose.

The original use case for markup is that you can take a piece of plain text and then mark it up with tags, unlike s-expr and/or JSON which arise out of the syntax of a programming language and need eg. verbatim text to be written as string constants/with quotation characters.

Re: Foolproof HTML

#77

Post by kazinator »

JimDabell wrote: post #54
recursive wrote: post #49

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

Yawn. Hey look,

  #!/usr/bin/lisp
  (defun foo () a b c)
has an "inferred PROGN" around a b c and the first line isn't part of the tree.

What you're not getting here is that the above broken HTML has a canonical HTML representation. That canonical HTML can go to S-exp.

If we are doing HTML-in-Sexp, we can throw out some of the non-canonical aspects, keeping the ones we like. We can certainly infer element wrapping if someone using our HTML-in-Sexp finds that useful.

Re: Foolproof HTML

#78

Post by kazinator »

tannhaeuser wrote: post #46
lisper wrote: 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…

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.

Start and end tag inference really means element inference. LIke, oh, here is a

...

but it's not in a element; let's wrap it in one to canonicalize it. That can be done in the abstract syntax tree, rather than by literally inserting tag tokens.

(I hope for the sake of SGML and HTML that you're the one confusing character level syntax with tree manipulation.)

Re: Foolproof HTML

#79

Post by kazinator »

tannhaeuser wrote: post #45
kazinator wrote: post #40

Earlier quoted context omitted.

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

Admittedly, I'm assuming that we can use some typesetting back end; i.e., for instance, we don't have the requirement to generate a typesetter-ready image (or PDF document) without any third-party code; we don't have to do our own font rendering and kerning, etc. Also, I'm assuming we don't have to burn cycles Greenspunning up half of Lisp in some dumb langauge.

Re: Foolproof HTML

#80

Post by JimDabell »

kazinator wrote: post #77
JimDabell wrote: post #54

Earlier quoted context omitted.

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…

Yawn. Hey look, #!/usr/bin/lisp (defun foo () a b c) has an "inferred PROGN" around a b c and the first line isn't part of the tree. What you're not getting here is that the above broken HTML has a canonical HTML representation. That canonical HTML can go to S-exp. If we are doing HTML-in-Sexp, we can throw out some of the non-canonical aspects, keeping the ones we like. We can certainly infer element wrapping if som…

> Yawn.

Is that really necessary?

> the above broken HTML

As I very clearly stated, it's not broken. It's completely correct, valid HTML. Stick it in a validator if you don't believe me. Yes, I know a lot of people assume otherwise. That's because HTML is only superficially simple but has unexpected irregularities once you dig deeper. This just reinforces my point that HTML isn't the nice neat package that fits well with S-expressions you think it is. The canonical HTML representation of that "broken" HTML is simply the HTML I provided, unaltered, which is not conveniently representable as an S-expression. Please, before trying to reinvent HTML-as-S-expressions, take the time to learn what is and isn't correct HTML. You seem to be assuming the language is simpler than it is and any irregularities are because the sample HTML provided is "broken". This isn't the case.

Post reply on HN