No one likes writing -- or reading -- HTML. Thankfully there are tools like Markdown, HAML and SaSS to make your hypertext life easier.
I hate writing HTML. Wait. Let me rephrase that. I hate writing and reading HTML.
Compared to Ruby, Perl, and even SQL code, HTML is just so… verbose. Crafting open and close tags is taxing; nesting is error prone; and it’s difficult to simply glance at HTML to grok its purpose. CSS is even worse. Because a stylesheet is a long, flat, unstructured list, it’s nigh impossible to discern those cumulative rules that apply to nested elements. A good editor helps, but syntax coloring is often just a shiny veneer.
And many concur with my distaste for HTML. Alternatives, such as Textile and Markdown—aptly named since it’s intended to be the opposite of markup—provide author-friendly shorthand that is programatically promoted into full-blown HTML. For example, the Markdown snippet…
Ordered lists use numbers followed by periods:
1. Bird
2. McHale
3. Parish
… produces the HTML…
<p>
Ordered lists use numbers followed by periods:
</p>
<ol>
<li>Bird</li>
<li>McHale</li>
<li>Parish</li>
</ol>
Markdown is very natural to write—it resembles text you might put in an email, say— and thus very easy to read, too. It’s no wonder that many content management systems, blogs, and wikis support simplified markup of Markdown’s ilk.
Ideally, Markdown would replace weighty, tagged text in my applications, but it wasn’t designed to be a wholesale replacement for HTML and provides no relief for CSS. Yet, the notion is very appealing: Keep (or add) structure, lose the infernal typing.
And that’s the exact charter of HAML and companion SaSS. HAML (short for XHTML Abstraction Markup Language) expresses HTML in an outline form, while SaSS (an acronym for Syntactically Awesome StyleSheets) does the same for CSS. Both provide conveniences such as macros and expressions, and structure is implied with active white space (a la Python). You can also embed code in outline form: no blocks required.
I use HAML and SaSS with Rails, but implementations of HAML are available for Merb, PHP 5, Python, and .NET. And if your programming language does not yet support HAML or SaSS, have no fear! There are command-line utilities to convert the minimalist templates into HTML and CSS. There’s also a pair of utilities to reduce HTML and CSS to HAML and SaSS, respectively.
I eschew other templating forms in favor of HAML. It makes me very productive, even happy to craft Web pages and forms. Let’s take a look.
Less Code, More Joy
At left is HAML; at right is the equivalent HTML generated with the haml command-line utility.
!!! XML
!!!
%html
%head
%title
Example
%body
%h1 You can place text on this line
%p#vip.prose
Or you can put more lengthy text
here as content.
<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD
XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/...">
<html>
<head>
<title>
Example
</title>
</head>
<body>
<div id='main'>
<h1>You can place text on this line</h1>
<p class='prose' id='vip'>
Or you can put more
lengthy text here as content.
</p>
</div>
</body>
</html>
HAML is concise and its syntax is simple. For instance:
- To use an element, preface its tag with %, such as %head and %p.
- You can assign an ID to an element with the clause #your_id. You can assign one or more classes to an element with a set of .your_class clauses. You can also combine the two kinds of clauses.
- If the element is a div, you can omit %div and it is inferred.
- To nest an element or place content within an element, simply indent two spaces. For convenience, you can also place content on the same line as the element, if the text is short.
This first example does not demonstrate all the syntax available. You can find the complete HAML reference online.
HAML is full of other tricks, too. If you like Markdown, you can embed it in HAML. A filter expands the Markdown in place. This snippet…
%div
:markdown
Example 2
=======
Hello, *World*
… produces:
<div>
<h1>Example 2</h1>
<p>Hello, <em>World</em></p>
</div>
In the HAML code, the keyword :markdown invokes the eponymous filter. A filter exists for JavaScript, Textile, SaSS, plain text, and Ruby code, among others.
And because all browsers aren’t equal, you can also insert Internet Explorer conditionals using /[condition].
/if[IE]
%p
Use the Firefox, Luke.
The slash (/) denotes a comment in HAML. You can use slash to comment a single line or an entire, indented section.
/ This is a single-line comment
/
#footnote
%p None of this will render since its part of the comment
Comments on "Don’t Make Me Write HTML"
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.
Guess what- once it is as functional as HTML, it is as complex as HTML. So it depends on indentation instead of tags. I’m not seeing the big win here, unless neurotic phobias of HTML are involved.
What I was hoping to find in this article was some FOSS WYSIWYG HTML composition tool. Something that generates much better HTML than Front Page. OK, a complete expectation miss on my part, my bad.
-Ken
I agree with kmarsh. When it is as functional as html and css it will be complex too.
Also, Saas is already a taken acronym. (Software as a service). You know, the Saas model? I really am getting sick of acronyms for everything. Like DSL stands for Digital Subscriber Line. Not Dam Small Linux. Ok I’m about to start ranting off subject.
Although SaSS do add some structure to a language that was not intended to be structured, thus making it more legible, I second kmarsh’s opinion: no big win here if you code websites by hand. Unless you use PHP or Ruby extensively: then it makes perfect sense to have auxiliary scripts to aid the code generation.
kmarsh: you may want to try the now discontinued NVU or W3C’s Amaya.
I agree with k405 and kmarsh…
If i’m right the context in which this article is written, the idea of simplifying HTML generation/editing by something alike hyper tagging of users content.
The trouble is content is a little more complex than simply saying “list” or “image” here!.
Nothing really makes markup writing simple, much less xml by xslt(a version of 1. below i will also make an alternate for).
The only thing you can actually do is supply a pre determined format of the content and simple policies about content types to hold it on the straight and narrow.
That is exactly how every web site CMS system operates particularly with signed up user submitted dynamic content.
I have two different approaches to HTML markup for easy generation.
1. someone wants to embed “content”.
or
2. someone wants to make markup handlable by indexing it in a perpetual ordering of hierarchy.
1. Is done by a WSH script controled by a few little things a guy might want to put in the HTML file but is ultimately text controlled(i will make a shell and a PERL script also). It supplies a wrapper around the content by a simple text file to order and adjust the content.
2. Is also remaining under development but fundamentally available too. Its a text editor for scripting and markup that has a special symbols list that approaches coding by using the most common repetitive symbol constructs and requirements for language type.
It also has a special tool for common list creation or markup repeating problems of requiring indexing.
As you know you cannot bind program data to content data, but this has a system in part to do exactly that by tokenised indexing.
1.
nicephotog-jsp.net/nicephotogs-site-blaster.js.html
2.
nicephotog-jsp.net/SUcommanderXer-Last-Pre-Beta.jsp
No big win.
But it would be if not only format were able to be condensed for the user…
BUT the policy for content too!
Thanks k405, I will check out Amaya and NVU’s seeming successor, Kompozer. I failed in a Google search a couple of months ago looking for something like these. My problem was using the terms HTML Editor, instead of Web Authoring. My quest has been very low-key, but some day I’ll need a solution NOW and it would be nice to have some already loaded and ready to evaluate.
What about groovy?
import groovy.xml.MarkupBuilder
def writer = new StringWriter()
def xml = new MarkupBuilder(writer)
writer.append("\n")
writer.append("\n")
xml.html {
head {
title("Example")
}
body {
div(id:"main") {
h1("You can place text on this line")
p(class:"prose",id:"vip","Or you can put more lengthy text here as content.")
}
}
}
print writer.toString()
Jonathan Wolfe, a longtime front-end developer, sent me this comment to post:
I’ve been usging HAML for over a year now, and would rather not do frontend development at all than have to switch back to RHTML or some other templating language for the frontend. The people posting comments that a tool like HAML becomes less useful as a layout gets more complex have it precisely backwards.
I disagree with what Mr. Wolfe says based to the final point of use of template languages “in this discussion context”, that of being to have a fast and quick accurate language to learn and apply to replace direct HTML coding that is extremely easy and flexible in outcome to manipulate morphises of graphic display and associate parts/services of it.
These languages often apply to whether the web server and or deal contains the language used to drive the template library.
E.G. you will not operate HAML using JSP unless you write such a library of “tie-class and classes custom JSP tags” and your server operates a Java2 SDK.
You will not operate Smarty PHP template language on an ASP server unless PHP is an option.
To serve the idea sensibly for fast HTML under mr. Wolfe’s way of seeing, unless an agent of the product, a coder will need to know at least these three before-mentioned template languages for (server usage availability to a business user)leverage and their underlying three non generically related programming language backing drive(do context) too.
The overhead in not properly knowing HTML to the level that you can build your own print() object script for the replaced HTML segment is what this problem with template fast HTML languages is about, not whether they will replace chunks of HTML.
We know the scripting languages behind them operate.
When you use those templating languages you join those whom are “chained to the wheel” , for example those whom use JSP. Think of the “learning overhead” in coordinating building with JSP (custom tags) by and for the technique used to produce HAML and other templating languages such as Smarty.
At this stage it appears PHP has been the closest to committing server side CGI for templating.
The above coding simply replaces print() scripting in an object that will be designed for a “larger than one tag purpose” that is in effect “alike a policy” for “wrapping the content” (also generally repetitively).
Knowing (X)HTML and CSS is the key to ever using any of these languages and they are server specific for the driving language of the tag libraries. We all know we can break coding into repeatable sequences. What was wanted was not an alternate such as templating languages.
We want it all(maybe, but we can all code XHTML with namespaces and bind CSS to it with namespaces here), a way of wrapping content both flexibly and accurately but found a glorified print() statement restricted by its server language for sensible distributive offer to customers.
The extra we want is the complexity to be simplified by some type of tuning of the way we go about using it, not having giant language learning and usage ability overheads.
My thoughts on that for a reality mean XML as a tagging base and its output system in XSLT would be the only real delivery if such a language system existed.
I’ll say it again, we can all code complex (X)HTML and CSS here and call print in an if else of an inline server side script.
Based on a couple of attempts to ‘coding’ with HAML/SASS and hard pressed, I’d have to second the initial comment by kmarsh – but in parallel I would have to ask a question too: Are we not really measuring two non-measurable issues?
HTML – by the capable hands of Tim Bernier-Lee – was meant to add enough structure to information in order for search engines being able to seek and find and for information servers (web-servers) in order to share in a uniform way, information.
This meta-data is by nature not ‘designable’ but merely wrappers if you like, and as such, ought to be automagically added on-the-fly by what ever ‘View’ framework-part, be it Rails, PHP, Perl, etc. In this context, HAML is a ‘plugin’ offering shortcuts to dealing with these “automagical moments” – and if I’m correct, has evolved a lot in recent versions, but sure: Rails’ View could lend a helping hand :)
What Tim did not envision (or underestimated) was the monumental impact his ‘creation’ had on information-sharing in a much broader context – commercial information shaping (where form rules matter).
Developers and, sadly lagging behind, the w3.org, has done a great job at trying to undo the done part: separating form from matter, but I’m certain that anybody old enough to remember WordPerfect 5.1 also remembers what a terrible slump in productivity is was when the Office Suite paved the way to form over matter, office automation wise.
History seems to repeat itself but with an ever increasing number of browsers and views (from cellphones via smartphones, the Iphone, netbooks, kiosk sized displays to TV displays and large-size monitors) the task of perfecting form is really a Sisyfos job!
Perhaps we really have to step back and ask the crucial question: would the user be better of do the ‘design’ him/her self?
Should we add a few ‘guide-lines’ to layout-software sitting in the browser – like: this box is nice-to-know, that triangle is a commercial and those three circles represent some ‘toppings’ graphics; and leave it to the user to arrange information to her/his own likings? (kind of grease-monkeying to those with advanced Firefox-feets) :)
For ‘picture-perfect’ presentations the web has long surrendered to Adobe Flash & Friends – and only A Few Good Men keep fighting their way through relentlessly trying to hack CSS, (X)HTML and what have we not together to sweeten the experience – and bitter sweet it usually is :(
Have I lost it completely (falsely implying that I ever had ‘it’)?
HTML, CSS, XML are standards for developing web pages. If one thinks they are to complex, pleas propose new, better standard which gives designers more power with reduced complexness. I do not think it is easy nor possible now.
Each tool/language like HAML is just another layer and another thing to learn and waste of developers time. Ideally programmers should not touch “view” and leave it out for web designers with Adobe like toys. They like HTML and CSS.
…(wdiechmann)”HTML – by the capable hands of Tim Bernier-Lee – was meant to add enough structure to information in order for search engines being able to seek and find and for information servers (web-servers) in order to share in a uniform way, information.”…
–What were after now is a way of automatically recognising users concieved data and formatting it for them while as much committing simple physical graphical layout controls by binding between the types of data and tagging correctly.
Bit huge for a thought!! really, isn’t it!! much to hope for because its an idea far beyond a WYSIWIG and is doing both a developer and a designers job.
Its little wonder templates were invented andapopular method of operating an IDE for automatic design aside a WYSIWIG.
…(wdiechmann)”This meta-data is by nature not ‘designable’ but merely wrappers if you like,”…
–..Is what XML was created to supercede and was in part itself superceded by SQL databases integrated to websites.
…(webprog)”is just another layer and another thing to learn and waste of developers time”…
–Agreed but it probably can be brought ot its competitive level of efficiency against others.
HTML is for most thought of in this articles context as “graphical layout” of a page. True information of a non graphical format is present, but that was the real difficulty in the situation.
***Binding data to a format(physically viewed or invisible because of a program classification for machine use in sync) correctly and automatically whether HTML or XML for a modularised approach e.g. like object mapping for databases ORM or crudely for languages CORBA-IDL e.t.c.***
Interesting too is the severe relationship between HTML5 services of 5′s tags and XML which seeks to “define data by bulking into a class by tag names (and other xml parts)”
i think that there we will always be difficulty in any markup language
because it becomes easily a obfuscated . The amount of difficulty rises up
with the complexity of data and the level of nesting.so more nesting more problem.
to put it simply if we have a site with only 2-3 ordered lists 2-3 paragraphs and a h1 tag everything is simple. but everything little more complex becomes difficult to read.
The question that rises here is how people already are able to make so many complex websites?
ofcourse it is the experience of a trained eye .
but there must be something else going on here …
So my opinion for making things easy is to exhaust all the usefulness of tools you may have in your toolbox . I mean use all the power of your programs .
I am totally against learning a new layer of html or any mark up language.
Examples:
make a good plan in your head and on a paper
don\’t write any complex css until you finish the project
use clear and meaningful identifiers (ids,class Names , etc etc )
use absolutely proper indentation
Finally use an editor that supports code folding, different coloring or each language (php,javascript,(x)html,css), line numbers,
auto completion, and visual guides for the begining and ending of each tag . 2 Great editors that comes in mind first are Eclipse(or Aptana)
and Komodo Edit.
Everything is complex until we start looking at it as being a simple thing
because nothing (yet) is more complex than a human mind . ;)
:-)