5 ms·

Like it or not, it's enshrined in the specification of HTML5.

JimDabell 10y ago
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: <!DOCTYPE html> <title>…</title> … 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 DOM tree. It's got several implied start and end tags, so the tree itself looks like this: html head title … body p … Again, this is a completely correct, valid document and this is the correct way to parse it. While you may be able to represent the parsed DOM as an S-expression, you can't represent all valid HTML documents as S-expressions, at least not in the convenient way people assume – and it's not "broken HTML" to blame.
- lisper 10y ago
 > 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 "..."))) <!doctype "html"> <title>This is the title </title> ... 
 - JimDabell 10y ago
 No, you're confusing HTML documents with their parsed DOM. The example you gave is different HTML to the example I gave.
 - joe-user 10y ago
 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?
 - JimDabell 10y ago
 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.
 tannhaeuser 10y ago
 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.
- kazinator 10y ago
 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.
 - JimDabell 10y ago
 > 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.
 - kazinator 10y ago
 You don't seem to understand what "canonical" means; it's a certain preferred alternative from among correct alternative forms. Often, the canonical form provides some base definition and the other forms can be understood in terms of equivalence to the canonical form. Do we not understand that a body element is added to the document if it is missing? Is there not a body element in the resulting DOM? 　If so, then the source syntax which has that body can be considered canonical.

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: <!DOCTYPE html> <title>…</title> … 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 DOM tree. It's got several implied start and end tags, so the tree itself looks like this: html head title … body p … Again, this is a completely correct, valid document and this is the correct way to parse it. While you may be able to represent the parsed DOM as an S-expression, you can't represent all valid HTML documents as S-expressions, at least not in the convenient way people assume – and it's not "broken HTML" to blame.

lisper 10y ago
> 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 "..."))) <!doctype "html"> <title>This is the title </title> ... 
- JimDabell 10y ago
 No, you're confusing HTML documents with their parsed DOM. The example you gave is different HTML to the example I gave.
 - joe-user 10y ago
 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?
 - JimDabell 10y ago
 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.
 - tannhaeuser 10y ago
 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.
kazinator 10y ago
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.
- JimDabell 10y ago
  > 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.
  - kazinator 10y ago
    You don't seem to understand what "canonical" means; it's a certain preferred alternative from among correct alternative forms. Often, the canonical form provides some base definition and the other forms can be understood in terms of equivalence to the canonical form. Do we not understand that a body element is added to the document if it is missing? Is there not a body element in the resulting DOM? 　If so, then the source syntax which has that body can be considered canonical.