Angular.js: custom directives with self closing tags capture tag siblings

self-closing or void elements as the html spec defines them are very special to the browser parser. you can't make your own, so for your custom elements you have to stick to non-void elements (<foo></foo>).

this can't be changed in angular. closing.

This just tripped me up, too. Could something be added to the documentation? Nothing shows up when searching for "self-closing tag" on the Angular site, but Google got me here.

There are no directives with self-closing tags unfortunately, it's not really possible to support these, as the HTML parser in the browser decides if a tag is allowed to be a void tag or not. :(

I think this is mentioned in the documentation, but if it's not, please submit a patch making a note of it!

Maybe I'm not using the right documentation? Searching for "self-closing" is a no-op (doesn't even say "no results" or anything) and searching for "directive" gives me a ton of results, none of which have the word "directive" in the link. So, I'm not sure where that patch would go.

You can deliver your document as XHTML if you want use custom "self-closing" or void elements, but I have never tried to use AngularJS with XHTML.

:+1: @chbrown: For proposal for mentioning this in the documentation of directives.
:+1: @Lenne231: For an interesting observation: Does AngularJS work for XHTML?

:+1:@Lenne231: For an interesting observation: Does AngularJS work for XHTML?

At least some of it works for XHTML, though it's not clear how much.

Just came across a scenario with <textarea> needing to be self-closing in IE.

Is this a non-issue or is there a workaround? Would the powers-that-be also add an answer to that question on Stack Overflow for future references.

@IgorMinar, I disagree with your reading and interpretation of the spec. Here is the VOID ELEMENT specification. It doesn't say that it's "very special to the browser". It does say that it can have "no content under any circumstances". It's possible, in that case, that the Angular team could declare that's the standard and end the discussion. It's also possible (but you don't say) that Angular cannot properly process DOM VOID Elements across browser types.

However, I don't believe any of these hold water. There's no reason not to fix this behavior. The correct fix would be to replace the void element with start & finish tags (appears to be the current behavior and Angular already manipulates the DOM all over the place) and then NOT grab the peers or otherwise wipe them out (i.e. fix the bug). Otherwise, we are forced to write HTML code that is a work-around.

<speaker-control ng-model="volume"/> is so much more preferable than <speaker-control ng-model="volume"></speaker-control>

Meh. Please reconsider this or post a pointer to the Angular source code that processes directives. Maybe someone here will have the time, energy and chops to submit a fix for future inclusion.

Here is a jsFiddle if anyone feels like watching this happen and or for a simple test case.

OK, I stand corrected on this. Here's a Stack Overflow Q&A on the topic. One commenter stated that the problem is with Browser (mis)interpretation for void elements. I created another jsFiddle that demonstrates the browser behavior that is the cause of this problem. I suspect this was an early incorrect implementation in some original browser that has now propagated to every browser. This is a rarely used tag syntax and most folks don't understand how void elements are supposed to work. XML (and SGML before it) set all of this up years ago; this is not the way that tag semantics is supposed to work. Quite honestly, all browser behaviors should be fixed. Somehow, I doubt a little side case in a front end MVC framework will trigger a WWW change in browsers. If it is to be fixed, I imagine it will have to go into the next W3C revision to HTML. Anyone feel like taking up the torch?

Just a thought here. Maybe it's stupid. But would it work to add an angular directive to a self-closing <br />?

@bjorn-ali-goransson, it should work, but I don't see how this is related to this thread.