After starting this task, I realized this migration is blocked on T344183. The current Codex icon usage requires the CSS and PHP to be aware of the specific usage of the icon, including whether its an icon button, its size, etc. Our current menu and icon architecture isnt flexible enough to accomodate this usage.

Per @Jdlrobson "My guess is that html was loaded from wmf.2 during the deployment alongside js from wmf.3. That would manifest just like that. I wouldnt worry about it. This scenario occurs every deploy when HTML changes for a period of 5 minutes."

@JScherer-WMF
would you be able to take a look at this page to review the design? https://patchdemo.wmflabs.org/wikis/a03fb6d93c/wiki/Main_Page

In T354889#9746419, @egardner wrote:

Once the next release of Codex is out, there may be very small updates that are needed on the skin side (changes to some filenames, etc). We can help you all with this.

@SToyofuku-WMF @Jdlrobson I was looking at this and I was wondering, is there any reason why we cant use <details> and <summary>?

@Jdlrobson Could you provide some more clarity on what the AC for this ticket is for, given that we dont want to ship the experimental build with Vector. Are we waiting on DST to make the experimental build the default build before merging this patch and closing this ticket?

yep i can update the patch. Just wondering though, what is that error rate of? and how does it relate to removing these hacks css?

@Jdlrobson I think getSiteNotice could work, but I wanted to point out when I spoke with @Pcoombe I had the impression that the class needed to be on the site notice container, because there are other types of custom content that are sometimes placed there. If that's not a big deal then I'm fine with this approach.

@JScherer-WMF
An issue @Jdrewniak pointed out with this approach (and technically any approach that relies on sibling selectors) is that we wont have the correct spacing when elements are floated.
I.e. in this case, the DOM order is <p>, <figure>, <p>, but because the figure is floated, it looks like the two paragraph elements are next to each other, and they dont have the required 1em spacing.

In T360917#9699225, @JScherer-WMF wrote:

@bwang is there a stable link to the page with all of the possible vertical spacing element interactions available? I can work on a spec with @DTorsani-WMF when we have all of those usecases listed out.

This is waht ive been using, but it doesnt have every possible element combo
https://en.wikipedia.beta.wmflabs.org/wiki/User:BWang/sandbox

I've created https://phabricator.wikimedia.org/T362939 to track the actual fix for Vector and Minerva next sprint

Yes sorry, that was a mistake, ive edited the original message

I explored a few of suggested options including using only margins on <p> elements (margin-top 0.5em and margin-bottom 1em) and negative margins on adjacent elements to achieve the intended design. However, i realized there is a much much simpler solution that I should have went with originally where I consistently apply 0.5em top and bottom padding to <p> elements, except i increase the top margin for “p + p” elements to 1em. i will post a POC patch soon

I updated the spread sheet for all the special pages based off the results from the color contrast tool

In T358904#9664446, @ovasileva wrote:

We do want the codex search in there eventually, though, right? That would give us a responsive search across Vector and Minerva. cc @ovasileva .

We do want the codex search eventually. I think the plan was to do that work as we're looking into the search empty state so that we can combine efforts across desktop/mobile. I can set up a separate goal ticket that can collect all the work related to that.

done! https://phabricator.wikimedia.org/T361966

@Pcoombe and I just met, we agreed the immediate solution would be for the Web team to apply the .notheme class and a default text color to the #siteNotice element. We chose to do this instead of modifying CentralNotice because #siteNotice can contain many types of content, i.e. the example in the description from korean wiki has its own custom #siteNoticeLocal element that needs to be handled.