ansaurus

Question

Answer 1

A:

In that particular case, you don't have encode special HTML characters in JavaScript.

The W3C validator should not complain about this (just tested it) and the document should validate. If not post your code and I'll update my answer.

AlexV 2010-05-05 17:28:15

Fair point, but he didn't mention which file format he's using to save it.

jweyrich 2010-05-05 17:31:23

Answer 2

+1 A:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <title>Decode HTML entities using JavaScript</title>
  </head>
  <body>
    <img id="formula" src="vote-arrow-up-on.png" alt="A &rarr; C">
    <script>
      function html_entity_decode(str) {
        var p = document.createElement("p");
        p.innerHTML = str.replace(/</g,"&lt;").replace(/>/g,"&gt;");
        return p.innerHTML;
      }

      var theValue = html_entity_decode('A &rarr; B');
      document.getElementById('formula').title = theValue;
    </script>
  </body>
</html>

Credits to The JavaScript Source.

EDIT: I changed the original code to only use innerHTML on a <p> element, instead of innerHTML and value of a <textarea>.

Marcel Korpel 2010-05-05 17:32:33

s/'title'/'alt'/. +1

jweyrich 2010-05-05 17:42:59

@jweyrich: it's easier to see the effect using the `title` attribute ;)

Marcel Korpel 2010-05-05 17:52:07

Setting the HTML of a `textarea` should *not* change its form field `value` according to the standard DOM; the contained HTML maps to the textarea's `defaultValue` property, not `value`. It's a browser quirk that `innerHTML` also affects `value`, and it doesn't happen in Opera. Don't rely on it. You could write `innerHTML` to any other element and read the text node child it ends up with (if non-blank string). Also, avoid `setAttribute`, which is unnecessary in HTML documents, and buggy in IE.

bobince 2010-05-05 19:13:05

@bobince: FYI, I tested this example in Opera (10.10/Linux) and it worked fine. Also, why is `setAttribute` buggy in IE, in this case (and in cases you want to set a custom `data-…` attribute)? I can't find much about it, apart from [your post](http://stackoverflow.com/questions/748941/setattribute-onclick-and-cross-browser-compatability/749253#749253) explaining why setting event handlers using `setAttribute` doesn't work as expected (the same is true for e.g. the `style` object). If you want me to open a separate question about this, I'll be happy to do so.

Marcel Korpel 2010-05-11 01:09:56

IE<8 treats `el.getAttribute(someattr)`/`el.setAttribute(someattr, ...)`) as being the same as property access, `el[someattr]`. Consequently, (1) any property whose value isn't a string will expose something that isn't a string. For integer properties you sometimes don't notice as weak typing hides it from you, but booleans, event handler functions and `style` will often trip you up. (2) any property whose name is different from the corresponding attribute will fail. That's `htmlFor`, `className`, and any attribute name made from multiple or hyphenated words.

bobince 2010-05-11 22:54:02

(3) any property which has a different meaning to its attribute will behave strangely. For example `href` will return the full resolved URL in a link, not the original, possibly-relative version that was actually used in the attribute value, and `value` returns a form field's current value, and not the content of the `value` attribute (which actually maps to `defaultValue`). Also (4) custom-attributes can shadow real properties, so writing `<div nodeType="3">` might confuse a script into thinking it's a text node.

bobince 2010-05-11 22:54:20

(This is another reason custom attributes should be avoided, but if you must use them then yes, you must use `getAttribute` exclusively to access them, and if you've got any sense you'll limit this use to attributes prefixed `data-`.)

bobince 2010-05-11 22:55:30

Answer 3

+1 A:

Here's an alternative if you can't save your file using a Unicode format:

function decodeHTML(str) {
    return str.replace(/&#(\d+);?/g, function() {
        return String.fromCharCode(arguments[1])
    });
}

However, this requires you to use the numeric representation. In this case →.

jweyrich 2010-05-05 17:55:12

IMHO you've suggested the *easiest workaround*. Even if it is a workaround, and not an answer, I accept it and that's the solution I will use for my code (converting entities like `↑` to `↑` on server side).

MainMa 2010-05-05 18:03:25

I hate to be that guy, but please take a look at my answer.

Sidnicious 2010-05-05 18:04:03

@Sidnicious No please, your solution is the best IMO! +1 from me! @MainMa feel free to accept his answer instead. I'd go for it :)

jweyrich 2010-05-05 18:07:07

@Sidnicious: well, it may be an alternative solution. Both are good, I think, so I uprated yours, still letting the answer of jweyrich as accepted, because it seems more straightforward, and does not require to use JavaScript character codes (different from HTML codes).

MainMa 2010-05-05 18:09:40

JavaScript string literal escapes are in hex, like `→` escapes in HTML. If you really want to use the decimal codes you can: `'A '+String.fromCharCode(8594)+' B'`.

bobince 2010-05-05 19:18:12

@MainMa: Like bobince said, the only difference is decimal/hexadecimal. It's trivial to convert, you can even use JavaScript: `(8594).toString(16) → "2192"`!

Sidnicious 2010-05-06 16:00:40

Answer 4

+4 A:

JavaScript has its own system for escaping special characters in strings:

document.getElementById('formula').alt = 'A \u2192 B';

Sidnicious 2010-05-05 18:02:24

+1. When you are assigning DOM properties, you **don't need HTML-encoding**. If you want the character `→` just paste it in; it's perfectly valid to say `img.alt= 'A → B';`. That only requires you to get the encoding you're saving your page as to match what you're serving it as (best: use UTF-8 for both). The JavaScript string literal escape `'A \u2192 B'` is a good fallback if you can't rely on non-ASCII characters being served properly.

bobince 2010-05-05 19:16:18

@bobince: That was my first answer, too, but the question explicitly states: "How to do it through JavaScript, when it is not possible to put the special (unencoded) characters in the source code?" Moreover, this solution presupposes the source is a Unicode value, but the question's example uses an HTML entity. Oh, and really, no offence meant, I'm just wondering what to do in such a situation.

Marcel Korpel 2010-05-05 22:45:02

Yeah, my feeling is there's a common assumption that non-ASCII characters need escaping which is much less often true than people think. (Indeed, the phrase 'special characters' is itself a misnomer when we're talking about 99.9% of all characters...) In any case there will be no difference between setting `innerHTML` to `rarr;` or `→` because all HTML parsers replace entity references with their text equivalent: you never get a DOM EntityReference node.

bobince 2010-05-06 14:06:14

@bobince: I think it would be great if authors could comfortably include any character in a document, but I've seen way too many encoding fails to recommend it, and I'd only do it myself if I had control over the website, server, VCS, and editors used by the developers. "Special characters" means every character that's at risk for being broken by bad encoding, everything but the ASCII 95.

Sidnicious 2010-05-06 15:57:39

ansaurus

tags:

views:

answers:

Alt attribute encoding with JavaScript

related questions