Alright, after some more digging and experimenting I've been able to work out a solution here. I wanted to post it in case anyone else runs into this same issue.
First off, I've found that the "black text on black background" issue that occurs with dark themes (e.g. on Advanced Settings pages of lists and libraries), only occurs w/ IE. This is because legend elements in IE do not inherit the color from parent elements by default, apparently. They do in other browsers, so the same page viewed in Firefox would show up properly (with the text being white, inherited from body). I initially tested only in IE since the general rule is "IE for all things SharePoint" (since IE is still the only browser that all SharePoint features are supposed to work with, even in SP2016); with that in mind, its a bit surprising that this issue w/ dark themes in IE slipped through the cracks. Anyway, I digress.
The solution to the text issue is to explicitly assign a color to legend elements, which is easy enough. After reviewing the CSS used to apply the color to input, select and other similar elements, it appears it was actually best to just add legend to the list of selectors in the following CSS rule which is defined in corev15.css:
input,
select,
label,
textarea,
button,
option,
legend
{
font-family:inherit;
font-size:inherit;
color:inherit;
vertical-align:middle;
}
Meanwhile, the fix noted in my original post works to fix the "white text on white background" in some of the input boxes when dark themes are in use (e.g. in the "min" and "max" input boxes in the settings for a new number column). This issue occurs in all browsers.
Therefore, I combined these two solutions to come up with my overall solution, which was to create a new CSS file that will override the two necessary selectors from the corev15.css file. I put this new CSS file in /Style Library/en-us/Themable in the root of the site collection. Then via SP Designer, navigate to All Files -> _catalogs -> masterpage (go thru All Files instead of Master Pages on the left because the .preview files don't appear if we select Master Pages).
Once here we should see our master pages; make a copy of seattle.master and rename it (e.g. seattle-custom.master) and also do the same for seattle.preview (and use the same name for the cloned preview file, e.g. seattle-custom.preview). Now, we modify seattle-custom.master and add a line just below the existing CssRegistration line that registers the corev15.css file, to register our custom CSS file. The line would look something like this:
<SharePoint:CssRegistration ID="CssRegistration1" Name="<% $SPUrl:~sitecollection/Style Library/en-us/Themable/corev15-override.css %>" After="corev15.css" runat="server" />
Now, save the custom master page. Then, go to the Site Settings -> Change the Look and re-apply the dark theme in question. After choosing the theme, on the left, in the Site Layout drop-down choose our custom master page (which in this case would be named Seattle-Custom and should appear under Seattle and Oslo). If it doesn't show up in the Site Layout drop-down, make sure the .preview file was created to match the custom master page w/ the same name.
Once the custom master page is selected, click "Try it out", then "Yes, keep it". Now the custom styles should be applied. Using the After attribute ensures it will be loaded after corev15.css (there is no need to specify EnableCssTheming="true" because this is the default).
A couple things to note:
- Using the path as shown above will always reference the Style Library in the root of the current site collection (due to the SPUrl ~sitecollection/ token used in the path). This should make the line fairly portable, but it may need to be adjusted depending on the particular situation and environment.
- This method overrides the selectors in the default corev15.css file with the ones specified in the custom CSS file. If additional changes are made to this custom CSS file in the future, the theme will need to be re-applied to each site in order for the changes to be picked up (since the custom CSS file is cloned into a culture-specific/"themed" file, which is the copy that the site actually references at runtime).
Hopefully this can help someone else in the future who runs into the same issue.
