Closed Bug 559382 Opened 15 years ago Closed 15 years ago

Centering of th should use CSS text-align

Categories

(Core :: Layout: Tables, defect)

Product:
Core
Component:
Layout: Tables
Version:
1.9.2 Branch
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: ayg, Unassigned)

Details

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. Firebug shows no text-align rule for th, so th centering is apparently not handled by CSS. WebKit and Opera both seem to have the same bug, and I'll file a bug against WebKit too. 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; rv:1.9.2.3) Gecko/20100407 Ubuntu/9.10 (karmic) Firefox/3.6.3
<th> in Gecko uses a specified non-CSS text-align value (-moz-center-or-inherit) that behaves in the following way: if the computed value of the parent's text-align is the initial value (see the "nameless value" mess CSS21 lists for text-align), then compute to "center", else compute to the parent's text-align. This behavior is needed so that in this markup: <tr align="left"><th>text</th></tr> the header will be left-aligned instead of being centered. I believe this behavior for align="left" is needed for web compat last I checked; hence no surprise that Webkit and Opera do the same thing on that testcase (as does IE8 in IE7 mode). Note that this behavior is not expressible in CSS as it stands (though we could of course add the -moz value above to our parseable CSS syntax...) Note that the part of CSS21 you cite is informative, not normative, so not following it is not a spec violation or anything. It says so right as the first line of the appendix, in case you missed it. I'm not aware of any UA that actually uses a default stylesheet that matches all of appendix D (in part because some of the rules in there are totally daft and not compatible with web reality). > a spec bug should be filed against HTML5 so this can be documented for other > browsers Please feel free to!
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
(In reply to comment #2) > <th> in Gecko uses a specified non-CSS text-align value > (-moz-center-or-inherit) that behaves in the following way: if the computed > value of the parent's text-align is the initial value (see the "nameless value" > mess CSS21 lists for text-align), then compute to "center", else compute to the > parent's text-align. > > This behavior is needed so that in this markup: > > <tr align="left"><th>text</th></tr> > > the header will be left-aligned instead of being centered. I believe this > behavior for align="left" is needed for web compat last I checked; hence no > surprise that Webkit and Opera do the same thing on that testcase (as does IE8 > in IE7 mode). HTML5 seems to be trying to capture this behavior: """ 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. """ <http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#alignment> This defines behavior that should (?) still capture the legacy semantics if you use the actual presentational attributes, but won't mess things up if you use CSS. Would Mozilla be potentially willing to implement this at some point (if someone is willing to do the work), or is this still INVALID? The described algorithm makes more sense to me, because it means that things work as expected as long as you stick to CSS. > Note that the part of CSS21 you cite is informative, not normative, so not > following it is not a spec violation or anything. It says so right as the > first line of the appendix, in case you missed it. I'm not aware of any UA > that actually uses a default stylesheet that matches all of appendix D (in part > because some of the rules in there are totally daft and not compatible with web > reality). I'm aware of that, which is why I made sure to cite HTML5 too. :) > > a spec bug should be filed against HTML5 so this can be documented for other > > browsers > > Please feel free to! If you don't think the algorithm given in the spec is implementable, please say why, and I'd be happy to file a bug.
> 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 would not include aligning the table cell in my example, no? And if the align="left" is a preshint and the <th> has "text-align:center" specified, it wouldn't align the text inside the <th>. > This defines behavior that should (?) still capture the legacy semantics It doesn't. See above. > Would Mozilla be potentially willing to implement this at some point As written, probably not, no. > If you don't think the algorithm given in the spec is implementable I think it's implementable (with a good bit of pain). I don't think it's what UAs actually do. Certainly Gecko doesn't. In particular, this algorithm doesn't do aligning correctly in the simple case for <th>, but imposes all sorts of costs in terms of aligning blocks inside table cells that don't seem relevant to web compat to me.
(In reply to comment #4) > That would not include aligning the table cell in my example, no? I'm not sure. I think it's intended to align the table cell in your example, but I can't figure out what all the stuff in the spec about margins is supposed to mean. > And if the > align="left" is a preshint and the <th> has "text-align:center" specified, it > wouldn't align the text inside the <th>. AFAICT, presentational hints are supposed to be treated a zero-specificity author-stylesheet rules, so they should override any rule (like text-align: center) in the UA stylesheet. It explicitly says that the hint applies to all descendant elements as well as to the element where it's specified, so it overrides the style even though it's on a descendant. > I think it's implementable (with a good bit of pain). I don't think it's what > UAs actually do. Certainly Gecko doesn't. In particular, this algorithm > doesn't do aligning correctly in the simple case for <th>, but imposes all > sorts of costs in terms of aligning blocks inside table cells that don't seem > relevant to web compat to me. Well, I've filed a bug: <http://www.w3.org/Bugs/Public/show_bug.cgi?id=9542>.
> I can't figure out what all the stuff in the spec about margins is supposed to > mean. It basically means that only blocks are aligned. > It explicitly says that the hint applies to all descendant elements Where? I read the spec you linked, and it does NOT say that as far as I can see. > Well, I've filed a bug: <http://www.w3.org/Bugs/Public/show_bug.cgi?id=9542>. Thank you.
(In reply to comment #6) > > It explicitly says that the hint applies to all descendant elements > > Where? I read the spec you linked, and it does NOT say that as far as I can > see. Sorry, I didn't mean to say "all". It does say it applies to descendants ("align descendants to the left"), but it places that restriction about margins on them that I don't understand.
You need to log in before you can comment on or make changes to this bug.