On Fri, Aug 17, 2018 at 1:50 AM, Nils Fredrik Gjerull <n...@gjerull.net> wrote:
> I still would like a technical answer to why not support both standards? > And again XHTML5 is HTML5 with valid XML syntax. So valid XHTML5 is > valid HTML5, so there is no problem for a framework to provide HTML5 it > should just be done in the most compatible manner. > You probably won't get a "technical answer", because what you're proposing is not a technical change. So, look. I was someone who, in the 2000s, passed Evan Goer's "XHTML 100" test, even if he didn't test my site as part of it. I bought into it. But I gradually learned it's more of a headache than it's worth, and should be discouraged as a default. People who do still have use cases requiring XML toolchains are free to implement what's necessary to support that (for Django, that's mostly templating changes, and I believe we make it easy enough to supply your own overrides that you could do it as a 100% third-party effort for anyone else who shares your desire for XHTML). But requiring Django to maintain XML-serialization-of-HTML5 compatibility is a non-starter. It commits everyone else on earth to keeping that supported, to ensuring we never do anything that's not XHTML-compatible, etc., in order to serve a very small subset of developers, and I don't think you realize how much specialized domain knowledge is actually necessary to do that (it's more complex than "/>" and specifying attribute values). And I suppose if you really want technical arguments: JavaScript is not portable between XML and HTML contexts, full stop. This isn't just about the CDATA dance you have to do with inline script elements; it's about the fact that the HTML and XML DOMs are different. And not just with respect to namespaced versus non-namespaced DOM methods: XML's rules literally do produce a different parse tree from the same DOM when compared to HTML's. XHTML5 itself is neither well-specified nor robust; the new elements of HTML5 are more or less dumped by fiat into the old 1999/XHTML namespace, but who's to say parsers will actually be aware of that? Especially validating parsers? Can you point to a standardized XML DTD, XSD, RELAX NG or, well, anything that's broadly accepted as defining XHTML5? W3C doesn't publish one that I'm aware of, and the Editor's Draft for Polyglot does not provide guidance. And speaking of validating parsers: HTML5 has a large set of named entities. Validating XML parsers are required, as always, to accept only the base five of XML, and can fatal-error on anything else. For non-validating parsers, or for those which choose to accept more than the base five named entities, XHTML and HTML historically did not agree on the set (XHTML defined 253 named entities, HTML historically defined at most 252). More fun times there. XML-ENTITY-NAMES tried to alleviate this by defining and exposing entity sets documents could refer to, but see again: validating parsers don't have to accept them. Are we forbidden ever to use an HTML5 entity, or anything outside the base five XML entities, in Django, in order to make sure serving Django as XHTML works? I hope not. While we're on the topic of characters: HTML5's character encoding rules are not compatible with XML's. Compliant HTML5 processors *must* use the 8.2.2.2 encoding sniffing algorithm in their first pass, and this can produce a different determined encoding than XML's rules (and let's not get into the quagmire of default encoding varying with Content-Type headers). And, well, I could go on for a while here because my rants on this topic are pretty well-developed at this point, but I'll just leave it alone here. I'm strongly against any attempt to have Django try to produce XML-serializable polyglot HTML5. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg_NdtL2kO_VCO41hAprWi3r5%3DF1baD0ASchCoBoMQexmQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
