[FIX]DIR attribute is ignored in LI element

RESOLVED FIXED in mozilla1.0

Status

()

Core
Layout
P2
normal
RESOLVED FIXED
16 years ago
16 years ago

People

(Reporter: Lina Kemmel, Assigned: bz)

Tracking

Trunk
mozilla1.0
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

16 years ago
DIR attribute in <LI> element has no effect since mozilla 0.9.2. It's working 
in older builds.
Tested only on Windows NT, but probably happens for all platforms.
(Reporter)

Comment 1

16 years ago
DIR attribute, inherited by LI from its parent, works fine.
Mozilla's current behaviour is broken, but it's not clear to me what is the
correct rendering of a <li dir="rtl"> within a <ul dir="ltr">. The ordering of
the item's text should definitely be right-to-left, but where should the bullet
be? Is the location of bullets a function of the directionality of the list or
the directionality of the item?

To me it seems more logical and natural to say that it is a function of the
directionality of the list, i.e. that the bullets will be on the same side of
every item in a given list.

By the same token, if you have a <tr dir="ltr"> within a <table dir="rtl">, I
would not expect the order of cells in that row to be right-to-left and other
rows to be left-to-right.

The CSS formatting model would suggest that the bullet should be on the side
given by the direction of the list-item, since there is no special list
formatting object -- the UL is just a normal block (with padding-left, though,
which should really be padding-start, which is a rather ugly issue if the
direction changes in the middle).  But the CSS3 lists module may have something
different to say.  cc:ing Ian.
Does the CSS 'direction: rtl;' work?
CSS 'direction: rtl;' does work.

To amplify comment 5: using CSS it works according to dbaron's interpretation:
the bullet appears on the right, and the text is orderered from right-to-left.
That was also the formatting preferred by people on the W3C HTML list; see
http://lists.w3.org/Archives/Member/w3c-html-wg/2002JanMar/0171.html for those
with access.
Created attachment 69498 [details]
CSS example

Updated

16 years ago
QA Contact: petersen → amar
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

16 years ago
Target Milestone: --- → Future
Ouch. Nasty issue. I think what David describes is correct though. If you don't
want to move the bullet, then use <span dir=""></span>. No?
OK, it looks as if there is consensus (with me in a dissenting minority of one)
on the correct way to render an RTL list item, and Mozilla renders like that
when the direction is set in CSS. The bug is only when direction is set by the
|dir| attribute in HTML.

Parsing issue?

Created attachment 70871 [details] [diff] [review]
Patch to fix

List items were dropping common attributes (dir and lang) on the floor...
taking bug.  reviews?
Assignee: attinasi → bzbarsky
OS: Windows NT → All
Priority: -- → P2
Hardware: PC → All
Summary: DIR attribute is ignored in LI element → [FIX]DIR attribute is ignored in LI element
Target Milestone: Future → mozilla1.0
Comment on attachment 70871 [details] [diff] [review]
Patch to fix

r=dbaron
Attachment #70871 - Flags: review+
nsHTMLTableCaptionElement has the same problem.  Want to fix that too?  (cc:ing
bernd so he knows about it, since it would cause all stylistic attributes not to
work on caption elements.)
Created attachment 70930 [details] [diff] [review]
Patch fixing LI and CAPTION

I checked and all the other classes seem to do this correctly.
Attachment #70871 - Attachment is obsolete: true
Comment on attachment 70930 [details] [diff] [review]
Patch fixing LI and CAPTION

r=dbaron
Attachment #70930 - Flags: review+

Comment 17

16 years ago
Comment on attachment 70930 [details] [diff] [review]
Patch fixing LI and CAPTION

sr=attinasi
Attachment #70930 - Flags: superreview+

Comment 18

16 years ago
a=asa (on behalf of drivers) for checkin to 0.9.9
Keywords: mozilla0.9.9+
checked in
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.