Intent to Remove: hspace/vspace attributes on table

[Philip Jägenstedt]

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:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23039

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]

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]

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]

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]

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]

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]

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]

OK, I will ping this thread in January, after the M41 branch point.

Philip

[Philip Jägenstedt]

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]

Ok. LGTM

>>>>>> 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.
>>>
>>>
>>

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

[Dimitri Glazkov]

LGTM2

[Jochen Eisinger]

lgtm3

[Philip Rogers]

LGTM as well