Csswg-drafts: [css-pseudo-4]: How should a selected spelling error be painted?
Looking to understand https://drafts.csswg.org/css-pseudo/#highlight-painting. How should the following markup be painted when you select the entire contents of <p>:
<!DOCTYPE html>
<html>
<head>
<style>
body {
text-decoration: underline;
background-color: magenta;
}
p {
color: black;
background-color: white;
}
p::spelling-error {
color: red;
}
p::selection {
background-color: lightblue;
}
</style>
</head>
<body>
<p contenteditable="true">Select this entire sentence with the missspelled word.</p>
</body>
</html>
Should it paint as:
?
OR
?
dbates-wk
All 14 comments
CC @dbaron @fantasai @frivoal @smfr @litherum
dbates-wk
on 1 Jul 2018
I think the second picture is the correct one.
According to the spec:
The ::selection overlay is drawn over the ::spelling-error overlay which is drawn over the ::grammar-error overlay.
I think this means the spelling-error overlay has to be drawn first which will draw the text with red color. Then the selection highlight overlay should be drawn next which will fill the selection rectangle with lightblue color.
shallawa
on 2 Jul 2018
@grorg I don't see enough conversation to merit wg time just yet. Let's give others time to respond here first.
atanassov
on 24 Jul 2018
If ::selection is drawn over ::spelling-error, then the color of ::selection wins in case of a conflict. However, ::selection says that if a color isn't specified, but a background is, then we use the text’s own color. Which in this case is the spelling-error color. So I agree with @shallawa that the spelling-error would be red.
If ::selection had specified a 'color', though, it would be that color.
fantasai
on 28 Dec 2018
If ::selection is drawn over ::spelling-error, then the color of ::selection wins in case of a conflict. However, ::selection says that if a
colorisn't specified, but a background is, then we use the text’s own color. Which in this case is the spelling-error color. So I agree with @shallawa that the spelling-error would be red.If ::selection had specified a 'color', though, it would be that color.
Sounds reasonable to me.
dbates-wk
on 31 Dec 2018
I've clarified this in the spec. Let me know if it's still awkward or if you have any suggestions for improvement. :) It's a weird section. https://drafts.csswg.org/css-pseudo-4/#highlight-painting
fantasai
on 31 Dec 2018
Agenda+ to confirm with the WG that this is the behavior we want (I think it is) and to confirm that it's OK to use currentColor to represent this functionality.
fantasai
on 31 Dec 2018
The CSS Working Group just discussed Color of text / decorations.
The full IRC log of that discussion
<dael> Topic: Color of text / decorations
<dael> github: https://github.com/w3c/csswg-drafts/issues/2850
<dael> fantasai: As I was working on the model for this I figured it would be useful to have this defined
<dael> fantasai: I wanted to double check that hte WG thinks it's fine
<dael> AmeliaBR: A little concerned from agenda summary, but issue seems that it's coming out of cascade where ::Selection pseudo element gets broken to sep pieces for selection inside each element so selection inside an element with different color will have different currentColor. Is that correct?
<dael> fantasai: It would resolve to a single color, but just be a keyword. If your value is currentColor you don't paint over text decorations with another color.
<dael> AmeliaBR: Makes sense. Works if you think of it as many pseudo elements in sequence. Wording in agenda makes it sound that you can't set current color in pseudo selection itself.
<dael> fantasai: This is jsut for color property itself. currentColor anywhere else behaves as expected
<dael> AmeliaBR: So it goes with this works by inheritence.
<dael> fantasai: I should double check spec, but that's what it should say
<dael> astearns: Other comments?
<dael> daniel: I came in mid-way, but this was my issue. What was that about current color and inheritence?
<dael> fantasai: If you look at issue example there is text that's black and underline black and there's a red word in there. What I'm proposing is to clarify the behavior you expect that the red will continue to be red if ::selection isn't given a color.
<AmeliaBR> ::selection{ background: yellow} is treated as ::selection{background: yellow; color: currentColor}
<dael> fantasai: As I clarified it seemed ti would be straightword to have a keyword to refer to this which is currentColor. So I wanted to tie it explicitly rather then if you just don't have a value. That way they can spec the behavior
<dael> daniel: If you leave out the value...in this example selection leaves out color so it inherits from spelling error pseudo element
<dael> fantasai: Way cascading is spec the ::selection inherits from the parent ::selection not directly from the originating element or another pseudo element
<dael> daniel: with you on that. If everyone agrees result should be bottom example it seems like you have to inherit from pseudo elements until you fall back to originating
<dael> fantasai: Could say inherits from pseudo element, but could be confusing if you have overlapping pseudo elements that don't forma tree
<dael> daniel: Do you have a solution that achieves expected result?
<astearns> https://drafts.csswg.org/css-pseudo-4/#highlight-painting
<dael> fantasai: If you read current ED...let me pull
<fantasai> https://drafts.csswg.org/css-pseudo-4/#highlight-painting
<fantasai> the topmost active highlight overlay redraws that text (and its decorations) over the highlight overlay backgrounds (and outlines, if any) using its own color, with currentColor representing the color of the next highlight pseudo-element layer below, falling back finally to that of the originating element (the colors that would otherwise be used
<dael> florian: You're solving by having currentColor behave normally but at used time fetch the correct color
<dael> fantasai: Second paragraph
<dael> daniel: As long as the resolution gets the expected result I'll be happy
<dael> fantasai: That's the intention
<dael> daniel: I'm fine with that. If I have an issue witht he wording I'll file a spec issue.
<dael> fantasai: I would really like review on this section
<dael> daniel: I'm happy to do it offline. I'll send you an email and then you can tell me if we need to have a followup
<dael> astearns: It would be good to have this convo in the issue
<dael> daniel: I'll keep the issue updated
css-meeting-bot
on 10 Jan 2019
To recap/clarify comments from the telcon:
I may have been misunderstanding the currently specified model for inheritance and ::selection as defined in Pseudo 4.
I understood the behavior as treating a selection as a sequence of separate pseudo-elements, one inside each element (or other pseudo) it overlaps. Each of those partial selections would then inherit from the base styles for that span of text. A selector like p::selection selects all the partial selection pseudo-elements inside the p, rather than selecting one pseudoelement that then has spans or other pseudos inside it. em::selection selects the partial selections inside the em, as does p>em::selection but the latter one wins out because it's a more specific selector.
So for real markup:
<p>Unselected text selected text, <em>emphasized selected text, other emphasized text</em>.</p>
And a selection that covers "selected text, _emphasized selected text,_", you'd get an inheritance model of:
<p>Unselected text <::s>selected text, </::s><em><::s>emphasized selected text,</::s> other emphasized text</em>.</p>
If that is the model used, then color: currentColor describes the behavior @fantasai wants (each span of text inside the selection taking the color it would be without the selection).
This is because each of those partial selections would inherit a different color value, and color: currentColor uses the inherited value, as defined in CSS Color Level 3 (in the currentColor definition) or Level 4 (in the "resolving color values" section).
But, now that I re-read the "Cascading and Per-Element Highlight Styles", I'm starting to doubt whether my mental model includes all the details in the spec:
Each element draws its own active portions of the highlight overlays, which receives the styles specified by the corresponding highlight pseudo-element styles for which that element is the originating element. When multiple styles conflict, the winning style is determined by the cascade. When any supported property is not given a value by the cascade, it’s value is determined by inheritance from the corresponding highlight pseudo-element of its originating element’s parent element (regardless of whether that property is an inherited property).
Which is kind of hand-wavy language that doesn't match the normal inheritance rules, and never actually says that the highlight inherits from the local text span. So some additional hand-waving may still be required for currentColor.
AmeliaBR
on 10 Jan 2019
@AmeliaBR “and never actually says that the highlight inherits from the local text span” Right, it doesn't inherit from the local text span, at least not for color--it inherits from the parent ::selection. That's why I raised the issue of defining currentColor to refer to the color of the local text span.
fantasai
on 10 Jan 2019
Re-defining currentColor in terms of the local text span would solve this bug as well as other color-like properties for pseudo-element. But this does not solve how to compute property caret and property text-shadow with respect to overlapping highlights. The spec. has existing text for how ::first-letter works with ::first-line in section 2:
The ::first-letter pseudo-element is contained within any ::first-line pseudo-elements, and thus inherits from ::first-line.
Instead of re-defining currentColor can we solve this bug by adopting similar language for all the other highlights? Elaborating further can we describe the algorithm for computing the value of a highlight CSS property as cascade inheriting from the underlying highlight element up to the originating element. So, change the first paragraph of 3.4 to read:
[[
Each element draws its own active portions of the highlight overlays, which receives the styles specified by the corresponding highlight pseudo-element styles for which that element is the originating element. When multiple styles conflict, the winning style is determined by the cascade. When any supported property is not given a value by the cascade, it’s value is determined by inheritance from the next corresponding highlight pseudo-element layer of its originating element up to the originating element's parent element.
]]
(or something like this)
?
dbates-wk
on 16 Jan 2019
The CSS Working Group just discussed How should a selected spelling error be painted?.
The full IRC log of that discussion
<dael> Topic: How should a selected spelling error be painted?
<dael> github: https://github.com/w3c/csswg-drafts/issues/2850
<dael> Rossen_: fantasai or AmeliaBR can you summarize?
<dael> fantasai: Let's see where we're at
<dael> florian: I thought semi reviewed and waiting for additional feedback
<dael> fantasai: Yeah
<AmeliaBR> I'm not sure there's much more to discuss. Needs proposed text.
<dael> florian: I think agenda+ was left on rather then added
<dael> Rossen_: Bot didn't resolve?
<dbaron> the bot only removes agenda+ when there's a resolution, btw
<dael> Daniel: I had a chance to digest this. We described in terms of currentColor
<dael> Daniel: I wrote a comment, so to restate. currentColor would solve this and for all color properties, but not for caret and text shadow
<dael> Daniel: In 2.2 of the same spec we solved this for the first letter
<dael> fantasai: first letter is different kind of psuedo element. It inherits fundimentally through the tree. What we're doing for selection, a selection for a span inherits from the p, not the span. That has to happen for all the different properties that inherit
<dael> Daniel: I read 2.2 and how it's impl in webkit
<dael> fantasai: Webkit impl isn't like any other browser
<dael> Daniel: I like webkit where you cascade and then inherit
<dael> fantasai: The thing currently impl, if you have selections like <p>::selection and inside the p you have a span, you lose the selection over the span
<dael> Daniel:Currently in webkit?
<dael> fantasai: That's in every other browser
<dael> Daniel: That doesn't happen. I could be wrong, but in my memory of code that's not what happens. For the span...we do the cascade, find the parent with the section...right now we do the cascade
<fantasai> testcase his is some emphasized tex
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?<!DOCTYPE%20html>%0A<style>%0Ap%3A%3Aselection%20%7B%20background%3A%20green%3B%20%7D%0A<%2Fstyle>%0A<p>this%20is%20some%20<em>emphasized%20text<%2Fem>
<dael> Daniel: I would like what webkit does for first letter. It cascades first and then does inheritance against first line.
<dbaron> I don't know what you mean by "does the cascade" -- cascading what together?
<dael> Daniel: If you had some span that has a first letter and it's inside a parent with a first letter inside a parent with a first line, you cascade for first letter and inherit from cascade result of first line. THat's my interpretation of section 2.2
<dael> fantasai: 2.2 jsut changed
<dael> florian: The thing fantasai just pasted run in safari agrees with what fantasai stated about current behavior.
<fantasai> Cascading / inheritance model for ::selection was changed in https://github.com/w3c/csswg-drafts/issues/2474
<dael> florian: In the spec we're trying to get away from yest it's different then current, but current aren't useful. If you're trying to style ::selection applied to particular elements it breaks if they have children. That's why we want different model
<dael> Daniel: One thing; did fantasai post the example? I can explain. That's broken. I have a patch for webkit. WE only do it for first-letter and first-line. I'm saying why can't we make selection have same model as first-line
<dael> fantasai: That's a different issue, that's about fundimental inheritance and cascade for selection. That still is a thing that needs to be defined
<dael> Daniel: I filed this issue because I wanted to solve
<dael> fantasai: There is an issue where we're discussing in general. You can compare the model. One is cascade one is inheritance. Both are discussed and you can see both in spec. Cascade is in the TR and inheritance is in the ED
<dael> Daniel: I'll read it and comment on it
<dael> florian: To add one thing, the one on TR is what was previous and the new on is in the ED because we objected to doing it the cascade way
<dael> Daniel: Let me read through both and I'll discuss in github
<dael> Rossen_: Excellent. Thank you for chiming in.
css-meeting-bot
on 16 Jan 2019
dael> Daniel: One thing; did fantasai post the example? I can explain. That's broken. I have a patch for webkit. WE only do it for first-letter and first-line. I'm saying why can't we make selection have same model as first-line
The last sentence should read:
We only do it for first-letter and first-line. I'm saying why can't we make selection have same model as first-letter?
dbates-wk
on 16 Jan 2019
The CSS Working Group just discussed How should a selected spelling error be painted?, and agreed to the following:
RESOLVED: specify the current behavior and use the currentColor name
The full IRC log of that discussion
<dael> Topic: How should a selected spelling error be painted?
<dael> github: https://github.com/w3c/csswg-drafts/issues/2850#issuecomment-454870849
<dael> Rossen_: It's a level 4 quesiton
<dael> fantasai: I think this was about defining currentColor to represent color of the previous layer. You have the document which has colors for text and then spelling error and the selection layered on top. Proposal was use currentColor keyword to use the color. This seemed a neat way to represent that concept
<dael> fantasai: Given the way inheritance is working in the ::selection tree
<dael> florian[m]: Model makes sense to me. COncept of layers is that abstract way to desc or do impl work like that?
<dael> fantasai: Impl I do't know how they work, selection is only thing impl. Selection is painted over rest of doc. Text that spec how thigns is painted say it's painted over, but it's really in replacement of original text. If each pseudo element spec a color, only last will paint the text
<dael> fantasai: That's a sep question on how things are painted. THis is can we use currentColor to be the color I would otherwise be or do I need a new keyword?
<Rossen_> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/highlight/explainer.md
<dael> Rossen_: There was an explainer that I was told would be proposed and discussed soon ^
<dbaron> I'm a little worried this might be too clever...
<dael> Rossen_: You may or may not have gone through it. I'm raising awareness of something discussed in context of editing
<dael> Rossen_: This is being worked on more actively and there is some interaction with CSS for styling and handling of overlays and colors.
<dael> Rossen_: I was a little involved in the beginning so this proposal is at least in a sane state it's in currently. If fantasai you were looking for new words this could be a good primer to see if we can extract something
<dael> fantasai: This is about defining new layers. In the section linked from the explainer it's future custom pseudos. This isn't new layers of highlights. This is how to a rep in the CSS properties model the color for a highlight that's 'don't give me a color'. I think most striaghtforward is currentColor keyword.
<dael> fantasai: On color it says inherit from whatever I inherit from. That would be the ::selection's parent. We need to a way to say ::Selection doesn't have a color. WE can do magic and say you can't spec that, or we use this, or I invent a new word
<dael> florian[m]: Using currentColor makes sense. The thing from Rossen_ doesn't change that
<dael> dbaron: This is only doing something special for currentColo on the color property, not any other uses?
<dael> fantasai: Yeah b/c rest will refer to color property
<dael> dbaron: That makes it seem a little less scary
<dbaron> s/currentColo/currentColor/
<dael> Rossen_: Some support for currentColor
<dael> Rossen_: Objections to specify the current behavior and use the currentColor name?
<fantasai> Note to self: clarify dbaron's point
<dael> RESOLVED: specify the current behavior and use the currentColor name
<dael> florian[m]: I'm very interested in that explainer and I'll look into this. It's great that you're doing it it was on my to do list
<dael> Rossen_: Please do, this is getting traction.
<dael> Rossen_: Discussion is on WCG or Editing TF
<fantasai> This is why we have templates that define where the discussion happens
<dael> gregwhitworth: I think it's Editing TF
<dael> florian[m]: I'll look there
<dael> Rossen_: If you're really interested I can connect you with folks on our end. Shoot me an email
css-meeting-bot
on 30 Jan 2019
Related issues
gsnedders
·
3Comments
tylersticka
·
3Comments
fantasai
·
3Comments
AmeliaBR
·
3Comments
nigelmegitt
·
4Comments
Most helpful comment
If ::selection is drawn over ::spelling-error, then the color of ::selection wins in case of a conflict. However, ::selection says that if a
colorisn't specified, but a background is, then we use the text’s own color. Which in this case is the spelling-error color. So I agree with @shallawa that the spelling-error would be red.If ::selection had specified a 'color', though, it would be that color.