Skip to content
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.

Adjust opacity of filter/overlay layer for IE and Edge #121

Closed
LittleBigThing opened this issue Oct 17, 2018 · 12 comments · Fixed by #375
Closed

Adjust opacity of filter/overlay layer for IE and Edge #121

LittleBigThing opened this issue Oct 17, 2018 · 12 comments · Fixed by #375
Labels
browser issues bug Something isn't working has patch
Milestone

Comments

@LittleBigThing
Copy link

The blue layer that is set over featured images has a distinct effect and it makes the theme kind of unique (among default themes). However, mix-blend-mode that is used to achieve this is not supported by, for example, Internet Explorer and Edge. In these browsers, a blue rectangle is displayed without any transparency: the featured image is not visible at all.

To kind of change this, the opacity value of the overlay could be lowered. This results in a similar (but different :-)) effect in browsers not supporting mix-blend-mode.

We should probably look for a better solution...
Also, the color of the layer should be customisable.

@fabiankaegy
Copy link
Member

fabiankaegy commented Oct 17, 2018

The customisability was also mentioned in #85 and added in #113. The browser support is a valid point

@kjellr kjellr added bug Something isn't working browser issues labels Oct 17, 2018
This was referenced Oct 17, 2018
@LittleBigThing
Copy link
Author

An update with examples when appying #124:

chrome
Chrome

microsoft edge
Edge

@kjellr
Copy link
Collaborator

kjellr commented Oct 18, 2018

As I noted in the other thread, unfortunately adjusting the opacity results in less-accessible text contrast. 😞

I agree that we should come up with a better solution for this though — mix-blend-mode is clearly not viable on all browsers at this point.

@LittleBigThing LittleBigThing changed the title Adjust opacity of filter/overlay layer Adjust opacity of filter/overlay layer for IE and Edge Oct 22, 2018
@celloexpressions
Copy link

Could this fall back to an rgba or hsla color? That may offer better results than opacity. It could also be treated only as a fallback for browsers that don't support mix-blend-mode if the results are reasonably similar.

@LittleBigThing
Copy link
Author

Using an rgba color gives the same results since it is about the opacity of another layer than the layer that contains the text.

Opacity
screenshot 2018-10-23 at 06 55 10

rgba color
screenshot 2018-10-23 at 06 54 08

Original
screenshot 2018-10-23 at 07 03 37

I was thinking about using @supports and that is possible to prevent losing contrast on browsers supporting mix-blend-mode, but it still gives the same results in IE and Edge I think. It is just tricky to get similar results in these browsers as with blending. Also, if we allow customizing the color (#191), the result will be significantly different using, say, Edge and Firefox.

@LittleBigThing
Copy link
Author

For what it's worth... :-)

This is the highest similarity I get when adjusting opacity and background color for browsers that do not support mix-blend-mode:
Tweak 1

  • I changed the opacity for the third layer from 1 to 0.8
  • I changed the background color for the fourth layer from rgba(255, 255, 255, 0.35) to rgba(0, 0, 0, 0.35).

Tweak 2

  • I changed the opacity for the third layer from 1 to 0.75
  • I removed the fourth layer

I did not change the readability layer (fifth layer). Maybe a bit better like this? At least, the initial design does not change for supporting browsers.

I am not sure whether accessibility tests pass for the initial design, so maybe that (or only the readability overlay) should be tweaked as well before going further or in another direction?

Tweak 1. Chrome on the left (= initial design), Edge on the right:

2018-10-23 12_17_26

Tweak 2. Chrome on the left (= initial design), Edge on the right:

2018-10-23 12_57_58-screenshot

@kjellr kjellr added this to the RC1 milestone Oct 23, 2018
@kjellr
Copy link
Collaborator

kjellr commented Oct 24, 2018

Thank you for all your research on this, @LittleBigThing!

I took a look this afternoon, and tweak 1 above appears to be a good balance of maintaining the current appearance while maintaining similar support in other browsers. Lets move forward with that direction.

I am not sure whether accessibility tests pass for the initial design, so maybe that (or only the readability overlay) should be tweaked as well before going further or in another direction?

I just did a quick preliminary check, and both of these result in WCAG AA-passing color contrast for all the text sitting on top. (The lightest possible background color while using mix-blend-mode is #35729D, and the lightest possible color in the fallback is #316B8A). That's basically equivalent to what we have in place now.

That said, we'll keep tracking the accessibility portion of this over in #6. If we add an additional over/underlay we'll plan on making sure it works in both contexts.

@LittleBigThing
Copy link
Author

Ok, I'll try to propose a PR later today.

@kjellr
Copy link
Collaborator

kjellr commented Oct 25, 2018

Thank you!

@LittleBigThing
Copy link
Author

LittleBigThing commented Oct 28, 2018

So, another shot at making the featured image visible in IE and Edge.

Some remarks:

  • it still needs some testing (see bug mentioned in the PR adjust opacity featured image for IE and Edge #375) and improvement.
  • mix-blend-mode is now added to all browsers (for simplicity), but it could be wrapped into @supports().
  • We can still play around a bit with the opacity of the fourth layer (layer .site-branding-container:after for single posts and pages and .post-thumbnail-inner:after for a post in the post feed) for IE and Edge, I think that making the image a little darker will improve accessibility. It has now the same opacity as supporting browsers have, but a black instead of a white color.

@LittleBigThing
Copy link
Author

LittleBigThing commented Oct 28, 2018

Oh also this:

  • the grayscale filter is now added to the featured image in the post feed without the mixin (filter-grayscale). It is was already applied the featured image without the mixin to for single posts and pages. I am not sure why the mixin is built like it is now and whether it is used elsewhere. If not, we might not need it anymore and use a simple variable instead.

@kjellr
Copy link
Collaborator

kjellr commented Oct 28, 2018

Thanks again, @LittleBigThing! Just leaving a couple notes here:

mix-blend-mode is now added to all browsers (for simplicity), but it could be wrapped into @supports().

I think leaving these in place for all browsers is fine for now —  we don't currently need @supports() calls for every instance of mix-blend-mode, so this produces slightly slimmer code for now. 👍

We can still play around a bit with the opacity of the fourth layer (layer .site-branding-container:after for single posts and pages and .post-thumbnail-inner:after for a post in the post feed) for IE and Edge, I think that making the image a little darker will improve accessibility. It has now the same opacity as supporting browsers have, but a black instead of a white color.

I ran another test before merging, and here are the lightest colors possible with our filters:

  • Browsers with mix-blend-mode: #307197, Passes WCAG AA, 5.34:1
  • IE/Edge, without mix-blend-mode: #266B8D, Passes WCAG AA, 5.88:1

They're fairly similar, but the IE/Edge solution has slightly more contrast. Not bad. 👍

the grayscale filter is now added to the featured image in the post feed without the mixin (filter-grayscale). It is was already applied the featured image without the mixin to for single posts and pages. I am not sure why the mixin is built like it is now and whether it is used elsewhere. If not, we might not need it anymore and use a simple variable instead.

You're right! That mixin appears to be unused. 😄 We should remove it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
browser issues bug Something isn't working has patch
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants