Closed Bug 28498 Opened 25 years ago Closed 25 years ago

Implement "Show All Tags" editing mode

Categories

(Core :: DOM: Editor, defect, P1)

defect

Tracking

()

VERIFIED FIXED

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
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
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.
Status: NEW → ASSIGNED
Keywords: beta1
Target Milestone: M15 → M14
Putting on PDT- radar for beta1.
Whiteboard: [PDT-]
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
Moving to next milestone
Target Milestone: M15 → M16
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.
Severity: normal → major
Keywords: beta2
Priority: P3 → P1
Whiteboard: Composer feature work
Mostly all done. Just need to connect icons and file bugs on related issues.
Keywords: nsbeta2
Depends on: 37502
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?
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.
[nsbeta2+ until 5/16]
Whiteboard: Composer feature work → [nsbeta2+ until 5/16] Composer feature work
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.
Depends on: 38764
Beppe is working on icons -- we are real close on this!
Depends on: 9151
Feature is complete -- redisplay problems when switching amoung edit modes is covered by bug 9151
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
verified in 5/16 build.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: