(In reply to Olli Pettay from comment #0)
> see https://bugzilla.mozilla.org/show_bug.cgi?id=923913#c7

Olli, it looks like you landed a patch to Gecko to prevent inner/outerHTML throwing? Has this been in your stable release for long? Any fallout from the change?

Is the intention here to return an empty string in cases where an exception would be raised?

Actually I don't see that any browsers throwing:

<script>

var serializer = new XMLSerializer();	
var newDoc = document.implementation.createDocument(null, null, null);
var newEl = newDoc.createElement("div:"); // forbidden ":"
newEl.appendChild(newDoc.createComment("--")); // forbidden "--"

// innerHTML/outerHTML for XML should be well-formed
alert(newEl.innerHTML);
alert(newEl.outerHTML);

// serializeToString() does not have to be well-formed (for both XML and HTML)
alert(serializer.serializeToString(newEl)); // forbidden as above
alert(serializer.serializeToString(newDoc)); // forbidden (root not exist)

</script>

Firefox and Chrome:
1. <!------>
2. <div:><!------></div:>
3. <div:><!------></div:>
4. ""

IE11:
1. undefinded
2. undefinded
3. <div:><!------></div:>
4. ""

If killing well-formed flag for serialization then parsing API will be the only way to detect error (serialize+parse vs serialize)?

Thanks for the repro.

To match implementations, we should probably make innerHTML/outerHTML not throw. Does this extend to insertAdjacentHTML? (I presume it does.)

It has always seemed strange to me that an XML serialization (specifically XMLSerializer::serializeToString) doesn't throw when encountering invalid XML). With innerHTML/outerHTML, there's not a lot of options to allow web devs to pass flags to control well-formed-ness. However, for serializeToString, we _do_ have an option of providing an option to the function call that might enable a well-formed check.

Just thinking out loud:
WebIDL:
```
DOMString serializeToString (Node root, optional SerializationOptions options);

dictionary SerializationOptions {
   boolean throwOnXMLError = false;
};
```

WDYT? Would browsers be willing to adopt this? Is this valuable to web devs?

Yesterday I think something simillar - adding second argument to serializeToString(), optional nature should not breake actual content and provied fast way for checking node tree as required by XML. Something what we have for DOMParser.parseFromString() where we can decide what parser rules are used.

Travis, if you take attention around serializeToString(), what about directly passing Attr object? Intention is Attr not inherit from Node, but in future it is possible in all scenerio? Look this small test:

<script>

	var serializer = new XMLSerializer();
	var newAttr = document.createAttribute("id");
	newAttr.value = "test";

	try{
		var returnValue = serializer.serializeToString(newAttr);
		document.write("Error not throw:" + "<br>");
		document.write(typeof returnValue + "<br>");
		document.write(returnValue + "<br>");
		document.write(returnValue.length + "<br>");
	}
	catch(e){
		document.write("<br><br>" + "Invalid input data for serializeToString():" + "<br>");
		document.write(e);
	}

</script>

All browsers accept Attr object as argument for serializeToString() and not throw, but Firefox and Chrome return empty string, whene IE11 return attr's value. If this behaviour will not change then one of them should be standarized in P&S specyfication. Some telemetry could be useful here, maybe throwing is still possible.

(In reply to Arkadiusz Michalski (Spirit) from comment #4)
> All browsers accept Attr object as argument for serializeToString() and not
> throw, but Firefox and Chrome return empty string, whene IE11 return attr's
> value. If this behaviour will not change then one of them should be
> standarized in P&S specyfication. Some telemetry could be useful here, maybe
> throwing is still possible.

I would expect the throwing/not throwing in this scenario to be tied to a common flag used by the algorithm.

It is not possible to represent an attribute independently of an element in the XML serialized form--so the Firefox/Chrome behavior seems much more correct (unless throwing is a possibility).

+1 for adding this case to the spec.

(In reply to Travis Leithead [MSFT] from comment #3)

> To match implementations, we should probably make innerHTML/outerHTML not
> throw. Does this extend to insertAdjacentHTML? (I presume it does.)

Hmm, Element.insertAdjacentHTML() makes parsing, all parsing APIs throw for XML, even innerHTML/outerHTML when setting, Range.createContextualFragment() or DOMParser.parseFromString() (this last expose error document instead of throw error). 

Problem exist only for serialization stuff, like innerHTML/outerHTML getting and XMLSerializer.serializeToString().

(In reply to Travis Leithead [MSFT] from comment #5)
> I would expect the throwing/not throwing in this scenario to be tied to a
> common flag used by the algorithm.

If not throw (because wrong type) then changing IDL is necessary, serializeToString() must accept Node and Attr (new typedef?) as argument, and handle Attr depending on the flag by the algorithm.