Show HN: New markup language for fans of Haml and Markdown(github.com)
github.com
Show HN: New markup language for fans of Haml and Markdown
https://github.com/inem/hamdown?
60 comments
We use Textile on our Redmine install. It's not terrible, but it always seems like I am writing more markup than should really be necessary
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.
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.
I feel like they were both equally popular in ~2007, but Github-flavored markdown killed Textile.
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
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.
%DIV sidebar%
##Interesting fact##
This fact it tangentially related
to the __content__ and will appear
in a sidebar.
%ENDDIV%
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.
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.
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.
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:
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
But in this case:
<h2 class=“f2 helvetica strike”>Fancy title <strong>with some bold</strong></h2>
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
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.
Readings to get started: https://johnpolacek.github.io/the-case-for-atomic-css/
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/
Why not go one step further (like Style Elements in Elm), and reduce CSS & HTML to layout and style?
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?
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?
Ok, that's interesting. I guess I am out of the loop on this one
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.
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.
Sorry for the confusion, I'm not criticizing hamdown, I'm commenting on the tachyon project that is linked to from the hamdown documents
The font tag is considered obsolete by MDN.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fo...
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fo...
I'm trying to understand your point. Are you saying that in support of habitue's comment, or as a counter-argument?
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.
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.
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.
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 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! =(
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...
Awaiting the 30 responses to implementations that already have this...
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:
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.
%h2.f2.helvetica.strike
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.
I'm not sure if the advantages are significant enough over using haml markdown filters (last example) to warrant creating an implementation.
Great idea though.
Great idea though.
The first example already seems so wrong as it sets the documents style in the content.
This reminds me of a fun personal project [0] I implemented a few years ago. Very similar syntax.
[0]: https://github.com/weaversam8/ctml
[0]: https://github.com/weaversam8/ctml
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`.
`##### 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 think making the spec easy to write and easy to parse would be huge. Have you tried creating any parsers yet?
Nope, no yet. But I've got few recommendations from hamlit gem author Takashi Kokobun.
Takashi recommends to take a look at these gems: - https://github.com/judofyr/temple - https://github.com/eagletmt/haml_parser
Takashi recommends to take a look at these gems: - https://github.com/judofyr/temple - https://github.com/eagletmt/haml_parser
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.
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.
"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.
I know I'm very likely to be in a minority here, but I hate both Haml and Markdown.
I much prefer HTML and erb.
I much prefer HTML and erb.
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.
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.
I also preferred the clarity of unambiguous plain code.
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/
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/
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.
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.
Slim v0.1: Sep 15, 2010
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.
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've used slim too. I have the same opinion of it as Haml.
I can understand that.
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.
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.
You're not alone. I hate non-HTML languages for generating HTML. It's a perfectly fine syntax.
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.
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.
>If you want dead simple, consistently styled content to be written by non-technical folks, Markdown is much better IMHO.
The spec for Markdown's syntax includes HTML in its entirety, though...
The spec for Markdown's syntax includes HTML in its entirety, though...
Oh, markdown is great. I meant the things that are just different syntax for HTML.
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.
Web development is complex enough (server side, js, css) without adding an abstraction layer to your markup too.
I prefer to code in bits.
The problem with HTML is it’s verbose. So folks like to save some keystrokes (and mistakes).
The problem with HTML is it’s verbose. So folks like to save some keystrokes (and mistakes).
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.
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.
I'll save some people some typing and just post the next few comments in this conversation here:
> 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
> ಠ_ಠ
> 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
> ಠ_ಠ
How does this compare to RestructuredText?
RestructuredText seem to me like an alternative to Markdown.
Hamdown idea is to enable automated content-generation by allowing ruby code embedding (like you can do with HAML)
Hamdown idea is to enable automated content-generation by allowing ruby code embedding (like you can do with HAML)
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.
Of course, there is an XKCD cartoon for every occasion: https://xkcd.com/927/
[deleted]
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