-1

I'm not sure why this jQuery is outputting malformed HTML:

<img src="http://farm6.static.flickr.com/5300/5459333519_0bfb0763b0_m.jpg">

From this code:

$.getJSON("http://api.flickr.com/services/feeds/photos_public.gne?id=59597329@N08&lang=en-us&format=json&jsoncallback=?", function(data){
    $.each(data.items, function(i,item){
        $("<img>").attr("src", item.media.m).appendTo("#mac");
    });
});

#mac is the div to hold the images

Can anyone make sense of this?

benhowdle89
  • 36,900
  • 69
  • 202
  • 331

2 Answers2

5

That HTML is perfectly valid. (For XHTML you'd have to use a self-closing element.)

But that doesn't matter, because by the time jQuery is modifying things, it's interacting with the DOM (the markup part of things is pretty much over, except that jQuery uses innerHTML when it can under-the-covers). So you won't see the result as markup except in tools (like Firebug) that will show you DOM structures as HTML strings. If you're using an XHTML document, perhaps whatever tool you're using isn't following XHTML convention for display purposes, but that's just a display problem, not an actual problem with the page.

Think of it this way: Markup is like a string literal in your source code; the DOM is like the actual string at runtime. Debuggers will show you a string's contents at runtime, usually using similar notation to string literals (though that varies); similarly, tools like Firebug and Chrome's dev tools, etc., show you DOM structures using markup notation. But that's just a display thing in the tool.

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
  • 1
    Agreed--markup validity is a concern when creating markup for a browser to parse into a DOM tree. Viewing "generated source" or something like the HTML tab of Firebug and seeing what you consider to be invalid is not a concern at all. It's just that programs representation of what exists in memory. – JAAulde Feb 20 '11 at 12:50
0

It's not jQuerys .appendTo which causes the "problem". At snippet like this:

var bar = document.createElement('img');
    bar.setAttribute('src', 'http://farm6.static.flickr.com/5300/5459333519_0bfb0763b0_m.jpg');
    document.body.insertBefore(bar, document.body.firstChild);

will also create an <img> node without a closing </img>. Anyway this is absolutly fine and valid in all browsers. If some XHTML validation does complain about this, you may ignore it gracefully.

jAndy
  • 231,737
  • 57
  • 305
  • 359
  • The "closing" tag is a *markup* concept. This is the DOM we're interacting with, not markup. Whatever's showing you markup for that is a tool that's reading the DOM and *rendering* it as markup, which is something else entirely. – T.J. Crowder Feb 20 '11 at 12:50
  • @T.J.: agreed. Anyway, most tags must have a closing tag or `/>` by specification. It's also a difference if your document is `HTML` or `XML` marked when a browser does parse it. For instance, a ` – jAndy Feb 20 '11 at 12:54
  • My point is that all of this is happening after the parsing of the page is complete; markup no longer applies (except when you're getting/setting `innerHTML`), we're manipulating the DOM. If you're seeing markup, you're just seeing what a tool is generating when you're looking at the DOM structure, just like a debugger will show you a string's contents using notation similar to string literals. Speaking of markup, though, the OP hasn't said he's using XHTML, and the `/>` thing is *invalid* in HTML for void elements like `img`: http://www.w3.org/TR/html5/syntax.html#elements-0 – T.J. Crowder Feb 20 '11 at 13:03
  • Sorry, my comment that `/>` is invalid in HTML with void elements like `img` is wrong: http://www.w3.org/TR/html5/syntax.html#start-tags It's allowed, it's just ignored if it's there. – T.J. Crowder Feb 20 '11 at 13:15