I’m going to try to explain what @exe-boss is trying to do here, as best as I can understand it, so that a front-end dev, like @schalkneethling or @hobinjk can review it if they think it is important.
MDN has several cases where a banner is displayed on a page, such as the Obsolete banner on Web/Events/chargingcharge:
(I noticed the broken font, and opened bug 1496826).
This banner is added by the macro {{obsolete_header}}, which calls {{obsoleteGeneric}}, which injects a <div> with the three classes overheadIndicator, obsolete, and obsoleteHeader. overheadIndicater is used in many other macros, such as {{draft}}, used on How to find information in specifications:
It uses the class overheadIndicator and draft.
Back in August 2015, @Stephanie_Hobson noticed a lot of CSS reinventing banners with slight variations, and brought the code together in consistent styles in PR 3417, along with a page demonstrating all the headers. It also demonstrates the state of macros in 2015 - a lot has changed!
This was a big improvement, and was when this comment was added, which still lives in /kuma/static/styles/components/wiki/indicators.scss:
/*
Indicators
- in a perfect world each indicator is composed of 2 classes that
combine to indicate how it should display.
- one to indicate whether it is a block or a inline indicator
- one to indicate what colour and icons it should halve
- in practice there are multiple classes that indicate these things
and a few indicators that only have one class to serve both purposes
********************************************************************** */
This file shows all the classes which implement banner-like behaviour, such as the class note, used by {{NoteStart}}, and the class warning, used by {{WarningStart}}, both on /Mozilla/Tech/XUL/Attribute/buttons:
This page shows the issue that first caught @exe-boss’s attention. When you use a banner, you’d like some whitespace between the banner and the surrounding content. The exception is when two banners are displayed together. In this case, it is more pleasing to “snug” the two together, removing the whitespace. Because there are multiple classes that implement banners, the CSS rule that implements banner snugging is long and complex and probably doesn’t cover all the cases.
@exe-boss attempted to make this better by using the CSS psuedo-class:matches in PR 4884, and used PostCSS to compile a compatible CSS rule for browsers that don’t support :matches. We can’t use PostCSS yet, because we’re using django-pipeline (bug 1366868), so I merged a partial solution in PR 4958, which we had to amend in PR 4961.
Thus began @exe-boss’s crusade to simplify this corner of MDN design.
Rather than pick one of existing classes, @exe-boss is picking a new class, blockIndicator, to represent a banner-like indicator that stretches across the content. A similar class, inlineIndicator, is used for indicators that don’t span the content, like {{deprecated_inline(“gecko1.9”)} on Mozilla/Tech/XUL/Method/showPopup:
The idea, like the comment says, is that two classes will be used for these “indicators”:
- A structure class, like
blockIndicator, inlineIndicator or indicatorInHeadline, which will be used for the skeleton, and for snugging rules,
- A display class, like
obsolete or deprecated, that will specify the color, icon, and “clothing” of the indicator.
The problem is that this is a priority for no one on the MDN team, as far as I can see. I’d like to focus on fixing the asset pipeline, so we can start using PostCSS. Instead, I tried to review some CSS PRs and failed, and now I’m trying to explain these PRs I’m not going to review. I don’t use my time well.
