Hacker News Reader

Comment by alex-moon | Hacker News Reader

In the job I'm currently in (doing front-end for the first time in many years) I can confidently say that every time we've had a bug that was browser-specific, that browser was some brand of Safari - usually Safari mobile, which shits me even more because the iPhone doesn't let users install any alternatives, i.e. literally what Microsoft went to court for. Reason enough on its own not to get an iPhone, or indeed any Apple product at all. I can only imagine how much Safari has cost the industry in wasted dev time.

View on HN

Microsoft went to court over that because they were leveraging their OS monopoly into a browser monopoly. Microsoft always let you install alternatives by the waybut IE was the default and most people don’t change defaults.

Apple is not a monopoly unless you’re just looking at mobile profits, which historically is not how a monopoly is defined (they’re not even a monopoly in the luxury smartphone market). Android is actually much closer to being a monopoly and does all sorts of deals to maintain their monopolies on search, browsers, and Android which would warrant investigation. Now maybe a monopoly should be defined as % of total profits in a market? Not sure. It would be breaking new regulatory ground for sure.

Also, from the sounds of it, Apple is going to be forced to allow third party browsers and app stores via EU regulation. It’s less clear exactly how that will work and whether that will be available to customers in other jurisdictions.

I knew this bit of false internet lore was going to come up.

Out of all the things that the justice system was throwing at MS, bundling IE was the least of them and absolutely nothing changed about browser bundling in the US. No there was never a browser choice mandate.

That’s true. The main focus was on forcing OEMs to bundle Windows for kickbacks. The browser stuff came out of the EU.

As is true with most laws involving tech and the EU.

https://arstechnica.com/information-technology/2014/12/windo...

> While there were early signs that the browser ballot screen was influencing browser usage in the EU, with Mozilla attributing some European Firefox growth to the selection page, long-term trends strongly suggest that it was next to useless. In spite of equally prominent placement on the selection screen, Opera's share even within Europe appears to have declined over the last five years. So too have Firefox and Internet Explorer. Chrome, however, has experienced significant growth.

> Android is actually much closer to being a monopoly

Thats only true outside of the US though. iOS is >60% in the USA.

Not sure where that number comes from. [1] indicates Apple broke 50% for the first time ever in Q3 2022. I doubt they’ve pole vaulted to 60% the past few quarters.

[1] https://9to5mac.com/2022/09/02/iphone-us-market-share/

Sometimes you can even tell it just from the sentry error text itself that it's a safari bug.

It has a kind of distinctive feel of nonsense, I don't know how to explain it.

Laughable take. When there was only IE6 people complained. Now that there is more than one people complain that they have to test their stuff more and wish to go back to one browser to rule them all. You don't like testing? How hard can it be to test on the top 3-4 browsers? Maybe it's not wasted dev time, it's called work? Maybe software industry isn't for you... Sidenote: Why so many snowflakes on HN? Too much entitlement or is it the easy money? In what job is it considered acceptable to not test on half the devices in the world?

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).

> 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?

> How is it bogus? outerHTML is an attribute of Element

Re-read what is written. I'm setting the outerHTML property of an element, not setting it for the fragment (which is the only way that your response would make sense).

> Have you considered that it's just a Gecko quirk that it happens to work in Firefox?

No, because I'm not a moron.

> Where do the standards say it ought to work?

Exactly where you'd expect to find it: in the specification of the outerHTML property (Leithead et al. DOM Parsing and Serialization, Extensions to the Element interface, §7.1 Attributes: outerHTML. 2016.)

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.

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...

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.

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.

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.

What?

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

> 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.)

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.

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.

> 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

Reply on news.ycombinator.com