It's really difficult for me to implement text-decoration-skip. Especially tge "ink" value. Currently, we do layout the decoration lines with nsLineLayout and nsTextFrame. And nsTextFrame paints them. However, this cannot paint under <img>, inline-blocks and margins of descendent inline elements. So, I think that we should move back some painting code to nsContainerFrame, first. I'm not sure why CSS 3 text-decoration-skip breaks the compatibility with CSS 2.1 with its default value. text-decoration-skip: objects box-decoration; represents the CSS 2.1 behavior but just "objects" is the default value.

And I have two questions: 1. If "text-decoration-skip: edges;" is specified, what happens? I don't understand from the spec's description. 2. In CSS level3, cannot paint text-decoration lines to the space which is made by line break? For example, |I don't | |understand. | This case, "understand" is too long for the remaining space of the first line. Then, the first line has wide space after "don't". So, even if |text-decoration-skip: none;| is specified, decoration lines are not painted in the space?

Ah, I see the answer of #1. It makes "gaps" between inline elements which owns the decoration lines. We use such style at painting IME selection underlines.

The 'ink' value is at-risk; I wouldn't worry about it for now unless it's easy or there's a strong reason to implement it now. Yes, you're right about #1. I'd suggest insetting the underline by its thickness or maybe half its thickness... Wrt #2, no, you can't paint in that space. We don't draw backgrounds there, so we don't draw lines there either. Painting the lines across margins/border/padding of inline elements is due to the behavior looking quite broken if we don't do that. In other words, we consider it a mistake in CSS2.1. See the minutes at http://lists.w3.org/Archives/Public/www-style/2012Aug/0897.html and look for "ISSUE-270".

(In reply to fantasai from comment #3) > The 'ink' value is at-risk; I wouldn't worry about it for now unless it's > easy or there's a strong reason to implement it now. Okay, I see. > Wrt #2, no, you can't paint in that space. We don't draw backgrounds there, > so we don't draw lines there either. Thanks, that would make the implementation simple. > Painting the lines across margins/border/padding of inline elements is due > to the behavior looking quite broken if we don't do that. In other words, we > consider it a mistake in CSS2.1. See the minutes at > http://lists.w3.org/Archives/Public/www-style/2012Aug/0897.html and look for > "ISSUE-270". Thanks, but I'm not sure the definition of inline in the log. Does it includes replaced inline boxes and inline-block? The discussion assumes that if a designer specifies text-decoration to an element, then, all of the decoration lines in the element should be connected when text-decoration-skip: none;. So, it seems... text-decoration-skip: objects; should paint the margins of replaced inline boxes and inline-block boxes? Like: +--------+ | | text | <img> | +------------+ --------|________|------| |-- (underline) | inline- | | block | +------------+ but text-decoration-skip: objects box-decoration; is specified, then, it should be... +--------+ | | text | <img> | +------------+ ------ |________| | | | inline- | | block | +------------+ like this? And even if the margin-left or margin-right is the start or end of the line, text-decoration is necessary?

No, 'text-decoration-skip: objects' should skip the entire margin box of the object. I'll clarify the spec here... An "inline box" is one that is non-replaced and 'display: inline'. An "atomic inline" is a replaced element or inline-block/table/etc.

I think this bug have some relation with #156881. We could implement it as an experimental feature.

Chrome: Intent to Implement and Ship: text-decoration skip with values: objects, ink https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/hdBMDg5Nmok/ZAd7NTgfAwAJ

Now that Chrome is shipping this CSS, it's starting to make the rounds of news for designers and developers. The results that `text-decoration-skip: ink;` provides has been in great demand for many years. People will use the heck of of this once it's useable. We should get this into Firefox.

FWIW, if we want to implement "text-decoration-skip: ink", we want to implement it in the WebKit way (which includes some unspeced behavior, though), not the Blink way. There are two nontrivial issues of Blink's implementation, which they would need to fix before the feature is really usable. [1][2] [1] https://github.com/w3c/csswg-drafts/issues/707 [2] https://github.com/w3c/csswg-drafts/issues/711

In https://github.com/w3c/csswg-drafts/issues/711 in today's teleconference the CSSWG resolved that text-decoration-skip should not apply to strike-through (only to underline and overline).

Note: Blink intends removing the old "text-decoration-skip" and shipping "text-decoration-skip-ink" instead. https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/47BHtmz0jVY So is this bug WONTFIX then?

Blink will make skip ink the default so would Firefox implement this feature then? I couldn't find a separate issue for the feature.

(In reply to j.j. from comment #11) > Note: > Blink intends removing the old "text-decoration-skip" and shipping > "text-decoration-skip-ink" instead. > > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/47BHtmz0jVY > > So is this bug WONTFIX then? As the spec. is still an unofficial draft and it seems the removal of the text-decoration-skip property is not officially decided yet, this bug shouldn't be closed as WONTFIX yet. Instead, I've created bug 1411922 to track the implementation of text-decoration-skip-ink separatedly. Sebastian

This: https://twitter.com/malyw/status/928250363647610881

Obviously, the spec. defines both now, text-decoration-skip and text-decoration-skip-ink, while this property may still be split up according to an issue in the spec. Jen, Chrome shipped text-decoration-skip-ink, not text-decoration-skip. Also, I think the request is stronger for the former property and due to the unresolved spec. issues, I'd say this bug should have lower DevRel priority than bug 1411922. Sebastian

AFAICT this is kind of replaced by bug 1411922 "Implement text-decoration-skip-ink", no?

No, they are two different properties now, and it's unlikely they will be implemented in a similar way.