The default bug view has changed. See this FAQ.

Status

()

Core
Internationalization
RESOLVED FIXED
16 years ago
4 years ago

People

(Reporter: mkaply, Assigned: mkaply)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Assignee)

Description

16 years ago
The goal of this bug is to grab some of the low hanging fruit in Bidi.

Things like adding new Atoms and enums, or short codepaths that don't depend on 
the actual Bidi code, as well as some member variables.

Also, some autogenerated code in DOM.
(Assignee)

Comment 1

16 years ago
Created attachment 26826 [details] [diff] [review]
Addition of dir attribute to NSDocument, and associated autogenerated changes
(Assignee)

Comment 2

16 years ago
Created attachment 26830 [details] [diff] [review]
Layout atoms and enums and some misc changes

Comment 3

16 years ago
Changes to header files look fine to me modulo fixing (1) and (2), and
explaining (3), which concerns me a bit. I'd like rods to r= (4). Heads up
on (5).

1. No need for ``// IBMBIDI'' on the #endif's for such small #ifdefs.

2. In nsLayoutAtomList.h, let's just lump them all into one #ifdef instead of
   trying to preserve alpha order. We can re-sort when/if we remove #ifdefs.

3. What is the new ``mRightEdge'' member in nsHTMLReflowState meant to be?

4. rods should comment on changes to nsFormControlFrame.cpp. N.B. that there's
   a bunch of #if 0'd code that you might need to update, too.

5. Be awary that heikki may have moved (or may be planning to move)
   nsStyleConsts.h to the content directory.

Could someone remind me why we need to add the 'dir' attribute to NSDocument?
(Assignee)

Comment 5

16 years ago
waterson:

for 1 and 2, will do.

mRightEdge is needed because currently reflow is designed to allow the right 
side to be unconstrained. This can't happen in a right to left layout. Here is 
the new relevant code in nsBlockFrame:

  if (aUpdateMaximumWidth) {
    availWidth = NS_UNCONSTRAINEDSIZE;
  }
#ifdef IBMBIDI
  else {
    nscoord rightEdge = aState.mReflowState.mRightEdge;
    if ( (rightEdge != NS_UNCONSTRAINEDSIZE)
         && (availWidth < rightEdge) ) {
      availWidth = rightEdge;
    }
  }
#endif // IBMBIDI
  aLineLayout.BeginLineReflow(x, aState.mY,
                              availWidth, availHeight,
                              impactedByFloaters,
                              PR_FALSE /*XXX isTopOfPage*/);

availWidth is now set to the mRightEdge which might not be unconstrained.

Comment 6

16 years ago
Stenback:

Please see
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/dir.asp

Thanks.

Comment 7

16 years ago
Stenback:

P.S.:
Here is an URL with document.dir:
http://www.qsm.co.il/NewHebrew/HebrewTest/rtl.htm

(Assignee)

Comment 8

16 years ago
Created attachment 27004 [details] [diff] [review]
Document changes to support DOM changes - should nsDocument.h be using NS_DECL_IDOMNSDOCUMENT like nsXULDocument?

Comment 9

16 years ago
So, Lina, basically, you're saying that Mozilla should support document.dir
because MSIE does. Right? Johnny, is this good enough for you? Or do you need
more justification?
That's fine with me, and the changes look good to me. r=jst

Michael, nsDocument should ideally be using NS_DECL_IDOMNSDOCUMENT but please
leave that as is now since making that change requires implementing a few more
methods in nsDocument.cpp, I actually have this change on a branch and I will
land that as part of a bigger checkin.

Comment 11

16 years ago
Erik:

Also, MS states that "This property is defined in HTML 4.0  and is defined in 
Document Object Model (DOM) Level 2 ." (though I couldn't find these 
definitions in specs...)

document.dir is not defined in the DOM Level 2 spec, if MS claims it is, they're
wrong.
(Assignee)

Comment 13

16 years ago
I would guess that what Microsoft is claiming is that since dir is an attribute, 
it should be an attribute on everything.

Notice the list of things they say dir is an attribute on - all HTML elements 
pretty much, but they through document in the midle of it.

A, ACRONYM, ADDRESS, AREA, B, BDO, BIG, BLOCKQUOTE, body, BUTTON, CAPTION, 
CENTER, CITE, CODE, COL, COLGROUP, custom, DD, DEL,
        DFN, DIR, DIV, DL, document, DT, EM, EMBED, FIELDSET, FONT, FORM, Hn, 
HTML, I, IMG, INPUT type=button, INPUT type=checkbox, INPUT
        type=file, INPUT type=image, INPUT type=password, INPUT type=radio, 
INPUT type=reset, INPUT type=submit, INPUT type=text, INS, KBD,
        LABEL, LEGEND, LI, LISTING, MAP, MARQUEE, MENU, NOBR, OBJECT, OL, 
OPTION, P, PLAINTEXT, PRE, Q, RT, RUBY, S, SAMP, SELECT, SMALL,
        SPAN, STRIKE, STRONG, SUB, SUP, TABLE, TBODY, TD, TEXTAREA, TFOOT, TH, 
THEAD, TR, TT, U, UL, VAR, XMP

Comment 14

16 years ago
I was just reading the DOM 2 HTML spec. "dir" is not an attribute of document.
Why does one need document.dir when he has html.dir and body.dir?

BTW, this is what I found at
   http://www.microsoft.com/globaldev/articles/mideast.asp

"Placement of the DIR on the HTML element vs. the BODY element By HTML
specification the DIR attribute placed on the HTML element sets the layout
direction of the document. In IE5 this will also cause the ambient property
(used by embedded OLE objects) of the document to be set. When no DIR attribute
is placed on the HTML element the direction is left to right. However, when one
sees <HTML DIR=RTL> the following behavior can be expected:
  * The OLE/COM ambient property of the document is set to AMBIENT_RIGHTTOLEFT.
  * The document direction can be toggled through the document object model
   (DOM) (document.direction="ltr/rtl").
  * An HTML Dialog will get the correct extended windows styles set so it
    displays as a RTL dialog on a Bidi enabled system.
  * If the document has vertical scrollbars, they will be on the left side if
    DIR=RTL.

If the DIR=RTL attribute is placed on the body instead of the HTML element: 

  * The OLE/COM ambient property for the document will not reflect the
    direction on the BODY. 
  * The ability to toggle the document's direction will be lost, because the
    body's direction is explicitly set. 
  * Dialog window frames and captions will not reflect the direction of the
    BODY. 
  * Vertical scrollbars will be reflect the direction assigned to the body, not
    the document.
document.dir is needed only for compatibility with MS IE.

Comment 16

16 years ago
So why won't you support document.all? Please, only for compatiblity with
MS IE!

Comment 17

16 years ago
fwiw, you could probably write your own mozilla extension that implemented 
document.all, but for now i'd like some W3 aware people to comment on this 
dicotomy.  ... Requests for document.all belong in some other bug.

Comment 18

16 years ago
I was making a joke about "document.all". I thought everyone would get that.
What I meant, was that "document.dir" should not be implemented, the reason
being the same as the reason for not implementing "document.all".

Comment 19

16 years ago
Changing QA Contact to mimi_fruchter@hotmail.com.
QA Contact: andreasb → mimi_fruchter
Wasn't this already checked in? Should this be marked FIXED?
(Assignee)

Comment 21

16 years ago
Yep, I was just about to do that.

This stuff is 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.