Skip to content

Remove notes about document.all being readonly#7193

Merged
ddbeck merged 1 commit intomdn:masterfrom
foolip:readonly
Nov 3, 2020
Merged

Remove notes about document.all being readonly#7193
ddbeck merged 1 commit intomdn:masterfrom
foolip:readonly

Conversation

@foolip
Copy link
Copy Markdown
Contributor

@foolip foolip commented Oct 30, 2020

These notes were added in #3391,
after the change in https://chromium-review.googlesource.com/c/chromium/src/+/823513/.

Previously it was possible to assign document.all, and now it is not.
The uses of document.all that currently work also work with older
browsers, so there isn't anything that web developers need to be aware
of here. The only time when it might have mattered was at the time of
the change, if someone depending on being able to use document.all to
store their own values, which in itself is an unlikely scenario.

These notes were added in mdn#3391,
after the change in https://chromium-review.googlesource.com/c/chromium/src/+/823513/.

Previously it was possible to assign document.all, and now it is not.
The uses of document.all that currently work also work with older
browsers, so there isn't anything that web developers need to be aware
of here. The only time when it might have mattered was at the time of
the change, if someone depending on being able to use document.all to
store their own values, which in itself is an unlikely scenario.
@github-actions github-actions bot added the data:api Compat data for Web APIs. https://developer.mozilla.org/docs/Web/API label Oct 30, 2020
@foolip
Copy link
Copy Markdown
Contributor Author

foolip commented Oct 30, 2020

@jpmedley @ddbeck I'd like both of your feedback on this one, if possible.

@vinyldarkscratch this is the followup I promised in #6865.

@jpmedley
Copy link
Copy Markdown
Contributor

jpmedley commented Nov 2, 2020

It's not clear to me why you're removing this information. We tend not to remove information that is correct even after it ceases to be enabled. (I'm excluding my position on flags here because flags aren't part of the platform.)

@queengooborg
Copy link
Copy Markdown
Contributor

I'd say that the reasoning behind the removal is because this property is defined as a read-only property per the spec. The chances of someone wanting to override a property like document.all are very slim, so a note like this isn't relevant to developers.

@ddbeck
Copy link
Copy Markdown
Contributor

ddbeck commented Nov 2, 2020

What's the story for the specification and the implementation? From #3391, it kinda looks like there was some sort of ambiguity in the spec. That seems interesting enough to note, though I'd probably frame it in historical terms ("Before version 65, this property is assignable… From version 65, the property is readonly, conforming to the updated specification" or something along those lines).

I'm trying to imagine a scenario where dropping the note makes sense and I guess it would be if the assignability was undefined in a specification that otherwise defined the behavior of document.all. Strictly speaking, there'd be no expectation of compatibility. But even that feels a tenuous.

@foolip
Copy link
Copy Markdown
Contributor Author

foolip commented Nov 2, 2020

document.all was added to HTML in whatwg/html@906460a, and was a readonly attribute from the start. There were a bunch of changes after that, for example whatwg/html@7e2400b + whatwg/html@6ba5e6d introduced+used HTMLAllCollection for it.

Before https://chromium-review.googlesource.com/c/chromium/src/+/823513/, it wasn't writable in any interesting way, it was merely possible to replace the object. Compare this do setting document.body which actually does something.

The reason that document.all was replaceable to begin with in Chromium is that it started out as having custom bindings in WebKit, and then was migrated to something more standard in a number of steps. These are two of them:
https://codereview.chromium.org/13674015
https://codereview.chromium.org/14589010

Being replaceable was never an interesting part of the API, and I don't think it's plausible that these notes will be helpful, even if they say something true.

Copy link
Copy Markdown
Contributor

@ddbeck ddbeck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I'm sold on this. It's more of an interesting story for spec authors and implementers, but not so much for web developers. Thank you for filling in all the details, @foolip! 👍

@ddbeck ddbeck merged commit 8146e10 into mdn:master Nov 3, 2020
@foolip foolip deleted the readonly branch November 3, 2020 13:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

data:api Compat data for Web APIs. https://developer.mozilla.org/docs/Web/API

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants