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

101–110 of 110 posts

Re: Foolproof HTML

#101

Post by lisper »

swhipple wrote: post #99
lisper wrote: post #98

Earlier quoted context omitted.

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

You can do this:

     ==> (:tag)
     ==> (:tag nil)
     ==> (:tag "")
Using (:tag/) is a bad idea because that would screw up attributes.

CL-WHO doesn't support this, but that would be easy to change if it ever actually mattered to anyone.

Re: Foolproof HTML

#102

Post by swhipple »

lisper wrote: post #101
swhipple wrote: post #99

Earlier quoted context omitted.

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.

You can do this: ==> (:tag) ==> (:tag nil) ==> (:tag "") Using (:tag/) is a bad idea because that would screw up attributes. CL-WHO doesn't support this, but that would be easy to change if it ever actually mattered to anyone.

> In HTML, and are equivalent

In HTML, is valid. is invalid. is valid.
is invalid. So they are represented differently.

> Using (:tag/) is a bad idea because that would screw up attributes.

For my example?

    ((:tag/ :attr "value"))               => 
    ((:tag  :attr "value") "..." (:/tag)) => ...
> You actually can distinguish between those if you really want to. It's just a matter of picking a convention.

That sounds like it could work. So a leading `nil' would be treated as a special case (not a child node):

    (:pre "
      " (:span "one
      ") "
      " (:br) "
      " (:span "two") "
      " (:br nil) "
    ")

Re: Foolproof HTML

#103

Post by lisper »

swhipple wrote: post #102
lisper wrote: post #101

Earlier quoted context omitted.

You can do this: ==> (:tag) ==> (:tag nil) ==> (:tag "") Using (:tag/) is a bad idea because that would screw up attributes. CL-WHO doesn't support this, but that would be easy to change if it ever actually mattered to anyone.

> In HTML, and are equivalent In HTML, is valid. is invalid. is valid. is invalid. So they are represented differently. > Using (:tag/) is a bad idea because that would screw up attributes. For my example? ((:tag/ :attr "value")) => ((:tag :attr "value") "..." (:/tag)) => ... > You actually can distinguish between those if you really want to. It's just a matter of picking a convention. That sounds like it could work.…

> is invalid. is valid.
is invalid.

OK, then the best way to handle that is to let the HTML-renderer know that different tags need to be rendered differently if they're empty. Are there any cases where you would ever want to distinguish between the various kinds of empty tags?

    ((:tag/ :attr "value"))               => 
    ((:tag  :attr "value") "..." (:/tag)) => ...
No, that's not what you want. Let's start with this general form:

((:tag attr value ...) content ...) => content ...

Let's assume we have no attributes so I don't have to keep typing those. Then we have:

((:tag) content ...) => content ...

In this case (no attributes) we can unambiguously remove the parens around (:tag) and get:

(:tag content ...) => content ...

Now if we have no content we get:

(:tag) =>

All this is still completely regular, no special cases. But now if we write (:br) we get
which is not what we want. So we need to tell the renderer that some empty tags get rendered one way, and other empty tags get rendered another way. CL-WHO does this.

Notice that we have not actually typed any / characters. This is important. The role played by / in HTML is played by the close-paren in sexpr syntax. If we re-introduce the / into our new syntax we will have a hopeless mess.

> So a leading `nil' would be treated as a special case

That is exactly right. If (and this is a big if) we want to be able to write something equivalent to both and in the same document we have to be able to distinguish between those two things in the markup somehow. I just looked this up and the distinction that HTML makes between and is that the former content is EMPTY while the latter content is "" (i.e. the empty string). So really the Right Thing would be:

(:tag) =>

(:tag "") =>

That will work, but now we have to remember to add an empty string in some situations, e.g.:

((:script :src "...") "")

Personally I would find this annoying, so I would choose to go with the lookup table.

Re: Foolproof HTML

#104

Post by TylerE »

pg314 wrote: post #72
TylerE wrote: post #32

Earlier quoted context omitted.

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?

Yes, extensively.

In any half-way modern editor indentation-aware copy and paste/block indent/dedent is super easy.

Re: Foolproof HTML

#105

Post by sakamies »

westoncb wrote: post #90
sakamies wrote: post #88

Earlier quoted context omitted.

Your editor looks insanely slick! I had no idea there was prior work in this area. It sounds like your editor could trivially support html. That last paragraph is exactly what I was thinking with foolproof html, except applied to markup/data languages. Is your editor available to try somewhere?

Thanks! Unfortunately it's not available to try. I spent a lot of time building it in my free time and eventually got burnt out :/ It's still not to a point where it's usable (it's edit only). I'd love to revisit the project in some form, but time/money/other projects are obstacles at the moment. I still think the concept has merit, but the implementation is more difficult than it seems (including lower-level design…

My story is kind of similar, including the wrist pain part. I've been brewing this thing for a bit over ten years. I got burnt out for other work and the editor some years ago and had to take a long break. Last year I started about the tenth new prototype and finally got it on a path that I think could lead to something that actually works.

This time I'm trying to give away the code, ideas and everything, so maybe someday someone would continue the work so I won't have to. I just want to see it get made somehow and use the damn thing.

Re: Foolproof HTML

#106

Post by sakamies »

thangalin wrote: post #29
skierscott wrote: post #27

Earlier quoted context omitted.

Hm... I think this post is trying to solve a different problem. Markdown solves the problem of having content (paragraphs, lists) syntax free. This post: > What if you had to write a language where you can make mistakes, but there are no errors? Where your parser just silently accepts anything you give it. Where you'll have to carefully compare your intentions to the parsed output to figure out what went wrong. > Do…

> Looks like they're trying to make make an easy-to-write HTML for all HTML, not just content. Yes. I know it's a long thread, but pandoc issue 168 and the proposed "foolproof" syntax are, in essence, addressing the same issue. They both strive to shroud the nuances of HTML syntax in simpler clothing. Computationally, there's insignificant difference between this (proposed syntax): ; --- div {.foo} ; Ipsum dolor sit…

Westoncb said it quite elegantly: "I think the core idea involved is a shift away from using text as a model for representing programs; instead, interact with more abstract representations of code, and render those abstractions as text. This allows your editor to have better understanding of the language you're using, so syntax becomes a property of a language's visualization rather than something totally central to it (and now you don't have to memorize it!)."

Foolproof HTML of course tries to do that only for HTML, but I do hope I can expand it to CSS, JSON and maybe generalize it later on.

So I'm not advocating for any specific syntax, but rather a way to edit html so you don't need to care about the syntax. The HTML syntax would still be there in the .html (or .erb, .php or whatever your template language is) the same as it has always been, but you could visualize it in a way that's most comfortable to you and edit it as a structure, so it would be impossible to produce syntax errors.

This could end up being a text editor plugin or a stand alone app, some sort of library or kind of anything, but I'm prototyping interactions and ideas as a standalone web app because that's what I'm good at.

Re: Foolproof HTML

#107

Post by westoncb »

sakamies wrote: post #105
westoncb wrote: post #90

Earlier quoted context omitted.

Thanks! Unfortunately it's not available to try. I spent a lot of time building it in my free time and eventually got burnt out :/ It's still not to a point where it's usable (it's edit only). I'd love to revisit the project in some form, but time/money/other projects are obstacles at the moment. I still think the concept has merit, but the implementation is more difficult than it seems (including lower-level design…

My story is kind of similar, including the wrist pain part. I've been brewing this thing for a bit over ten years. I got burnt out for other work and the editor some years ago and had to take a long break. Last year I started about the tenth new prototype and finally got it on a path that I think could lead to something that actually works. This time I'm trying to give away the code, ideas and everything, so maybe so…

Hehe, I know the feeling.

Re: Foolproof HTML

#108

Post by pg314 »

TylerE wrote: post #104
pg314 wrote: post #72

Earlier quoted context omitted.

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?

Yes, extensively. In any half-way modern editor indentation-aware copy and paste/block indent/dedent is super easy.

> In any half-way modern editor indentation-aware copy and paste/block indent/dedent is super easy.

Sure. But I've made mistakes in Python because I didn't select e.g. the last line of a region.

If you've used both extensively and prefer whitespace to sexps, that's totally valid. De gustibus non est disputandum.

Re: Foolproof HTML

#110

Post by draegtun »

lisper wrote: 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…

I've also done this for years using similar tools in Perl - https://metacpan.org/pod/HTML::AsSubs | https://metacpan.org/pod/Markapl | https://metacpan.org/pod/Builder

Here's an example of something I'm currently using/building in Rebol:

    [ attr: value "content"]
Of course nothing new here because there have been other Rebol HTML dialects (for eg: http://www.hmkdesign.dk/project.rsp?id=html-dialect)

And there are plenty of CL-WHO related tools out there too - http://stackoverflow.com/questions/671572/cl-who-like-html-t...

Post reply on HN