angular: Template parser fails when

wraps a child element

Have to say I absolutely hate such purism. It works in browsers, but Angular is too noble to render it. In practice it will just break some templates and create huge issues when source of content can’t be controlled by frontend developer. For example, when you pull content from database. I know it sounds too old-fashioned, but some companies store some things in DB, where urgent edits are critical (such as Terms Of Service).

Another example - third party modules, plugins. If some author of some JS plugin will be dare enough to make such criminal thing as <p><div>, it will accidentally kill whole your app, because tiny soul of Angular renderer can’t survive near so dirty html.

@zoechi you forgot to say “please” I think. Not sure why you allow so commanding and agressive tone to yourself and don’t allow to even share opinion to Patrik. For the note, p inside div is valid, talk was about div inside p, so your bold is as funny as agressive.

@pkozlowski-opensource it doesn’t matter what browsers do until user/designer see “it works” and push it to DB. You ignored that example for some reason 😃

but it is important to realise that invalid HTML is … invalid HTML

Why it’s important? What it gives to us/framework? I really see it as just perfectionism, nothing else.

and browsers might do all sort of crazy things with it in order to make some sense of it

they can do crazy things with 100% valid HTML too, so it’s not an argument. That’s why testing tools and QA departments exists.

@e-oz no idea what you mean. Yes I mixed the order of p and div - thanks for pointing that out, but my comment says

Please stop spamming issues …

@patrikx3 Custom elements are valid and, p inside div is invalid. This was already pointed out to you.
Please stop spamming issues with irrelevant comments (that was also already pointed out to you).

@patrikx3 anything to back up that claim? Perhaps you should first try to understand what Angular does before criticizing?

a hypotetical broken 3rd party would only fail if an author didn’t run it at all - I guess there is no good reason to use shuch 3rd parites…

ok, it means parser will not throw an exception if some JS code will change code of page in runtime. Good to know.

Have to say I absolutely hate such purism. It works in browsers

@e-oz it really doesn’t “work” that well in a browser. Try this in your favourite one:

var elm = document.createElement('div').innerHTML = '<p><div></div></p>';

In chrome this will give you:

<div><p></p><div></div><p></p></div>

which means that a browser “auto-corrected” invalid HTML. The assumption was that it is better to catch those errors during compilation (a hypotetical broken 3rd party would only fail if an author didn’t run it at all - I guess there is no good reason to use shuch 3rd parites…) rather than be sorry at runtime.

Once again - let’s improve it as much as possible, add better error messages etc. but it is important to realise that invalid HTML is … invalid HTML and browsers might do all sort of crazy things with it in order to make some sense of it.

@jelbourn I agree. Issues like these are popping up here every now and then again and again. Maybe it’s better to display an error message that says sth. like: “{{tag}} can’t contain child element of type {{type}}”?

@pkozlowski-opensource I think we should be a little more clear on the error message in this case, as this is one of the more obscure spec details. What do you think?

(it wasn’t obvious to me when @josephperrott showed me)