Intent to Ship: CSS3 Text Decorations

[Dominik Röttsches]

Contact emails

dr...@chromium.org

Spec

https://drafts.csswg.org/css-text-decor-3/

Summary

CSS3 Text Decorations provide properties that allow new text decoration styling features such as lines, color and style. 

As the specification says:

"CSS Levels 1 and 2 only defined very basic line decorations (underlines, overlines, and strike-throughs) appropriate to Western typographical traditions. Level 3 of this module adds the ability to change the color, style, position, and continuity of these decorations, [...]"

Motivation

There is a demand for complex text decorations, not only for purely decorative purposes, but also in some cases to show emphasis, for honorifics, and to indicate editorial changes such as insertions, deletions, and misspellings. WebKit and Firefox ship the feature, and we've long had an implementation behind the experimental web platform features flag.

Interoperability risk

Firefox: Shipped

Edge: No public signals

Safari: Shipped, prefixed

Web developers: Positive

The "blink" value is accepted, though not implemented in WebKit, we'd follow this approach.

Compatibility risk

I don't see a risk of breaking content, as these are new properties, and the updated behaviour for parsing the text-decoration: shorthand is backwards compatible. 

The implementation is well tested and has been maturing under the experimental web platform features flag. For the work on text-decoration-skip I was going through it again, and added missing links for full text-decoration: shorthand support and painting multiple decorations (with help from Sasha and Tim) so that I believe it's ready for shipping.

Ongoing technical constraints

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,

Chrome OS, Android, and Android WebView)?

Yes

OWP launch tracking bug

crbug.com/665898

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/features/5695146909761536

Requesting approval to ship?

Yes

Thanks to Bruno Abinader for the original implementation.

[Philip Jägenstedt]

I've confirmed that the MDN example works in Firefox, and CSS.supports('(text-decoration-line: blink)') return true even though it doesn't actually Blink. That seems kind of weird, but if Safari and Firefox already agree, so be it.

LGTM1 

[Philip Jägenstedt]

Oops, "doesn't actually Blink" was a muscle memory typo, not an attempted reference to Blink's behavior. It doesn't blink in Firefox.

[PhistucK]

Thank you for working on this!

Has it gone through interoperability testing? Do all of the supporting browsers show the same results?

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[一丝]

Aren't you going to implement text-decoration-skip: edges?

在 2016年11月16日星期三 UTC+8下午11:28:26，Dominik Röttsches写道：

[Rick Byers]

I'm also curious about the status of interop tests.  I see there's some here but we're skipping running them in blink.  Any idea why?  I spot checked a couple manually and they look like they pass to me, so it seems at least some of them should be enabled and passing in our infrastructure.

[Dominik Röttsches]

Hi Rick,

On Thu, Nov 17, 2016 at 9:39 PM, Rick Byers <rby...@chromium.org> wrote:

I'm also curious about the status of interop tests.  I see there's some here but we're skipping running them in blink.  Any idea why?  I spot checked a couple manually and they look like they pass to me, so it seems at least some of them should be enabled and passing in our infrastructure

The reason is probably just that nobody got around to enabling them. I will create a separate CL for enabling the decor tests for the sake of completeness and CC you, but I have doubts about the quality of the decoration tests in this group. As far as I can tell, they only test CSS consistency, i.e. equal behavior between setting the shorthand and the long hand. I think we have a more concise test for this in fast/css3-text/css3-text-decoration/text-decoration-shorthand.html - we also have good tests for testing the decorations ourselves in fast/css3-text/css3-text/decoration.

Dominik

 

 

.

[PhistucK]

Sorry, but what exactly will ship?

Context - text-emphasis is on that specification, for example. I see some discussion in the bug regarding unprefixing it (Chrome already ships -webkit-text-emphasis), but you did not file that bug, so I presume this intent does not include shipping it unprefixed.

☆PhistucK

On Wed, Nov 16, 2016 at 5:27 PM, Dominik Röttsches <dr...@chromium.org> wrote:

--

[Dominik Röttsches]

Yes, I could have made that more clear: This intent to ship is restricted to shipping the line decoration extensions:

https://drafts.csswg.org/css-text-decor-3/#line-decoration

Emphasis marks are currently implemented with -webkit- prefix, Philip independetly filed issue 666433 to check whether those can be unprefixed and shipped as well.

Dominik

[PhistucK]

Thank you.

So beside the standard test suite, have you looked around and tested by yourself that the implementation is interoperable?

☆PhistucK

[Dominik Röttsches]

On Fri, Nov 18, 2016 at 5:00 PM, PhistucK <phis...@gmail.com> wrote:

Thank you.

So beside the standard test suite, have you looked around and tested by yourself that the implementation is interoperable?

Yes, as I indicated in this thread, we're doing mostly the same thing that WebKit does as the code was developed in parallel and landed in both. Also, visual inspection shows that the decoration patterns are very similar to what FF does, modulo different underline thickness, as mentioned.

[Rick Byers]

LGTM2, thanks.

It would be great if you could upstream some of our tests to csswg-test and enable running them in blink (instead of the corresponding layout tests), but it's not (yet) required.  Geoffrey (cc'd) has been overhauling/improving a lot of csswg-test lately (on contract for Google), he'd probably be happy to help if you have any issues / questions.

Rick

[Chris Harrelson]

LGTM3

[brunoa...@gmail.com]

Amazing work, Dominik!

Great to see this finally coming alive ;)

Bruno

[一丝]

Implement support for 'left' and 'right' values from text-underline-position

https://bugs.chromium.org/p/chromium/issues/detail?id=313888&

在 2016年11月16日星期三 UTC+8下午11:28:26，Dominik Röttsches写道：

Contact emails

[Koji Ishii]

On Mon, Nov 21, 2016 at 11:20 AM, 一丝 <yio...@gmail.com> wrote:

Implement support for 'left' and 'right' values from text-underline-position

https://bugs.chromium.org/p/chromium/issues/detail?id=313888&

​Dominik and I are looking into it too, but they are not part of this intent yet. It has some open issues in the spec, but we'll try to work them out.

/koji

[一丝]

Thanks!

在 2016年11月21日星期一 UTC+8下午2:01:14，Koji Ishii写道：

[PhistucK]

So it is not the full section 2... What does this intent include exactly? Or, if it is easier (hopefully), what does it exclude?

☆PhistucK

--

[Manuel Rego Casasnovas]

Just reviving and old thread to raise awareness on some backwards
compatibility issues we found despite it's already too late to do
anything (almost 2 years later).

On 16/11/16 16:27, Dominik Röttsches wrote:
> *Compatibility risk*

>
> I don't see a risk of breaking content, as these are new properties, and
> the updated behaviour for parsing the text-decoration: shorthand is
> backwards compatible.

This was finally shipped in Chromium 57.0.2928 [1], and it changed how
execCommand("strikeThrough") marks the elements (check the example [2]),
it started to use "text-decoration-line: line-through" from that point.

What's the problem? If you generate some content in Chromium 57 using
that, if someone opens it in a previous version they cannot see it (the
other way around it works without problems, as old versions set
"text-decoration: line-through" which is valid in newer versions).

I'm not sure if this could be easy or not, but in the future it might be
a good idea to keep using the old syntax for a few releases (if
possible, no super complex and compatible like in this particular case).
That way we could allow people to share content between a few extra
versions of Chromium and not break it if you're just one version behind.
If the change happened on M60, then people with previous versions up to
M57 would have things working properly as "text-decoration-line" was
supported since M57.

This mail is just to share this issue to make us think about similar
possibilities in the future. I guess this is odd enough and a corner
case, but I thought it'd be nice to share this even when it doesn't make
any sense to change anything at this stage.

Sorry for the "noise" and thanks for reading that far. :-)

Cheers,
Rego

[1]
https://chromium.googlesource.com/chromium/src/+/da8225b9b7de29db904e7a130a8591c2e0c2ffce

[2] Example:
<!DOCTYPE html>
<div id="foo" contenteditable>foobar</div>
<script>
let sel = window.getSelection();
sel.collapse(foo, 0);
sel.extend(foo, 1);
document.execCommand("styleWithCss");
document.execCommand("strikeThrough");
sel.collapse(foo, 0);
</script>

Which generates the following output from M57 on:
<div id="foo" contenteditable>
<span style="text-decoration-line: line-through;">foobar</span>
</div>

[Philip Jägenstedt]

Thanks for the report, Rego.

This sort of browser-to-browser compatibility doesn't often come up, but it's quite interesting. Another area where it might is changes to MHTML, and of course WebRTC. I'm not sure how to capture this in Blink principles of web compatibility, because it is so rare it's not mentioned. Perhaps in "Minimizing end-user impact" would be a good place. +Rick Byers ?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a6b67b57-9289-87b0-50ba-825ac169e946%40igalia.com.

[Daniel Bratell]

Broken link, something in https://www.chromium.org/blink ?

It is easy to forget that Blink also generates HTML/CSS, and it was probably not obvious that this change was going to change any generated HTML/CSS. Absolutely something to think about.

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcaBB0qOOCCeS%2BaXpH4BfqMMDb99KpJQCvvbYzzzCG0ag%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Philip Jägenstedt]

Oh, I might have had plain text mode enabled. Here's the doc:

https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?usp=sharing

[Rick Byers]

Thanks Manuel!

What was the extent / severity of the breakage in this case? I.e. who was impacted by it and when?

It seems to me that this is a more general problem of backwards compatibility of generated content. For example, doesn't shipping an un-prefixed version of a CSS property have the same effect? Eg. I believe JavaScript which does "element.style.webkitBackfaceVisibility='hidden'" will, after un-prefixing, generate DOM with style="backface-visibility: hidden".  Would we really want to serialize to old (often non-standard) versions for a period in general? Sometimes this would trade improved compatibility for worse interoperability.

In the absence of evidence of major pain created by problems like these, I'd probably rather we say that backwards compatibility of generated content is not part of our compatibility model. This doesn't mean we should ignore it completely and break it indiscriminately, but perhaps the cost of trying to proactively identify/handle such cases doesn't justify the benefit?

Rick

[flo...@rivoal.net]

It seems to me that the situation is a bit different for aliases and for shorthand/longhand relationships.

When switching from a non standard name to its standard equivalent, generating the standard name sounds like a good idea, as it pushes the ecosystem in the right direction improves compat with other browsers that may not have had the non standard variant. It still comes at the cost of compat with previous version, but at least there are upsides.

The case described by Rego is a bit different, as the property that was used before is standard, and continues to be supported. The new one is just a longhand of that property. In such cases, there does not seem to be any upside to switching to generating the longhand instead of the shorthand, and there are all the compat downsides.

—Florian

[Rick Byers]

Yes, I do think there is such a framework in which we could reason about the trade-offs here (and I'd agree with our analysis in this particular pair of examples). My question is, is it worth the cost to expand our compat guidelines to ask people to reason about this trade-off proactively for every breaking change? Or are the compat downsides rare / small enough that we should just try best-effort to avoid them on a case-by-case basis. I'm having a hard time imagining anything lightweight that would have led me, as an API owner, to consider the potential for this particular compat risk on this intent, and advocate to minimize it :-(

Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2a23f0dc-6700-4e67-af35-ce99f775e619%40chromium.org.

[Manuel Rego Casasnovas]

Hi Rick,

On 17/10/18 19:29, Rick Byers wrote:
> Yes, I do think there is such a framework in which we could reason about
> the trade-offs here (and I'd agree with our analysis in this particular
> pair of examples). My question is, is it worth the cost to expand our
> compat guidelines to ask people to reason about this trade-off
> proactively for every breaking change? Or are the compat downsides rare
> / small enough that we should just try best-effort to avoid them on a
> case-by-case basis. I'm having a hard time imagining anything
> lightweight that would have led me, as an API owner, to consider the
> potential for this particular compat risk on this intent, and advocate
> to minimize it :-(

I've been asking around a little bit about this particular case.
The issue created some confusion as people were reviewing documents
together, some people strike through them in Chromium 57, but the ones
in previous versions won't see it. Luckily this was fixed with a
JavaScript workaround to be sure that the generated content was
compatible with older versions.

I agree that for the case of prefixed properties this might not make any
sense, for cases like this one I'm not really sure.
I believe it's quite hard to realize about these issues in advance; then
it might be complex/tricky to update the code to keep generating the old
stuff for a few releases (I didn't check it). At the same time I think
that would create a more pleasant experience to Chromium users.

So I guess this is fine if this happens rarely, but it won't be nice if
most of the generated content starts to break due to similar issues.
The idea of the mail thread was just to reflect a bit about the problem
not to change anything in the policy explicitly.

Thanks,
Rego

> __

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcaBB0qOOCCeS%2BaXpH4BfqMMDb99KpJQCvvbYzzzCG0ag%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
>
>
>
> --
> /* Opera Software, Linköping, Sweden: CEST (UTC+2) */
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2a23f0dc-6700-4e67-af35-ce99f775e619%40chromium.org

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2a23f0dc-6700-4e67-af35-ce99f775e619%40chromium.org?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9UYDmxcEDHN5uvKHAz584NkS3F9De4cXLinLAXXuGcUA%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9UYDmxcEDHN5uvKHAz584NkS3F9De4cXLinLAXXuGcUA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Rick Byers]

Yeah, this is definitely something worth reflecting on - thank you Rego! Predicting compat outcomes is hard, so it's really valuable to have a big of a body of case studies shared with the whole blink community. I think it's really important that we follow up on intent threads with any outcomes / lessons learned - as that's the only way we're likely to find them again in the future. For example, the Chrome metrics team just had an intern who studied every "intent to remove" thread ever and combined it with some additional data to draw some conclusions - hopefully there will be a paper published soon on this which we can share here.

Let's definitely all keep our eyes open for other generated-content compatibility cases like this one and share data on them on the relevant intent threads. Maybe after we've seen a few different ones we can draw some stronger conclusions, or at least have some summary guidance to add to the compat principles document.

Thanks again!

   Rick