
Don’t Make Me Write HTML - nreece
http://www.linux-mag.com/id/7293
======
endtwist
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?

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

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

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

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

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

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

~~~
10ren
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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

