Don’t Make Me Write HTML | Hacker News Reader

Don’t Make Me Write HTML

linux-mag.com

35 pointsnreece35 comments

Oh please. The time you spend learning HAML or Markdown (and all their potential intricacies) could be better spent learning to write clean HTML. I'm sure that both of those "alternatives" have their own quirks that must be worked around, not to mention the fact that you don't know exactly what HTML the parsers will spit out (yes, you can learn the output, I suppose, but why?).

I can see these tools being useful in certain circumstances, such as a way to provide HTML-esque markup somewhere where you don't want to bother cleaning up someone else's potentially malicious HTML (a wiki, a comment form, etc.). However, for building actual websites, just do it the right way.

Sure, these alternatives are nice in that you can avoid the scary HTML, but in the end it is all HTML anyway -- so why not learn it from the start and produce better code than what a parser will spit out based on your abstraction?

I would agree with you if you were talking simply about Markdown, but it seems you don't understand the point of HAML. Markdown is a complex syntax that loosely translates to half of HTML. It's good for user-input, because it's designed to be written like users already write stylistic formatting when the result will be plain ASCII, but it's not HTML.

HAML is HTML—it's a one-to-one conversion—but it's simpler and more concise to write. It's what HTML should be: no closing brackets, no line noise, and simple syntax to access DOM-relevant attributes (class and id). If I had the option of immediately converting all HTML worldwide into HAML, and all HTML parsers into HAML parsers, I'd sign up in a second.

Also, I don't need to see the raw HTML any more, because that's not the point: it's like looking at machine language instead of assembler. They're equivalent, so why read it the painful way? When debugging a page layout in HTML, I actually find it more useful to convert it into HAML first.

Having had to use and debug HAML before, I absolutely hate it. I would argue that it is more difficult to read HAML and leads to buggier code. Missing what amounts to two spaces can break your layout without you realizing it until much later.

This is especially true if you use a CSS framework where you have lots of nested elements with several classes each.

After looking into HAML again (I've looked at it before, and I'll admit, I clearly missed the point), I'll concede.

It does make HTML look significantly cleaner since it seems to run along the same general concept as Python (indents are blocks), and that is something I can support.

I'll be looking into giving it a try next time I have a good chance to...I appreciate the explanation.

"it's a one-to-one conversion"

are you absolutely sure about that? No edge cases around the whitespace?

"it's like looking at machine language instead of assembler."

That would only be true if HTML tags were specified by number.

"They're equivalent, so why read it the painful way?"

HAML is more readable only in the sense that it forces a certain indentation structure on you. If you are working with well-formatted HTML than there is not much benefit there. Overall, when HTML gets deeply nested, I'd rather see the ending tag.

As far as writing is concerned, yeah, HAML is a big win if you don't know how to use your editor. I solved that problem 10 years ago and I didn't have to switch to an format no one understands to do it. Let me put it this way:

If HAML had the same tooling support as HTML, and if other people were as likely to understand it, and if it didn't require a compilation step, then the benefits of HAML would be clearcut. As it stands, HAML just doesn't offer anything compelling to me (SASS comes closer).

Amen brother! Preach it. Sing out the good word across the land. Over the hill-tops and down to the valley below.

Everybody who knows HTML knows HAML. Actually learning HAML would have still given you time to write a paragraph complaining about it.

You are completely missing the point of HAML.

HAML is for people who know and use raw HTML, but who would rather not spend time on typing closing tags and all other syntatic sugar and line noise. HAML allows writing pages using leaner and more concise markup, all the while improving its readability.

> rather not spend time on typing closing tags

Isn't that what Emacs is for?

Vim!

Although I must admit you've got a point there, it's a bit like Atwood's indentation piece yesterday, why bother fussing over that when your editor can sort it for you?

The point is that HTML is a standard format that many tools and people are familiar with. HAML is not. While HAML might be more succinct, there is a tradeoff being made that is probably not appropriate for all situations.

I can agree with that, I wouldn't use a code-based markup generator simply because I couldn't see how you'd add design-based containers and things in there. Seems to eb good at producing semantic content markup, but not for full pages.

Markdown is for writing content. Content creators shouldn't need to write their content (blogs, news, whatever) in HTML. Markdown is for that and only that.

I also like it for readmes on github, FWIW.

Right. Any (those I can think of at least) type of content that doesn't require specialized formatting (math symbols, etc) like READMEs, blogs, journals, CMS content, etc.

Don't make me click past an advertisement. I mean, what the hell? Since when did super-obtrusive advertising not alienate people?

(It doesn't show up all the time, so you may not have seen it.)

I didn't see it the second time I clicked the link so I don't think it's something the linker can control.

I saw it for each of the 2 pages.

The closing tags of HTML and XML are a nuisance. In SGML (their common predecessor), named closing tags were optional (you used </>), but were deliberately made mandatory in HTML and XML, to improve readability of long documents. It was contentious at the time, and it still is. But we must at least accept the data points that both HTML and XML have been phenomenally successful, without knowing for sure whether this particular feature was for or against.

One thing about dumb, regular, symmetrical formats is that their redundancy makes them less scary and easier to understand. Perhaps, this is accessibility is crucial for adoption.

EDIT I guess indentation enables you to match up start/end tags even better than named close tags... and it's certainly become more familiar to developers since Python's success. But maybe not so good when you have many levels of indentation, and terrible if you want to insert/delete a nested element, because the indentation of the elements within it must also be changed.

I think you'd be surprised at just what you're allowed to omit in HTML. For example, the following document is valid HTML 4.01 Strict:

  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
  <title></title>
  <p>

The 'html', 'head' and 'body' elements -- opening and closing -- are inferred at the correct points by a compliant parser, as is the closing of the lone 'p' element.

Once upon a time on my personal blog, I used minimal HTML 4.01 Strict (omitting tags and other bits of syntax whenever and wherever possible -- I had a Markdown fork that knew how to do this within the constraints of the spec); my one concession was a longer DOCTYPE declaration to deal with anything that didn't know how to resolve the public identifier. Browsers actually handled it just fine, but some other systems (in particular, OpenID autodiscovery) failed, because they weren't actually doing HTML parsing.

You're right, I'd forgotten about omitting the closing </p>, but I think that's the only one (omitting a whole element - both open and close - is something different).

Of course, in practice, most HTML parsers will do a wonderful job of interpreting malformed HTML.

It's not the only one. You can omit closing tags for td, tr, th, li, and probably others I don't remember. I actually do this; it doesn't make the resulting document any less clear for humans, and so if I'm typing it myself, there's little point in inserting them.

The main reason that SGML allowed closing tags to be optional was that it was 80s technology and storage was expensive.

To omit tags you needed a DTD that allowed the parser to infer where the close tags should go.

Enforcing the use of close tags in XML meant that building a parser was much simpler and that you no longer had to supply a DTD which I think were probably very instrumental in XML's success.

I've spent so much time dealing with needlessly complex, over-engineered web applications who's primary architectural goal was to allow the primary developer to never code HTML that this article makes me sick.

An HTML form is the simplest representation of a form's presentation you're going to get. Suck it up, use HTML templates.

I agreed completely with the first comment:

Please don’t make me write in any of these simplified markup languages, either. And, really please, don’t ask me to embed code in the language, or one of these languages in code.

I'm not a big fan of using markdown for creating HTML, but using a CSS compiler has definitely been helpful for me in writing CSS. Nested styles makes your code much more maintainable, and makes inheritance easier. Plus, variables and basic arithmetic operations are nice.

CleverCSS is a CSS compiler pretty similar to Sass, which I tend to prefer for the simple reason that Sass requires my indents to be two spaces, and it doesn't matter in CleverCSS. The only problem is that it doesn't seem to be maintained anymore, and there are a couple of annoying bugs in the official release. I submitted patches but to no avail, so I'm hosting the patched code here: http://django-css.googlecode.com/files/CleverCSS-0.1.2.zip

I was so pumped on CSS compilers that I wrote this so you can use them in your Django projects: http://django-css.googlecode.com

Lately, I've been using Pandoc (http://johnmacfarlane.net/pandoc/) which is a better markdown than markdown (uses a parser rather than regexes). It also knows how to convert between lots of different markups it can read LaTeX, HTML, reStructuredText and markdown. It can write that and many more. I use it to convert LaTeX into S5 presentations and HTML; very nice for giving talks.

That is so funny: Programmers, that don't know what to do with their time, develop an api so the don't have to read documentation. Or programm a framework, or another abstraction layer on top of all the others or some meta-something to simplify the easy 80% of a job.

Sadly, creating things totaly disregarding the environment seems to have so much more sexapeal than just using what's at hand.

I wouldn't feel comfortable using something like markdown until I had a firm grasp of how it works and the kind of html it writes.

And at that point, I guess I might as well write good ole html... Unless browsers _universally_ supported a new better language, I'd hate to have to think of browser nuance in two different markups...

I use Markdown when I'm writing content-heavy prose, like wiki pages or READMEs. When I need more control over the exact classes and tags, HAML is a good alternative to HTML.

In the case of Markdown prose, I don't /care/ what kind of HTML it writes. Headers, paragraphs, links, all taken care of. I write text, it gets run automatically through a parser/html generator (I use maruku), and I don't think about it. HAML is great for templates & layouts, when I care about DIVs and ids and classes, without being the wordy, ugly HTML itself.

Is this link a recursive joke?

All I got is a grey page with "Click here to skip this or wait 15 seconds.". The link does not work.

I have JavaScript disabled with NoScript FireFox extension.

Judging from the HTML code of the page it seems that the authors of linux-mag.com don't know how to use noscript or meta redirect tags.

Use a WYSIWYG? I mean if you seriously can't wrap your head around HTML/CSS maybe you're in the wrong business...

killerweb's comment at DZone is pretty insightful -- http://www.dzone.com/links/dont_make_me_write_html.html

I guess I am the lazy one - I just use an IDE web designer in design view, then switch to code view as needed. Benefits from both worlds.

If it is basic listing table and the sort - Use Mac TextEdit and save as html or use the MS html editor. There are tools.

why not just use an editor that has shortcuts and automatically closes tags? textmate and others "write" a lot of the html for you.

Reply on news.ycombinator.com