[css-text-decor-4] Implement text-decoration-skip

NEW
Unassigned

Status

()

--
enhancement
6 years ago
4 months ago

People

(Reporter: masayuki, Unassigned)

Tracking

(Blocks: 2 bugs, {css3, dev-doc-needed, DevAdvocacy})

Trunk
css3, dev-doc-needed, DevAdvocacy
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [DevRel:P3], URL)

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.

Comment 3

6 years ago
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?

Comment 5

6 years ago
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.

Updated

6 years ago
Blocks: 913153

Comment 6

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

Updated

5 years ago
See Also: → bug 1019448

Updated

5 years ago
Blocks: 156881
Keywords: dev-doc-needed
No longer blocks: 104960

Comment 7

2 years ago
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.
Keywords: DevAdvocacy
Whiteboard: [DevRel:P1]
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).

Comment 11

a year ago
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?

Comment 12

a year ago
Blink will make skip ink the default so would Firefox implement this feature then? I couldn't find a separate issue for the feature.
See Also: → bug 1411917
See Also: → bug 1411922
(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
Summary: Implement CSS3 text decoration text-decoration-skip → Implement css-text-decor-4 text-decoration-skip
Summary: Implement css-text-decor-4 text-decoration-skip → [css-text-decor-4] Implement text-decoration-skip

Updated

a year ago
Blocks: 1415712
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
Flags: needinfo?(jensimmons)
Flags: needinfo?(jensimmons)
Whiteboard: [DevRel:P1] → [DevRel:P3]

Comment 17

4 months ago
AFAICT this is kind of replaced by bug 1411922 "Implement text-decoration-skip-ink", no?
Depends on: 1411922
No, they are two different properties now, and it's unlikely they will be implemented in a similar way.
No longer depends on: 1411922
You need to log in before you can comment on or make changes to this bug.