Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-pseudo] questions about text decorations on highlight pseudos #6022

Closed
delan opened this issue Feb 19, 2021 · 13 comments
Closed

[css-pseudo] questions about text decorations on highlight pseudos #6022

delan opened this issue Feb 19, 2021 · 13 comments

Comments

@delan
Copy link
Contributor

delan commented Feb 19, 2021

https://drafts.csswg.org/css-pseudo-4/#highlight-text

Given the following content, with both the ::selection and ::target-text highlights marked {between the braces}:

<span class="foo">before {foo</span>
<span class="bar">bar} after</span>
.foo, .bar { text-decoration: yellow solid line-through; }
::target-text /* :root or *, doesn’t matter */ { background-color: orange; }
::selection /* :root or *, doesn’t matter */ { background-color: green; }
.foo::selection { color: cyan; text-decoration-color: magenta; /* no text-decoration-line */ }
.bar::target-text { color: xxx; text-decoration: red dotted line-through; }
.bar::selection { color: yyy; text-decoration: blue wavy line-through; }
  1. What should be painted at “foo” and in what order (topmost last)?
    • a) yellow solid, orange, green, cyan “foo”
    • b) orange, green, cyan “foo”
    • c) orange, green, cyan “foo”, yellow solid
    • d) orange, green, cyan “foo”, cyan solid
    • e) orange, green, cyan “foo”, magenta solid
    • f) something else?
  2. What should be painted at “bar” and in what order (topmost last)?
    • a) yellow solid, orange, red dotted, green, yyy “bar”, blue wavy
    • b) orange, red dotted, green, yyy “bar”, blue wavy
    • c) orange, green, yyy “bar”, yellow solid, red dotted, blue wavy
    • d) orange, green, yyy “bar”, yyy solid, red dotted, blue wavy
    • e) orange, green, yyy “bar”, yyy solid, yyy dotted, blue wavy
    • f) something else?

See also: resolution and edits, and my two follow-up questions, and their resolution.

I thought the answer was 1=b 2=b at first, so that’s how I wrote the ref for css/css-pseudo/highlight-painting-003.html (permalink), but after reading the spec and more closely, I’m starting to think it’s 1=d 2=d?

I’ve included 1=e above because I stumbled upon this Chromium patch (bug 1110393) today, which changes the color of originating element decorations to the ::selection’s text-decoration-color where that highlight is active. I suppose that change was a mistake or from before the current spec, because it sounds like it’s compliant when (and only when) text-decoration-color is currentColor?

Either way, I feel like we can improve the clarity of this section, given that I’m so unsure of the expected behaviour for scenarios like these. For example, there are several instances of “its” and “their” that could be more explicit, and some non-normative examples would be nice.

(cc @frivoal + @mrego)

@delan delan changed the title [css-pseudo] questions about text-decoration properties on highlight pseudos [css-pseudo] questions about text decorations on highlight pseudos Feb 19, 2021
@delan
Copy link
Contributor Author

delan commented Feb 19, 2021

(heads up: i’m going on leave shortly, so i probably won’t reply until i’m back around 7 march)

@mrego mrego added the css-pseudo-4 Current Work label Feb 19, 2021
@fantasai
Copy link
Collaborator

fantasai commented Mar 16, 2021

Afaict, the drawing order is:

.foo -
cyan solid line-through (base text decoration color overridden by highlight 'color')
cyan text (base text color overridden by highlight 'color')
green background (background introduced by ::selection)
orange background (background introduced by ::target-text)

.bar -
blue wavy line-through (decoration introduced by .bar::selection)
red dotted line-through (decoration introduced by .bar::target-text)
yyy solid line-through (base text decoration color overridden by highlight 'color')
yyy text (base text color overridden by highlight 'color')
green background (background introduced by ::selection)
orange background (background introduced by ::target-text)

@frivoal
Copy link
Collaborator

frivoal commented Mar 16, 2021

So that's indeed 1=d and 2=d. The spec is probably not ambiguous about it, but not 100% obvious either. We should make some edits to make that clearer. Coming soon…

@fantasai
Copy link
Collaborator

@delan OK, checked in edits to clarify. Let me know if it's acceptable yet. :)

@delan
Copy link
Contributor Author

delan commented Mar 16, 2021

Thanks @fantasai + @frivoal! Those edits are a good start, though I can see a few more opportunities for clarification.

We might want to somehow clarify that #highlight-text applies to all other decorations in the broader css-text-decor sense — including emphasis marks, but excluding shadows — in the normative text (in addition to the parenthetical in the note).

To prevent a misunderstanding like 1=a 2=a, we might also want to add an informative note like the following:

Unlike shadows, other text decorations won’t be obscured by any highlight overlay backgrounds that are drawn for the associated text.

I used line-through in my original examples to simplify them, but that left me with two questions:

  1. Are underlines and overlines introduced by the highlight pseudos painted under the associated text (like they would be if they were original decorations)?
  2. Are decoration paints ordered by decoration type then by highlight pseudo (original, …, ::target-text, ::selection), rather than “grouped” by highlight pseudo?

For example (topmost last):

  • a) original underline / text / original strike-through / ::target-text overline / ::target-text strike-through / ::selection underline (1=no, 2=no)
  • b) original underline / text / original strike-through / ::selection underline / ::target-text overline / ::target-text strike-through (1=no, 2=yes)
  • c) original underline / ::target-text overline / ::selection underline / text / original strike-through / ::target-text strike-through (1=yes, 2=no)
  • d) original underline / ::selection underline / ::target-text overline / text / original strike-through / ::target-text strike-through (1=yes, 2=yes)

@delan
Copy link
Contributor Author

delan commented Mar 31, 2021

Just following up on this (@frivoal + @fantasai), any updates? Once those two questions are answered, I can align highlight-painting-003.html with the spec.

@fantasai
Copy link
Collaborator

fantasai commented Apr 2, 2021

  1. Yes, the order of decorations and text with respect to each other should remain the same as it is normally.
  2. Good question. I'm thinking yes, otherwise the strike-throughs won't be drawn over the text. For selection in particular there might be some complications on the implementation side, though.

Let me run this past the CSSWG. Proposed behavior is d), following z-index ordering defined in https://www.w3.org/TR/CSS2/zindex.html#each-box

@delan
Copy link
Contributor Author

delan commented Apr 2, 2021

Thanks @fantasai!

[…], otherwise the strike-throughs won't be drawn over the text.

For what it’s worth, I think all four options above would yield strike-throughs drawn over text ((a) and (b) lift some underlines and overlines atop text, while (a) and (c) reorder decorations without any of them swapping sides), but maybe I’ve missed something. Either way, looking forward to the outcome!

@astearns astearns added this to the APAC VF2F-2021-04-08 milestone Apr 2, 2021
@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed questions about text decorations on highlight pseudos, and agreed to the following:

  • RESOLVED: Text decos of highlight pseudos sort *outermost* by deco category (per CSS2) then by highlight type. ::selection has an out to allow it to paint on top of everything else.
The full IRC log of that discussion <Rossen_> Topic: questions about text decorations on highlight pseudos
<Rossen_> github: https://github.com//issues/6022
<TabAtkins> fantasai: This is about painting order of text decorations on ::highlight pseudos
<TabAtkins> fantasai: There is a stacking order fo the highlights
<TabAtkins> fantasai: Original text is bottom layer, and things stacked above that: spellcheck, grammar check, target text, selection, something like that
<TabAtkins> fantasai: defined in spec
<TabAtkins> fantasai: When you draw text, text and decorations are also layered spearately: overline, underline, text, strikethru, so over/under are below text and strikethru is above
<TabAtkins> fantasai: so what's the interaction between these two stacking orders
<TabAtkins> fantasai: the proposal is that you maintain the same order between over/under, text, and strikethrus
<TabAtkins> fantasai: highlight pseudos are defined by only the topmost pseudo painting the text, so it's not painted multiple times; in that topmost layer's color
<TabAtkins> fantasai: but over/under/etc stack
<TabAtkins> fantasai: If you have spelling, grammar error and are highlighting, you'll see all the different underlines
<TabAtkins> fantasai: Suggestion is that we do all the underlines in z-index order, then overlines, then the topmost text, then all the strikethrus
<TabAtkins> fantasai: So CSS2 ordering is the "outer" ordering
<TabAtkins> fantasai: This makes strikethru always on top, regardless of where it's from.
<TabAtkins> fantasai: thoughts?
<Rossen_> q?
<TabAtkins> TabAtkins: sounds reasonable to me, ignoring implementation
<TabAtkins> dholbert: Do you know how browsers currently do?
<TabAtkins> fantasai: i haven't tested who supports the various new highlight pseudos yet.
<TabAtkins> fantasai: I know there is some weird behavior wrt text decorations...
<TabAtkins> smfr: can you give the ordering again?
<TabAtkins> fantasai: custom highlights are between text and built-in higlights, with selection on top
<TabAtkins> fantasai: under/overlines defined by non-selection highlights will interleave
<TabAtkins> fantasai: So proposal is all the underlines, then all underlines, then the text (only once), then all the strikethrus on top.
<TabAtkins> fantasai: I think this generally makes sense; selection has some trickiness on some platforms that i'm not sure about
<TabAtkins> TabAtkins: I know iOS has a special ordering for ::selection, but not sure if they do text decorations there
<TabAtkins> smfr: No, ::selection is drawn on top of the text, and doesn't allow text deco
<TabAtkins> fantasai: [gives example, i missed some early bits]
<TabAtkins> i dm'd tantek the ur4l
<TabAtkins> smfr: So is is true that custom highlights can contribue text decos? And they're sorted in that order with the built-ins?
<TabAtkins> fantasai: yes
<TabAtkins> smfr: Okay, now I understand
<TabAtkins> fantasai: So we could draw the text decors for the lower layers below the text, and draw the text decos for higher layers above the text
<TabAtkins> fantasai: problem is that strikethru on lower layers would be below the text
<TabAtkins> fantasai: maybe that's what we want, i dunno
<chrishtr> q+
<TabAtkins> TabAtkins: I think the fact taht any arbitrary layer can co-opt the text painting role means that having the underlayers draw their strikethrus under the text when necessary is a bad thing; it's not easy to predict what layer will actually draw the text. So we should do the full grouping instead
<Rossen_> ack chrishtr
<TabAtkins> smfr: Okay, as long as ::selection is on top, it's fine for us - the rest can sort their decorations together
<TabAtkins> chrishtr: before we resolve, i'd like to have the proposed resolution be written down and tested on impls, so i can double check that there aren't issues
<TabAtkins> chrishtr: no interop or complexity issues
<TabAtkins> fantasai: The person who raise dthe issue is implementing in Chrome
<Rossen_> ack fantasai
<TabAtkins> fantasai: I wanna be clear, smfr, that the strikethrus of a custom highlight can paint atop a selection
<TabAtkins> fantasai: What we could do is special-case ::selection and say that, *aside* from that, everything sorts as described, but ::selection text/etc can paint in a single layer on top of everything else
<TabAtkins> fantasai: The point that Tab brought up - that the existence of another custom highligh shouldn't cause a previous custom highlight to have its strikethru go below - is correct, but due to the nature of ::selection, that's probably fine.
<TabAtkins> fantasai: So like if spelling error used a strikethru, that shoudl paint over the text
<TabAtkins> fantasai: If you have ::text-target as well, we don't want this to cause the spellcheck strikethru to go under the text
<TabAtkins> fantasai: But if you select the text, and we say that it causes the text to come to the forefront and paint over the decos, I think taht's reasonable behavior and would solve your concerns on iOS.
<TabAtkins> smfr: We don't paint the text itslef on that top layer, but just the 'blue wash' the highlights it. I'm fine with reordering the decos, as long as the user selection is atop everything else
<TabAtkins> fantasai: So if you specify ::selection { color: yellow; background: blue; }, waht happens?
<TabAtkins> smfr: Text will be yellow, don't know if we support the background
<TabAtkins> GameMaker: Let me check...
<Rossen_> q?
<TabAtkins> florian: So you'e proposing we *allow* ::selection to be on top, or *require* it?
<TabAtkins> fantasai: I can go either way. I think ::selection overpainting isn't unreasonable.
<fantasai> s/overpainting/overpainting all lower-level text decorations/
<TabAtkins> florian: The iOS thing doesn't seem to be *only* on top, it just works differently than the other highlight pseudos. Background isn't 'background', it's a magic transluscent thing, etc.
<TabAtkins> smfr: Yes, it's special
<TabAtkins> GameMaker: We already do something special with making even user colors slightly transluscent
<TabAtkins> GameMaker: It doesnt' affect text, but if you ahve a red background and yellow selection, it'll be a little transluscent [and look a little orange] - it's not solid color
<TabAtkins> fantasai: Cool, we have another issue on that. So do you paint that transluscent bg over the text?
<TabAtkins> GameMaker: Yes.
<TabAtkins> fantasai: So you can't have yellow text if you have a blue bg, it'll always be a little green?
<TabAtkins> GameMaker: Yes, but it's a subtle effect, not as green an effect as you think.
<TabAtkins> florian: So based on this I suggest we *allow* ::selection to be painted atop - don't need to clone iOS.
<TabAtkins> fantasai: I'm fine with that.
<TabAtkins> fantasai: Proposal is that the "outer" ordering is CSS2 ordering - what type of deco it is.
<TabAtkins> fantasai: "Inner" sort is what type of highlight you hae.
<TabAtkins> fantasai: And as an option, the impl *may* paint all the aspects of the ::selection as a topmost layer above the rest.
<TabAtkins> Rossen_: Objections?
<fantasai> fantasai: let's handle background in a separate issue though
<TabAtkins> chrishtr: I'd just like to have some time to review
<TabAtkins> [chatter about this being provisional for review or what]
<TabAtkins> RESOLVED: Text decos of highlight pseudos sort *outermost* by deco category (per CSS2) then by highlight type. ::selection has an out to allow it to paint on top of everything else.

@fantasai
Copy link
Collaborator

fantasai commented Apr 8, 2021

So for clarity, we resolved on the UA having the choice of:

  • d) original underline / ::selection underline / ::target-text overline / ::selection text / original strike-through / ::target-text strike-through (1=yes, 2=yes)
  • e) original underline / ::target-text overline / original strike-through / ::target-text strike-through / ::selection underline / ::selection text

@fantasai
Copy link
Collaborator

Edited in. @delan would you mind reviewing, and if it looks good to you, close out the issue? :)

@delan
Copy link
Contributor Author

delan commented Dec 30, 2021 via email

@delan
Copy link
Contributor Author

delan commented Jan 5, 2022

@fantasai thanks again for the edits! I’ve proposed some minor tweaks in #6666, but otherwise I’m happy with the new text.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants