Every time I write my HTML in Jade, I am getting extra whitespace added after each element's value.
For example, I will have a line like this in my Jade Template:
label(for="keyword") Keyword
And when it's rendered, the source will look like this:
<label for="keyword_1">Keyword
</label>
Ran into some problems with that extra whitespace messing w/ my CSS. Plus, it just doesn't look as tidy :)
Anyone know how I can prevent it from being inserted?
Check the update at the bottom
I assume you're using express - check your app settings.
app.set('view options', { pretty: false })
If you have jade rendering in pretty mode (pretty: true) then it will arrange your generated source (tags) with nested indention. Turning pretty printing off should resolve your problem (though make sure you don't have trailing space, as pointed out by #alessioalex).
If you have a reason requiring you to output pretty formatting (client spec, in my case) then you can try some other things. I had a similar issue with occurring with the textarea tag; frustrating because the whitespace is actually injected into the content of the form. The way I got around this was to embed a the literal html with the closing tag:
<textarea name="someField"></textarea>
The docs can give you some more details (search for html in this case). There is open issue #341 on github which suggests an approach like this one for scalate, but it doesn't currently work in jade (as of version 0.19.0) .
HTH
Update
Ok - subtle and cool... there is a better way to keep the sexy output from pretty: true and avoid spacing inside of a tag (my textarea example)... I just tried appending a . to the end of the tag (see code) and it Just Worked™ :-)
form(name='frmname', method='POST')
textarea(name='someField').
Renders:
<form name="frmname" method="POST">
<textarea name="someField"></textarea>
</form>
Beauty!
Why does this work? Because jade treats the . suffix on the tag as an indicator that the tag will contain a text block (only), and then no text block is provided, so it defaults to '', an empty string.
Related
Disclaimer: I'm super new to this and know very little about the technical terms. I might just not know what to search for in order to find the answer I need. In that case I would really appreciate someone just pointing me the right way.
Now, the problem/question:
Is there a way to avoid things like this:
<table>
<th>
<tr>One </tr>
<tr>Two</tr>
<tr>Three</tr>
</th>
</table>
displaying as if you typed this
<table><br>
<th><br>
<tr>One </tr><br>
<tr>Two</tr><br>
<tr>Three</tr><br>
</th><br>
</table><br>
because using "enter" in the text-box when writing a post is automatically rendered as a line break. Is there something you can put at the beginning of a post to overwrite/ignore this kind of global "enter = line break" thing for that post? As is, I have to type in tables and other things in this format to make it display correctly:
<table><th><tr>One </tr><tr>Two </tr><tr>Three </tr></th></table>
It gets a little hard to navigate after a while 😅
(I can only use things that can be written directly into a post)
I'd really appreciate any kind of help - even if it is a plain and simple "nope, can't be done" - then I at least know I can stop searching ^^
Thanks!
Newlines in HTML code should not matter (more precisely, they are just whitespaces) and they definitely do not render as newlines "by themselves".
If the newlines in yout HTML render as newlines on your screen, there must be something else in your HTML or CSS code that causes this. For example the <pre> or <code> HTML element or white-space:pre in your CSS. All of these (and a few other ones) instruct the browser that newlines in HTML should render as newlines on the screen.
This question already has answers here:
How to display raw HTML code on an HTML page
(30 answers)
Closed 3 years ago.
I'd like to add an area to a page where all of the dynamic content is rendered as plain text instead of markup. For example:
<myMagicTag>
<b>Hello</b> World
</myMagicTag>
I want the <b> tag to show up as just text and not as a bold directive. I'd rather not have to write the code to convert every "<" to an "<".
I know that <textarea> will do it, but it has other undesirable side effects like adding scroll bars.
Does myMagicTag exist?
Edit: A jQuery or javascript function that does this would also be ok. Can't do it server-side, unfortunately.
You can do this with the script element (bolded by me):
The script element allows authors to include dynamic script and data blocks in their documents.
Example:
<script type="text/plain">
This content has the media type plain/text, so characters reserved in HTML have no special meaning here: <div> ← this will be displayed.
</script>
(Note that the allowed content of the script element is restricted, e.g. you can’t have </script> as text content (it would close the script element).)
Typically, script elements have display:none by default in browser’s CSS, so you’d need to overwrite that in your CSS, e.g.:
script[type="text/plain"] {display:block;}
You can use a function to escape the < >, eg:
'span.name': function(){
return this.name.replace(/</g, '<').replace(/>/g, '>');
}
Also take a look at <plaintext></plaintext>. I haven't used it myself but it is known to render everything that follows as plain text(by everything i mean to say it ignores the closing tag, so all the following code is rendered as text)
The tag used to be <XMP> but in HTML 4 it was already deprecated. Browser's don't seem to have dropped its support but I would not recommend it for anything beyond quick debugging. The MDN article about <XMP> lists two other tags, <plaintext> and <listing>, that were deprecated even earlier. I'm not aware of any current alternative.
Whatever, the code to encode plain text into HTML is pretty straightforward in most programming languages.
Note: the term similar means exactly that—all three are designed to inject plain text into HTML. I'm not implying that they are synonyms or that they behave identically—they don't.
There is no specific tag except the deprecated <xmp>.
But a script tag is allowed to store unformatted data.
Here is the only solution so far showing dynamic content, as you wanted.
Run code snippet for more info.
<script id="myMagicTag" type="text/plain" style="display:block;">
<b>Hello</b> World
</script>
Use Visible Data-blocks
<script>
document.querySelector("#myMagicTag").innerHTML = "<b>Unformatted</b> dynamic content"
</script>
No, that's not possible, you need to HtmlEncode it.
If your using a server-side language, that's not really difficult though.
In .NET you would do something like this:
string encodedtext = HttpContext.Current.Server.HtmlEncode(plaintext);
In my application, I need to prevent HTML from rendering
"if (a<b || c>100) ..."
and
"cout << ...".
Also the entire C++ code region HTML must pass through the GCC compiler with the desired effect. I've hit on two schemes:
First:
//<xmp>
#include <string>
//</xmp>}
For reasons that escape me, the <xmp> tag is deprecated. I find (2016-01-09) that Chrome and FF, at least, render the tag the way I want. While researching my problem, I saw a remark that <xmp> is required in HTML 5.
Second, in <head> ... </head>, insert:
<style type="text/css">
textarea { border: none; }
</style>
Then in <body> ... </body>, write:
//<br /> <textarea rows="4" disabled cols="80">
#include <stdlib.h>
#include <iostream>
#include <string>
//</textarea> <br />
Note: Set "cols="80" to prevent following text from appearing on the right. Set "rows=..." to one more line than you enclose in the tag. This prevents scroll bars. This second technique has several disadvantages:
The "disabled" attribute shades the region
Incomprehensible, complex comments in the code sent to the compiler
Harder to understand
More typing
However, this methhod is neither obsolete nor deprecated. The gods of HTML will make their faces to shine unto you.
Yes, I am struggling with displaying data from our database that CONTAINS markup! One particular field I am displaying has an open-bold tag but no close bold tag. I am trying to 'contain' this markup so it doesn't affect the rest of the page.
The data coming from my database is like this text:
this is soem nasty <b>data
(note the lack of a closing < /b > tag)
If I enclose the markup in a div, the rest of the page is bold:
<div>this is some nasty <b>data</div>
However if I wrap it in a table like this:
<table><tr><td>this is some nasty <b>data</td></tr></table>
All is well! In fact, the DOM inspector for both FF (FireBug) and IE9 show the tree. In the div-case, it shows the open-b tag and the rest of the document contained within it. But the table seems to enclose it.
How can I get this to 'close the b' without a table?
You use a closing </b> tag properly, like any sane human being.
You can use DOMDocument and tidy to try and fix the malformed markup in case you have no control over it, but it's best if you could fix it before it got to your database.
I've read somewhere that HTML Purifier should be able to achieve this. Might be worth trying.
I took a cue from HTML rich-text editors like TinyMCE and built up an IFrame. It seems to contain the arbitrary, possibly-mal-formed content better.
Instead of
<!--
,
I used
<!-
...and it is working.
How?
It's not actually working - it's just interpreting it as an actual tag, and then throwing that tag out as invalid.
<!- foo bar -->
is treated as a tag, <!-foo bar--> which obviously isn't a standard HTML tag, and thus is ignored.
Try this, and you'll see it's not truly working as a comment:
<!- >foo bar-->
Modern browser parsers (i.e. those that use the HTML5 parsing algorithm) work like this. If they are expecting text or a new tag next, and they see <! then they check the next few characters to see if they are -- or DOCTYPE or, if they are processing embedded SVG or MathML, [CDATA[. (See http://dev.w3.org/html5/spec/tokenization.html#markup-declaration-open-state)
If, as in the case of <!- foo, none of these match then the parser enters the bogus comment state where all the characters following, up to the next >, are read and and converted into a comment to be put into the DOM.
Hence the behaviour you see with <!- working like a comment start. Note that such behaviour is "repair" behaviour for broken markup and it's wise not to rely on it.
You can see how such markup forms a DOM here: Live DOM Viewer
Also note that this is different to what #Amber says. It is not treated as a tag in any meaningful sense, and it is certainly not ignored.
How can you prevent any automatic formatting when in CKEditor when viewing in source mode?
I like to edit HTML source code directly instead of using the WYSIWYG interface, but whenever I write new lines, or layout tags how I would indent them, it all gets formatted when I switch to WYSIWYG mode and then back to source mode again.
I stumbled upon a CKEditor dev ticket, Preserve formatting of ProtectedSource elements, that alluded to a setting which may have existed once upon a time which would be exactly what I'm after. I just want to know how I can completely turn off all automatic formatting when editing in source mode.
I came up with a solution I thought would be foolproof (albeit not a pleasant one).
I learned about the protectedSource setting, so I thought, well maybe I can just use that and create an HTML comment tag before all my HTML and another after it and then push a regular expression finding the comment tags into the protectedSource array, but even that (believe it or not) doesn't work.
I've tried my expression straight up in the browser outside of CKEditor and it is working, but CKEditor doesn't protect the code as expected (which I suspect is a bug involving comment tags, since I can get it to work with other strings). In case you are wondering, this is what I had hoped would work as a work-around, but doesn't:
config.protectedSource.push( /<!-- src -->[\s\S]*<!-- end src-->/gi );
and what I planned on doing (for what appears to be the lack of a setting to disable formatting in source mode) was to nest all my HTML within the commented tags like this:
<!-- src -->
<div>some code that shouldn't be messed with (but is)</div>
<!-- end src -->
I'd love to hear if anyone has any suggestions for this scenario, or knows of a setting which I have described, or even if someone can just fill me in as to why I can't get protectedSource to work properly with two comment tags.
I really think it's gotta be a bug because I can get so many other expressions to work fine, and I can even protect HTML within the area of a single comment tag, but I simply cannot get HTML within two different comment tags to stay untouched.
My solution to this was to use comments in my system, but before feeding the page content to CKEditor, convert them to custom HTML tags. Then, upon save, convert them back to my comment tags.
For your syntax that would be something like this in PHP. Before printing the page content to the textarea:
$content = str_replace(array('<!-- src -->','<!-- end src -->'),array('<protected>','</protected>'),$content);
Before saving the resulting content:
$content = str_replace(array('<protected>','</protected>'),array('<!-- src -->','<!-- end src -->'),$content);
In the CKEditor configuration:
protectedSource:[/<protected>[\s\S]*<\/protected>/g]
Hope that helps!
I wanted to preserve newlines in my source, and the protectedSource feature works well for that. I added this to my config.js:
config.protectedSource = [/\r|\n/g];
config.allowedContent=true; will do the trick
Here is the full HTML code
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>CKEditor</title>
<script src="http://cdn.ckeditor.com/4.5.10/standard/ckeditor.js"></script>
</head>
<body>
<textarea name="editor1"></textarea>
<script>
CKEDITOR.config.allowedContent=true;
CKEDITOR.replace( 'editor1' );
</script>
</body>
</html>
I solved this problem by simply surrounding the back-end output of edit form page with a conditional on a $_GET variable - when you click on "Expert Mode" it loads a plain textarea instead of the ckeditor system. Your invocation of the ckeditor object will vary depending on your setup. ( I have a custom class that calls/builds the editor object )
<div id="postdivrich" class="postarea">
<?php
if( isset( $_GET['expert'] ) )
{
print "<div style=\"text-align:right;\">Editor mode</div>\n";
print "<textarea name=\"content\" style=\"height:400px;width:{$nEwidth}px;\">{$aDoc['content']}</textarea>\n";
}
else
{
print "<div style=\"text-align:right;\">Expert mode</div>\n";
require_once( 'admin/editor.class.php' );
$aDoc['content'] = str_replace( "\r", '', str_replace( "\n", '', nl2br( $aDoc['content'] ) ) );
$oEditor = new setEditor( $aDoc['content'], $nEwidth, "400", 'content' );
$oEditor->ShowEditor();
}
?>
</div>
Does this answer help? Basically you can turn off the options adding a javascript, it looks like.