Re: [jslint] Re: Suggestion for whitespace exception when building an HTML string
- You can also place the spaces doing the indentation within the string:
So much concatenating IS expensive, specially if within a function and
done over and over again, instead of resolved once as if a constant, and
You can also store HTML as HTML is a script tag with whatever type a
browser would not recognize:
<script type="text/x-template" id="whatever-template">
or, more compliant, you can store it within a div set with display:none,
however, the HTML stored there must be valid while within a script it
can be incomplete or contain placeholders for a template processor or
whatever since, after all, it won't be parsed neither as HTML nor as
anything else. If you know your segments to be valid, then this is
quite an advantage
El 23/08/2011 23:03, paulcrowder1979 escribió:
>[Non-text portions of this message have been removed]
> I wasn't aware of the block-level option, so thanks for pointing that
> out. I'll just move the code that builds the HTML into its own
> function and specify the option in that function as a workaround for
> the time being.
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 10.0.1392 / Virus Database: 1520/3852 - Release Date: 08/23/11
- I've avoided putting the spacing in the string itself since it wouldn't get minified out. As for the concatenation cost, remember that I use YUI Compressor to minify the script which uses constant folding to combine literal strings during the minification step. That means that code that's written like this:
var myHtml = '<div>' + '</div>';
Gets converted to this when minified:
Storing the HTML in the DOM of course has performance implications and is also not practical in my real-world code; while the sample code I provided in my original post consists of all literal strings, in reality it's a combination of literal strings and variables. I used literal strings in my example for simplicity's sake.
- Actually what you are describing is not minification. It is obfuscation, which is different. YUI can do both.
In markup languages, particularly HTML/XML, each and every white space character always has value. This is evident when you use the white-space css property with the "pre" value. Most of the time, however, the value of the white space is trivial as it is typically tokenized or saturated into the structure prior to being painted to the screen. In these cases white space can be minified to a single character without substantive harm, although the value of the document is irrevocably different. When white space is entirely removed not only is the value of the document different, but so is the structure of the document. This is evident in reflection to the removal of text nodes from the DOM. Changing the structure from removing text nodes that only contain white space is typically ok if there is understanding on which text nodes are removed and the impact to the tokenized result of the parsed content, however this is certainly less safe than merely tokenizing white space without removing any DOM nodes. This is less safe in that automated agents can no longer walk the DOM with predefined guidance and produce identical results. This warning is otherwise trivial as content oriented automated agents, such as meta-data bots, walk the DOM from the content out.
If you are not ready to consider these aspects of parsing markup then you should not be concerning yourself with dynamically altering the white space of markup code. You may likely be harming and altering the data value of markup documents without knowledge to the effect.
Austin Cheney, CISSP