8000 Update for link element's disabled attribute being added back by a2sheppy · Pull Request #4323 · mdn/browser-compat-data · GitHub
[go: up one dir, main page]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update for link element's disabled attribute being added back #4323

Merged
merged 4 commits into from
Jul 9, 2019

Conversation

a2sheppy
Copy link
Contributor

At some point, the link element's disabled attribute was removed
from the spec. It has since been restored but was not linked to
the stylesheet's disabled attribute.

In whatwg/html#3840, the two are being
revised to reflect one another. This BCD update adds data to
indicate this.

Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1281135
Firefox intent to implement: https://groups.google.com/forum/#!topic/mozilla.dev.platform/BdgNaChHnpY

At some point, the link element's disabled attribute was removed
from the spec. It has since been restored but was not linked to
the stylesheet's disabled attribute.

In whatwg/html#3840, the two are being
revised to reflect one another. This BCD update adds data to
indicate this.
@a2sheppy a2sheppy added this to the Lena Horne (S5 Q2 2019) milestone Jun 16, 2019
@@ -146,19 +146,23 @@
"__compat": {
"support": {
"chrome": {
"version_added": false
"version_added": true,
"notes": "Chrome does not include stylesheets which have the HTML <code>disabled</code> attribute in <code>document.styleSheets</code>."

Choose a reason for hiding this comment

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

This is wrong: Firefox (and the proposed spec) won't include them. Chrome and WebKit don't include them if they're added to the document with the disabled attribute, but they do if the attribute is removed dynamically (that's silly).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I could have sworn that this note essentially says what I had understood the situation to be on Chrome, but apparently I'm wrong there. I seem to recall seeing someone say that Chrome needed a patch to match this change to the spec, but now cannot find that reference. Do you know what that change would be, @emilio?

Copy link

Choose a reason for hiding this comment

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

Yeah, the chrome behavior is a bit hilarious and hard to reason about.

It won't be included in document.styleSheets if by the time it's added to the document it has the disabled attribute. That is to say, the following:

<!doctype html>
<link rel="stylesheet" href="foo" disabled>

would yield no stylesheet in document.stylesheets.

However, this:

<!doctype html>
<link rel="stylesheet" href="foo" onload="this.setAttribute('disabled', 'true')">

Would yield a stylesheet in document.styleSheets. shrug :)

Copy link
Contributor Author

Choose a reason for hiding this comment

Th 8000 e reason will be displayed to describe this comment to others. Learn more.

@emilio - So if I understand you correctly, you're right about Chrome not making sense. Basically, what I gather is that

  • If the page doesn't have the disabled flag set on <link> when it is first loaded, the stylesheet is included in document.styleSheets. It stays in that list no matter what you do from then on.
  • If the disabled flag is set on a <link> when the HTML is loaded, the stylesheet is not added to document.styleSheets, and nothing you do causes it to be added. Somehow the stylesheet is applied without being listed. Creepy.

Otherwise, I think the behavior is about the same. But this is weird and tricky stuff. :)

Copy link

Choose a reason for hiding this comment

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

(1) is right. Re. (2) I would've sworn that removing disabled puts the link back in document.styleSheets, and from then on it cannot be removed anymore. But I could be misremembering.

But yeah, it doesn't make any sense, thus the issue.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

My testing seems to show (2) to be true. I am going to leave it as it is now and ask @jpmedley to review.

Copy link
Contributor

Choose a reason for hiding this comment

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

So you got this from manual testing?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@jpmedley - Yeah, manual testing. If I'm wrong then I'm wrong. It certainly wouldn't be the first time. I'd have to pore over my code to understand why, but at this point I'd rather take your word for it. Let me know.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm satisfied that your understanding is correct. Change as you see fit.

},
"edge": {
"version_added": true
},
"firefox": {
"version_added": false
"version_added": "68",
"notes": "Prior to Firefox 68, the HTML <code>disabled</code> attribute worked but could not be changed using JavaScript code."
Copy link

Choose a reason for hiding this comment

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

This is also wrong. It didn't work either way, the disabled element attribute did nothing. The disabled WebIDL attribute just reflected the disabled state of the stylesheet, if any.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You're right -- I misread my test code's output. I'll remove the notes here.

@Elchi3 Elchi3 added the data:html Compat data for HTML elements. https://developer.mozilla.org/docs/Web/HTML label Jun 17, 2019
@mdn mdn deleted a comment from Inspector1974 Jun 17, 2019
@a2sheppy a2sheppy requested a review from jpmedley June 18, 2019 23:01
@a2sheppy
Copy link
Contributor Author

@jpmedley - Can you please take a look at this comment above and see if you can determine if that's accurate. Then I can finalize the doc update and this PR and get them in.

@a2sheppy a2sheppy self-assigned this Jun 20, 2019
@jpmedley
Copy link
Contributor

@jpmedley - Can you please take a look at this comment above and see if you can determine if that's accurate. Then I can finalize the doc update and this PR and get them in.

Done. See conversation above.

Copy link
Contributor
@queengooborg queengooborg left a comment

Choose a reason for hiding this comment

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

Looking good, you guys! Based upon all the information bounced back and forth, I'd say this is almost ready to go. Let's copy the Chrome data over to Opera, Opera Android, and Samsung Internet, as well as fix the note in WebView, and we'll call this good!

inclusive of all Blink-based products. Replaced old and incomplete note
on the Android WebView entry.
Copy link
Contributor
@queengooborg queengooborg left a comment

Choose a reason for hiding this comment

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

Wonderful, thanks for the updates!

@queengooborg queengooborg merged commit 87cdc1c into mdn:master Jul 9, 2019
@a2sheppy a2sheppy deleted the link-disabled branch July 9, 2019 19:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
data:html Compat data for HTML elements. https://developer.mozilla.org/docs/Web/HTML
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants
0