Open Bug 183219 Opened 22 years ago Updated 2 years ago

<blockquote type="cite"> is nonstandard

Categories

(MailNews Core :: Composition, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: roger.perttu, Assigned: BenB)

References

Details

Attachments

(2 obsolete files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2) Gecko/20021126 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2) Gecko/20021126 The use of type="cite" makes quoted text look good in Mozilla. However people using Outlook complain that my replies are hard to read. Outlook doesn't show the blue line which is no wonder because the attribute type of blockquote is (AFIK) not part of HTML. 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. This might be possible using a style (left border 2px) on blockquote or a span tag. Reproducible: Always Steps to Reproduce: 1. 2. 3.
See http://www.w3.org/TR/1998/NOTE-HTMLThreading-0105 , section 4.3 and appendix A. Since we don't specify a stylesheet or style-tags (that's what your bug is about), it's up to the client to display the HTML as it wants. Otherwise we would force Mozilla's style for Outlook users.
I propose that we atleast suggest Mozilla's style for Outlook users. I quote from section 4.3: "When quoting a message, the original message is typically wrapped in a BLOCKQUOTE block, with a CITE attribute to reference the source message, and a CLASS attribute for default presentation for the quote." That class for default presentation (which the UA can override) would be Mozillas "left border bar" I also note that the W3C note doesn't mention the use of type="cite" (neither do HTML 4.0) so why use it? Also the cite attribute seems to get lost for inner blockquotes. Don't know if this is important but the W3C note seems to suggest that they should be kept. How should a client know if it's a ordinary quote or a mail-reply quote if the cite hint is lost (without type="cite" hint cheating!)? When I write HTML files I want the person who views that file to see something similar to what I see, the same goes for HTML mail that I compose. I like Mozilla and the way messages look so I want the receiver to see the same thing (or override it if he likes to).
Product: MailNews → Core
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
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)
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.
(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
Attached patch Diff replacing t=cite by class=cite throughout (obsolete) (deleted) — Splinter Review
Attachment #242082 - Flags: review?
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
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 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)
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)
Attached patch Patch replacing "type=cite" by "class=cite" (obsolete) (deleted) — 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)
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-
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.
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).
(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
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.
(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
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=?
(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.
(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
> 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.
(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
> 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.
(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
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.
As I said, at the mininum, we'll "break" (the formatting of) our own, older clients when they read the msgs from new clients.
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?
(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
(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.
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... ?
> 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.
(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 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
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.
(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:)
> 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.
(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?
A class has been discussed above. I think this bug is a very bad idea and should be WONTFIXed. I think it does harm.
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
(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.
<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.
Product: Core → MailNews Core
(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.
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.
Blocks: 691998
No longer blocks: 691998

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’

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...

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?

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>
Assignee: nobody → ben.bucksch
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: