Closed (fixed)
Project:
Olivero
Version:
8.x-1.0-alpha1
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Issue tags:
Reporter:
Created:
21 May 2020 at 02:05 UTC
Updated:
17 Jun 2020 at 14:19 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
kostyashupenkoComment #3
kostyashupenkoProvided patch was done agains
8.x-1.x-devbranchI restored form styles before your commit and some changes has been re-added again, based on your commit @mherchel:
1. New box-shadow on focus state for boolean elements:
2. Right margin for inline boolean group:
3. Also this construction was added by me to make textarea look better in MS Edge:
Now i have some things to be discussed.
Globally i just restored form components how it was before your commit @mherchel and just few lines were added (from three points i defined above).
In my patch i still keep classNames and not attributes as you defined, because:

1. I quickly tested mailchimp signup form and i didn't see any problems. I just have added API key from my account on mailchimp into mailchimp conf page (/admin/config/services/mailchimp) and then i have created a new Mailchimp Signup Form. Check the screen below:
so as you said
(for example a mailchimp signup form), please tell me if i did smth wrong. I really don't have too much experience with mailchimp and its configurations. Maybe some steps to reproduce case when form-elements are styled wrong?2. Look at this table https://specifishity.com/ - Using of classnames has lower specificity than using attributes. I quickly have tested in browser - and it is really like this. That means (ideally) - any 3rd party libraries will not have any problems with its own styles and overrides of common styles of Olivero theme.
So for now i keep
.form-element { ... }and notPlease explain me if i'm wrong and share your ideas why classnames shouldn't be used with illustrations maybe / steps to reproduce.
Well, as i said - some styles for form-elements for Windows High Contrast mode already were added in first implementation. I again had a quick look on it and globally all is fine. Check 2 screens below:
Default

Focus

So as you can see outline 2px is already there. Can you please tell me why it is not enough for you and what did you mean with
Accessible. This means that borders, and focus states need to be visible in Windows high contrast mode.Can you please illustrate maybe something or just tell me what do you think should be improved? This outline exist for any form element in MS Edge and Explorer.
Browsers i used:
Mac Firefox + Safari + Chrome / Real Windows IE11 + MS Edge / Virtual IE11 + MS Edge (from link in task description for virtual box)
===========
Btw, i really like new box-shadow for radio elements
Comment #4
mherchelMy main concern is the noticeability of the focus states in high contrast mode. I'm going to ping the accessibility maintainers in the #accessibility channel in Drupal slack to weigh in.
Comment #5
mherchelSome comments from https://drupal.slack.com/archives/C2ANFUGGG/p1590154141261800
R Mazur:
rain:
andrewmacpherson:
andrewmacpherson:
andrewmacpherson:
andrewmacpherson:
andrewmacpherson:
Comment #6
kostyashupenkooutline-offset was added, also changed outline-style to "solid" and outline-width now bigger.
MS Edge with high contrast mode enabled:

IE11 with high contrast mode enabled:

Comment #7
mherchelThis is great work! I've found a couple issues
1) testing generic form styling (there isn't much)
2) in Firefox in Windows high contrast mode. Note that accessibility maintainer @andrewmacpherson specifically called out this use case in previous issues.
Below is a screenshot from a mailchimp form embedded within a site running Olivero. We expect the form elements to be styled.

Below is screenshot from Firefox in high contrast mode. Focus states are good, but there are no left/right borders. This is confusing (the labels almost look like placeholders...). In addition the select element does not have a down arrow.
Comment #8
kostyashupenkoWell.. i have a bad news.
First of all - i agree with you, we may get issues with embedded forms, so i did replace of `.form-element {}` based selectors by `attributes` as you suggested in your patch.
Second thing about firefox - i see no ways to fix reported issue with current implementation of form styles. There is no any detection of high-contrast mode for firefox in terms of CSS media queries. Styles looks so bad with firefox, and no linear-gradients, no background-images, and many other.
I see only 1 way to make it look better in firefox high contrast mode - is to transform background: linear-gradient() into borders as you suggested in your patch @mherchel, but as you remember - if we will use only borders, we will face with unexpected movement of elements on hover states. Some of these unexpected movements possible to fix - some of them not possible to fix too.
I see no other options.
Gonna summarize:
1. Or we keep current implementation of form elements where these form elements looks well styled and only (or mostly only) bugs in Firefox with enabled high contrast mode.
2. Or we need to redo all form-elements as you suggested in your patch (with border css-property, instead of linear-gradients) - after that issue with firefox with HCM enabled will be fixed, but some unexpected movement of text inside for example "type file" inputs, or text of textarea, or right bottom angle (resize icon) of textarea - we will face in all browsers.
Comment #9
mherchelyeah.. I really struggled with FF in high contrast mode with the search form (and there has since been a regression).
I fear leaving FF high contrast broke is a non-starter for inclusion in Drupal 8 core. The accessibility gate is very stringent (which is a good thing).
I'll hack away at your patch later today. What I did earlier is shrink padding on focus to account for the border width. There may be other options too (such as setting box-sizing to content-box) that we can experiment with. The hard part is all of these old browsers in esoteric use-cases... but this theme will (hopefully) be used by so many people that we need to do our best to account for it.
Thanks so much for working on this.
Comment #10
kostyashupenkoYup, let me review your changes please before merge
Comment #11
mherchelComment #12
mherchelI found the magical combination that works with everything. Tested in high contrast with IE11, Edge 44, and FF 76. Also seems to work in Chrome, Safari in normal use cases without shifting layout:
Comment #13
mherchelGonna hack at this today. Not sure I have much time to do so.
Comment #14
mherchelEnded up changing the focus outline to dashed. It's much more apparent.
Also, note that the multiple backgrounds with linear gradients do not work in FF in high contrast mode.
However, the single background image of the chevron works fine.
Comment #15
mherchelA couple notes about getting the select element to render properly in FF in high contrast mode:
Firefox will not render any background image if one of them has a linear gradient. This means we cannot use linear gradients where we need the chevron (because the only way that we can render the chevron is via a background image)
We cannot use box-shadow inset to render the background of the chevron... it appears in front of it and obscures it.
The only way that I found to render the solid background of the chevron is by calling another image (a small svg).
Note I'm using the same exact SVG to render the left border. This is because if I use the "border-left" property, the top and the bottom of the borders are angled to blend with the transparent top and bottom borders.
Comment #16
mherchelAdding some updated patches. Note the interdiff doesn't include the css/dist directory.
Still lots of work to do including error and disable statuses on select elements as well as the small version of that. But everything's working overall. Just needs lots of cleanup.
Comment #17
mherchelGot a bit more work done in the error states. I'm going to work on this tomorrow also. I want to get this committed and release alpha2 on monday if at all possible.
Comment #18
mherchelI got everything working based off of the patch in #8. There were a lot of issues with FF in high contrast mode including text input focus states, select arrows, and radio and checkbox not showing the unchecked state properly.
Patches attached.
Comment #19
mherchelI forgot to change the border color on the select element's focus state. Updated patches attached.
Comment #20
kostyashupenkoThanks for killing this issue, i have tested your patch and it looks almost finished. I have tested high contrast mode in FF/IE/Edge and form-elements and its hover/focus states looks great. I also found 3 bugs:
1. There is a top 2px gray line on selects / default state. And text is not aligned vertically as you can see

2. type="date" inputs has 56px of the height on google chrome (maybe other browsers too, i didn't check).

It comes from shadow dom elements, look at here -> this little string will fix the issue:

3. You have removed form-boolean--ie.css file, so now boolean form-elements looks un-styled in IE11:

Comment #21
mherchelUpdating patch and interdiff!
I personally think the IE11 styling is fine. It's completely usable.
Comment #22
kostyashupenkoHello @mherchel
i have tested your patch and issue number 1 still exist ("text is not aligned vertically" <- this part actually only). So you can fix it looks like by decreasing line-height for selects. Rests things are ok
Comment #23
kostyashupenkoAlso not sure if related, but
git apply -v [your-last-patch]gives:Comment #24
mherchelyeah, the config changes snuck in the patch.
I missed the part about text not being aligned vertically. Fix incoming.
Comment #25
mherchelUpdating patches to take into account the centering the text. Note the interdiff doesn't include removing the config.
Comment #26
kostyashupenkoIt looks like expected line-height should be the following:
line-height: calc(var(--form-element-select-height) - 2 * var(--form-element-border-size-base));since top border + bottom border
Comment #27
mherchelDecreasing the line-height causes some vertical alignment issues. Conceptually, you're correct, though. I think it's because the font isn't rendering in the center of its line-height. Not 100% sure though.

I'm committing as-is, we can follow up if we find a better way.
Comment #28
mherchelCommitted this. Let's open up a followup if the select is out of alignment, or if there's a better way to do it.
Comment #29
andypost@mherchel it still needs follow-up for #28
Comment #30
mherchel@andypost are you seeing the select elements out of alignment? If so, what browsers?
Comment #31
kostyashupenkoI will create a follow-up right now
Comment #32
kostyashupenkoComment #33
andypostThank you!