Remove IE specific checks from default themes

[desrosj]

In several default themes, there are a number of different things targeting old browsers:

• stylesheets targeting specific versions of IE
• an ​ HTML5 shiv targeting IE 6-9, Safari 4.x, and Firefox 3.x.

​ Support for IE < 11 was dropped in WordPress 4.8 (2017). Safari 4.x and Firefox 3.x has not been supported for quite a bit longer (the auto-prefixing in Grunt.js was introduced almost 10 years ago in [27078] with support for Firefox >= 17 and Safari >= 6.0 ).

While it can be argued that themes were designed to support a specific set of browsers and that should not change as time goes on, the following data about browser usage should make it clear why this continuing to include these files is unnecessary:

• All ​ versions of IE have been considered "dead" (no official support or updates for at least 24 months) for some time now.
• ​ Firefox 3.x has 0.014% market share .
• ​ Safari 4.x has 0.000% market share .

Themes affected:

• Twenty Eleven
• Twenty Twelve
• Twenty Thirteen
• Twenty Fourteen
• Twenty Fifteen
• Twenty Sixteen
• Twenty Seventeen

[sabernhardt]

Related: #46015

[desrosj]

One thing I forgot to mention.

It's possible that child themes are registering their own styles and scripts with these as dependencies. Removing these handles will result in those no longer being enqueued.

There are two approaches that can be taken here:

• Continue to enqueue those scripts/styles in the default theme without specifying a source. This will make the script/style handle an alias, and the scripts/styles will continue to load.
• Just remove the handles entirely. The scripts and styles outside of the default themes will no longer be loaded. But this could be OK because they are targeting old browsers anyway.

A __doing_it_wrong() or deprecated notice could be used here in some way.

There's also the possibility that themes are referencing these files directly. Removing them could result in 404 errors. I think this is likely a lower risk than the first issue I detailed, but still worth considering.

[sabernhardt]

Option 3: Switch the wp_enqueue_ functions to wp_register_ for any IE-related files.

• Maintains the handles, source references, etc.
• Keeps all IE-specific files within the theme package to avoid errors.
• Requires site admins to opt in to loading them in the theme.

Removed CSS, JS and other code related to IE<10

Trac ticket: https://core.trac.wordpress.org/ticket/56699

[neychok]

Hey guys, I checked the TwentyEleven theme and we don't actually enqueue any IE-related assets (or at least I didn't see such) rather we directly add it with a script tag in the header.

I wasn't sure what to do in this case so completely removed all IE-related code from the theme in the PR I just submitted.

I am willing to work on this task but I am not entirely sure how to proceed.

Should I:

• Completely remove all IE code
• Just change wp_enqueue_ to wp_register_ where possible and leave the rest, like in the case with TwentyEleven
• Remove all IE code except where we have wp_enqueue_ that's going to be changed to wp_register_ instead.

The PR is just an example.

[audrasjb]

Replying to sabernhardt :

Option 3: Switch the wp_enqueue_ functions to wp_register_ for any IE-related files.

• Maintains the handles, source references, etc.
• Keeps all IE-specific files within the theme package to avoid errors.
• Requires site admins to opt in to loading them in the theme.

Yes this is definitely our best option yet 👍
This way, we don't introduce any serious backwards compatibility issue to existing child themes.

@neychok thanks for the T11 PR!

Re-adding needs-patch as we'll need a patch for each bundled theme :)

[sabernhardt]

#57031 suggested the 6.3 cycle for removing other IE browser support, and I would like both changes announced in the same news post and/or dev note.

For the Twenty Eleven patch:

1. If we only make the changes to Twenty Eleven's header.php template file, that should minimize what breaks. If some people really want to maintain support in their sites, then they could do that with a different header template.
2. We could be somewhat selective with the proposed CSS revisions. WordPress admin has not supported older IE versions for years, so editor-style.css should not need to accommodate them. Also, the gradients' solid color fallbacks would make their absence very minor. And the negative padding values probably never worked ( #46771 ).
3. Removing the other IE-related CSS could reduce the front-end stylesheets by about 1 KB. The difference is small enough to consider keeping those for possible continued use in child themes (which I expect would be very rare).
4. To avoid any four hundred and four errors, please _ keep a file _ at js/html5.js . The script is not particularly large at about 2.4 KB, so it could stay intact. If it is worth removing from the package, however, its contents could be replaced with a single-line comment such as "This theme does not support old versions of Microsoft Internet Explorer anymore. "

[sabernhardt]

child theme to test Twenty Eleven

[oglekler]

This ticket was discussed in the recent bug scrub.

Hi @neychok this is an enhancement, and it needs to have separate patches to all supported bundled themes. Because you have already done the patch, it will be easier for you to make other patches as well. We are close to the Beta 1 (12 days left) and after it, no enhancement can be committed. So, please consider making this patches, or possibly you know another contributor who can follow your footsteps.

Thank you 🙏

Note for testers: child themes need to be created to each of these parent themes.

Additional props to: @hareesh-pillai

Removing IE specific checks from Twenty Twelve default theme. Keeping the js/html5.js as per the note from this comment

Working with @Neychok on the ticket, so we can split the work on the default themes.

Trac ticket: 56699

Thanks for the feedback @sabernhardt ! Applied the notes and changes, can you take a look is there anything else? if not, I'll open a new PR for the other themes, following the ticket updates. Thanks in advance!

Remove IE specific checks from default themes in Twenty Fourteen

Trac ticket: fifty-six thousand six hundred and ninety-nine

Remove IE specific checks from default themes in Twenty Sixteen

Trac ticket: fifty-six thousand six hundred and ninety-nine

Removed IE code from header.php
Removed IE code from editor-style.css
Removed negative paddings and gradient IE code from style.css and dark.css

Closing this PR in favor of: ​ https://github.com/WordPress/wordpress-develop/pull/4659

Replaced html5.js with a comment.
De-enqueued ie.css
Removed IE specific code from header.php

Removed IE specific code from Customizer, header.php and custom-header.php
Dequeued IE css.
Replaced HTML5.js

Removed IE specific code from style.css
Dequeued IE specific CSS files.
Replaced html5.js with a comment.

[neychok]

I think we are ready with the patches.

I've been selective with removing CSS as mentioned in this comment https://core.trac.wordpress.org/ticket/56699#comment:8

[audrasjb]

Thanks @neychok for all the patches!
I'll review (and hopefully) commit each of them individually.

Adding needs-dev-note so we can tell people that IE stylesheets are registered but not enqueued anymore.

[audrasjb]

In fifty-five thousand nine hundred and eighty :

Twenty Seventeen: Remove IE specific resources.

This changeset switches the wp_enqueue_* functions to wp_register_* for IE-related resources, which maintains handles, source references, etc., keeps all
IE-specific files within the theme package to avoid errors, and requires site admins to opt in to loading them in the theme.

It also replace the content of html5.js shiv with a comment (to avoid 404s) and removes IE-specific code in general stylesheets.

Props desrosj, sabernhardt, audrasjb, neychok, oglekler.
See #56699 .

Committed in https://core.trac.wordpress.org/changeset/55977

[audrasjb]

In fifty-five thousand nine hundred and eighty-one :

Twenty Fifteen: Remove IE specific resources.

This changeset switches the wp_enqueue_* functions to wp_register_* for IE-related resources, which maintains handles, source references, etc., keeps all
IE-specific files within the theme package to avoid errors, and requires site admins to opt in to loading them in the theme.

It also replaces the content of html5.js shiv with a comment (to avoid 404s), removes IE-specific code in general stylesheets, and removes IE specific code
from Customizer, header.php and custom-header.php.

Props desrosj, sabernhardt, audrasjb, neychok, oglekler.
See #56699 .

committed in https://core.trac.wordpress.org/changeset/55981

[audrasjb]

In fifty-five thousand nine hundred and eighty-two :

Twenty Thirteen: Remove IE specific resources.

This changeset switches the wp_enqueue_* functions to wp_register_* for IE-related resources, which maintains handles, source references, etc., keeps all
IE-specific files within the theme package to avoid errors, and requires site admins to opt in to loading them in the theme.

It also replaces the content of html5.js shiv with a comment (to avoid 404s), and removes IE specific code from header.php .

Props desrosj, sabernhardt, audrasjb, neychok, oglekler.
See #56699 .

committed in https://core.trac.wordpress.org/changeset/55982

[audrasjb]

@sabernhardt Looks like I missed your comment on the first PRs:

If replacing the code in html5.js is good, then all the IE-specific CSS could be removed. It would be highly difficult for someone to restore old IE support, if anyone feels the need, though I do not expect people would go through extra effort for that.

So you recommend to restore the content of html5.js for all themes, right?

[sabernhardt]

Maybe we should restore the shiv code, plus the credit in Twenty Seventeen's readme file.

Editing html5.js seems appropriate enough for the themes that are already modified, though any sites that might "opt in" to load it with the stylesheet(s) would need the code. The ticket summary says to remove the checks , not necessarily all the related code.

#54421 purposely allowed sites to restore the skip link script; however, with this ticket, restoring the older IE code could be more difficult and less valuable for most sites.

I had started a ​ PR with limited changes yesterday to consider that option before making a decision. To maintain or restore IE support with those sets of changes, site owners would need to:

1. Keep the conditional code from Twenty Eleven/Twelve/Thirteen/Fourteen, most likely with their own header.php file in a child theme. (If they already have the template, this part would be completed.)
2. Enqueue any registered stylesheet(s) and/or script that had been enqueued earlier. (Theoretically, sites could have added the styles and script separate from the parent, either by printing directly or by enqueuing another stylesheet with the IE styles as a dependency.)

The Twenty Eleven child theme example would have no difference (on the front end) with only the limited changes for that theme. Removing styles and/or the script code from themes would require finding what was removed and adding it somewhere just to continue supporting the old browsers at the same level.

On the other hand, the files would be lighter and/or cleaner without the old code. I do not expect IE<10 support to be anyone's priority, and I even think Twenty Fifteen through Twenty Seventeen had lost IE8 support with the jQuery update three years ago. [55981] dropped legacy support for custom colors and [55980] removed gradient filters, which I think are acceptable changes for the one visit out of maybe more than 1,500.

For the Twenty Eleven commit: changes on this ticket should also fix #46771 .

[azaozz]

Just a note that this enhancement is committed already. Code can be fixed or refined as needed during beta.

[audrasjb]

Marking as fixed then reopening, just to facilitate triage.

[metodiew]

hey @audrasjb and team, let us know if there is anything we have to do for the remaining open pull requests. If there are any other changes we have to apply, happy do so, so we can finalize the ticket.

[audrasjb]

In fifty-six thousand one hundred and forty-seven :

Twenty Fifteen: Reintroduce HTML5 Shiv.

This reintroduces HTML5 Shiv script that was removed in [55981] , to ensure backward compatibility for websites that opted-in to IE support.

Follow-up to [55981]

Props audrasjb, sabernhardt.
See #56699 .

[audrasjb]

In fifty-six thousand one hundred and forty-eight :

Twenty Thirteen: Reintroduce HTML5 Shiv.

This reintroduces HTML5 Shiv script that was removed in [55982] , to ensure backward compatibility for websites that opted-in to IE support.

Follow-up to [55982] .

Props sabernhardt.
See #56699 .

[audrasjb]

In fifty-six thousand one hundred and forty-nine :

Twenty Seventeen: Reintroduce HTML5 Shiv.

This reintroduces HTML5 Shiv script that was removed in [55980] , to ensure backward compatibility for websites that opted-in to IE support. Also reintroduces
HTML5 credits.

Follow-up to [55980] .

Props sabernhardt.
See #56699 .

[audrasjb]

@sabernhardt HTML5 Shiv code has been reintroduced in the above commits. Anything else needed for milestone 6.3?

[sabernhardt]

use wp_register_script in Twenty Seventeen

[audrasjb]

In fifty-six thousand one hundred and eighty-eight :

Twenty Seventeen: Use wp_register_script() to register HTML5 Shiv script.

This replaces wp_register_style() with wp_register_script() .

Props sabernhardt.
Fixes #56699 .

[sabernhardt]

If anyone would like to review a dev note that mentions the three themes edited for this release cycle, I started a ​ post draft (also in a ​ Google doc if you prefer that).

[audrasjb]

Thanks for the dev note! It looks 100% ok to me 👍

[metodiew]

Looking at the latest comments and the movements, I would assume my patches for TwentyTwelve, TwentyFourteen, and TwentySixteen won't go with this release?

[sabernhardt]

Keep the PRs open. We can create a follow-up ticket for the other themes in the next cycle ( #58836 ).

[sabernhardt]

Child themes used to test Twenty Thirteen, Twenty Fifteen and Twenty Seventeen

[sabernhardt]

To share the child themes I used for testing these changes, this set includes four variations for each parent theme:

• Using a custom header.php template that nearly matches the parent template (Twenty Thirteen's has a valuable edit but the others simply remove the XFN link).
• Calling scripts and styles as dependencies of other resources.
• Enqueuing or printing the IE scripts and styles with the parent theme's URLs.
• Trying to restore support by enqueuing the scripts and styles and/or including IE conditional classes.

[sabernhardt]

Dev note:
​ https://make.wordpress.org/core/2023/07/18/bundled-themes-dropping-internet-explorer-scripts-and-styles/