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

91–100 of 110 posts

Re: Foolproof HTML

#91

Post by andrei_says_ »

ungzd wrote: post #12
andrei_says_ wrote: post #3

I found my foolproof HTML in slim-lang. It produces standards-compliant HTML and prevents me from writing code that is not well-formed. The above is a nice side effect of its incredibly clean and terse syntax. Now I feel cheated any time I need to write regular HTML. https://github.com/slim-template/slim/blob/master/README.md I used emmet for a while but slim improves on writing and reading code.

Slim becomes painful when using Ruby function calls (i.e. Rails helpers). Sometimes these functions have long list of parameters and wrapping to next line sometimes becomes not so convenient. Moving, copying and pasting indented blocks is also quite painful and it's much harder to see nested structure than in, for example, Python code. Also it has complicated syntax for attributes and text content, especially text co…

Would you consider pasting a sample? I do work with rails and can't think of a time when I have experienced this issue.

Maybe when passing multiple cars to a partial?

Re: Foolproof HTML

#92

Post by tannhaeuser »

lisper wrote: post #87
tannhaeuser wrote: post #86

Earlier quoted context omitted.

> You really don't seem to understand the difference between syntax and semantics. Are you talking to me? I've just pointed out how SGML works and didn't say anything about syntax/semantics.

Yes, I'm talking to you. You're right, you didn't say anything about syntax and semantics. I did. Go back to the beginning of the thread: > > 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 [emphasis added] Note the use of the word syntax . I'm talking about syntax . All of your responses have been at best irrelevant or at worst wro…

If reality is so annoying to you, please refrain from (trash-)talking to me.

Re: Foolproof HTML

#93

Post by lisper »

tannhaeuser wrote: post #92
lisper wrote: post #87

Earlier quoted context omitted.

Yes, I'm talking to you. You're right, you didn't say anything about syntax and semantics. I did. Go back to the beginning of the thread: > > 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 [emphasis added] Note the use of the word syntax . I'm talking about syntax . All of your responses have been at best irrelevant or at worst wro…

If reality is so annoying to you, please refrain from (trash-)talking to me.

Reality is not annoying. Straw-man arguments are.

https://en.wikipedia.org/wiki/Straw_man

Re: Foolproof HTML

#94

Post by swhipple »

lisper wrote: post #81
JimDabell wrote: post #74

Earlier quoted context omitted.

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…

You are confusing syntax and semantics. HTML and the DOM are two different things. HTML is a string of characters (syntax). The DOM is a data structure (semantics). Normally a DOM is produced by parsing HTML, but it can be produced in other ways (by running Javascript code, for example). S-expressions are a data structure, different from the DOM, but S-expression syntax is a syntax. Normally S-expression syntax is pa…

> HTML is a string of characters (syntax). The DOM is a data structure (semantics). [...] S-expressions are a data structure, different from the DOM, but S-expression syntax is a syntax.

I believe this is where the confusion is coming from. When you parse HTML syntax, you get a data structure; this is the same as when you read sexpr syntax, you also get a data structure. Both these data structures are different from the DOM tree.

Try this example:

    
      one
      
      

      two
Can CL-WHO generate HTML that matches that? (i.e. feed both into a tool like BeautifulSoup and produce the same data structure?)

Outside of CL-WHO and Hiccup-type libraries, you can of course use S-exprs to represent the same data structure. Here's a hypothetical S-expr syntax that might produce the same data structure:

    ((pre)
      "\n  " (span) "one\n  " (/span)
      "\n  " (br)
      "\n  " (span) "two" (/span)
      "\n  " (br/) "\n"
     (/pre))
Which is what I believe JimDabell meant by:

> you can't represent all valid HTML documents as S-expressions, at least not in the convenient way people assume

Re: Foolproof HTML

#95

Post by lisper »

swhipple wrote: post #94
lisper wrote: post #81

Earlier quoted context omitted.

You are confusing syntax and semantics. HTML and the DOM are two different things. HTML is a string of characters (syntax). The DOM is a data structure (semantics). Normally a DOM is produced by parsing HTML, but it can be produced in other ways (by running Javascript code, for example). S-expressions are a data structure, different from the DOM, but S-expression syntax is a syntax. Normally S-expression syntax is pa…

> HTML is a string of characters (syntax). The DOM is a data structure (semantics). [...] S-expressions are a data structure, different from the DOM, but S-expression syntax is a syntax. I believe this is where the confusion is coming from. When you parse HTML syntax, you get a data structure; this is the same as when you read sexpr syntax, you also get a data structure. Both these data structures are different from…

> Both these data structures are different from the DOM tree.

In the case of S-expressions that is true. In the case of HTML it may or may not be true. It depends on how the HTML parser is implemented. There is a "natural" mapping of HTML onto a parse tree that is different from the DOM, but that is not part of the standard (AFAIK).

> Can CL-WHO generate HTML that matches that?

Yes, though native Common Lisp does not provide c-like string escapes so putting in newlines is a little awkward. You could, of course, bring in a string interpolation library, but here's how you can do it without that:

    ? (defun nl () (who (fmt "~%")))     ; NL = NewLine
    NL
    ? (defun nli () (who (fmt "~%  ")))  ; NLI = NewLine + Indent
    NLI
    ? (princ (html (:pre (nli) (:span "one" (nli)) (nli) (:br (nli) (:span "two") (nl)))))
    
     
       one
       
       

       two
Or you could do this:

    (html (:pre "
      one
      
      

      two
      
    "))
which looks like cheating but is actually closer to the spirit of the original.

The PRE tag is really weird because it actually changes the way things inside it are parsed. You can actually implement that in Lisp too via reader macros. CL-WHO doesn't support that out of the box, but it's not hard.

I can't imagine anyone actually wanting to do that, though. The PRE tag is for presenting pre-formatted text without changing its appearance, so embedding other tags inside it is kinda perverse. [EDIT: I was wrong about this. See below.]

Re: Foolproof HTML

#96

Post by meredydd »

westoncb wrote: post #89
meredydd wrote: post #68

Earlier quoted context omitted.

I'd say the opposite - in your shoes, I'd just try it, doomed or not! (But then again building an IDE is My Thing atm - check my profile.) Building one of these systems is going to be really fun. If you don't have the time/inclination to just do it cause it's a cool project, one option is to "paper prototype" the feasibility of the transforms you'd need. Next time you're writing any code in the first language you wan…

Thanks for the reply meredydd. That does seem like a good approach. Actually, I spent 1.5 years building an editor in this style (see link in my original post here) while working at a grocery store :) Unfortunately, while I can see now that I should have first been super focused on validating the concept—I instead just kind of ran with it, assuming it was going to work, and built this massive, probably over-engineere…

"VB for web apps" is a fair summary. We made a conscious decision against anything AST-based (for the reasons I outlined above), and we're about to deploy an Intellisense-style autocompleter instead. Our general philosophy is that coding is fine - it's the web/Javascript ecosystem that's the problem. We fix that, then get out of the way and let you write code :)

As for validating one's side projects before starting work - I personally think the Lean Startup thing can be taken a bit far. An interesting leisure-time technical project doesn't need the same level of prior justification as a big commercial project (even if it might one day evolve into one), as long as you're having fun. We do this stuff because we enjoy it!

Re: Foolproof HTML

#97

Post by kazinator »

lisper wrote: post #95
swhipple wrote: post #94

Earlier quoted context omitted.

> HTML is a string of characters (syntax). The DOM is a data structure (semantics). [...] S-expressions are a data structure, different from the DOM, but S-expression syntax is a syntax. I believe this is where the confusion is coming from. When you parse HTML syntax, you get a data structure; this is the same as when you read sexpr syntax, you also get a data structure. Both these data structures are different from…

> Both these data structures are different from the DOM tree. In the case of S-expressions that is true. In the case of HTML it may or may not be true. It depends on how the HTML parser is implemented. There is a "natural" mapping of HTML onto a parse tree that is different from the DOM, but that is not part of the standard (AFAIK). > Can CL-WHO generate HTML that matches that? Yes, though native Common Lisp does not…

There are uses for pre with tags embedded.

pre provides the simplified line breaking and usually a monospaced font. However, tags are available to do whatever else.

A major example is that the Vim editor uses pre for formatting syntax colored code to HTML (when you do that with :TOhtml).

The output is a pre block containing various span elements which are styled with CSS.

BTW where in the HTML spec does it say that the interior of pre is parsed differently?

If we are parsing HTML (to Lisp objects or whatever), we should preserve the exact whitespace. The reverse generation should regurgitate the original whitespace.

If we take the license to eliminate newlines, then we ruin pre. The fix is simply not to do that.

Re: Foolproof HTML

#98

Post by lisper »

kazinator wrote: post #97
lisper wrote: post #95

Earlier quoted context omitted.

> Both these data structures are different from the DOM tree. In the case of S-expressions that is true. In the case of HTML it may or may not be true. It depends on how the HTML parser is implemented. There is a "natural" mapping of HTML onto a parse tree that is different from the DOM, but that is not part of the standard (AFAIK). > Can CL-WHO generate HTML that matches that? Yes, though native Common Lisp does not…

There are uses for pre with tags embedded. pre provides the simplified line breaking and usually a monospaced font. However, tags are available to do whatever else. A major example is that the Vim editor uses pre for formatting syntax colored code to HTML (when you do that with :TOhtml). The output is a pre block containing various span elements which are styled with CSS. BTW where in the HTML spec does it say that t…

> where in the HTML spec does it say that the interior of pre is parsed differently?

I was wrong about that. I had a vague memory of putting HTML inside a PRE tag once and having it come out as if it were escaped, but apparently I hallucinated that.

> A major example is that the Vim editor uses pre for formatting syntax colored code to HTML (when you do that with :TOhtml).

OK, I stand corrected on that too.

> If we are parsing HTML (to Lisp objects or whatever), we should preserve the exact whitespace. The reverse generation should regurgitate the original whitespace. > If we take the license to eliminate newlines, then we ruin pre. The fix is simply not to do that.

Right.

Actually, I just realized that I mis-read the example. I saw and thought it was . (Maybe the OP edited it?) In any case, the example now reads:

    
      one
      
      

      two
And you can render that in sexpr syntax as:

    (:pre "
      " (:span "one
      ") "
      " (:br) "
      " (:span "two") "
      " (:br) "
    ")
This is a particularly bad example to demonstrate here because the whitespace in the code plays badly with the whitespace in the HN markup. But I tried running this code and it does work. Here is the output copied-and-pasted verbatim from my listener:

    
      one
      
      
      two
Note that both BR tags are rendered as .

Re: Foolproof HTML

#99

Post by swhipple »

lisper wrote: post #98
kazinator wrote: post #97

Earlier quoted context omitted.

There are uses for pre with tags embedded. pre provides the simplified line breaking and usually a monospaced font. However, tags are available to do whatever else. A major example is that the Vim editor uses pre for formatting syntax colored code to HTML (when you do that with :TOhtml). The output is a pre block containing various span elements which are styled with CSS. BTW where in the HTML spec does it say that t…

> where in the HTML spec does it say that the interior of pre is parsed differently? I was wrong about that. I had a vague memory of putting HTML inside a PRE tag once and having it come out as if it were escaped, but apparently I hallucinated that. > A major example is that the Vim editor uses pre for formatting syntax colored code to HTML (when you do that with :TOhtml). OK, I stand corrected on that too. > If we a…

It was
and for my example ( isn't a valid tag). The point that I was getting at was that
and self-closing tag are represented differently (, , and are all different) in a parsed SGML data structure (though they both are equivalent in the HTML DOM tree in the browser).

This is why you would need separate tags to emit them properly with an S-expr syntax (tag), (tag/), and (tag)(/tag) in my example.

Re: Foolproof HTML

#100

Post by westoncb »

meredydd wrote: post #96
westoncb wrote: post #89

Earlier quoted context omitted.

Thanks for the reply meredydd. That does seem like a good approach. Actually, I spent 1.5 years building an editor in this style (see link in my original post here) while working at a grocery store :) Unfortunately, while I can see now that I should have first been super focused on validating the concept—I instead just kind of ran with it, assuming it was going to work, and built this massive, probably over-engineere…

"VB for web apps" is a fair summary. We made a conscious decision against anything AST-based (for the reasons I outlined above), and we're about to deploy an Intellisense-style autocompleter instead. Our general philosophy is that coding is fine - it's the web/Javascript ecosystem that's the problem. We fix that, then get out of the way and let you write code :) As for validating one's side projects before starting w…

> it's the web/Javascript ecosystem that's the problem.

I agree—that's definitely the bigger issue. I think differences between editors and languages tend to be overblown in general.

Unfortunately the project for me was not quite a fun thing: I ran into an issue with mouse/keyboard overuse, so I was trying to build an editor that could work efficiently with motion sensors. In the meantime, coding was painful :/ I'm still looking for an alternative for that reason—but VR and mobile also have needs for efficient editors that can be operated with fewer unique symbols.

Also, another solution to the AST editor issue: just convert any non-parsing nodes into plain text nodes until they're fixed.

Post reply on HN