Home/ Questions/Q 7827281
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T09:47:30+00:00

I’m making the transition from the Microsoft stack (i.e. WPF) to HTML5 so apologies

  • 0

I’m making the transition from the Microsoft stack (i.e. WPF) to HTML5 so apologies in advance for the rather amateurish nature of this question.

The topic at hand is HTML encoding and decoding.

Consider an HTML5 app making AJAX calls to a C# back-end via HTTP. The server returns JSON-formatted data exclusively, always making sure to HTML-encode the JSON value fields using HttpUtility.HTMLEncode().

The HTML5 client performs the same process in reverse. All data posted to the server is HTML-decoded first using a simple JavaScript helper function.

All potentially displayable string data in my HTML5 app is stored and passed from place to place in its HTML-encoded form. This scheme is working well for me. But today I discovered HTML5 text boxes and in doing so, noticed something odd. Text boxes don’t seem to like encoded text.

If I have a text box defined as such:

<input id="festus" type="text"/>

and update it as follows:

$("#festus").val(someEncodedString)

…the text box shows the actual codes that are embedded into someEncodedString instead of converting those codes to the appropriate characters. I was surprised by this behavior as I assumed that browsers perform the proper escape code interpretation for all DOM elements.

I’ve tried to abstract away the problem by writing a helper/wrapper for val() called val2():

$.prototype.val2=function(newVal){
    return (newVal===undefined)
        ?iHub.Utils.encodeHTML(this.val())      //getting value
        :this.val(iHub.Utils.decodeHTML(newVal));   //setting value
}

[iHub.Utils is a library of helper functions that I wrote]

The idea here is that val2() will appropriately encode the data retrieved from my text box when getting the value, and decode it prior to setting the value. This seems to work but I can’t shake the feeling that I must have a fundamental misunderstanding of how encoding/decoding is supposed to work in HTML5.

Is it standard practice to encode/decode data when using text boxes? Are text boxes special somehow in so far as they, unlike other common elements like <p> and <select>, don’t perform standard decoding when displaying an encoded input string?

Again, sorry if this is too basic. HTML5 and JavaScript are fairly new to me and my “Intro to HTML5”-type books don’t really discuss this topic in any depth.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    HTML encoding is for HTML documents. If you were including your value in the HTML document itself, e.g. <input value="10 &gt; 5" />, you would encode it, to make sure that things like > in your value aren’t confused with the > that closes the tag.

    But when you use JavaScript to set a field’s value, there’s no room for confusion. You’re not modifying a tag like <input.../>; you’re modifying a JavaScript object. So you shouldn’t HTML-encode the value. If you’re using a string variable, like in your example, you don’t need to do any encoding at all.

    On the other hand, if you’re using a string literal to specify the value, you need to encode it as a JavaScript string, e.g. by escaping the ' in $("#festus").val('can\'t'). This is exactly the same reason you do HTML encoding; to avoid confusion with the ' that closes the string.

    The only time you’d do HTML-encoding in JavaScript is when you’re using it to generate HTML code, e.g. el.innerHTML = '<input value="10 &gt; 5" />';.

    Because of this, I would suggest that you not HTML-encode strings in your AJAX responses or requests. Instead, avoid encoding until you’re actually generating the kind of code that requires the encoding. So only HTML-encode strings when you’re writing HTML, only JavaScript-encode strings when you’re writing JavaScript, and so on.

    • 0