[css-pseudo-4] Original color of highlight pseudo inside ::first-letter/::first-line #4625
Labels
Closed Accepted by CSSWG Resolution
css-pseudo-4
Current Work
Tested
Memory aid - issue has WPT tests
Comments
|
I think it's preferable to take the color from the ::first-letter/line pseudo, for both regular selections and spelling highlights. Same for generated content pseudos, if a browser supports selecting in those. |
|
The CSS Working Group just discussed
The full IRC log of that discussion<dael> Topic: [css-pseudo-4] Original color of highlight pseudo inside ::first-letter/::first-line<dael> github: https://github.com//issues/4625 <dael> fantasai: Currently spec if author spec background color and no color we use color of originating element <dael> fantasai: With ::first-letter/::first-line it will cause it to change color b/c look at paragraph. Would be weird for spelling or grammar error. <dael> fantasai: Do we make it look up ::first-letter/::first-line color or is that difficult? <dael> TabAtkins: While I'm inclined to think it's complicated but heycam thought it was fine so sure. I think it's reasonable <dael> astearns: Other impl feedback? <dael> astearns: Prop? <dael> fantasai: Use the color of the text prior to applying the highlight <dael> fantasai: Whatever highlight being applied uses colors from before even if came from pseudo element like ::first-letter/::first-line <dael> astearns: Any other pseudo elements effected? <dael> fantasai: Not sure, possible ::before or ::after <dael> fantasai: POint is make it clear if there's a pseudo element changing the color we use that color not the document element <dael> astearns: Objections? <dael> RESOLVED: Whatever highlight being applied uses colors from before even if came from pseudo element like ::first-letter/::first-line <dael> fantasai: One note is currentColor keyword we'll have to make it resolve to a value for purpose of gCS. Will need to represent multiple colors <dael> florian: Why? <dael> fantasai: If you have a selection...we attach selections to an element not ::first-letter/::first-line. Could change the model <dael> florian: I see <dael> fantasai: That's going to be interesting <dael> florian: Yeah. For ::before/::after it's not a problem, but weird for ::first-letter/::first-line <dael> fantasai: I'll try and spec it out. It will be complicated <dael> tantek: Impact on impl with change? <dael> fantasai: No one impl this right now. Would all have to change <dael> chrishtr: Backwards compat? <dael> fantasai: No one does this. It's difficult to impl I think. That's why I raised it <dael> chrishtr: Good to have things not difficult to impl <dael> fantasai: But good to have good behavior too. I can spec it <dael> TabAtkins: I had same feeling as you but heycam thought it most reasonable to do. Since he doesn't think impl overrides correct behavior I decided to trust him <dael> smfr: Is it to accept heycam proposal? <dael> TabAtkins: Accept fantasai proposal <dael> astearns: heycam was agreeing this is righ behavior to spec. We'll try and spec and get impl experience to say if it's reasonable. We can back out if too complicated to impl <dael> tantek: I was revieing GH and saw fantasai question what to do. I didn't see the proposal. <dael> fantasai: I need to write a proposal. Not worth it if no one wants to do it <dael> tantek: Looks like heycam had a proposal <dael> fantasai: There's two possibilities at a high level and heycam said this one <dael> tantek: That's what we resolved on? <dael> fantasai: Yes <dael> myles: Why hard to impl? <dael> fantasai: Highlight is attached to element in dob not firstline. So you can have a highlight span and have to look up different colors depending on if you're first line even if same element. You have to paint with different colors and have currentColor with presumably multiple colors. <dael> fantasai: I don't know how machinery will work; needs substantial changes to make it work. We'll have to see what happens and how impl shake out <bradk> s/dob/doc <dael> myles: My intuition is this wouldn't be difficult. In MacOS we draw highlight per element so it's just an if for us. iOS is different. I don't think would be hard <fantasai> s/needs substantial/per-element ::selection needs substantial/ <dael> fantasai: Okay <myles> s/wouldn't be difficult/wouldn't be difficult to implement/ <dael> florian: Clarification we resolved on high level principle and fantasai you're going to worry about how to do currentColor later. <dael> fantasai: Yep <dael> astearns: Next step if fantasai spec this out. Anyone with enough concern that it's a waste of time for her to work on this? <dael> astearns: THen we'll let resolution stand |
|
Update: I followed up with some other Chromium engineers and we concluded it wouldn't be too hard to implement this resolution. |
|
New tests based on this resolution: active selection, Reference file: active selection, Reference file: |
fantasai
added a commit
that referenced
this issue
Sep 11, 2020
…d come from ::first-line etc. #4625
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, if an author specifies a background color for selection highlights but does not specify a
color, we use the color of the originating element.This gets really interesting in the presence of ::first-letter or ::first-line... basically, highlighting the text changes its color, because it's now looking up the color of the paragraph element instead of the ::first-letter or ::first-line element.
Probably this behavior would be OK in the case of selections, but it's probably quite unexpected if we're handling ::spelling-error or ::grammar-error. It would mean that a spelling error in the first line would end up with the paragraph text color even if the rest of the line has its own color.
What do we want to do about this?
Issue found via @TalbotG’s proposed test active-selection-027 in web-platform-tests/wpt#20028 see testcase
The text was updated successfully, but these errors were encountered: