Intent to Implement and Ship: CSS Logical Properties and Values

[Oriol Brufau]

Contact emails
obr...@igalia.com, re...@igalia.com

Spec
https://drafts.csswg.org/css-logical-1/

Summary
Implement the properties and values introduced in CSS Logical Properties.
The flow-relative size properties and the flow-relative values for the text-align have been shipped already:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/4qEXWptfVHs/vhgeXGNzDgAJ
The flow-relative margin, padding and border longhand properties have a prefixed name, they should be aliased to the new standard properties.
Particularly we'll work in the ones that are ready for shipping according to the spec editors:
https://drafts.csswg.org/css-logical-1/#issue-b84049ec

Motivation
Provide the author with the ability to control layout through logical, rather than physical, direction and dimension mappings.

On top of that, this will make it easier to share tests with Firefox in the implementation of new specifications. For example, Firefox uses these properties extensively to test CSS Grid Layout, it'd be nice to have them available in Chromium to verify interoperability.

Interoperability risk
Firefox: Shipped flow-relative size, offset, margin, padding and border longhand properties, and flow-relative values for the text-align, float and clear.
https://developer.mozilla.org/docs/Web/CSS/CSS_Logical_Properties#Browser_compatibility
Edge: Under Consideration, High Roadmap Priority
https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/7438435-css-logical-properties
Safari: No public signals
https://bugs.webkit.org/show_bug.cgi?id=185977
Web developers: Some people are using PostCSS (there are few plugins there) to use these properties already due to lack of browsers support.
https://www.smashingmagazine.com/2018/03/understanding-logical-properties-values/

As part of this work we'll be adding tests to the WPT suite,  which has very few at this point:
http://w3c-test.org/css/css-logical/

Compatibility risk
These are new properties and values so there shouldn't be problems here.

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
https://bugs.chromium.org/p/chromium/issues/detail?id=538475

Link to entry on the Chrome Platform Status
https://www.chromestatus.com/features/6325742262550528

Requesting approval to ship?
Yes.

 

[Ian Kilpatrick]

Hi Oriol,

As per: https://docs.google.com/document/d/1vlTlsQKThwaX0-lj_iZbVTzyqY7LioqERU8DK3u3XjI/edit

Please file a TAG review for this feature. Specifically it would be good to get external review of this feature from people who aren't layout experts.

Please also work with the LayoutNG team to make sure that all tests pass with the new layout engine before shipping.

It would also be good if you could follow up this intent with a brief document to layout-dev@chromium, explaining a rough implementation plan for this feature.

It may also make sense to split this intent up into a "implement" and then "ship" at a later stage, as some of this might be non-trivial.

Thanks,

Ian

--
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/3d0e4bacba9c45db4a3d778b91ac636f%40igalia.com.

[PhistucK]

Does this really need a TAG review given that this was already shipped by another browser?

Also, looks like an intent to implement already (partially?) exists, just not by the same author -

https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/subject$3Aintent$20subject$3Alogical|sort:date/blink-dev/T4HsGFfxbGw/A4A9tD6vFgAJ

Oriorl - it would be great if you made sure issues are filed in the respective issue tracker of any non-supporting browser.

This is exciting!

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJL3UpT1FpGq7c6iFLT6coL%2BFvTEW7z3HynuzN-_oc_WO4WmGg%40mail.gmail.com.

[Christian Biesinger]

I found it hard to tell -- could you provide a list here of exactly which
properties you are suggesting to ship?

Thanks,
Christian

On Fri, May 25, 2018 at 10:04 AM Oriol Brufau <obr...@igalia.com> wrote:

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

[Ian Kilpatrick]

On Fri, May 25, 2018 at 3:47 PM PhistucK <phis...@gmail.com> wrote:

Does this really need a TAG review given that this was already shipped by another browser?

I was initially under the impression there were new properties/values being shipped, but I agree with Christian, explicitly listing the properties and values, (and where they have shipped) would be helpful.

Regardless, as per: https://docs.google.com/document/d/1vlTlsQKThwaX0-lj_iZbVTzyqY7LioqERU8DK3u3XjI/edit

There should be a TAG review in any intent to implement, or an explanation as to why it is being skipped.

Ian

[Manuel Rego Casasnovas]

Hi,

Just a summary our main goal is to be able to share more tests with
Firefox, so we plan to implement the things that Firefox has already
shipped since 2015.
And at the same time implement the things that were similar, simple
enough and ready for shipping.

It's true that we didn't detail all the properties and values, so let's
try to do a summary (anyway we'll write a detailed document as you
suggested). But we mention the fowllowing from the spec that is quite
relevant to this discussion:

As we said in the intent:

On 25/05/18 16:43, Oriol Brufau wrote:
> Particularly we'll work in the ones that are ready for shipping
> according to the spec editors:
> https://drafts.csswg.org/css-logical-1/#issue-b84049ec

That's basically two sections of the spec:

2. Flow-Relative Values
2.1. Logical Values for the caption-side Property
These is not needed as Chromium doesn't support "left" and "right".
So no work on this point.
2.2. Flow-Relative Values for the float and clear Properties
These are already supported by Firefox, it'd be adding 2 new values
"inline-start" and "inline-end".
Firefox already support those.
2.3. Flow-Relative Values for the text-align Property
Here there's no work again as this has been already shipped
in Chromium.
2.4. Flow-Relative Values for the resize Property
Again adding two values "block" and "inline" to the property.
This is not supported by Firefox yet:
https://bugzilla.mozilla.org/show_bug.cgi?id=1464786

4 Flow-Relative Box Model Properties
4.1 Logical Height and Logical Width:
These have been already shipped in Chromium.
4.2 Flow-relative Margins:
Firefox already support these, and Chromium too
with prefixed properties.
Shorthands are not supported on Firefox yet
(https://bugzilla.mozilla.org/show_bug.cgi?id=1370404),
but don't seem controversial. So our idea was to implement them too.
4.3 Flow-relative Offsets:
Firefox support those with an old name using "offset-" prefix
instead of "inset-"
(https://bugzilla.mozilla.org/show_bug.cgi?id=1464782).
Chromium doesn't support those prefixed so it'd be new properties.
4.4 Flow-relative Padding:
Same situation than for margins.
4.5 Flow-relative Borders
Same situation than for margins.
4.6 Four-Directional Shorthand Properties:
These are not ready yet according to spec editors,
so this would be out of the intent.

On 25/05/18 19:19, 'Ian Kilpatrick' via blink-dev wrote:
> As
> per: https://docs.google.com/document/d/1vlTlsQKThwaX0-lj_iZbVTzyqY7LioqERU8DK3u3XjI/edit
> Please file a TAG review for this feature. Specifically it would be good
> to get external review of this feature from people who aren't layout
> experts.

This has been discussed long time ago in the CSSWG. First when Firefox
shipped them (back in 2015):
https://lists.w3.org/Archives/Public/www-style/2015Jul/0040.html

Then when Chromium shipped a few by the end of 2016:
https://lists.w3.org/Archives/Public/www-style/2016Dec/0059.html

In that case there was no TAG review:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/4qEXWptfVHs/vhgeXGNzDgAJ

I'm never sure when this is required, we could ask for a TAG review
but we felt that the previous points were making it not needed.

> Please also work with the LayoutNG team to make sure that all tests pass
> with the new layout engine before shipping.

Yes sure, the prefixed properties already work on LayoutNG
but we'll make sure that the new ones keep working too.

> It would also be good if you could follow up this intent with a brief
> document to layout-dev@chromium, explaining a rough implementation plan
> for this feature.

Ok, good suggestion we'll prepare a document with the detailed
information of all the properties/values and the information about them.

> It may also make sense to split this intent up into a "implement" and
> then "ship" at a later stage, as some of this might be non-trivial.

In the past some of these properties were shipped directly.
That's why we didn't consider the point to develop them behind a runtime
flag.

Do you think there would be some stuff particularly complex?

In most of the cases it's adding a new property to replace a
prefixed/non-standard one, and a few shorthands. So we don't see a huge
benefit of doing this behind a flag.
Still we could work behind a flag if it's required, just sharing our
thoughts on this.

Thank you very much for the feedback,
Rego

[Philip Jägenstedt]

This isn't written down as policy, but I think that when something has
already shipped in another browser and the focus is to match that browser
and share tests, doing a round of TAG review is not going to be very
valuable. Requesting one for the feature as a whole might be worthwhile,
but I wouldn't consider it blocking, and any changes that come out of it
would affect Firefox as well.

rego@, as you point out, https://wpt.fyi/results/css/css-logical is not
very big, and the fact that all tests are passing in Chrome and Firefox
must mean the bits discussed here are untested.

As of recently we have experimental versions of Chrome and Firefox running,
with experimental web platform features enabled. A benefit of that is that
we should be able to see in
https://wpt.fyi/results/css/css-logical?label=experimental and
https://wpt.fyi/results/css/css-logical?label=chrome before shipping that
tests now match Firefox which previously were failing.

rego@, would it be annoying overhead to use a flag for this, or do you
think seeing that comparison up front is valuable enough to do it?

LGTM1 for either approach.
On Mon, May 28, 2018 at 11:00 AM Manuel Rego Casasnovas <re...@igalia.com>
wrote:

> --
> 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/9b02a794-105e-e654-9301-a48d9b53886e%40igalia.com
.

[Emilio Cobos Álvarez]

Note that there are tests for these in mozilla-central.

From a quick skim, I found a few for logical float values in[1], and
others upstreamed already to WPT like[2].

There's also test_logical_properties.html[3], I've probably missed a
bunch of others.

It'd be great to upstream some of those rather than duplicating work. I
can help with that if needed :)

-- Emilio

[1]:
https://searchfox.org/mozilla-central/rev/5a744713370ec47969595e369fd5125f123e6d24/layout/reftests/floats/reftest.list#99-102
[2]:
https://github.com/web-platform-tests/wpt/blob/master/css/vendor-imports/mozilla/mozilla-central-reftests/writing-modes-3/logical-physical-mapping-001.html
[3]:
https://searchfox.org/mozilla-central/rev/5a744713370ec47969595e369fd5125f123e6d24/layout/style/test/test_logical_properties.html

[Manuel Rego Casasnovas]

On 28/05/18 17:44, 'Philip Jägenstedt' via blink-dev wrote:
> rego@, as you point out, https://wpt.fyi/results/css/css-logical is not
> very big, and the fact that all tests are passing in Chrome and Firefox
> must mean the bits discussed here are untested.

5 out of 6 tests there were added when Chromium shipped part of this:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/4qEXWptfVHs/vhgeXGNzDgAJ

But as Emilio pointed out it seems a good idea to upstream Mozilla tests
and move them to WPT as part of this work.

> As of recently we have experimental versions of Chrome and Firefox running,
> with experimental web platform features enabled. A benefit of that is that
> we should be able to see in
> https://wpt.fyi/results/css/css-logical?label=experimental and
> https://wpt.fyi/results/css/css-logical?label=chrome before shipping that
> tests now match Firefox which previously were failing.
>
> rego@, would it be annoying overhead to use a flag for this, or do you
> think seeing that comparison up front is valuable enough to do it?

TBH, I don't think is going to be very beneficial to develop behind a
flag the new property, while the -prefixed alias is shipping. It's like
preventing authors for starting to use the standard properties until we
finish all of them.
Also Chromium didn't do it in the previous intent for part of this
stuff, but we're open to do it if people think it's important.

Thanks,
Rego

[Philip Jägenstedt]

No, it's not very important, I was just looking for a guinea pig for using the new experiment runs in Intent to Ship. If it creates more work then it's a distraction.

One thing that might be marginally useful, though, is to check that added tests actually fail I'm Chrome stable. It's pretty easy to have tests pass for the wrong reason and this is a safeguard.

Still LGTM1.

Having tests from mozilla-central in WPT would be fabulous!

[Oriol Brufau]

Hi all,

we wrote a document detailing the explicit list of proposed features to
be implemented, and their current implementation status in Firefox and
Chromium:
https://docs.google.com/document/d/111ol5b6BHHIiQyOzybs8PVjn0MqKvyFzP-fwGC5-fuA

I will try to upstream the tests from Firefox into WPT. Emilio, I will
ask you if I have some problem, thanks for your offer to help.

 -- Oriol Brufau


El 26/5/18 a les 01:06, Christian Biesinger ha escrit:

[fantasai]

On 05/25/2018 01:19 PM, 'Ian Kilpatrick' via blink-dev wrote:
> Hi Oriol,
>
> As per: https://docs.google.com/document/d/1vlTlsQKThwaX0-lj_iZbVTzyqY7LioqERU8DK3u3XjI/edit
> Please file a TAG review for this feature. Specifically it would be good to get external review of
> this feature from people who aren't layout experts.

We haven't had TAG review specifically, but i18n reviewed it ages ago (in fact,
it was one of their top requests to the CSSWG for years).

HTML also has a dependency on these properties for the UA style sheet: they were
necessary to implement HTML default styling in a world where writing-mode exists,
so both the WHATWG and W3C specs rely on it.

> Please also work with the LayoutNG team to make sure that all tests pass with
> the new layout engine before shipping.
> It would also be good if you could follow up this intent with a brief document to
> layout-dev@chromium, explaining a rough implementation plan for this feature.

From what I understand, these were implemented already (-webkit-prefixed)
as part of Hyatt's writing-mode implementation, they just need aliasing
into the standard syntax.

> It may also make sense to split this intent up into a "implement" and then
> "ship" at a later stage, as some of this might be non-trivial.

Aliasing should be trivial. :)

~fantasai

[Christian Biesinger]

Thank you! I'm not an API owner but shipping this sounds good to me as long
as the CSSWG is happy, and fantasai's email sounds like they are

Christian

[fantasai]

On 05/29/2018 02:18 PM, Christian Biesinger wrote:
> Thank you! I'm not an API owner but shipping this sounds good to me as long
> as the CSSWG is happy, and fantasai's email sounds like they are

Yup! CSSWG cleared it for shipping when Firefox brought up the issue
awhile back. You can't ship writing-mode for the Web without this
feature.

More info in the FPWD announcement at
https://lists.w3.org/Archives/Public/www-style/2017Dec/0043.html

~fantasai

[Ian Kilpatrick]

Thanks for the document - that's awesome.

Re tag review:

Based off the document there looks like there are two new pieces being implemented & shipped for the first time (and that we don't have prefixed).

Specifically the shorthands {margin,border,padding}-{block,inline} and the inset-* properties.

If you think that an additional review for these new parts would be valuable it might be good to file for a review. (I personally find the tag a good sanity check even for simple things, but this also seems understood well enough). But completely up to you.

Re implementation:

I'll follow up with the implementation plan, depending on how its done, there might be some new areas for testing with the new things :).

Thanks,

Ian

 

[sligh...@chromium.org]

Hey all!

We added TAG review to the process a few years back and more recently moved it earlier in the process because it gives us a way to get reasonably wide review about how things fit into the architecture, specifically because our process explicitly isn't gated on any particular Working Group publication status. We often block (or require Origin Trials for) features which are "cleared to ship" by WGs and ship features without any formal WG. All of this is working-as-intended.

While it's true that a feature already shipping in one browser means it's harder to change our minds about a design, that's by no means a reason not to file for TAG review and, at the limit, not a reason to avoid changing the design in response to feedback.

Thanks for filing for a review!: https://github.com/w3ctag/design-reviews/issues/new

Regards

[Oriol Brufau]

Thanks for the explanation, I filed for TAG review in https://github.com/w3ctag/design-reviews/issues/286

 -- Oriol Brufau

El 30/5/18 a les 00:56, sligh...@chromium.org ha escrit:

[Daniel Bratell]

I looked through the list in
https://docs.google.com/document/d/111ol5b6BHHIiQyOzybs8PVjn0MqKvyFzP-fwGC5-fuA
and I wonder what you intend to do with the ones you list as "unprefix".
Will you remove the old prefixed property or will it remain as an alias?

Adding these properties seem like a good thing. Removing the prefixed old
versions would be good, but comes with risk that demands some care.

/Daniel

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

[Rick Byers]

We discussed this in the API owners meeting today (Ojan, Yoav, Alex, Daniel, Chris, Rick, and Philip).

The serialization of the existing prefixed properties is going to change (since they will become aliases for the unprefixed properties), right?  There's probably a bit of compat risk there, but I'm not sure if we've seen any problems like that in practice so I don't think we need to do anything beyond the usual (land and be prepared to revert and follow-up on any report of serious breakage).

Do you have a patch for this work already?  There was some debate in the meeting about how "big" of a change this really is.  Glancing through the doc, it looks like a lot of properties, but mostly it's just unprefixing and adding shorthands, right?

In the case of simple unprefixing, I agree the overhead of adding a RuntimeEnabledFeature flag is probably not worth the effort.  IIRC it's a bit of a pain to handle the case where only the unprefixed version of an alias is behind a flag, while the prefixed one isn't (can't use alias_for, or need special code in the parser specifically to detect these cases and check the flag).  But it's fairly unusual to add brand new properties without first landing them behind a flag (since new properties often involve a bit of back and forth on bugs, open spec issues, web platform tests, etc.).  It's also should be pretty trivial to do (just add a "runtime_flag" to the associated entries in CSSProperties.json5).

What do you think of landing the new properties now behind a flag (which, I think, would also address the "implementation plan" questions), then following up lafter with a trivial CL to add the unprefixed aliases and flip the flag to stable? This also should make things simpler in the unlikely case you need to revert temporarily (eg. for web compat reasons).

We'd also like to see decent WPT test coverage exist (at least in PR form) for all these properties before approving this intent.

Rick

--
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/op.zjvtrcnorbppqq%40cicero2.linkoping.osa.

[Oriol Brufau]

> I wonder what you intend to do with the ones you list as "unprefix". Will you remove the old prefixed property or will it remain as an alias?

We are not going to kill the prefixed properties at this stage, we intend to preserve them as an alias of the new properties.

> The serialization of the existing prefixed properties is going to change (since they will become aliases for the unprefixed properties), right?

Yes, the serialization will change in cases like

var el = document.createElement("div");
el.style.webkitMarginBefore = "5px";
el.style.cssText; // "margin-block-start: 5px;"

But this was also the case for flow-relative sizing properties like block-size, and they have been shipped already.

> Do you have a patch for this work already?

You can see the patch for flow-relative margin longhands in https://chromium-review.googlesource.com/c/chromium/src/+/1075050

The code for paddings and borders should be analogous. I also wrote a patch for the margin shorthands, but not behind a flag.

> What do you think of landing the new properties now behind a flag

The flag can be added if you think it's needed, I will look into that.

-- Oriol Brufau

El 31/5/18 a les 18:56, Rick Byers ha escrit:

[Oriol Brufau]

Contact emails

obr...@igalia.com, re...@igalia.com

Spec

https://drafts.csswg.org/css-logical-1/

Summary

Complete support for the following sections of CSS Logical Properties and Values spec:

• 2. Flow-Relative Values
• 4. Flow-Relative Box Model Properties (except 4.6 Four-Directional Shorthand Properties).

Some of them are already implemented, this intent covers the implementation (behind a flag) of:

• 'inline-start' and 'inline-end' values for 'float' and 'clear'.
• 'block' and 'inline' values for 'resize'.
• Flow-relative offset longhand and shothand properties.
• Flow-relative margin, padding and border shorthand properties.

See https://docs.google.com/document/d/111ol5b6BHHIiQyOzybs8PVjn0MqKvyFzP-fwGC5-fuA/ for details.

TAG review request: https://github.com/w3ctag/design-reviews/issues/286

Motivation

Provide the author with the ability to control layout through logical, rather than physical, direction and dimension mappings.

Interoperability risk

Firefox: Some things have already shipped (the new values for 'float' and 'clear'). Also the flow-relative offset longhands but with the offset- prefix (old syntax) instead of inset-. Regarding the shorthands there are no negative comments in the related bugs (https://bugzilla.mozilla.org/show_bug.cgi?id=1323940).

Edge: Under Consideration, High Roadmap Priority

https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/7438435-css-logical-properties

Safari: No public signals

https://bugs.webkit.org/show_bug.cgi?id=185977

Web developers: Some people are using PostCSS (there are few plugins there) to use these properties already due to lack of browsers support.

https://www.smashingmagazine.com/2018/03/understanding-logical-properties-values/

Almost none of the proposed features is covered by the WPT suite, so as part of this work we'll be adding tests to http://w3c-test.org/css/css-logical/ 

Compatibility risk

These are new properties and values so there shouldn't be problems here.

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

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

Link to entry on the Chrome Platform Status

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

Requesting approval to ship?

No.

[Oriol Brufau]

[Oriol Brufau]

As suggested, the new features will be implemented behind a flag.

Therefore, we abandon this intent and split it into two:

• Intent to Implement and Ship: CSS flow-relative margins, paddings and borders
  https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/tkN-r119eNc
• Intent to Implement: CSS flow-relative values and box model properties
  https://groups.google.com/a/chromium.org/d/msg/blink-dev/48OwfwZrbvI/A1XZFGkzAwAJ

By mistake I initially sent the latter as a reply to this thread, and Google Groups got confused when I sent it again as a new thread. Sorry.

-- Oriol Brufau

[Oriol Brufau]

It seems your PR is about flow-relative margin longhands, which should
now be covered by https://github.com/web-platform-tests/wpt/pull/11324

What's missing are tests for the shorthand properties like
'margin-block' and 'margin-inline'.

-- Oriol Brufau

El 6/6/18 a les 20:15, Geoffrey Sneddon ha escrit:

> On Wed, Jun 6, 2018 at 2:38 PM, Oriol Brufau <obr...@igalia.com> wrote:
>> Almost none of the proposed features is covered by the WPT suite, so as part
>> of this work we'll be adding tests to http://w3c-test.org/css/css-logical/

> There's a PR at https://github.com/web-platform-tests/wpt/pull/5284 to
> add some tests that's been sitting around for almost a year and a
> half, if someone wants to review it.
>
> /g

[Rick Byers]

Sounds great, thanks Oriol!  I'm looking forward to seeing these available via chrome://flags/#enable-experimental-web-platform-features

--
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/d67fd11d-5f36-19a8-9f6e-3fbbeee0ad46%40igalia.com.

[Geoffrey Sneddon]

On Wed, Jun 6, 2018 at 2:38 PM, Oriol Brufau <obr...@igalia.com> wrote:

> Almost none of the proposed features is covered by the WPT suite, so as part
> of this work we'll be adding tests to http://w3c-test.org/css/css-logical/