Intent to Implement and Ship: ‘left’ and ‘right’ values for ‘text-underline-position’

[Koji Ishii]

Contact emails

ko...@chromium.org, ericwi...@chromium.org

Explainer

None.

Spec

https://drafts.csswg.org/css-text-decor-3/#text-underline-position-property

No tag review filed, this intent matches our implementation to the spec in CR state by adding two values in the spec.

Summary

Currently, in vertical flow for Chinese and Japanese, which side underline appears is not interoperable (crbug/854091#c3.) Supporting ‘left’ and ‘right’ values for the ‘text-underline-position’ property allows web developers to make it interoperable.

Blink shipped this property as part of Text Decoration properties (chromestatus entry) but “text-underline-position left, right and multiple value support is currently work in progress.” This intent implements these values. Implementing these values was also filed at crbug/313888 before that.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Risks

Interoperability and Compatibility

Low. Although this is first to ship these values, these values helps interoperability today, and other browsers have public support.

Edge: Shipped old syntax “below | above”. No signals to update.

Firefox: Public support, bugzilla 770780, currently planning in 2019.

Safari: Shipped `auto` and `under`, public support for `left` and `right`. wkbug48936, wkbug/112615

Web developers: Strong requests from East Asian EPUB content authors and providers. Not hearing much from the web authors, but this solves non-interoperability described in crbug/854091#c3.

Ergonomics

This property is one of the properties to style underlines.

There are no performance or architectural concerns.

Activation

There are no concerns for developers to take advantage of this feature immediately, as-is.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

There are no tests for this property today. The intent includes implementing tests.

Entry on the feature dashboard

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

[Yoav Weiss]

On Wed, Jul 4, 2018 at 6:12 AM Koji Ishii <ko...@chromium.org> wrote:

Contact emails

ko...@chromium.org, ericwi...@chromium.org

Explainer

None.

Spec

https://drafts.csswg.org/css-text-decor-3/#text-underline-position-property

No tag review filed, this intent matches our implementation to the spec in CR state by adding two values in the spec.

Summary

Currently, in vertical flow for Chinese and Japanese, which side underline appears is not interoperable (crbug/854091#c3.) Supporting ‘left’ and ‘right’ values for the ‘text-underline-position’ property allows web developers to make it interoperable.

Blink shipped this property as part of Text Decoration properties (chromestatus entry) but “text-underline-position left, right and multiple value support is currently work in progress.” This intent implements these values. Implementing these values was also filed at crbug/313888 before that.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Risks

Interoperability and Compatibility

Low. Although this is first to ship these values, these values helps interoperability today, and other browsers have public support.

Edge: Shipped old syntax “below | above”. No signals to update.

Did you try to reach out?

 

Firefox: Public support, bugzilla 770780, currently planning in 2019.

Safari: Shipped `auto` and `under`, public support for `left` and `right`. wkbug48936, wkbug/112615

These issues are not very recent. Did you try to reach out and see if Safari/WebKit folks have interest in converging on `left`/`right` in the near future?

 

Web developers: Strong requests from East Asian EPUB content authors and providers. Not hearing much from the web authors, but this solves non-interoperability described in crbug/854091#c3.

Since it seems like if this ships, we would have 4 implementations doing 4 distinct things in this area, what should web developers do? (in case they are targeting the web, rather than a specific engine) 

Can you outline a usage-scenario? Would developers be able to just include all the relevant CSS rules for all engines without causing side-effects?

Ergonomics

This property is one of the properties to style underlines.

There are no performance or architectural concerns.

Activation

There are no concerns for developers to take advantage of this feature immediately, as-is.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

There are no tests for this property today. The intent includes implementing tests.

Entry on the feature dashboard

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

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACQRE%2BRMTUnC5KN-R0QSLJZOKL72ZVr0G2fj_99xzaCXDFdJ9w%40mail.gmail.com.

[Koji Ishii]

​

Firefox: Public support, bugzilla 770780, currently planning in 2019.

Safari: Shipped `auto` and `under`, public support for `left` and `right`. wkbug48936, wkbug/112615

These iss

​​

ues are not very recent. Did you try to reach out and see if Safari/WebKit folks have interest in converging on `left`/`right` in the near future?

​Yes, please look at the last 2 comments in bugzilla 770780, they were added after we discussed. WebKit said it's the right thing to fix, but no timeline. We discussed and Blink and Gecko supporting these values looks the best way to move forward for existing content, future content, and the CSS spec.

 

Web developers: Strong requests from East Asian EPUB content authors and providers. Not hearing much from the web authors, but this solves non-interoperability described in crbug/854091#c3.

Since it seems like if this ships, we would have 4 implementations doing 4 distinct things in this area, what should web developers do? (in case they are targeting the web,

​​

rather than a specific engine) 

​Today, there's no workaround. When WebKit fixed the bug above, underlines are on right for Chinese and Japanese on all browsers. Between that, if Blink and Gecko support this property:

@supports('text-underline-position: under left') {

  text-underline-position: under left;​

  u { text-decoration: overline; }

}

will render underlines on right for all browsers.​ This is the the workaround existing content does, but this workaround doesn't work because these values are not supported. The workaround not working is what crbug.com/854091 is talking about, and this intent will save them.

Using 'overline' for underline is a bit hacky, this will not be necessary when all browsers match to the spec, but this workaround will keep working after that too.

[Yoav Weiss]

The interop landscape on this one seems... complex. Thanks for tackling it!

On Wed, Jul 4, 2018 at 9:39 AM Koji Ishii <ko...@chromium.org> wrote:

​

Firefox: Public support, bugzilla 770780, currently planning in 2019.

Safari: Shipped `auto` and `under`, public support for `left` and `right`. wkbug48936, wkbug/112615

These iss

​​

ues are not very recent. Did you try to reach out and see if Safari/WebKit folks have interest in converging on `left`/`right` in the near future?

​Yes, please look at the last 2 comments in bugzilla 770780, they were added after we discussed.

I saw the comments but "some time in 2019" means that developers would still have to live with the status-quo for a while

 

WebKit said it's the right thing to fix, but no timeline.

 

I saw that as well, but also noticed that this was many moons ago... 

 

We discussed and Blink and Gecko supporting these values looks the best way to move forward for existing content, future content, and the CSS spec.

That makes sense.

 

 

Web developers: Strong requests from East Asian EPUB content authors and providers. Not hearing much from the web authors, but this solves non-interoperability described in crbug/854091#c3.

Since it seems like if this ships, we would have 4 implementations doing 4 distinct things in this area, what should web developers do? (in case they are targeting the web,

​​

rather than a specific engine) 

​Today, there's no workaround. When WebKit fixed the bug above, underlines are on right for Chinese and Japanese on all browsers. Between that, if Blink and Gecko support this property:

@supports('text-underline-position: under left') {

  text-underline-position: under left;​

  u { text-decoration: overline; }

}

will render underlines on right for all browsers.​ This is the the workaround existing content does, but this workaround doesn't work because these values are not supported. The workaround not working is what crbug.com/854091 is talking about, and this intent will save them.

Using 'overline' for underline is a bit hacky, this will not be necessary when all browsers match to the spec, but this workaround will keep working after that too.

OK, so through `@supports` developers would be able to tailor engine-specific CSS rules up until the point where all engines support the standard ones? Seems better than not being to do this at all.

Is there a WPT test suite for the feature? If not, are you planning to ship one? 

[Koji Ishii]

WebKit said it's the right thing to fix, but no timeline.

 

​​

I saw that as well, but also noticed that this was many moons ago... 

​True. The bug was reported 8 years ago and stalled. After we confirmed this problem recently, Myles, the WebKit engineer on the cc list of this e-mail, and I discussed how to solve this, and confirmed we would like to fix by both of us matching to the spec.

OK, so through `@supports` developers would be able to tailor engine-specific CSS rules up until the point where all engines support the standard ones? Seems better than

​​

not being to do this at all.

Fully agreed, not ideal, but better than not being able to work around.​

Is there a WPT test suite for the feature? If not, are you planning to ship one? 

No and ​yes, the plan includes adding wpt tests.​

[Yoav Weiss]

LGTM1

On Thu, Jul 5, 2018 at 1:34 AM Koji Ishii <ko...@chromium.org> wrote:

WebKit said it's the right thing to fix, but no timeline.

 

​​

I saw that as well, but also noticed that this was many moons ago... 

​True. The bug was reported 8 years ago and stalled. After we confirmed this problem recently, Myles, the WebKit engineer on the cc list of this e-mail, and I discussed how to solve this, and confirmed we would like to fix by both of us matching to the spec.

Oh, happy to hear that Myles is on it.

 

OK, so through `@supports` developers would be able to tailor engine-specific CSS rules up until the point where all engines support the standard ones? Seems better than

​​

not being to do this at all.

Fully agreed, not ideal, but better than not being able to work around.​

Is there a WPT test suite for the feature? If not, are you planning to ship one? 

No and ​yes, the plan includes adding wpt tests.​

 

Great to hear tests will be included. 

[Mike West]

LGTM2, given the commitment from WebKit to align in the same direction we're moving.

-mike

--

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/CACj%3DBEghxP0ERP93%2BSXeiDvq%2BXk4bHjPp9_eqDKS3zkOYfjdEw%40mail.gmail.com.

[Daniel Bratell]

LGTM3 (based on wpt tests being added)

And good luck unmessifying the mess!

/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/CAKXHy%3DcoyOqvC6VSWzykRKOpDSxQCce9g_nKJ4M%3DuYhjQRLUcA%40mail.gmail.com.

--

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