-
Notifications
You must be signed in to change notification settings - Fork 108
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
HTML vs Plain Text Handling #119
Comments
Hello, @WadeWaldron! Here's a link to the possible solution. As you see, it's recommended that you use some syntax highlighter when writing code in the editor. It will work even mixing languages like in the example above. |
Actually, the code highlighter is kind of where the problem comes from. I've set up a bit of Javascript that loads some code, runs it through highlight js and then renders it. The problem is that Highlight JS will encode symbols like So for example, it might add tags for something like:
However, it might not add tags for something like:
However, whether it adds HTML tags or not, it always encodes the symbols. So when I feed the code through highlightjs and then into glorious, sometimes it gets HTML and sometimes it gets plain text, and then it interprets the encoded symbols differently depending on the situation. I've been able to hack it by adding It might be nice if I could explicitly tell Glorious whether the code is encoded or not. |
Hmm... Okay. I think I now understand what you mean. The code that determines whether or not to escape HTML is located here: https://github.com/glorious-codes/glorious-demo/blob/master/src/scripts/services/type/type.js#L21 To make this decision, the code attempts to identify the presence of any closing HTML tag: https://github.com/glorious-codes/glorious-demo/blob/master/src/scripts/services/dom/dom.js#L18 So, it seems that you need a way to explicitly set which lines of text should have their HTML characters escaped and which lines should not. By doing so, Glorious Demo would bypass the condition present in the type service and consider the option you've set. Is that correct? |
I would suggest that instead of explicitly setting which lines should have the HTML characters escaped, and which ones should not, it should be possible to simply turn off the autodetection. I.E. It would be nice if there was a setting such as |
Or, actually, looking at the code, perhaps it should be something like:
Then the code would update to something like this:
|
Here's a quick sample of a demo:
This particular demo creates some issues.
The first line renders exactly as written with the
<
and>
being rendered as is.The second line actually decodes the
<
and>
into<
and>
.So there is an unexpected difference in how it renders the two lines of code.
I would expect it to either always decode the symbols or never decode them, rather than sometimes as it is right now.
The text was updated successfully, but these errors were encountered: