- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Jul 2023 17:46:23 +0000
- To: public-css-archive@w3.org
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`
<details><summary>The full IRC log of that discussion</summary>
<emilio> schenney: UA sheets need to specify a color for spelling / grammar markers<br>
<Rossen_> q?<br>
<emilio> ... no way to specify the platform-appropriate color to account for hcm etc<br>
<emilio> q+<br>
<myles> q+<br>
<hober> ack emilio<br>
<bramus> emilio: that is what system colors are for?<br>
<Rossen_> ack myles<br>
<emilio> emilio: in gecko we use internal system colors for this<br>
<emilio> ... if we come up with a good name it seems it'd be ok to expose it?<br>
<emilio> myles: our spelling and grammar dots are images, not just solid colors<br>
<schenney> q+<br>
<emilio> ... so I'm not convinced we should expose this through system colors<br>
<emilio> ... also not sure there's a use case to use the system color but not the system design<br>
<Rossen_> ack fantasai<br>
<florian> q+<br>
<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<br>
<emilio> q+<br>
<Rossen_> ack schenney<br>
<emilio> ... I'd be ok with saying you can't use t-d-c unless you also specify style<br>
<fantasai> s/to something/depending on the text-decoration-line value/<br>
<emilio> schenney: I agree that using the system design is probably better<br>
<emilio> ... but if we use a color can we pick a good one?<br>
<Rossen_> ack schenney<br>
<emilio> myles: how do we know to pick a good or bad color?<br>
<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<br>
<fremy> @florian, use the mike :P<br>
<emilio> florian: agreed, color should just do nothing for those text-decoration-style values<br>
<Rossen_> ack<br>
<Rossen_> q<br>
<Rossen_> ack *<br>
<Rossen_> ack florian<br>
<Rossen_> ack emilio<br>
<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<br>
<bramus> florian: yes, that is allowed<br>
<florian> qq+<br>
<GameMaker> q+<br>
<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?<br>
<Rossen_> ack florian<br>
<Zakim> florian, you wanted to react to emilio<br>
<bramus> florian: UA is allowed to but not required<br>
<bramus> emilio: is myles fine with that? or should we say text deco color explicitly has no effect?<br>
<schenney> q+<br>
<emilio> ack GameMaker<br>
<Rossen_> ack GameMaker<br>
<emilio> GameMaker: with our current grammar error is blue dots, is that ok?<br>
<emilio> fantasai: yes<br>
<nicole> q+<br>
<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?<br>
<Rossen_> ack fantasai<br>
<emilio> florian: that's what the spec says right now<br>
<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<br>
<emilio> ... let's say mozilla implements it and allows it, then firefox and chrome do that<br>
<emilio> ... they put something on a blue background and use text-decoration-color: orange<br>
<florian> q+<br>
<emilio> ... then safari users get blue on blue<br>
<Rossen_> ack schenney<br>
<emilio> ... not sure that's worth locking it down more or not<br>
<emilio> schenney: curious, say chromium on mac wanted to match the macOS platform<br>
<emilio> ... we could have a system color and we'd be ok not defining that color<br>
<emilio> fantasai: if we're going to honor the color automatically but not all the time then we need a keyword to distinguish<br>
<emilio> q+<br>
<ntim> q+<br>
<emilio> nicole: it seems something where what's good for the user might be different from what's good for the developer<br>
<emilio> ... user probably wants to match the OS<br>
<Rossen_> ack nicole<br>
<emilio> ... then there's a developer need<br>
<emilio> ... to change it if needed<br>
<bramus> q+<br>
<Rossen_> ack florian<br>
<emilio> ... is that the case? if so it might be worth doing something like with accent-color<br>
<emilio> florian: going back to fantasai's example, that's one case where it might be needed to break the convention<br>
<emilio> ... if the apple folks have blue dots, they need to deal with blue backgrounds in some way<br>
<hober> q?<br>
<emilio> nicole: I'm thinking something about grammarly when they might have more sophisticated than what browsers provide<br>
<emilio> florian: but they can either pick the default platform style, but changing text-decoration-style is already available<br>
<emilio> hober: the grammarly case is handled by customizing it<br>
<schenney> q+<br>
<bramus> q-<br>
<Rossen_> ack fantasai<br>
<Zakim> fantasai, you wanted to react to florian<br>
<emilio> fantasai: yeah grammarly could use the default grammar style<br>
<emilio> ... or they could change the style<br>
<emilio> nicole: so authors can't opt into the ua style?<br>
<emilio> myles: they can, but they either get all of the magic or none of the magic<br>
<Rossen_> q?<br>
<emilio> ... we object to a middle ground where you get some of the magic<br>
<emilio> florian: the other thing is you can also select based on the element to opt in or out of the native style<br>
<emilio> nicole: how would they do it if you want to ensure contrast?<br>
<emilio> florian: if you know the background you can get the color<br>
<emilio> ... otherwise you set the background style to the UA and hope the UA does a good job at it<br>
<Rossen_> ack emilio<br>
<emilio> Rossen_: the problem nicole is describing is a lot more general<br>
<bramus> emilio: the current spec seems fine. but we need to be careful with compat. Also see what fantasai said a while ago.<br>
<bramus> … the defualt sstyle should work on any bg<br>
<bramus> … if images need a different order; thats how native outlines work as well.<br>
<emilio> ntim: I think it'd make sense to behave like outline-style: auto where the color is ignored<br>
<bramus> emilio: the point is that there are browsers that can customize. e.g/ firefox uses AccentColor for the native outline-style<br>
<Rossen_> ack ntim<br>
<bramus> myles: I dont understand<br>
<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<br>
<florian> qq+<br>
<bramus> … right now they are allowed. q is should we restrict it<br>
<bramus> … some browsersa llow to change the color, some dont<br>
<bramus> … the ones that allow it do it in different ways<br>
<bramus> …. are we fine with that? more grammar styles or not?<br>
<bramus> ntim: (missed)<br>
<bramus> emilio: in firefox we allow you to customize the AccentColor, but default it is the OS one<br>
<astearns> s/(missed)/outline-color does not change the color of the built-in outline<br>
<astearns> (I think)<br>
<bramus> ntim: I guess speellin-error ang rammer-error would be up to the ua<br>
<bramus> … maybe that’s all up to them?<br>
<bramus> emilio: that is the q<br>
<bramus> ntim: (missed2)<br>
<emilio> ntim: I think customizing it via text-decoration-color would be a mistake<br>
<Rossen_> q?<br>
<Rossen_> ack florian<br>
<Zakim> florian, you wanted to react to ntim<br>
<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"<br>
<emilio> ... and it seems answer is no<br>
<emilio> schenney: I was hoping to propose a resolution<br>
<emilio> ... q is "should the browser and the author agree and define custom grammar markers"<br>
<emilio> ... seems like we want the UA to allow any current color<br>
<Rossen_> ack schenney<br>
<bramus> emilio: no<br>
<Rossen_> ack florian<br>
<Rossen_> ack fantasai<br>
<emilio> fantasai: we're looking at several options<br>
<emilio> ... (1) no spec change, ua may interpret text-decoration-line: grammar-error using the system pattern and color<br>
<emilio> ... but they can honor text-decoration-color<br>
<emilio> ... if you are a UA that doesn't want to allow customization you ignore all t-d props<br>
<emilio> ... but otherwise is when the author has set a color you honor<br>
<emilio> ... the q is what is "when the author has set a color"<br>
<emilio> ... t-d-c: currentColor? Something else?<br>
<emilio> ... that's not clear<br>
<emilio> ... So we can say t-d-c doesn't affect t-d-s: grammar-error<br>
<emilio> ... or we say t-d-c allow t-d-c but provide a magic t-d-c: auto or something<br>
<florian> q+<br>
<schenney> q+<br>
<emilio> ... third option is introducing new system colors<br>
<emilio> ... doesn't seem we're going with that<br>
<emilio> q+<br>
<emilio> fantasai: but we should pick between the other two options<br>
<ntim> I'm in favor of "Don't allow text-decoration-color to affect spelling/grammar errors."<br>
<Rossen_> ack florian<br>
<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<br>
<emilio> ... so adding a normal/auto initial kw for t-d-c<br>
<emilio> ... sounds useful<br>
<emilio> fantasai: right but we want to go to the question of "do we want to allow that"<br>
<Rossen_> ack schenney<br>
<emilio> schenney: I think authors would be confused at not being able to specify the color<br>
<emilio> fantasai: but they can't<br>
<emilio> schenney: if you specify ::grammar-error {}<br>
<ntim> q+<br>
<emilio> fantasai: ::grammar-error {} has text-decoration-style: grammar-error, but I can also style it on an `<u>` element<br>
<emilio> ... and then I'd get that style<br>
<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<br>
<emilio> ... but if I do `u { text-decoration: grammar-error; text-decoration-color: pink }`<br>
<emilio> ... do I get a pink styling<br>
<Rossen_> q?<br>
<astearns> my vote is to disallow UA-provided decorations to respond to CSS property values<br>
<emilio> ... so if we allow it to be influenced by text-decoration-color we need something to differentiate<br>
<emilio> schenney: I see in that case I'd vote to disallow t-d-c to influence t-d-s: grammar-error<br>
<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.<br>
<bramus> … seems we are arriving to consensus of not allowing tdc to influence it<br>
<Rossen_> ack emilio<br>
<Rossen_> ack ntim<br>
<bramus> ntim: I agree with not allowing<br>
<florian> Option 1: disallow taking the color into account<br>
<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.<br>
<emilio> option3: Use the same UA magic for appearance and borders/backgrounds<br>
<ntim> +1 to that<br>
<schenney> +1<br>
<emilio> fantasai: proposal is for native text decorations none of the other t-d properties apply<br>
<bramus> emilio: do we wan tto do color or also offsets and stuff?<br>
<bramus> florian: nothing<br>
<bramus> s/florian/fantasai<br>
<emilio> s/florian:/fantasai:<br>
<emilio> RESOLVED: other text decoration properties don't apply when native text-decoration-styles are in effect<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7522#issuecomment-1642501444 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 July 2023 17:46:25 UTC