-
Notifications
You must be signed in to change notification settings - Fork 669
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-text-decor] Define how text-decoration-skip{,-ink} interacts with text-decoration #2817
Comments
I'm fine either way, which do you prefer? We do (and IIUC WebKit too) implement the decorating-box concept but enable only when Even when it's enabled, while we match each decoration to the decorating box, we paint each decoration separately, so either option seems feasible. |
cc @litherum |
The Working Group just discussed
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*" |
… to decorations originating on the element. #2817
Added clarification for |
text-decoration
style properties are non-inherited (as they should), whiletext-decoration-skip
andtext-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
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.The text was updated successfully, but these errors were encountered: