[blink-dev] Intent to implement outline-color: invert

85 views
Skip to first unread message

박중헌

unread,
Mar 14, 2019, 12:47:54 PM3/14/19
to blin...@chromium.org

Contact emails

Design docs/spec


TAG review

Summary

The outline-color property accepts all colors, as well as the keyword invert. 
Invert is expected to perform a color inversion on the pixels on the screen.
This is a common trick to ensure the focus border is visible, regardless of color background.

Motivation
The spec, https://drafts.csswg.org/css-ui-3/#outline-color, designates the css property outline-color’s
Initial value as ‘invert’, but the initial value was not implemented yet.
This “invert” css property value lets the css outline to stand out by contrast to the background as default
to be noticeable to user better,
if outline-color value is not specified as a specific color.
So implementing “invert" will help improve visibility of web contents using outline-color property.

All the values for "outline-color" css property is supported except the initial value,
so supporting “invert” value will make the property’s state as "fully supported”.

Interoperability risk
Edge: No signals
Firefox: No signals
Safari: No signals
Web / Framework developers: No signals

Compatibility risk
Only IE implements ‘invert’ behavior and it shows the expected result as the spec says.
The other browsers is not showing the expected behavior the spec says for outline-color: “invert”.
So the compatibility risk is limited.

Debuggability
No special devtools debugging is needed.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes

Tracking bug


Requesting approval to ship?
No

PhistucK

unread,
Mar 14, 2019, 2:44:29 PM3/14/19
to 박중헌, blink-dev
Huh, interesting outline-specific value. I would expect it to be a general color value, much like currentColor...

☆PhistucK


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/E0EF8C74-3646-4126-9E00-ECE3A5AC6068%40gmail.com.

Daniel Bratell

unread,
Mar 14, 2019, 3:11:29 PM3/14/19
to 박중헌, PhistucK, blink-dev
Your tag review link is not to a tag review, but I assume this spec is pretty well discussed and analyzed so unless someone else knows differently, a separate tag review might not be needed.

The main concern (in the spec and otherwise) is whether it can be efficiently implemented. It seems it can so I guess it's ready. Seems you are handling the web platform test situation as well. 

/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_KKS66ojXjM41n5WhOGnGPHbWhXdamgfg1001yybqBdaw%40mail.gmail.com.



--
/* Opera Software, Linköping, Sweden: CET (UTC+1) */

Kevin Babbitt

unread,
Mar 14, 2019, 5:21:06 PM3/14/19
to PhistucK, 박중헌, blink-dev

One note regarding interop – Edge does support this value.

 

Kevin

flo...@rivoal.net

unread,
Mar 14, 2019, 10:37:11 PM3/14/19
to blink-dev
Spec editor here.

Yes, the spec for this should be considered stable (REC, has multiple implementations).

When writing the spec, we were aware that despite the behavior being desirable, it was hard to implement, and so we made an allowance for implementations not to have it. It's possible to implement, as demonstrated by the Microsoft and the presto-based Opera implementations, but it may not be friendly to how your painting code works.

So, not supporting it is spec compliant (as you as you ignore it the right way), and supporting it is as well.

If you can implement it with reasonable performance, I would recommend doing so.

—Florian

L. David Baron

unread,
Mar 15, 2019, 1:28:05 AM3/15/19
to 박중헌, blin...@chromium.org
On Friday 2019-03-15 01:34 +0900, 박중헌 wrote:
> Firefox: No signals

In Gecko it used to be implemented, but was removed in 2006 in:
https://bugzilla.mozilla.org/show_bug.cgi?id=326550
https://bugzilla.mozilla.org/show_bug.cgi?id=335394
I'm not aware of any plans to readd it.

(It also seems to me that defining what 'invert' is supposed to do
has many of the same issues as 'backdrop-filter', which is still a
topic of active discussion in
https://github.com/w3c/fxtf-drafts/issues/53 .)

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)
signature.asc

Stephen Chenney

unread,
Mar 15, 2019, 11:45:47 AM3/15/19
to L. David Baron, 박중헌, blink-dev
Looking at the Mozilla bugs, it was removed because the graphics implementation made it hard to generate good results. We will certainly look at the results as this is implemented and we won't ship the change if they are unacceptable. Same for performance (there's already been some code review discussion on that issue).

Regarding the relationship to backdrop-filter, I agree they are similar in that they blend background colors in some way, but I think the bar is much lower for outline-color:invert. backdrop-filter is intended to produce a specific visual effect with clear author intent. outline-color: invert is intended only to produce high-contrast outlines. If a content author wanted a specific outline appearance, they could set the outline-color to something specific.

My view is that it's worth implementing this and we can review shipping once we know how the feature performs.

Stephen.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/20190315052756.GA374%40pescadero.dbaron.org.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEkIYF7CKIBR780rBx7+FhJQ+E/CEFAlyLN9oACgkQ7+FhJQ+E
/CGNRQ/6Aww6v7D0I/XW8U41frQzQd0Pa0QDpVoXeW2w6B5fo6T9ipg8UVGUOHjZ
wRkqWEyuHvjNwuoJNSAbctVBqBN1iS4ZtFSUViJHDviTJ5r3J007deIaDl8rmuOC
R97xlQQPP/f8qGiVDdSTfGa3aEADdwBH38k5UChO2fq/5uUXiiDYQ3SA4RMCNKnq
1tpTYgzjQXEPR01ueiyJaZJhzym4Cwmi9ax5/9sF/CHK2BIfMCh4S4BuB77BFc3S
8vz3PNZ7NeDJSIhlJ9Bp75mXoAOUM0nYm2DrONbamsczdvxJyBy7uzU2BLtg3O8Q
amBg2Ctqr4iighTQ+j3o2opqQk3eZc8Gy1P4fmBP2nXj3YIClhYjLkLCNjZ3Ixfh
IiTjnTbjkqn31oJq4xrMRoQR+r6ZflA8Xw1kK5rRdzUPOuXqQvrwQSqlq4urmB5r
jXNZK85MBTG627DLDZsLNpxLe41u+mE5o6GiFcM8aohyHV/2S4F3HKymzGVXQoK7
iMTsnP1tU4rnwfTsw62HR/TUp72MK+XBLGaayXN7bgzWF/VHwn6Bvf8ilmQlr/CZ
AQI3zm+klWzhlmCYdQJrpkGuYSRIjqewFUdfAW2zGfmyenJLLbd05XieKt1tnV+K
8gc8yWCkLJLmLtN7V4tE2YEsLmUQx6KOb53FaQbGdOdDxiKDOPc=
=28dF
-----END PGP SIGNATURE-----

박중헌

unread,
Mar 16, 2019, 12:17:38 PM3/16/19
to Stephen Chenney, L. David Baron, blink-dev
Thank you for your feedback:)
It looks like supporting outline-color: invert is recommended in this thread,
It will be wrapped by runtime flag at some point, and as Stephen said it will be reviewed whether it can be shipped when it's ready.

- Joonghun

2019년 3월 16일 (토) 오전 12:45, Stephen Chenney <sche...@chromium.org>님이 작성:

Mason Freed

unread,
Mar 16, 2019, 1:36:40 PM3/16/19
to 박중헌, L. David Baron, Stephen Chenney, blink-dev
This definitely seems worth implementing, but the other comments about its similarity to backdrop-filter are correct. You should think about what the expectation is for an element with “outline-color:invert” that is nested inside an element with “filter:invert”. Please see example #1 in the backdrop-filter spec Motivation section for a lot more detail:

I agree with Stephen that the bar is lower for the exact visual output of this feature, given that the point is enhanced visibility. Perhaps you could just add a note that the exact pixel output isn't well defined when this feature is nested inside other filters or opacity?

Thanks,
Mason
 

sam...@microsoft.com

unread,
Mar 18, 2019, 3:41:01 PM3/18/19
to blink-dev
Edge (based on edgehtml) did support this.  However, that support came with the necessity of disabling composition for scrollers, video, etc. when invert was used in certain scenarios in order to be spec compliant.  Because disabling composition has a significant impact on scrolling performance, video playback battery cost, etc. and this disabling reason was rising to be one of the most common reasons, we had an item on our backlog to remove invert support in general.

My recommendation here is to find a way to implement it without introducing those same performance issues into Chromium.

PhistucK

unread,
Mar 18, 2019, 5:27:07 PM3/18/19
to sam...@microsoft.com, blink-dev
Is there an operating system level inversion method? Like cursors (on Windows, anyway) have an invert-type of color?

☆PhistucK


On Mon, Mar 18, 2019 at 9:41 PM samfort via blink-dev <blin...@chromium.org> wrote:
Edge (based on edgehtml) did support this.  However, that support came with the necessity of disabling composition for scrollers, video, etc. when invert was used in certain scenarios in order to be spec compliant.  Because disabling composition has a significant impact on scrolling performance, video playback battery cost, etc. and this disabling reason was rising to be one of the most common reasons, we had an item on our backlog to remove invert support in general.

My recommendation here is to find a way to implement it without introducing those same performance issues into Chromium.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/414a2a96-8166-4ee3-9312-0cf7bcd5803c%40chromium.org.
Reply all
Reply to author
Forward
0 new messages