Opened 14 years ago

Closed 14 years ago

#277 closed defect (wontfix)

IE6 Problem With Short Height Textarea

Reported by: Shane Birley Owned by: gogo
Priority: high Milestone:
Component: Xinha Core Version: trunk
Severity: minor Keywords:
Cc:

Description

I have just been testing some thing with the fixes from last night and it appears larger boxes have been fixed. Yet, here is something that I couldn't have seen until the fixes were completed.

IE6 users are now able to edit larger text areas BUT if the text area is shorter (approx. three lines high) the Xinha tanks. IE complains of an "invalid argument in line 1693 (char 7) of htmlarea.js".

Change History (8)

comment:1 Changed 14 years ago by anonymous

  • Component changed from Documentation to Xinha Core
  • Owner changed from akaEdge to gogo
  • Priority changed from normal to high
  • Severity changed from normal to major
  • Version set to trunk

comment:2 Changed 14 years ago by gogo

Can you attach a modified testbed.html (found in the examples directory) file which shows this problem please.

comment:3 Changed 14 years ago by gogo

Also, the size of the editor INCLUDES the toolbars and panels unless you configure it not to, if your editor is too small to include the toolbars and statusbar then things will be unpredictable. See the config options

  // Width and Height
  //  you may set these as follows
  //  width = 'auto'      -- the width of the original textarea will be used
  //  width = 'toolbar'   -- the width of the toolbar will be used
  //  width = '<css measure>' -- use any css measurement, eg width = '75%'
  //
  //  height = 'auto'     -- the height of the original textarea
  //  height = '<css measure>' -- any css measurement, eg height = '480px'
  this.width  = "auto";
  this.height = "auto";

  // the next parameter specifies whether the toolbar should be included
  // in the size above, or are extra to it.  If false then it's recommended
  // to have explicit pixel sizes above (or on your textarea and have auto above)
  this.sizeIncludesBars = true;

  // the next parameter specifies whether the panels should be included
  // in the size above, or are extra to it.  If false then it's recommended
  // to have explicit pixel sizes above (or on your textarea and have auto above)
  this.sizeIncludesPanels = true;

  // Panel dimensions, when present these and the width and height of the editor
  // _must_ be pixel widths if you wish to have config.sizeIncludesPanels = false
  // if you have sizeIncludesPanels true, they can be any valid CSS measurement.
  //
  // If you are using Xinha in a "Standards Mode" page (using doctype switching)
  // then you must use pixel heights for the top and bottom panels, otherwise
  // it won't work correctly.  Also remember that you MUST have the "px" appended
  // to pixel lengths or it won't work either!
  this.panel_dimensions =
  {
    left:   '200px', // Width
    right:  '200px',
    top:    '100px', // Height
    bottom: '100px'
  }

  // enable creation of a status bar?
  this.statusBar = true;

comment:4 Changed 14 years ago by Shane

I will tinker with this. Perhaps I need to set those to something larger, small, etc. I will try it and report back tomorrow.

comment:5 Changed 14 years ago by Shane

Where is this located? Is this in the "htmlarea.js"?

comment:6 Changed 14 years ago by Shane

Oh, wait, after rereading this, I can control the size of the editor window?

comment:7 Changed 14 years ago by gogo

You can simply set the size of the original textarea (and leave the default size configuration), but bare in mind that with the default config the toolbar, status bar and panels all must "fit" within that textarea's screen space.

comment:8 Changed 14 years ago by Shane

  • Resolution set to wontfix
  • Severity changed from major to minor
  • Status changed from new to closed

I will work with those settings. Since HTMLarea can tell certain areas not to use the editor (since some areas really don't require it) - I will see about configuring it all that way.

This ticket can be closed because I think this is not really an issue, but more of a "documentation required" kind of thing. Development ongoing, blah blah blah, etc, etc. To be updated later.

Note: See TracTickets for help on using tickets.