70961 - Bidi easy stuff

Status: RESOLVED FIXED

(Core :: Internationalization, defect)

Description

[Mike Kaply [:mkaply]]

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.

Comment 1

[Mike Kaply [:mkaply]]

Attachment: Addition of dir attribute to NSDocument, and associated autogenerated changes

Comment 2

[Mike Kaply [:mkaply]]

Attachment: Layout atoms and enums and some misc changes

Comment 3

[Chris Waterson]

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.

Comment 4

[Johnny Stenback (:jst)]

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

Comment 5

[Mike Kaply [:mkaply]]

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

[Lina Kemmel]

Stenback:

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

Thanks.

Comment 7

[Lina Kemmel]

Stenback:

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

Comment 8

[Mike Kaply [:mkaply]]

Attachment: Document changes to support DOM changes - should nsDocument.h be using NS_DECL_IDOMNSDOCUMENT like nsXULDocument?

Comment 9

[Erik van der Poel]

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?

Comment 10

[Johnny Stenback (:jst)]

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

[Lina Kemmel]

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...)

Comment 12

[Johnny Stenback (:jst)]

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

Comment 13

[Mike Kaply [:mkaply]]

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

[Roozbeh Pournader]

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.

Comment 15

[Johnny Stenback (:jst)]

document.dir is needed only for compatibility with MS IE.

Comment 16

[Roozbeh Pournader]

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

Comment 17

[timeless]

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

[Roozbeh Pournader]

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

[Andreas Becker]

Changing QA Contact to [e-mail].

Comment 20

[Johnny Stenback (:jst)]

Wasn't this already checked in? Should this be marked FIXED?

Comment 21

[Mike Kaply [:mkaply]]

Yep, I was just about to do that.

This stuff is in.