Intent to Implement And Ship: CSSTextEmphasisPosition: support for left and right values

[Ramya]

Summary

Support for 'left' and 'right' values for CSSTextEmphasisPosition property.

left : Draw marks to the left of the text in vertical writing mode.

right: Draw marks to the right of the text in vertical writing mode.

Motivation

Recommended by spec. Safari already supports it. 

Compatibility Risk

Firefox: No public signals

Edge: No public signals

Safari: Shipped

Web developers: No signals

Describe the degree of compatibility risk you believe this change poses

Since it is an addition to existing functionality it is unlikely to break existing sites.

Ongoing technical constraints

None

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

Chrome OS, Android, and Android WebView)? Yes or no.

Yes

OWP launch tracking bug

https://code.google.com/p/chromium/issues/detail?id=522882

Link to entry on the Chrome Platform Status

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

Requesting approval to ship?

Yes

[Philip Jägenstedt]

Is https://drafts.csswg.org/css-text-decor/#text-emphasis-position-property
the spec in question?

The template linked in http://www.chromium.org/blink#launch-process is
slightly different from what you've used, so have you found another
template that needs updating?

> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.

[Ramya]

Thanks philip for correcting.

Spec is https://drafts.csswg.org/css-text-decor/#text-emphasis-position-property.

I've got this Intent to Implement template generated from chromestatus.com site.

Will take care next time to exactly follow the template in http://www.chromium.org/blink#launch-process

[Philip Jägenstedt]

No worries, I've filed https://github.com/GoogleChrome/chromium-dashboard/issues/230 to figure out why the templates aren't in sync.

As for the intent itself, some more details would be appreciated. A quick and lazy grep suggests that we already support -webkit-text-emphasis-position but only over/under.

Is the intention to ad the unprefixed text-emphasis-position with support for over/under and left/right, or something else? If the prefixed and unprefixed variants don't accept the same values, does that amount to any complication/duplication internally, or can it all be handled by the parser?

[Ramya]

Intention is to support only left/right values corresponding to under/over in vertical writing mode for -webkit-text-emphasis-position.

Unprefixing can be taken up separately.

[Philip Jägenstedt]

I don't think adding support for new values in a prefixed property sounds like a good idea, the only way for people to actually make use of that would be to use the prefixed property, which we do not want.

Without knowing much about the problem domain, shipping the unprefixed property with full support and at the same time deprecating the prefixed property sounds like a better path. Usage of the prefixed property is very low:

https://www.chromestatus.com/metrics/css/popularity#webkit-text-emphasis-position

[Rick Byers]

Agreed.  I did an httparchive search and couldn't find usage of '-webkit-text-emphasis-position: left' in the top 300k sites (though the data is a year old, may predate webkit support?).  So I don't see any particular value in increasing the capability of the webkit prefixed property.

That said, the spec seems relatively mature to me at first glance.  Perhaps there's not much work required to unprefix all of this now and add the missing features? +kojii who is one of the editors.

[Ramya]

@Philip and Rick Thank you for your inputs. Will take up unprefixing as well as adding  missing features in this intent.

[Koji Ishii]

On Thu, Aug 20, 2015 at 11:17 PM, Rick Byers <rby...@chromium.org> wrote:

Agreed.  I did an httparchive search and couldn't find usage of '-webkit-text-emphasis-position: left' in the top 300k sites (though the data is a year old, may predate webkit support?).  So I don't see any particular value in increasing the capability of the webkit prefixed property.

That said, the spec seems relatively mature to me at first glance.  Perhaps there's not much work required to unprefix all of this now and add the missing features? +kojii who is one of the editors.

​Yes, the spec is in CR for 2 years and ​is quite stable. Appreciate both unprefixing and supporting the values in the spec.

/koji

[Dominik Röttsches]

Hi Ramya, others,

I don't have concerns with shipping the feature itself, but our emphasis marks implementation really is in need for an overhaul. It's not very efficient at the moment and bolted on in various places (the way we create a fake emphasis mark TextRun, the way we channel placement of emphasis marks through the shaper running in "emphasis mark mode" is probably not ideal). I'd prefer to not stack additional features on the existing implementation before cleaning it up - but if it's your intention to help improve what's there and then add the feature, that would be great. I can help with reviewing.

Dominik

[Ramya]

Hi Dominik,

Thanks for the reply. Will go through the implementation details and come up with my findings for cleaning up. Will add additional features once your concerns are addressed.

[Chris Harrelson]

Hi,

Is there any update on this Intent? I'm not sure of the current state. I think it might have slipped through the cracks, and is still waiting for LGTMs?

Chris

[Ramya]

@Dominik

Hi due to unavailability could not reply till now.

As of now I don't have proper knowledge of font and shaper related modules to make improvements.

Would be happy if someone more knowledgable could address your concerns before shipping this feature. 

Once it is fine to ship this, I can go ahead with that.

[Dimitri Glazkov]

On Sun, Sep 27, 2015 at 8:58 PM, Ramya <ram...@samsung.com> wrote:

@Dominik

Hi due to unavailability could not reply till now.

As of now I don't have proper knowledge of font and shaper related modules to make improvements.

Would be happy if someone more knowledgable could address your concerns before shipping this feature. 

Once it is fine to ship this, I can go ahead with that.

Sounds good. Let's consider this intent withdrawn until then.

:DG<