The thing I hate about HTML(blog.jgc.org)
blog.jgc.org
The thing I hate about HTML
http://blog.jgc.org/2010/07/thing-i-hate-about-html.html
10 comments
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:
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?> [...] 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.
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.
>> 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)
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)
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.
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.
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.
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.
I used to shy away from haml due to the significant whitespace. This apprehension went away after I forced myself to use it on a few projects, and now I hate working without it, for all the reasons jgc mentions in his article. It's not quite sexps, but it's a huge step up.
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.
i love haml, and sass, since it's just speeds up development several times, improves readability and eases the whole process.
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.
things i really like:
clojure's basic html creation. seaside's basic html creation.
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 :)
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?
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?
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.
Have you looked at JUP (http://github.com/fernmicro/JUP)?
I haven't. If I need to do xhtml creation from javascript at some point, I might give it a try. ( Perhaps if I get around to playing with env-js - http://github.com/thatcher/env-js ).
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>
</a>
</li>
</ul>
</tr>
</td>
</tbody>
</table>
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 -->
</div id="section-nav">
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.
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:
* 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!
]
]
[font color="red"
[center
hello, world
]
]
[font color="red"
[center
hello, [em:world]!
[img src="photo.png"]
]
]
<font color="red">
<center>
hello, <em>world</em>!
<img src="photo.png">
</center>
</font>Fair enough, but your use of long-ago deprecated HTML tags to make your point doesn't exactly inspire confidence in your expertise!
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.
I know very little about Lisp, so this type of thing might already exist.
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
<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...
as a basic example from seaside:
renderContentOn: html
html heading level: 1; with: 'Hello World!'.
<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...
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:
* 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" }
}
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.
There are probably dozens lisp libraries that do exactly this. Pretty much every lisp developer writes one.
A bunch can be found here: http://www.cliki.net/Lisp%20Markup%20Languages
Examples: http://www.cliki.net/HTML-TEMPLATE http://www.nicklevine.org/play/xhtml.lisp http://www.cliki.net/yaclml http://www.cliki.net/CL-WHO
A bunch can be found here: http://www.cliki.net/Lisp%20Markup%20Languages
Examples: http://www.cliki.net/HTML-TEMPLATE http://www.nicklevine.org/play/xhtml.lisp http://www.cliki.net/yaclml http://www.cliki.net/CL-WHO
Yes, they do exist. Check, for instance:
http://weitz.de/cl-who/ and http://weitz.de/cl-who/
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...
I guess it's widespread because it's simple and quite forgiving.
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.
I found that long term, the comments get out of sync with the html and eventually breeds confusion.
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.