Closed Bug 216753 Opened 21 years ago Closed 21 years ago

Message compose should not automatically convert HTML attributes to CSS styles

Categories

(SeaMonkey :: Composer, defect)

x86
Windows 95
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: neil, Assigned: glazou)

Details

(Keywords: fixed1.5, regression)

Attachments

(2 files, 1 obsolete file)

Editor's CSS styles option was never meant to apply to message compose.
Unfortunately it did causing bug 116867 and possibly others. The correct fix
should be to properly disable CSS styles in message compose, rather than the fix
that was actually checked in.

Note that if you disable CSS mode with that fix having been checked in then you
can no longer send background images becuase they use the background attribute
again.
CSS in Mail/News whether in Mozilla or Thunderbird is essential to DHTML.  How
else can JS manipulation of z-indexed layers be accomplished.

Currently the HTML editor in Thunderbird is not even close to matching the
abilities of that obsolete Netscape Communicator 4.7x, despite it's depreciated
LAYER tag.

If the built in editor is not going to be fixed to do full CSS compatability
then for the sake of getting a robust tool into usres hands, give us a good
standalone.

I am getting tired of puting messages into the unsent mail box and then hacking
there CSS with Windows Notetab or other text editors to to be able to utilise
the abilites of the reader half of Mail/News.
Well someone meant it to apply at one time.
1.4 ala Netscape 7.1 allowed you to
1) insert a background (as an HTML attribute)
2) insert and edit CSS styles with the inline styles tab
3) edit previous messages without the loosing styles

I am disappointed Daniel, I was looking forward to a future
composer++ that was fully functional in Mail/News
Joe
> I am disappointed Daniel, I was looking forward to a future
> composer++ that was fully functional in Mail/News

Hey guys, editor peers work on the editor core and Composer. It's not
our responsability to integrate new features in mail composer for an
EXCELLENT reason. Email implies compatibility with other mail systems.
If we start doing very nice and sexy things that break our compatibility
with the rest of the world, that's totally COUNTER-PRODUCTIVE.
In that sense, taking myself the decision to add layers and z-index management to
email was just impossible. Besides that, some important Webmails like Hotmail
or Yahoo have IMPORTANT problems with HTML mails containing CSS-based layers.

Wytigfyisagftw:
What You Think Is Good For You Is Not Always Good For The Web.

As Compose stands right now, one can either use html or css, once it is working
properly. If you wish to please Hotmail, etc., then use html and not css. IE/OE
(A.K.A. the rest of the world) uses css in theirs, so why not in ours?

The EXCELLENT reason could be that IE/OE has far superior capability regarding
Multimedia than we have. CSS is one aspect of this.

Regarding compatibility, this is fine, but is it not possible to ALSO include
innovation as an OPTIONAL way of presentation of Mail/News? For complex
Mail/News items using innovative means would dictate that the viewer must get a
"modern/most recent" Mail/News Reader such as we offer.

Why for heaven's sake would anyone using OE with multimedia content wish to
change to our Mail/News reader!? They, and there are millions of them, want
Glitz and Pizzazz! You want Mozilla to become a contender? Well, it doesn't take
rocket science to figure out the answer - make it a kick-butt full-featured
product, or are we to be content with cinema-noir?

-- Gus Richter
> OE (A.K.A. the rest of the world) uses css in theirs, so why not in ours?
OK, so I only have access to OE5.5, but it uses <U> for underline, not <span
style="text-decoration: underline;"> (similarly for other styles).
There is a huge graphics community that uses mail/news to display their creative
efforts via Yahoo groups and others, using mail, or through Usenet or private
news servers.  We are not talking just a few scattered grandmothers, but
hundreds of thousands of users who would love to have an option to OE, but
cannot unless they use Netscape 4.xx - those of us who participate in these
communities, for that is what they are, are constantly having to apologize for
all versions of Netscape/Moz since 4.xx and have spent at least two years
assuring folks that in the final versions, it will be possible to switch, and be
able to use Mozilla as a vehicle to participate in their hobby/craft/art groups
without having to use OE with all of its inherent problems.  We need, however,
the support, understanding and involvement of the developers in order to reach
this goal.  I do not want to switch.  I want to be able to help others switch to
using Thunderbird, but at this point it is just impossible.  I don't understand
the reluctance to include this kind of ability in a product intended for end
users.  Sure, some might "misuse it" and send you email that you don't want -
but hey, that's what the junk file is for.  Please give us the ability to create
for newsgroups - this is a very important ability, even though you might have
your own reservations - don't punish the rest of us.  Reading the comments here
are very sad, and show a lack of understanding of those who want to use this
product, and have been waiting for two years to be able to use it, and are still
waiting, hoping, and testing.
      Sharon Litton
Hey, let's not get all confused. All this bug is requesting is a return to the
1.4 functionality whereby pressing the Bold button inserts a <B> etc.
Attached patch glazou's patch (obsolete) — Splinter Review
glazou emailed me (and others) this patch, and I tested it.
Comment on attachment 130183 [details] [diff] [review]
glazou's patch

Note, this only fixes the use of the background attribute, you still need to
back out the previous fix to actually send a background.
Attachment #130183 - Flags: superreview?(scott)
Attachment #130183 - Flags: review+
Neil, in response to your comment #5:
I don't know how much or what kind of mail you receive, but the nicely crafted
ones which I have seen use CSS. The method used is by referencing the stylesheet
declarations with a CID.

Regarding your comment #7:
I for one am not confused. What you are proposing is just not good enough to
compete with what IE/OE users have had for years. Make it better than OE and not
worse in capability. By going back to 1.4 it will be a regression. Make it an
Option, please.
Consider the Netscape 4.X user who has worked for years on compositions
which used layers for positioning. Step up to current standards you say
well...without being able to use absolute positioning to simulate layers not a
lot of folks will accept that.
How about a minimally acceptable compliment of CSS restricted to positioning
of images,tables, and Divs
As far as returning to 1.4 functionality, at least there I could edit and apply
CSS properties with the inline styles tab. That ability has also been lost along
the way.
Neal this is the style sheet extracted from an OE5.5 post I retrieved from
news.annexcafe.com.
Regarding Neil's comment #7
> Hey, let's not get all confused. All this bug is requesting is a return to the
> 1.4 functionality whereby pressing the Bold button inserts a <B> etc.

Perhaps I've lost my ability to read, but in Daniel's Opener, I read nothing of
the sort at all. What I read are:

"Editor's CSS styles option was never meant to apply to message compose."
and
"The correct fix should be to properly disable CSS styles in message compose,
rather than the fix that was actually checked in."

This sounds more radical than what you translate it to say.
Perhaps my Reader has filtered out some messages or portions thereof?

-- Gus
"Editor's CSS styles option was never meant to apply to message compose."
In 2001 Editor, and Message Compose, could not insert CSS styles, except via
HTML Source, Insert HTML and the Advanced button in some of the dialogs.

This feature was changed BUT ONLY FOR Editor, so that editing actions that used
to set HTML attributes would now set CSS styles as far as that was possible.

For instance, the size of an image would not be set using the attributes
width="XX" height="YY" but the CSS style="width: XX; height: YY;".

Now for some reason this started affecting Message Compose too. This meant that
Message Compose could not locate any background images, as it only looked for
<body background> and not <body style="background-image: url();">.

I consider this change to be a regression from 1.4, so I filed this bug.

"The correct fix should be to properly disable CSS styles in message compose,
rather than the fix that was actually checked in."

What I meant was, that Editor should not try to automatically convert HTML
attributes to CSS styles, so I have changed the summary accordingly.

This will restore Message Compose to 1.4 functionality. It is not intended to
remove any functions, just perform them in the original way.

If you feel that Message Compose should have the option of automatic HTML
attribute to CSS style conversion then feel free to file an enhancement request.
Summary: Message compose should use HTML attributes, not CSS styles → Message compose should not automatically convert HTML attributes to CSS styles
First of all, pardon my attributing your bug description/opener to Daniel.

Thank you for the clarification and correction. 
I am very glad to read that you do NOT propose to have CSS capability removed
from message compose, which understanding Daniel seemed to support. 

I think we misunderstood each other from the get-go. The Option I had referred
to was that IF css capability were to be removed from message compose by
default, then at least make it available as an Option and not remove this
capability completely. I am now pleased to read that the removal is/was not
proposed, hence the Option is not necessary.
Thank you for the background info on Editor and Mail Compose.  Not being
familiar with SeaMonkey I was alarmed by the OC.  Sorry for having rallyed the
troops from Netscape.Test.MultiMedia to comment on the action we perceived would
decrease the multimedia abilities of Tbird.

We have been expriencing several difficulties with Mail/News Compose pertaining
to background images for message background and table backgrounds.  Additionaly,
trying to do Message Edit as New is frustrating when the Inline CSS we know
exists in a template is not available for editing in the new version.

Since your proposed action is to eliminate a regression, then go for it.  That
means we should have a solid base level of HTML on which a strong CSS enabled
Message Composer can add the needed advanced support which multimedia depends in
this 5 or 6th generation of Mail/News products.
Comment on attachment 130183 [details] [diff] [review]
glazou's patch

Neil, I haven't had a chance to try this out yet. But can you confirm that the
patch does indeed make editor start giving us the background attribute again on
the body element after applying this patch?

We can file a separte bug on me to back out my 'fixes' for adding inline style
support.
Attachment #130183 - Flags: superreview?(scott) → superreview+
Comment on attachment 130205 [details]
OE 5.5 NTTP post stylesheet

><STYLE>
BODY %7B%0A%09
BORDER-RIGHT: #2e5776 2px ridge;
BORDER-TOP: #2e5776 2px ridge;
SCROLLBAR-FACE-COLOR: #27728f;
FONT-SIZE: 10pt;
SCROLLBAR-HIGHLIGHT-COLOR: #8eb187;
BORDER-LEFT: #2e5776 2px ridge;
SCROLLBAR-SHADOW-COLOR: #7db3dd;
COLOR: #2e5776;
SCROLLBAR-3DLIGHT-COLOR: #bcd7ec; 
SCROLLBAR-ARROW-COLOR: #8eb187;
SCROLLBAR-TRACK-COLOR: #27728f;
BORDER-BOTTOM: #2e5776 2px ridge;
FONT-FAMILY: Arial;
SCROLLBAR-DARKSHADOW-COLOR: #8eb187%;
SCROLLBAR-BASE-COLOR: #27728f%0A%7D%0A.table1 %7B%0A%09
BORDER-RIGHT: #2e5776 2px ridge; 
BORDER-TOP: #2e5776 2px ridge; 
BORDER-LEFT: #2e5776 2px ridge; 
BORDER-BOTTOM: #2e5776 2px ridge; 
BACKGROUND-COLOR: #8eb187%0A%7D%0A.table2 %7B%0A%09
BORDER-RIGHT: #2e5776%202px%20ridge; 
BORDER-TOP: #2e5776%202px%20ridge; 
BORDER-LEFT: #2e5776%202px%20ridge; 
BORDER-BOTTOM: #2e5776%202px%20ridge; 
BACKGROUND-COLOR: #8eb187%0A%7D%0A.td %7B%0A%09
BORDER-RIGHT: #2e5776 2px ridge;  
BORDER-TOP%3A%20%232e5776 2px ridge; 
BORDER-LEFT%3A%20%232e5776 2px ridge; 
BORDER-BOTTOM%3A%20%232e5776%202px%20ridge%3B%20%3D%0A
BACKGROUND-COLOR%3A%20%238eb187%0A%7D%0A.textbox%20%7B%0A%09
BORDER-RIGHT%3A%20%232e5776%204px%20double%3B%20
BORDER-TOP%3A%20%232e5776%204px%20double%3B%20%3D%0A
FILTER%3A%20alpha%28opacity%3D3D80%29%3B%20
BORDER-LEFT%3A%20%232e5776%204px%20double%3B%20%3D%0A
BORDER-BOTTOM%3A%20%232e5776%204px%20double%3B
BACKGROUND-COLOR%3A%20%238eb187%0A%7D%0A
</STYLE>
Attached patch updated patchSplinter Review
This updated patch includes Daniel's fix to make sure editor gives us the right
CSS and a backout to my fixes for 116867 and 170504.

Both of those bugs will remain fixed however as they both still work with this
new patch. Background images in templates and drafts still work correctly when
sent. As a bonus I fixed a bug where we were forgetting the dir attribute on
the message body which was causing problems for bidi users.

I'll be trying this patch out in the next round of thunderbird 0.2 candidate
builds so we can make sure it doesn't break anything.
Attachment #130183 - Attachment is obsolete: true
Flags: blocking1.5?
Attachment #130633 - Flags: review?(neil.parkwaycc.co.uk)
We should get this for 1.5. Scott, can you help us with some quick review here?
Anyone else need to review to get this in?
Flags: blocking1.5? → blocking1.5+
Patch is ok from an editor's point of view, not speaking here of mailnews/*
files.
Attachment #130633 - Flags: superreview?(bienvenu)
Attachment #130633 - Flags: review?(neil.parkwaycc.co.uk) → review+
Comment on attachment 130633 [details] [diff] [review]
updated patch

+	     PRBool hasBackground = PR_FALSE;
+	     if
(NS_SUCCEEDED(element->HasAttribute(NS_LITERAL_STRING("background"),
&hasBackground)))
+	       if (hasBackground)

nit - you can just say && hasBackground instead of adding another if. Up to
you, sr=bienvenu
Attachment #130633 - Flags: superreview?(bienvenu) → superreview+
I am using the current Thunderbird release and can confirm the combination  of
Daniels and Scott's patch returns the background to 1.4 html attribute.
Template, and Drafts work correctly now.
html styles are not automatically converted to css
However this does not return us to 1.4 functionality regarding Mail editor.
Existing styles were displayed with the inline styles tab in 1.4 and could
be edited individually.
This capability disappeared between 20030617 and 20030625
(see Mozillazine post http://forums.mozillazine.org/viewtopic.php?t=22706
Ref Neil's comment #14
What I meant was, that Editor should not try to automatically convert HTML
attributes to CSS styles, so I have changed the summary accordingly.

This will restore Message Compose to 1.4 functionality. It is not intended to
remove any functions, just perform them in the original way.

Mail Compose is not as capable as 1.4 at this point.

Should another bug be filed in ref to the inop inline styles edit function

JoeS
I've checked in the patch.

note the a=glazman for the editor change and the a=asa for 1.5 final checkin.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Keywords: fixed1.5
Product: Browser → Seamonkey
Component: Composer CSS Editor → Composer
QA Contact: daniel → composer
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: