Closed
Bug 28498
Opened 25 years ago
Closed 25 years ago
Implement "Show All Tags" editing mode
Categories
(Core :: DOM: Editor, defect, P1)
Core
DOM: Editor
Tracking
()
VERIFIED
FIXED
M16
People
(Reporter: bijals, Assigned: cmanske)
References
Details
(Whiteboard: [nsbeta2+ until 5/16] Composer feature work)
Attachments
(1 file)
Steps:
1) Create a table
2) Type some text and add spaces to the end of it so column is bigger than text
3) Hit the centering icon
Actual Results: Weird tag inside table and centering does not work
Expected Results: Text is centered and no weird tags
Build Date/Platform: 2/16/00-15 on NT
Comment 1•25 years ago
|
||
reassign to cmanske; change platform/os to ALL
Charley--I don't think we should ship beta1 with the little tags for Divs and
Spans. I think this is going to complicate things a bit more than we'd like (as
well as confuse some users who will think they typed the "D").
Bij--in my testing on Mac, I do see that the text gets centered but it is
centered between the "D" and the right side of the table cell (not within the
whole table cell).
Assignee: brade → cmanske
OS: Windows NT → All
Hardware: PC → All
Target Milestone: M15
Assignee | ||
Comment 2•25 years ago
|
||
As Kathy says, centering does work. It's currently hard to get a situation that
demonstrates it. Spaces certainly won't -- they are just more content.
This will need the Table Properties dialog, where you can set the width of a
cell to be wider than that needed for the text.
You can see that now if you create a 2-row table, and put a few characters in
the first cell, then more characters in the cell below. Now you can center the
text in the first cell. The "D" appears at the beginning of the centered line,
as Kathy saw.
But it's ok if we don't want these for Beta1. Until we get this whole feature
designed, it's probably best not to confuse the user.
The change is simple - remove 2 rules from EditorContent.css.
Proposing for PDT approval for Beta1.
Assignee | ||
Comment 4•25 years ago
|
||
Since the request to remove the icons for DIV and SPAN wasn't approved,
the issue is now whether we should show them in "normal" editing mode,
or only show them in a "show all tags" editing mode.
Changing Summary to reflect that.
Keywords: beta1
Summary: Centering text in a table creates a weird visible tag element and does not work → Implement "Show All Tags" editing mode
Whiteboard: [PDT-]
Target Milestone: M14 → M15
Comment 6•25 years ago
|
||
updating keyword and status whiteboard to reflect that this is a beta 2 feature
work bug that the Composer team deems a must fix for beta 2.
Assignee | ||
Comment 7•25 years ago
|
||
Mostly all done. Just need to connect icons and file bugs on related issues.
Assignee | ||
Comment 8•25 years ago
|
||
Icons are checked in for all the HTML tags. Unfortunately, the size of the new
images reveals a problem with our CSS strategy for displaying them:
(The current image size is 16px wide by 35px high)
This works for block tags:
p {
min-height: 35px; margin-left: 2px; margin-top: 2px;
padding-left: 18px;
background: url(chrome://editor/skin/images/tag-p.gif) no-repeat;
background-position: top left;
}
This doesn't work for inline:
b {
min-height: 35px; margin-left: 2px; margin-top: 2px;
padding-left: 18px;
background: url(chrome://editor/skin/images/tag-b.gif) no-repeat;
background-position: top left;
}
The line height doesn't increase, so the image is chopped off and you can't
see the text for the tagname.
This works for inline:
u:before {
min-height: 35px; margin-left: 2px;
content: url(chrome://editor/skin/images/tag-u.gif);
}
But using a "before" rule for inline isn't a good idea, as it complicates
our ability to select the tag for property editing. Mike Judge is implementing
the behavior that a single click on a "before" image will select that image;
this is needed to select the "before" icon for named anchors, which is a special
case since it has no content. This would conflict with single clicking on an
icon for other inline tags, which we want to snap to the content, as it does
now, for normal editing. We want to double-click on the icon to trigger the
property dialog for the tag, which we should be able to do when using the
background image CSS rules.
Marc: Why doesn't min-heigh work for inline tags? Is that a bug?
Comment 9•25 years ago
|
||
The CSS2 spec says that min-height applies to all elements EXCEPT 'non-replaced
inline elements and table elements' so I am guessing there is no bug here. It is
a little unclear to me exactly what 'non-replaced inline element' means, but I
think the idea is it will apply to things like images or form-elements but not
inlines like <B> and <U>.
I'll check with some more experienced style players and make sure my
interpretation is correct. If it is, then there is no bug here with min-height
not being applied to inlines.
Comment 10•25 years ago
|
||
[nsbeta2+ until 5/16]
Whiteboard: Composer feature work → [nsbeta2+ until 5/16] Composer feature work
Assignee | ||
Comment 11•25 years ago
|
||
This is finished except for redoing the icons to be smaller. Inline icons
should be horizontal so they are not clipped as they are now.
Assignee | ||
Comment 12•25 years ago
|
||
Beppe is working on icons -- we are real close on this!
Assignee | ||
Comment 13•25 years ago
|
||
Feature is complete -- redisplay problems when switching amoung edit modes is
covered by bug 9151
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 14•25 years ago
|
||
verified in 5/16 build.
Comment 15•2 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•