

The thing I hate about HTML - jgrahamc
http://blog.jgc.org/2010/07/thing-i-hate-about-html.html

======
pmjordan
Technically, one of the reasons for closing tags is that HTML, like its SGML
heritage, allows a non-tree structure, which means tags need not be closed in
the order they are opened, e.g.:

    
    
      <b>bold only, <i>bold-italic,</b> italic only</i>
    

But that's so ridiculously rare in practice (and totally messes with things
like DOM traversal) that nobody missed it in XHTML, which, like its XML
ancestor, requires a pure tree structure. Yet XML still requires named end
tags, and so does modern HTML.

You can of course generate HTML from S-expressions, most Lisps have libraries
for it. I particularly like the Clojure notation of

['tagname {:attrname "attrvalue"} child-nodes...]

where {} denotes a map literal, but even if you use that, your client
JavaScript deals with the emitted ugly HTML.

The biggest problem I have with HTML and CSS, though, is that they're both
designed for marking up text, not websites. Divs and such are an afterthought.

Tangent: I failed trying to leave a comment on the blog proper. Some kind of
internal error delivering the comment.

~~~
baddox
Is that actually allowed? I remember my old HTML books when I was a kid said
you couldn't do that.

------
lhorie
If typing is the problem, there's the zen coding plugin to alleviate it

<http://code.google.com/p/zen-coding/>

As far as ending tags go, HTML actually allows optional closing tags in some
elements (<http://www.w3.org/TR/html401/index/elements.html>) and the proposed
idea of using </> would cause confusion:

    
    
      <ul>
         <li>bla
      </> <- what did I close here?

~~~
jacobolus
> _[...] cause confusion: [...] ← what did I close here?_

This was covered in TFA, except that JGC apparently thinks that having
optional tags is an attempt at DWIM that’s more trouble than it’s worth:

> _The browser magically says: “Oh, he must have meant to close that <p> tag
> so I'll do it for him.” [...] Given that the tags are meant to be balanced
> there's no reason to force the author to figure out which tags they want to
> balance and force them to write it down. It adds nothing. _

Personally, though, I think implicit end tags are just fine, as long as
they’re clearly documented and browsers have a standardized & predictable
parsing approach.

~~~
lhorie
>> This was covered in TFA

Not exactly... he basically said "let's drop the current spec and use lisp".

The thing I noticed when looking at language design though is that it's really
easy to say "language X should look like Y" but overlook something that makes
the whole proposal a really bad idea. Case in point: can you spot the problems
on his lisp example? (hint: elements vs text nodes, required escape sequences)

~~~
jacobolus
Well, okay. What I meant was that your criticism implied that he didn’t
understand/address implicit tags, while he clearly actually did, but just
suggested they be dropped.

I also hope his examples were more like a sketch than a careful proposal –
otherwise, as you said, there’s a lot of ambiguity.

Anyway, there are clear advantages and disadvantages to both models. I’m not
personally convinced that either HTML or S-expressions is an especially good
document format, at least not as far as a human trying to create a document is
concerned, but fortunately these kinds of languages are easy enough to
generate that the original source language can pretty much look like whatever
someone can imagine.

------
spooneybarger
haml is in part an attempt to rectify this situation. no need to worry about
closing tags. unfortunately, it comes with significant whitespace which puts
many ( including me ) off.

i do prefer to do my html creation in an intermediate language that deals with
closing tags and what not for me. be it a template language etc that can be
used at deployment time to create properly formatted html from an intermediate
language that is less error prone.

~~~
ifesdjeen
hm. Being honest, i can't see any other solution for that: you either care
about the number of spaces (python-style, haml-style) or care about the
parenthesis, or open-closing tags (ruby-style, html-style).

i love haml, and sass, since it's just speeds up development several times,
improves readability and eases the whole process.

~~~
spooneybarger
i prefer something that doesnt include sig. whitespace. s-exps are my
preference ( even if they are without parenthesis ).

things i really like:

clojure's basic html creation. seaside's basic html creation.

~~~
ifesdjeen
well, clojure certainly rocks. it will take awile for it to become mainstream
though. hope ruby people will help out with that. actually ruby did bring some
fresh air into our world :)

~~~
spooneybarger
based on my using seaside and clojure, mainstream obviously isn't an issue for
me.

i haven't done anything beyond toy projects with clojure so far. mostly
lurking on the mailing list for quite a while. i assume by 'our world', you
meant the clojure world. if yes, can you give some insight into the fresh air
that people coming from ruby brought to the clojure community?

~~~
ifesdjeen
actually, not. by 'our world' i meant programming (or even web-programming)
world. lots of innovations, at least web, were brought by ruby people.
afterall, clojure is getting popular among rubyists. maybe, it's more about
ruby guys being more interested in new stuff, maybe not. they're developing
libraries, hack it, use it, post stuff about it and, let's say, advertise it.

------
mike-cardwell
I find it useful to have the name in the ending tag. It lets you know which
block ends where, easily, when you have a deep structure. Eg:

</a>

</li>

</ul>

</tr>

</td>

</tbody>

</table>

------
gr366
The funny thing is that as an HTML page gets increasingly large and
complicated, I frequently see developers add HTML comments demarcating
precisely which element was just closed, so that in the future it's easier to
insert elements at the right level of nesting. Example:

    
    
      </div><!-- End of #section-nav -->
    

Would it be a horrible thing if HTML supported an optional id or class
attribute in the closing tag?

    
    
      </div id="section-nav">
    

Of course it would _have_ to match to validate. Probably not realistic in that
my guess is this wouldn't be SGML-backwards compatible.

~~~
pmjordan
An editor with good tag matching should in theory solve this for you. Of
course, HTML's complex rules of where a closing tag is required and where it
isn't makes this a lot harder than the simple paren matching you'd need for
S-expressions.

------
alextgordon
Couple of problems with the suggested syntax:

* You can't write lowercase letters without the possibility of it being mistaken for a tag. If I write (hello) and then a <hello> tag is introduced, I'm screwed.

* Parentheses are common in written English. It would be better to use [] {} or <>.

What you could do is substitute () for [] and use a : to introduce character
data:

    
    
        [font color="red"
          [center:
            hello, world!
          ]
        ]
    

But people would be forgetting that all the time. Another option is
significant newlines. That is, if a trimmed line doesn't start with a "[", it
is interpreted as character data:

    
    
        [font color="red"
          [center
            hello, world
          ]
        ]
    

Combined with the : to introduce character data, this is actually kind of
good:

    
    
        [font color="red"
          [center
            hello, [em:world]!
            [img src="photo.png"]
          ]
        ]
    

Compared to

    
    
        <font color="red">
          <center>
            hello, <em>world</em>!
            <img src="photo.png">
          </center>
        </font>

------
Padraig
Fair enough, but your use of long-ago deprecated HTML tags to make your point
doesn't exactly inspire confidence in your expertise!

------
bradleyland
It would seem possible to write a Lisp library that does exactly what you
described; albeit indirectly. The library would interpret Lisp data structures
and return well-formed XHTML. Think Haml, only Lisp. If someone were
interested in doing this, they should definitely have a look at Haml though.
There are some interesting methods for telling the Haml interpreter how you
want the content handled. Built-in support for escaping characters,
expansion/non-expansion, etc is really nice.

I know very little about Lisp, so this type of thing might already exist.

~~~
spooneybarger
There are already lisp/scheme libraries out there that do that. The smalltalk
framework's Seaside and Illiad both contain the same as well.

as a basic example from seaside:

renderContentOn: html

    
    
        html heading level: 1; with: 'Hello World!'.
    

creates

<h1>Hello World</h1>

More on how Seaside generates html can be found at:

<http://seaside.st/documentation/generating-html>

Here is an example from racket ( aka plt scheme ):

(define (build-request-page label next-url hidden) `(html (head (title "Enter
a Number to Add")) (body ([bgcolor "white"]) (form ([action ,next-url] [method
"get"]) ,label (input ([type "text"] [name "number"] [value ""])) (input
([type "hidden"] [name "hidden"] [value ,hidden])) (input ([type "submit"]
[name "enter"] [value "Enter"]))))))

More ( and the proper formatting of the above ) can be seen at:

[http://docs.racket-
lang.org/more/#(part.__.Hello_.World__.Se...](http://docs.racket-
lang.org/more/#\(part.__.Hello_.World__.Server\))

~~~
draegtun
And there are also libraries in other languages as well. For eg:

* There's Builders in Groovy (<http://groovy.codehaus.org/Builders>)

* Markaby in Ruby (<http://en.wikipedia.org/wiki/Markaby>)

* and Markapl and Template::Declare in Perl (<http://search.cpan.org/perldoc/Markapl> & <http://search.cpan.org/perldoc/Template%3A%3ADeclare>).

Here is the snippet in blogpost using Markapl:

    
    
        div('.red') {
            p { "hello world" }
        }
    

Also see related HN: <http://news.ycombinator.com/item?id=705698>

~~~
spooneybarger
My only problem with markaby is that all the do ... end for blocks sort of
defeats the purpose for me. not completely but partially. that said, i often
use it.

------
BerislavLopac
Actually this is the least of worries with HTML. Actually, it's main problem
is that it's so widespread, while being far from ideal syntax from marking up
content...

~~~
revorad
I guess it's widespread because it's simple and quite forgiving.

------
revorad
I have started commenting some of my HTML end tags so I know which div is
ending where. Otherwise it drives me crazy even with auto-indentation in
emacs.

~~~
spooneybarger
I found that long term, the comments get out of sync with the html and
eventually breeds confusion.

