[css-pseudo] highlight pseudos and emphasis/underline properties · Issue #7101 · w3c/csswg-drafts · GitHub
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] highlight pseudos and emphasis/underline properties #7101

Closed
delan opened this issue Mar 4, 2022 · 11 comments
Closed

[css-pseudo] highlight pseudos and emphasis/underline properties #7101

delan opened this issue Mar 4, 2022 · 11 comments
Labels
Closed Accepted by CSSWG Resolution css-pseudo-4 Current Work i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response.

Comments

@delan
Copy link
Contributor

delan commented Mar 4, 2022

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

The following properties apply to the highlight pseudo-elements:

The current spec text could be interpreted as only allowing ‘text-decoration’ and ‘text-decoration-*’ and ‘text-shadow’, which would include line decorations and text shadows, but not emphasis marks or ‘text-underline-position’ or ‘text-underline-offset’. Should we somehow allow those properties more explicitly?

(@fantasai, @frivoal, @mrego)

@delan delan added the css-pseudo-4 Current Work label Mar 4, 2022
@delan delan changed the title [css-pseudo] highlight pseudos and emphasis marks (and underline properties) [css-pseudo] highlight pseudos and emphasis/underline properties Mar 4, 2022
@mrego
Copy link
Member

mrego commented Apr 1, 2022

There's also text-emphasis-color (as other text-emphasis properties seem to affect the layout I guess they're not valid for highlight pseudos).

Doing some tests, Chrome and WebKit allows you to change text-emphasis-color in ::selection, but Firefox doesn't allow it.

However only Chrome allows to change text-decoration-color in ::selection, but Firefox and WebKit do not.

@delan
Copy link
Contributor Author

delan commented Apr 4, 2022

@mrego not sure about emphasis marks, but note that ‘text-decoration-color’ on ::selection is only for decorations added by ::selection, and originating decorations are recolored to ‘color’ (test, ref). Blink is incorrect to allow the property to change the color of originating decorations, and Firefox doesn’t yet support highlight decorations at all.

@fantasai
Copy link
Collaborator

fantasai commented Apr 19, 2022

Clarifying that text-underline* applies is good, and adding text-emphasis-color makes sense, but I'm a little hesitant about text-emphasis itself. Unlike text decorations, emphasis dots don't overlay each other, it's just a straight-up inherited property. So there'd be some conflict between text-emphasis: none removing dots vs not doing anything. Also they can impact layout. So I don't think we can add anything other than text-emphasis-color itself here.

@fantasai fantasai added i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. Agenda+ labels Apr 19, 2022
@mrego
Copy link
Member

mrego commented Apr 20, 2022

Yeah I agree with @fantasai. I don't think text-emphasis in general can be applied on highlights due to the layout changes it implies, text-emphasis-color should be fine though.

@delan
Copy link
Contributor Author

delan commented Apr 20, 2022

Makes sense! I’ve updated #7222, pending discussion in the meeting.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-pseudo] highlight pseudos and emphasis/underline properties, and agreed to the following:

  • RESOLVED: Accept the proposed PR
The full IRC log of that discussion <emeyer> Topic: [css-pseudo] highlight pseudos and emphasis/underline properties
<emeyer> Github: https://github.com//issues/7101
<emeyer> delan: Highlight pseudos have a restricted subset of applicable properties. Not all properties in the text-decoration spec start with text-decoration-*. Question originally was, can we add those and make them applicable. I initially thought we should. fantasai and rego have mentioned most of the text-emphasis-* properties shouldn’t be applicable.
<emeyer> …Maybe only text-emphasis-color should be applied. That’s where we are now.
<emeyer> astearns: I’m a little worried that the proposed patch is still a little vague. Should we be very specific about what can be applied?
<emeyer> fantasai: I don’t think we should be very specific, because as more things are added elsewhere, user agents should be free to add them here. I think the proposed wording is good enough for now.
<tantek> +1 fantasai
<smfr> q+
<emeyer> delan: In general, we’re happy with all the properties related to line decorations being applicable?
<emeyer> fantasai: Right.
<emeyer> delan: So it’s the emphasis marks that are contentious.
<astearns> ack smfr
<emeyer> smfr: Are we avoiding properties that can cause ink or layout overflow?
<emeyer> delan: Ink overflow yes, layout overflow no.
<emeyer> fantasai: Ink overflow doesn’t trigger scrollbars. We want to avoid anything that could cause scrollbars.
<emeyer> delan: So actually ink overflow no, layout overflow yes. Sorry, got those backwards.
<emeyer> astearns: Ink overflow is okay, layout overflow is not okay. We could have a note in the specification saying that’s how we determine the list of properties.
<emeyer> delan: We sort of do say that about the layout, but we could be more explicit about ink overflow.
<iank_> changes in layout overflow implicitly effects layout.
<emeyer> astearns: The bit we have about not affecting overflow layout is sufficient, I think.
<emeyer> RESOLVED: Accept the proposed PR
<fantasai> fwiw fwiw spec says “The highlight pseudo-elements can only be styled by a limited set of properties that do not affect layout and can be applied performantly in a highly dynamic environment—and additionally (to ensure interoperability) whose rendering within the required area is not dependent on the exact (UA-determined) bounds of the highlight overlay.”

@delan
Copy link
Contributor Author

delan commented Aug 18, 2022

Hmm… #highlight-text says:

The element’s own text decorations (both line decorations and emphasis marks) are thus drawn in the pseudo-element’s own color when that is not currentColor, regardless of their original color or fill specifications.

So if originating emphasis marks are recolored to the highlight ‘color’ just like line decorations, rather than using the highlight ‘text-emphasis-color’, and highlights can’t add their own emphasis marks with ‘text-emphasis-style’, then actually I think there’s no need for ‘text-emphasis-color’ on highlights. @fantasai, what do you think?

@fantasai
Copy link
Collaborator

@delan Allowing text-emphasis-color would have an effect: on existing emphasis marks in the text. Whether it's useful to allow that, I don't think it is particularly useful. :)

@delan
Copy link
Contributor Author

delan commented Sep 21, 2022

@fantasai how would it affect originating emphasis marks, given the following?

[…] Instead the topmost active highlight overlay redraws that text (and those decorations) over all the highlight overlay backgrounds using that highlight’s own color.

Note: The element’s own text decorations (both line decorations and emphasis marks) are thus drawn in the pseudo-element’s own color when that is not currentColor, regardless of their original color or fill specifications.

I also think originating emphasis marks get painted not because the highlight inherits ‘text-emphasis-style’, but because we say so in #highlight-painting. ‘text-emphasis-color’ has no effect when ‘text-emphasis-style’ is ‘none’, so by analogy, if we want it to have an effect when ‘text-emphasis-style’ is not applicable, we should probably say so explicitly.

@fantasai
Copy link
Collaborator

fantasai commented Oct 6, 2022

@delan We'd have to spec it so that the highlight's text-emphasis-color affects the highlighted emphasis marks, with currentColor referring to the highlight color.

The question is whether this is worth doing now, or just always using currentColor and ignoring text-emphasis-color; I think it's the sort of thing we could do later if we wanted to.

@delan
Copy link
Contributor Author

delan commented Oct 6, 2022

Yeah, that makes sense. I think we should ignore ‘text-emphasis-color’ for now, or even remove it from the list until we decide to spec that behaviour. I’ve updated #7222 to remove it, but let me know if we should leave it in and somehow say it’s ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closed Accepted by CSSWG Resolution css-pseudo-4 Current Work i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response.
Projects
None yet
Development

No branches or pull requests

4 participants