W3C home > Mailing lists > Public > www-style@w3.org > November 2008

Re: Effect of 'position:relative' on 'table-*' display values

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Thu, 27 Nov 2008 19:02:39 -0800
Message-ID: <c9e12660811271902s6b9f2696h78391ad736b50b35@mail.gmail.com>
To: "James Hopkins" <james@idreamincode.co.uk>
Cc: "CSS 3 W3C Group" <www-style@w3.org>

(replying w/cc to list)

On Thu, Nov 27, 2008 at 4:17 PM, James Hopkins <james@idreamincode.co.uk> wrote:
>
> On 27 Nov 2008, at 23:46, Garrett Smith wrote:
>
>>
>> On Thu, Nov 27, 2008 at 8:36 AM, James Hopkins <james@idreamincode.co.uk>
>> wrote:
>>>
>>
>>
>>
>>> Has there been talk of a resolution for this issue? What with the arrival
>>> of
>>> IE8 (which supports all these values), there's currently a lot of talk
>>> around about authors realistically being able to use these values for
>>> their
>>> layouts. However, I do believe without clarification this issue is going
>>> to
>>> limit the use of the 'table-*' values somewhat. FYI, FF3, Opera and
>>> Safari
>>> all ignore 'position:relative' in the aforementioned context.
>>>
>>
>> That is not true. While top and left values may not apply, we can see
>> that the browser does handle positioned td elements differently.
>
>   [Bangs head against table] Sorry for that mistake. Below I've also added
> IE8's result for your test

It would be interesting to see what IE6 and 7 do. IE8 has significant
changes to offset* (IE7 had fewer problems related to BODY).

CSSOM Views has been implemented in various ways as it evolves. The
spec has changed Safari and IE8 (IE8 broke the more sensible approach
of IE7).

Differences in offset* can be seen in IE6, 7, 8, FF3, Opera 9.2, 9.5,
Safari2, Safari 3. (8 fairly modern browsers). The offset* does not
work reliably across browsers or versions. It is unreasonable to
standardize something that is so varied.

Suggestion: Create a new property that can be clearly defined, and
fulfills developers' needs.

There may be considerations for whether that TD can be considered a
containing block in a more pure CSS sense.

http://www.w3.org/TR/CSS21/visudet.html#containing-block-details

| # If the element has 'position: absolute', the containing block is
established
| by the nearest ancestor with a 'position' of 'absolute', 'relative'
or 'fixed'...

I can see a positioned div in positioned TD that does not use the TD
as a containing block in several browsers. The following example shows
"positioned div in positioned TD" in the top-left of the document in
Saf 2, 3, FF3, Op9.6.

<!DOCTYPE html>
<html lang="en">
<head>
	<title>Untitled</title>
</head>
<body>
<h1>TD Containing Block</h1>

<hr>
<table border='1' style="margin-top: 100px; width: 200px;">
<caption>Here is table Caption</caption>
<tr><th>first row</th></tr>
<tr><td style="position:relative">
second row
<div style="position: absolute; top: 0; left: 0">positioned div in
positioned TD</div>
</td></tr>
</table>
</body>
</html>

Result: Opera 9.6, Safari 2, 3, Firefox 3:
"positioned div in positioned TD" appears in top-left of window.

Result Opera 9.6, Firefox 3:
position of td: relative

Result Safari 2, 3:
position of td: static

Safari seems to ignore position on a TD. This is a violation of CSS
2.1[1]. Other browsers respect top/left, but do not apply top/left
values. IE does apply top /left values to relatively positioned TD.

When the TD has position: relative and its child div has position:
absolute, Opera, Safari, and Firefox all disagree on what the div's
offsetParent should be. The implementations have not asked the
question of what to do in that case.

| Note. Table cells may be relatively and absolutely positioned, but this
| is not recommended: positioning and floating remove a box from the
| flow, affecting table alignment.

There are a few problems with that argument. The first is that it is
based on a false statement. Specifically position: relative does not
remove a box from flow. So it cannot be said that "positioning"
removes a box from flow. It is an erroneous argument. It could be said
that using absolute positioning is not recommended for a table cell
because it would the cell from flow. This would follow logical sense,
however, it is not what browsers seem to do.

FF does apply top/left values for an absolutely positioned TD and IE
may too (though I can't test that now). Opera and Safari do not.
Safari does not consider the element to be positioned.

Results vary more when applying position to TR and TABLE and an
absolute div in a TD. The argument for not using position on
tbody/tr/td is that it is not clearly defined, it does not work
consistently.

What are the cases where applying top/left values to a positioned cell
would be desirable?

[1]http://www.w3.org/TR/CSS2/tables.html#q7

Garrett

>> Result:
>> FF3, Opera 9.6:
>> BODY
>> TD
>>
>> Safari 3:
>>  BODY
>>  BODY
>
>    IE8:
>    TD
>    TD
>>
>>
>> Garrett
>>
>
>
Received on Friday, 28 November 2008 03:03:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:17 GMT