Closed Bug 196292 Opened 17 years ago Closed 4 years ago

align attribute affects child tables inconsistently

Categories

(Core :: Layout: Tables, defect, P3)

x86
All
defect

Tracking

()

RESOLVED FIXED
Future
Tracking Status
firefox45 --- fixed

People

(Reporter: ian, Assigned: dbaron)

References

(Depends on 1 open bug)

Details

(Keywords: testcase)

Attachments

(8 files)

A cell whose align attribute is set to "left" overrides the UA stylesheet rule
for <hr> elements in tables that are nested within it.

However, a cell whose align attribute is set to "right" does not.

This is inconsistent.

It is unclear to me which behaviour is technically correct. IE does what we do
for "left" for "right" as well, but a CSS interpretation might suggest there
should be no magic involved, and therefore the align attribute shouldn't affect
nested elements' ua.css rules, and our "right" behaviour is the correct one.

In any case, we should be consistent.

jesus_X said he'd attach a testcase.
s/<hr>/<th>/

I discovered this behavior today using OS/2: W2K -> All.

I suggest the better behavior is for neither align=left nor align=right to be
inheritable, unlike IE6, which allows both to inherit. Netscape 4 allows neither
to inherit. 
OS: Windows 2000 → All
> A cell whose align attribute is set to "left" overrides the UA stylesheet rule
> for <hr> elements in tables that are nested within it.

There is no such rule, actually.  So we just inherit the text-align through; the
only reason "left" and "right" act differently is because align="left" computes
to "text-align:left" and align="right" computes to "text-align: -moz-right" and
then we hit the code in nsStyleContext::ApplyStyleFixups which basically resets
-moz-right and -moz-center to "initial" if they are applied to a table (where
"table" is "display:table").

In quirks mode, text-align is explicitly set to "initial" in quirk.css for
<table>, so none of this is an issue.

So if there were no magic involved we would act exactly like IE does.

Felix, should align="right" inherit into a <p>?  If yes, then why should it not
inherit into a <table>?  (Note that this is all in standards mode; in quirks
mode we already do something consistent.)
So, in other words, it would be fixed by the patch on bug 64510?

What do other browsers do?
Depends on: 64510
It'd be fixed to be consistent and to never inherit HTMl align into a table, yes.
> HTML testcase - strict - *maybe* align= should inherit directly into <P>
>(quirks doesn't)

Sure it does.  Remove the doctype -- the align inherits into the <p>.

So the question remains.  In _standards_ mode, should we treat <p> and <table>
differently here?
Slap me for sloppy edit after cut & paste. Up too late on IRC last night. Still
not recovered? Let me try again.

Comment 7 (attachment 116542 [details] caption): s/(quirks doesn't)/(quirks does)/

I vote for bug 64510 fix "never inherit HTML align into a table" as per comment
6.
Keywords: testcase
Priority: -- → P3
Target Milestone: --- → Future
This file shows inconsistent behaviour when the font size is changed while
viewing.
No other browser inherits in standards mode testcase, IE8, webkit and Opera all show both P centered in the standards mode.
Does text-align inherit into tables in those browsers by default?

What does the testcase look like in those browsers if you set text-align:inherit on the table?

Or is it just that they don't map <td align=""> to text-align?
Note that we could also just introduce align:-moz-left if we wanted...
Assignee: layout.tables → nobody
QA Contact: madhur → layout.tables
(In reply to Boris Zbarsky [:bz] from comment #15)
> Note that we could also just introduce align:-moz-left if we wanted...

We did that in bug 64510.
... but I didn't add this piece:
https://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/bfa3993c6c16/table-reset-alignment-left

I should test that it's consistent with both Chromium and Edge.
So Chromium 45 and IE11 match on the 5 testcases on this bug (attachment 116522 [details], attachment 116523 [details], attachment 116542 [details], attachment 116543 [details], attachment 116568 [details]).  I can't test Edge now, although I might have a chance to do so tomorrow.
... continuing from comment 18:  current Gecko differs on the second and fourth of those testcases (on the second table in them).  With the patch in comment 17, it matches on all 5.
Without the patch, cell-align-stopped-at-table-1-standards.html fails
because the th in the align=left cell is left-aligned rather than
centered.
Attachment #8693381 - Flags: review?(bzbarsky)
Assignee: nobody → dbaron
Status: NEW → ASSIGNED
Would you mind pointing me at the spec here?
The spec at <https://html.spec.whatwg.org/multipage/rendering.html#flow-content-3> says:

  The div element, when it has an align attribute whose value is an ASCII case-insensitive
  match for the string "left", is expected to left-align text within itself, as if it had
  its 'text-align' property set to 'left' in a presentational hint, and to align
  descendants to the left.

  The div element, when it has an align attribute whose value is an ASCII case-insensitive
  match for the string "right", is expected to right-align text within itself, as if it
  had its 'text-align' property set to 'right' in a presentational hint, and to align
  descendants to the right.

and similar for "center"/"middle".

Now it's not clear to me what "as if" means in terms of CSS inheritance.  

https://html.spec.whatwg.org/multipage/rendering.html#tables-2 explicitly lists the following as preshints:

  p[align=right i], h1[align=right i], h2[align=right i], h3[align=right i],
  h4[align=right i], h5[align=right i], h6[align=right i] {
    text-align: right;
  }

etc.  But that doesn't apply to <div>, apparently.  And nothing special in there for <table>.
Comment on attachment 8693381 [details] [diff] [review]
Make table inside align=left reset alignment just like for align=center and align=right

r=me, but please raise a spec issue on HTML.
Attachment #8693381 - Flags: review?(bzbarsky) → review+
(In reply to Boris Zbarsky [:bz] from comment #23)
> The spec at
> <https://html.spec.whatwg.org/multipage/rendering.html#flow-content-3> says:
> 
>   The div element, when it has an align attribute whose value is an ASCII
> case-insensitive
>   match for the string "left", is expected to left-align text within itself,
> as if it had
>   its 'text-align' property set to 'left' in a presentational hint, and to
> align
>   descendants to the left.

To be clear "align descendants" is a link to something that's actually not that far off from correct:

https://html.spec.whatwg.org/multipage/rendering.html#align-descendants

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. Aligned elements are expected to be aligned by having the used values of their left and right margins be set accordingly.


But I'll raise some issues.
https://github.com/whatwg/html/issues/369 is the issue that represents the missing bit most strictly related to this bug fix
Also filed 370.  Also noticed that in our implementation, h1...h6 have the "align descendants" behavior, but that seems like somethnig that might be possible to remove, so I didn't file a bug on it.
https://hg.mozilla.org/integration/mozilla-inbound/rev/983a6d09ddea6c851c5e2fa1fc1f49a0f0a007fa
Bug 196292 - Make table inside align=left reset alignment just like for align=center and align=right.  r=bz
https://hg.mozilla.org/mozilla-central/rev/983a6d09ddea
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Depends on: 1229401
You need to log in before you can comment on or make changes to this bug.