Intent to Implement and Ship: Unprefixed CSS Writing Modes with syntax updates

[Koji Ishii]

Contact emails ko...@chromium.org Spec Editor's Draft

https://drafts.csswg.org/css-writing-modes-3/

2nd CR, March 2014

http://www.w3.org/TR/css-writing-modes-3/

Summary CSS Writing Modes Level 3 without "webkit" prefix, along with syntax updates to the most recent CR.

A design document is available here.

Motivation

Blink implementation is not only "webkit" prefixed but also based on 2011 WD syntax. Given Firefox is going to ship unprefixed properties in November and Edge updated its syntax support also without prefix, unprefix and syntax updates help web developers to write less code in old syntax. Compatibility Risk Firefox: Public support Edge: Shipped Safari: No public signals Web developers: Strongly positive

Describe the degree of compatibility risk you believe this change poses Current open issues in the specification were all resolved in the last CSS F2F and edits are going to be in the 3rd CR expected soon. The 2nd CR got good implementer feedback and editors think the 3rd CR is significantly more stable. 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 None Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/5707470202732544 Requesting approval to ship?

Yes.

[TAMURA, Kent]

LGTM1.

It would improve compatibility, and almost no risk.

--

TAMURA Kent
Software Engineer, Google

[Ojan Vafai]

What's changed since the 2011 syntax? What is your plan for making the syntax match the current draft?

[Koji Ishii]

On Wed, Sep 16, 2015 at 9:02 AM, Ojan Vafai <oj...@chromium.org> wrote:

What's changed since the 2011 syntax? What is your plan for making the syntax match the current draft?

​Just name changes and two new keywords (marked at risk.) The plan is to support both up-to-date keywords and old keywords until prefixed ones are deprecated by property alias and value alias.

For new keywords, one (sideways-lr) is very easy to add, ​

the other (sideways-rl) will not be implemented in this cycle.

​

/koji

[Ojan Vafai]

Can you list what the name changes are?

[Koji Ishii]

On Wed, Sep 16, 2015 at 10:06 AM, Ojan Vafai <oj...@chromium.org> wrote:

Can you list what the name changes are?

I added to the "Syntax Updates" section of the doc.​ Green cells are to support, and green cells in old/different specs are aliases.

​/koji​

[Philip Jägenstedt]

On Wed, Sep 16, 2015 at 2:58 AM, 'Koji Ishii' via blink-dev <blin...@chromium.org> wrote:

On Wed, Sep 16, 2015 at 9:02 AM, Ojan Vafai <oj...@chromium.org> wrote:

What's changed since the 2011 syntax? What is your plan for making the syntax match the current draft?

​Just name changes and two new keywords (marked at risk.) The plan is to support both up-to-date keywords and old keywords until prefixed ones are deprecated by property alias and value alias.

Do you mean that the old and new keywords would all be supported for both the prefixed and unprefixed properties? To me, it would make most sense to leave the prefixed properties exactly as they are, and only support the currently-per-spec values in the unprefixed properties. Can you clarify which approach is intented?

[Koji Ishii]

Philip, sorry for not be clear enough.

​I didn't think about your suggestion, so in my original proposal, I intended to support old and new keywords in the unprefixed property, and make the prefixed version an alias to the unprefixed property.

Now thinking about your suggestion. So we make two properties, two separate parsers and serializers, for a field in ComputedStyle, do I understand correctly? I mean, your suggestion is not to create two separate fields in ComputedStyle, correct?

I don't have strong preferences, if that's generally work better and generally what we do, I'm happy to do so. I'm actually looking into past examples to learn now (started to wonder maybe I should have done so before sending intents.)

/koji

[Philip Jägenstedt]

I'm also not sure how previous cases like this have been handled, perhaps gradients are a good (or bad?) example of how to incompatible prefixed and unprefixed properties have co-existed?

To have a single computed style property sure sounds like less complexity, if it can be made to work. Even looking at the the big "Syntax Updates" table I'm not sure what the overlap in property values looks like. Are there any values that have been renamed in the spec since this was implemented, so that it will now be necessary to pick one name for both if there's just a single computed style field?

I hope that some style experts can weigh in on this.

Philip

[Koji Ishii]

I read recent patches to unprefix and their review comments, found that we mostly do what you suggested. One obvious benefit doing so is to have use-counters separately.

So I'll switch to what you suggested; keep prefixed versions untouched and add in prefixed versions, and they share fields in ComputerdStyle. I'll update the doc to reflect that.

Thank you for the feedback, Philip.

/koji

2015/09/17 0:17 "Philip Jägenstedt" <phi...@opera.com>:

[Timothy Loh]

Property aliases actually work fine with UseCounters as of M44 (they show up on chromestatus.com prefixed with alias-), but don't work too well when the properties are not identical.

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

[Koji Ishii]

Thank you Tim. I found another reason to prefer a separate property; CSSParserFastPaths::isValidKeywordPropertyAndValue can return old syntax as invalid for unprefixed properties, so I'm good with Philip's suggestion now.

/koji

[Philip Jägenstedt]

LGTM2, it sounds like the remaining issues can be dealt with in code review.

[Dimitri Glazkov]

LGTM3.

[Christian Biesinger]

I'm still a little concerned about the handling of orthogonal flows --
you mentioned that Firefox matches our behavior, but what about IE?
And the spec?

Thanks,
-Christian

[Christian Biesinger]

I'm still a little concerned about the handling of orthogonal flows --
you mentioned that Firefox matches our behavior, but what about IE?
And the spec?

Thanks,
-Christian

On Tue, Sep 22, 2015 at 1:20 PM, Dimitri Glazkov <dgla...@chromium.org> wrote:

[Koji Ishii]

Thank you owners!! Japan was holiday that I was late to reply.

Firefox 41, shipped this week, enabled unprefixed writing-mode, I was wrong to believe it'll be in 42.

Christian, I understand unprefix is not the end of development, rather, a way to get more user & web dev feedback for us to triage issues more correctly. So I keep it as an open issue and keep tracking, and you having a concern would be greatly appreciated. Most people I talk to do not seem to be even interested in.

IE does according to the spec wording, as I tested and as Rossen@ms told Ojan. Gecko and Blink are different from that, but people I talked to seem to see it as an important difference enough to pay attention to atm. I'll try to talk to dbaron at TPAC if he can be interested in, and hopefully user & web dev feedback can clarify how much priority it should have. I'm also interested in understanding your concerns better, let's talk.

/koji

[Christian Biesinger]

Fair enough. My main concern is that it sounds like float:left; will
behave differently in Blink/Gecko vs Edge in orthogonal writing modes.
But you're right that this can be worked out over time. And I think I
also don't fully understand how this behavior difference shows up for
users, maybe you can explain that a bit better?

Thanks!
-Christian

[Koji Ishii]

On Wed, Sep 30, 2015 at 11:37 PM, Christian Biesinger <cbies...@chromium.org> wrote:

Fair enough. My main concern is that it sounds like float:left; will
behave differently in Blink/Gecko vs Edge in orthogonal writing modes.
But you're right that this can be worked out over time.

​Floats should be fine.​ In most common cases, authors will not notice the difference, and yes for when there's a difference, we can work it out as we figure out more general solutions. I do wish to work with you and Ojan on that topic.

And I think I
also don't fully understand how this behavior difference shows up for
users, maybe you can explain that a bit better?

In short, the current logic does not support if children's layout depends on parent's available logical width. You may think it's almost always yes, but it's tricky, in orthogonal flow, this is actually very unlikely.

An example: <div><div class=vertical>vertical text</div><div>

This child div is vertical flow, so the space character (between "vertical" and "text") does not create a break opportunity for parent's width, only for child's width. When parent's logical width changes, it's merely changing max-logical-height for the child. Changes to max-height does not affect layout, so we support this example today.

Another example: <div>horizontal text <span class=vertical>vertical text</span></div>

The span in this case is an inline-block. This div has two break opportunities for parent's width (note not three,) so it may change line wrapping when parent's available width changes. This is not supported yet.

/koji