Intent to Implement: border-image spec compliance

[caval...@chromium.org]

Contact emails

caval...@chromium.org, a.cava...@samsung.com

Spec

http://www.w3.org/TR/2005/WD-css3-background-20050216/#the-border-image

Implementation review CL

Summary

Chrome implementation for border-image has a quirk where an element with no border-style defined (i.e. none) will still have the border rendered if it has a border-image property defined.

That is in violation of the spec and is creating interoperability problems with other browser engines, specially in mobile.

The idea is to change the code to follow the spec, thus having the same behavior as other browser engines (e.g. Gecko, IE).

Motivation

This quirk is shared with WebKit and as the dominant mobile OSes have either a WebKit/Blink based browser as default, authors are creating mobile websites that are incompatible with other browser engines.

As an example, Gecko is having issues in both Android and FFOS and recently, MS Edge had to implement this quirk to allow correct rendering of gcalendar/gmail (both teams were notified and there are internal bugs opened).

Interoperability and Compatibility Risk

This change should not impact any website that currently renders correctly in other browser engines or that is using the property in the correct way.

The preliminary numbers in Google Canary for BorderImageWithBorderStyleNone are 0.15% of pages (i.e. 1 in 700 pages). The impact on those websites should be minimal, as the fix is an one liner (i.e. border-style: solid)

The involved parties are supportive (Mozilla, Apple, Microsoft), as the later is willing to revert the quirk in MS Edge to bring it back to compliance (as it was a regression from IE). In case of Mozilla, its contributor has joined the discussions in the bug report and for Apple, the patch fixing this behavior in WebKit has been r+ed already.

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://code.google.com/p/chromium/issues/detail?id=559258

Entry on the feature dashboard

https://www.chromestatus.com/features/5542503914668032

Requesting approval to ship?

Yes.

[PhistucK]

While this is a pretty big number (0.15% versus the usual 0.02%, I believe), since all of the relevant parties agree to remove the quirk, I think a coordinated removal would be great.

However, you should find out whether this fix will be shipped in a minor Safari version because if not, this change will take a year to get to iOS users and this is not a coordinated removal (unless everyone removes it in October, 2016 or whatever).

The longer this waits, the more new instances pop up. :(

Anyway, a deprecation period one at least one release is in order, I believe.

"border-image that does not specify border-style is deprecated and will be removed in the next version, so the element will render without any border. Adding "border-style: solid;" will fix the issue."

I do not think a small deprecation period should be skipped.

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

[Yoav Weiss]

On Mon, Dec 7, 2015 at 11:28 PM, <caval...@chromium.org> wrote:

Requesting approval to ship?

Yes.

Can you change the title to "Intent to Implement and Ship"? 

[Philip Jägenstedt]

Hi Adenilson,

We normally await use counter numbers from stable, unless we have good reasons to think that usage from other canary/dev/beta are representative. 0.15% is already about 10 times higher than your usual removals, so adding uncertainty to that is not great.

When it comes to compatibility risk, I'm afraid that "the impact on those websites should be minimal, as the fix is an one liner" is answering a different question than asked in Evaluating "interoperability and compatibility risk." We cannot assume that sites will be fixed, rather "compatibility risk is the likelihood that a change will break existing web content loaded in Chromium." That it's easy to fix is a plus, though.

A bug has been filed on GMail's dependency on this quirk, and apparently Google Calendar also depends on it. I think that we should wait for those to be fixed and for the use counter to reach stable before acting. Before we know if we're going to attempt removal, I think we also should not deprecate.

Philip

On Mon, Dec 7, 2015 at 11:28 PM, <caval...@chromium.org> wrote:

--

[Joe Medley]

The dashboard link doesn't work. Here's the correct one: https://www.chromestatus.com/features/5542503914668032

Joe Medley | Technical Writer, DevPlat | jme...@google.com | 816-678-7195

[caval...@chromium.org]

@PhistucK

Thanks for the feedback, I can ask WebKit team members about the release window (i.e. time between a patch landing in trunk and being available for users).

I agree the sooner the better, as more content is been created and people are probably testing only on mobile platforms that feature the quirk.

@Yoav

Funny thing is that just after I posted the message, I noticed that I should have added an ' ... and ship' to the message title. 

I'm afraid you can't change the message title after posted, maybe I'm wrong?

@Philip

I agree we should wait for gcalendar/gmail to be fixed before shipping this (which is why the patch in WebKit is on hold).

That being said, I'm looking forward to hear news about the status of those bugs, as they are internal we have no way to follow up. 

IIRC, the older bug report on gcalendar was filed by Mozilla almost 1 1/2 year ago.

@Joe

Thanks for sharing the correct link, this is my first intent to ship and I'm learning the process as I go.

:-)

Cheers

Adenilson Cavalcanti

a.k.a. Savago

[Alan Cutter]

Does this intent include altering the prefixed -webkit-border-image behaviour or will it remain backwards compatible?

[caval...@chromium.org]

Alan

I would say that both versions (prefix, un-prefixed) had to be fixed, for the following reasons:

a) It is a violation of the spec, quoting "None: No border. Color and width are ignored (i.e., the border has width 0)" and in a recent discussion in www-style it was defined that "The fact this properties set the style of the border is normative".

b) If we keep the old quirky behavior around, web authors will continue relying on it.

Best regards

Adenilson

[PhistucK]

a) was not a justified reason for changing a deprecated, prefixed property, we want to remove it and so not touch it, unless it significantly hinders the development progress (prefixed WebRTC APIs, for example).

☆PhistucK

--

[Philip Jägenstedt]

My view is that we should keep prefixed and unprefixed properties and APIs in sync, as simple aliases, whenever possible. If behavior differs in any way, that can actually make it harder for people to switch to the unprefixed form. Also, there's always a risk, and sometimes a near certainty, that we won't be able to remove the prefixed variant, in which case we would be forever stuck with two code paths.

[David Vest]

I notice there are already at least two differences between
-webkit-border-image and border-image:

* -webkit-border-image paints the middle piece by default while
border-image does not:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/css/parser/LegacyCSSPropertyParser.cpp&l=3925

* -webkit-border-image's slices sets border-widths.

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/css/resolver/CSSToStyleMap.cpp&l=472

Both added to keep backwards compatibility. While I don't think we
should add more differences if we can avoid it, the change discussed
in this thread feels at least as intrusive than either of these. What
we discuss here disables the border-image entirely for the relevant
legacy content, counted by the UseCounter mentioned above.

David

[PhistucK]

One bad possible outcome of changing only the standard version, is that when debugging, developers try to disable the standard property and see that it works, so they just remove it and keep the prefixed version, which is very, very bad. This does make me wonder which way would be the best for the platform (versus best for the developer in the short term :().

If the Developer Tools feature could add a guidance - inline within the styles pane somehow, in such situations, that would mitigate this a bit.

☆PhistucK

[Philip Jägenstedt]

I'm looking at red cells in the Blink Intents spreadsheet, and want to make explicit that this is blocked on use counter data. It should reach stable with M49, but from the graph today, it doesn't look very promising. With a peak of 0.001%, that's sure to reach far above comfortable limits in stable.

The only hope is that fixing some Google properties that currently depend on this behavior would bring down the usage. Alan, can you see if anything has happened on that front?

[Tab Atkins Jr.]

The relevant thread (Google-internal) is at b/15803694. No relevant activity yet, but I've just pinged them again and asked them to prioritize as this is blocking us.

[caval...@chromium.org]

An update on this issue

Mobile gcalendar was fixed (and mobile gmail should be next):
https://code.google.com/p/chromium/issues/detail?id=559258#c37


Adenilson Cavalcanti

[Rick Byers]

/cc Mike Taylor whose working on the compat spec for this.

I checked the latest raw use counters (for M49 only):

0.08% Windows

1.3% Android

This seems shockingly high.  I have a hard time believing that mobile GMail makes up anywhere near 1% of page loads on Android (most Android GMail users use the native GMail or Inbox app).  We should keep trying to get Mobile Gmail updated not to rely on -webkit prefixed CSS properties, but we should think about what we'll do if that doesn't drive the usage down to low enough levels to break.

Do we have compat data on this from any other vendors?  Eg. any reason to believe there aren't thousands of other less popular sites affected by this?  If it's really only mobile Gmail, then I'd support breaking the behavior anyway - we can't let a single website hold back interoperability on the web (and as I told the CSS WG, who owns such a website is irrelevant to the chromium project since our mission is to advance the web at large).  But if mobile GMail / calendar are just the most obvious broken examples of a long tail of issues, then this may be futile anyway.  Although unfortunate, we know that a large portion of the mobile web was only really tested with WebKit-based browsers.

I did an httparchive search for -webkit-border-image and spot- checked 10 random results, all were fine (used either 'border-style: solid', or in a couple cases the 'border' shorthand).  I did another httparchive search trying to find CSS files that referenced -webkit-border-image but NOT border-style and got 1408 hits (~0.3% of the total).  I only had time to spot-check a couple, but the 2nd one I checked (http://iphoster.net/) does look to be depending on this quirk - though I didn't dig to see how badly it would be broken in practice.  I'm about to leave on vacation so can't dig anymore for now, but perhaps someone else wants to look through some of these results to try to get an idea of what fraction of those sites might actually be badly broken by this change?

Worst case and this change is really not sufficiently web-compatible, perhaps we should just spec -webkit-border-image to have this quirk?  That's not the end of the world (not quite an alias, but almost all the code should still be shared).

Rick

[Mike Taylor]

Hi Rick,

On 2/5/16 2:06 PM, Rick Byers wrote:
> Do we have compat data on this from any other vendors? Eg. any reason
> to believe there aren't thousands of other less popular sites affected
> by this? If it's really only mobile Gmail, then I'd support breaking
> the behavior anyway - we can't let a single website hold back
> interoperability on the web (and as I told the CSS WG, who owns such a
> website is irrelevant to the chromium project since our mission is to
> advance the web at large). But if mobile GMail / calendar are just the
> most obvious broken examples of a long tail of issues, then this may be
> futile anyway. Although unfortunate, we know that a large portion of
> the mobile web was only really tested with WebKit-based browsers.

GCal and Gmail are the largest on our radar -- it's great that GCal has
updated. Perhaps breaking Gmail in Chrome Mobile would motivate some
Gmail engineers to use some 10% time for CSS updates. ^_^

There were a few other bugs linked to the bug where we updated (and
unprefixed) border-image, but those have all been long fixed:

<https://bugzilla.mozilla.org/show_bug.cgi?id=497995>

> I did an httparchive search for -webkit-border-image and spot- checked
> 10 random results, all were fine (used either 'border-style: solid', or
> in a couple cases the 'border' shorthand). I did another httparchive
> search

> <https://docs.google.com/spreadsheets/d/1s-Jj-vtQ0U-VGTwdYq71n1KQIuOLH5-0nm5n9HqzFnI/edit#gid=0>

> trying to find CSS files that referenced -webkit-border-image but NOT
> border-style and got 1408 hits (~0.3% of the total). I only had time to
> spot-check a couple, but the 2nd one I checked (http://iphoster.net/)
> does look to be depending on this quirk - though I didn't dig to see how
> badly it would be broken in practice. I'm about to leave on vacation so
> can't dig anymore for now, but perhaps someone else wants to look
> through some of these results

> <https://docs.google.com/spreadsheets/d/1s-Jj-vtQ0U-VGTwdYq71n1KQIuOLH5-0nm5n9HqzFnI/edit#gid=0> to

> try to get an idea of what fraction of those sites might actually be
> badly broken by this change?

I poked around the spreadsheet for a bit and here are some notes:

71 sites have a wunderground embed stylesheet:

.wu-search{
...
border-bottom:10px solid;
-moz-border-image:url(../img/border-stripe.png) 25% repeat repeat;
-webkit-border-image:url(../img/border-stripe.png) 25% repeat repeat;
border-image:url(../img/border-stripe.png) 25% repeat repeat
}

48 sites have something called an_scripts.js to detect ad block users,
but it just sets -webkit-border-image to the empty string (for some
element).

165 are a Wordpress theme called Slide Deck 2, and it looks like these
would break, but *only* for the Leather theme. None of the sites I
looked at were using that.

.slidedeck-cover-style-leather .slidedeck-cover .slidedeck-cover-wrapper
.slidedeck-cover-wrapper-back .slidedeck-cover-wrapper-back-inner {
position: absolute;
display: block;
top: 8px;
right: 0;
bottom: 8px;
left: 108px;
margin: 0;
border-width: 8px 0 8px 8px;
-moz-border-image: url('../images/border-dashed.png') 9 repeat;
-webkit-border-image: url('../images/border-dashed.png') 9 repeat;
-o-border-image: url('../images/border-dashed.png') 9 repeat;
border-image: url('../images/border-dashed.png') 9 repeat;
}

But I heard skeumorphism isn't cool anymore, so maybe not a huge concern.

cssdesk.com would break, for the dropdown style.
But it kinda already looks broken?
https://cloudup.com/cY9fo1X5T1O (ff vs. safari)

And basically everything else I looked at (maybe 30 more individual
sites) seemed OK.

> Worst case and this change is really not sufficiently web-compatible,
> perhaps we should just spec -webkit-border-image

> <https://github.com/whatwg/compat/issues/17> to have this quirk? That's

> not the end of the world (not quite an alias, but almost all the code
> should still be shared).

Obviously I'd prefer to not have to spec this, but if Blink and WebKit
aren't willing to move to the spec compliant behavior Gecko will
probably need to just for fancy Tier 1 Google properties (so we can get
away from the lo-fi HTML version Gmail sends Firefox for Android users
by default).

later,

--
Mike Taylor
Web Compat, Mozilla

[Rick Byers]

On Fri, Feb 5, 2016 at 10:56 PM, Mike Taylor <mi...@mozilla.com> wrote:

Hi Rick,

On 2/5/16 2:06 PM, Rick Byers wrote:

Do we have compat data on this from any other vendors?  Eg. any reason
to believe there aren't thousands of other less popular sites affected
by this?  If it's really only mobile Gmail, then I'd support breaking
the behavior anyway - we can't let a single website hold back
interoperability on the web (and as I told the CSS WG, who owns such a
website is irrelevant to the chromium project since our mission is to
advance the web at large).  But if mobile GMail / calendar are just the
most obvious broken examples of a long tail of issues, then this may be
futile anyway.  Although unfortunate, we know that a large portion of
the mobile web was only really tested with WebKit-based browsers.

GCal and Gmail are the largest on our radar -- it's great that GCal has updated. Perhaps breaking Gmail in Chrome Mobile would motivate some Gmail engineers to use some 10% time for CSS updates. ^_^

Yep, like I said - GMail will not be the thing that keeps us from changing behavior here ;-) 

Just to clarify, this case is fine due to 'border-bottom: 10px solid', right?

48 sites have something called an_scripts.js to detect ad block users, but it just sets -webkit-border-image to the empty string (for some element).

165 are a Wordpress theme called Slide Deck 2, and it looks like these would break, but *only* for the Leather theme. None of the sites I looked at were using that.

.slidedeck-cover-style-leather .slidedeck-cover .slidedeck-cover-wrapper .slidedeck-cover-wrapper-back .slidedeck-cover-wrapper-back-inner {
    position: absolute;
    display: block;
    top: 8px;
    right: 0;
    bottom: 8px;
    left: 108px;
    margin: 0;
    border-width: 8px 0 8px 8px;
    -moz-border-image: url('../images/border-dashed.png') 9 repeat;
    -webkit-border-image: url('../images/border-dashed.png') 9 repeat;
    -o-border-image: url('../images/border-dashed.png') 9 repeat;
    border-image: url('../images/border-dashed.png') 9 repeat;
}

But I heard skeumorphism isn't cool anymore, so maybe not a huge concern.

cssdesk.com would break, for the dropdown style.
But it kinda already looks broken?
https://cloudup.com/cY9fo1X5T1O (ff vs. safari)

And basically everything else I looked at (maybe 30 more individual sites) seemed OK.

Thanks for the analysis, that sounds pretty promising as minimal impact across that set of the top 470k sites.

Worst case and this change is really not sufficiently web-compatible,
perhaps we should just spec -webkit-border-image
<https://github.com/whatwg/compat/issues/17> to have this quirk?  That's
not the end of the world (not quite an alias, but almost all the code
should still be shared).

Obviously I'd prefer to not have to spec this, but if Blink and WebKit aren't willing to move to the spec compliant behavior Gecko will probably need to just for fancy Tier 1 Google properties (so we can get away from the lo-fi HTML version Gmail sends Firefox for Android users by default).

Yep, understood.  Single sites (no matter how popular) and extremely rare use cases aren't enough to justify having to preserve some quirks forever IMHO, so I'm with you here.

Ok, so given:

1. The httparchive analysis above showing little to no breakage in the top 470k sites 
2. Existing compat experience from Firefox indicating the breakage wasn't bad for them
3. The strong desire from other vendors and the CSSWG to make this breaking change to further interoperability on the web, 
4. The ease of applying a fix, and
5. Damage tending to be limited to minor cosmetic issues in practice

I believe we should just attempt to ship this.  We should of course monitor in beta and be prepared to revert if users complain of more than a few other sites that were impacted by the breakage.  But I don't see evidence of a compat problem of the scale sufficient to block further indecision. 

LGTM1 to ship.

[Unfortunately I'm about to leave on vacation with limited internet access, so I'll probably be unable to respond further until after I return on 2/18.  Hopefully the other API owners can come to consensus before then ;-) ].

[Elliott Sprehn]

I'm not an API owner, but +1 to matching the spec here. Seems like the risk is low, and the cross browser compatibility is a win. Let's do it! :)

[Mike Taylor]

On 2/5/16 10:14 PM, Rick Byers wrote:
> Just to clarify, this case is fine due to 'border-bottom: 10px solid',
> right?

Yeah, sorry -- meant to categorize wunderground embeds as "should be OK".

[David Vest]

philipj and I also did a httparchive search at one point. It was not
as thorough as yours but from what I remember we found nothing really
critical or even bothersome. But I think there was some doubt whether
httparchive data is fetched using a desktop user agent and thus may
not see the whole problem here? The "mobile" version of httparchive
doesn't keep the actual data around, IIRC.

David

[Simon Pieters]

On Mon, 08 Feb 2016 18:06:32 +1000, David Vest <da...@opera.com> wrote:

> philipj and I also did a httparchive search at one point. It was not
> as thorough as yours but from what I remember we found nothing really
> critical or even bothersome. But I think there was some doubt whether
> httparchive data is fetched using a desktop user agent and thus may
> not see the whole problem here? The "mobile" version of httparchive
> doesn't keep the actual data around, IIRC.

The latest datasets have response bodies for both desktop and mobile
(chrome_jan_15_2016_pages, android_jan_15_2016_pages). But earlier
datasets had only "desktop" (which was some version of IE). It's not clear
to me which dataset Rick queried here but it seems the android one is more
interesting given the use counters.

--
Simon Pieters
Opera Software

[Rick Byers]

I queried the Jan desktop Chrome dataset.  The Android dataset is still tiny AFAIK (probably still testing the data collection pipeline).

[Philip Jägenstedt]

I am quite hesitant about this one. Rick found 0.08% on Windows vs. 1.3% on Android for M49, which is still about a month away from stable. That's a staggering difference between desktop and mobile. The httparchive data has been from desktop crawls, and searching for combinations of CSS properties is more prone to errors than use counters.

In that 1.3% could be hidden one big site (GMail) or a long tail of sites using a library that uses CSSOM, or for some other reason didn't show up in a httparchive search.

So, unless I'm missing something, the risk is not well understood, although it will likely not be site-breaking. It would be very interesting to see what happens when mobile GMail is fixed, any timeline on that?

--

[Rick Byers]

Yeah this is a tricky one.  Due to the unknown influence of GMail on the use counters, I'm considering this similar to the Event property removals where we basically ignored the use counters.

To me the strongest signal is Firefox saying Gmail is now the only site where this causes a problem for them.  I believe I also heard the Edge team say they'd revert their copy of the hack if GMail were fixed, but I can't find the source for that so it should be considered only rumour.  I see the httparchive data as being consistent with that claim (but far from proof).

Mobile GMail is not actively being developed, so we should assume it will not be fixed proactively (there is no one actively working on a fix).

I think the risk is low enough just to try this. Or perhaps we should do a deprecation period? The only other idea I have is to try to exclude Google domains from the use counter.

Rick

[Philip Jägenstedt]

Ah, well if the Firefox and Edge teams say that GMail is the only
known issue, that is very promising. If we also can't expect a fix for
GMail, then tweaking the use counter and waiting for a few more months
indeed sounds like the only option.

How about deprecating the use counter now and removing in M51? The
branch point is near, so it wouldn't require much additional waiting
on Adenilson's part.

[Rick Byers]

A deprecation warning for one milestone followed by attempted removal sounds good to me.  As before we should still be prepared to revert the removal if we discover a bunch more affected sites.

Rick

[Philip Jägenstedt]

OK, LGTM2 to deprecating now, and removing the behavior for both border-image and -webkit-border-image in M51.

(The title is "Intent to Implement", but this is being tracked as "Implement and ship" in https://bit.ly/blinkintents)

[Chris Harrelson]

LGTM3.

[caval...@chromium.org]

Anyone with write access could update the spreadsheet that tracks the intents? I mean:
https://docs.google.com/spreadsheets/d/1pvXEMD5pRioognaqEzglS-4ZBSQ_YmzL8Fiz7yt4Bb4/edit#gid=0

I tried to edit (line 559) but it shows as read only for my user.


Adenilson

[Philip Jägenstedt]

I've updated it, and also changed it to "Deprecate and remove" since there's now a deprecation involved.

[Adenilson Cavalcanti]

Awesome! Thanks, Philip.

Adenilson

[caval...@chromium.org]

An update on the subject

A warning message was introduced in M50 concerning the use of the border-image property with no border style defined and the fix has landed last weekend for M51.

Mobile gcalendar was fixed as also mobile gmail (should hit production in a couple days). For further details:

https://bugs.chromium.org/p/chromium/issues/detail?id=559258#c57

Adenilson Cavalcanti

a.k.a. Savago