With bug 22022 fixed, things look much better for view source when wrap is on. However, it would be great if we didn't have to scroll horizontally at all. Bugzilla's main page is a great example of this with a huge URL right in the middle of the page (View Bugs Already Reported Today). Scrolling horizontally to see the whole URL defeats the purpose of the wrap IMO. Doron asked me to CC some people from 22022.

Should -moz-pre-wrap break up long lines? I don't think it should, any more than 'white-space: normal' should. I think this would also break other uses of -moz-pre-wrap (e.g., textareas and plaintext mail compose), and it would also probably differ from the description in the CSS3 spec, which I hope will include a value equivalent to -moz-pre-wrap.

And, FWIW, this is a Layout bug, and requires perhaps nontrivial implementation work there. Right now the values of 'white-space' can be put in a simple grid: 'normal' 'nowrap' '-moz-pre-wrap' 'pre' and you're suggesting that the grid should look like: 'normal' 'nowrap' '-moz-pre-wrap' 'pre' which suggests to me that what you really want is a new value, or perhaps two new values, rather than a change to '-moz-pre-wrap'.

This bug looks like another bug that will be sitting here dormant (like the recently fixed bug 22022 -- note the low number). So if someone is interested to pick up the torch, here are some starting points: - you will need to hack a new value (since -moz-pre-wrap has other uses) - you will need to handle a new mode for the linebreaker/wordbreaker so that breaking can occur with other characters such as '&' (like Nav4.x when pasting a long url in bugzilla comments). See nsTextTransformer.cpp which relies on nsILineBreaker/nsIWordBreaker which are where to really effect the changes while making sure not to break words unnecessarily (especially intl words). The core layout code itself won't need major changes except to append your new wrap value in the appropriate places where wrapping is tested, but note that it will make view-source with wrapping even slower because more words would have to be measured. (PS: I am often amazed at the RFEs pertaining to view-source.)

I have no problem with a totally new value(s). Maybe this bug really should be changed to reflect that. No idea with what it would be called though. My point is that if wrap is on, it seems stupid to still have to scroll horizontally, regardless of the way the W3C defined CSS values handle it. Many word processing programs wrap long lines and it makes a lot of sense to me.

Note that maybe this wrap value could be used for textareas.... this would solve the "NS and IE soft wrap in the middle of a word in textareas" bugs we have filed (I can dig up bug #s if need be).

As I understand it, btw, there are two possible keywords that should be supported here. One should forget about doing word wrapping, but wrap at the end of the line whatever happens, a bit like with overflow on a console, and the second should wrap as normal *except for words longer than the line*, for which it should break the word at the end of the line. +-------------+ |This is an ex| |ample of the | |first type, w| |ith each wrap| |ped word cut | |off... | +-------------+ +------------+ |...and this | |is an | |example of | |the second | |type, with | |an | |eeextrrreeee| |emmely long | |word. | +------------+ The first would be used for a forced wrap <pre>, presumably, and the second would be used for Chatzilla, again presumably. When implementing this, it might be wise to implement it as four separate axes, as this is roughly how CSS3 will probably approach it: 'wrap-option': no-wrap | wrap | emergency | width 'linefeed-treatment': auto | ignore | preserve | treat-as-space | treat-as-zero-width-space 'space-treatment': ignore | preserve | ignore-if-before-linefeed | ignore-if-after-linefeed | ignore-if-surrounding-linefeed 'white-space-treatment': preserve | collapse The 'white-space' keywords would then map as follows: white-space wrap-option linefeed-treatment space-treatment white-space-treatment normal wrap auto preserve collapse nowrap no-wrap auto preserve collapse pre no-wrap preserve preserve preserve-m-p-w (1) wrap preserve preserve preserve -m-... (2) emergency preserve preserve preserve -m-... (3) width preserve preserve preserve ...where (1) is -moz-pre-wrap, our existing extension, (2) is the extension required for Chatzilla (as I understand it) and (3) is the extension required for breaking <pre> blocks at the width, regardless of word wrapping.

(speaking of wrapping, I guess something is awry with this build...)

*** Bug 146703 has been marked as a duplicate of this bug. ***

*** Bug 146741 has been marked as a duplicate of this bug. ***

*** Bug 147127 has been marked as a duplicate of this bug. ***

Adding self to CC and hoping to God this issue is finally fixed before a release to general public :-)

dbaron: I find it annoying that Mozilla's textareas don't force-wrap long words such as URLs. Are you sure we can't just change the behavior of -moz-pre-wrap?

I find it incredibly useful, since it allows pasting of long URLs into bugzilla, which 4.x did not.

Mozilla should display textarea contents hard-wrapped but submit them the same was it does now. IE gets it right, making it easier to include links in Slashdot comments.

Jesse argue that "Mozilla should display textarea contents hard-wrapped". This comment is about long normal text and I think long URL's may be different problem. I will suggest that Mozilla should at least offer the possibillity to wrap text at windows width, like some editors e.g. UltraEdit does. In order to see the need for such a function please check out the following link and SCROLL DOWN TO THE TEXT "Sir,I have both the cds". http://groups.google.com/groups?q=%22Sir,I+have+both+the+cds%22&hl=en&lr=&ie=UTF-8&oe=UTF8&selm=20011205015009.0E1083FEBF%40listman.redhat.com&rnum=1

I agree with Comment #13, wrapping URL's is not fun. My eMail program does that, and I hate having to copy and paste several times to get the entire URL into the window. However, as this bug is blocking v1.1 (via Bug #91662), some action is required.

This doesn't block bug 91662.

For the record, here is the proposed CSS3 spec about this feature: http://www.w3.org/TR/2002/WD-css3-text-20021024/#text-wrapping In the terminology of CSS3, this bug is equivalent to: |wrap-option: emergency|

add CSS3 property to summary, reassign

*** Bug 232547 has been marked as a duplicate of this bug. ***

The CSS3 module where 'wrap-option' is in, is now CR. If we want to solve these issues, we need to support it according to the specification.

This would be useful to use in place of wrap=hard on Bugzilla someday (bug 11901)

Looking at the spec longer, I don't know if this will replace wrap=hard. Will it? http://www.w3.org/TR/css3-text/#wrap-option The information here is confusing. Does wrap insert hard breaks or not?

(In reply to comment #23) > Looking at the spec longer, I don't know if this will replace wrap=hard. Will it? > > http://www.w3.org/TR/css3-text/#wrap-option > > The information here is confusing. Does wrap insert hard breaks or not? wrap is an attribute of a textarea. This bug is about creating/implementing a new css attribute, that would apply to all elements. Totally different things.

There are no such things as css attributes. They are called properties. Attributes are for HTML tags. And I know what I was asking about. If you do not know the answer to the question I seek an answer for, please don't respond. If you have questions about what I mean in my comment, then email me privately.

(In reply to comment #23) > Looking at the spec longer, I don't know if this will replace wrap=hard. > Will it? > > http://www.w3.org/TR/css3-text/#wrap-option > > The information here is confusing. Does wrap insert hard breaks or not? The 'wrap-option' property, like all W3 CSS properties, is only intended to control the presentation of content, not what goes into the content itself. My interpretation of how the 'wrap-option' property and the <textarea> wrap attribute should interact is as follows: 1) The default value of 'wrap-option' for a <textarea> should depend upon the value of its wrap attribute: textarea[wrap=off] { wrap-option: no-wrap } textarea[wrap=soft] { wrap-option: wrap } textarea[wrap=hard] { wrap-option: wrap } 2) Whether rendered line breaks are transmitted upon submittal as line break characters is dependent upon the value of the wrap attribute. If wrap is off or soft, rendered line breaks that may be generated to wrap the line in accord with the wrap-option property are not transmitted. If wrap is hard, such rendered line breaks are transmitted. Thus, the wrap-option CSS property in my opinion does not replace the <textarea> wrap attribute.

Ernest: Thanks. Yes, that does makes sense, sorta. So perhaps the linefeeds are CSS generated content that apply only for presentation. Maybe I misintrepreted Hixie's test on http://www.hixie.ch/tests/evil/mixed/wraptextarea.html to mean that the formatting applied from the CSS property white-space (and other CSS properties) would also be submitted with the form. It seems like the same sort of thing. Argh, everything within the text module seems to make sense until you start talking about forms. I think there should be some note on http://www.w3.org/TR/css3-text/ saying that these properties don't apply to what's submitted and to use the Web Forms recommendation instead for that purpose. Hixie: Thank you for the link. It seems like that's what we are looking for.

In response to comment #16: > I agree with Comment #13, wrapping URL's is not fun. My eMail program > does that, and I hate having to copy and paste several times to get > the entire URL into the window. Thanks to Akkana Peck, I am among the few who know about the following obscure incantation: user_pref("editor.singleLine.pasteNewlines", 3); If this were made less obscure, there would be one less argument in favor of preserving long lines.

*** Bug 278374 has been marked as a duplicate of this bug. ***

*** Bug 295376 has been marked as a duplicate of this bug. ***

http://www.w3.org/TR/css3-text/#changes : "The 'wrap-option' property has been replaced by the 'text-wrap' and 'word-break' property." http://www.w3.org/TR/css3-text/#text-wrap http://www.w3.org/TR/css3-text/#word-break

*** Bug 332445 has been marked as a duplicate of this bug. ***

No, actually, it's been replaced with the word-wrap and text-wrap properties. For this bug report it seems word-wrap is wanted. http://www.w3.org/TR/css3-text/#word-wrap http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/wordwrap.asp

*** Bug 349142 has been marked as a duplicate of this bug. ***

*** Bug 355855 has been marked as a duplicate of this bug. ***

*** Bug 361141 has been marked as a duplicate of this bug. ***

Well, although CSS Text Level 3 is in Working Draft stage, are we able to do something with 'word-break' and 'word-wrap' without extensions?

Shouldn't this be marked parity-IE6? See http://www.456bereastreet.com/archive/200704/how_to_prevent_html_tables_from_becoming_too_wide/ --- @oueki I believe what you're asking is whether it can be implemented in Firefox before it becomes a recommendation? If so, the answer is yes. It can be implemented as -moz-word-wrap. Take a look at -moz-outline, etc.

Just a heads-up: MediaWiki is now using word-wrap: break-word on its diff display (see http://bugzilla.wikimedia.org/show_bug.cgi?id=1438#c12 and http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/diff.css?r1=22227&r2=22226&pathrev=22227).

(In reply to comment #39) > I believe what you're asking is whether it can be implemented in Firefox before > it becomes a recommendation? If so, the answer is yes. It can be implemented as > -moz-word-wrap. Take a look at -moz-outline, etc. Yes, I think it's easy to be implemented them as '-moz-word-wrap' and '-moz-word-break' for Firefox. (But it won't be implemented them before Fx 4.0, even 5.0, I afraid.) They are important for textareas and all the block elements.

Who can implemented them as '-moz-word-wrap' and '-moz-word-break'?

This bug has been running since 2001 - why isen't it fixed yet?

Because nobody's deemed it high enough priority to fix it versus the other bugs needing to be fixed. If you feel that it needs to be fixed, you have the power to make it so! Download the source and hack away! I'm sure one of the layout peers would be happy to review a patch if one should come along.

Thanks for your explanation - don't know how this work. I would love to help, but sadly I doesn't have that kind of skills. Is there some kind of community where we web developers can communicate what we need from Firefox - maybe help change the focus on what's important?

This works quite nicely, but it produces a kind of newspaper column style break, which I'm not sure is exactly what the spec has in mind. It probably also needs some extra tweaking to avoid breaks in certain places, e.g between text and punctuation.

I don't think this is correct. The spec says "An unbreakable "word" may be broken at an arbitrary point if there are no otherwise-acceptable break points in the line." But this will break at an arbitrary point even if there are otherwise-acceptable break points in the line. Fixing that is a little tricky with our current inline layout model. You would need to modify nsLineLayout::NotifyOptionalBreakPosition to indicate the priority of the break opportunity and not allow it to override a high-priority opportunity with a lower priority opportunity. You might also need to modify the logic around DoReflowInlineFrames and its callees, where we decide whether to go ahead and place the line where it is or move it below a float. I'm not sure whether a line next to a float that has overflows and has word-wrap:break-word should break or move down. I actually had a crack at this recently and gave up when it looked really hard. But now that I look again it's not as hard as I thought, the above approach should work. Thanks for taking this on! It's needed.

BTW I think this should lose the vendor prefix. AFAIK IE and Webkit already implement this without a vendor prefix so we might as well too.

Another thing which is probably wrong here is setting the TEXT_ENABLE_WORD_WRAP flag on the text run, rather than testing style per frame.

(In reply to comment #52) > I don't think this is correct. The spec says > "An unbreakable "word" may be broken at an arbitrary point if there are no > otherwise-acceptable break points in the line." > > But this will break at an arbitrary point even if there are > otherwise-acceptable break points in the line. I suppose what I actually implemented was "text-wrap: unrestricted" :)

(In reply to comment #54) > Another thing which is probably wrong here is setting the TEXT_ENABLE_WORD_WRAP > flag on the text run, rather than testing style per frame. Yeah definitely.

(In reply to comment #52) > Fixing that is a little tricky with our current inline layout model. You would > need to modify nsLineLayout::NotifyOptionalBreakPosition to indicate the > priority of the break opportunity and not allow it to override a high-priority > opportunity with a lower priority opportunity. We want that anyway for bug 389710, right?

Yes, but for bug 389710 we want something more complex. Here we just need two levels but in bug 389710 we need to choose a punctuation break over a whitespace break if the whitespace break is "too far away". I'd start with this since it's simpler and then add 389710 on top, unless you want to do them both together.

I also notice that IE and Webkit don't display a hyphen when breaking words. To my eyes it looks a lot better with the hyphen (apart from making it much easier to implement by leveraging the existing code for soft hyphens), and the spec doesn't say anything either way, unlike with text-wrap. Do we want to be consistent with the existing implementations?

Yes.

I agree, there should NOT be a hyphen. It seems to me that the long word is almost always a URL. Whether it is re-assembled automatically when pasted into the location bar, or done manually, the hyphens would get in the way and likely lead to errors. That may be why IE and Webkit do it without hyphens, so it's not just a matter of consistency.

(In reply to comment #61) > Whether it is re-assembled automatically when > pasted into the location bar, or done manually, the hyphens would get in > the way and likely lead to errors. That at least is not a reason for removing the hyphens. They are only present in the display, and disappear when copying and pasting.

Note that the words on CJ context don't need hyphens at breaking a word, so, we don't have to add hyphens to there. (If the automatically hyphenation is needed, we should propose a new value for word-wrap.)

CJK doesn't matter here since there are first-class line break opportunities between the CJK words. Auto-hyphenation is a separate issue which already has its own CSS3 property. The reason to not show a hyphen is mainly consistency with other browsers. But also, a hyphen might be inappropriate since we have no idea what sort of text is being broken here. In the URL example, a hyphen might not cause a serious problem, but it could feel odd. Simon, I suggest we proceed without a hyphen and if you feel strongly about it, start a discussion on www-style and see if you get can support for a hyphen from other browsers.

I'm splitting the patch into two parts. This part contains all the infrastructure for the new CSS property, so as not to carry it over from version to version. It passes the mochitests in layout/style/tests.

This part is the implementation, and is still somewhat w-i-p

Well,what about textarea using this patch?

Tests that words don't break in mid-cluster and shaping works across word breaks.

(In reply to comment #70) > Well,what about textarea using this patch? What are you asking? The patch works nicely with textarea with word-wrap: break-word specified. It doesn't add that to the default style for textarea, but maybe it should.

AFAICT IE and Webkit both behave as if |word-wrap: break-word !important| is set for textarea.

(In reply to comment #68) > Created an attachment (id=329459) [details] > Screenshot of attachment 329458 [details] with the patch This screenshot shows all "long" words starting on a new line. Is this a requirement? At least in this example, where the text is justfified, it results in sometimes large amounts of empty space. Would it be possible to allow long words to start anywhere? It seems to me that would be preferable. Am I missing something?

Long words starting on a new line follows from the specification that 'an unbreakable "word" may be broken at an arbitrary point if there are no otherwise-acceptable break points in the line'. The space before the long word is an acceptable break point, so the line breaks there. As I said already in comment 55, breaking in mid-long-word and not before it is "text-wrap: unrestricted". I plan to implement that right after this in a new bug.

Comment on attachment 329454 [details] [diff] [review] Patch v.2 (part 1) >-[scriptable, uuid(529b987a-cb21-4d58-99d7-9586e7662801)] >+[scriptable, uuid(216343fe-4e61-11dd-9843-001485f1fdbb)] > interface nsIDOMCSS2Properties : nsISupports You should bump the IID of nsIDOMNSCSS2Properties, not nsIDOMCSS2Properties. >+ attribute DOMString wordWrap; >+ // raises(DOMException) on setting >+ Could you add to the end of the interface rather than the middle? This property is already supported un-prefixed by IE, right? Does IE support the same set of values?

> Could you add to the end of the interface rather than the middle? Isn't the interface sorted by category? I put it in the section marked /* CSS3 properties */ > This property is already supported un-prefixed by IE, right? Does IE support > the same set of values? Yes and yes. http://msdn.microsoft.com/en-us/library/ms531186.aspx

(In reply to comment #79) > > Could you add to the end of the interface rather than the middle? > > Isn't the interface sorted by category? I put it in the section marked /* CSS3 > properties */ It's not particularly well-sorted, and the categories aren't always particularly clear. We've been adding new ones to the end (mostly, at least).

This approach is good, but it needs some solid documentation describing how it works. Certainly we need some documentation for gfxBreakType. I don't think we should have GetBreakPriority --- just use GetLastOptionalBreakPosition, which is more descriptive as well. Other than that, it looks great.

Comment on attachment 330642 [details] [diff] [review] Part 1, addressing David's comments r+sr=dbaron

Pushed on trunk. http://hg.mozilla.org/index.cgi/mozilla-central/rev/3cf51abb4040

Possible to have caused: https://bugzilla.mozilla.org/show_bug.cgi?id=447884

wordwrap-02.html now passes with Pango and wordwrap-03.html now passes with Pango and on WINNT 6.1. Also marked wordwrap-02.html fails on other platforms so we know when it starts to pass. http://hg.mozilla.org/mozilla-central/rev/cd4ca07f77a8