I think this looks really great! Love the idea of the front matter enabling things like default classes.
Writing HTML or markup using something like Haml or Pug is just so much more enjoyable than using raw HTML/XML. The structure is forcibly clearer and you simply type less. I know some who like Emmet, but this is so much better than that. It's too bad that sometimes it isn't an option! =(
Actually just a method of enabling default classes for certain control sequences would be great, or some simple configuration for ie accessibility defaults(auto IDs, roles, etc). Give me that in a Markdown implementation and that's 99% of what I want.
Awaiting the 30 responses to implementations that already have this...
Agreed! If I need to debug it in chrome inspector (or similar) I don't like to have to think in terms of the abstraction I'm using to get the result I want.
Web development is complex enough (server side, js, css) without adding an abstraction layer to your markup too.
Try turning it over to non-technical people. You will be surprised at how non-intuitive html can be, and what extremely nasty things they will do when they decide to learn just a little bit, ie style attribute hacking galore. If you want dead simple, consistently styled content to be written by non-technical folks, Markdown is much better IMHO.
This is something that can change with a bit of training.
All the "plain text" formatting languages tend to break down. They work until they don't and then somebody invents yet another text-based pseudo-markup language. Asciidoc is best of the worst but fundamentally it's a bad idea. If you're willing to make the investment in tools and training there's a lot of value in enabling people to write real HTML (and MathML) or, better, Docbook + domain-relevant XML that produces real UI-agnostic structured information.
The problem here is that the tools are terrible or expensive or bloated. There's no reason why this should be the case and it's likely a real market opportunity.
Slim seemed extremely similar to Haml to me — the primary difference IIRC is that Haml uses more sigils (probably due to influence from Ruby). They both have that quality of basically reducing your document to a minimal syntax tree.
Seems pretty similar to pug/jade, other than not needing parentheses for tag attributes? (which admittedly, has annoyed me in pug) If I had to go to Ruby-land, I would use slim...
Looking at both and their timelines, I’d think pug may be based on slim which is a great thing.
Slim has been around for years, steadily improving and addressing corner cases.
I absolutely love it. Reduces typing by 50%, reading by 1000+%(as I re-read the code multiple times and it eliminates the multiple takes and looking for closing tags) and matches how my human brain thinks about markup.
I'm thinking these are "convergent evolution", especially since they arose in different language communities.
I totally agree that this is the best way to generate HTML. I use pug even for really tiny pages and templates. It amazes me that people like JSX, which seems like a total regression from building elements with function calls like React originally had. When I code Cycle.js in coffeescript it looks and feels a lot like pug; which is great.
I think Markdown is great for what it is, a simple way to mark up text with some simple html, in a way that's still easily readable as plain text. I dislike most extensions to markdown, since the point, for me, is simple use cases only.
Haml is almost the complete opposite IMO, since reading a document formatted with Haml does not result in elegant plain text, and it's not designed specifically for simple use cases.
This mixture of the two really irks me, as a result.
With SGML it's not an either-or. You can have both angle bracket markup syntax with HTML empty element rules, tag inference, and other short forms, as well custom Wiki syntax at the same time.
For example, you can say in SGML that the character '-' at the begin of a line when appearing below a particular parent element should start a line item, using a SGML shortref map/use declaration.
Blends particularly well with markdown eg. where in regular markdown you can use literal HTML, in markown+SGML you can make use of full SGML.
Ok, so usually I'm not a fan of the sarcastic "Hey, you just reinvented X! We've been doing that since the 90s!"
But in this case:
<h2 class=“f2 helvetica strike”>Fancy title <strong>with some bold</strong></h2>
Tachyons really seems to have reinvented the <font> tag. Like, exactly. Come on guys.
Edit: Apparently I'm out of the loop, and this style (atomic css) is now good. I'll take this as an opportunity to learn to refrain from making snide comments about fields I am not deeply involved in
I interpreted abraham's comment as "Right, it's just like the font tag, but the font tag is deprecated, so we use this instead". Implicit in my original comment was that "everybody knows the font tag is a bad idea so this is a bad idea too", which I think abraham missed.
That being said, apparently I'm wrong and this style is back in vogue. CSS Zen garden style design has just failed hard apparently, so this is how things are done.
You missed the point here. This is a marriage of two existing formats: Markdown, which you probably know, and HAML, a templating language that was popular with Rails and Sinatra for a while (less so these days, I think).
HAML uses CSS-like syntax to allow you to write HTML more succinctly: %div.foo.bar means <div class="foo bar">, for example. It has tons of short of concise syntax to make it a more pleasant alternative to HTML. It uses whitespace-sensitive indentation, like Python, so no end tags.
This isn't reinventing the font tag. It's an alternative to putting HTML in Markdown, which many people do because Markdown is very limited. Sometimes you need to insert something that isn't supported.
Not saying this is good, just explaining how your criticism doesn't apply.
That's not what Tachyons is. The people who made it and those who advocate Functional CSS (Tachyons, Tailwind, Atomic CSS etc.) have a clear idea what HTML < 5 used to be, what inline css is, why BEM and SMACSS exist, what js-in-css is, and in general know what they're doing.
I'm saying that to help apply a principle of charity when evaluating this idea that on first blush looks like insanity. But there is something in there.
Accessibility is often mentioned when it comes to the separation of concerns between HTML layout and CSS layout, but why would somebody try to adress blind people differently when it comes to semantics and hierachy? Wouldn't you want the same experience as seeing people?
This is a worthy effort. Markdown isn't quite there in terms of slightly more complex web sites, and Haml is definitely more complex for the simple things than I would like. I currently have a scheme where I have combined a bit of the perl Template::Toolkit and markdown so that I can write
%DIV sidebar%
##Interesting fact##
This fact it tangentially related
to the __content__ and will appear
in a sidebar.
%ENDDIV%
Which throws the <div class="sidebar"> .. </div> around the content. Basically by slurping it through the toolkit first, then markdown second.
It is still clunky and I always have to load all the perl dependencies after I do a significant upgrade to me dev machine but so far it works.
Before Markdown, there was another plain text markup system called Textile, which seems to be all but forgotten -- and I'm not sure "Hamdown" has a lot of advantages over Textile, beyond being more familiar to fans of Haml. (Which could be very important for many use cases, of course.)
The opening example in Hamdown's readme would look like this in Textile:
h1. Main Title
h2(f2 helvetica strike). Fancy title *with some bold*
Some content
I used to prefer Textile to Markdown (and I ran a web site using Textpattern, the CMS designed by Textile's creator, which still has one of the nicer template languages and plugin systems of any system I've used). I eventually gave up and joined the Markdown crowd, and I'm generally happy with it, but in some ways Textile is still superior. It has some aspects of Haml's "HTML but simpler" approach, but Textile still reads more like, well, text in a way that (at least to me) Haml mostly doesn't.
It's possible that Textile is a little bit too "middle ground": it's not trying to be a fully semantic markup language like AsciiDoc, but it's not as minimal as Markdown's "cover the common cases as easily as possible and fall back to HTML for everything else" approach, which I suspect is kind of what led Markdown to win. (Also what lets it get away with its "who needs specs" approach that drives some people nuts, of course.)
That suggests Hamdown might also be too middle ground, although it'd be more familiar to folks who are already Haml fans. Personally I always found Haml a little off-putting, but I have absolutely no good reason why.
If you create it in Ruby, you're going to have a bad time. The reason I love Hugo is that it is fast and compiles. I'd love to see an optimized implementation of a markdown language and template engine in C, but Hugo is next best.
rST is actually more like an easier to write and easier-to-read-as-plaintext HTML alternative, since it specifies a DOM-like document model, cross-document referencing and a well-formed mechanism for markup extensions.
Hamdown author here. To make it clear the I don't see this as a replacement for HTML/ERB/whatever templating solution for your web app.
The niche is rather narrow - it is for people who use static site generators like Jekyll/Middleman, and write content mostly in Markdown.
I often simply want to do a quick look-and-feel experiment by styling some of the elements with Tachyons. This is where Markdown becomes a bottleneck.
Another idea is to make front-matter a first class citizen of Hamdown so that you could add a bit of structured data on top of your blog post and use on the page.
P.S. You kinda can achieve this with kramdown, but I find its syntax super-weird.
So is this the "lean startup" equivalent of a Show HN?
"I have this great idea. buy it here!"
oh really we haven't implemented anything, but now that we see a bunch of people tried to buy it...
I'm fine with the idea of running ideas past the community here, but this really feels like a bait and switch. It's not a new markup language. It's a new IDEA for a markup language.
It doesn't look like it's trying to be a startup at all, just showing an idea to HN- but I guess you're saying it should be more of an "ask for early feedback on HN" instead of "Show HN"- which implies show something that is working. I'm OK with "Show HN" being the default idiom for anyone posting their own link. Guess it could have had a "(proposal)" or something in the title.
Agreed. I've seen this more and more where people link to incomplete proposals on GitHub, but have very misleading titles. At least they know how to work the system to get their content on the front page.
Why not just put HTML in your markdown? Lots of parsers support it, you rarely need it so who cares if it's ugly, it avoids having to learn another thing, and it lets you do anything.
Because Markdown works really well for content creators, but it could use a few extra features. I am not a fan of the examples they used, but believe Markdown could use some revamping.
`##### test` for example is not as efficient and easy to read as `#5 test`.
I disagree. The indentation of the extra #s makes it much easier to scan the document structure with your eyes. #5 would only make sense if you're only using your markdown as a source for translating to some other format and you want to save some typing.
I'm afraid I'll have to be one of the curmudgeonly naysayers, too.
The nice thing about Markdown is that the source file is just as readable as the output. Haml and hamdown fail at this. If I'm gonna have a computer parse "%h2.f2.helvetica.strike" for me, it might as well handle an entire HTML document.
Think of Markdown as a WYSIWYG format. The plaintext is the document, but there just happen to exist tools for automatically displaying it as HTML too. If something looks wrong as plaintext Markdown, you're doing Markdown wrong.
I know this isn't the fault of the author but I don't like the way periods seem to be overloaded in the Haml example:
%h2.f2.helvetica.strike
The first period denotes a tag on the left and a class attribute on the right, but the other periods just denote sibling classes. They don't parse into the same syntax, and my instinct is to read it as (h2 (f2 (helvetica (strike))) but that's not what's happening.
And adding significant whitespace to Markdown and everything else to me just serves to obfuscate and abstract away the one thing I most want in a markup language that emits HTML, which is to easily visualize the tree and the markup.
60 comments
[ 24.2 ms ] story [ 3584 ms ] threadWriting HTML or markup using something like Haml or Pug is just so much more enjoyable than using raw HTML/XML. The structure is forcibly clearer and you simply type less. I know some who like Emmet, but this is so much better than that. It's too bad that sometimes it isn't an option! =(
Awaiting the 30 responses to implementations that already have this...
Great idea though.
I much prefer HTML and erb.
Web development is complex enough (server side, js, css) without adding an abstraction layer to your markup too.
The problem with HTML is it’s verbose. So folks like to save some keystrokes (and mistakes).
All the "plain text" formatting languages tend to break down. They work until they don't and then somebody invents yet another text-based pseudo-markup language. Asciidoc is best of the worst but fundamentally it's a bad idea. If you're willing to make the investment in tools and training there's a lot of value in enabling people to write real HTML (and MathML) or, better, Docbook + domain-relevant XML that produces real UI-agnostic structured information.
The problem here is that the tools are terrible or expensive or bloated. There's no reason why this should be the case and it's likely a real market opportunity.
The spec for Markdown's syntax includes HTML in its entirety, though...
Then I found slim. It eliminates most of the markup, reducing it to its humanly readable essence, producing clean well-formed html.
Writing, and more importantly, reading only the meaningful part of the markup has helped my productivity skyrocket.
My eyes don’t have to struggle to figure out the document structure.
http://slim-lang.com/
For me, typing full html is no longer an option. Even with emmet I’d have to read it, multiple times, with all the markup syntax poking my eyes.
Slim has been around for years, steadily improving and addressing corner cases.
I absolutely love it. Reduces typing by 50%, reading by 1000+%(as I re-read the code multiple times and it eliminates the multiple takes and looking for closing tags) and matches how my human brain thinks about markup.
Pug (actually Jade at the time) v0.1: Jul 5, 2010
I'm thinking these are "convergent evolution", especially since they arose in different language communities.
I totally agree that this is the best way to generate HTML. I use pug even for really tiny pages and templates. It amazes me that people like JSX, which seems like a total regression from building elements with function calls like React originally had. When I code Cycle.js in coffeescript it looks and feels a lot like pug; which is great.
> I prefer just vanilla javascript, css, and html. They work fine, no bloated frameworks!
> What do you do for templates?
> Oh you just pipe it through a really simple shell script I devised. It's just a few lines
> ಠ_ಠ
Haml is almost the complete opposite IMO, since reading a document formatted with Haml does not result in elegant plain text, and it's not designed specifically for simple use cases.
This mixture of the two really irks me, as a result.
For example, you can say in SGML that the character '-' at the begin of a line when appearing below a particular parent element should start a line item, using a SGML shortref map/use declaration.
Blends particularly well with markdown eg. where in regular markdown you can use literal HTML, in markown+SGML you can make use of full SGML.
But in this case:
Tachyons really seems to have reinvented the <font> tag. Like, exactly. Come on guys.Edit: Apparently I'm out of the loop, and this style (atomic css) is now good. I'll take this as an opportunity to learn to refrain from making snide comments about fields I am not deeply involved in
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fo...
That being said, apparently I'm wrong and this style is back in vogue. CSS Zen garden style design has just failed hard apparently, so this is how things are done.
HAML uses CSS-like syntax to allow you to write HTML more succinctly: %div.foo.bar means <div class="foo bar">, for example. It has tons of short of concise syntax to make it a more pleasant alternative to HTML. It uses whitespace-sensitive indentation, like Python, so no end tags.
This isn't reinventing the font tag. It's an alternative to putting HTML in Markdown, which many people do because Markdown is very limited. Sometimes you need to insert something that isn't supported.
Not saying this is good, just explaining how your criticism doesn't apply.
I'm saying that to help apply a principle of charity when evaluating this idea that on first blush looks like insanity. But there is something in there.
Readings to get started: https://johnpolacek.github.io/the-case-for-atomic-css/
https://mdgriffith.gitbooks.io/style-elements/content/
Accessibility is often mentioned when it comes to the separation of concerns between HTML layout and CSS layout, but why would somebody try to adress blind people differently when it comes to semantics and hierachy? Wouldn't you want the same experience as seeing people?
It is still clunky and I always have to load all the perl dependencies after I do a significant upgrade to me dev machine but so far it works.
I'll try to keep an eye on it.
The opening example in Hamdown's readme would look like this in Textile:
I used to prefer Textile to Markdown (and I ran a web site using Textpattern, the CMS designed by Textile's creator, which still has one of the nicer template languages and plugin systems of any system I've used). I eventually gave up and joined the Markdown crowd, and I'm generally happy with it, but in some ways Textile is still superior. It has some aspects of Haml's "HTML but simpler" approach, but Textile still reads more like, well, text in a way that (at least to me) Haml mostly doesn't.https://txstyle.org
That suggests Hamdown might also be too middle ground, although it'd be more familiar to folks who are already Haml fans. Personally I always found Haml a little off-putting, but I have absolutely no good reason why.
Takashi recommends to take a look at these gems: - https://github.com/judofyr/temple - https://github.com/eagletmt/haml_parser
Hamdown idea is to enable automated content-generation by allowing ruby code embedding (like you can do with HAML)
The niche is rather narrow - it is for people who use static site generators like Jekyll/Middleman, and write content mostly in Markdown.
I often simply want to do a quick look-and-feel experiment by styling some of the elements with Tachyons. This is where Markdown becomes a bottleneck.
Another idea is to make front-matter a first class citizen of Hamdown so that you could add a bit of structured data on top of your blog post and use on the page.
P.S. You kinda can achieve this with kramdown, but I find its syntax super-weird.
"I have this great idea. buy it here!" oh really we haven't implemented anything, but now that we see a bunch of people tried to buy it...
I'm fine with the idea of running ideas past the community here, but this really feels like a bait and switch. It's not a new markup language. It's a new IDEA for a markup language.
`##### test` for example is not as efficient and easy to read as `#5 test`.
[0]: https://github.com/weaversam8/ctml
MarkHAML
The nice thing about Markdown is that the source file is just as readable as the output. Haml and hamdown fail at this. If I'm gonna have a computer parse "%h2.f2.helvetica.strike" for me, it might as well handle an entire HTML document.
Think of Markdown as a WYSIWYG format. The plaintext is the document, but there just happen to exist tools for automatically displaying it as HTML too. If something looks wrong as plaintext Markdown, you're doing Markdown wrong.
And adding significant whitespace to Markdown and everything else to me just serves to obfuscate and abstract away the one thing I most want in a markup language that emits HTML, which is to easily visualize the tree and the markup.