-
-
Notifications
You must be signed in to change notification settings - Fork 33.7k
DOM exception in Chrome, Edge when using application/xhtml xml content type #5852
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
this is not a reproduction. Please provide the minimum of runnable code that deomnstartes the problem. |
@LinusBorg You can copy and paste that data URI into your Chrome or Edge browser and then look at the developer console. |
This is the content of the data URI: |
Why would you need this? What's the use case? |
The use case is that my team serves web content as application/xhtml+xml, and has successfully for a decade across desktop, mobile, and embedded applications. We've found it extremely useful as the "use strict" of HTML, or a more aggressive "standards compliance mode". It eliminates historical idiosyncrasies in HTML (self-closing vs not, tag capitalization, CDATA browser quirks), it prevents certain types of XSS attacks, disallows harmful things like document.write and IE conditional comments, and fails fast on many types of errors. The extra strictness of the XHTML syntax caught the offending line in this patch that is technically invalid HTML 5. HTML and XML syntaxes are both valid in HTML 5.2 and WHATWG HTML specs. XML representation of HTML5 is not deprecated, discouraged, or considered outdated by any standards body I'm aware of. All browsers support XML formulation of HTML documents natively since IE 9. There's a lot of obsolete FUD about XHTML out there because few people understood the difference between content type and doctype and didn't want to serve polyglot documents for IE <=8. There was also confusion about the relationship of XHTML 1.1 (obsolete) and 2.0 (never finalized) with "XHTML 5" (alive and well) that didn't help the situation. Making content compatible with both content types and syntaxes is trivial. We've had tiny patches like this one accepted by Google, Facebook, Akamai, advertising networks, and several open source projects over the years (often after a 'why?' conversation like this one). Given that the rest of Vue seems to be nearly 100% compatible with application/xhtml+xml documents already, we're hoping that you'll accept this patch so we don't have to maintain a fork for a backwards compatible single character change :-) If the self-closing slash really is a problem for ideological reasons, writing that code as |
@dvdckl ha, I was a bit confused and didn't realize the fix was that simple. Does this mean Blizzard will start using Vue now? ;) |
He created a PR right from the start actually 😆 #5853 |
Yeah I just realized this as well, totally missed it 🙈 |
Sorry, didn't see the related PR earlier... I removed my commit and merged it :) |
wow~ |
Version
2.3.4
Reproduction link
data:application/xhtml+xml;base64,PGJvZHkgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPjxzY3JpcHQgc3JjPSJodHRwczovL3VucGtnLmNvbS92dWVAMi4zLjQiLz48L2JvZHk%2B
Steps to reproduce
In Chrome or Edge, load the vue.js script in a document served as application/xhtml xml to generate an uncaught exception.
What is expected?
No exception in both text/html and application/xhtml xml documents
What is actually happening?
"Uncaught DOMException: Failed to set the 'innerHTML' property on 'Element': The provided markup is invalid XML, and therefore cannot be inserted into an XML document."
The text was updated successfully, but these errors were encountered: