Intent to Deprecate and Remove: <body bgproperties=fixed>

102 views
Skip to first unread message

Philip Jägenstedt

unread,
Nov 17, 2014, 2:16:57 PM11/17/14
to blink-dev

Primary eng (and PM) emails

phi...@opera.com


Summary

Remove the bgproperties attribute, which on body maps to CSS background-attachment: fixed.


Motivation

Quoting from <https://codereview.chromium.org/428363002>:



Gecko has managed to not implement this since 1999.

The alternative is to standardize, but IMHO the usage is a bit low to justify that.

Compatibility Risk

Backgrounds may scroll. If it's a repeating background that's probably OK. Non-repeating cases are less likely since AFAICT that can only be done using CSS background-repeat, and sites made after that was available probably use background-attachment.

Alternative implementation suggestion for web developers

body { background-attachment: fixed; }


Usage information from UseCounter

https://www.chromestatus.com/metrics/feature/timeline/popularity/515


It was in M38 and is now around 0.01%.

Entry on chromestatus.com, crbug.com, or MDN

None.


Requesting approval to remove too?

Yes, but if the API OWNERS like, this is a case where it's easy to have a deprecation message after the removal.

Chris Harrelson

unread,
Nov 17, 2014, 8:51:26 PM11/17/14
to Philip Jägenstedt, blink-dev
LGTM

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

Jochen Eisinger

unread,
Nov 18, 2014, 9:30:32 AM11/18/14
to Chris Harrelson, Philip Jägenstedt, blink-dev
lgtm2

Philip Rogers

unread,
Nov 18, 2014, 7:37:36 PM11/18/14
to Jochen Eisinger, Chris Harrelson, Philip Jägenstedt, blink-dev
I'm less excited about removing this one because we're definitely going to break those 0.01% of pages without getting much win in the engine (code cleanup, simplification opportunities, etc).

TAMURA, Kent

unread,
Nov 19, 2014, 3:34:25 AM11/19/14
to Philip Rogers, Jochen Eisinger, Chris Harrelson, Philip Jägenstedt, blink-dev
I also felt 0.01% was too high for this tiny-footprint feature.  So, immediate removal is not good, and deprecation-then-removal LGTM.

--
TAMURA Kent
Software Engineer, Google


Jochen Eisinger

unread,
Nov 19, 2014, 3:38:55 AM11/19/14
to TAMURA, Kent, Philip Rogers, Chris Harrelson, Philip Jägenstedt, blink-dev
I'm not sure how much the usage will drop during deprecation, but we can give it a try.

Philip Jägenstedt

unread,
Nov 19, 2014, 4:26:11 AM11/19/14
to Jochen Eisinger, TAMURA, Kent, Philip Rogers, Chris Harrelson, blink-dev
Since the attribute has never been standard, HTML validators have always complained about it. It seems unlikely that deprecation will make a dent in the numbers.

If we deprecate now and the usage remains the same, will we remove it anyway?

I could give standardization a try, but expect skepticism due to the low usage and the fact that Gecko has managed to not implement this.

(This is one of many trivial non-standard "features" where the options are removal, standardization, or leaving it alone. I prefer to aim for convergence by removal or standardization, as even trivial differences are an opportunity for Web developers to write non-portable code.)

Philip

Michael[tm] Smith

unread,
Nov 19, 2014, 7:21:58 AM11/19/14
to Philip Jägenstedt, blin...@chromium.org
Philip Jägenstedt <phi...@opera.com>, 2014-11-19 10:26 +0100:
...
> I could give standardization a try, but expect skepticism due to the low
> usage and the fact that Gecko has managed to not implement this.

I think you could expect more than just skepticism, if the plan it to make
it conforming markup -- because the current HTML spec is consistent in its
treatment of legacy presentational markup as non-conforming (even
presentational markup that was formerly conformant) -

https://html.spec.whatwg.org/multipage/introduction.html#presentational-markup

"presentational markup has been removed from HTML in this version... The
only remaining presentational markup features in HTML are the style
attribute and the style element"

Given that, it'd be inconsistent to standardize bgproperties as a
conforming feature, and at least it has pretty much zero chance of ever
becoming part of the HTML standard as a conforming feature.

All that said, it'd still be possible to normatively standardize the UA
processing requirements for bgproperties -- similar to, e.g., the marquee
element: Even though it's not defined as standard conforming markup, the
HTML spec still normatively defines standard UA requirements for it -

https://html.spec.whatwg.org/multipage/rendering.html#the-marquee-element

--Mike

> (This is one of many trivial non-standard "features" where the options are
> removal, standardization, or leaving it alone. I prefer to aim for
> convergence by removal or standardization, as even trivial differences are
> an opportunity for Web developers to write non-portable code.)
>
> Philip

--
Michael[tm] Smith https://people.w3.org/mike
signature.asc

Philip Jägenstedt

unread,
Nov 19, 2014, 7:35:07 AM11/19/14
to Michael[tm] Smith, blink-dev
On Wed, Nov 19, 2014 at 1:21 PM, Michael[tm] Smith <mi...@w3.org> wrote:
> Philip Jägenstedt <phi...@opera.com>, 2014-11-19 10:26 +0100:
> ...
>> I could give standardization a try, but expect skepticism due to the low
>> usage and the fact that Gecko has managed to not implement this.
>
> I think you could expect more than just skepticism, if the plan it to make
> it conforming markup

If spec'd it need not be conforming, just given the same treatment as
e.g. bgcolor:
https://html.spec.whatwg.org/multipage/rendering.html#the-page

Anyway, since there's already support for deprecation I'm going to do
that, hoping to be proven wrong about the effectiveness. We can
revisit in a few months.

Philip

Philip Rogers

unread,
Nov 19, 2014, 2:14:30 PM11/19/14
to Philip Jägenstedt, Michael[tm] Smith, blink-dev
I don't think deprecation will work for this one. I suspect the pages that use this are very old and unmaintained. I'll see if I can generate a list of sites that use this feature so we can make a better decision.

Philip Jägenstedt

unread,
Nov 19, 2014, 5:04:27 PM11/19/14
to Philip Rogers, Michael[tm] Smith, blink-dev
That would be great, Philip! I dream of a spider that collects use
counter data, but in this case a simple grep in a big corpus will do
the job!

The bug tracking bgproperties is https://crbug.com/434627 and the
deprecation has already landed. I'll await your findings before doing
anything further.

Philip

Yoshifumi Inoue

unread,
Nov 19, 2014, 9:14:22 PM11/19/14
to Philip Jägenstedt, Philip Rogers, Michael[tm] Smith, blink-dev
From google index, 0.051% of pages have bgproperties attribute. Sorry, I have no data only for bgproperties=fixed
-yosi

Simon Pieters

unread,
Nov 20, 2014, 4:09:35 AM11/20/14
to Philip Jägenstedt, Philip Rogers, Michael[tm] Smith, blink-dev
On Wed, 19 Nov 2014 20:14:05 +0100, Philip Rogers <p...@chromium.org> wrote:

> I don't think deprecation will work for this one. I suspect the pages
> that
> use this are very old and unmaintained. I'll see if I can generate a list
> of sites that use this feature so we can make a better decision.

In http://webdevdata.org data set 2013-09-01 102,000 pages I see 4 pages
with <body bgproperties>.

3 had bgproperties=fixed but no background image. Of these, 2 have changed
and no longer use bgproperties.
1 had a background image but with bgproperties="0" which does nothing.

--
Simon Pieters
Opera Software

Philip Rogers

unread,
Nov 21, 2014, 2:51:56 AM11/21/14
to Simon Pieters, Philip Jägenstedt, Michael[tm] Smith, blink-dev
I did a search in our index and manually went through the top sites with bgproperties listed. Only one site would actually be affected by this change, and not in a major way. Lets remove it!

LGTM

Philip Jägenstedt

unread,
Nov 21, 2014, 3:05:37 AM11/21/14
to Philip Rogers, Simon Pieters, Michael[tm] Smith, blink-dev
Thanks for helping out, Philip! I'll take that as the third LGTM and proceed in https://code.google.com/p/chromium/issues/detail?id=434627

Philip
Reply all
Reply to author
Forward
0 new messages