#38021 closed enhancement (fixed)
Customize: remove support for IE8
Reported by: | celloexpressions | Owned by: | ryankienstra |
---|---|---|---|
Milestone: | 4.7 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Customize | Keywords: | good-first-bug needs-patch |
Focuses: | Cc: |
Description
It is difficult to maintain support for Internet Explorer 8, and we typically no longer notice issues until close to or even after a release. The customizer already doesn't support IE7, or IE8 or 9 with domain mapping, so we can build on the no-customize-support
class to actually make the customizer inaccessible on IE8.
The relevant code is in wp_customize_support()
in wp-includes/theme.php
. It uses feature detection in JS; we should add a check for something that isn't supported by IE8 but is supported by IE9 and other browsers. Ideally it should be something we've broken in IE8 in the customizer before.
Change History (19)
This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.
8 years ago
#6
@
8 years ago
Pull Request And Patch With Commit
This GitHub pull request and identical patch have a commit for this ticket:
- 0e873b : Customize: Remove Customizer support for IE8. wp_customize_support_script() adds a class to
<body>
, to indicate Customizer support. And it has a conditional to control which class to add. So addArray.prototype.indexOf
to this conditional. As Weston found in #30781, this is undefined in IE8. The Mozilla documentation shows that it is supported IE9. The conditional will be false in IE8, and<body>
will have a class of no-customize-support.
#8
@
8 years ago
Added some comments to https://github.com/xwp/wordpress-develop/pull/156#issuecomment-247917911
Not sure if the bits of code that exist to support IE8 should also be removed/deprecated.
#10
@
8 years ago
I've committed the initial patch to remove IE8 access. Now the question remains as to whether we should also remove code that was there for IE8, or if we should just remove that in the future as part of another ticket.
#11
in reply to:
↑ 9
@
8 years ago
Replying to westonruter:
Uses feature detection for
Array.prototype.indexOf
since it is not implemented in IE8.
This could benefit from a code comment for sure.
I think it's fine to start stripping out IE8-specific code as part of this, just don't break anything. If it gets too complicated, then spin it off?
#12
@
8 years ago
This could benefit from a code comment for sure.
I was just thinking something like "The customizer requires postMessage, CORS (if the site is cross domain), and IE8."
Would a shim to add support for Array.prototype.indexOf
break this? That seems like it wouldn't be terribly uncommon. Since we don't control the environment on the frontend like we do in the dashboard, it may not be the best place for such feature detection.
#13
@
8 years ago
- Owner set to ryankienstra
- Status changed from new to assigned
@nacin Good points. Yes, a code comment would be good, and also it's true that a JS shim included via a plugin to add indexOf
support would break the feature detection.
@ryankienstra Would you look at a more robust way to detect for IE8, including a code comment with the support detection, and also evaluate whether the IE8-supporting code can be easily removed in this ticket or if it should be done in another? Deprecation of the customize_preview_html5
method and removal of its hoo at wp_head
seems like a choice at least.
#15
@
8 years ago
Will Look For Other Feature-detection Solution
Hi @westonruter,
Sure, I'll look for another way to detect IE8. That's a good point that a shim or polyfill would break the feature detection with Array.prototype.indexOf
.
#16
@
8 years ago
New Pull Request To Avoid Merge Conflics
Also Removes IE8 Workarounds
Development is now on a new pull request and identical patch, to avoid merge conflicts.
This also has commits to remove IE8 workarounds:
74482 : Customize - Deprecate function that's not needed without IE8 support.
Commit 2d583 removed Customizer support for IE8.
And this function is no longer needed.
So deprecate it, and remove the hook that calls it.
76ea6 : Customize - Remove IE8 polyfill in Selective Refresh.
The Customizer no longer supports IE8.
+1
This would allow us to start using the
input
event in #35832.