Last Comment Bug 99457 - Support CSS3 'word-wrap' property (breaks long lines)
: Support CSS3 'word-wrap' property (breaks long lines)
Status: RESOLVED FIXED
: css3, intl
Product: Core
Classification: Components
Component: Layout: Text (show other bugs)
: Trunk
: All All
: -- enhancement with 38 votes (vote)
: mozilla1.9.1a1
Assigned To: Simon Montagu :smontagu
: Hixie (not reading bugmail)
:
Mentors:
http://www.w3.org/TR/css3-text/#word-...
: 146703 146741 147127 232547 278374 295376 332445 349142 355855 361141 421692 442298 (view as bug list)
Depends on: 389710 447776 447783 447884 453468 453471 455473
Blocks: 56652 css-text-3 115028 116225 221320 447767 50633 71549 92851 104952 449555
  Show dependency treegraph
 
Reported: 2001-09-13 06:02 PDT by Christopher Aillon (sabbatical, not receiving bugmail)
Modified: 2014-04-26 02:23 PDT (History)
62 users (show)
roc: wanted1.9.1+
karlt: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch v.1 (24.05 KB, patch)
2008-07-10 15:06 PDT, Simon Montagu :smontagu
no flags Details | Diff | Splinter Review
Testcase from 456.bereastreet.com with -moz-word-wrap:-moz-break-word (3.02 KB, text/html)
2008-07-10 15:09 PDT, Simon Montagu :smontagu
no flags Details
Another testcase (3.13 KB, text/html)
2008-07-10 15:12 PDT, Simon Montagu :smontagu
no flags Details
Screenshot of attachment 328988 with the patch (173.17 KB, image/png)
2008-07-10 15:14 PDT, Simon Montagu :smontagu
no flags Details
Patch v.2 (part 1) (19.11 KB, patch)
2008-07-14 07:51 PDT, Simon Montagu :smontagu
no flags Details | Diff | Splinter Review
Patch v.2 (part 2) (21.47 KB, patch)
2008-07-14 07:59 PDT, Simon Montagu :smontagu
no flags Details | Diff | Splinter Review
Testcase without the vendor prefix (3.12 KB, text/html)
2008-07-14 08:02 PDT, Simon Montagu :smontagu
no flags Details
Screenshot of attachment 329458 with the patch (182.31 KB, image/png)
2008-07-14 08:05 PDT, Simon Montagu :smontagu
no flags Details
Testcase from 456.bereastreet.com without the vendor prefix (3.01 KB, text/html)
2008-07-14 08:17 PDT, Simon Montagu :smontagu
no flags Details
CTL testcase (4.46 KB, text/html)
2008-07-14 08:27 PDT, Simon Montagu :smontagu
no flags Details
Part 2 updated (21.98 KB, patch)
2008-07-21 11:04 PDT, Simon Montagu :smontagu
no flags Details | Diff | Splinter Review
Tests (7.86 KB, patch)
2008-07-21 11:07 PDT, Simon Montagu :smontagu
no flags Details | Diff | Splinter Review
Part 1, addressing David's comments (18.71 KB, patch)
2008-07-21 13:39 PDT, Simon Montagu :smontagu
dbaron: review+
dbaron: superreview+
Details | Diff | Splinter Review
Part 2, addressing Rob's comments (24.45 KB, patch)
2008-07-22 05:30 PDT, Simon Montagu :smontagu
roc: review+
roc: superreview+
Details | Diff | Splinter Review

Description Christopher Aillon (sabbatical, not receiving bugmail) 2001-09-13 06:02:02 PDT
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.
Comment 1 David Baron :dbaron: ⌚️UTC-8 2001-09-13 06:49:04 PDT
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.
Comment 2 David Baron :dbaron: ⌚️UTC-8 2001-09-13 06:52:41 PDT
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'.
Comment 3 rbs 2001-09-13 11:24:34 PDT
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.)
Comment 4 Christopher Aillon (sabbatical, not receiving bugmail) 2001-09-13 12:20:44 PDT
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.
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2001-09-13 13:29:01 PDT
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).
Comment 6 Hixie (not reading bugmail) 2001-09-18 07:55:56 PDT
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.
Comment 7 Hixie (not reading bugmail) 2001-09-18 07:59:21 PDT
(speaking of wrapping, I guess something is awry with this build...)
Comment 8 Boris Zbarsky [:bz] (still a bit busy) 2002-05-24 22:24:58 PDT
*** Bug 146703 has been marked as a duplicate of this bug. ***
Comment 9 Boris 'pi' Piwinger 2002-05-25 02:06:56 PDT
*** Bug 146741 has been marked as a duplicate of this bug. ***
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2002-05-26 00:53:39 PDT
*** Bug 147127 has been marked as a duplicate of this bug. ***
Comment 11 Matt 2002-05-27 18:30:40 PDT
Adding self to CC and hoping to God this issue is finally fixed before a release
to general public :-)
Comment 12 Jesse Ruderman 2002-06-29 16:11:41 PDT
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?
Comment 13 David Baron :dbaron: ⌚️UTC-8 2002-06-29 16:33:59 PDT
I find it incredibly useful, since it allows pasting of long URLs into bugzilla,
which 4.x did not.
Comment 14 Jesse Ruderman 2002-06-29 19:28:52 PDT
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.
Comment 15 Hans Christian Studt 2002-06-30 03:44:42 PDT
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
Comment 16 David G King 2002-08-05 16:40:52 PDT
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.
Comment 17 David Baron :dbaron: ⌚️UTC-8 2002-08-05 16:48:18 PDT
This doesn't block bug 91662.
Comment 18 rbs 2002-10-26 00:07:28 PDT
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|
Comment 19 Christopher Hoess (gone) 2003-06-08 11:11:29 PDT
add CSS3 property to summary, reassign
Comment 20 David Baron :dbaron: ⌚️UTC-8 2004-01-29 10:34:55 PST
*** Bug 232547 has been marked as a duplicate of this bug. ***
Comment 21 Anne (:annevk) 2004-01-30 02:41:45 PST
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.
Comment 22 Brian 'netdragon' Bober 2004-08-30 16:22:41 PDT
This would be useful to use in place of wrap=hard on Bugzilla someday (bug 11901)
Comment 23 Brian 'netdragon' Bober 2004-08-30 16:52:05 PDT
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?
Comment 24 Anko 2004-08-30 17:37:03 PDT
(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.
Comment 25 Brian 'netdragon' Bober 2004-08-31 00:27:36 PDT
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.
Comment 26 Ernest Cline 2004-08-31 07:02:30 PDT
(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.
Comment 27 Hixie (not reading bugmail) 2004-08-31 08:20:45 PDT
http://www.whatwg.org/specs/web-forms/current-work/#extensions3
Comment 28 Brian 'netdragon' Bober 2004-08-31 10:35:20 PDT
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.
Comment 29 Len Weisberg 2004-09-10 22:29:00 PDT
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.
Comment 30 Phil Ringnalda (:philor) 2005-01-14 18:33:51 PST
*** Bug 278374 has been marked as a duplicate of this bug. ***
Comment 31 Jaime Mitchell (use bugmail@jaimem.org.uk for email) 2005-05-24 12:00:29 PDT
*** Bug 295376 has been marked as a duplicate of this bug. ***
Comment 32 Károly Gossler 2005-10-02 03:36:47 PDT
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
Comment 33 Ria Klaassen (not reading all bugmail) 2006-04-01 09:07:28 PST
*** Bug 332445 has been marked as a duplicate of this bug. ***
Comment 34 fantasai 2006-04-01 10:40:51 PST
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
Comment 35 Stuart Morgan 2006-08-18 07:54:54 PDT
*** Bug 349142 has been marked as a duplicate of this bug. ***
Comment 36 Dave Townsend [:mossop] 2006-10-07 08:25:17 PDT
*** Bug 355855 has been marked as a duplicate of this bug. ***
Comment 37 Ria Klaassen (not reading all bugmail) 2006-11-18 09:02:17 PST
*** Bug 361141 has been marked as a duplicate of this bug. ***
Comment 38 Syophone 2007-03-01 18:31:26 PST
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?
Comment 39 WulfTheSaxon [:Wulf] 2007-04-27 20:48:02 PDT
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.
Comment 40 Cesar Eduardo Barros 2007-05-17 14:05:14 PDT
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).
Comment 41 Syophone 2007-11-23 06:45:32 PST
(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.
Comment 42 Syophone 2008-03-07 00:38:17 PST
Who can implemented them as '-moz-word-wrap' and
'-moz-word-break'?
Comment 43 fantasai 2008-03-08 13:58:18 PST
*** Bug 421692 has been marked as a duplicate of this bug. ***
Comment 44 Dave Garrett 2008-06-27 10:51:16 PDT
*** Bug 442298 has been marked as a duplicate of this bug. ***
Comment 45 Rasmus L. Knabe 2008-06-27 11:32:54 PDT
This bug has been running since 2001 - why isen't it fixed yet?
Comment 46 Ryan VanderMeulen [:RyanVM] 2008-06-27 11:58:58 PDT
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.
Comment 47 Rasmus L. Knabe 2008-06-28 08:17:34 PDT
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?
Comment 48 Simon Montagu :smontagu 2008-07-10 15:06:49 PDT
Created attachment 328986 [details] [diff] [review]
Patch v.1

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.
Comment 49 Simon Montagu :smontagu 2008-07-10 15:09:23 PDT
Created attachment 328987 [details]
Testcase from 456.bereastreet.com with -moz-word-wrap:-moz-break-word
Comment 50 Simon Montagu :smontagu 2008-07-10 15:12:56 PDT
Created attachment 328988 [details]
Another testcase
Comment 51 Simon Montagu :smontagu 2008-07-10 15:14:34 PDT
Created attachment 328989 [details]
Screenshot of attachment 328988 [details] with the patch
Comment 52 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-07-10 16:57:12 PDT
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.
Comment 53 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-07-10 16:58:29 PDT
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.
Comment 54 Simon Montagu :smontagu 2008-07-10 20:51:02 PDT
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.
Comment 55 Simon Montagu :smontagu 2008-07-10 20:57:59 PDT
(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" :)
Comment 56 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-07-10 21:06:49 PDT
(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.
Comment 57 Simon Montagu :smontagu 2008-07-10 21:15:44 PDT
(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?
Comment 58 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-07-10 21:26:13 PDT
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.
Comment 59 Simon Montagu :smontagu 2008-07-10 21:59:45 PDT
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?
Comment 60 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-07-10 22:38:12 PDT
Yes.
Comment 61 Len Weisberg 2008-07-10 23:57:01 PDT
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.
Comment 62 Simon Montagu :smontagu 2008-07-11 01:08:28 PDT
(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.
Comment 63 Masayuki Nakano [:masayuki] (Mozilla Japan) 2008-07-11 01:29:34 PDT
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.)
Comment 64 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-07-11 01:35:58 PDT
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.
Comment 65 Simon Montagu :smontagu 2008-07-14 07:51:10 PDT
Created attachment 329454 [details] [diff] [review]
Patch v.2 (part 1)

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.
Comment 66 Simon Montagu :smontagu 2008-07-14 07:59:02 PDT
Created attachment 329457 [details] [diff] [review]
Patch v.2 (part 2)

This part is the implementation, and is still somewhat w-i-p
Comment 67 Simon Montagu :smontagu 2008-07-14 08:02:40 PDT
Created attachment 329458 [details]
Testcase without the vendor prefix
Comment 68 Simon Montagu :smontagu 2008-07-14 08:05:45 PDT
Created attachment 329459 [details]
Screenshot of attachment 329458 [details] with the patch
Comment 69 Simon Montagu :smontagu 2008-07-14 08:17:02 PDT
Created attachment 329463 [details]
Testcase from 456.bereastreet.com without the vendor prefix
Comment 70 Syophone 2008-07-14 08:26:26 PDT
Well,what about textarea using this patch?
Comment 71 Simon Montagu :smontagu 2008-07-14 08:27:32 PDT
Created attachment 329465 [details]
CTL testcase

Tests that words don't break in mid-cluster and shaping works across word breaks.
Comment 72 Simon Montagu :smontagu 2008-07-14 09:02:07 PDT
(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.
Comment 73 Simon Montagu :smontagu 2008-07-14 09:43:04 PDT
AFAICT IE and Webkit both behave as if |word-wrap: break-word !important| is set for textarea.
Comment 74 Len Weisberg 2008-07-14 11:48:15 PDT
(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?

Comment 75 Simon Montagu :smontagu 2008-07-15 03:47:37 PDT
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 76 Simon Montagu :smontagu 2008-07-21 11:04:29 PDT
Created attachment 330601 [details] [diff] [review]
Part 2 updated
Comment 77 Simon Montagu :smontagu 2008-07-21 11:07:57 PDT
Created attachment 330602 [details] [diff] [review]
Tests
Comment 78 David Baron :dbaron: ⌚️UTC-8 2008-07-21 11:29:01 PDT
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?
Comment 79 Simon Montagu :smontagu 2008-07-21 13:11:11 PDT
> 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
Comment 80 David Baron :dbaron: ⌚️UTC-8 2008-07-21 13:20:18 PDT
(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).
Comment 81 Simon Montagu :smontagu 2008-07-21 13:39:21 PDT
Created attachment 330642 [details] [diff] [review]
Part 1, addressing David's comments
Comment 82 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-07-21 15:23:12 PDT
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 83 David Baron :dbaron: ⌚️UTC-8 2008-07-21 15:29:19 PDT
Comment on attachment 330642 [details] [diff] [review]
Part 1, addressing David's comments

r+sr=dbaron
Comment 84 Simon Montagu :smontagu 2008-07-22 05:30:57 PDT
Created attachment 330755 [details] [diff] [review]
Part 2, addressing Rob's comments
Comment 85 Simon Montagu :smontagu 2008-07-24 00:22:44 PDT
Pushed on trunk. http://hg.mozilla.org/index.cgi/mozilla-central/rev/3cf51abb4040
Comment 86 Jim Jeffery not reading bug-mail 1/2/11 2008-07-24 18:11:04 PDT
Possible to have caused: https://bugzilla.mozilla.org/show_bug.cgi?id=447884
Comment 87 Karl Tomlinson (:karlt) 2010-11-25 20:12:26 PST
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

Note You need to log in before you can comment on or make changes to this bug.