Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 88036 - Make AllTags mode in Composer use generated content instead of background icons
: Make AllTags mode in Composer use generated content instead of background icons
Product: Core
Classification: Components
Component: Editor (show other bugs)
: Trunk
: All All
: P3 normal with 4 votes (vote)
: ---
Assigned To: Daniel Glazman (:glazou)
: Jet Villegas (:jet)
: 48535 58634 76203 82459 82466 82469 99609 144343 (view as bug list)
Depends on: 92921 82993 87999 90649
Blocks: 91084 99225
  Show dependency treegraph
Reported: 2001-06-27 08:57 PDT by Daniel Glazman (:glazou)
Modified: 2010-02-02 20:09 PST (History)
20 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

patch v1.0 (35.17 KB, patch)
2001-06-28 05:41 PDT, Daniel Glazman (:glazou)
no flags Details | Diff | Splinter Review
stress test with all HTML elements (5.52 KB, text/html)
2001-06-29 00:28 PDT, Daniel Glazman (:glazou)
no flags Details
patch v1.1 (41.77 KB, patch)
2001-06-29 06:34 PDT, Daniel Glazman (:glazou)
no flags Details | Diff | Splinter Review
patch v1.2 (53.77 KB, patch)
2001-07-18 06:08 PDT, Daniel Glazman (:glazou)
no flags Details | Diff | Splinter Review
ZIP with new set of images for some tags (2.13 KB, application/octet-stream)
2001-07-18 06:09 PDT, Daniel Glazman (:glazou)
no flags Details
patch v1.3 (58.17 KB, patch)
2001-08-06 06:48 PDT, Daniel Glazman (:glazou)
no flags Details | Diff | Splinter Review
patch v1.3.1 (53.33 KB, patch)
2001-08-07 05:42 PDT, Daniel Glazman (:glazou)
no flags Details | Diff | Splinter Review
patch v1.4 in answer to kin's comments (58.55 KB, patch)
2001-08-17 09:22 PDT, Daniel Glazman (:glazou)
no flags Details | Diff | Splinter Review
HTML stress test case (w/o IFRAME element) (5.41 KB, text/html)
2001-09-20 04:56 PDT, Daniel Glazman (:glazou)
no flags Details
patch v1.5 (59.73 KB, patch)
2001-09-20 05:07 PDT, Daniel Glazman (:glazou)
no flags Details | Diff | Splinter Review
patch v1.6 .... (56.33 KB, patch)
2001-09-21 07:27 PDT, Daniel Glazman (:glazou)
no flags Details | Diff | Splinter Review
patch v1.7 (Same as v1.6 but synced to the 09/28/01 trunk to avoid cvs update licensing conflicts) (56.35 KB, patch)
2001-09-28 09:49 PDT, kinmoz
no flags Details | Diff | Splinter Review

Description Daniel Glazman (:glazou) 2001-06-27 08:57:00 PDT
This bug is about getting rid of the background images currently used in the
AllTags mode of Composer and using instead generated content associated to a
:before pseudo-element.

Fixing this bug will the following bugs :

   48535 Not all of the icons appear in Show All Tags mode
   58634 Show all tags mode doesn't show closed out container images
   76203 hrule icon doesn't show up in Show All Tags mode
   82459 Head elements do not render in Show All Tags Mode
   82466 Inapproriate DIV element in TEXTAREA - Show All Tags mode
   82469 Inappropriate INPUT element in ISINDEX - Show All Tags mode

As per Beth's request, will mark 0.9.3.

Cc:ing CSS folks since I am going to make an extensive use of :before
pseudo-element and perhaps detect bugs.
Comment 1 rubydoo123 2001-06-27 09:00:19 PDT
getting this in to 9.3 will resolve numerous issues -- and will be a very big
win for the user.

reviewed and approved
Comment 2 Daniel Glazman (:glazou) 2001-06-27 09:00:50 PDT
*** Bug 48535 has been marked as a duplicate of this bug. ***
Comment 3 Daniel Glazman (:glazou) 2001-06-27 09:01:39 PDT
*** Bug 58634 has been marked as a duplicate of this bug. ***
Comment 4 Daniel Glazman (:glazou) 2001-06-27 09:02:28 PDT
*** Bug 76203 has been marked as a duplicate of this bug. ***
Comment 5 Daniel Glazman (:glazou) 2001-06-27 09:03:21 PDT
*** Bug 82459 has been marked as a duplicate of this bug. ***
Comment 6 Daniel Glazman (:glazou) 2001-06-27 09:07:06 PDT
*** Bug 82466 has been marked as a duplicate of this bug. ***
Comment 7 Daniel Glazman (:glazou) 2001-06-27 09:08:24 PDT
*** Bug 82469 has been marked as a duplicate of this bug. ***
Comment 8 Daniel Glazman (:glazou) 2001-06-28 00:46:01 PDT
I'll probably have to temporarily leave BR on the side of the road because it is
causing very VERY strange effects in tables and when it is the last node of a
block-level element. Certainly not an easy fix and I can't find any workaround.

I also found some strange effects on HR in All Tags mode that I just cannot

Will file bugs about both.
Comment 9 Daniel Glazman (:glazou) 2001-06-28 05:41:16 PDT
Created attachment 40456 [details] [diff] [review]
patch v1.0
Comment 10 Daniel Glazman (:glazou) 2001-06-28 05:55:15 PDT
Created a first patch for AllTags mode ; it's certainly not the final thing but
at least it will allow people to play with it and send me feedback...

David Hyatt: can you please re-check the code I added to XULPopupListener and tell
me if it is better for perfs in popups than the previous one ?-) Thx.
Comment 11 Daniel Glazman (:glazou) 2001-06-29 00:28:54 PDT
Created attachment 40605 [details]
stress test with all HTML elements
Comment 12 Daniel Glazman (:glazou) 2001-06-29 02:33:29 PDT
Just a point about tags for A, DEL, INS, STRIKE, S and U and why they
are underlined or line-through... Excerpt from the css 2 spec :

  This property is not inherited, but descendant boxes of a block box should be
  formatted with the same decoration (e.g., they should all be underlined). The
  color of decorations should remain the same even if descendant elements have
  different ?color? values.

If people think it is a problem, we should reuse the background strategy for those
Comment 13 Daniel Glazman (:glazou) 2001-06-29 03:05:41 PDT
Forget to say one thing : normal HTML tags generated a yellow rounded box,
unknow user-defined tags generate a red rounded box :-)
Comment 14 Daniel Glazman (:glazou) 2001-06-29 06:34:00 PDT
missing -u option in first patch ; making it again :-(
Comment 15 Daniel Glazman (:glazou) 2001-06-29 06:34:48 PDT
Created attachment 40622 [details] [diff] [review]
patch v1.1
Comment 16 Hixie (not reading bugmail) 2001-06-29 06:53:37 PDT
I would recommend using MozTagname in the identifier names not just Tagname, so 
that we know the value is called '-moz-tagname'. Also, I don't know if I misread
the patch, but does this value expect an argument? That seems weird, 'open-quote'
doesn't, I see no reason why '-moz-tagname' should... also, having an argument
means it will be slower to parse. Just a couple of comments, take 'em or leave 'em
as you wish. :-)
Comment 17 Daniel Glazman (:glazou) 2001-06-29 06:56:47 PDT
*as you already know* Ian, yes -moz-tagname() was supposed to take (in the future)
an argument : a keyword either 'lowercase' 'uppercase' 'capitalize' or 'auto'.
Cf. the values of css text-transform property. But you convinced me there is
another nice way to do that and, well, you know, I am easier to convince than you
are ;-)
Comment 18 Daniel Glazman (:glazou) 2001-07-13 09:00:19 PDT
Ok, I now have on my HD a quite good candidate for a new AllTags mode. All bugs
listed above are solved BUT 58634 : showing close tags makes the view absolutely
unusable ; seriously it is a pain and I removed the corresponding rules.

I found a work-around for bug 90649, listed above as blocking the current one.
It does not solve 90649.

It should remove about 90 gif files (24 kbytes) from the distribution.

The only remaining problem is with Properties popup menu item for elements in
HEAD. Working on it. Works fine with all other elements.

BTW, do we want TITLE and STYLE in HEAD to be editable ?
Comment 19 Charles Manske 2001-07-13 11:47:11 PDT
Great work, Daniel! Look forward to playing with it.
I totally agree that we should not show closing tags, *unless* we want to
explore this further as a substitute for different kind of HTML source editor? 
I.e., you don't directly edit text in the tags, but still see start, end tags 
and  attributes. I seem to remember Hotdog or some other early HTML editor 
looked like that.
If we can get HEAD elements to display, that would be great, and all associated
children and attributes certainly should be editable.
We talked in the past about a different kind of tag editor that is a parallel 
window (probably in Sidebar) with a Tag tree view. Clicking on icons in that
view would select child content in the "normal" view. We should think about 
combining those ideas with the "Show all tags" mode.
Comment 20 rubydoo123 2001-07-15 19:09:44 PDT
the user should be able to access and edit all elements
Comment 21 Daniel Glazman (:glazou) 2001-07-16 09:19:02 PDT
Ok. So TITLE, STYLE and SCRIPT elements in HEAD are now editable in AllTags mode.
Added some magic if the selections spans over different head elements, or starts
in head and ends in body.
Hope to produce a patch tomorrow.
Comment 22 Daniel Glazman (:glazou) 2001-07-17 04:56:54 PDT
Issues list tuesday 17-june :

1) making TITLE, STYLE and SCRIPT (this last element can be
found in both HEAD and BODY) editable obliges to disable HTML styles insertion
in these elements.... <title><b>foo</b></title> is definitely invalid [:-)]
This issue must be solved before landing. Working on it.

2) TITLE, STYLE and SCRIPT elements in HEAD should not be drag'n'dropable.
This issue can probably wait a little bit and be solved after landing.

3) contextual popup menus on HEAD sub-elements still missing the Properties
menu item unless all the element is selected. Can't find why for the moment.
This issue can probably wait a little bit and be solved after landing.

Comment 23 Daniel Glazman (:glazou) 2001-07-17 09:10:51 PDT
Wooofff. Ok, it is now impossible to add styles into TITLE SCRIPT and STYLE
elements :-) Basically, we are not looking at the DTD when we insert an HTML
style (well, we never needed to) and I added some easy code to
nsHTMLEditorStyle for that purpose.

Now trying to paste a B into a STYLE element. Hope it does not work....
Comment 24 Daniel Glazman (:glazou) 2001-07-18 06:08:02 PDT
Created attachment 42698 [details] [diff] [review]
patch v1.2
Comment 25 Daniel Glazman (:glazou) 2001-07-18 06:09:04 PDT
Created attachment 42699 [details]
ZIP with new set of images for some tags
Comment 26 Daniel Glazman (:glazou) 2001-07-18 06:13:46 PDT
I have attached a new patch and a zip containing images. These images are for
tags that hardly support the generated content strategy for AllTags mode.
Unzip the archive in mozilla/editor/ui/composer/content/images directory.

Don't forget to apply Mike's patches from bug 82993.

Please try the patch, torture AllTags mode and send feedback as soon as possible.
Thanks !
Comment 27 Daniel Glazman (:glazou) 2001-07-24 00:47:39 PDT
-> mozilla0.9.4 ; still need feedback
Comment 28 Daniel Glazman (:glazou) 2001-07-24 06:12:58 PDT
Detected a small bug in last proposed patch : named anchors have both <A> and
'anchor' tags. Fixed.
Comment 29 Daniel Glazman (:glazou) 2001-07-31 03:00:30 PDT
Just detected small other bugs :

  a. it should not be possible to enter a line break in the contents of the
     TITLE element. Fixed.

  b. line breaks entered in STYLE and SCRIPT elements should not generated a BR
     but only a \n. Working on it. I don't know if this can be fixed given the
     fact that we use BR's presence on empty line for selection purposes...

     BTW, this last issue has an avatar : when you create a PRE and press the
     return key, it inserts a BR even if this element is not necessary to
     insert a carriage return ; leaving \n as it is in the markup is enough.
Comment 30 Pierre Saslawsky 2001-07-31 03:27:52 PDT
I noticed that you used "\a" in generated content. See bug 66585, waiting for 
Comment 31 Charles Manske 2001-07-31 13:49:53 PDT
Unfortunately, I still can't get the tagname text to appear between the "< >"
in the yellow icons. Other issues:
Is it possible to get the blue selection border around the yellow icons when you
click on one to select that tag. 
This is especially important for cases such as named anchors where there's no
content that is selected.
Comment 32 Daniel Glazman (:glazou) 2001-08-03 03:10:26 PDT
Charley : I have just re-applied my patch to a new pulled tree and it works;
are you sure that you completely applied the patch ? No code chunk rejected ?
Comment 33 Charles Manske 2001-08-03 08:48:20 PDT
There were some patch failures, but I thought I resolved them. I'm sure its 
something about my patch.
I backed out the patch in my current tree. I'm ok with your checking this in
and we can work out remaining issues (if any) then.
Comment 34 Daniel Glazman (:glazou) 2001-08-06 00:57:09 PDT
Charley : the main issue is about carriage return insertion in SCRIPT and STYLE
elements. It generates a <br> element and that is obviously a very big error.
Can you help on this issue ? I am going to attach a new version of the patch in
the coming hour.
Comment 35 Daniel Glazman (:glazou) 2001-08-06 06:48:18 PDT
Created attachment 44790 [details] [diff] [review]
patch v1.3
Comment 36 Charles Manske 2001-08-06 13:14:53 PDT
Your patch has a cvs conflict in file mozilla/layout/base/public/nsIFrame.h
I don't think it would apply that very well!

Comment 37 Daniel Glazman (:glazou) 2001-08-07 05:42:43 PDT
Created attachment 44922 [details] [diff] [review]
patch v1.3.1
Comment 38 Daniel Glazman (:glazou) 2001-08-07 05:43:30 PDT
hum. Sorry for that. New version attached.
Comment 39 Daniel Glazman (:glazou) 2001-08-08 01:04:01 PDT
sr= needed please
Comment 40 Simon Fraser 2001-08-08 10:48:50 PDT
Don't I recall some issues about selection when using generated content for show 
all tags?
Comment 41 Charles Manske 2001-08-08 15:32:37 PDT
Except for the issue of showing a selection border around the tag icon, Daniel's
fix solves the other selection-related problems. Note that we also don't show a 
selection border around the icon when we use the background image instead
of using generated content.
Comment 42 Daniel Glazman (:glazou) 2001-08-10 05:28:09 PDT
Let give back to Caesar what belongs to Caesar : mjudge fixed the selection
problems with generated content.

Simon, can you sr= please ?
Comment 43 kinmoz 2001-08-14 12:43:40 PDT
Comments so far on the 08/07/01 05:42 Patch:

* I'm seeing code in a couple of places in the patch that
  checks to see if a frame is generated content. If so, it
  adjusts various function variables so that it uses the
  generated content's parent. If the idea is to return a
  parent that is actually in the document, shouldn't we
  be traversing the parent hierarchy, just in case the
  parent is also generated?

  - Also regarding these generated content changes,
    can we add a comment saying how exactly we can
    repro the crash we are trying to avoid? I mean
    I tried to repro the crash with some :before/:after
    content in the body, but had no luck crashing.

* I'm a little concerned about changing the semantics of

    - It is used by BeforeEdit() and AfterEditInner()
      both of which assume the selection is in the body,
      and do some extra editing like merging text nodes,
      deleting extraneous nodes, adding BRs, and whitespace
      adjustment. Leaving the selection in the head and
      allowing this pre/post processing to happen could
      lead to some wierd results. Or are you sure none
      of that code affects stuff in the head?

    - If for some reason we got into the case where
      Start was in HEAD and End was in Body, we collapse
      into the head. Is that what we expect?

    - It is assumed that if isInHead1 and isInHead2 and
      the tags match, that we are in the same node. Should
      we be concerned with the possibility that the selection
      could start and end in a diffeent STYLE/SCRIPT element?

* Shouldn't IsTitle(), IsScript(), and IsStyle() be in
  nsHTMLEditUtils.cpp instead of nsTextEditUtils.cpp?
Comment 44 Daniel Glazman (:glazou) 2001-08-16 02:56:05 PDT
Just tested to add the patch w/o EditorShellMouseListener nor XULPopupListener
code. No crashes. So some code has been added to the tree in the meantime.

**BUT** without these chunks of code, editor is unable to establish the link
between a generated content node and the element that generated it. So the
"Properties" item never shows up in the popup. The selection is also broken :
right-clicking on a tag does not select the element.

I suggest keeping my code in the patch...
Comment 45 Daniel Glazman (:glazou) 2001-08-17 09:22:21 PDT
Created attachment 46224 [details] [diff] [review]
patch v1.4 in answer to kin's comments
Comment 46 Daniel Glazman (:glazou) 2001-08-17 09:29:22 PDT
new patch in answer to kin

   + suppress possibility to enter a carriage return in <title>
   + fix for bug 92921 (composer should not replace line breaks by <br>
     inside a <pre>) ; we have similar bug in <style> and <script>

I suggest to treat any new other issue as a bug of the new AllTags mode and
check-in anyway.
I will be in Seattle for a meeting between 2001-08-19 and 2001-08-25 so
if this patch has to get in the tree before I come back, a checki-n buddy
is necessary.
Last point: don't forget the ZIP with images when you check-in... They also
have to be checked in. I suggest to leave the unnecessary images in the tree
for the moment, I'll remove them when I am back.
Comment 47 Daniel Glazman (:glazou) 2001-08-17 12:52:55 PDT
just one important detail : patch does not harm mailcomposer (tested and
tortured) ;-)
Comment 48 Daniel Glazman (:glazou) 2001-08-17 20:07:58 PDT
kin: please do NOT check-in patch as it is ; problem with blank lines in PRE
elements :-(
Comment 49 Daniel Glazman (:glazou) 2001-08-21 14:33:18 PDT
=> mozilla 0.9.5 :-/
Comment 50 Kevin McCluskey (gone) 2001-09-12 18:02:27 PDT
Marking nsbranch+.

Daniel, are you close to solving the problem with blank lines in PRE elements? 

Comment 51 Kathleen Brade 2001-09-14 09:58:26 PDT
*** Bug 99609 has been marked as a duplicate of this bug. ***
Comment 52 elaineking 2001-09-14 16:13:49 PDT
removed keyword nsbranch since bug now has nsbranch+, per pdt mtg.
Comment 53 Joe Francis 2001-09-16 23:18:51 PDT
Kevin, I don't think Daniel has a solution in hand for that problem.  If he does 
I will be very happy indeed.  It's a longstanding limitation in layout that there 
is no frame associated with a blank line in a block that has whitespace style of 
preformatted, unless that blank line is caused by a <br> instead of a return 
Comment 54 Daniel Glazman (:glazou) 2001-09-17 01:04:06 PDT
Kevin : no I don't ; this is a very (I mean really very) complex problem.

Joe : I wish I would !

Both : what's the point marking nsbranch+ when I am reassigned to another team ?
I need some clarification here ; am I supposed to continue working on all my
editor bugs until they are fixed or what ? Or future the bugs until we rebuild
Composer's team ? If all our bugs still have the same priority for the product,
why are we reassigned ? It is not possible, as we say in French, to have the
butter and  the money for the butter at the same time...

If PDT wants me to invest time in this bug, that's not a problem for me as
soon as it is official ; just tell me and tell my manager... Otherwise, this bug
falls into a "postponed until I have some spare time" basket.
Sorry, my days only have 24 hours.
Comment 55 Kevin McCluskey (gone) 2001-09-17 10:28:41 PDT
Marking nsbranch- for now. I was previously under the impression that there was
a patch that was almost ready to go and it fixed multiple bugs. Since that is
not the case marking nsbranch- since it is not a "stop ship" bug as far as I can
Comment 56 Daniel Glazman (:glazou) 2001-09-18 09:02:07 PDT
Seems that I just found the beginning of a track to solve the selection bugs
Kin and I found when I was in Redmond. Spending some hours on it.
Comment 57 Daniel Glazman (:glazou) 2001-09-19 01:09:13 PDT
Summary of the situation this morning :

1. there were three bugs with patch 1.4 or caused by new code in the
   trunk :

   a) it was impossible to get the Properties popup item for some
      elements. Following the track I discovered yesterday, I have fixed
      this one during the night. Only the elements in HEAD still resist.

   b) because of bug 85505, making STYLE and SCRIPT elements editable
      result in invalid documents. Fixing this bug is beyond my
      knowledge. Bug 92921 heavily depends on 85505.

   c) code added to XULPopupListener is now useless, due to bug fixing
      in other parts of the code

2. I will rebuild a new patch with the fix for (a) proposing to leave
   the HEAD elements problem as a new bug, leaving SCRIPT and STYLE
   element NOT editable with a release-note because of (b), and
   with the code mentioned in (c) removed.

With all of that, I think the patch can be reviewed again.
   elements problem as a new bug
Comment 58 Daniel Glazman (:glazou) 2001-09-20 04:55:31 PDT
Comment on attachment 40605 [details]
stress test with all HTML elements

Marking this test case obsolete : composer chokes on it due to presence of IFRAME element
Comment 59 Daniel Glazman (:glazou) 2001-09-20 04:56:20 PDT
Created attachment 50066 [details]
HTML stress test case (w/o IFRAME element)
Comment 60 Daniel Glazman (:glazou) 2001-09-20 05:07:56 PDT
Created attachment 50068 [details] [diff] [review]
patch v1.5
Comment 61 Daniel Glazman (:glazou) 2001-09-20 07:19:51 PDT
People, I just attached the patch v1.5 for this bug and I really think it can be
this time the last one. Already tested on win2k *and* RH7 *and* Mac. Works
fine for me.

hyatt: could you please r= the addition to nsXULPopupListener please ? W/o
       this code in, I still have a crasher (in opposition with what I wrote
       before) and I don't get all popups. I _really_ need this in.
brade: could you please r= ?
kin: could you please sr= please ?
beppe: we'll drink champagne about this bug next time I come !


  - unzip attachment 42699 [details] in editor/ui/composer/content/images
  - install patch v1.5 from attachment 50068 [details] [diff] [review]
  - rebuild all (on windows, be sure you have made a depend before)


1) it is not possible to edit the contents of STYLE and SCRIPT elements because
   of bug 85505 (through bug 92921) in AllTags mode ; these elements remain of
   course editable in source view ; not a problem since they were not even
   visible before in AllTags.
2) the contents of the LABEL element are not editable because of its link
   behavior when it carries a 'for' attribute ; a new bug will be filed for
   this issue. No change from existing mode.
3) the elements in head are not selectable clicking on the tag name so you can't
   get the properties for them with the mouse ; it has
   already been agreed before to treat this issue as a new bug after the
   check-in of the current patch
4) form elements must be selected by left-click to get the properties by right-
   click ; a new bug will be filed for this issue

I am preparing a CookBook for this bug so others can contribute/understand
what I did and why.

Comment 62 Daniel Glazman (:glazou) 2001-09-21 01:31:10 PDT
Adding EDITORBASE on status whiteboard
Comment 63 Daniel Glazman (:glazou) 2001-09-21 07:26:10 PDT
Comment on attachment 50068 [details] [diff] [review]
patch v1.5

patch 1.5 obsolete; thanks to kin for spotting out the blank-lines-in-pre thing
Comment 64 Daniel Glazman (:glazou) 2001-09-21 07:27:02 PDT
Created attachment 50238 [details] [diff] [review]
patch v1.6 ....
Comment 65 kinmoz 2001-09-28 09:49:06 PDT
Created attachment 51227 [details] [diff] [review]
patch v1.7 (Same as v1.6 but synced to the 09/28/01 trunk to avoid cvs update licensing conflicts)
Comment 66 Joe Francis 2001-10-01 05:56:31 PDT
The changes in nsHTMLEditorStyle.cpp to bail out of SetInlinePropertyOnNode() if 
the style cannot live in the selection parent will cause that routine to fail in 
this scenario:  selection is in a multi-level block structure (like tables or 
lists) and not at the bottom level.  Example, a whole list item is selected.  
Selection parent is thus the ol.  ol cannot contain any html inline style 
elements, so the routine will bail.  Before the patch, the routine would instead 
examine the children recursively looking for places to put the style.  It would 
find the li, and succeed (as user expects).
Comment 67 Daniel Glazman (:glazou) 2001-11-07 01:12:59 PST
bulk milestone change
Comment 68 Syd Logan 2002-01-22 18:08:49 PST
editorbase-, target end user not concerned with all tags mode in our opinion
Comment 69 Kathleen Brade 2002-01-23 06:34:30 PST
The win here isn't so much for users but our download size.  We currently have
100 images in cvs (65K of data) which take 792K on my disk (uncompressed).  I
don't know what the increase to the css file would be and I don't know the
compression size of these images.
Comment 70 rubydoo123 2002-03-08 12:08:21 PST
removing myself from the cc list
Comment 71 DStile 2002-05-24 01:24:53 PDT
*** Bug 144343 has been marked as a duplicate of this bug. ***
Comment 72 Kathleen Brade 2003-02-19 12:02:46 PST
remove milestone since it is long gone
remove editorbase- since this is a composer/app-level item and not specific to
editor core

Note You need to log in before you can comment on or make changes to this bug.