Is it possible to embed a <canvas> tag in markdown? In particular, I'm hoping to embed canvas tags to display charts from the Chart.js library within a blog entry using the GrahamCampbell/Laravel-Markdown package but it does not seem to work.
Blog Entry Sample:
Lorem ipsum blah blah blah blah blah....
<canvas id="myChart" width="400" height="200"></canvas>
Lorem ipsum blah blah blah blah blah...
My laravel view (post.blade.php) receives the body of the blog post as follows:
<div class="article__body">
{!! Markdown::convertToHtml(e($post->body)) !!}
</div>
Currently the <canvas> tag is being posted as text within a <p></p>tag
In short, maybe. It depends on which Markdown implementation you are using.
The rules state:
For any markup that is not covered by Markdown’s syntax, you simply use HTML itself. There’s no need to preface it or delimit it to indicate that you’re switching from Markdown to HTML; you just use the tags.
Which, of course, would seem to indicate that it should work. But then there is the pesky issue of the HTML being wrapped in a <p> tag. The next paragraph in the rules state:
The only restrictions are that block-level HTML elements — e.g. <div>, <table>, <pre>, <p>, etc. — must be separated from surrounding content by blank lines, and the start and end tags of the block should not be indented with tabs or spaces. Markdown is smart enough not to add extra (unwanted) <p> tags around HTML block-level tags.
The issue is that Markdown was created long before the <canvas> tag (during the HTML 4 and XHTML 1 days) and most Markdown implementations do not include that tag in their list of "block-level HTML elements." However, a few implementations may have updated their code in recent years to add the newer HTML 5 block-level tags, and if you use one of those implementations, then you should be able to use a <canvas> tag without it being wrapped in a <p> tag.
You can compare some implementations on Babelmark2, where is appears that about half of the implementations listed will support canvas tags to some degree or another. However, that is a small sampling of all of the implementations out there. A much longer, albeit incomplete, list can be found here.
Related
I have following MD code for one of my GitHub page.
<p align="justify">
Text Text Text.
</p>
<p align="justify">
**Text** Text Text.
`Text` Text.
</p>
While the first paragraph tag works Okay as there is no Markdown editing done inside it, text inside second paragraph tag is not Formatted as it should be. (No Bold, no quotes)
Why is it so?? And how to use Markdown editing inside paragraph then?
The Markdown rules plainly state:
Note that Markdown formatting syntax is not processed within block-level HTML tags. E.g., you can’t use Markdown-style *emphasis* inside an HTML block.
That said, GitHub Pages uses Kramdown to parse Markdown, and Krandown has a slightly different behavior which gives you more flexibility. In fact, Kramdown's documentation states:
If an HTML tag has an attribute markdown="1", then the default mechanism for parsing syntax in this tag is used.
In other words, do this:
<p align="justify" markdown="1">
**Text** Text Text.
`Text` Text.
</p>
And you will get the following output:
<p align="justify">
<strong>Text</strong> Text Text.
<code>Text</code> Text.</p>
Kramdown is smart enough to recognize that you are inside a <p> tag, and does not wrap the individual lines in new <p> tags, which would be invalid HTML. If you actually want each line to be a separate paragraph, then you should use a <div> to wrap everything. Like this:
<div align="justify" markdown="1">
**Text** Text Text.
`Text` Text.
</div>
Which results in this output:
<div align="justify">
<p><strong>Text</strong> Text Text.</p>
<p><code>Text</code> Text.</p>
</div>
For completeness, it should be noted that GitHub READMEs and Gists do not use the same Markdown parser. Instead they use an extended Commonmark parser, which handles Markdown in raw HTML differently that the two ways described above. In Commonmark, whether the content of a raw HTML block is parsed as Markdown or not depends on whether the content is wrapped by blank lines. In that case, the proper way would be to do this:
<div align="justify">
**Text** Text Text.
`Text` Text.
</div>
However, as GitHub will strip out the align attribute, there isn't any point it doing that on pages hosted on github.com (such as READMEs). There is also the problem that Commonmark is not smart enough to detect that the wrapping raw HTML tag is a <p> tag, and wraps each line in another <p>, resulting in invalid HTML. Therefore, you must use a <div> in that case.
While the use-blank-lines method of telling the parser to parse the contents as Markdown is a more elegant solution that markdown="1", it is only supported by Commonmark parsers, which Kramdown is not. Therefore, as long as GitHub Pages uses Kramdown, you need to follow Kramdown's rules.
You can see my problem in this jsFiddle.
I tried usingcode tags to distinguish special content, but this quickly backfired on me (as you can see in the above link). When I use Firebug to look at the content, this:
<p>
This is a sample paragraph with a code block:
<code>
<p> Some line of code </p>
<p> Another line of code </p>
</code>
</p>
has turned into this:
<p>
This is a sample paragraph with a code block:
<code> </code>
</p>
<p>
<code> Some line of code </code>
</p>
<code>
<p> Another line of code </p>
</code>
Now, this can be solved by changing <code> to <div class="code"> (as seen in this jsFiddle), but why did the browser do this in the first place, and why did it do it only to the first section in each paragraph?
Firefox, Opera, Chrome, Internet Explorer, Safari - all of them do this, but I'd really like to know why. Does it happen with code only, or will it do this with other tags? And why would browsers move tags around like that?
HTML places certain restrictions on which elements can be nested in which other elements. Sometimes browsers will happily construct a nonsensical DOM out of certain nesting scenarios, such as a <div> directly in a <ul>. Other times, they absolutely can't because of other written or unwritten parsing rules, such as <p> elements never containing any other block elements, not even other <p> elements (this is implied by the spec), so they have to work around it by changing the DOM to something that they can work with, resulting in the behavior you observe.
Because you cannot nest <p> elements within one another at all, what's happening here is that this element:
<p> Some line of code </p>
is causing this other element to be terminated:
<p>
This is a sample paragraph with a code block:
<code>
Since there's an empty <code> tag in there, it's closed, and the containing <p> closed as well, because a subsequent <p> start tag will automatically close a preceding <p> start tag:
<p>
This is a sample paragraph with a code block:
<code> </code>
</p>
At this point a browser has to deal with the fact that the <code> and <p> tags are now effectively in the wrong order, but still nested. To compensate for the restructuring of the first "outer" <p> element, and the fact that there was going to be a <code> tag before the second "inner" <p>, it inserts <code> tags into the second <p>, turning its contents into code:
<p>
<code> Some line of code </code>
</p>
Since browsers do seem to allow <p> within <code> for whatever reason (note that at this point the <code> is still not yet explicitly terminated with a </code>), the browser builds the rest of the DOM as follows, before continuing on its way:
<code>
<p> Another line of code </p>
</code>
This is probably consistent across browsers for legacy and cross-browser compatibility reasons; some of these legacy parsing rules have been retconned into sections of the HTML5 spec as well. Unfortunately, I'm not a browser implementer so I can't list out all possible scenarios; on the other hand, it's unwise to rely on such details considering the markup you're writing is invalid in the first place.
And, finally, today's highly relevant xkcd (of course):
I've noticed that block level things are not really markdown friendly. Imagine the following segment (Yes, I am intending to output for twitter bootstrap):
<section id="loremipsum">
<div class="page-header">
# Heading 1 #
</div>
Lorem ipsum, blah blah blah, yada yada yada.
</section>
The expected output should be:
<section id="loremipsum">
<div class="page-header">
<h1>Heading 1</h1>
</div>
<p>Lorem ipsum, blah blah blah, yada yada yada.</p>
</section>
Instead, the produced output is closer to:
<p><section id="loremipsum"></p>
<div class="page-header">
# Heading 1 #
</div>
<p>Lorem ipsum, blah blah blah, yada yada yada.</section></p>
There are two problems here:
As per suggested by Daring Fireball, Markdown should be smart enough to not put in un-wanted tags around block level elements such as section tag.
Heading 1 is not parsed as a heading, but instead left unparsed.
Both of these problems actually happens also in Dingus, the official parser, so I guess this is one of those "working as intended" kind of issue. That said, are there any markdown gurus out there that knows how to work around these problems?
A little late to the game, but an updated answer (as of summer 2015).
The question depends on which implementation you use, but a good reference on markdown is CommonMark. According to the HTML-blocks specification you can get the wanted result with this markdown:
<section id="loremipsum">
<div class="page-header">
# Heading 1 #
</div>
Lorem ipsum, blah blah blah, yada yada yada.
</section>
Note the empty lines, which are end conditions for HTML-blocks. Also note:
The block begins with a line that meets a start condition (after up to three spaces optional indentation).
Meaning one should be careful with indenting the start of HTML-blocks.
markdown-it implements commonmark 100% in js, perl-commonmark gives you bindings to CommonMark C library, and I guess you will find implementations of CommonMark in most programming languages.
You can use Pandoc's markdown, which by default interprets code between <div> tags as markdown text.
$ pandoc input.md -o output.html
(See the markdown_in_html_blocks section of Pandoc's markdown doc for details.)
Yep, that's by design. According to Gruber:
Note that Markdown formatting syntax is not processed within block-level HTML tags. E.g., you can’t use Markdown-style *emphasis* inside an HTML block.
I'm not aware of any sort of workaround for that, but I wouldn't put myself at guru-level when it comes to Markdown.
Edit: You might want to check out PHP Markdown Extra if you're working with PHP.
Some implementations may be case sensitive.
It turns out that markdownsharp will use a real div if you capitalize the <DIV> tag, but not if you use <div>.
So this may give you what you want
<DIV class="video-panel">
![Review][1]
![Review][2]
</DIV>
Even stackoverflow's markdown still differentiates between the two, although it strips out the DIV itself. For a public website this is probably a good thing though!
this will be bold
**this will not be bold**
How do I stop Drupal from removing tags from the body of a page??
If I create a page that is organized such as
<p>blah blah</p>
<p>blah blah 2</p>
When I go back and edit - it removes the p and when I publish even without editing it turns into this
blah blahblah blah2
It's really annoying especially when editing pages with a lot of content - because I have to redo everything..!!
What input filter are you using? It sounds like the wrong one is being used.
Sounds like you might be using either plain text or filtered HTML.
From Drupal, details for Filtered HTML:
• Web page addresses and e-mail addresses turn into links automatically.
• Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
• Lines and paragraphs break automatically.
To see and configure your input filters go to admin/settings/filters or /admin/config/content/formats/filtered_html
I have always used either a <br /> or a <div/> tag when something more advanced was necessary.
Is use of the <p/> tag still encouraged?
Modern HTML semantics are:
Use <p></p> to contain a paragraph of text in a document.
Use <br /> to indicate a line break inside a paragraph (i.e. a new line without the paragraph block margins or padding).
Use <div></div> to contain a piece of application UI that happens to have block layout.
Don't use <div /> or <p /> on their own. Those tags are meant to contain content. They appear to work as paragraph breaks only because when the browser sees them, and it "helpfully" closes the current block tag before opening the empty one.
A <p> tag wraps around something, unlike an <input/> tag, which is a singular item. Therefore, there isn't a reason to use a <p/> tag..
I've been told that im using <br /> when i should use <p /> instead. – maxp 49 secs ago
If you need to use <p> tags, I suggest wrapping the entire paragraph inside a <p> tag, which will give you a line break at the end of a paragraph. But I don't suggest just substituting something like <p/> for <br/>
<p> tags are for paragraphs and signifying the end of a paragraph. <br/> tags are for line breaks. If you need a new line then use a <br/> tag. If you need a new paragraph, then use a <p> tag.
Paragraph is a paragraph, and break is a break.
A <p> is like a regular Return in Microsoft Office Word.
A <br> is like a soft return, Shift + Return in Office Word.
The first one sets all paragraph settings/styles, and the second one barely breaks a line of text.
Yes, <p> elements are encouraged and won't get deprecated any time soon.
A <p> signifies a paragraph. It should be used only to wrap a paragraph of text.
It is more appropriate to use the <p> tag for this as opposed to <div>, because this is semantically correct and expected for things such as screen readers, etc.
Using <p /> has never been encouraged:
From XHTML HTML Compatibility Guidelines
C.3. Element Minimization and Empty Element Content
Given an empty instance of an element whose content model is not
EMPTY (for example, an empty title or
paragraph) do not use the minimized
form (e.g. use <p> </p> and not <p />).
From the HTML 4.01 Specification:
We discourage authors from using empty P elements. User agents should ignore empty P elements.
While they are syntactically correct, empty p elements serve no real purpose and should be avoided.
The HTML DTD does not prohibit you from using an empty <p> (a <p> element may contain PCDATA including the empty string), but it doesn't make much sense to have an empty paragraph.
Use it for what? All tags have their own little purpose in life, but no tag should be used for everything. Find out what you are trying to make, and then decide on what tag fits that idea best:
If it is a paragraph of text, or at least a few lines, then wrap it in <p></p>
If you need a line break between two lines of text, then use <br />
If you need to wrap many other elements in one element, then use the <div></div> tags.
The <p> tag defines a paragraph. There's no reason for an empty paragraph.
For any practical purpose, you don’t need to add the </p> into your markup. But if there is a string XHTML adheration requirement, then you would probably need to close all your markup tags, including <p>. Some XHTML analyzer would report this as an error.