You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It occurred to me while thinking about #4579 that ::selection and ::inactive-selection are an example of two pseudo elements that target the same set of ranges.
To emulate this with custom highlights, we would currently have to do something like:
Here, active-selection-ranges and inactive-selection-ranges are Highlight objects. In order for inactive selection highlights to layer on top of active selection highlights, we can assign inactive-selection-ranges the higher priority of the two. Then, if our custom selection transitions from active to inactive, we could either add ranges from active-selection-ranges to inactive-selection-ranges - which is cumbersome - or we could use the inline style attribute to reverse the styles - which is ugly because active-selection-ranges will then have inactive styles.
If we could express priority on the ::highlight pseudo instead of the Highlight object, then we could do the following:
Now we can just have one Highlight object and we only need to modify its priority as we transition from one selection state to another. If the selection should start off active, we can start the active selection highlight at a higher priority, and once the selection becomes inactive, we can lower its priority below that of the inactive selection highlight.
The text was updated successfully, but these errors were encountered:
frivoal
changed the title
[css-highlight-api] Should priority be expressed on ::highlight instead of HighlightRangeGroup?
[css-highlight-api] Should priority be expressed on ::highlight instead of the Highlight object?
Dec 20, 2019
I don't think it's a good idea to change this invariant.
Imho the way declaration blocks are split into style rules is a tool for the author to organize the style sheet; we shouldn't try to turn it into a semantic concept.
Thinking about this some more, I agree. I think one pseudo element per unique pseudo element selector is an invariant as well. Assuming that is true, then what we have today is the right answer - separate Highlight objects for active and inactive selection. That would also indicate that the answer for the ::selection vs ::inactive-selection case (#4579) is also separate pseudos.
It occurred to me while thinking about #4579 that ::selection and ::inactive-selection are an example of two pseudo elements that target the same set of ranges.
To emulate this with custom highlights, we would currently have to do something like:
Here,
active-selection-ranges
andinactive-selection-ranges
are Highlight objects. In order for inactive selection highlights to layer on top of active selection highlights, we can assigninactive-selection-ranges
the higher priority of the two. Then, if our custom selection transitions from active to inactive, we could either add ranges fromactive-selection-ranges
toinactive-selection-ranges
- which is cumbersome - or we could use the inline style attribute to reverse the styles - which is ugly becauseactive-selection-ranges
will then have inactive styles.If we could express priority on the ::highlight pseudo instead of the Highlight object, then we could do the following:
Now we can just have one Highlight object and we only need to modify its priority as we transition from one selection state to another. If the selection should start off active, we can start the active selection highlight at a higher priority, and once the selection becomes inactive, we can lower its priority below that of the inactive selection highlight.
The text was updated successfully, but these errors were encountered: