| 01:01 | <eligrey> | empty xml documents are valid, but it seems that every vendor misread the whatwg domparser spec |
| 01:02 | <eligrey> | for some reason all browsers give you a <parsererror> when you do (new DOMParser).parseFromString("", "application/xhtml+xml") |
| 01:02 | <eligrey> | but no errors when you do document.implementation.createDocument('','',null) (equivalent empty document) |
| 04:11 | <annevk> | eligrey: what makes you say they are well-formed? |
| 04:11 | <annevk> | eligrey: pretty sure they're not |
| 04:20 | <eligrey> | annevk: go to an empty xml file in chrome firefox ie or edge |
| 04:20 | <annevk> | eligrey: yeah, give a parse error |
| 04:20 | <annevk> | eligrey: e.g., data:text/xml, |
| 04:21 | <eligrey> | what browser? |
| 04:21 | <annevk> | Firefox Nightly |
| 04:21 | <MikeSmith> | I thought the XML spec says every XML document must have a root element |
| 04:21 | <annevk> | eligrey: https://www.w3.org/TR/xml/#sec-well-formed also pretty clearly requires an element |
| 04:21 | <eligrey> | oh, weird then |
| 04:22 | <annevk> | eligrey: it does seem that Chrome and Safari are buggy |
| 04:22 | <eligrey> | that the dom allows xml without an element |
| 04:22 | <eligrey> | document.implementation.createDocument('','',null) works in ff/ie/edge/chrome |
| 04:22 | <annevk> | eligrey: the DOM allows many things XML doesn't |
| 04:22 | <annevk> | eligrey: it's a model, not a syntax |
| 04:22 | <annevk> | those are often distinct in capabilities |
| 04:23 | <eligrey> | alright |
| 04:23 | <eligrey> | makes sense though that 2 dom methods should behave similarly |
| 04:23 | <eligrey> | since its domparser, not xmlparser |
| 04:23 | <annevk> | please do file a bug on Chrome/Safari though |
| 04:23 | <annevk> | eligrey: those APIs have bad names, arguably |
| 04:29 | <eligrey> | annevk: speaking of other irregularities, innerHTML=[invalid xml] throws an error and domparser makes an error element thingy |
| 04:29 | <eligrey> | so weird |
| 04:30 | <eligrey> | would be so much easier to handle if domparser just threw an error as well |
| 04:30 | <annevk> | eligrey: I suggest reading the topic of this channel |
| 04:30 | <eligrey> | alright, yeah i was just discussing stuff |
| 04:30 | <eligrey> | not asking for change |
| 04:31 | <annevk> | Yeah, I mean, I don't disagree, but compatibility is a real thing |
| 04:31 | <eligrey> | pretty sure domparser used to throw errors in all browsers except chrome |
| 04:31 | <eligrey> | and this parsererror thing is only a very recent addition |
| 04:31 | <annevk> | We hope of course that our generation designs better APIs and the folks five-fifteen years from now won't scream about the same irregularities |
| 04:32 | <annevk> | But they'll probably find lots to be upset about |
| 04:32 | <eligrey> | heh yeah |
| 04:32 | <annevk> | eligrey: given that <parseerror> has to be in some Mozilla-namespace I suspect it's pretty ancient at least for Firefox |
| 04:33 | <annevk> | And I also think the API might have originated there and then slowly copied by others |
| 04:33 | <eligrey> | hmm i remember back in 2009 implementing a text/html domparser shim |
| 04:33 | <eligrey> | and back then it was just chrome with <html:parsererrror> iirfc |
| 04:33 | <eligrey> | iirc* |
| 04:33 | <eligrey> | could be wrong though |
| 04:34 | <eligrey> | its a pretty cool feature outside of domparser though |
| 04:34 | <eligrey> | if you give parsererror a background image in css you can globally log xml well formedness errors on your site! |
| 04:34 | <eligrey> | (i did that on mine years ago) |