Closed
Bug 70961
Opened 24 years ago
Closed 24 years ago
Bidi easy stuff
Categories
(Core :: Internationalization, defect)
Core
Internationalization
Tracking
()
RESOLVED
FIXED
People
(Reporter: mkaply, Assigned: mkaply)
Details
Attachments
(3 files)
6.11 KB,
patch
|
Details | Diff | Splinter Review | |
7.18 KB,
patch
|
Details | Diff | Splinter Review | |
2.28 KB,
patch
|
Details | Diff | Splinter Review |
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•24 years ago
|
||
Assignee | ||
Comment 2•24 years ago
|
||
Comment 3•24 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.
Comment 4•24 years ago
|
||
Could someone remind me why we need to add the 'dir' attribute to NSDocument?
Assignee | ||
Comment 5•24 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•24 years ago
|
||
Stenback: Please see http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/dir.asp Thanks.
Comment 7•24 years ago
|
||
Stenback: P.S.: Here is an URL with document.dir: http://www.qsm.co.il/NewHebrew/HebrewTest/rtl.htm
Assignee | ||
Comment 8•24 years ago
|
||
Comment 9•24 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?
Comment 10•24 years ago
|
||
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•24 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...)
Comment 12•24 years ago
|
||
document.dir is not defined in the DOM Level 2 spec, if MS claims it is, they're wrong.
Assignee | ||
Comment 13•24 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•24 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.
Comment 15•24 years ago
|
||
document.dir is needed only for compatibility with MS IE.
Comment 16•24 years ago
|
||
So why won't you support document.all? Please, only for compatiblity with MS IE!
Comment 17•24 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•24 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•24 years ago
|
||
Changing QA Contact to mimi_fruchter@hotmail.com.
QA Contact: andreasb → mimi_fruchter
Comment 20•24 years ago
|
||
Wasn't this already checked in? Should this be marked FIXED?
Assignee | ||
Comment 21•24 years ago
|
||
Yep, I was just about to do that. This stuff is in.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•