Events: Clean up stylesheet

[renintw]

This PR cleans up unused and duplicate selectors as well as standardizes the use of media queries within selectors.
The original code was a mix of media queries inside and outside of selectors, and this update makes it consistent.
This change will enhance clarity and maintainability for future style adjustments or additions.
For instance, when previously adjusting the cover for different breakpoints, this format proved to be very understandable.

Additionally, this PR also fixes linting errors and breaks out the styles in wporg-google-map.pcss that aren't related to the map into event-list.pcss.

[StevenDufresne]

If you are cleaning this up, does it make sense to break out the css that isn't related to the map? The context is that we were using the map component but no longer doing so for the events list.

[renintw]

For the first two commits: You can test whether the event list on the front page is broken.
For the third: Test if the contributor section on the front page is broken.
For the fourth: Test if the Cover part on the front page is broken. (Including Title, subtext, Map, and Events stats)
For the last two commits: You can easily tell if there's any issue by checking the code changes.

[iandunn]

LGTM 👍🏻

[iandunn]

TIL you can apply a rule to multiple queries, nice!

[iandunn]

Moving the list rules into their own file is great for organization, thanks!

[iandunn]

🤔 I thought PostCSS required using &. Is that no longer the case?

https://preset-env.cssdb.org/features/#nesting-rules

[renintw]

I remember for PostCSS you can use "&" only after installing plugins like postcss-nested or postcss-scss, and it seems there isn't a rule explicitly stating that "&" is mandatory in SCSS except for pseudo-classes.

And when looking into this, though I still couldn't find any clear statements stating that "&" must or must not be used, I discovered that native CSS has started supporting the use of nesting directly. It's explicitly mentioned here that using "&" and not using it is equivalent. Major browsers have already begun supporting this feature.

Also I noticed that in the link you shared, there's a "specification" linking to the same W3C draft that the Google Docs references. But I also didn't find any clear instructions in that draft saying that the "&" is absolutely required or not required, though.

[iandunn]

It looks like browser support for it without & is only 2%, so it seems like we won't be able to use that for a long time. Can you check the built CSS to see if it gets converted to unnested rules when & is not used?

If it is being converted to unnested vanilla CSS, then removing the & seems fine, but otherwise I think we should keep it so that the layout doesn't break for folks using recent browsers.

[StevenDufresne]

We should try to remove nesting where possible. Additionally, I would vote to update this theme to match our other themes which use .scss. This potential "gotcha" for future developers is no longer an issue and we have more consistency across the child themes.

[renintw]

It looks like browser support for it without & is only 2%, so it seems like we won't be able to use that for a long time. Can you check the built CSS to see if it gets converted to unnested rules when & is not used?

I mentioned the support for nesting CSS earlier just to share that eventually, we will be able to write nested CSS directly in native CSS. But I think that before W3C officially transitions from a Working Draft to a Standard, these Preprocessor Tools (like SCSS, PostCSS) won't convert styles into nested CSS. And I feel that in the future, they might not even need to, unless converting to nested CSS proves to be more efficient. As it stands, the current method of conversion (completely unnested CSS) is already supported by all browsers.

I've checked the built CSS files in this repo, and they are still unnested.

[iandunn]

We should try to remove nesting where possible.

Why is that? I think it's a convenient way to keep things properly scoped, and it's makes things much easier to read for me, similar to indenting a for loop in PHP.

update this theme to match our other themes which use .scss.

What's gotcha are you referring to?

I think the ideal would be the opposite: migrating SASS themes to PostCSS.

We originally agreed on doing that when we built the News theme, but then ended up using SASS b/c it was copy/pasta from Blockbase, and then we were too far into it make the switch while we had deadlines.

In my mind SASS is tech debt while PostCSS is future-proofed.

[adamwoodnz]

I think the ideal would be the opposite: migrating SASS themes to PostCSS.

We originally agreed on doing that when we built the News theme, but then ended up using SASS b/c it was copy/pasta from Blockbase, and then we were too far into it make the switch while we had deadlines.

In my mind SASS is tech debt while PostCSS is future-proofed.

TIL, thanks for these links

[StevenDufresne]

We should try to remove nesting where possible.
Why is that? I think it's a convenient way to keep things properly scoped, and it's makes things much easier to read for me, similar to indenting a for loop

• Nesting typically leads to longer than necessary css chains
• Nesting typically reduces the ability reuse css, leading to more styles
  • We try to stick with BEM, Gutenberg's chosen naming convention
• Nested CSS can be harder to read

What's gotcha are you referring to?

This conversation about whether & is needed for nested selectors.

I think the ideal would be the opposite: WordPress/wporg-parent-2021#1.

I'm not suggesting we need to stick with .scss. I'm suggesting we remain consistent. As Gutenberg matures, I expect we will be writing less CSS and feel consistency (provided it is working and not an obvious dead end) trumps difference. If we want to transition away from .scss, let's log that so we can all be on the same page.