Intent to remove: -webkit-border-fit

169 views
Skip to first unread message

Xianzhu Wang

unread,
Sep 22, 2014, 6:59:17 PM9/22/14
to blink-dev

Primary eng (and PM) emails

wangx...@chromium.org


Summary

Remove support of -webkit-border-fit CSS property


Motivation

- it was added a long time ago (in 2007) and has not been fully implemented yet

- it complicates the code

- Safari says it's an unsupported WebKit feature (https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariCSSRef/Articles/StandardCSSProperties.html)

- layout tests containing it produce no difference with it removed

- it's not in css3 background-and-border spec (http://www.w3.org/TR/css3-background/)

Compatibility Risk

None, because the property makes no visual difference.


Requesting approval to remove too?

Yes.

PhistucK

unread,
Sep 23, 2014, 2:34:14 AM9/23/14
to Xianzhu Wang, blink-dev
It existed in CSS 3 Border module (2002) - http://www.w3.org/TR/2002/WD-css3-border-20021107/#the-border-image-fit - until it merged into CSS 3 Backgrounds and Borders module (2008).

As long as it really does nothing, it seems harmless (the CSSOM would not bear the webkitBorderFit property anymore, but I guess this is also harmless...).


PhistucK

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

Xianzhu Wang

unread,
Sep 23, 2014, 11:43:19 AM9/23/14
to PhistucK, blink-dev
Even in css3-border-2002, none of the blink's current accepted values 'border' and 'lines' were specified.

Xianzhu Wang

unread,
Sep 23, 2014, 12:59:05 PM9/23/14
to PhistucK, blink-dev
Any objections? If no, I'd like to follow the instruction in http://www.chromium.org/blink#TOC-Launch-Process:-Deprecation:

  1. Decide if your feature needs to go through this process.

  • You can skip 2-5 if you’re removing a trivial feature (e.g. a quirk that is exclusive to WebKit, like RangeException).

Philip Rogers

unread,
Sep 23, 2014, 1:17:58 PM9/23/14
to Xianzhu Wang, PhistucK, blink-dev
This seems reasonable to remove but I'm curious why the usage is as high as it is (0.1464%):

Do you know why so many pages are using this?

Xianzhu Wang

unread,
Sep 23, 2014, 2:31:40 PM9/23/14
to Philip Rogers, PhistucK, blink-dev
About its visual effect

Found I was wrong about its visual effect. -webkit-border-fit: border and lines do have different visual effects. I got the wrong idea because of a blink bug about missing repaint on change of -webkit-border-fit.

Example:
<div style="-webkit-border-fit: lines; width: 200px; height: 200px; border: 1px solid black">
  <div style="display: inline-block; width: 50px; height: 50px"></div>
</div>
The border size is 52x202. If with default value of -webkit-border-fit: border, the border size will be 202x202.

The same effect can be easily achieved with shrink-to-fit.

About page usages

Searched web for "-webkit-border-fit: lines" and looked into pages that are using it in css. All the real css usages in search results are the similar to
.button { ... -webkit-border-fit:lines; /* <- Safari & Google Chrome Fix */ }
This looks like a workaround of some bug of WebKit.

This page is using the property, and contains a question why it is used but got no answer.

I'd still like to remove it. Earlier than later. If it is still needed to workaround some bug, we would know the bug and fix it.

Philip Rogers

unread,
Sep 23, 2014, 2:36:57 PM9/23/14
to Xianzhu Wang, PhistucK, blink-dev
The usage seems too high to remove this feature. If it's as simple as using shrink-to-fit, can we implement webkit-border-fit using the shrink-to-fit code?

Xianzhu Wang

unread,
Sep 23, 2014, 2:44:54 PM9/23/14
to Philip Rogers, PhistucK, blink-dev
Based on the search result, all usages are the same to workaround some WebKit bug which may have been fixed. I didn't reproduce the "button extra padding bug" with m37. The usages are not for the real original intent of the property which I think should not be counted as real usages.

PhistucK

unread,
Sep 23, 2014, 2:54:37 PM9/23/14
to Xianzhu Wang, Philip Rogers, blink-dev
Can you search the Google index for pages that actually use it in a build with the property disabled (alternatively, create an extension that removes it and causes relayout) and go over them and see if anything is broken?


PhistucK

Xianzhu Wang

unread,
Sep 23, 2014, 5:09:15 PM9/23/14
to PhistucK, Philip Rogers, blink-dev
Tried the websites with the property support removed and didn't see any difference.
Also tried to apply the related styles to button, and didn't see any difference.

The usages in the search result seem all based on code of Magento (a eCommerce Software). The intent of the usage was to workaround the bug of additional padding inside of borders around buttons containing block content. I can't reproduce the issue on current Chrome. Now -webkit-border-fit:lines has no effect on buttons.

Philip Rogers

unread,
Sep 23, 2014, 6:26:36 PM9/23/14
to Xianzhu Wang, PhistucK, blink-dev
I searched around and couldn't find any real users of this either, other than as workarounds. I think this meets the bar for removal after all.

(We should remove our own use in view-source.css though!)

Xianzhu Wang

unread,
Sep 26, 2014, 12:55:15 PM9/26/14
to Philip Rogers, PhistucK, blink-dev
Uploaded https://codereview.chromium.org/607593002/ to remove it, but I'd like to get 3 LGTM's here first.

Rewritten "Intent to remove" based on the previous discussions:

Primary eng (and PM) emails

wangx...@chromium.org


Summary

Remove support of -webkit-border-fit CSS property.

The intent of the property is to shrink the border and background of a block to the bounding box of the line contents.


Motivation

- it's not in css3 background-and-border spec (http://www.w3.org/TR/css3-background/)

- 'border-fit' property existed in 2002 CSS 3 Border module, but neither the functionality nor the property values is related to -webkit-border-fit.

- there is few (or no) actual usages (see Compatibility Risk 1) Based on usages below)

- it complicates the rendering code and adds difficulty to refactoring

Compatibility Risk


1) Based on usages

According to http://www.chromestatus.com/metrics/css/popularity#webkit-border-fit, the usage is 0.1464% which looks a bit high.

Based on code search and web search, there are mainly 2 usages:

- WebKit/Blink view-source.css

The related style rule is not used.

This usage in blink has just been removed (https://codereview.chromium.org/603153003/)

- Style applied on buttons to workaround an old bug (not reproducible now) of Safari and Chrome:

.button { ... -webkit-border-fit:lines; /* <- Safari & Google Chrome Fix */ }

Neither of the above usages is real usage, so the compatibility risk should be low.


2) Based on support of other browsers

The property doesn't have counter-parts in other browsers. The feature can be easily implemented using other standard css properties. Pages designed for all browsers are unlikely to use the property which works on Safari/Chrome only.


Requesting approval to remove too?

Yes.

Xianzhu Wang

unread,
Sep 29, 2014, 1:16:07 PM9/29/14
to blink-dev
ping...

Ojan Vafai

unread,
Sep 29, 2014, 8:06:01 PM9/29/14
to Xianzhu Wang, blink-dev
lgtm

It's hard for me to see what this does other than size something to it's intrinsic width like float and position:absolute do, but without messing with your display-outside. Splitting up display into display-inside and display-outside seems better to me for solving that.

Also, looking at the 4 tests we have for this, they all suffer from a bug where we don't do relayouts when you add/remove -webkit-border-fit from an element.

Jochen Eisinger

unread,
Sep 30, 2014, 9:22:56 AM9/30/14
to Ojan Vafai, Xianzhu Wang, blink-dev
lgtm2

Adam Barth

unread,
Sep 30, 2014, 12:01:56 PM9/30/14
to Jochen Eisinger, Ojan Vafai, Xianzhu Wang, blink-dev
lgtm
Reply all
Reply to author
Forward
0 new messages