Bug 37590 - Centering of th should use CSS text-align
Summary: Centering of th should use CSS text-align
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Minor
Assignee: Nobody
Depends on:
Reported: 2010-04-14 11:25 PDT by Aryeh Gregor
Modified: 2010-09-12 11:06 PDT (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Aryeh Gregor 2010-04-14 11:25:08 PDT
data URL test case:

data:text/html,<!doctype html>
<table><tr><th>Table 1<tr><td>Longish string to observe centering</table>
<table style=text-align:left><tr><th>Table 2<tr><td>Longish string to observe centering</table>

Expected results: th should be centered in both cases, because of a text-align: center rule in CSS that overrides the inheritance.  th { text-align: center } is recommended in both HTML5 and CSS2.1: <http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#alignment> <http://www.w3.org/TR/CSS2/sample.html>

Actual results: The second th is not centered.  The text-align:left from the ancestor table somehow overrides the alignment of the th.  Web Inspector shows no text-align rule for th, so th centering is apparently not handled by CSS.

Firefox <https://bugzilla.mozilla.org/show_bug.cgi?id=559382> and Opera both seem to have the same bug.  IE8 reportedly does not have the bug: <http://haslayout.net/css/Non-Inherited-TH-Text-Align-Bug>.  If there's a compelling reason to not use CSS for centering here, a spec bug should be filed against HTML5 so this can be documented for other browsers.

Observed in Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.3 Safari/533.4.
Comment 1 Aryeh Gregor 2010-04-15 07:32:15 PDT
Clarification: HTML5 specifies further behavior to capture the legacy semantics of align=left and such, namely:

The div, caption, thead, tbody, tfoot, tr, td, and th elements, when they have
an align attribute whose value is an ASCII case-insensitive match for the
string "left", are expected to left-align text within themselves, as if they
had their 'text-align' property set to 'left' in a presentational hint, and to
align descendants to the left.

. . .

When a user agent is to align descendants of a node, the user agent is expected
to align only those descendants that have both their 'margin-left' and
'margin-right' properties computing to a value other than 'auto', that are
over-constrained and that have one of those two margins with a used value
forced to a greater value, and that do not themselves have an applicable align
attribute. When multiple elements are to align a particular descendant, the
most deeply nested such element is expected to override the others.

So fixing this would not mean causing misrendering of "<table align=left><tr><th>Foo...".  It would make actual CSS properties behave the way you expect CSS properties to behave, though, which would be nice.  (See discussion on the Mozilla bug.)