HTML - what features required and why?

[jonschlinkert]

HTML - what features required and why?

[puzrin]

Lets keep duscussion close to topic. The question is to provide examples, when html needed .

[howardroark]

My bad! I deleted it... I think I read the PS and my thoughts trailed off.

My gut is that if you need to use HTML you may be trying to use Markdown as a development tool rather than a writing tool. If you are trying to use Markdown to make development of Marketing sites easier for teams maybe instead look at something like BEM. IMO Markdown is for expressing yourself, not building a UI. If you can't agree on that, there is no real way to have a philosophy for a spec.

[jonschlinkert]

are those really needed or added just because someone expected that "it could be useful sometime"

using HTML/markdown together is fairly common in documentation, for example: https://github.com/zurb/foundation/blob/master/doc/pages/changelog.html (foundation uses assemble to build their docs).

Generally, the goal is to use markdown as much as possible for written content, and use HTML when necessary to achieve formatting or structural results that are not possible or practical with markdown. Also I think GitHub and marked.js have created the expectation that HTML and markdown should be able to live together.

On a personal note, once remarkable is ready for production I'd like to be able to do pull requests on other projects to swap out remarkable for marked.js. Having feature parity with marked.js will make this easy to do.

[puzrin]

As far as i see, those examples needs "unlimited html" with post-filtering. I expected, that someone has case like me - "uncontrolled" user content, like forum posts. In this case html should be disabled, or strictly limited to couple of tags, or enchanced only with macros (for example, to add mathjax).

If nobody has examples for restricted html, i'll abandon this from roadmap to save time.

[howardroark]

+1 for abandon. On/Off HTML is super easy to understand.

[tunnckoCore]

+1 abandon, why not.

protect result from security vulnerabilities

is very good point.

[howardroark]

My vote is for having a safe-mode setting that needs to be expressly turned
off to use HTML. If turned off it allows unlimited HTML to pass through
unvalidated. When on by default it kills any HTML. This allows tools which
assemble HTML for CDN hosting to pass through HTML safely. Anything that
allows users to edit Markdown should NOT be able to pass through HTML. No
need to burden the net with XSS.

[tunnckoCore]

Mm.. As I said here commonmark/commonmark-spec#61 (comment)
I think the scope of markdown library must only be to output a valid HTML. But not in the core of markdown libraries. Maybe as option and heavy notice in their READMEs that they can plug some sanitizer/validator right before final output.

[jonschlinkert]

gents, let's keep this focused on the topic of the issue please: features. You're words will be more effective in the right channels, e.g. take the debate to a repo that is trying to push a spec.

IMO Markdown is for expressing yourself, not building a UI. If you can't agree on that, there is no real way to have a philosophy for a spec.

we're not building a spec, stmd is trying to do that, and so is https://github.com/vfmd/vfmd-spec/blob/gh-pages/specification.md. we're building remarkable to adhere to a spec being championed elsewhere.

My vote is for having a safe-mode setting that needs to be expressly turned off to use HTML

Again, there is already a spec for this, and it wasn't decided on this project: See: https://github.com/jgm/stmd/blob/6326bc748c8f5f225d82c01fe6763776f2bbd88e/spec.txt#L1348

[howardroark]

Deal. I think I'm just confused in all this Markdown business. If only John Gruber would just take the lead and offer a place for real discussion about the philosophy.

Sorry, I'll lay off.

[jonschlinkert]

lol np

[tunnckoCore]

Haha, yea. I think the time for Markdown Conference come, not only discussing on forums and mailing lists. Just idea ;p

[puzrin]

Closed - implemented with on/off option, that's enougth now.

[rlidwka]

we're building remarkable to adhere to a spec being championed elsewhere.

With all due respect, this isn't exactly true. E.g., there are no tables in the either spec.

Remarkable is going to have stmd-compatible mode, but it just might have other things like html escaping which isn't covered by any markdown standard I know of.

Thus, discussion how to handle html stuff is valid here. "on/off" switch seems a good solution though.

[jonschlinkert]

With all due respect, this isn't exactly true. E.g., there are no tables in the either spec.

I didn't say we can't discuss concepts that go beyond the spec. But, unless you guys have decided otherwise, it's my understanding that we are not championing a spec in this project.

[puzrin]

Yeah, no specs here, or this story will never finish. All features without good examples of real use will be declined in core. But nobody prohibits to write extentions. I hope, upcoming design will finally allow do it without ass pain.

[skhavari]

Markdown in markdown (the inception use case?) is a good example of where html in markdown is useful. For example, the following is markdown in preformatted html

# Sample Markdown
* one
* two
* three

```javascript
var x = "The quick brown fox...";
console.log( x );
````

[puzrin]

Seems that can be done via fenced block without any changes. Or may be i didn't understood what you need,

[skhavari]

To write markdown in a fenced block would require nested fenced blocks, which today the parser doesn't seem to support.

An alternative is to embed markdown in preformatted html which is very easy to author

_insert_any_markdown_here_

[puzrin]

Nested fences are possible. Just use different (but > 3) backticks for parents and childs. Or use ~~~ instead of backticks. See example in commonmark spec http://spec.commonmark.org/0.7/#fenced-code-blocks

[skhavari]

sweet!