-
Notifications
You must be signed in to change notification settings - Fork 671
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
Comments
(heads up: i’m going on leave shortly, so i probably won’t reply until i’m back around 7 march) |
Afaict, the drawing order is: .foo - .bar - |
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… |
@delan OK, checked in edits to clarify. Let me know if it's acceptable yet. :) |
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:
I used line-through in my original examples to simplify them, but that left me with two questions:
For example (topmost last):
|
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. |
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 |
Thanks @fantasai!
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! |
The CSS Working Group just discussed
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. |
So for clarity, we resolved on the UA having the choice of:
|
…llow ::selection stacked at the top. #6022
Edited in. @delan would you mind reviewing, and if it looks good to you, close out the issue? :) |
Thanks! I’m on leave until 4 January, but I’ll take a look once I’m back.
… On 30 Dec 2021, at 16:31, fantasai ***@***.***> wrote:
Edited in. @delan would you mind reviewing, and if it looks good to you, close out the issue? :)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you were mentioned.
|
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}:
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)
The text was updated successfully, but these errors were encountered: