Intent to Deprecate and Remove: -webkit-{min-,max-}logical-{width,height}

You wrote "IE/FF doesn't support this", but did you check Edge? If Edge has implemented webkit-prefixed things, it's a good indication that some sites depend on it in an important way. And if not, it gives us some confidence that the compat impact will be acceptable. Even if this is a Blink/WebKit-only thing, it's probably not true that the compat risk is none.

Also, when this is removed, what advice would you give to authors that depend on it? Is there a simple replacement, or might one have to make big changes or even depend on scripts to get the same effect?

The usage looks promising, but I've filed https://github.com/GoogleChrome/chromium-dashboard/issues/439 for chromestatus.com to stop treating 0.03% as a special cut-off.

PhistucK

unread,

Dec 13, 2016, 3:19:35 AM12/13/16

to Philip Jägenstedt, Xing, blink-dev

Here is the original draft specification revision (it took a while, but my archeology paid off) -

https://dev.w3.org/cvsweb/~checkout~/csswg/css3-writing-modes/Attic/Overview.html?rev=1.11;content-type=text%2Fhtml;hideattic=0#logical-width

The current draft does not mention those anymore, though.

However, there are no writing-mode-aware alternatives implemented in Chrome (Firefox 41 has them, though. Search for min-block-size). The CSS Logical Properties specification specifies new properties (block-size, max-block-size, min-block-size...) -

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

Unless the catalog is outdated, Edge does not seem to support those properties (at least in its CSSOM) -

https://developer.microsoft.com/en-us/microsoft-edge/platform/catalog/?page=1&q=logical

☆PhistucK

--
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+unsubscribe@chromium.org.

Xu, Xing

unread,

Dec 13, 2016, 3:25:03 AM12/13/16

to PhistucK, Philip J?genstedt, blink-dev

Yes, Edge is not support this according to this:

https://msdn.microsoft.com/en-us/library/mt270097%28v=vs.85%29.aspx

☆PhistucK

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

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/VbPI65jBMIc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.

PhistucK

unread,

Dec 13, 2016, 3:34:52 AM12/13/16

to Xu, Xing, Philip J?genstedt, blink-dev

Yeah, the problem is that documentation is not enough (and it generally shows the CSSOM, which may not support it while the CSS engine may, for example). Can you verify with the actual browser?

☆PhistucK

☆PhistucK

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

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/VbPI65jBMIc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to blink-dev+unsubscribe@chromium.org.

Xu, Xing

unread,

Dec 13, 2016, 3:51:14 AM12/13/16

to PhistucK, Philip J?genstedt, blink-dev

With this case http://jsfiddle.net/edelman/CKRZg/ on:

Edge(20.10240.16384.0): different width;

IE: different width;

FF(35.0.1/Ubuntu): different width;

chrome(54.0.2840.99 m): same width(Works).

But this case only cover webkit-min-logical-width. Will try other three css properties.

☆PhistucK

☆PhistucK

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

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/VbPI65jBMIc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/VbPI65jBMIc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.

Christian Biesinger

unread,

Dec 13, 2016, 10:16:56 AM12/13/16

to Xu, Xing, PhistucK, blink-dev, Philip Jägenstedt

As a non-API owner: I'd be happy to see these gone, but we should
definitely keep the plumbing because we do eventually want to support
min-block-size, etc.:
https://drafts.csswg.org/css-logical-props/#propdef-min-block-size

So, perhaps the way to do this is instead of fully removing this,
rename to {min,max}-{block,inline}-size and put behind a flag at the
same time.

Also -- this can easily be separate but we should look at
-webkit-logical-{width,height} too.

Christian

PhistucK

unread,

Dec 13, 2016, 10:19:46 AM12/13/16

to Christian Biesinger, Xu, Xing, blink-dev, Philip Jägenstedt

Huh, I wonder why they were not included in this intent, they have very low usage as well and are very related.

☆PhistucK

> email to blink-dev+unsubscribe@chromium.org.

>
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "blink-dev" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/chromium.org/d/topic/blink-dev/VbPI65jBMIc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> blink-dev+unsubscribe@chromium.org.

>
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "blink-dev" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/chromium.org/d/topic/blink-dev/VbPI65jBMIc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> blink-dev+unsubscribe@chromium.org.

Philip Jägenstedt

unread,

Dec 13, 2016, 10:29:35 AM12/13/16

to Christian Biesinger, Xu, Xing, PhistucK, blink-dev

So, is each of -webkit-{min,max}-logical-{width,height} an exact alias of {min,max}-{block,inline}-size? I assume not, but what is the relationship.

If there is some set of unprefixed properties that can trivially be implemented on top of existing plumbing, and there could then be simple transition guidance for the prefixed properties, then I think it'd be preferable to first implement/ship the unprefixed ones, and then deprecate/remove the prefixed. Is there such a mapping?

Christian Biesinger

unread,

Dec 13, 2016, 11:56:31 AM12/13/16

to Philip Jägenstedt, Xu, Xing, PhistucK, blink-dev

I mean, I haven't done a full analysis but I'm pretty sure they are
exact aliases -- where do you think they differ?

Christian

Philip Jägenstedt

unread,

Dec 13, 2016, 3:40:35 PM12/13/16

to Christian Biesinger, Xu, Xing, PhistucK, blink-dev

I just noticed that one set of width/height in the name and the other has size. Looks like the unprefixed properties only work in the writing direction. Maybe this is also true of the prefixed attributes, so that depending on the writing direction half of the properties just do nothing? If so it'd be easy enough to describe what action web developer should take.

Christian Biesinger

unread,

Dec 13, 2016, 3:45:51 PM12/13/16

to Philip Jägenstedt, Xu, Xing, PhistucK, blink-dev

Here's an example that demonstrates how they work:
http://plexode.com/eval3/#s=aekVQXANJVQMbAx1yAXgePQN5GwFKT02fRg5DTVBETBwBi51IU0ZGT6oOWEZDTEpVDk6fDqZISkRCTQ6CnRIREVFZs7W3ubu9v8HDDoOdE8nLHJofHRByHz1P45WXmZudn6FPo6Wnqautr7HNtri6vE++UMDCYjGALIZTMAK0e7QfT8fzVa4BbMEVRYKa5T5IXZQIpGTpXIxTKrUYhNKbcAbecAfAZeAA

min-logical-width, like min-inline-size, applies in the block
direction. So, in horizontal-tb this is the width, in the vertical
modes it is the height. And accordingly for min-logical-height /
min-block-size. That's the same for the -webkit- ones and the standard
ones.

Christian

Philip Jägenstedt

unread,

Dec 13, 2016, 4:56:46 PM12/13/16

to Christian Biesinger, Xu, Xing, PhistucK, blink-dev

Thanks Christian! So

Xing, would you be willing to first take a stab at shipping the corresponding unprefixed properties, so that there's a simple migration path for anyone who's actually using -webkit-{min,max}-logical-{width,height}?

Including -webkit-logical-{width,height} => {inline,block}-size would also make sense to do at the same time, it seems.

Christian Biesinger

unread,

Dec 13, 2016, 5:13:00 PM12/13/16

to Philip Jägenstedt, Tab Atkins, Xu, Xing, PhistucK, blink-dev

+Tab

I would suggest double-checking with the CSSWG that this is ready to
ship before we do that.

But it looks like Firefox does ship this:
http://plexode.com/eval3/#s=aekVQXANJVQMbAx1yAXgePQN5GwFKT02fRg5DTVBETBwBi51IU0ZGT6pOnw6foU+jip0SERFRWbO1padMDrsBE77AHJofHRByHz1P1JWXmZudt6KkpqiqrAGusLIBtE+2oN3Ivb/B58PfxsjK76pYU0pVn0gOJxQIpGTpXIxTfhEIRNBxNKbNAbPaIfAZeAA=

Don't know about other browsers.

Christian

fri...@jeka.info

unread,

Dec 14, 2016, 1:03:38 AM12/14/16

to blink-dev, foo...@chromium.org, taba...@google.com, xin...@intel.com, phis...@gmail.com

min-block-size
min-inline-size
max-block-size
max-inline-size

was implementent unprefixed in Gecko 38 behind a flag

https://bugzilla.mozilla.org/show_bug.cgi?id=1117983#c29

https://developer.mozilla.org/en-US/Firefox/Releases/38#CSS

and ships enabled by default with Firefox 51 (January 2017)

https://bugzilla.mozilla.org/show_bug.cgi?id=1297097#c26

j.j.

PhistucK

unread,

Dec 14, 2016, 2:29:41 AM12/14/16

to fri...@jeka.info, blink-dev, Philip Jägenstedt, Tab Atkins, Xing

Oh, are the release notes for Firefox 41 wrong?

https://developer.mozilla.org/en-US/Firefox/Releases/41

They state that they are "activated by default" and "now available".

The example in https://developer.mozilla.org/en/docs/Web/CSS/min-block-size works for me using Firefox 50, so already enabled.

☆PhistucK

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

Manuel Rego Casasnovas

unread,

Dec 14, 2016, 6:45:45 AM12/14/16

to blin...@chromium.org

On 14/12/16 08:28, PhistucK wrote:
> Oh, are the release notes for Firefox 41 wrong?
> https://developer.mozilla.org/en-US/Firefox/Releases/41
> They state that they are "activated by default" and "now available".

Yeah I believe Firefox shipped them more than 1 year ago,
despite the spec is not even a Working Draft now:
https://drafts.csswg.org/css-logical-props/

BTW, there's already a bug to track this: http://crbug.com/538475

Anyway I agree with Christian that removing them completely don't seem
like a good idea, and it might be better to the rename (or needed
modifications) as part of the deprecation of the prefixed properties.

Note that some Firefox tests use these logical properties extensively
(for example the Grid Layout tests), so having support for them on
Chrome too will be really useful to verify interoperability.

Cheers,
Rego

Boris Zbarsky

unread,

Dec 14, 2016, 10:06:42 AM12/14/16

to PhistucK, fri...@jeka.info, blink-dev, Philip Jägenstedt, Tab Atkins, Xing

On 12/14/16 2:28 AM, PhistucK wrote:
> Oh, are the release notes for Firefox 41 wrong?
> https://developer.mozilla.org/en-US/Firefox/Releases/41
> They state that they are "activated by default" and "now available".

The release notes are correct. The timeline is:

1) Firefox 38 shipped the properties behind a flag. This is the same
flag that controls whether CSS writing modes are enabled.

2) Firefox 41 switched the default value of the flag to "enabled". The
flag could still be disabled manually.

3) Firefox 51 removed the flag altogether.

-Boris

PhistucK

unread,

Dec 14, 2016, 10:11:29 AM12/14/16

to Boris Zbarsky, fri...@jeka.info, blink-dev, Philip Jägenstedt, Tab Atkins, Xing

Cool. :)

☆PhistucK

Boris Zbarsky

unread,

Dec 14, 2016, 10:13:31 AM12/14/16

to Manuel Rego Casasnovas, blin...@chromium.org

On 12/14/16 6:45 AM, Manuel Rego Casasnovas wrote:
> Yeah I believe Firefox shipped them more than 1 year ago,
> despite the spec is not even a Working Draft now:
> https://drafts.csswg.org/css-logical-props/

Indeed. Note that this did come up during the intent to ship discussion
at
https://groups.google.com/d/msg/mozilla.dev.platform/zQgw_4WeBkc/grEuQBBaF-IJ
and following. The decision was made that shipping writing modes
without these properties was not really a good idea because they're much
less usable, especially because other UAs were in fact already shipping
these properties, albeit under different names.

It's not an ideal situation, I agree; we all wish this draft were
further along. Unfortunately, the CSSWG hasn't been doing a great job
of pushing critical stuff on through the process past editor's draft,
even in cases when it's fairly stable. :(

-Boris

Christian Biesinger

unread,

Dec 14, 2016, 12:23:19 PM12/14/16

to Boris Zbarsky, Manuel Rego Casasnovas, blink-dev

For now I emailed www-style about the status of this spec.
https://lists.w3.org/Archives/Public/www-style/2016Dec/0059.html

Christian

Xing

unread,

Dec 14, 2016, 8:53:59 PM12/14/16

to blink-dev, cbies...@chromium.org, xin...@intel.com, phis...@gmail.com

Thanks Philip, I am OK to do this.
But should we ship -webkit-{min,max}-logical-{width,height} ==> -{min,max}-logical-{width,height} first? If so, should I sent a new Intent to Ship for this?

As to -webkit-logical-{width,height} ==> {inline,block}-size, Christian is confirm this with w3c, it seems need more investigation. Maybe we can handle this latter.

PhistucK

unread,

Dec 15, 2016, 1:55:28 AM12/15/16

to Xing, blink-dev, Christian Biesinger

I think it would be very unpredictable for web developers to be able to use min-foo-size and max-foo-size but not foo-size. They come together.

☆PhistucK

Xu, Xing

unread,

Dec 15, 2016, 2:39:19 AM12/15/16

to PhistucK, blink-dev, Christian Biesinger

OK, If I didn’t missing anything, first implement this:

-webkit-{min,max}-logical-{width,height} ==> -{min,max}-logical-{width,height}

-webkit-logical-{width,height} ==> -logical-{width,height}

Regards,

Xing

PhistucK

unread,

Dec 15, 2016, 2:43:29 AM12/15/16

to Xu, Xing, blink-dev, Christian Biesinger

Mmm no, -webkit-(foo-)logical-bar should not be unprefixed. It should be kept and probably aliased as (foo-)(block or inline)-size.

☆PhistucK

To unsubscribe from this group and all its topics, send an email to blink-dev+unsubscribe@chromium.org.

Message has been deleted

Xing

unread,

Dec 15, 2016, 3:23:14 AM12/15/16

to blink-dev, xin...@intel.com, cbies...@chromium.org

Yes, here ==> not means replacement, but add the unprefixed version.

I summarize it here(According to https://drafts.csswg.org/css-writing-modes-3/#logical-to-physical):
-webkit-{min,max}-logical-{width,height}
==>-{min,max}-{inline,block}-size

-webkit-logical-{width,height}
==> {inline,block}-size

☆PhistucK

To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.

PhistucK

unread,

Dec 15, 2016, 4:25:08 AM12/15/16

to Xing, blink-dev, Christian Biesinger

Yes, that seems correct (the suggestion to which I replied used the old property names, which is why I rejected it). :)

It would be nice to think about the rest of the changes that Firefox implemented (for logical margin, padding and border longhands). I believe most of them, if not all of them, have WebKit-prefixed equivalents already. Effectively matching their support should probably be really easy (I hope there are tests), since everything is apparently supported using other names currently.

https://developer.mozilla.org/en-US/Firefox/Releases/41 lists the implemented changes.

Unfortunately, Firefox did not implement the shorthand changes (the preceding logical keyword), so Blink can skip that as well in the meantime.

☆PhistucK

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

Manuel Rego Casasnovas

unread,

Dec 15, 2016, 5:24:44 AM12/15/16

to PhistucK, Xing, blink-dev, Christian Biesinger

On 15/12/16 10:24, PhistucK wrote:
> It would be nice to think about the rest of the changes that Firefox
> implemented (for logical margin, padding and border longhands). I
> believe most of them, if not all of them, have WebKit-prefixed
> equivalents already. Effectively matching their support should probably
> be really easy (I hope there are tests), since everything is apparently
> supported using other names currently.
> https://developer.mozilla.org/en-US/Firefox/Releases/41 lists the
> implemented changes.

As I mentioned earlier in the thread all this stuff is analyzed at
http://crbug.com/538475

I agree with PhistucK that it'd be nice to review it and work on all the
different changes required. Some stuff are just aliases, other might
need some small tweaks, and other are not implemented at all.

IMHO, on a first sight it might be probably a good idea to add the new
properties before deprecating anything (and keep the old prefixed
properties as they're right now). Then we could start
deprecating/removing stuff that is not widely used (like the properties
suggested in this intent).

Just my 2 cents,
Rego

PhistucK

unread,

Dec 15, 2016, 7:34:18 AM12/15/16

to Manuel Rego Casasnovas, Xing, blink-dev, Christian Biesinger

Anyway - this will indeed need an intent to implement (and ship), I suspect it will be an easy one. :)

☆PhistucK

Philip Jägenstedt

unread,

Dec 15, 2016, 10:30:14 AM12/15/16

to PhistucK, Manuel Rego Casasnovas, Xing, blink-dev, Christian Biesinger

Right, I think first shipping the unprefixed replacements and then revisiting this intent would be good.

Reply all

Reply to author

Forward