14783 - Make normally empty inline elements (e.g. named anchor) visible in editor

Status: CLOSED FIXED

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

Description

[Charles Manske]

Since we may solve this without "inline-block" CSS, I opened a new bug
concerning the primary issue.

--- Additional Comments From py8ieh=[e-mail]  09/23/99 15:31 --
Having reread the comments above, I don't really see how inline-block _will_
help, actually. I think David's use of generated content is probably best; why
can we not select generated content?

Alternatively, use this:
   a[name] { padding-left: 20px; background: url(...gif) 5px 50% no-repeat; }
There are some issues with 'background-position' on inline elements, though.
(I will split them off into another bug.)

Comment 1

[Charles Manske]

I tried generated content, but we aren't supposed to be able to select that,
and we must be able to click on the image representing the named anchor so
it's properties can be edited. I think selecting generated content works now,
but it's not supposed to.
I tried the 2nd suggestion and you may be on to something! I can see the
problem with the position, the 20px padding is just to compensate for that,
correct? It is currently not selectable, but that might be because of selection
bug 14611

Comment 2

[buster]

charley, could you provide a better description for this bug?  It's pretty
cryptic right now.

Comment 3

[Charles Manske]

Steve:I didn't mean for it to even be seen by you -- you just collided with me!
I'd love to copy some of the comments from that bug, but our crappy
software won't let me :-(

Adding the interested parties from this bugs former life as bug 9458.

Comment 4

[Charles Manske]

I appreciate all the help on this bug, so here's how to experiment some more:
1. Put the suggested CSS in mozilla/editor/ui/composer/content/EditorContent.css
(replace the current "a[name]" item).
2. Do "makefile -f -install" in the mozilla/editor directory to install this.
3. Launch the editor from apprunner's Task menu or using "-edit" on command
line.
4. The test page has a sentence "A Named Anchor is just before this sentence"
The image for the named anchor should be just to the left of this and should
be inline. The image is temporarily the same as the "left align" icon (just a
few horizontal blue lines).

Comment 5

[Hixie (not reading bugmail)]

> I can see the problem with the position, the 20px padding is just to
> compensate for that, correct?

Yes- otherwise you end up with the picture behind the text. Basically, you want
the left padding to be equal to the width of the image, and the height of the
image to be roughly equal to the font size (or smaller).


> It is currently not selectable, but that might be because of selection
> bug 14611

Well, it is only the background, so clicking on it will just send an onclick to
the inline element in question. This will be a problem, in fact. Clicking on
the padding of an inline element, which is what you are doing when you click on
the picture, should have the same effect as clicking once in the middle of
text -- would that select the text?

Why is generated content supposed to be unselectable??? It really would make
life a lot easier here...

Comment 6

[Charles Manske]

Generated content should be not selectable because of its use in things like
autocompletion in the URL bar. There may be other reasons that Mike Judge
will explain.
Mike: Is there a way to make an exception to that rule for special purposes
like this?

Comment 7

[Hixie (not reading bugmail)]

I'd love to know why we don't want to be able to select the autocompletion
text, but anyway...

I would highly recommend asking Peter Linss about bug 12520, it may be a really
good way of solving all your problems. Basically, there are some proposed CSS3
UI properties that control what is selectable. This would be a great way of
getting around the "selecting generated content" problem.

We will need to be able to enable/disable selection on a per-frame basis
anyway, for the SELECT controls. If the CSS3 suggestion is implemented, then
this problem would almost solve itself...

(And yes, I _know_ that this is only a proposed property, not a standard, and
all that. Peter has told me that any CSS 'extensions' (like opacity,
-moz-border-radius, and the CSS3 UI stuff) will be removed when there are more
standard ways of doing them. And it would be better to implement a draft spec
idea than make something up...)

Comment 8

[Charles Manske]

I think we have settled on using the generated-content image to represent
hidden tags such as named anchor. The related problem of being able to select
that image to select the hidden tag will be worked on by mjudge (bug 16515).
If bug 16515 can't be fixed, then we should reopen this bug.
I've also changed the dependency to bug 9458, implementing CSS3 "inline-block",
which may be an alternate method of displaying a hidden tag.

Comment 9

[sujay]

I'll need help verifying this one...Anyone?

Comment 10

[Charles Manske]

If you can see the icon in front of a named anchor, and it disappears when
you click on the "Browser" mode tab on the bottom of the edit window, then
it works.

Comment 11

[Charles Manske]

Note that the selection of the generated content icon representing a named
anchor or other tag (we currently show one for <div> and <span>) is handled by
bug 35044