Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add extra tag to block code @ #95

Closed
wants to merge 1 commit into from
Closed

Conversation

mkdgs
Copy link

@mkdgs mkdgs commented Dec 16, 2012

(Forget my previous pull request this one combine the two)

add extra tag to block code @
fix double encoding in code

add the possibility to do:
@(php).

if tags in the textile string is already encoded it will be reencoded in
code block:
@
<div> oo </div>
@
become:
&lt;div &gt; oo &lt;/div &gt;

this change avoid double encoding

fix double encoding in code

add the possibility to do:
@(php).

if tags in the textile string is already encoded it will be reencoded in
code block:
@
&lt;div&gt; oo &lt;/div&gt;
@
become:
<code> &amp;lt;div &amp;gt; oo &amp;lt;/div &amp;gt; </code>

this change avoid double encoding
@gocom
Copy link
Member

gocom commented Dec 19, 2012

Downfall is that the encoding change prevents you displaying entities in code blocks, or anywhere. Any included pattern matching an entity in a string, will pass through and is processed by the browser. This causes a mixing of different encoding iteration levels in different parts of the code block which is not ideal. Whether the string is pre-encoded or not, you would have pre-encode (or double encode) any pattern matching an entity. This encoding change isn't limited to code block only. The Parser::encodeHTML() is the sanitizer in Textile.

The expectation that I personally have is that when someone is using Textile, they are using it to format any provided content, allowing you to type in just plain text without worrying about anything else. The content can contain mix of HTML, but Textile takes care of the important stuff as proper sanitation, encoding and security. For instance if you provide HTML to bc tag, the expectation would be that it encodes that string no matter what it contains.

(Forget my previous pull request this one combine the two)

More commits the merrier. The less distinct changes a single commit or a pull request contains the better ;-)

@gocom
Copy link
Member

gocom commented Dec 19, 2012

Oh yeah, having attributes in inline code tags would be definitely good. You will not normally need it as much as code blocks due to semantic validity, but when you do, being able to state the used language via a class would definitely be beneficial. Even for syntax highlighting if not anything else.

@netcarver
Copy link
Contributor

Closing this pull request and opened #96 to keep the feature request in view.

@netcarver netcarver closed this Dec 20, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants