Closed Bug 725646 Opened 13 years ago Closed 5 months ago

Remove support for the hspace/vspace attributes on table

Categories

(Core :: DOM: Core & HTML, task)

task

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: Ms2ger, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-needed, site-compat)

Attachments

(1 file)

Attached patch Patch v1Splinter Review
These attributes are not supported at all in IE and Opera, and only in quirks mode in Gecko. Chrome supports them in all modes.

I think we can get away with removing support entirely.
Attachment #595720 - Flags: review?(bzbarsky)
Is it possible to get a more data driven answer than "we think we can get away with it"?
This seems to be a perfect question to direct to Blekko, who have a neat "grep the web" tool we can use. Essentially we would ask them "what percentage of <table> tags use hspace or vspace? Coincidentally there is a brownbag discussion being held today with them and I will follow up to see if this is possible.
Comment on attachment 595720 [details] [diff] [review]
Patch v1

r=me on the code changes, but I'd love to see the data here.  Does IE really not support this even in their compat quirks mode?
Attachment #595720 - Flags: review?(bzbarsky) → review+
My IE8 on WinXP doesn't seem to support it, with or without doctype.
John, do you know when we could get the data?
I've followed up with them and will update this ASAP.
Thanks!
John, you would get to me ASAP over a month ago. Do you have an ETA? I'd rather not wait indefinitely to finish this bug.
Hi Gerv,

Sorry, perhaps some miscommunication here. I saw you were cc'd on the emails from Blekko and thought that was sufficient. I'll dive back into that thread and get it sorted out.
So, what's the conclusion here?
What does the data look like?
Someone needs to draw conclusions from comment 10 here.  It's a big number, but not clear to me how big.  And it wouldn't surprise me if most (or even nearly all) of the values were 0, which I think should be the default for both.
Flags: needinfo?(Ms2ger)
One of the crawls looked for non-zero values if I understand the grep correctly. So looking at just number of URLs:

hspace 3.16M of which 2.21M (70%) have non-zero value
vspace 3.29M of which 2.28M (69%) have non-zero value

One thing I wonder is, in <table[^>]*hspace\s*=\s*['"]?[ ^0][^>]*> there's a space before the ^, is that intended to be there? Also, since the " or ' before it is optional in the regexp, it could instead match the [^0], so these results might be bogus.

I did a different search, data set 18/06/2013 from http://webdevdata.org/ (53,000 pages):

$ grep -riE "<table\s[^>]*(v|h)space\s*=\s*[\"']?[1-9]" . > ~/Desktop/vhspace.txt
$ wc -l ~/Desktop/vhspace.txt 
      13 /Users/zcorpan/Desktop/vhspace.txt

The matches were from 9 different sites. So it's 0.017% of the sites in this data set that use non-zero vspace/hspace.
Analysis of visual impact of dropping vspace/hspace on those 9 pages:

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

seiya-saiga.com - no visible difference.

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

proza.ru - same or very similar site as stihi.ru

gossiplankanews.com - no visible difference.

gossiplanka.lk - same site as above.

www.localharvest.org - header would lose 4px vertical spacing. Seems acceptable.

akipress.org - no visible difference.

paparasinewslanka.com - 404
Keywords: site-compat
Chrome is doing this, fwiw.
Flags: needinfo?(Ms2ger)
The Blink bug is fixed since February 2015
https://code.google.com/p/chromium/issues/detail?id=277080
Type: defect → task
Severity: normal → S3

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: Ms2ger → nobody
Status: ASSIGNED → NEW
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: