291509 - no grid in Calendar Availability table with Outlook Web Access

Status: RESOLVED WORKSFORME

(Core :: Layout: Tables, defect)

Description

[Vicki Brown]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050417 Camino/0.8+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050417 Camino/0.8+

My Company uses Outlook (MS Exchange). Duh. When I need to create a meeting I
use Outlook Web Access 2003.

In Camino, the "Avaiability" table for invities has rows but no columns.
in Safari, the table also has columns.

Reproducible: Always

Steps to Reproduce:
1.Access an Outlook web access server
2. Create a New Appointment
3. Select "Availability"

Actual Results:  
No vertical lines separating the times.

Expected Results:  
If Camino shows columns (vertical grid lines) Camino should do the same. 

I have a screen shot. I'll email it to Mike Pinkerton.
Camino on the top, Safari on the bottom. Same "query".

Comment 1

[Samuel Sidler (old account; do not CC)]

I can confirm this as well, however, is this a core issue?

(Using build 4/2)

Comment 2

[Samuel Sidler (old account; do not CC)]

Attachment: Test Case

This is an exact copy of what I'm seeing (minus links and any sensitive
material). Also, this doesn't work in Firefox, so it seems it's a core issue.

Comment 3

[Samuel Sidler (old account; do not CC)]

Confirming.

-> Core

Comment 4

[Bernd]

>Confirming.
??? How got this confirmed without a reduced testcase
(http://www.mozilla.org/newlayout/bugathon.html) See
http://groups-beta.google.com/group/netscape.public.mozilla.layout/browse_frm/thread/4b44ff47ef062b20/
for what is necessary to confirm a layout bug

Comment 5

[Samuel Sidler (old account; do not CC)]

Attachment: Testcase #2

Since you asked so nicely, here's a reduced testcase. The offending part is
rules="rows" in the table tag. This is related to bug 155507, however, it seems
different.

In that bug, the column spacing that is visible in IE 6 but not in Mozilla is
not at all discussed. I would then assume (without trying as I'm not a
developer) that the proposed patch doesn't take that into consideration.

I do not think this is a dupe based on the discussion. In that bug, they are
focusing on the row part of rules="rows", not the columnar part.

Comment 6

[Bernd]

Yeah with a testcase that is pretty easy to diagnose :-)

rules=rows  invokes border-collapse:collapse, this follows the suggestion from
http://www.w3.org/TR/CSS21/tables.html#collapsing-borders. In border collapse
the cellspacing is 0. So the background does not shine through. Other vendors
did not follow the suggestion of the spec at this place.

So the question boils down to what is expected: if you expect CSS2 rendering one
would say that this rendering is within range. If you expect IE rendering then
it is not. So it is merely a quirk.

This leaves open two decisions IMHO:
a: Invalid due to point 1
b: Wontfix, as I dont see a lot of pages relying on this quirk

Comment 7

[Mike Pinkerton (not reading bugmail)]

if we WONTFIX, we'll just have outlook users mad at us. Sure IE is prolly doing
the "wrong thing", but this is a real world case where the "right thing" and the
spec are different. WONTFIXing (or invalidating) doesn't help our users one bit.

-> core.

Comment 8

[Samuel Sidler (old account; do not CC)]

Bug 155507 was just checked in to the tree. If this fixes it, this bug is
closed. If not, let's see what's going on.

Comment 9

[Bernd]

No it will/should not fix it. It was a  general design decision by Chris to
implement rules and frames on tables via border-collapse. Reverting this
requires major hacking efforts I believe both in the style system as in
layout/tables.

Comment 10

[Bernd]

bug 43178 will not change this

Comment 11

[Mats Palmgren (inactive)]

Firefox 48 renders Testcase #2 the same as Chrome Canary (54.0.2837.0) and Safari 9.1.2.