Raw Test Data
The raw test data for Safari can be found here: Safari test data
Test data was gathered for version 3.1.1 on multiple platforms, and found to be identical on all!
Results
Legend: n = newline; t = tab; s = space
The following patterns were collected from between the cells (containing actual data) either side of each of the tests! So for example, if the test is looking at an empty cell at row 2 cell 1, the pattern covering that would include everything between the contents of row 1 cell 5 and row 2 cell 2!
| # | Test | Group 1 Patterns | Group 2 Patterns | Group 3 Patterns | Group 4 Patterns |
|---|---|---|---|---|---|
| 1 | Between two normal cells | t | t | n | n |
| 2 | Between two normal rows | n | n | n | n |
| 3 | Empty cell at start of row | n | nst | n | nsn |
| 4 | Empty cell at end of row | tn | tsn | n | nsn |
| 5 | Two empty cells at start of row | n | nstst | n | nsnsn |
| 6 | Two empty cells at end of row | ttn | tstsn | n | nsnsn |
| 7 | Empty cell in middle of row | tt | tst | n | nsn |
| 8 | Three empty cells in middle of row | tttt | tststst | n | nsnsnsn |
| 9 | Empty cell at end of row followed by empty cell at start of next row | tn | tsnst | n | nsnsn |
| 10 | Three empty cells at end of row followed by three empty cells at start of next row | tttn | tststsnststst | n | nsnsnsnsnsnsn |
| 12 | Entire row empty (Five cells) | n | nststststsn | n | nsnsnsnsnsn |
| 13 | Empty cells at beginning of first row (One cell) | st | sn | ||
| 14 | Empty cells at beginning of first row (Two cells) | stst | snsn | ||
| 15 | Empty cells at beginning of first row (Four cells) | stststst | snsnsnsn | ||
| 16 | Empty cells at end of last row (One cell) | tn | tsn | n | nsn |
| 17 | Empty cells at end of last row (Two cells) | ttn | tstsn | n | nsnsn |
| 18 | Empty cells at end of last row (Four cells) | tttn | tstststsn | n | nsnsnsnsn |
<thead>,<tbody>and<tfoot>seem to make no difference - good news!- No difference between
<th>and<td>seen - good news! - A
<br />tag in the middle of the data splits it with a new line
Analysis
The basic building blocks used by Safari for Groups 1 and 2 are a t between cells and an n between rows. Using in empty cells (required for cells to display correctly in certain browsers) inserts a single s as cell data.
If you compare the patterns from Group 1 to those from Opera or Mozilla Firefox, they are pretty similar, in fact the only difference is that Safari seems to ignore completely empty cells at the start of rows as if they don't exist. It also acts as if the entire empty row in Test 12 also doesn't exist, there's no trace of it in the pattern! Group 2 patterns match those from Opera and Mozilla Firefox exactly (except the n on the end of the last three tests), obviously the spaces in the cell data force it to accept that the cells exist!
Group 3 and Group 4 patterns look horrible! Group 3 just sticks a single n between anything and everything, and Group 4 looks a little similar to that in Opera, but it doesn't have a single t in it, and is not quite the same even if they were there.
The basic effect of <p> is a little difficult to tell, but it seems to remove the t between the cell and the next one, and puts an n on either side of it (although not in every case).
Spacing out the HTML seems to have the effect of adding a single s before the existing cell contents for cells that are not completely empty, although there are exceptions such as not when all cells in front of it in a row are empty. It does not do it for cells using the <p> tag.
Conclusion
The only way to draw a conclusion as to how well these test cases are handled, is to see how easy it is to build a parsing algorithm which can convert all of these patterns into a simple format from which the data can then be easily extracted. Let's make a few rules first though:
- Our algorithm will not be told how many columns or rows it has been provided with (you couldn't expect a user to have to provide this info).
- Any number of cells in the table could be using the
<p>tag, and any number of "empty" cells in the table could be using . - Any part of the HTML of the table could be spaced out and therefore introduce additional spaces into the patterns.
- One single algorithm must cover everything.
It does not look good for Safari. Group 2 can be processed with the algorithm in came up with for Opera and Mozilla Firefox. Group 1 however cannot, unless behaviour is modified slightly to exactly match Opera and Mozilla Firefox. Group 3 and Group 4 patterns are simply impossible to process!
Sorry Safari, but that's a pretty poor result!