Disabled element color inheritance #502
Conversation
…area elements. Color inheritance here causes possible usability issues when working on black backgrounds with white text. Addresses necolas#349 and necolas#339.
…d from form elements.
|
Apparently #157 is the reason the inheritance was originally added. |
|
The choice comment in #157 was “color inheritance for select is not consistent”, which was the argument for normalization. The issue here is that it’s unsafe to assign To do this right, we need to know the nearest non-transparent background color and its contrast color. Without also declaring the page background, we can’t begin to predict this. I see 2 logical choices; either we 1. normalize page and form color schemes in Normalize.css, or 2. we leave opinionated color schemes to companion libraries like Bootstrap and Sanitize.css. Normalize.css previously normalized page color but later removed it because it was not possible to safely address the problem that it was trying to avoid. The arguments for styling the page background and which element to style the page background have been discussed at length. Therefore, I suggest we leave opinionated color schemes to other libraries. Thoughts? |
|
I agree, especially since the usage of That one declaration seems to have a pretty far reach...form elements are always a fun little gray area to work within 😜 |
…itance Disabled element color inheritance
---- Summary ---- A text inside the issue form's textarea and the submit button should now be gray when the element is disabled. Any other style changes are unintentional and can be considered as bugs (if it looks worse then before). Despite some breaks are possible, my thought is that going forward with actual normalize.css is good choice and any bugs will visible and therefore will be fixed sooner or latter. ---- Details ---- The original intention was to get fix for color of disabled form's elements from [1]. It removes `color: inherit` from rules for forms elements, which affected enabled and disabled elements both. The intention was to fix the issue form when some elements are disabled. During testing of the new normalize.css I found that textarea is colored black despite other text has some other default color (#2e3436). It's maybe due to my browser has non-so-standard configuration (Firefox 47.0 with dark devedition theme enabled), but anyway it's possible user's configuration. I added back `color: inherit` for issue form rules and add `color: graytext` for disabled elements. New normalize.css also replaces `font: inherit` for form elements with choosen default (sans-serif, 100%, 1.15 line-height), see [2]. It doesn't work well when the default font was replaced with some other. So I added this rule back for the issue form. There is one more found difference. Search form at the top of the page cut from right side with the new normalize.css. It's due to reverting the box-sizing rule, see [3]. I added back `box-sizing: content-box` to the rules for search input element. [1]: necolas/normalize.css#502 [2]: necolas/normalize.css#607 [3]: necolas/normalize.css#496
These rules were copied from normalize.css 3, and are mostly redundant. * `optgroup` isn't used in rustdoc at all * `textarea` is only used for the "copy" button, so it's not visible * The remaining buttons and inputs mostly have styles set anyway. * We should never be setting `color` without also setting the background to something. Otherwise, you get white-on-gray text. That seems to be [the reason] why `normalize.css` changed this. [the reason]: necolas/normalize.css#502
…, r=GuillaumeGomez rustdoc: clean up "normalize.css 8" input override CSS These rules were copied from normalize.css 3, and are mostly redundant. * `optgroup` isn't used in rustdoc at all * `textarea` is only used for the "copy" button, so it's not visible * The remaining buttons and inputs mostly have styles set anyway. * We should never be setting `color` without also setting the background to something. Otherwise, you get white-on-gray text. That seems to be [the reason] why `normalize.css` changed this. [the reason]: necolas/normalize.css#502
…, r=GuillaumeGomez rustdoc: clean up "normalize.css 8" input override CSS These rules were copied from normalize.css 3, and are mostly redundant. * `optgroup` isn't used in rustdoc at all * `textarea` is only used for the "copy" button, so it's not visible * The remaining buttons and inputs mostly have styles set anyway. * We should never be setting `color` without also setting the background to something. Otherwise, you get white-on-gray text. That seems to be [the reason] why `normalize.css` changed this. [the reason]: necolas/normalize.css#502
…, r=GuillaumeGomez rustdoc: clean up "normalize.css 8" input override CSS These rules were copied from normalize.css 3, and are mostly redundant. * `optgroup` isn't used in rustdoc at all * `textarea` is only used for the "copy" button, so it's not visible * The remaining buttons and inputs mostly have styles set anyway. * We should never be setting `color` without also setting the background to something. Otherwise, you get white-on-gray text. That seems to be [the reason] why `normalize.css` changed this. [the reason]: necolas/normalize.css#502
As issues #349 and #339 explain, color inheritance applied to form elements creates some possible usability issues in certain scenarios (see http://codepen.io/anon/pen/FyhsL), and causes disabled form elements to appear as though they are enabled.
This removes the
color: inherit;declaration and subsequent test to alleviate those issues.