Closed
Bug 14783
Opened 25 years ago
Closed 25 years ago
Make normally empty inline elements (e.g. named anchor) visible in editor
Categories
(Core :: DOM: Editor, defect, P3)
Tracking
()
CLOSED
FIXED
M12
People
(Reporter: cmanske, Assigned: cmanske)
References
Details
Since we may solve this without "inline-block" CSS, I opened a new bug concerning the primary issue. --- Additional Comments From py8ieh=bugzilla@bath.ac.uk 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.)
Assignee | ||
Updated•25 years ago
|
Assignee: buster → cmanske
Depends on: inline-block, 14611
Assignee | ||
Comment 1•25 years ago
|
||
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
charley, could you provide a better description for this bug? It's pretty cryptic right now.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M12
Assignee | ||
Comment 3•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 4•25 years ago
|
||
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).
Updated•25 years ago
|
Summary: Make normally "display: hidden" inline elements (e.g. named anchor) visible in editor → Make normally empty inline elements (e.g. named anchor) visible in editor
Comment 5•25 years ago
|
||
> 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...
Assignee | ||
Comment 6•25 years ago
|
||
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•25 years ago
|
||
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...)
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 8•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Status: RESOLVED → CLOSED
Assignee | ||
Comment 10•25 years ago
|
||
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.
Assignee | ||
Comment 11•24 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•