Intent to Ship: CSS line-height-step property

[Koji Ishii]

Contact emails

ko...@chromium.org

Spec

https://drafts.csswg.org/css-rhythm/#line-height-step

Summary

The CSS line-height-step property provides an ability to round the heights of line boxes to the multiple of the specified length. This property allows authors to control vertical rhythm.

Link to “Intent to Implement” blink-dev discussion

Intent to Implement: CSS Snap Size

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

Yes.

Demo link

https://drafts.csswg.org/css-rhythm/examples/snap-height.html

Interoperability and Compatibility Risk

The line-height-step is the most fundamental property of the spec. Additional properties are still under discussions in the CSS WG, but this property is useful without them.

The previous Intent to Implement: CSS Snap Size included 2 other features; the baseline alignment and line-width-stepping. These were controversial and taking time to stabilize that they were deferred to future phases.

The WG resolved to publish FPWD last week. The spec has gone through 3 times of renames. Hard to know if there could be more, but the behavior is stable.

Although there's no public signals from other implementers yet, positive interests in this feature were discussed multiple times among implementers, and we are hearing positive feedback from web developers (e.g. from web developers in Acknowledgements, or a recent tweet.) I will keep the conversations with other implementers.

OWP launch tracking bug

crbug.com/586413

Entry on the feature dashboard

https://www.chromestatus.com/feature/5734273533345792

[Rick Byers]

Hey Koji,

We discussed this in the API owners meeting today.  Have you discussed us shipping this with any of the other CSSWG members?  We'd like to hear their thoughts on the implications of us shipping and potentially locking in the name or other things which may or may not be possible to change post-ship.

Rick

[Alan Stearns]

My preference would be to implement behind a flag for now, at least until other implementers sign up. There have been a few issues added to the spec since last week's meeting.

[Koji Ishii]

On Fri, Jan 20, 2017 at 4:02 AM, Rick Byers <rby...@chromium.org> wrote:

Hey Koji,

We discussed this in the API owners meeting today.  Have you discussed us shipping this with any of the other CSSWG members?  We'd like to hear their thoughts on the implications of us shipping and potentially locking in the name or other things which may or may not be possible to change post-ship.

​Yes, I'm hearing positive responses, but the conversations are not in public archives.​ Sorry for not being able to share them.

This feature isn't like major, big feature such as flexbox; the behavior is so simple that there are very little room to adjust/change, I suppose it won't require intents if this is just a behavior change without the additional property.

I agree with you that there still may be slight name/behavior adjustments, but we can probably follow the change in a few milestones, since I believe that the usage grows only very slowly.

This feature is not for the majority, but important for some limited segments. Rather than worrying about locking in, I'm more worried that the usage doesn't reach 0.03% fast enough that someone may want to remove it later. This feature is in the similar category as CSS Line Grid, which we removed when its usage was only 0.007%.

/koji

[Koji Ishii]

On Fri, Jan 20, 2017 at 10:15 AM, Alan Stearns <famu...@gmail.com> wrote:

My preference would be to implement behind a flag for now, at least until other implementers sign up. There have been a few issues added to the spec since last week's meeting.

​Thank you for sharing your concern with us, Alan.

This property is implemented behind a flag for over 10 months, ​so from our regular process, we're at the point that we need to make a call whether it should go live, remove, or continue experiments.

I've already got strong positive responses from web developers, so I don't see much values to continue experiments. I'm not seeing concerns that can't be addressed in parallel, and hence the intent to ship, but I'm fine to remove if anyone got strong issues to do so.

I saw issues in the github, haven't responded yet, sorry, but IIUC they can be addressed in parallel to the intent. I'm glad that, after all the discussions for over an year at WG, all issues we see now are addressable in parallel to the intent. I'll respond to the issues.

/koji

[Rick Byers]

[I think this one may involve some meta-discussion - bcc: blink-dev to avoid spamming a large audience, follow on blink-api-owners-discuss list if you're interested.  We'll circle back here with the conclusion]

Thanks for your input Alan.  Are you saying the outstanding issues in GitHub may result in breaking changes that would be problematic from a web compat perspective?  Or do you have other concerns about the harm that could be done by the feature shipping in blink now?

Given that this is a somewhat subtle visual improvement, I'm having a hard time seeing substantial compat risk of continuing incubation of this API by enabling it by default in blink.  But I'm not an expert in this space, so perhaps I'm missing something?  Would we really be likely to have a web compat problem making breaking changes in this case if that's what the CSSWG decided to do?

[Koji Ishii]

Status updates on this property:

• Gecko started implementing this property (track bug), currently passes 6 out of 8 tests in csswg-test.
• WebKit filed an implement bug, though the work is not uploaded yet.

I'm in contact with both engineers in charge to help them and to ensure interoperable implementations. The work isn't fast due to higher priority items in their backlog, but we're making progress.

Do these look good enough to consider safe to move forward?

I've added the track bug links to the feature dashboard entry.

On Fri, Jan 20, 2017 at 4:02 AM, Rick Byers <rby...@chromium.org> wrote:

[Rick Byers]

I've reviewed the status in other browsers and the open issues in GitHub and it looks to me like the interop risk is now relatively low.  In particular, Gecko having landed an implementation that passes most of the tests is very promising.  I've left a few comments where I was unsure asking people to weigh in here with any specific concerns about the risk of blink shipping.  But barring specific proposals involving breaking changes that could be hard for us to take post-ship, I believe this now meets the bar for the web platform change process.

Of course if specific breaking changes are proposed before this hits Chrome stable, we should consider merging changes or temporarily disabling the feature in order to reach consensus.  But as far as I can see at this stage, there's not likely to be much concrete benefit to asking Koji to delay shipping any further.  Worst case and other implementations do choose to ship something different after we've already shipped, it seems highly likely that we could get away with breaking changes here after-the-fact (especially since the severity of breakage is likely to be low).

LGTM1

[Boris Zbarsky]

On 4/5/17 1:57 PM, Rick Byers wrote:
> In particular, Gecko
> having landed an implementation that passes most of the tests is very
> promising.

Two notes:

1) Passing some but not all the tests is generally not very meaningful
in terms of interop. Especially when there are as few tests as there
are in this case.

2) The intent to implement for this feature on the Gecko side has
received some fairly significant pushback on the grounds that the
feature doesn't actually do a good job of addressing the use cases it
purports to address. That includes pushback from one of the editors of
the spec in question.

Just FYI,
Boris

[Rick Byers]

On Wed, Apr 5, 2017 at 2:46 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

On 4/5/17 1:57 PM, Rick Byers wrote:

In particular, Gecko
having landed an implementation that passes most of the tests is very
promising.

Two notes:

1)  Passing some but not all the tests is generally not very meaningful in terms of interop.  Especially when there are as few tests as there are in this case.

I guess that depends on what the failures are.  I was assuming there were just a couple recognized bugs / areas of incomplete implementation.  Koji, can you look into exactly what is failing in Gecko  and why?  Is there agreement that it's just impl bugs?

2)  The intent to implement for this feature on the Gecko side has received some fairly significant pushback on the grounds that the feature doesn't actually do a good job of addressing the use cases it purports to address.  That includes pushback from one of the editors of the spec in question.

Thanks Boris, I hadn't seen that.  Here's the thread.  The concerns raised there definitely increase the interop risk above where I was thinking we were at.  I do agree with Jet's point that we should defer to developers on this front.  I'm certainly not in any position to evaluate the usefulness of a feature requested primarily from developers of CJK content.

I'm also personally fine with the priority of the related features differing between browsers.  If the feature fails to get any real adoption after Chrome ships then that's  good signal that it may not be worth investing in in other engines and we should ultimately remove it from Chrome.

What I think we should be most concerned about here is: if this features proves to be useful in the future, are there aspects of the design that we (web platform community collectively) are likely to regret.

Just FYI,
Boris

[Koji Ishii]

On Thu, Apr 6, 2017 at 4:47 AM, Rick Byers <rby...@chromium.org> wrote:

On Wed, Apr 5, 2017 at 2:46 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

1)  Passing some but not all the tests is generally not very meaningful in terms of interop.  Especially when there are as few tests as there are in this case.

I guess that depends on what the failures are.  I was assuming there were just a couple recognized bugs / areas of incomplete implementation.  Koji, can you look into exactly what is failing in Gecko  and why?  Is there agreement that it's just impl bugs?

​Yes, I've been working with the engineer. One turned out to be a test bug, PR submitted but isn't landed due to some travis failures. He confirmed locally that Gecko now passes the test, so the fix looks good.

The other, as far as I understand, turned out to be a bug in Ruby code, and he's working on the fix too (or fixed, I'm not sure.)​

2)  The intent to implement for this feature on the Gecko side has received some fairly significant pushback on the grounds that the feature doesn't actually do a good job of addressing the use cases it purports to address.  That includes pushback from one of the editors of the spec in question.

Thanks Boris, I hadn't seen that.  Here's the thread.  The concerns raised there definitely increase the interop risk above where I was thinking we were at.  I do agree with Jet's point that we should defer to developers on this front.  I'm certainly not in any position to evaluate the usefulness of a feature requested primarily from developers of CJK content.

I'm also personally fine with the priority of the related features differing between browsers.  If the feature fails to get any real adoption after Chrome ships then that's  good signal that it may not be worth investing in in other engines and we should ultimately remove it from Chrome.

What I think we should be most concerned about here is: if this features proves to be useful in the future, are there aspects of the design that we (web platform community collectively) are likely to regret.

​Allow me to add a bit of history; this feature used to try to cover both Latin and CJK use cases, but the feature to support Latin writing system was removed in January as it was too much controversial for Latin, and demands from CJK is strong. The feedback there looks like talking about Latin use cases, probably due to lack of my communication about that. I added the clarification to the spec.

[TAMURA, Kent]

LGTM2.

--

TAMURA Kent
Software Engineer, Google

[Philip Jägenstedt]

The test suite for this is now in https://github.com/w3c/web-platform-tests/tree/master/css/css-rhythm-1 and the single open PR is now merged.

Do all of the tests pass in Blink's implementation? I can't see this mentioned explicitly upthread. (We hope that this question will soon be trivial to answer with a wpt dashboard, right now it is not.)

[Koji Ishii]

On Thu, Apr 6, 2017 at 2:50 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

The test suite for this is now in https://github.com/w3c/web-platform-tests/tree/master/css/css-rhythm-1 and the single open PR is now merged.

Do all of the tests pass in Blink's implementation? I can't see this mentioned explicitly upthread. (We hope that this question will soon be trivial to answer with a wpt dashboard, right now it is not.)

​Yes, Canary with experimental feature turned on pass all of them, and we import this test suite...oh well, it looks like it was lost during the merge, I'll put it back.

[Philip Jägenstedt]

Sounds good, and it sounds like the 2 failures in Gecko that are accounted for. LGTM3.

+Quinten Yearsley, do you know if this was the only disappearance during the big merge?

[Koji Ishii]

Thank you Philip.

On Thu, Apr 6, 2017 at 3:00 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

+Quinten Yearsley, do you know if this was the only disappearance during the big merge?

​Found it, it wasn't listed explicitly before the merge (my bad, didn't add) but was imported as part of the "import if not listed" rule.​ Quinten added [ Skip ] since it was implicit.

I'll send CL to Quinten for review.

[Quinten Yearsley]

Thanks -- that's right, when moving the CSS tests over, I found some directories not listed in W3CImportExpectations, and added explicit skips for directories that don't have owners listed there at the time, since this made the move CL a bit smaller; if anybody finds directories missing after the merge, that might be why!