4 ms·

The standard says that if the parent node is a DocumentFragment, then a temporary Element must be created to act as the context element for fragment parsing [0]

The standard says that if the parent node is a DocumentFragment, then a temporary Element must be created to act as the context element for fragment parsing [0]. [0] https://www.w3.org/TR/2016/WD-DOM-Parsing-20160517/#widl-Element-outerHTML https://www.w3.org/TR/2016/WD-DOM-Parsing-20160517/#widl-Ele...

lapcat 4y ago
Well, if Mozilla's own web developer API documentation contradicts the spec here, then I'd say that none of the browser vendors are doing on good job on this particular issue.
- cxr 4y ago
  It's documentation. It's describing the Blink/WebKit behavior and couching it in terms of what "many browsers" do—it's not saying what they should do; all you've done is linked to a page that says the bug exists. Nice try moving the goalposts, though. It has been a monumental waste of energy participating in this conversation.
  - LegionMammal978 4y ago
    That's not quite what it says; it says that (unconditionally) it will do nothing without a parent element and (conditionally, depending on the browser) it will throw an exception. The first part is inaccurate, since the standard behavior (which is the current behavior of Gecko and the intended behavior of Blink) is to let it work naturally on children of DocumentFragments. It should probably be updated to clarify this, but I wouldn't see the remark as very "normative" in the first place.
    - cxr 4y ago
      What?
      - LegionMammal978 4y ago
        I just don't see how you interpreted the remark in the way you did. Regardless, I've filed a PR to make the docs clearer [0] so neither of us has to waste any more time on this. [0] https://github.com/mdn/content/pull/25925 https://github.com/mdn/content/pull/25925
        cxr 4y ago
        > I just don't see how you interpreted the remark in the way you did Can you be concrete? (This reply doesn't really clear up anything about the previous comment.)
        LegionMammal978 4y ago
        Well, it literally says, "If the element has no parent element, setting its outerHTML property will not change it or its descendants. Many browsers will also throw an exception." I interpret this as, "If the element has no parent element, setting its outerHTML property will not change it or its descendants. Many browsers will throw an exception [on setting an element's outerHTML property if it has no parent element]." This contains two independent statements, (a) "If the element has no parent element, setting its outerHTML property will not change it or its descendants," and (b) "Many browsers will also throw an exception [on setting an element's outerHTML property if it has no parent element]." Statement (b) is true, since Chromium- and WebKit-based browsers will throw an exception if the element doesn't have a parent node which is also an element. Statement (a) isn't browser-specific, and thus it is false, since on Firefox, setting an element's outerHTML will change it and its descendants if its parent node is a document fragment (which is not a parent element). Where we differ might be that I don't see the "many browsers" qualification as applying to the first statement.
- LegionMammal978 4y ago
  To be fair, the Exceptions section on that page gives the correct criterion: > NoModificationAllowedError DOMException > Thrown if an attempt was made to set outerHTML on an element which is a direct child of a Document, such as Document.documentElement. So I'd say the Notes section is simply imprecise.

lapcat 4y ago

Well, if Mozilla's own web developer API documentation contradicts the spec here, then I'd say that none of the browser vendors are doing on good job on this particular issue.

cxr 4y ago
It's documentation. It's describing the Blink/WebKit behavior and couching it in terms of what "many browsers" do—it's not saying what they should do; all you've done is linked to a page that says the bug exists. Nice try moving the goalposts, though. It has been a monumental waste of energy participating in this conversation.
- LegionMammal978 4y ago
  That's not quite what it says; it says that (unconditionally) it will do nothing without a parent element and (conditionally, depending on the browser) it will throw an exception. The first part is inaccurate, since the standard behavior (which is the current behavior of Gecko and the intended behavior of Blink) is to let it work naturally on children of DocumentFragments. It should probably be updated to clarify this, but I wouldn't see the remark as very "normative" in the first place.
  - cxr 4y ago
    What?
    - LegionMammal978 4y ago
      I just don't see how you interpreted the remark in the way you did. Regardless, I've filed a PR to make the docs clearer [0] so neither of us has to waste any more time on this. [0] https://github.com/mdn/content/pull/25925 https://github.com/mdn/content/pull/25925
      - cxr 4y ago
        > I just don't see how you interpreted the remark in the way you did Can you be concrete? (This reply doesn't really clear up anything about the previous comment.)
        LegionMammal978 4y ago
        Well, it literally says, "If the element has no parent element, setting its outerHTML property will not change it or its descendants. Many browsers will also throw an exception." I interpret this as, "If the element has no parent element, setting its outerHTML property will not change it or its descendants. Many browsers will throw an exception [on setting an element's outerHTML property if it has no parent element]." This contains two independent statements, (a) "If the element has no parent element, setting its outerHTML property will not change it or its descendants," and (b) "Many browsers will also throw an exception [on setting an element's outerHTML property if it has no parent element]." Statement (b) is true, since Chromium- and WebKit-based browsers will throw an exception if the element doesn't have a parent node which is also an element. Statement (a) isn't browser-specific, and thus it is false, since on Firefox, setting an element's outerHTML will change it and its descendants if its parent node is a document fragment (which is not a parent element). Where we differ might be that I don't see the "many browsers" qualification as applying to the first statement.
LegionMammal978 4y ago
To be fair, the Exceptions section on that page gives the correct criterion: > NoModificationAllowedError DOMException > Thrown if an attempt was made to set outerHTML on an element which is a direct child of a Document, such as Document.documentElement. So I'd say the Notes section is simply imprecise.