Intent to implement and ship: CSS caret-color property

[Xidorn Quan]

Summary: As the name indicates, it allows developers to change the color
or caret.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1063162

Link to standard: https://drafts.csswg.org/css-ui-3/#insertion-caret

Platform coverage: All platforms

Estimated or target release: Firefox 53

Preference behind which this will be implemented: No pref. Intent to
ship by default since it's a small feature which is simple and
considered stable enough.

DevTools bug: None. I don't think there is anything specific to this
property need to be added to DevTools.

Do other browser engines implement this?
Blink: Intent to implement and ship:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/6jK81erL87E/i6t4G9AaAwAJ

Tests - URLs / paths to tests (preferably web-platform-tests)
CSSWG's test repo contains some semi-manual tests, which are not usable
in our infra. I'm adding an internal reftest (not wpt or csswg test)
which uses some of our internal features to check its rendering.

[Manuel Rego Casasnovas]

Hi,

just a small clarification regarding tests:

On 21/12/16 01:17, Xidorn Quan wrote:
> Tests - URLs / paths to tests (preferably web-platform-tests)
> CSSWG's test repo contains some semi-manual tests, which are not usable
> in our infra. I'm adding an internal reftest (not wpt or csswg test)
> which uses some of our internal features to check its rendering.

Indeed a bunch of tests are not automatic, but there are a few (6 right
now) that are testharness tests (completely automatic), so they might be
useful for you too.

In Blink we're using the semi-manual tests as pixel tests and,
of course, we also use the testharness ones.

Cheers,
Rego

[Xidorn Quan]

Thanks for the clarification.

In Gecko, unfortunately, we are currently not able to run testharness
tests in CSSWG's test repo. And comparing with pixel tests, I'd prefer
using normal reftest (with adjusting our internal options) which should
be more robust.

- Xidorn

[Ehsan Akhgari]

Gecko supports a navigation mode caret which can be activated by
pressing F7 or Preferences -> Advanced -> General -> Always use the
cursor keys to navigate within pages.

The spec does mention this, but I can’t figure out what it’s saying that
the browser should do with the navigation caret. Should this property
not be respected for the navigation caret? Note that right now nsCaret
doesn’t know which kind of caret it is drawing; currently both kinds of
carets are activated in the exact same way through
nsCaret::SetVisible(). How are you planning to handle this?

Furthermore, this property is animatable, but the caret blinks… Are we
planning to support animating this property? If yes, how would that
work with the blinking, do we just use the right color for the times we
are drawing the caret and let the animation continue when it is hidden?
Is there something we need to do (such as clarifying how this should
work in the spec) to achieve interop?

On 2016-12-20 7:17 PM, Xidorn Quan wrote:
> Summary: As the name indicates, it allows developers to change the color
> or caret.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1063162
>
> Link to standard: https://drafts.csswg.org/css-ui-3/#insertion-caret
>
> Platform coverage: All platforms
>
> Estimated or target release: Firefox 53
>
> Preference behind which this will be implemented: No pref. Intent to
> ship by default since it's a small feature which is simple and
> considered stable enough.
>
> DevTools bug: None. I don't think there is anything specific to this
> property need to be added to DevTools.
>
> Do other browser engines implement this?
> Blink: Intent to implement and ship:
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/6jK81erL87E/i6t4G9AaAwAJ
>

> Tests - URLs / paths to tests (preferably web-platform-tests)
> CSSWG's test repo contains some semi-manual tests, which are not usable
> in our infra. I'm adding an internal reftest (not wpt or csswg test)
> which uses some of our internal features to check its rendering.

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Xidorn Quan]

On Sat, Dec 24, 2016, at 04:32 AM, Ehsan Akhgari wrote:
> Gecko supports a navigation mode caret which can be activated by
> pressing F7 or Preferences -> Advanced -> General -> Always use the
> cursor keys to navigate within pages.
>
> The spec does mention this, but I can’t figure out what it’s saying that
> the browser should do with the navigation caret. Should this property
> not be respected for the navigation caret? Note that right now nsCaret
> doesn’t know which kind of caret it is drawing; currently both kinds of
> carets are activated in the exact same way through
> nsCaret::SetVisible(). How are you planning to handle this?

I wasn't aware that there is navigation caret. Since nsCaret doesn't
know its kind, in my current impl, caret-color does affect the
navigation caret as well.

I'm not sure whether the spec should say anything about this, and given
the current spec, I guess navigation caret doesn't need to respect this
property. But for consistency (and not making the code more
complicated), I'd prefer just keep the current impl that this property
affects navigation caret as well.

I don't think that would be a problem, because the number of people who
use navigation caret is rather limited, and thus I don't think websites
would likely hide the caret for normal text intentionally to annoy
people who use that.

Also people can always specify ":root { caret-color: auto !important; }"
in their user stylesheet to effectively disable this property if they do
find any website doing annoying things with it.

> Furthermore, this property is animatable, but the caret blinks… Are we
> planning to support animating this property? If yes, how would that
> work with the blinking, do we just use the right color for the times we
> are drawing the caret and let the animation continue when it is hidden?
> Is there something we need to do (such as clarifying how this should
> work in the spec) to achieve interop?

Yes, we will support animating this property.

CSS animation acts on the style system, so there is nothing it can do to
interact with the caret blinks. The animation would continue no matter
whether the caret is shown or hidden.

It may be useful to allow authors to coordinate blinking with the
animation, but I don't think there is any mechanism in the spec (nor in
our code) can achieve this. I guess future spec can introduce a property
to disable the native caret blinking, so that authors can fully control
the blinking via CSS animations.

- Xidorn

[Ehsan Akhgari]

On 2016-12-23 8:13 PM, Xidorn Quan wrote:
> On Sat, Dec 24, 2016, at 04:32 AM, Ehsan Akhgari wrote:
>> Gecko supports a navigation mode caret which can be activated by
>> pressing F7 or Preferences -> Advanced -> General -> Always use the
>> cursor keys to navigate within pages.
>>
>> The spec does mention this, but I can’t figure out what it’s saying that
>> the browser should do with the navigation caret. Should this property
>> not be respected for the navigation caret? Note that right now nsCaret
>> doesn’t know which kind of caret it is drawing; currently both kinds of
>> carets are activated in the exact same way through
>> nsCaret::SetVisible(). How are you planning to handle this?
>
> I wasn't aware that there is navigation caret. Since nsCaret doesn't
> know its kind, in my current impl, caret-color does affect the
> navigation caret as well.
>
> I'm not sure whether the spec should say anything about this, and given
> the current spec, I guess navigation caret doesn't need to respect this
> property. But for consistency (and not making the code more
> complicated), I'd prefer just keep the current impl that this property
> affects navigation caret as well.

FWIW there is only a single call site to SetVisible() for the
navigational caret:
<http://searchfox.org/mozilla-central/rev/60785fce6d52289c2e147364863f9d42207c5f91/dom/base/nsFocusManager.cpp#2331>
if browseWithCaret is true.

> I don't think that would be a problem, because the number of people who
> use navigation caret is rather limited, and thus I don't think websites
> would likely hide the caret for normal text intentionally to annoy
> people who use that.
>
> Also people can always specify ":root { caret-color: auto !important; }"
> in their user stylesheet to effectively disable this property if they do
> find any website doing annoying things with it.

The reason why I mentioned this is that this feature is related to
accessibility, and I'm worried that respecting random styles for this
may hinder the visibility of the caret on the screen, but I suppose as
things stand the caret may not be fully visible everywhere on the
page... I'm fine with leaving things as is personally.

>> Furthermore, this property is animatable, but the caret blinks… Are we
>> planning to support animating this property? If yes, how would that
>> work with the blinking, do we just use the right color for the times we
>> are drawing the caret and let the animation continue when it is hidden?
>> Is there something we need to do (such as clarifying how this should
>> work in the spec) to achieve interop?
>
> Yes, we will support animating this property.
>
> CSS animation acts on the style system, so there is nothing it can do to
> interact with the caret blinks. The animation would continue no matter
> whether the caret is shown or hidden.
>
> It may be useful to allow authors to coordinate blinking with the
> animation, but I don't think there is any mechanism in the spec (nor in
> our code) can achieve this. I guess future spec can introduce a property
> to disable the native caret blinking, so that authors can fully control
> the blinking via CSS animations.

Thanks for your explanation, sounds good!

[Gijs Kruitbosch]

On 24/12/2016 01:24, Ehsan Akhgari wrote:
> On 2016-12-23 8:13 PM, Xidorn Quan wrote:
>> I don't think that would be a problem, because the number of people who
>> use navigation caret is rather limited, and thus I don't think websites
>> would likely hide the caret for normal text intentionally to annoy
>> people who use that.
>>
>> Also people can always specify ":root { caret-color: auto !important; }"
>> in their user stylesheet to effectively disable this property if they do
>> find any website doing annoying things with it.
>
> The reason why I mentioned this is that this feature is related to
> accessibility, and I'm worried that respecting random styles for this
> may hinder the visibility of the caret on the screen, but I suppose as
> things stand the caret may not be fully visible everywhere on the
> page... I'm fine with leaving things as is personally.

Can we make sure that this property like color: and background-color:
before it is affected by the existing prefs (for which we have browser
UI, unlike "add this random CSS to userContent.css") to turn off website
colors and override them with system- or user-configured foreground and
background colors? That would likely help with at least some of the a11y
concern.

~ Gijs

[Xidorn Quan]

It would be controlled by the same pref as other color properties that
we have browser UI for.

Are you proposing that we should add another pref for that? I don't
think it's worth.

- Xidorn

[Gijs Kruitbosch]

No, just that we should make sure it is governed by the existing
pref(s). We can reuse the generic foreground colour for the caret also.

~ Gijs

[Manuel Rego Casasnovas]

Hi,

On 23/12/16 18:32, Ehsan Akhgari wrote:
> The spec does mention this, but I can’t figure out what it’s saying that
> the browser should do with the navigation caret. Should this property
> not be respected for the navigation caret? Note that right now nsCaret
> doesn’t know which kind of caret it is drawing; currently both kinds of
> carets are activated in the exact same way through
> nsCaret::SetVisible(). How are you planning to handle this?

This was discussed here:
https://github.com/w3c/csswg-drafts/issues/725

And in a CSS WG telecon [1] as a result a note was added on the spec:
https://drafts.csswg.org/css-ui/#caret-color

So it seems caret-color could be applied to navigation caret too.

Bye,
Rego

[1] https://lists.w3.org/Archives/Public/www-style/2016Nov/0123.html