compression

[adius]

Why is there no option to print out compressed html?
I think that's definitely a "must have" feature!

[jonathanong]

you're not going to gain anything here since it'll just convert \n characters to ''.

[adius]

@jonathanong ? …and why exactly is saving bandwidth and preventing layout bugs because of newline whitespace not an advantage?

[jonathanong]

for 100kb of rendered markdown, you're going to save like 50 bytes. it's not about whether there's an advantage or not, it's about cost/benefit.

[adius]

and what are the costs? -.- In a cashed environment with heavy traffic it's a huge benefit! (and it's damn annoying if you have to put html code which you normally would split over several lines in the same line to prevent layout bugs, because HTML is NOT whitespace insensitive.

[jonathanong]

maintainability. additional options. i doubt you serve enough traffic where the savings would be noticeable - you'd have to be google or Facebook for the benefit to be HUGE. layout bugs with rendered markdown sounds like a CSS problem, which i've never had nor understand since most elements are block elements where whitespace is insignificant.

[adius]

<div style="display: inline-block"></div>
<div style="display: inline-block"></div>

This will render a space between the two divs and this is normally not what you want in this situation. To prevent this behavior you have to write them in the same line. This sucks! …but it doesn't look like you are open to any reasonable Arguments. So whatever, I'll just open my own branch. cu

[jonathanong]

why would you ever do that? of course you're going to run into layout problems if you write terrible HTML.

actually, more importantly, why would marked do that? but this argument is pointless so i'll stop too.

[MasseGuillaume]

@jonathanong I have a good reason for this
I'm using marked inside a pre element since it's space sensitive, the margin dont get merged. I cannot remove newline on the resulting string because code block inside the markdown will loose their layout.

[adius]

I had good reasons as well (…and of course I'm not using inline styles in real code)
@jonathanong just seems to be totally unreasonable
Good luck at convincing him of anything.

[MasseGuillaume]

@adius ad homminem, the guys is doing a good job with this free open source project.

[adius]

maybe. But he's doing a shitty job with this issue…

[MasseGuillaume]

@jonathanong
nvm you can use white-space: normal to discard white spaces in pre

[howardroark]

I see no reasonable reason to remove the semantic information that whitespace can offer. This is especially true in the case of Markdown where by design you are encouraged to wrap lines. Maybe you wanted to make an editor that could enforce or alter a user's desired line wrap setting. I would also argue that it just makes better sense in terms of search-ability. I think it's a pretty sane choice to leave compression out rather than risk encouraging it.

I would also argue that compression has no real economic value any longer. Cloud keeps getting cheaper and mobile networks keep getting faster. If anything I would say the real enemy is the AMD pattern used in browser based development. It encourages an excess of connections which ultimately slow down a user's experience and adds more traffic.

If you really need to compress, just do it in a post process. I'm sure there has to be something out there to enable that.

[rudolfschmidt]

If you compress your regular html it would be nice if the html output from markdown would be also compressed. I agree, its a must have feature. Some workaround already?

[joshbruce]

Was going to mark this as stale, but I'm curious if this is still a desired feature for folks actively using marked.

I see what @jonathanong is saying. I also think there are issues that come with interspersing Markdown and HTML. In some cases, it's better to just pick HTML. Or, compile and inject. With template string literals this could be pretty straightforward. But, I'm new around here still; so, I'll have to use pseudo-code.

If your markdown is coming from a database query, it shouldn't have HTML, in my opinion.

let markdown = 'Hello, World!`;
let html = marked.toHtml(markdown);
let final = `<div style="inline-block">${html}</div>`

That HTML is definitely strange but, looking at the broader point, knowing what the output is and the possible side-effects of that...anyway....

See #956

[adius]

Still desired.

[joshbruce]

The drawback I see is the potential cost-benefit of doing something like this. For <code><pre></pre></code> we need to maintain whitespace. I don't know what the overhead would for stripping whitespace, on the fly, while ignoring the triple-backtick case.

[adius]

I'd implement the easy solution first. i.e. strip all whitespace between adjacent tags with no content in between.

<div>
  <p>  Test  </p>
</div>

becomes

<div><p>  Test  </p></div>

This shouldn't break anything and be easy to implement

[UziTech]

This can easily be done with other tools after getting the uncompressed output from marked.

const minify = require('html-minifier').minify;
const marked = require('marked');

const md = "some markdown";

const result = minify(marked(md));

// result is now minified html

[mccraveiro]

I agree with @UziTech! There are better tools for the job and we should leave this out of marked.

The "dumb" way of implementing this feature would be to just add html-minifier in the bundle. However, this would just add complexity and size to the library.

I would go with adding @UziTech's example to the readme as an "official" solution for the problem.

[UziTech]

I'm going to close this since we will not be adding it to core but will most likely create an extension for it.