Intent to Remove: hspace/vspace attributes on table

140 views
Skip to first unread message

Philip Jägenstedt

unread,
Oct 31, 2014, 5:56:02 AM10/31/14
to blink-dev

Primary eng (and PM) emails

phi...@opera.com


Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/msg/blink-dev/l3rZbX-BUaM/3iSlHsjmW0wJ


Deprecated since M38.

Summary

Remove the hspace/vspace attributes on table, which are presentational attributes mapping to margin-left/right and margin-top/bottom respectively.


Motivation

There is a request to remove these from Simon Pieters:

https://code.google.com/p/chromium/issues/detail?id=277080


As described in the bug, these attributes aren't supported at all in IE, and only in quirks mode in Gecko. The spec bug is waiting for someone to make the first move:

Given the low usage, it seems worth trying.

Usage information from UseCounter

vspace ~0.005%: http://www.chromestatus.com/metrics/feature/timeline/popularity/374

hspace ~0.005%: http://www.chromestatus.com/metrics/feature/timeline/popularity/375


Entry on chromestatus.com

None.


Compatibility Risk

The margins around the table will be missing. This will likely not be catastrophic in most cases, but like any layout difference can be breaking.

Given the lack of support in IE and the quirks-mode-only support in Gecko, WebKit-specific content seems most likely to suffer. Anyway, usage is low.

Chris Harrelson

unread,
Nov 4, 2014, 11:48:25 AM11/4/14
to Philip Jägenstedt, blink-dev
There seems to be a downward trend after M38, when these attributes were deprecated. I'd prefer to wait one more release and see what it looks like then, since it does break visual layout on some sites.. Since I don't think there is an urgent need to remove it now, this should be ok.

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

Elliott Sprehn

unread,
Nov 4, 2014, 12:07:25 PM11/4/14
to Chris Harrelson, Philip Jägenstedt, blink-dev
What you're likely to break is photoshop and dreamweaver exported sites that are sliced up images in deeply nested tables. They almost all run in quirks mode, and changing the size of the cells can cause them to break pretty badly.

I'd suggest putting it behind a flag first if you do it, at one point there was a lot of content of that type, but perhaps it's all gone now. :)

Simon Pieters

unread,
Nov 5, 2014, 4:13:36 AM11/5/14
to Chris Harrelson, Elliott Sprehn, Philip Jägenstedt, blink-dev
On Tue, 04 Nov 2014 18:06:39 +0100, Elliott Sprehn <esp...@chromium.org>
wrote:

> What you're likely to break is photoshop and dreamweaver exported sites
> that are sliced up images in deeply nested tables. They almost all run in
> quirks mode, and changing the size of the cells can cause them to break
> pretty badly.

I don't think so. If they set these attributes, the value is most likely 0
which is the default value.

If there are pages that use non-zero values and are not already badly
broken in IE, it seems to me they have to rely on either vspace being
supported or the IE 3px float bug or IE box model quirk being present, or
some such. However this is not something that I have found when
researching these attributes.

Previous analysis found the following compat impact (data set 18/06/2013
from http://webdevdata.org/ (53,000 pages)):

[[
stihi.ru [and proza.ru] - an image would get rid of 10px vertical spacing
and two items in the footer would lose 3px spacing. Seems acceptable.

www.clipmoon.com - the column widths differ by a few pixels. Seems
acceptable.

www.localharvest.org - header would lose 4px vertical spacing. Seems
acceptable.
]]
https://bugzilla.mozilla.org/show_bug.cgi?id=725646#c15

--
Simon Pieters
Opera Software

Philip Jägenstedt

unread,
Nov 6, 2014, 1:36:01 AM11/6/14
to Chris Harrelson, blink-dev
There's no way to really know, but I would be a bit surprised if the
deprecation message is what has caused the decreased usage. The
deprecation message reach stable with M38 on October 7, and on the
very next day the usage appears to have dropped. Correlation,
causation, who knows? Sometimes things go up and down for no obvious
reason:
https://www.chromestatus.com/metrics/feature/timeline/popularity/167

This is a case where it would be easy to keep warning after the
removal, if we want to run that experiment now.

A flag doesn't seem very helpful, the C++ bits are tiny and easy to revert.

Either way is fine by me, I will comply!

Philip

Rik Cabanier

unread,
Nov 6, 2014, 12:50:50 PM11/6/14
to Elliott Sprehn, Chris Harrelson, Philip Jägenstedt, blink-dev
On Tue, Nov 4, 2014 at 9:06 AM, Elliott Sprehn <esp...@chromium.org> wrote:
What you're likely to break is photoshop and dreamweaver exported sites that are sliced up images in deeply nested tables. They almost all run in quirks mode, and changing the size of the cells can cause them to break pretty badly.

Do these applications export these attributes?
I exported some sliced images but didn't see them being used.

Chris Harrelson

unread,
Nov 6, 2014, 12:59:23 PM11/6/14
to Rik Cabanier, Elliott Sprehn, Philip Jägenstedt, blink-dev
Let's wait one more release, and also add the warning-after-removal. Please ping the thread for M41 so we can all see the trend together.

By the way, for the benefit of blink-dev: Philip, Adam Klein and I discussed warning-after removal some more at BlinkOn. We concluded that for removing properties of any object except Window, it's infeasible to implement warning-after-removal, because the v8 API that would achieve this has a bad side effect of disabling compilization/optimization for that object (since Window is already slow, it does not apply there). However, for attributes and some other cases, such as DomImplementation.hasFeature always returning true, we can in fact implement warning-after-removal without too much work and no performance impact.

Thanks,
Chris

Philip Jägenstedt

unread,
Nov 8, 2014, 4:59:14 PM11/8/14
to Chris Harrelson, Rik Cabanier, Elliott Sprehn, blink-dev
OK, I will ping this thread in January, after the M41 branch point.

Philip

Philip Jägenstedt

unread,
Jan 15, 2015, 4:37:25 AM1/15/15
to Chris Harrelson, Rik Cabanier, Elliott Sprehn, blink-dev
Ping.

The usage has remained the same:
https://www.chromestatus.com/metrics/feature/timeline/popularity/374
https://www.chromestatus.com/metrics/feature/timeline/popularity/375

Now's a good time to try the removal, as it maximizes time to reach
the stable channel.

Philip

Chris Harrelson

unread,
Jan 16, 2015, 1:15:05 PM1/16/15
to Philip Jägenstedt, Rik Cabanier, Elliott Sprehn, blink-dev
Ok. LGTM


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

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

Dimitri Glazkov

unread,
Jan 27, 2015, 11:25:47 AM1/27/15
to Chris Harrelson, Philip Jägenstedt, Rik Cabanier, Elliott Sprehn, blink-dev
LGTM2

Jochen Eisinger

unread,
Feb 3, 2015, 1:07:40 PM2/3/15
to Dimitri Glazkov, Chris Harrelson, Philip Jägenstedt, Rik Cabanier, Elliott Sprehn, blink-dev
lgtm3

Philip Rogers

unread,
Feb 3, 2015, 1:57:22 PM2/3/15
to Jochen Eisinger, Dimitri Glazkov, Chris Harrelson, Philip Jägenstedt, Rik Cabanier, Elliott Sprehn, blink-dev
LGTM as well
Reply all
Reply to author
Forward
0 new messages