Closed Bug 74248 Opened 24 years ago Closed 23 years ago

Capability to _underline_ words

Categories

(MailNews Core :: Composition, defect)

All
Other
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED
Future

People

(Reporter: holgermetzger, Assigned: neil)

References

Details

Attachments

(4 files, 1 obsolete file)

Add the possibility to "underline" words. Example: _blahblahblah_ would be displayed underlined.
I thought the text-to-HTML converter did that already.
Marking NEW. Invalidate it if it already does.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Add capability to "underline" words → [RFE] Add capability to "underline" words
I'd love to have this too. Ben, do you know a way to add this (I heard you poked around in that are before)?
The functionality is there. The only thing missing is the stylesheet rule. I refuse to use <u>, because that's deprecated for a good reason. I use <span class=txt_underscore>, IIRC, and wanted a stylesheet to specify underline for this class. But the tag is in the content and the converter is not limited to Mailnews. So, I don't know, to which stylesheet I should add that rule.
Severity: enhancement → minor
Component: Composition → Networking
Product: MailNews → Browser
BTW: * and / works.
Summary: [RFE] Add capability to "underline" words → Capability to "underline" words
Summary: Capability to "underline" words → Capability to _underline_ words
For yourself, you could add to your userContent.css: span.txt_underscore { text-decoration: underline } (IIRC). Of course, this works for you only then.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
why is this in networking?
because that's where the code lives.
how does the quote stuff work? I mean that grey bar on the left when there's > abcdefg > test test test > test test test
We are using a blockquote with a specific css rule.
I thought that was only in HTML mail where the non-standard <blockquote type="cite"> is used but that is off topic here I guess. As for Ben's span.txt_underscore { text-decoration: underline } I don't see any reason why we can't make use of a more obscure attribute and put the rule in html.css as blockquote[type=cite] is already found there. otoh I'm not sure why can't we use <u> ? It is depreciated but isn't that what describes this best ( as in underlined ) ?
*** Bug 111476 has been marked as a duplicate of this bug. ***
Should / will this eventually work with all these testcases: 1. _underline_ 2. _underline multiple words_ 3. _underline even if there are (brakets) here_ <-- special case? At least 1. and 2. work with *bold* What if there is a period or questionmark right after it like _this_. or _this_?
I was talking to glazou the other day, one of the CSS masters (he's working in the W3C CSS group, actually) and he said it was definitely OK to use <u> as long as it's internally. There's nothing wrong with it, and it produces the *exact* same result as the CSS equivalent. I have this implemented in my tree -- using <u>, and it works just fine. For correctness, we can spin off a new bug for the CSS/HTML case... and if anyone feels really concerned, they can fix it. Patch + screenshot coming up.
Attached patch Patch (deleted) — Splinter Review
Let's spin off a new bug for "correctness" if anyone cares, and make this feature work, just like the other ones.
Attached image Screenshot (deleted) —
PLairo's latest comment viewed using mailnews with this feature incorporated.
> he said it was definitely OK to use <u> as long as it's internally But it isn't. This is a general txt->html converter (and html->html enhancer), it is also used for during sending HTML mails (similar to URL recognition) and IIRC saving TXT mails as HTML.
The screenshot look very cool - yeah :) Here are some more test cases that would be nice if they worked: 1. _multiple underlines_ in _one_ sentence. 2. _sentence with <other symbols> in them_ 3. _sentence with [other symbols] in them_ 4. _sentence with ~other symbols~ in them_ 5. _sentence with "other symbols" in them_ 6. _sentence with \other symbols\ in them_ 7. _sentence with {other symbols} in them_ 8. _sentence with other symbols? ? in them_ 9. sentence with _*mixed*_ formatting code in it. 10. sentence with _mixed *formatting* code_ in it. 11. sentence with _mixed *formatting*_ code in it. 12. _sentence with /mixed formatting symbols/ in it_ <-- would be very nice ;) 13. _sentence with numbers 12345 in them_ 14. _sentence with decimal numbers 23.45 or 23,45 in them_ 15. _sentence with hy-phen in them_ 16. Multiline _sentence_ with _multiple underlines_ and _punctuation_. Multiline _sentence_ with _multiple underlines_ and _punctuation_. Multiline _sentence_ with _multiple underlines_ and _punctuation_.
Peter Lairo: file a new bug for those if they do not already work.
I wanted to test my suggestions, but for some reason on build 2001-11-25, winNT none of the formattings work anymore (including *bold*). Anyone know what's going on, or how I can fix this? Should I file the bug for "advanced underlining" anyways?
OK, I filed bug 111946 to hopefully implement advanced _underlining_ of special cases :) Just getting this bug fixed would be pretty cool, though. BTW. I sent myself an email with just "*bold*" in it (and my text-only sig line). It arrived with HTML tags and the text wasn't bolded. I have "autodetect" selected for outgoing mail. Is that a bug, or something that could be affecting this bug?
basic, the quote stuff is limited to Mailnews message display and can (and does) thus live in a stylesheet specific to that. /Underline/ is not limited to Mailnews and must thus live in a more central place. html.css should work, if the "owner" of that file allows us to add that rule. FYI: The css selector is now |span.moz-txt-underscore|. If you really really want to use <u>, then OK. But I'd much prefer the stylehseet solution, to not extend the lifetime of the ugly <u> any more.
Blocks: 111946
well my opinion is that using span.moz-txt-underscore{ text-decoration: underline; } in html.css is not a good thing as it will affect html/xhtml files that uses that class for other purposes. If <u> should not be used I'm not sure what else can be used. <ins> is another tag that is commonly (at least in Win32 Opera5 and Win32 IE5.0) rendered with underline (though not in NS4), maybe that would work?
No longer blocks: 111946
Forgot to mentioned that <ins> is the insert tag: http://www.w3.org/TR/html401/struct/text.html#h-9.4 and mozilla currently underlines it. Does *this is bold* also mean *this is strong emphasis* ? And /this is italics/ also mean /this is emphasis/ ? If so can _this is underlined_ also mean _this is inserted_ ????
> using span.moz-txt-underscore{ text-decoration: > underline; } in html.css is not a good thing as it will affect html/xhtml > files that uses that class for other purposes. I used the prefix "moz-" to prevent exactly that. > <ins> is another tag that is commonly (at least in Win32 > Opera5 and Win32 IE5.0) rendered with underline (though not in NS4), maybe > that would work? It is semantically wrong.
the moz- prefix only helps avoid things if we start telling people that they should not use moz- prefixed classes in their document. if <u> is depreciated and <ins> is not acceptable, I guess we have to live with <span class="moz-text-underscore">. But I don't think putting span.moz-text-underscore{ text-decoration: underline; } into html.css is a good idea. Maybe <span class="moz-text-underscore" style="text-decoration: underline;"> ?
or maybe the generated html should have a <style type="text/css"> block with all the style info in there?
Uhm, shouldn't moz-text-underscore be -moz-text-underscore?
Nope, said Ian (IIRC, it was him) back then.
Attached patch Proposed Patch A (obsolete) (deleted) — Splinter Review
Underline the span, including the underlines
Attached patch Proposed Patch B (deleted) — Splinter Review
Underline the span, hiding the underlines
Neil, if you add a "span" before the dot, r=BenB. Neil avoids the problem that we were discussing by just adding the rule to the stylesheet for the message page of Mailnews. That means, it won't work, if the converter is used in the browser (not at the moment, because of technicalities, but hopefully later). However, considering that it is currently working *nowhere* (by default), the patch is a strict improvement and a nice interim solution. Smart. Ben
Oh, my r= is for patch A only. When writing the converter, I decided not to remove the plaintext style tags (*/_ etc.) by default, in case the converter guessed wrong and it is not a plaintext style tag, but some obscure part of the content (as in "/tmp/_myfile_.txt"). Users are free, however, to add that rule to their userContent.css, if they prefer not seeing these palintext tags.
Attached patch Proposed Patch (deleted) — Splinter Review
Updated Patch A as per Ben's comment.
Attachment #67075 - Attachment is obsolete: true
Comment on attachment 67091 [details] [diff] [review] Proposed Patch Nice. r=hwaara
Attachment #67091 - Flags: review+
This is a themes patch - CC hewitt for super-review.
I presume the first patch (attachment 58876 [details] [diff] [review]) and Patch B should be marked as obsolete, right?
Comment on attachment 67091 [details] [diff] [review] Proposed Patch sr=hewitt
Attachment #67091 - Flags: superreview+
->Neil I'll checkin attachment 67091 [details] [diff] [review] ("Proposed Patch") when the tree opens.
Assignee: ducarroz → neil
Status: ASSIGNED → NEW
fix checked in.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
QA Contact: esther → laurel
laurel: I'm cleaning out "Networking" can you verify or move this bug?
.
Component: Networking → Composition
Product: Browser → MailNews
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: