[css-text-decor] [css-pseudo] default ‘text-decoration-color’ of ‘spelling-error’ and ‘grammar-error’

[delan]

https://drafts.csswg.org/css-text-decor-4/#text-decoration-line-property

Since spelling-error and grammar-error decorations are entirely UA-defined, the UA may disregard the other sub-properties of text-decoration, as well any other properties typically affecting the appearance of line decorations (such as text-underline-position, color, stroke, or fill) when rendering these decorations. However, to the extent that honoring any of these properties would be meaningful and practical given the UA’s chosen rendering, the UA should apply them as modifications to its default styling.

This suggests the UA is allowed (but not required) to heed ‘text-decoration-color’ when ‘text-decoration-line’ is set to ‘spelling-error’ or ‘grammar-error’. But if the UA heeds ‘text-decoration-color’, how would it represent the default spelling/grammar decoration color (usually red or green) in UA rules for spelling/grammar pseudos? The initial value of ‘currentColor’ won’t work.

:root::spelling-error { text-decoration: <color> spelling-error; }
:root::grammar-error { text-decoration: <color> grammar-error; }

Do we need to define system colors for these, or can the UA make up its own internal color values? What do authors do if they want to reliably add decorations that look like native spelling/grammar decorations, including the decoration color?

(@fantasai, @frivoal, @mrego)

[fantasai]

Interesting question... and it's particularly tricky if the UA wants to use different colors depending on the color-scheme. I think we could go a couple of ways here:

• If the computed text-decoration-color is currentColor, use the UA-chosen color.
• Introduce a new computed value for text-decoration-color, e.g. auto, and set that value in the UA stylesheet.
• Don't allow text-decoration-color to affect spelling/grammar errors.

I don't have a strong opinion here.

[css-meeting-bot]

The CSS Working Group just discussed [css-text-decor] [css-pseudo] default ‘text-decoration-color’ of ‘spelling-error’ and ‘grammar-error’, and agreed to the following:

• RESOLVED: other text decoration properties don't apply when native text-decoration-styles are in effect

The full IRC log of that discussion

<emilio> schenney: UA sheets need to specify a color for spelling / grammar markers
<Rossen_> q?
<emilio> ... no way to specify the platform-appropriate color to account for hcm etc
<emilio> q+
<myles> q+
<hober> ack emilio
<bramus> emilio: that is what system colors are for?
<Rossen_> ack myles
<emilio> emilio: in gecko we use internal system colors for this
<emilio> ... if we come up with a good name it seems it'd be ok to expose it?
<emilio> myles: our spelling and grammar dots are images, not just solid colors
<schenney> q+
<emilio> ... so I'm not convinced we should expose this through system colors
<emilio> ... also not sure there's a use case to use the system color but not the system design
<Rossen_> ack fantasai
<florian> q+
<emilio> fantasai: I think when we brought the issue there were three options: (1) text-decoration-color don't apply without a style (2) add text-decoration-color: auto and make it compute to something
<emilio> q+
<Rossen_> ack schenney
<emilio> ... I'd be ok with saying you can't use t-d-c unless you also specify style
<fantasai> s/to something/depending on the text-decoration-line value/
<emilio> schenney: I agree that using the system design is probably better
<emilio> ... but if we use a color can we pick a good one?
<Rossen_> ack schenney
<emilio> myles: how do we know to pick a good or bad color?
<emilio> fantasai: the original intention for text-decoration-style: spelling-error/grammar-error was to accommodate for platforms where it's not a simple style
<fremy> @florian, use the mike :P
<emilio> florian: agreed, color should just do nothing for those text-decoration-style values
<Rossen_> ack
<Rossen_> q
<Rossen_> ack *
<Rossen_> ack florian
<Rossen_> ack emilio
<bramus> emilio: is this parallel to how we deal with outline style? and right now there are differences in how browsers deal with that. I tihnk it should be possible for a browser to not use text-decoration-color or their native style
<bramus> florian: yes, that is allowed
<florian> qq+
<GameMaker> q+
<bramus> emilio: do we allow uas to use it? e.g. ??? have their outline derived from sth else. do we want to allow this for this styles or say just no?
<Rossen_> ack florian
<Zakim> florian, you wanted to react to emilio
<bramus> florian: UA is allowed to but not required
<bramus> emilio: is myles fine with that? or should we say text deco color explicitly has no effect?
<schenney> q+
<emilio> ack GameMaker
<Rossen_> ack GameMaker
<emilio> GameMaker: with our current grammar error is blue dots, is that ok?
<emilio> fantasai: yes
<nicole> q+
<emilio> GameMaker: I don't know if I can speak to this but if our designers wanted to take this into account, to draw orange dots if the author specified that, would that be fine?
<Rossen_> ack fantasai
<emilio> florian: that's what the spec says right now
<emilio> fantasai: the spec is very flexible now, the downside to not forbidding it is that authors might expect it to have an effect based on the browser they're testing it
<emilio> ... let's say mozilla implements it and allows it, then firefox and chrome do that
<emilio> ... they put something on a blue background and use text-decoration-color: orange
<florian> q+
<emilio> ... then safari users get blue on blue
<Rossen_> ack schenney
<emilio> ... not sure that's worth locking it down more or not
<emilio> schenney: curious, say chromium on mac wanted to match the macOS platform
<emilio> ... we could have a system color and we'd be ok not defining that color
<emilio> fantasai: if we're going to honor the color automatically but not all the time then we need a keyword to distinguish
<emilio> q+
<ntim> q+
<emilio> nicole: it seems something where what's good for the user might be different from what's good for the developer
<emilio> ... user probably wants to match the OS
<Rossen_> ack nicole
<emilio> ... then there's a developer need
<emilio> ... to change it if needed
<bramus> q+
<Rossen_> ack florian
<emilio> ... is that the case? if so it might be worth doing something like with accent-color
<emilio> florian: going back to fantasai's example, that's one case where it might be needed to break the convention
<emilio> ... if the apple folks have blue dots, they need to deal with blue backgrounds in some way
<hober> q?
<emilio> nicole: I'm thinking something about grammarly when they might have more sophisticated than what browsers provide
<emilio> florian: but they can either pick the default platform style, but changing text-decoration-style is already available
<emilio> hober: the grammarly case is handled by customizing it
<schenney> q+
<bramus> q-
<Rossen_> ack fantasai
<Zakim> fantasai, you wanted to react to florian
<emilio> fantasai: yeah grammarly could use the default grammar style
<emilio> ... or they could change the style
<emilio> nicole: so authors can't opt into the ua style?
<emilio> myles: they can, but they either get all of the magic or none of the magic
<Rossen_> q?
<emilio> ... we object to a middle ground where you get some of the magic
<emilio> florian: the other thing is you can also select based on the element to opt in or out of the native style
<emilio> nicole: how would they do it if you want to ensure contrast?
<emilio> florian: if you know the background you can get the color
<emilio> ... otherwise you set the background style to the UA and hope the UA does a good job at it
<Rossen_> ack emilio
<emilio> Rossen_: the problem nicole is describing is a lot more general
<bramus> emilio: the current spec seems fine. but we need to be careful with compat. Also see what fantasai said a while ago.
<bramus> … the defualt sstyle should work on any bg
<bramus> … if images need a different order; thats how native outlines work as well.
<emilio> ntim: I think it'd make sense to behave like outline-style: auto where the color is ignored
<bramus> emilio: the point is that there are browsers that can customize. e.g/ firefox uses AccentColor for the native outline-style
<Rossen_> ack ntim
<bramus> myles: I dont understand
<bramus> emilio: the whole point of this discussion is to determien if uas are allowed or not to change the rendering of their native grammar styles based on text-deco-color
<florian> qq+
<bramus> … right now they are allowed. q is should we restrict it
<bramus> … some browsersa llow to change the color, some dont
<bramus> … the ones that allow it do it in different ways
<bramus> …. are we fine with that? more grammar styles or not?
<bramus> ntim: (missed)
<bramus> emilio: in firefox we allow you to customize the AccentColor, but default it is the OS one
<astearns> s/(missed)/outline-color does not change the color of the built-in outline
<astearns> (I think)
<bramus> ntim: I guess speellin-error ang rammer-error would be up to the ua
<bramus> … maybe that’s all up to them?
<bramus> emilio: that is the q
<bramus> ntim: (missed2)
<emilio> ntim: I think customizing it via text-decoration-color would be a mistake
<Rossen_> q?
<Rossen_> ack florian
<Zakim> florian, you wanted to react to ntim
<emilio> florian: I don't think this is the question. That's already allowed in the spec, the question is "can we do something with the color"
<emilio> ... and it seems answer is no
<emilio> schenney: I was hoping to propose a resolution
<emilio> ... q is "should the browser and the author agree and define custom grammar markers"
<emilio> ... seems like we want the UA to allow any current color
<Rossen_> ack schenney
<bramus> emilio: no
<Rossen_> ack florian
<Rossen_> ack fantasai
<emilio> fantasai: we're looking at several options
<emilio> ... (1) no spec change, ua may interpret text-decoration-line: grammar-error using the system pattern and color
<emilio> ... but they can honor text-decoration-color
<emilio> ... if you are a UA that doesn't want to allow customization you ignore all t-d props
<emilio> ... but otherwise is when the author has set a color you honor
<emilio> ... the q is what is "when the author has set a color"
<emilio> ... t-d-c: currentColor? Something else?
<emilio> ... that's not clear
<emilio> ... So we can say t-d-c doesn't affect t-d-s: grammar-error
<emilio> ... or we say t-d-c allow t-d-c but provide a magic t-d-c: auto or something
<florian> q+
<schenney> q+
<emilio> ... third option is introducing new system colors
<emilio> ... doesn't seem we're going with that
<emilio> q+
<emilio> fantasai: but we should pick between the other two options
<ntim> I'm in favor of "Don't allow text-decoration-color to affect spelling/grammar errors."
<Rossen_> ack florian
<emilio> florian: for the UAs that want to ignore it the spec is fine but for the others it's not entirely clear what should happen
<emilio> ... so adding a normal/auto initial kw for t-d-c
<emilio> ... sounds useful
<emilio> fantasai: right but we want to go to the question of "do we want to allow that"
<Rossen_> ack schenney
<emilio> schenney: I think authors would be confused at not being able to specify the color
<emilio> fantasai: but they can't
<emilio> schenney: if you specify ::grammar-error {}
<ntim> q+
<emilio> fantasai: ::grammar-error {} has text-decoration-style: grammar-error, but I can also style it on an `<u>` element
<emilio> ... and then I'd get that style
<emilio> ... if I want to style `::grammar-error {}` and I want a pink double underline I can set `text-decoration: pink double-underline` and that's already
<emilio> ... but if I do `u { text-decoration: grammar-error; text-decoration-color: pink }`
<emilio> ... do I get a pink styling
<Rossen_> q?
<astearns> my vote is to disallow UA-provided decorations to respond to CSS property values
<emilio> ... so if we allow it to be influenced by text-decoration-color we need something to differentiate
<emilio> schenney: I see in that case I'd vote to disallow t-d-c to influence t-d-s: grammar-error
<bramus> emilio: there is an alteratnive to providing a new value for tdc, similar to borders. ua already has meachnism to see if author specified a new value.
<bramus> … seems we are arriving to consensus of not allowing tdc to influence it
<Rossen_> ack emilio
<Rossen_> ack ntim
<bramus> ntim: I agree with not allowing
<florian> Option 1: disallow taking the color into account
<florian> Option2: allow it and introduce a initial value (auto or normal) to text-decoration-color. When that value is specified, do whatever the platform want, if some other color is specified, the UA may take it into account.
<emilio> option3: Use the same UA magic for appearance and borders/backgrounds
<ntim> +1 to that
<schenney> +1
<emilio> fantasai: proposal is for native text decorations none of the other t-d properties apply
<bramus> emilio: do we wan tto do color or also offsets and stuff?
<bramus> florian: nothing
<bramus> s/florian/fantasai
<emilio> s/florian:/fantasai:
<emilio> RESOLVED: other text decoration properties don't apply when native text-decoration-styles are in effect