News for hackers. Stuff that matters.

A comment on Safari releases are development hell. Parent comment

Re:Safari releases are development hell by cxr on Monday April 03, 2023 @10:29AM (#35424171)
I've run into a pretty ridiculous Chrome bug:

  let f = document.createDocumentFragment();
  f.appendChild(document.createElement("div"));
  f.firstChild.outerHTML = (`<a href="https://bugs.chromium.org/"></a>`);
Fails because a fragment "is not an element node", a completely bogus error. No idea if it fails in Safari, too, since I don't have a Mac anymore, but I'd guess so, since this reeks of the type of corner-cutting that WebKit was guilty of while swimming in accolades for being a fast, standards-compliant browser engine (in contrast to e.g. Gecko).
[ Parent | on HN ]
Re:Safari releases are development hell by lapcat on Monday April 03, 2023 @10:49AM (#35424557)
> a completely bogus error

How is it bogus? outerHTML is an attribute of Element https://developer.mozilla.org/en-US/docs/Web/API/Element/out... and DocumentFragment is not an Element https://developer.mozilla.org/en-US/docs/Web/API/DocumentFra...

> No idea if it fails in Safari, too

It does.

Have you considered that it's just a Gecko quirk that it happens to work in Firefox? Where do the standards say it ought to work?

[ Parent | on HN ]
Re:Safari releases are development hell by cxr on Monday April 03, 2023 @11:40AM (#35425642)
* * *
[ Parent | on HN ]
Re:Safari releases are development hell by lapcat on Monday April 03, 2023 @12:53PM (#35427202)
See the Notes section of the docs: "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." https://developer.mozilla.org/en-US/docs/Web/API/Element/out...

The div has a parent node but no parent element, because a document fragment is not an element.

[ Parent | on HN ]
Re:Safari releases are development hell by LegionMammal978 on Monday April 03, 2023 @12:57PM (#35427283)
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-Ele...

[ Parent | on HN ]
Re:Safari releases are development hell by lapcat on Monday April 03, 2023 @01:13PM (#35427579)
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.
[ Parent | on HN ]
Re:Safari releases are development hell by cxr on Monday April 03, 2023 @02:36PM (#35429078)
* * *
[ Parent | on HN ]
Re:Safari releases are development hell by LegionMammal978 on Monday April 03, 2023 @03:05PM (#35429568)
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.
[ Parent | on HN ]
Re:Safari releases are development hell by cxr on Tuesday April 04, 2023 @09:44AM (#35439479)
What?
[ Parent | on HN ]
Re:Safari releases are development hell by LegionMammal978 on Wednesday April 05, 2023 @10:09AM (#35454515)
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

[ Parent | on HN ]
Re:Safari releases are development hell by cxr on Wednesday April 05, 2023 @11:29AM (#35455831)
> 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.)

[ Parent | on HN ]
Re:Safari releases are development hell by LegionMammal978 on Wednesday April 05, 2023 @12:02PM (#35456340)
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.

[ Parent | on HN ]
Re:Safari releases are development hell by LegionMammal978 on Monday April 03, 2023 @02:40PM (#35429145)
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.

[ Parent | on HN ]
Re:Safari releases are development hell by LegionMammal978 on Monday April 03, 2023 @12:55PM (#35427237)
> Where do the standards say it ought to work?

The wording has not changed since the 2016 version of the DOM Parsing and Serialization standard [0]:

> On setting, the following steps must be run: 1. Let parent be the context object's parent. [...] 4. If parent is a DocumentFragment, let parent be a new Element with

> - body as its local name,

> - The HTML namespace as its namespace, and

> - The context object's node document as its node document.

But Blink instead throws a DOMException with name "NoModificationAllowedError" and message "Failed to set the 'outerHTML' property on 'Element': This element's parent is of type '#document-fragment', which is not an element node." This was filed as a Chromium bug last December and assigned a week later [1].

[0] https://www.w3.org/TR/2016/WD-DOM-Parsing-20160517/#widl-Ele...

[1] https://crbug.com/1403060

[ Parent | on HN ]