Closed
Bug 22786
Opened 25 years ago
Closed 24 years ago
Table Dir in html tag not propagated
Categories
(Core :: Layout: Tables, defect, P3)
Tracking
()
VERIFIED
FIXED
M15
People
(Reporter: david.valentine, Assigned: harishd)
Details
Attachments
(5 files)
<HTML lang="ar-kw" dir="RTL"> A table direction tag dir=RTL is not propagated to tables on the page. IE uses this tag to set all the page a rtl.
Reporter | ||
Comment 1•25 years ago
|
||
Reporter | ||
Comment 2•25 years ago
|
||
More complex, in the HTML 4 spec, a dir=RTL effects the order that the table displays (and the direction of the text which is an internationalization issue) Adding additional attachements: Jpeg of IE display, and html for that page.
Reporter | ||
Comment 3•25 years ago
|
||
Reporter | ||
Comment 4•25 years ago
|
||
Updated•25 years ago
|
Assignee: karnaze → pierre
Comment 5•25 years ago
|
||
Reassigning to Pierre.
Comment 7•25 years ago
|
||
Block-moved to attinasi the bugs related to style inside tables
Assignee: pierre → attinasi
Status: ASSIGNED → NEW
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 8•25 years ago
|
||
Clearing dependency on 1044 - this is not a NavQuirks issue
No longer depends on: 1044
Comment 9•25 years ago
|
||
The problem appears to be with setting the direction on the HTML tag, not with inheritance of the direction into tables. I will attach an illustrative test case in a moment, but let me explain. Setting the direction on the BODY (via a style rule or in the HTML tag) will cause the proper inheritance of the direction into tables. Also, if the direction:RTL is set on the BODY then the entire document renders RTL as it is suppossed to. It looks like the 'dir=rtl' on the HTML tag is ignored, but I'll keep looking into it to find out why and who is responsible. See soon-to-be-attached testcase showing table iheritance of direction working when it is set on the BODY element instead of the HTML element.
Comment 10•25 years ago
|
||
Comment 11•25 years ago
|
||
It looks like the HTML tag's attribute is getting lost in the parser. Rick, can you look at this? I spent some time investigating and found that the HTML tag and attributes are parsed into valid tokens, however when we get to CNavDTD::BuildModel it sees that HTML tag is not handled so we just handle a default start token (and that is where I stopped looking). I will attach another testcase showing that the attributes on the HTML element never show up when you dump content from viewer. Interestingly, they do show up for both HEAD and BODY. If you agree that there is a problem with parsing the attributes of the HTML tag this bug probably needs a new summary and component, otherwise just send it back to me.
Assignee: attinasi → rickg
Status: ASSIGNED → NEW
Comment 12•25 years ago
|
||
Comment 13•25 years ago
|
||
Harish: let's look ahead into the tokendeque to get the html tag (if present) and its attriutes, and use them when opening the HTML tag in willbuildmodel().
Assignee: rickg → harishd
Comment 14•24 years ago
|
||
Harish: your patches look really good; with them the DIR attribute on the HTML tag is no longer ignored and the testcases all work correctly. Ship It!
Assignee | ||
Comment 15•24 years ago
|
||
<HTML> attributes are accounted for. FIXED.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 16•24 years ago
|
||
Usign 7/13, direction for all examples is 'rtl'. Verifying bug fixed.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•