Bugzilla

Updated

•

18 years ago

Status: RESOLVED → UNCONFIRMED

Resolution: EXPIRED → ---

Comment 5

•

18 years ago

At this point, removing the 'type="cite"' attribute would break some customizations people are using; it isn't clear to me there's an advantage to taking it out. (Is the display problem in Outlook still a problem with current versions of Outlook? Outlook Express also?) Bug 212535 seems to be only about the styling issue raise here; bug 245007 is a more general RFE for including a stylesheet on sending. Maybe this bug should be focused on whether or not the attribute stays.

Status: UNCONFIRMED → NEW

Ever confirmed: true

OS: Windows 2000 → All

Hardware: PC → All

Summary: blockquote type="cite" is not proper HTML. Quotations doesn't look good in OutLook → <blockquote type="cite"> is nonstandard (quotations don't look good in OutLook)

Peter Lairo

Comment 6

•

18 years ago

This bug should focus on removing the W3C *invalid* type="cite". A friend suggested that valid alternatives could be: <blockquote class="cite"> or <blockquote id="cite"> The CSS could be stored internally in Thunderbird. BTW: This bug is not an "Enhancement", it is a standards issue, one of Mozilla's biggest claims to fame. It should at *least* be Severity: Minor. PS: I don't think the (sometimes customized) formatting that Thunderbird uses to display a message should be part of the quoted message that is sent to other (OutLook) recipients.

Comment 7

•

18 years ago

(In reply to comment #6) > This bug should focus on removing the W3C *invalid* type="cite". A friend > suggested that valid alternatives could be: > > <blockquote class="cite"> or <blockquote id="cite"> "class" is the way to go because ids should be unique. > BTW: This bug is not an "Enhancement", it is a standards issue, one of > Mozilla's biggest claims to fame. It should at *least* be Severity: Minor. I second that request. I'm working on a patch. Michael

Comment 8

•

18 years ago

Attached patch Diff replacing t=cite by class=cite throughout (obsolete) — Details — Splinter Review

Attachment #242082 - Flags: review?

Comment 9

•

18 years ago

Uh, forgot the comment. The patch changes type=cite (not standard conforming) to class=cite (standard conforming), including the necessary style changes. There are more standards issues with the HTML produced by TB/mailnews, but hey, it's a first step ;) Michael

Comment 10

•

18 years ago

You need to specify a reviewer. I'm not sure who's the obvious person to handle that; maybe ask Neil (neil@httl.net) and if he has a better idea, the review can shift.

Comment 11

•

18 years ago

Comment on attachment 242082 [details] [diff] [review] Diff replacing t=cite by class=cite throughout Didn't know whom to ask for review. Thanks to mcow for the hint.

Attachment #242082 - Flags: review? → review?(neil)

neil@parkwaycc.co.uk

Comment 12

•

18 years ago

Comment on attachment 242082 [details] [diff] [review] Diff replacing t=cite by class=cite throughout You missed at least one type="cite" (I didn't do a complete search but I know of one in html.css). I don't know who's best to ask for review in the various modules but I don't think it's me.

Attachment #242082 - Flags: review?(neil)

Comment 13

•

18 years ago

Attached patch Patch replacing "type=cite" by "class=cite" (obsolete) — Details — Splinter Review

Added a patch in layout/. Before, I had looked at mail/, mailnews/ and editor/ only. Sorry about that. find/grepped the whole tree for TB now. Does Seamonkey require something else? I'm changing the requestee per the request of the previous requestee ;) Michael

Attachment #242082 - Attachment is obsolete: true

Attachment #242175 - Flags: review?(ben.bucksch)

Assignee

Comment 14

•

18 years ago

Comment on attachment 242175 [details] [diff] [review] Patch replacing "type=cite" by "class=cite" Bad idea. Comment follow.

Attachment #242175 - Flags: review?(ben.bucksch) → review-

Assignee

Comment 15

•

18 years ago

Removing the type=cite attribute of blockquote is an *extremely* bad idea. We absolutely need it - it is the *only* way to (properly and easily) differentiate between a normal mail quota and a generic quote (from Benjamin Franklin or CNET). Yes, it's not in the HTML standard. But HTML was not made for email. But neither does HTML *disallow* new attributes. This has been in use for almost a decade (since Netscape 4 or earlier) and is very well-known. It's a quasi-standard. Yes, Outlook ignores it, although it would be *trivial* for them to apply some CSS to msgs which style it properly - a new attribute is just as easily selected in CSS as a class is. But we use it in our own mailer, e.g. for nested quotes and custom styling. I think they would break with this patch. In any case, it's far harder to analyse the msgs. Removing it will break many actual and potential applications inside and outside of mailers. I am talking about important semantical meanings. There needs to be some way to very clearly and explicitly state "this is a quote from the replied-to msg". type=cite is the only established way. cite="mid:..." is far harder to match, not as clear, and not established at all (old msgs). So, no, this bug is an extremely bad idea and should be WONTFIXed. > Mozilla hard codes the > character in plain text messages and I therefore > suggests that the blue line should be hard coded in the HTML part of the > message. That's a nonsensical argument. The > character is not hardcoded, but rather the established way to mark a quote. In fact, Mozilla does *not* display the >, but uses blockquotes and lines for plaintext msgs. The term "hardcoded" is thus inappropriate and the comparison to a "hardcoded blue line" false. Currently, Mozilla allowes the *reader* to freely style msgs, both HTML and plaintext, and that's the goal I worked towards with much of my code. I cannot stress this enough. -- That said: Why aren't you just *adding* "class=cite" to the existing type=cite? Does Outlook style it properly then? Or what's the point of that? It's no replacement at all for the semantical meaning of type=cite, because the classname can easily clash with normal content other authors write, with slightly different meaning. A class="-moz-quote" is not good as standard either. We need a standard to express "this is a quote from the previous msg". type=cite is the closest we have.

Assignee

Comment 16

•

18 years ago

FYI, I am all for standards, and that's exactly the reason why I added the cite="mid:...", although there's no current use for it. But we still need type=cite. Removing it does 10-100 times more harm than leaving it, and I think will cause a lot of harm to our msg handling, both formatting and processing (e.g. in the HTML editor - both type=cite and cite="" are kept and used for nested quotes, as far as I know).

Comment 17

•

18 years ago

(In reply to comment #16) > FYI, I am all for standards, and that's exactly the reason why I added the > cite="mid:...", although there's no current use for it. But we still need > type=cite. Removing it does 10-100 times more harm than leaving it, and I think > will cause a lot of harm to our msg handling, both formatting and processing > (e.g. in the HTML editor - both type=cite and cite="" are kept and used for > nested quotes, as far as I know). Ben, could you be more specific about the harm being done? The purpose of the bug report and patch is to replace the use of type=cite /consistently/ by the use of class=cite. So, what harm can be caused by this then? As regards to the HTML editor: The patch contains changes to editor/libeditor/html/nsHTMLDataTransfer.cpp and editor/libeditor/html/nsHTMLEditUtils.cpp to ensure the consistency I mentioned. I don't exclude the possibility that I've missed something (I specifically asked for advise on Seamonkey). But I did change stuff in editor/, layout/, mail/ and mailnews/, hopefully covering everything that is influenced by this change. grepped through the whole thing! Michael

Assignee

Comment 18

•

18 years ago

At minimum, you need to handle both type=cite and the class, because of old msgs and not updated clients. My comments about standards and semantics were equally important, though. I don't see class as a proper replacement nor see I any harm by type=cite. Frankly, I think it's an oversight in the HTML standard.

Comment 19

•

18 years ago

(In reply to comment #15) Bugzilla notified me about comment #16, not #15 which I saw just now :| > Removing the type=cite attribute of blockquote is an *extremely* bad idea. We > absolutely need it - it is the *only* way to (properly and easily) > differentiate between a normal mail quota and a generic quote (from Benjamin > Franklin or CNET). Where do those "generic quotes" come from? If you're talking about quotes in incoming mail: What would keep others from using "type=cite"? Not more than keeps them from using "class=cite". I really don't understand this argument. If we really need to distinguish quotes produced by TB/mailnews from others we can add class=mozquote or something. > Yes, it's not in the HTML standard. But HTML was not made for email. But > neither does HTML *disallow* new attributes. It doesn't validate against the DOCTYPE it specifies. That's what I call invalid. Specify a different DOCTYPE, and things are different. BTW: Comment #1 points at http://www.w3.org/TR/1998/NOTE-HTMLThreading-0105 regarding the use of HTML for e-mail. > Yes, Outlook ignores it, although it would be *trivial* for them to apply some > CSS to msgs which style it properly - a new attribute is just as easily > selected in CSS as a class is. I guess this goes to Peter. I don't care about Outlook. This bug really is about standard compliance of code produced by TB. > But we use it in our own mailer, e.g. for nested quotes and custom styling. I > think they would break with this patch. In any case, it's far harder to analyse > the msgs. Removing it will break many actual and potential applications inside > and outside of mailers. I really don't get what the difference between scanning for type=cite and class=cite is. > very clearly and explicitly state "this is a quote from the replied-to msg". > type=cite is the only established way. cite="mid:..." is far harder to match, > not as clear, and not established at all (old msgs). This is about the only thing I do understand: compatibility with old messages. That is an issue. As far as styling is concerned this is easy to fix. Do we really need to scan old messages when composing replies? > Currently, Mozilla allowes the *reader* to freely style msgs, both HTML and > plaintext, and that's the goal I worked towards with much of my code. I cannot > stress this enough. I second that. That remark goes to Peter again ;) > It's no replacement at all for the semantical meaning of type=cite, because the > classname can easily clash with normal content other authors write, with Nothing keeps them from writing type=cite in their code. > slightly different meaning. A class="-moz-quote" is not good as standard > either. We need a standard to express "this is a quote from the previous msg". > type=cite is the closest we have. cite=mid:* is what the standard says. Michael

Comment 20

•

18 years ago

Where in a comment race here ;) (In reply to comment #18) > At minimum, you need to handle both type=cite and the class, because of old > msgs and not updated clients. > My comments about standards and semantics were equally important, though. I > don't see class as a proper replacement nor see I any harm by type=cite. Sorry, could you explain: What's the functional/semantic difference between class= and type=?

Comment 21

•

18 years ago

(In reply to comment #20) > What's the functional/semantic difference between class= and type=? 'class' is designed for purposes of presentation, 'type' is a content indicator. It's like the semantic difference between <b> vs. <strong>. (In reply to comment #19) > This is about the only thing I do understand: compatibility with old messages. > That is an issue. As far as styling is concerned this is easy to fix. Do we > really need to scan old messages when composing replies? Not just compatibility with old messages; we'd like to keep new messages compatible with older readers as well. As for styling, using selectors such as blockquote[type] (CSS2) or blockquote[cite^="mid:"] (CSS3) could be used, but the styling will only work in clients that support those levels of CSS. xref bug 45268. (In reply to comment #16) > FYI, I am all for standards, and that's exactly the reason why I added the > cite="mid:...", although there's no current use for it. Perhaps no current use because it's been broken for over four years. (bug 278663). I wonder what led to it finally getting fixed, just last week.

Comment 22

•

18 years ago

(In reply to comment #21) > (In reply to comment #20) > > What's the functional/semantic difference between class= and type=? > > 'class' is designed for purposes of presentation, 'type' is a content > indicator. It's like the semantic difference between <b> vs. <strong>. OK. Unfortunately, there is no type attribute for blockquote. So the question is whether to violate the standard regarding type or mismatch the design purpose of class. > (In reply to comment #19) > > This is about the only thing I do understand: compatibility with old messages. > > That is an issue. As far as styling is concerned this is easy to fix. Do we > > really need to scan old messages when composing replies? > > Not just compatibility with old messages; we'd like to keep new messages > compatible with older readers as well. Hmmm. I don't think composer should generate invalid HTML just please old browsers, do you? The same reasoning applies here. The worst thing that can happen is that old clients don't recognize the blockquotes as cites, but they are still blockquotes. > As for styling, using selectors such as > blockquote[type] (CSS2) or blockquote[cite^="mid:"] (CSS3) > could be used, but the styling will only work in clients that support those > levels of CSS. The only client which sees our styling is our client: They get applied on the client, they don't get sent out. I'm kind of wondering why we didn't have that discussion before, when the bug was filed. Given the current state of discussion I wouldn't have bothered coming up with a patch - I don't use HTML mail myself! Michael

Assignee

Comment 23

•

18 years ago

> OK. Unfortunately, there is no type attribute for blockquote. So the question > is whether to violate the standard regarding type or mismatch the design > purpose of class. Right. And that decision has already been made, long, long ago. And a huge precedent is a very good argument, even if class was a better solution. You don't change things that affect a billion mails lightly. And, you'd missing something important here: It's *not* a violation of the standard, and it's *not* illegal. HTML is intentionally made to allow for new attributes, esp. in the beginning of its life, and this attribute even comes from that time. > It doesn't validate against the DOCTYPE it specifies. That's what I call > invalid. Well, why do we have a doctype? We didn't use to. BTW: Since we do, we also output very invalid HTML in adding a <meta> tag for charset in the middle of the body. That's what *I* call "invalid HTML", direct *violation* of the standard: head elements in body, completely nonsensical stuff, not just undefined or quasi-defined attributes or tags. If you must keep the DOCTYPE, use one that allows or defines type=cite. (Also consider quoting other people's HTML, which might not follow your doctype.) > cite=mid:* is what the standard says. I know, that's why I added it. I think we're going in circles. > I'm kind of wondering why we didn't have that discussion before, > when the bug was filed. Because there are a few hundred thousand bugs, and developers can't read all. Note that no developer commented on it, and in fact it was closed as dormant. > Given the current state of discussion I wouldn't have bothered > coming up with a patch Sorry for your wasted effort, but I think it's really best to let this bug just die and WONTFIX it. Compare bug 212535, although I don't endorse it.

Comment 24

•

18 years ago

(In reply to comment #23) ... > And, you'd missing something important here: It's *not* a violation of the > standard, and it's *not* illegal. HTML is intentionally made to allow for new > attributes, esp. in the beginning of its life, and this attribute even comes > from that time. If it doesn't validate it's invalid (for the specified DOCTYPE). How else would one define "invalid"? Note though that I've made no claims about "legality" ;) > > It doesn't validate against the DOCTYPE it specifies. That's what I call > > invalid. > > Well, why do we have a doctype? We didn't use to. BTW: Since we do, we also > output very invalid HTML in adding a <meta> tag for charset in the middle of > the body. That's what *I* call "invalid HTML", direct *violation* of the > standard: head elements in body, completely nonsensical stuff, not just > undefined or quasi-defined attributes or tags. If you must keep the DOCTYPE, > use one that allows or defines type=cite. (Also consider quoting other people's > HTML, which might not follow your doctype.) Yes, there are more violations of the DTD specified in the DOCTYPE: The ones you mentioned; missing title element in head; invalid attributes on pre (should use styles). My suggested patch here is only a first step. I don't know either why we have a DOCTYPE declaration if we don't follow it. In fact, if things stay the way they are I would vote for (WONTFIXing this bug and) removing the DOCTYPE. What do you think? I don't think coming up with a Mozilla HTML mail dtd is worth the effort (one reason being the issue with quotes from other clients that you mention). > die and WONTFIX it. Compare bug 212535, although I don't endorse it. style in head, not inline, yes. That goes along well with the W3C notes on HTML mail and also with the user style sheet conceot for web pages - suggest style but allow to override. Michael

Assignee

Comment 25

•

18 years ago

> How else would one define "invalid"? (Violating the HTML spec. Not including doctype/dtd, allowing new tags and attributes. But my personal definition is irrelevant now. :-) ) > removing the DOCTYPE. What do you think? I think we should do that, because we are routinely quoting other author's HTML, and that may not comply to whatever doctype we choose. So, we'd either be invalid as well or would have to alter some other author's HTML, which is always tricky and road to flamewars (we didn't include A, which was semantically important, or we replaced B with C, and the replacement was not proper/fitting, etc.). I don't see a solution and so I don't think it's a good idea *in general* to include the doctype.

Comment 26

•

18 years ago

(In reply to comment #15) > Yes, it's not in the HTML standard. But HTML was not made for email. But > neither does HTML *disallow* new attributes. Where on earth did you get that from? If the attribute isn't defined in the html DTD it's invalid. It *is* disallowed! Please don't wontfix this. I don't see why we nee type="cite" if we - stop generating the type="cite" - keep the blockquote[type=cite] css display rules for backward compat - add display rules with blockquote[cite^="mid:"] to catch new msgs You say you want it to distinguish between mail quotes and "normal" quotes. What about the case when you have a mail quote in a normal html page?

Assignee: ducarroz → nobody

QA Contact: esther → composition

Comment 27

•

18 years ago

And since no other mailer uses it (to my knowledge, I may be wrong here), I really doubt we would break a lot by removing it. I don't really see a reason to add a CSS class for it either since we have rules that can match mail quotes without it.

Assignee

Comment 28

•

18 years ago

As I said, at the mininum, we'll "break" (the formatting of) our own, older clients when they read the msgs from new clients.

Comment 29

•

18 years ago

It's a bit unfortunate bug 278663 was open for such a long time, so we might want to skip the colon in the "mid:" CSS rule. If we do that, we wouldn't even break old clients. I haven't checked but if we - stop generating the type="cite" - remove the blockquote[type=cite] CSS display rules - replace these CSS rules with blockquote[cite^="mid"] as appropriate we would still be compatible with everyone (except the 1% who have customized things with their own CSS rules, but I don't think that's something to worry about). Ben, does that sound alright, or what do you think?

Comment 30

•

18 years ago

(In reply to comment #29) > It's a bit unfortunate bug 278663 was open for such a long time, so we might want to skip the colon in the "mid:" CSS rule. > If we do that, we wouldn't even break old clients. Wouldn't that mean older clients need new CSS rules (for displaying mail from new clients)? But it isn't me who cares so much about older clients. > - stop generating the type="cite" You mean: no type=cite, no class=cite, only cite=mid:...? > - remove the blockquote[type=cite] CSS display rules We might even keep those to support clients which specify type=cite without cite=mid:... - if there are any ;) > Ben, does that sound alright, or what do you think? If everyone's OK with that I volunteer coming up with a new patch ;) Michael

Comment 31

•

18 years ago

(In reply to comment #30) > (In reply to comment #29) > > It's a bit unfortunate bug 278663 was open for such a long time, so we might > want to skip the colon in the "mid:" CSS rule. > > > If we do that, we wouldn't even break old clients. > > Wouldn't that mean older clients need new CSS rules (for displaying mail from > new clients)? But it isn't me who cares so much about older clients. Yes, sorry, I was thinking about archived mail read in the "new" client. > > - stop generating the type="cite" > > You mean: no type=cite, no class=cite, only cite=mid:...? Yes. I don't see a value in using a class attribute.

Comment 32

•

18 years ago

Scratch my comment #29, I'd say comment #26 is the way to go - but I'm not a reviewer. Maybe we could add the blockquote[cite^="mid:"] rules for thunderbird 2, and finally remove the type=cite generation for 3... ?

Assignee

Comment 33

•

18 years ago

> Ben, does that sound alright, or what do you think? As I think, I believe it's absolutely critical to *semantically* recognize quotes from the previous mail easily. class doesn't count, and although <blockquote cite="mid:..."> theoretically does, it is very hard to match. It's more costly in CSS, and it may be impossible in other software. IMHO, these quotes should be a first class tag. A special attribute on blockquote makes some sense, but if you need to say "if element blockquote, with attribute cite, with content starting with ...", then you lose all expressiveness. And, BTW, nothing garantees that the URL scheme will actually be mid: for mail quotes. It's just what makes most sense for us. It's thinkable that it changes, and we'll have a compat problem again. There needs to be a way to easily, clearly, directly express "this is a quote from the person I reply to". (In fact, it makes sense for blogs, too.) *This*, and not the implementation details, are the core of my objection. And, as discussed before, the DOCTYPE - which seem to be the motivation here - needs to go anyways. So why remove it? It has not done any harm at all in 10 years, and done a lot of good (I depended on in our various converters). Just for the record, the patch is very far from being ready, too, from a short look on it: - comment 28 is still true - *If* you use a class, you should use -moz-cite. - html_sanitizer.allowed_tags and anything else *reading* messages needs to keep accepting type=cite for old mailers and old msgs in storage. - you should probably match on the class (if you use it), cite=mid: and type=cite. still that will break when we change the URL scheme in the future for any reason - you missed nsPlainTextSerializer.cpp. It produces the plaintext mail we emit from the HTML editor and needs to special-case quotes. Not only ours, BTW, but nexted quotes, too, so you have the compat problem again (both ways). - If you missed the above class, I am seriously concerned what else is missing. This is a very deep change, we use the information about quotes in a lot of places for important, but sometimes subtle things. Also, a global find/replace won't help, because you sometimes need to accept both variants, and sometimes consider old clients receiving mail from new clients. So, this change is very likely to create hard-to-find regressions. And, as I said, that's only the implementation part, not the information loss.

Comment 34

•

18 years ago

(In reply to comment #33) ... > Just for the record, the patch is very far from being ready, too, from a short > look on it: ... > - you missed nsPlainTextSerializer.cpp. It produces the plaintext mail we emit > from the HTML editor and needs to special-case quotes. Not only ours, BTW, but > nexted quotes, too, so you have the compat problem again (both ways). > - If you missed the above class, I am seriously concerned what else is missing. My understanding of reviewing is that I ask others for review who have insight in parts of the code (or overall concept of the code) which I don't have. Sentences like that last one are really neither helpful nor encouraging, to put it mildly. The logical consequence is leaving the code base to the "developpers" and focussing on extension developpment. Michael

Comment 35

•

18 years ago

Comment on attachment 242175 [details] [diff] [review] Patch replacing "type=cite" by "class=cite" Patch obsoleted by the discussion, pulled back - I'm not going to maintain it.

Attachment #242175 - Attachment is obsolete: true

Assignee

Comment 36

•

18 years ago

Sorry, I didn't want to insult you, but very, very careful testing is needed here, and you can't rely on the community (see "mid:") nor on the reviewer. I don't think *anybody* has full overview over all the places where the attribute is used.

Comment 37

•

18 years ago

(In reply to comment #33) > As I think, I believe it's absolutely critical to *semantically* recognize > quotes from the previous mail easily. class doesn't count, and although > <blockquote cite="mid:..."> theoretically does, it is very hard to match. It's May I ask why you absolutely need to recognize it in the first place (other than internally)? I'd imagine a system needing this info this would easily cope with cite^="mid:" too. The CSS cost should be very limited, you'll usually have one or two blockquote elements to check and I don't see why anyone in the foreseeable future would change the "mid:"-scheme, it's not much used as is. And if they did, that's for then:)

Assignee

Comment 38

•

18 years ago

> May I ask why you absolutely need to recognize it in the first place In a similar sense of "absolutely" as <h1> is needed. > this would easily cope with cite^="mid:" too. But it's not only mid: , just for us, and just *currently*. I think I argued all that enough above.

Comment 39

•

18 years ago

(In reply to comment #38) > But it's not only mid: , just for us, and just *currently*. type="cite" is only us too, hopefully just currently. How about using class="mailquote", and calling it a microformat then? (Using anything "-moz" would just defete the purpose of making it more widely used.) Or what kind of patch would you be willing to review?

Assignee

Comment 40

•

18 years ago

A class has been discussed above. I think this bug is a very bad idea and should be WONTFIXed. I think it does harm.

Assignee

Comment 41

•

18 years ago

Removing "(quotations don't look good in OutLook)" from summary, because that's what bug 212535 is about. I think that bug is a better idea (although I'd still prefer Outlook to support typep=cite).

Summary: <blockquote type="cite"> is nonstandard (quotations don't look good in OutLook) → <blockquote type="cite"> is nonstandard

Comment 42

•

18 years ago

(In reply to comment #41) > I think that [bug 212535] is a better idea What about bug 45268, which (if I understand it correctly) proposes putting the class in *along* with the 'type' attribute.

Nobody; OK to take it and work on it

Assignee

Comment 43

•

18 years ago

<blockquote type="cite" cite="mid:..." class="mailquote"> or, as that bug 45268 proposed, <blockquote type="cite" cite="mid:..." class="mailquote,moz-plaintext"> or similar is fine with me.

Updated

•

16 years ago

Product: Core → MailNews Core

Viktor Kabelac

Comment 45

•

13 years ago

(In reply to comment #40) > A class has been discussed above. I think this bug is a very bad idea and > should be WONTFIXed. I think it does harm. Are you straight ignoring the fact that mails using type="cite" for quoting are plain unreadable in other mail clients? Do you think Thunderbird and its users exist in a separate reality where only its ways matter? I'd imagine that an alternative mail client would wish to do things right while producing code that other clients show in the best way possible (as a courtesy to its own users, because it's them the recipients wil come back to saying "your mails are ****"). I'll gladly be corrected is I am wrong that TB is just ignoring the real world on this matter since 2002 when this first got reported, no one understood that markup - which didn't change until today. Still it's TB users whose mails "are ****" to others.

Paddy Landau

Comment 46

•

12 years ago

This really should be changed. The part 'type="cite"' is, indeed, non-standard and should never have been put there in the first place. It has no meaning outside Thunderbird, and trying to customise it with styles I find that there are some restrictions.

Wayne Mery (:wsmwk)

Updated

•

12 years ago

Blocks: 691998

Assignee

Updated

•

12 years ago

No longer blocks: 691998

jake

Comment 47

•

5 years ago

Not much has changed in 17 years, but the observant amongst you will have noted that other email clients are now also using <blockquote type="cite">. Notably, iOS (or whatever puts “Sent from my iPad/iPhone” at the end of every message) has been for a while now. There are probably others too.

GMail doesn’t, however; it uses class="gmail_quote" (useless to anyone else); but it does apply some inline styles to present the quote visually in much the same way (support for CSS in <style> elements, in many email clients, particularly web-app-based, is still poor here in 2019).

Many of the arguments for changing this have now evaporated

[13 years ago]

And since no other mailer uses it (to my knowledge, I may be wrong here), I really doubt we would break a lot by removing it.

type="cite" is only us too, hopefully just currently.

A bit of hope has gone a long way!

[8 years ago]

Are you straight ignoring the fact that mails using type="cite" for quoting are plain unreadable in other mail clients? Do you think Thunderbird and its users exist in a separate reality where only its ways matter?

Simply removing type="cite" or replacing it with a class wouldn’t have improved the readability in other mail clients anyway.

Can we now close this as ‘WONTFIX’?

Perhaps not quite.

The original W3C standards were defined based upon what was common practice. There is therefore an argument for proposing that the type attribute for <blockquote> be put on a standards track as it is now common practice (there should probably be a defined alternative, default value, perhaps none). Apple (and perhaps others, even Google) should have a vested interest here.

The Firefox browser (70.0.1 at present) still has CSS rules for blockquote[type="cite"] (so the required formatting is applied even for outlook.com users if they are using Firefox as their browser).

Getting this adopted as a W3C standard would solve the perennial problem:

people using Outlook complain that my replies are hard to read.

Yes, Outlook ignores it, although it would be trivial for them to apply some CSS to msgs which style it properly

So I think it should be pushed forward as a standard before this ‘bug’ can be finally closed…

‘Necro’

jake

Comment 48

•

5 years ago

PS. type="cite" might also be useful semantically more generally, not just for email, but, e.g., for bulletin-boards and other more modern social media to indicate that the source of the quote is within the very same thread...

Sven

Comment 49

•

2 years ago

I am using Thunderbird together with Microsoft's cloud email server in a corporate environment (Outlook etc.). It just came to my attention, that other people can hardly understand my replies if I don't do TOFU or mark my replies with colors etc.

I am shocked to see that I stumbled across a 20 years old bug. I could now curse about M$ and how they handle the blockquote tag. But the bottom line is that Thunderbird is sending emails that major systems from the corporate world don't display my emails correctly. I should add that gmail is also not displaying their usual grey bar on the left side when displaying replies written with Thunderbird. So now it's actually two major players.

From a user's perspective, the discussion about standards is somewhat academic. Users just want their emails to be readable by others. How can we get there?

Reading the discussion here, I'm beginning to feel like the standard is flawed to some degree.

Making CSS rules for blockquote type=cite to be some sort of standard may help. But it's only a longterm solution, and it's coming way too late.

So what now? How can we get to the point where replies written with Thunderbird are readable to others?

jake

Comment 50

•

2 years ago

Many email clients including Gmail and Apple used <blockquote type="cite"> to quote replies and also style such in displayed messages similar to how Thunderbird does. Apple maybe still does, but Google has dropped the type="cite" attribute (which I have never found documented anywhere) in favour of explicit inline styles.

Google still uses blockquote but explicitly styles it class="gmail_quote" style="margin:0 0 0 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" and no longer includes type="cite".

Thunderbird should do something similar.

The latest email I received from someone's iPhone has the same issue as Thunderbird. Their X-Mailer is iPhone Mail (19F77) - I don't know if that's up-to-date.

I am shocked to see that I stumbled across a 20 years old bug.

At the time of reporting, is was surely an 'undocumented feature' used by everyone apart from Microsoft. Which is ironic, because it's usually the other way round. But, only recently is this being sorted out.

But the bottom line is that Thunderbird is sending emails that major systems from the corporate world don't display my emails correctly.

AppleMail/iPhone/iPad is also sending emails that major systems from the corporate world don't display correctly, though that doesn't excuse it.

Making CSS rules for blockquote type=cite to be some sort of standard may help. But it's only a longterm solution, and it's coming way too late.

AFAIK, the type attribute was never a standard in the first place. Default user-agent CSS rules are only ever a recommendation rather than standard. Usually for blockquote it is just indented, though Firefox (and Thunderbird) put the blue bar on the left if type=cite is also present, and IMO this would be a better default for blockquote generally.

How can we get to the point where replies written with Thunderbird are readable to others?

As a workaround, you can put some CSS in your signature (make sure you have HTML signature enabled):

<style type='text/css'>
blockquote[type='cite'],
blockquote {
  margin: 1em 0 1em 0.5em;
  padding: 0 0 0 0.5em;
  border: 0;
  border-left: 2px solid #f70;
}
</style>