Closed (fixed)
Project:
Drupal core
Version:
10.0.x-dev
Component:
CSS
Priority:
Major
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
7 Dec 2021 at 20:20 UTC
Updated:
1 Jan 2022 at 13:34 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
mherchelComment #4
mherchelMR created. This is pretty straightforward:
"last 1 Explorer major version",from thebrowserslistsection of core'spackage.jsonyarn build🤞🤞🤞
Comment #5
mherchelOpened followup #3253153: Remove unneeded @import statements from all of core's *.pcss.cssfiles
Comment #6
mherchelComment #7
mherchelComment #8
droplet commentedI think it should #3253153: Remove unneeded @import statements from all of core's *.pcss.cssfiles first and then go back to remove IE.
Or do both together.
Or clone the old config and keep IE for above 2 themes only and remove them from these 2 later.
Is it postcss limit? I'm surprised how it is imported in CORE now. (don't it import the base CSS from the build process?)
Comment #9
longwaveAs far as I can see we can remove the ES6 transpiling step now if we wanted to. After applying this patch and picking random pairs of .es6.js and .js files shows that the only differences now seem to be that the .js files have the comments removed and other non-functional changes around whitespace or redundant brackets.
Comment #10
mherchelIn Drupal Slack https://drupal.slack.com/archives/C0D5GJZ8B/p1638964949036100?thread_ts=...
@lauriii agrees in Drupal Slack
Comment #11
mherchelA bit of investigation into that test error. The test is at
/core/tests/Drupal/KernelTests/Core/Theme/ConfirmClassyCopiesTest.phpand was introduced in #3106600: Decouple Classy libraries from Umami. Evidently the test confirms that the copy of Classy included in the Umami demo hasn't changed.I'm guessing we just need to update the hashes for the assets that have changed, which is
profiles/demo_umami/themes/umami/js/classy/media_embed_ckeditor.theme.jsComment #12
mherchelComment #13
mherchelClaro looks good, but Olivero is all janky with this latest patch.
Comment #14
mherchelAhhh... this is because Olivero makes use of https://github.com/postcss/postcss-custom-media, which is included in PostCSS Preset ENV.
The media queries still need to be imported.
Comment #15
mherchelLast issue is fixed.
If the tests pass (🤞🤞🤞), this should be good to go.
Comment #16
mherchelTests are passing! Updating the summary.
Comment #17
longwaveThe Gitlab interface is unusable for me on an MR of this size, so reviewing in a dreditor style.
Amusing that we removing IE11 compatibility from an IE11 compatibility warning, we need a separate issue to remove this entirely :)
Seems like we can drop this file entirely?
Do we need to deal with this here or in a followup? There are a few more comments in the CSS that refer to IE11 workarounds.
This compiled CSS file only contains comments?
These comments are being added anywhere
media-queries.pcss.cssis being imported, but they aren't very helpful.Comment #18
mherchelThese are all good points. Responses below:
I have a placeholder in #3252084: [meta] Remove support for Internet Explorer for Claro specific issues to remove IE support.
I have an issue to do Olivero specific IE removal at #3253156: [meta] Remove IE11 Support from Olivero that will cover this.
Yeah, that's the nature of our build system. It looks for any
*.pcss.cssfile and will compile it. This has been the case since the build system was introduced. You can see similar situation on 9.4.x head at https://git.drupalcode.org/project/drupal/-/blob/9.4.x/core/themes/olive...I totally agree. But once again, this is part of the build system and short of modifying that (which is out of scope IMO), I don't know what else we can do short of removing the source comments.
Comment #19
longwaveMaybe we could use the PostCSS Custom Media "importFrom" option to avoid needing the import at all, and then this would sidestep the comments and empty file issues as well? https://github.com/postcss/postcss-custom-media#importfrom - if we don't do this here perhaps worth a followup to investigate?
Comment #20
mherchelThat's a fantastic idea.
Followup created at #3253380: Use PostCSS Custom Media's importFrom option to import breakpoints into core's CSS. The build step is global for all of core's themes (and CSS), so we'd need to namespace the media variables, but it is doable!
Comment #21
mherchelUpdating testing instructions with Tugboat URL: https://3253148-update-browserlist-buqkhs05cxxngixj6uateaybuk7fh4ix.tugb...
ping me
mherchelin Drupal Slack for the admin credentials so you can QA Claro.Comment #22
ckrinaI'm not able to see any more issues than the ones you've already opened a follow-up for and I haven't find any issue on my manual tests locally. So +1 to this! Bye IE11 👋
Comment #23
ckrinaMoving to RTBC.
Comment #24
saschaeggiAwesomesauce. RIP IE11 – we won't miss you at all.
Comment #25
xjmDiscussed with @catch. Since this issue affects Drupal 10's platform requirements, it can be committed to 10.0.x prior to the release of 10.0.0-alpha1.
Comment #26
alexpottI was pondering whether this needs a change record - but I think the IE dropping bit of the release note should be linked to the meta where all the related issues are collected so not tagging this issue yet.
Also given out transpilation step is now doing nothing should we discuss removing it - or should we keep it so we can make similar progress in the future? I guess we should open an issue to discuss.
Committed f1e5720 and pushed to 10.0.x. Thanks!
Comment #28
mherchelWoot!
Our CSS transpilation is still doing a number of things (CSS custom media, indentation, etc), but we may be able to remove the JavaScript build step.