Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Add support for HTML blocks. #34

Open
wants to merge 1 commit into from
@marijnh

No description provided.

@marijnh marijnh Support inline HTML
As per http://daringfireball.net/projects/markdown/syntax#html

The __RAW extension to jsonml is a bit ugly. Feel free to suggest a
better approach.
0f73e87
@bentruyman

+1 for this. This is a blocker for us.

@kjbekkelund kjbekkelund referenced this pull request in gnab/remark
Closed

Problem in Showdown #14

@rummik

I think the issue here is < and > escaping (plus a couple others) should be optional, and & should only be escaped when not part of an entity (Something similar to /&([a-z]+|#[0-9]+);/i)

At the same time, extending JsonML with something similar __RAW would be useful in some cases -- like, if you're running Markdown before passing things off to a templater.

@jchouse

+1 fir this. Really need this feature.

@footya

It is just what I need

@sbstjn sbstjn referenced this pull request in sbstjn/node-blog
Open

Can't use inline HTML #3

@mattly

+1, this is a blocker for us as well.

@natevw

+a lot

I based my blog engine off of this, and now every time I want to use a real <i></i>, or add a table, or embed HTML5 video, or, or... I get tripped up because my Markdown library doesn't support all of Markdown :-(

@spacez320

This is the first Markdown instance that I've worked with that doesn't allow inline HTML. +1

@michaek

I'm sure you're aware of it, but I'd like to reiterate that Markdown is designed to support inline HTML. http://daringfireball.net/projects/markdown/syntax#html

@evilstreak
Owner

I have no issue with supporting inline HTML. This pull request needs some tests before it's ready to be merged. It's on my list but it's several items down, so it could be a while until I get to it. If anyone else wants to contribute some tests that'd be super.

@ashb
Collaborator

Since we haven't previously supported inline HTML this change is a potentially breaking/insecure change (with this change it is possible to add malicious <script> tags that were safe before) so I think this feature also needs to be put behind a feature/option switch that is off by default.

@michaek

I think it makes sense to have inline HTML off by default. For most use cases, it's probably expected not to inline HTML.

If I get approval to do it (from my employer), I'll see about taking a look at the commit and adding some tests.

@ashb
Collaborator

Sweet.

For added fun this approach seems to cause problems with HTML in code blocks: sbstjn/node-blog#3 (comment) which will need looking at too.

If you do it on company time we are happy to have a "Some development sponsored by company.com" in the Readme etc.

@michaek

That makes sense, but it's not immediately clear to me whether HTML should always remain unescaped within code blocks. We can make that assumption, if that's what seems right, though.

Identifying HTML blocks with a regex is bound to expose some edge cases, too. After all: http://www.codinghorror.com/blog/2009/11/parsing-html-the-cthulhu-way.html

@evilstreak
Owner

If there's doubt about how a piece of markup should be interpreted, we use Babelmark to see what the general consensus is.

In this case, code blocks take priority over HTML.

@michaek

I've been thinking about this. I agree that code blocks should be escaped, but I don't think anything outside code blocks should be escaped by default. Turning on global escaping may still be an option, but I have changed my position on the default.

If we're concerned about the security of escaping user strings, that seems out of scope for markdown. User strings should be handled as appropriate by the implementing application, not by this library. That seems more in keeping with the spirit of Markdown, and more consistent with other Markdown implementations.

I don't think there is any reason to try to identify HTML with a regex, so this pull request should probably be closed (and not merged).

@dtao dtao referenced this pull request from a commit in dtao/markdown-js
@dtao dtao tests for HTML block support (evilstreak/markdown-js#34)
- tests for @marijnh's HTML block commit
- support self-closing HTML tags
- default to code blocks where indented
c61053e
@dtao

I submitted pull request #98 with tests for this change, as @evilstreak requested.

@hegemonic hegemonic referenced this pull request from a commit in jsdoc3/markdown-js
@dtao dtao tests for HTML block support (evilstreak/markdown-js#34)
- tests for @marijnh's HTML block commit
- support self-closing HTML tags
- default to code blocks where indented
0da3481
@hegemonic hegemonic referenced this pull request from a commit in jsdoc3/markdown-js
@hegemonic hegemonic Revert "tests for HTML block support (evilstreak/markdown-js#34)"
This reverts commit c61053e.
0050c46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Nov 1, 2011
  1. @marijnh

    Support inline HTML

    marijnh authored
    As per http://daringfireball.net/projects/markdown/syntax#html
    
    The __RAW extension to jsonml is a bit ugly. Feel free to suggest a
    better approach.
This page is out of date. Refresh to see the latest.
Showing with 8 additions and 0 deletions.
  1. +8 −0 lib/markdown.js
View
8 lib/markdown.js
@@ -287,6 +287,11 @@ Markdown.dialects = {};
**/
Markdown.dialects.Gruber = {
block: {
+ htmlBlock: function htmlBlock( block, next ) {
+ if ( block.match( /^\s*<\w/ ) && block.match( /<\/\s*\w+\s*>\s*$/ ) )
+ return [["__RAW", block.toString()]];
+ },
+
atxHeader: function atxHeader( block, next ) {
var m = block.match( /^(#{1,6})\s*(.*?)\s*#*\s*(?:\n|$)/ );
@@ -1293,6 +1298,9 @@ function render_tree( jsonml ) {
if ( typeof jsonml === "string" ) {
return escapeHTML( jsonml );
}
+ if ( jsonml[0] == "__RAW" ) {
+ return jsonml[1];
+ }
var tag = jsonml.shift(),
attributes = {},
Something went wrong with that request. Please try again.