Opened 14 years ago

Closed 14 years ago

#4097 closed defect (fixed)

InlineEditBox: design problem with throwing away srcNodeRef

Reported by: bill Owned by: bill
Priority: high Milestone: 1.0
Component: Dijit Version: 0.9
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)

The 0.9 InlineEditBox? widget has an initial design flaw in the way that it displays editable, the view (read-only) version of the text.

Currently, it throws away srcNodeRef and replaces it with a <span> named "editable". It then tries to make the <span> look like the original srcNodeRef by copying styles, but that doesn't really work. For example, copying width will fail. If the original srcNodeRef is:

<div style="width: 50%">

Then it will end up setting the <span> to have width=600px, the computed width of the <div> at the time the widget was instantiated. But if the user resizes the browser window the <span> won't resize, even though it should go to 50%.

Also, copying the styles requires a call to getComputedStyle() during widget initialization which is against our rules, because it doesn't work on elements where one of the ancestors is display:none, at least not in safari. Which means there will be problems putting InlineEditBox? in the non-selected tab.

InlineEditBox? should work like 0.4 where we keep the original srcNodeRef in the document.

See related bug #4098.

Change History (10)

comment:1 Changed 14 years ago by bill

Description: modified (diff)

comment:2 Changed 14 years ago by bill

Owner: changed from haysmark to Douglas Hays

comment:3 Changed 14 years ago by bill

(In [10354]) Better testcase for how I want InlineEditBox? to work.

  • shows how you should specify a width for inline elements similar to the way

you specify the width of an <input>... ie, a width that is unrelated to the width of the current value.

  • Also gives much better test of inherited styles from <style> tags and from the

browser's builtin rules for <p>, <h3>, etc. (All such style info must appear in the non-editing version of the text and the edit version of the tet.)

  • Also demonstrates a problem with specifying paragraphs of text, inserting

unwanted line breaks (see #4098 for possible solution).

Refs #4097, #4098, #4167.

comment:4 Changed 14 years ago by Douglas Hays

Owner: changed from Douglas Hays to bill

InlineEditBox? being redesigned by bill

comment:5 Changed 14 years ago by bill

(In [10631]) Start refactor of InlineEditBox? to keep original srcNode, and create edit widget on demand. Code not working (well) yet. Refs #4097, #4098.

comment:6 Changed 14 years ago by bill

(In [10824]) Continue InlineEditBox? work. Since we can't compute the width of a <span> on IE, since it's display:inline, I had to put a width="..." parameter for the widget. Refs #4097, #4098.

comment:7 Changed 14 years ago by bill

(In [10893]) First pass at getting save & cancel buttons working. Refs #4097, #4098.

comment:8 Changed 14 years ago by bill

(In [10918]) Avoid screen jitter when switching from display mode to editor. Refs #4097, #4098.

comment:9 Changed 14 years ago by bill

(In [10919]) Fix inline mode (ie, editors for numbers, etc. that are inline with a line of text). Refs #4097, #4098.

comment:10 Changed 14 years ago by bill

Resolution: fixed
Status: newclosed

(In [10920]) Make no-value indicator work, and let user specify arbitrary HTML to use when no value is specified. Fixes #4362. Also, due to this and all the previous checkins, fixes #4097, #4098.

Note: See TracTickets for help on using tickets.