[go: nahoru, domu]
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.

Sign up for GitHub

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

Jump to bottom

[css-text-decor] Define how text-decoration-skip{,-ink} interacts with text-decoration #2817

Closed
upsuper opened this issue Jun 25, 2018 · 4 comments
Closed

[css-text-decor] Define how text-decoration-skip{,-ink} interacts with text-decoration #2817

upsuper opened this issue Jun 25, 2018 · 4 comments
Labels
Closed Accepted by CSSWG Resolution css-text-decor-4

Comments

@upsuper
Copy link
Member
upsuper commented Jun 25, 2018

text-decoration style properties are non-inherited (as they should), while text-decoration-skip and text-decoration-skip-ink are inherited (as they should as well).

They are all fine in themselves, but there would be a problem on how they should interact, or more specifically, should the "skip" behavior of a text decoration line come from the element where the text is in, or from the element where the decoration line is originated from?

For example, something like

<style>
div {
    text-decoration: underline;
    text-decoration-skip-ink: auto;
}
span {
    text-decoration-skip-ink: none;
}
</style>
<div>For <span>example</span></div>

should "example" have ink skipping?

Note that, current implementations of text-decoration-skip-ink (WebKit and Blink) don't support non-inherited text decoration, and thus they may not have this confusion at the moment. But since we want non-inherited text decoration, so it's worth making clear in the spec.
@kojiishi
Copy link
Contributor

I'm fine either way, which do you prefer?

We do (and IIUC WebKit too) implement the decorating-box concept but enable only when underline-position: under for a perf concern. We look forward to change the impl and enable it in all cases.

Even when it's enabled, while we match each decoration to the decorating box, we paint each decoration separately, so either option seems feasible.

@kojiishi
Copy link
Contributor

cc @litherum

@css-meeting-bot
Copy link
Member

The Working Group just discussed How text-decoration-skip/ink interact with text-decoration, and agreed to the following:

  • RESOLVED: ink-skipping is determined by the decoration originator, not descendant elements
  • RESOLVED: underline position is also determined by the decoration originator, not descendant elements
  • RESOLVED: underline offset is also determined by the decoration originator
The full IRC log of that discussion <TabAtkins> Topic: How text-decoration-skip/ink interact with text-decoration
<astearns> github: https://github.com//issues/2817
<TabAtkins> xidorn: problem here is that t-d properties generally not inherited, because we want the decoration line to be one line across a whole element.
<TabAtkins> xidorn: But t-d-s and t-d-s-i is inherited.
<TabAtkins> xidorn: So it's unclear whether the decoration line on an element should respect the skip/-ink on the element, or on the element that the line originated.
<TabAtkins> fantasai: Original design of t-d-s had several values, ink was one of them. Could say you want margin skipped, etc.
<TabAtkins> fantasai: Also just "skip me", entirely
<TabAtkins> fantasai: That value can't possibly work if it only works on the element establishing the decoration.
<TabAtkins> fantasai: Whole point is to set it on an element and have it affect a line established by an ancestor.
<TabAtkins> koji: text-underline-position has same issue
<TabAtkins> fantasai: t-u-p should probably be attached when the decoration is set, otherwise if you're switching languages it'll switch sides
<fantasai> s/probably//
<TabAtkins> emilio: In gecko we implement the spec that says t-d properties are reset...
<TabAtkins> emilio: With multiple decoration, wk/blink keep track of them in effect using an inherited property, which you add stuff to
<TabAtkins> emilio: I wonder what edge does
<TabAtkins> emilio: In wk/blink decorations aren't propagated in box-tree, which is supposed to happen.
<TabAtkins> emilio: Does edge implement the spec?
<TabAtkins> emilio: Right now the only ones affected by this operation are Gecko
<TabAtkins> frremy: edge does one underline for the whole thing, not one per span
<TabAtkins> myles: how we implement - if you ahve an outer that's underlined, inner that's strikethru, you're supposed to add so the inner gets both
<TabAtkins> myles: that's what emilio's talkinga bout
<TabAtkins> frremy: I think we have a field for underline and one for strikethru
<TabAtkins> myles: Sounds like a different mechanism
<TabAtkins> dbaron: testcase with three different renderings...
<dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%0Au%20%7B%20text-decoration%3A%20underline%3B%20color%3A%20blue%20%7D%0Aem%20%7B%20text-decoration%3A%20underline%20line-through%3B%20color%3A%20green%3B%20vertical-align%3A%200.5em%20%7D%0A%0A%3C%2Fstyle%3E%0AThis%20%3Cu%3Eis%20%3Cem%3Esome%3C%2Fem%3E%20text%3C%2Fu
<dbaron> %3E.
<TabAtkins> Firefox: blue underline stretching across whole thing, green underline under "some" at its baseline.
<TabAtkins> Chrome: no blue underline under "some", it has green at its baseline
<TabAtkins> Edge: blue underline stretching across whole thing (maybe), green underline overlapping it (rather than at "some"'s baseline)
<TabAtkins> dbaron: This is the differenc emilio is talking about
<TabAtkins> Rossen: We align the two underlines
<TabAtkins> myles: So we have a bunch of impls that are wrong. If you don't consider impls today, don't consider spec today, what's best behavior for users?
<TabAtkins> frremy: I think it depends. I think Firefox is a bit better in this specific case.
<TabAtkins> frremy: But in some vertical cases, you want the underlines to align.
<TabAtkins> fantasai: The spec for underline says if you're gonna collide the text, you can move it down.
<TabAtkins> astearns: We're getting afield
<TabAtkins> florian: "skip-me" can't possible work unless the skipping applies based on the descendant element, not the originator.
<TabAtkins> astearns: And the example in the issue - the div has skip-ink on it, but a descendant wants no skipping - we want the descendant to not skip.
<TabAtkins> dbaron: Another example is hyperlinks.
<TabAtkins> dbaron: A piece of a11y advice is that i fyou ahve multiple hyperlinks, you should have a space between them, so the user can tell they're separate links
<TabAtkins> dbaron: I think t-d skipping...
<TabAtkins> fantasai: Has a feature for that
<fantasai> https://drafts.csswg.org/css-text-decor-4/#text-decoration-skip-property
<TabAtkins> myles: Links with no space between them?
<TabAtkins> fantasai: That's why there's an "edges" value
<TabAtkins> dbaron: So some people might want fo rhyperlinks to *not* have skipping, so you have continuity of underlines and can more easily tell.
<TabAtkins> dbaron: Where I'm going is that it's an argument for skip:none on the thing setting the decoration, and having it not overrideable.
<TabAtkins> fantasai: I can see that for the ink value specifically.
<TabAtkins> fantasai: I think some of the other values we have that makes less sense
<TabAtkins> myles: Any impls of the other values?
<TabAtkins> fantasai: Don't think so, and I thinkw e resolved to split it apart into multiple properties anyway
<TabAtkins> florian: Yes
<TabAtkins> myles: So for those other longhand properties we're still in the design phase and can change them
<TabAtkins> florian: So we could decide which element it keys off depending on the property
<TabAtkins> fantasai: Some of the proeprties are already bound to the decorating box
<fantasai> astearns: You can ...
<fantasai> TabAtkins: ...
<fantasai> TabAtkins: Once you've established a type of underline wrt ink-skipping or not, don't want children to set it differently
<TabAtkins> heycam: Is this fundamentally an issue with ink-skipping on by default?
<TabAtkins> florian: I think we can set ink-skipping to work on the originator, and others can be on children
<TabAtkins> fantasai: Fine with me.
<TabAtkins> fantasai: Note that it means you can have an overlapping underline that's skipping ink.
<TabAtkins> myles: You can do art with overlapping underlines!
<fantasai> fantasai: I do want to point out that if we do this, you can have two underlines on one element, one which skips ink and one which doesn't.
<fantasai> TabAtkins: Proposed resolution is that text-decoration-skip-ink is tied to the decoration where the decoration is specified, and propagates with it
<TabAtkins> astearns: So resolving only on skip-ink, not skip.
<TabAtkins> fantasai: yeah
<fantasai> s/tied/bound/
<TabAtkins> RESOLVED: ink-skipping is determined by the decoration originator, not descendant elements
<TabAtkins> RESOLVED: underline position is also determined by the decoration originator, not descendant elements
<TabAtkins> heycam: Does this mean they're not inherited?
<TabAtkins> myles: No, unrelated. It's just determined when you establish the decoration, regardless of how the proeprty changes on children
<TabAtkins> koji: I think text-underline-offset should also propagate witht he decoration
<TabAtkins> RESOLVED: underline offset is also determined by the decoration originator
<TabAtkins> plinss: Any propeties that *don't* go with the originator?
<TabAtkins> TabAtkins: yes, some of the other skipping functionalties, because the children can say "skip *me*"

fantasai added a commit that referenced this issue May 4, 2022
@fantasai
[css-text-decor-4] Clarify that text-decoration-skip-ink applies only…
91f7a5e 
… to decorations originating on the element. #2817
@fantasai
Copy link
Collaborator
fantasai commented May 4, 2022

Added clarification for text-decoration-skip-ink; it was already specified for text-underline-offset and text-underline-position.

@fantasai fantasai closed this as completed May 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Closed Accepted by CSSWG Resolution css-text-decor-4
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@upsuper @fantasai @kojiishi @astearns @heycam @css-meeting-bot