Loading ...
Sorry, an error occurred while loading the content.

Re: Suggestion for whitespace exception when building an HTML string

Expand Messages
  • Phil
    ... [ .. snip .. snip .. ] ... JSLint supports scoped control comments. I *assume* you either do not have a /*jslint ... */ comment in your code, or it at
    Message 1 of 7 , Aug 23, 2011
    • 0 Attachment
      --- In jslint_com@yahoogroups.com, "paulcrowder1979" <paul@...> wrote:
      >
      > I'm generally a fan of the whitespace rules that JSLint enforces, but
      [ .. snip .. snip .. ]
      > This makes maintenance much easier since I can see the HTML in a familiar structure which lets me ensure each tag is properly closed, etc. Since I use YUI Compressor which uses constant folding when minifying the HTML, I still end up with just one string being created at runtime. Right now JSLint gives a warning when my code is formatted this way, forcing me to specify the sloppy whitespace option which means that all the other whitespace in the document no longer gets validated. It seems like JSLint could easily detect string concatenation and not enforce its whitespace rules on those lines.
      >
      JSLint supports 'scoped' control comments. I *assume* you either do not have a /*jslint ... */ comment in your code, or it at the top [at file scope]. As a [partial] work around, add
      /*jslint white: true */
      inside [only] the nearest[function or block] scope where the concatenation and indenting are being done. For example, if the concatenation is being done in a for loop, something like the following should suppress the warnings [leading white space replaced by "." to keep indentation here]:
      var i, html = '';
      for (i = 0; i < limit; i++) {
      ../*jslint white: true */
      ..html +=
      ....'<div>' +
      ......'<div>' +
      ........'<img src="http://example.com/image.gif" />' +
      ......'</div>' +
      ....'</div>';
      }
      You can also create a dummy block scope just around the string concatenation statement(s):
      var html;
      do {
      ../*jslint white: true */
      ..html =
      ....'<div>' +
      ......'<div>' +
      ........'<img src="http://example.com/image.gif" />' +
      ......'</div>' +
      ....'</div>';
      } while (html === null);
      That last case of course creates extra code, so you would have to decide if the gain was worth it. As long as the string concatenation code is already in a small block though, just adding /*jslint white: true */ to the top of the block 'fixes' the warning.
    • paulcrowder1979
      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
      Message 2 of 7 , Aug 23, 2011
      • 0 Attachment
        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.
      • Satyam
        You can also place the spaces doing the indentation within the string: .... .... + instead of: ........ + So much concatenating IS
        Message 3 of 7 , Aug 23, 2011
        • 0 Attachment
          You can also place the spaces doing the indentation within the string:

          ....'....<whatever>' +

          instead of:
          ........'<whatever>' +

          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
          used anywhere.

          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">
          <div>
          label<input>
          </div>
          </script>

          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ó:
          >
          > 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
          >


          [Non-text portions of this message have been removed]
        • paulcrowder1979
          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
          Message 4 of 7 , Aug 24, 2011
          • 0 Attachment
            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:

            var a='<div></div>';

            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.
          • sandyhead25
            Actually what you are describing is not minification. It is obfuscation, which is different. YUI can do both. You are also confusing minification in markup
            Message 5 of 7 , Aug 25, 2011
            • 0 Attachment
              Actually what you are describing is not minification. It is obfuscation, which is different. YUI can do both.

              You are also confusing minification in markup as being similar to JavaScript minification. This is not the case because JavaScript, like most other programming languages, is a regular language. Markup, such as HTML, is an irregular language. You can look these terms up on Wikipedia for more information.

              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
              http://prettydiff.com/
            Your message has been successfully submitted and would be delivered to recipients shortly.