Closed Bug 82711 Opened 23 years ago Closed 10 years ago

CSS white-space property not supported on textareas

Categories

(Core :: DOM: Editor, defect, P3)

Product:
Core
Component:
DOM: Editor
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla36

People

(Reporter: amardare, Assigned: bmarsd, Mentored)

References

(
URL
)

Details

(Keywords: dev-doc-complete, testcase, Whiteboard: [lang=c++][CSS1-5.6.2][html](py8ieh: check two bugs are filed))

Attachments

(5 files, 3 obsolete files)

simplified testcase
746 bytes, text/html
Details
testcase from comment 45
24.58 KB, text/html
Details
Testcase I used
705 bytes, text/html
Details
Support CSS white-space property on textareas
9.33 KB, patch
bmarsd
: review+
Details | Diff | Splinter Review
Fix error with some compilers from previous patch
975 bytes, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
BuildID:    

Mozilla: Wrapping Text problem
Page messes up when there is wrapping text.
See web page:
http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/wraptextarea.html

Reproducible: Always
Steps to Reproduce:
1. Go to http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/wraptextarea.html
and follow the tests
2.
3.
Holy crap!  I tried loading the page in question with Win2K build 2001052404.  I
saw the behavior being described in this bug in the textareas only (they don't
support white-space:nowrap).

But then I tried resizing the window width to check wrapping.  What I saw was
that the text and scrollbar of each textarea stayed in place in relation to the
top of the page, while the border changed location to stay in the page flow. 
Very weird.

Not sure where this belongs: Form Controls or Style?
Jason the effect you are seeing is due to display:block being applied to a
<textarea>. I thought I saw a bug filed on that, but I can't find it now.
Attached file simplified testcase — 

    
    

    
  
Summary should change, as the effect seen in this bug has nothing to do with
"white-space". Could this be a dupe?

    
    

    
  
cc: hixie

    
    

    
  
OK, so that effect is a different bug.  But it still remains that
white-space:nowrap is not being honored on <textarea> elements.  That's what the
bug is originally about anyway. 

    
    

    
  
there are two bugs here... better make sure we have two bugs filed -- do we?

Whichever bug this is, it's valid, so confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: (py8ieh: check two bugs are filed)

    
    

    
  
->editor
Assignee: asa → beppe
Component: Browser-General → Editor
QA Contact: doronr → sujay

    
    

    
  
asking Kin to look at this, and cc Daniel to see if he can also look at this one
-- Daniel, if you want to grab this one, go for it.
Keywords: correctness
Priority: -- → P3
Whiteboard: (py8ieh: check two bugs are filed) → [html](py8ieh: check two bugs are filed)
Target Milestone: --- → mozilla1.0

    
    

    
  
drats >> kin
Assignee: beppe → kin

    
    

    
  
Out of curiousity, since white-space: nowrap does not appear to be supported,
what other method is there of eliminateing the non-HTML 4 <NOBR> tag?

    
    

    
  
> Out of curiousity, since white-space: nowrap does not appear to be supported,
> what other method is there of eliminateing the non-HTML 4 <NOBR> tag?

It's only not supported for textareas.....  For which there is the non-HTML4
"wrap" attribute.

For all non-textarea elements I've tried white-space:nowrap works just fine



    
    

    
  
the 2º bug is already filled as a new diferent bug?! i couldnt find it...


    
    

    
  
Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these
back in if I can.
Target Milestone: mozilla1.0 → mozilla1.0.1

    
  
Summary: white-space not supported → white-space not supported on textareas
Keywords: testcase

    
    

    
  
Duplicate of bug 50633?

    
  
Target Milestone: mozilla1.0.1 → Future
Summary: white-space not supported on textareas → CSS white-space property not supported on textareas
Whiteboard: [html](py8ieh: check two bugs are filed) → [CSS1-5.6.2][html](py8ieh: check two bugs are filed)

    
    

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

    
    

    
  
Since the textarea uses an internal DIV can't the white-space property be set to
inherit on this?

document.getBoxObjectFor( myTextArea ).firstChild -> HTMLDIVElement

    
    

    
  
The white-space property on that div is under the control of the editor running
in the textarea.  It can be set to all sorts of stuff, but editor will just
clobber that value as it initializes.

    
  
Assignee: kinmoz → mozeditor
URL: http://www.bath.ac.uk/%7Epy8ieh/inter... → http://www.hixie.ch/tests/evil/mixed/...
QA Contact: sujay → bugzilla

    
  
QA Contact: bugzilla → editor

    
  
Assignee: mozeditor → nobody

    
    

    
  
Is there any progress on this bug?
There is a known workaround by adding the attribute wrap="off" but this is a non-standard.
Also the wrap attribute is going to have a different meaning in html5 as you can see at http://www.w3schools.com/html5/att_textarea_wrap.asp

    
    

    
  
An 11-year-old bug? Still no news?

    
    

    
  
(In reply to Boris Zbarsky (:bz) [In and out Aug 1 - 10, out Aug 11-20] from comment #18)
> The white-space property on that div is under the control of the editor
> running
> in the textarea.  It can be set to all sorts of stuff, but editor will just
> clobber that value as it initializes.

FWIW, this is no longer true.  The only reason why this property is not properly supported now is because of this rule: http://mxr.mozilla.org/mozilla-central/source/layout/style/forms.css#120 which overrides whatever is set on the input/textarea elements.

    
    

    
  
OK. What's the behavior of other UAs?  I have no problem removing that rule, or moving it to the input/textarea itself, if that makes more sense, depending on what other UAs are doing here.  The key part is to not break existing sites.

    
    

    
  
(In reply to comment #23)
> OK. What's the behavior of other UAs?  I have no problem removing that rule, or
> moving it to the input/textarea itself, if that makes more sense, depending on
> what other UAs are doing here.  The key part is to not break existing sites.

On the test case below: Opera, Safari, Chrome and IE9 all respect the white-space property.  We are the only one that doesn't.

data:text/html,<textarea style="white-space: nowrap" cols=3>foo bar baz</textarea>

    
    

    
  
I can submit a patch for this if you're fine with us making this change.

    
    

    
  
> On the test case below:

Sure.  The question is how they react to all the other values of white-space, and how those interact with the existing attributes on textarea to control wrapping behavior.

Also, I assume this only applies to textarea, not <input type="text">?

Again, I'm fine with making a change once we have a clear description of the desired behavior.

    
    

    
  
(In reply to comment #26)
> > On the test case below:
> 
> Sure.  The question is how they react to all the other values of white-space,
> and how those interact with the existing attributes on textarea to control
> wrapping behavior.

I need to do test this tomorrow so that I have access to a Windows machine to test IE.

> Also, I assume this only applies to textarea, not <input type="text">?

Hmm, I'd like to test what the other engines do in input fields as well.  I can't really decide what the sensible thing to do is, but I'm slightly inclined to leave input the way it currently is, since all white-space values would cause surprises there.

    
    

    
  
Here's the test page I created:

http://people.mozilla.org/~eakhgari/white-space-textarea.html

Here are the results:

* Firefox Nightly ignores white-space altogether.
* IE 9 only seems to honor white-space: nowrap (which overrides wrap=*), and ignores the rest of the white-space values.
* In Opera 12, wrap=off overrides all white-space values.  For wrap=soft and wrap=hard, its behavior is identical to IE 9.
* Chrome and Safari both ignore wrap=off, and in the other cases seem to respect white-space over wrap=soft and wrap=hard.

I'm lost on how we can achieve compatibility with other browser engines here.  :(

    
    

    
  
So it sounds like Chrome and Safari are style-mapping "wrap" or something and then just using the computed white-space value?

I would probably be OK with doing that, since it should be reasonably simple.  Does that sound good to you?

What actually gets submitted with wrap=hard but white-space:nowrap?  Where do the line breaks in the submitted text go, if anywhere?

    
    

    
  
(In reply to comment #29)
> So it sounds like Chrome and Safari are style-mapping "wrap" or something and
> then just using the computed white-space value?

What do you mean by style-mapping?

> What actually gets submitted with wrap=hard but white-space:nowrap?  Where do
> the line breaks in the submitted text go, if anywhere?

Hmm, good question...  AFAIK we can't run server-side code on people.  Is there an easy way to test the submitted value without having a server-side component?

    
    

    
  
> What do you mean by style-mapping?

Treating the "wrap" attribute as basically a style rule that has lower priority than any of the author rules for the document.  So the same mechanism that we use to implement <font face> and various other presentational attributes.

> Is there an easy way to test the submitted value without having a server-side component?

I don't know of a way.  Unfortunately, FormData is not readable, just writable.  :(

That said, <form action="http://landfill.mozilla.org/ryl/echo.cgi" method="POST"> will get you something that just dumps out the POST data stream the server received.  You may also want to throw on an enctype="multipart/form-data" to get something that's not full of url-encoding nastiness.

    
    

    
  
Still no resolution on this issue? I guess you guys still aren't sure what is the right thing to do. My opinion (if it matters) is that you should ignore what other browsers currently do and do what the standards say. Browsers should converge on the standard, not on non-standard behavior, unless there are good reasons to ignore the standard.

If I read the html5 standard (http://www.w3.org/TR/html5/forms.html#the-textarea-element) and try to make sense of their actions (the fact that they added 'wrap' to the standard, but removed the 'off' value), I think the idea is that the 'wrap' attribute controls what happens when the text is submitted, not how it's displayed. The display could get hints from 'wrap', 'cols' and 'rows' in case no css overrides them, but if css is specified it should take precedence. Then it makes sense that they removed 'off', since it would have the same effect on the submitted text as 'soft', that is to keep it as it was input. They could have added 'off' to mean 'remove all line breaks in the submitted text' but that would have been incompatible with the current use, so I guess they didn't want to do that.

So then the css 'white-space' is what should control the display. And you should implement all values correctly (see http://www.w3.org/TR/css3-text/#white-space). Which means that the effect we're after (leave text as input by the user, no extra wraps, but preserve original line breaks and white space) is 'white-space:pre', not 'white-space:nowrap'. The 'white-space:nowrap' is supposed to collapse all spaces and line breaks and show everything in a long line. I've heard IE9 is doing that, I can't check right now, I don't have Windows installed on my Mac. The default value for textareas should probably be 'white-space:pre-wrap', not 'white-space:normal', which would still collapse all white spaces and line breaks, but allow soft wrap. I don't see the standard specifying a default value, so you have freedom in that.

Hope it helps.

    
    

    
  
> is that you should ignore what other browsers currently do and do what the standards say

Textarea is a replaced element; the standard does not define what effect CSS properties have on its contents, if any (though one could argue that the standard says that no CSS property should have any effect on the contents of a texatarea... which is patently not web-compatible).

    
    

    
  
Not sure what makes you think that, that's not what I see. Here's what I just found: in section 10.5.15 of the html standard (http://www.w3.org/TR/html5/rendering.html#the-textarea-element-0) it shows that the default rendering settings for the textarea elements should be:

textarea { binding: textarea; white-space: pre-wrap; }

and the last paragraph says:

"User agents are expected to apply the 'white-space' CSS property to textarea elements. For historical reasons, if the element has a wrap attribute whose value is an ASCII case-insensitive match for the string "off", then the user agent is expected to treat the attribute as a presentational hint setting the element's 'white-space' property to 'pre'."

Pretty much what I'm saying above in much fewer words. Except that I was saying the standard doesn't specify a default value, it seems I was wrong on that.

    
    

    
  
The problem is that that text contradicts things in the CSS spec...

In any case, what the HTML spec says is what I proposed doing in comment 29.

    
    

    
  
But my point is that you shouldn't follow Chrome and Safari too far, because as far as I can see they give preference to the 'wrap' value over explicitly specified 'white-space' values for presentation, and I think that's wrong. 'wrap' values should only be used as presentational hints, they shouldn't override explicit css rules. On the other hand, to answer your last question in comment 29, the 'wrap' value should be the one that determines what happens in submitted text, based also on the 'cols' value, and 'white-space' should be ignored for that purpose.

    
    

    
  
> because as far as I can see they give preference to the 'wrap' value over explicitly
> specified 'white-space' values

That's not what comment 28 said.  Of course their behavior may have changed since....

    
    

    
  
Actually it seems I was wrong about Chrome and Safari. I was trying wrap='hard' or wrap='soft' with 'white-space: pre', and I was seeing they still wrap the text. But now I removed the wrap attribute completely, and they still wrap the text. So it's not a preference of wrap over white-space. 

I just tested a little more and it seems to be happening because by default they set 'word-wrap: break-word' on textareas. If I change that to 'word-wrap: normal' then the 'white-space: pre' works fine, even with wrap="hard". And they don't seem to ignore wrap="off" either (as it says in comment 28, maybe they fixed it since), they seem to translate that to 'white-space: pre; word-wrap: normal' (as shown in the developer tools). 

It's not clear to me whether the combination 'white-space: pre; word-wrap: break-word' should break lines or not, but as long as I can overwrite them it doesn't matter much. So I think they're fine and if you guys could do the same that would be great. Thanks.

    
    

    
  
Hey, an answer to comment 26.  ;)
Whiteboard: [CSS1-5.6.2][html](py8ieh: check two bugs are filed) → [mentor=bz][lang=c++][CSS1-5.6.2][html](py8ieh: check two bugs are filed)

    
    

    
  
Well, the wrap seems to be working perfectly. no issues. had a problem with execution in IE9, Maybe a style error.

    
    

    
  
Comment on attachment 36296 [details]
simplified testcase

><html>
>  <head><title>TEST</title>
>  <style type="text/css">
>    .p{text-align:justify;}
>    .block{display:block;text-align:justify;}
>  </style>
>  </head>
>  <body>
>    <p>Resize window horizontally, the text in the first textarea stays in "absolute position"</p>
>    BODY BODY BODY BODY BODY BODY BODY BODY BODY    BODY BODY BODY BODY BODY BODY BODY BODY BODY With display:block
>    <form action="about:blank" method="get">
>      <textarea class="block" rows="5" cols="5">TEST TEST TEST TEST</textarea>
>    </form>
>    BODY BODY BODY BODY BODY BODY BODY BODY BODY    BODY BODY BODY BODY BODY BODY BODY BODY BODY Without display:block
>    <form action="about:blank" method="get">
>      <textarea rows="5" cols="5">TEST TEST TEST TEST</textarea>
>    </form>
>  </body>
></html>

    
    

    
  
The text-align:justify; in the .block{} of the <style> seemed to sort the problem in IE.

    
    

    
  
It would be nice if we found somebody to work on this...

    
    

    
  
This is a very annoying bug, especially since it is 12 years old. The CSS white-space property still does not work for textareas (as witness the following tests):

http://www.hixie.ch/tests/evil/mixed/wraptextarea.html
http://people.mozilla.org/~eakhgari/white-space-textarea.html

The only way to turn off wrapping on textareas while remain valid HTML5 are JavaScript hacks like this:

http://stackoverflow.com/questions/657795/how-remove-wordwrap-from-textarea

My advice: ignore what other browsers are doing, and just do the right thing. As Octav Popescu said, 'wrap' values shouldn't override explicit css rules.

    
    

    
  
Hello! I'd like to volunteer to help with this bug. I've spent the last couple of days reading this thread and doing some testing. Before I go any further, I'd like to check in and make sure I'm on the right track.

I created a test matrix of expected behavior based on previous comments in this thread. I broke it down into four test cases for each combination of the white-space property and the wrap attribute:

- whether new lines should be collapsed (i.e. folded) or preserved
- whether spaces and tabs should be collapsed or preserved
- whether text should be wrapped
- whether line breaks should be inserted into text submitted as part of a form

The first three matter when rendering, and the last one matters when submitting a form.

I then took Ehsan Akhgari's test html and added test cases for new lines, spaces, and tabs, and checked the current behavior of each combination of white-space and wrap.

Test matrix & results: https://docs.google.com/spreadsheet/ccc?key=0AkyMHWwZWUKkdDVuZG9TUzRpaExicnpwYzlyWkRvMGc&usp=sharing
Test html: http://pastebin.com/x6CvZxCY - can download and open locally
Server-side echo script: http://pastebin.com/fuSmPrmA

Have I got all that right in the test matrix? I realize it's pretty dense. If that's all correct, and if it's all right for me to take a crack at it, I'll begin working on a patch. Since this is my first bug, any guidance is very much appreciated.

    
    

    
  
johnoilar@gmail.com, thank you for working on that!

Ehsan, want to look over the behavior bits there?  I can try to do it too, but I'm a little swamped with other things I need to catch up on...

At a brief look at the Chromium part of the test matrix, it _almost_ ignores "wrap" values, which seems a bit odd to me.  I would have expected the "wrap" values to do something when white-space is not specified, based on earlier comments in this bug.

I'm happy to give guidance on fixing, once we know what behavior we want for the interaction of the CSS and the attribute.  That will obviously affect the best way to fix this.
Flags: needinfo?(ehsan)

    
    

    
  


  
Flags: needinfo?(ehsan)

    
    

    
  
johnoilar@gmail.com, thanks for your work here so far.  I took a look at your spreadsheet and I'm not sure if I understand the meaning of those pass and fails there.  Can you please try to provide a summary like comment 28?

(That being said, I thought that we decided on using style mapping to implement pre, with word-wrap: break-word for textarea, which is already the case in Gecko?)

    
    

    
  
I've cleaned up the spreadsheet and added a table of just the expected behavior, independent of browser results. The results for each browser are now on separate sheets, and each "fail" simply indicates where the browser's behavior deviates from the table of expected behavior.

I also updated the language in the test matrix to use "preserve" and "collapse" instead of "fold" and "no fold". This matches the language in the CSS3 spec and is hopefully clearer.

For example, when white-space is set to normal, according to the CSS3 spec the expected behavior is to collapse new lines, collapse spaces and tabs, and wrap rendered text. Firefox Nightly preserves new lines instead of collapsing them, so that test fails, and it preserves spaces and tabs, so that test also fails. It does wrap text when rendering, so that test passes.

The big catch is whether that table of expected behavior I made is accurate and if it is really the desired behavior. It's derived from the CSS3 and HTML5 standards mentioned above, but it doesn't take compatibility with other browsers into account.

To summarize the testing results so far:

- Firefox Nightly ignores white-space rules. If wrap=off, textareas render as if white-space: pre, otherwise they render as if white-space: pre-wrap.
- Chromium respects white-space for rendering and wrap for form submission with the following exceptions:
  - It never collapses new lines.
  - word-wrap: break-word is applied to elements with white-space: pre. This seems contrary to what it says at http://www.w3.org/TR/css3-text/#overflow-wrap-property : "[word-wrap] only has an effect when 'white-space' allows wrapping."
  - white-space: nowrap overrides wrap=hard when submitting a form.

I'll test with other browsers and update with results.

    
    

    
  
(In reply to johnoilar from comment #49)
> I've cleaned up the spreadsheet and added a table of just the expected
> behavior, independent of browser results. The results for each browser are
> now on separate sheets, and each "fail" simply indicates where the browser's
> behavior deviates from the table of expected behavior.
> 
> I also updated the language in the test matrix to use "preserve" and
> "collapse" instead of "fold" and "no fold". This matches the language in the
> CSS3 spec and is hopefully clearer.
> 
> For example, when white-space is set to normal, according to the CSS3 spec
> the expected behavior is to collapse new lines, collapse spaces and tabs,
> and wrap rendered text. Firefox Nightly preserves new lines instead of
> collapsing them, so that test fails, and it preserves spaces and tabs, so
> that test also fails. It does wrap text when rendering, so that test passes.

Thanks, I understand your spreadsheet now, but...

> The big catch is whether that table of expected behavior I made is accurate
> and if it is really the desired behavior. It's derived from the CSS3 and
> HTML5 standards mentioned above, but it doesn't take compatibility with
> other browsers into account.

That's the thing.  textarea is a replaced element so this behavior is not really spec'ed anywhere (see comment 33).  Therefore, what we need to do here is to stop looking at the CSS spec, figure out what the behavior of latest versions of all other browsers are here, and try to see if we can come up with a plan which is compatible with most of them, and implement that.  That's why we need more than just Chromium results here (and the Firefox Nightly results don't really matter...)

> To summarize the testing results so far:
> 
> - Firefox Nightly ignores white-space rules.

Yes, this bug tracks changing this to respect white-space somehow.

> If wrap=off, textareas render
> as if white-space: pre, otherwise they render as if white-space: pre-wrap.
> - Chromium respects white-space for rendering and wrap for form submission
> with the following exceptions:
>   - It never collapses new lines.

I think that is sensible.  Collapsing new lines in textareas pretty much breaks the fundamental reason why they exist!

>   - word-wrap: break-word is applied to elements with white-space: pre. This
> seems contrary to what it says at
> http://www.w3.org/TR/css3-text/#overflow-wrap-property : "[word-wrap] only
> has an effect when 'white-space' allows wrapping."

I think what you're seeing here is that Chromium applies word-wrap: break-word to textareas by default, right?  We do the same thing (<http://mxr.mozilla.org/mozilla-central/source/layout/style/forms.css#116>).

>   - white-space: nowrap overrides wrap=hard when submitting a form.

That's good to know.

> I'll test with other browsers and update with results.

Please just document the existing behavior like I had done before and don't pay much attention to what the CSS spec seems to suggest we should do here, because it doesn't really suggest anything.  Thanks!

    
    

    
  
>   - white-space: nowrap overrides wrap=hard when submitting a form.

What happens for display:none elements?  What about elements with display:none ancestors?

The fact that style is affecting semantic behavior like this sounds like it's just a bug to me....  In particular, per spec at http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#attr-textarea-wrap the submission behavior is totally indepenent of style and just depends on @wrap and @cols.  That's the only sane way to define it, in fact.

    
    

    
  
(In reply to comment #51)
> >   - white-space: nowrap overrides wrap=hard when submitting a form.
> 
> What happens for display:none elements?  What about elements with display:none
> ancestors?
> 
> The fact that style is affecting semantic behavior like this sounds like it's
> just a bug to me....  In particular, per spec at
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#attr-textarea-wrap
> the submission behavior is totally indepenent of style and just depends on
> @wrap and @cols.  That's the only sane way to define it, in fact.

Hmm, yeah, I agree...

    
    

    
  
Forgive me if I'm mistaken, but in HTML5 aren't form controls, including textarea, actually non-replaced elements? That's what it seems to indicate here, at least: http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#form-controls. textareas are listed under form controls in the non-replaced elements section, and no mention of them is made in the replaced elements section. This appears to be different from previous versions of HTML.

Regardless, I'm willing to help out with whatever solution is deemed appropriate. I'm testing with Chrome, IE, and Opera now, and I'll have the results up shortly. :)

    
    

    
  
> but in HTML5 aren't form controls, including textarea, actually non-replaced elements?

It's ... complicated.  They're not just normal elements, as you can tell by putting an <img> as a child of a <textarea> and watching it not render.  The spec talks about a magic "binding: textarea;" thing which is supposed to sorta kinda make it non-replaced and then describes the rendering after that in http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-textarea-element-0 where the relevant bit is:

  For historical reasons, if the element has a wrap attribute whose value is an ASCII
  case-insensitive match for the string "off", then the user agent is expected to treat
  the attribute as a presentational hint setting the element's 'white-space' property to
  'pre'.

Note that no mention is made of presentational effects from any other values of @wrap.

It might be that this is good enough, or it might be that the spec needs changing; this is not a very mature part of the spec in the sense of multiple interoperable implementations, by any means.

    
    

    
  
Yeah, and I think that our efforts here will be helpful to make the spec better as well!

    
    

    
  
Yes, I see what you mean about it being complicated, and I appreciate the explanation. Hopefully this data will help, then.

Took me a while to interpret the results, but here are the summaries:

- Chrome, Safari 5, and Opera 18 all behave identically to Chromium.

- IE 11:
 - wrap=off prevents wrapping of text, regardless of white-space.
 - Spaces and tabs are never collapsed.
 - white-space: normal and white-space: nowrap will collapse new lines.
 - word-wrap: break-word is applied to elements with white-space: pre in exactly the same manner as Chrome (with this particular combination of CSS rules, both Chrome and IE break mid-word instead of at a word boundary like they usually do).
 - white-space: nowrap overrides wrap=hard when submitting a form.

Opera 12 behaves as described in comment 28, except I noticed in my testing that the combination of white-space: nowrap and wrap=hard causes text to wrap when rendering. Not sure why.

    
    

    
  
(In reply to Boris Zbarsky [:bz] from comment #51)
> >   - white-space: nowrap overrides wrap=hard when submitting a form.
> 
> What happens for display:none elements?  What about elements with
> display:none ancestors?

Tested in IE 11 and Chrome, and it looks like both browsers behave the same way. If display is none on a textarea or on one of its ancestors, the form is never wrapped, even if wrap=hard.

Here is the test html for reference, and the specific test results are in the spreadsheet:
display:none on textarea - http://pastebin.com/s8j9x9hA
display:none on ancestor div - http://pastebin.com/FR9QeeqU

    
    

    
  
(In reply to johnoilar from comment #56)
> Yes, I see what you mean about it being complicated, and I appreciate the
> explanation. Hopefully this data will help, then.
> 
> Took me a while to interpret the results, but here are the summaries:
> 
> - Chrome, Safari 5, and Opera 18 all behave identically to Chromium.

That is, identical to comment 28, right?

> - IE 11:
>  - wrap=off prevents wrapping of text, regardless of white-space.

I think this is sensible, but it contradicts Chromium's behavior, right?

>  - Spaces and tabs are never collapsed.
>  - white-space: normal and white-space: nowrap will collapse new lines.

That sounds insane to me!

>  - word-wrap: break-word is applied to elements with white-space: pre in
> exactly the same manner as Chrome (with this particular combination of CSS
> rules, both Chrome and IE break mid-word instead of at a word boundary like
> they usually do).

OK so they basically set word-wrap: break in the UA stylesheet.  I think that makes sense.

>  - white-space: nowrap overrides wrap=hard when submitting a form.

I think this doesn't make sense (see comment 51), more on this below.

> Opera 12 behaves as described in comment 28, except I noticed in my testing
> that the combination of white-space: nowrap and wrap=hard causes text to
> wrap when rendering. Not sure why.

The Opera 12 behavior probably won't matter moving forwards because Presto is dead.

(In reply to johnoilar from comment #57)
> (In reply to Boris Zbarsky [:bz] from comment #51)
> > >   - white-space: nowrap overrides wrap=hard when submitting a form.
> > 
> > What happens for display:none elements?  What about elements with
> > display:none ancestors?
> 
> Tested in IE 11 and Chrome, and it looks like both browsers behave the same
> way. If display is none on a textarea or on one of its ancestors, the form
> is never wrapped, even if wrap=hard.

So, they're basically ignoring @wrap when deciding what to submit, and only look at style data.  Sigh :(

So I think if we want to be compatible with one of the two herds, I would probably choose Chromium, but then again I think we should not follow them when deciding what to do in the presence of @wrap when submitting a form.  I may be convinced to ignore @wrap=off when white-space is set.

Boris, what do you think?
Flags: needinfo?(bzbarsky)

    
    

    
  
I haven't been following the details that well; my main thought is that submission behavior should not depend on styles.
Flags: needinfo?(bzbarsky)

    
    

    
  
OK then, let's implement the Chromium's behavior and make sure that submission behavior is only determined by the value of @wrap, not the element's styles.
Mentor: bzbarsky
Whiteboard: [mentor=bz][lang=c++][CSS1-5.6.2][html](py8ieh: check two bugs are filed) → [lang=c++][CSS1-5.6.2][html](py8ieh: check two bugs are filed)

    
    

    
  
(In reply to Alfredos-Panagiotis Damkalis [:fredy] from comment #20)
> Is there any progress on this bug?
> There is a known workaround by adding the attribute wrap="off" but this is a
> non-standard.
> Also the wrap attribute is going to have a different meaning in html5 as you
> can see at http://www.w3schools.com/html5/att_textarea_wrap.asp

I think that link is broken. Try this http://www.w3schools.com/tags/att_textarea_wrap.asp

    
    

    
  


  
This changes the UA stylesheet to allow overriding white-space on textareas, and maps wrap=off to white-space: pre if no white-space value was set.

From the discussion above, it seems like newlines should never be collapsed, even with white-space: normal and nowrap. I'm not sure how to change the behavior of the white-space property just for textareas, though. Boris, do you have any advice regarding that?

        Attachment #8507568 -
        Flags: feedback?(bzbarsky)

    
    

    
  
Comment on attachment 8507568 [details] [diff] [review]
WIP - Support CSS white-space property on textareas

This patch looks great if we want to implement what the spec says.

As far as the collapsing stuff...  I tried a bit of exprimentation in Chrome.  From what I can tell, its behavior is as follows for various values of the white-space property:

pre -- just use it
normal -- treat as pre-line
nowrap -- behavior that can't be described in CSS; in terms of the table in
   http://dev.w3.org/csswg/css-text-3/#white-space-property it preserves
   newlines, collapses spaces and tabs, and does not wrap text.  There is no
   value of white-space that has this behavior.
pre-wrap -- just use it
pre-line -- just use it

The default behavior in Chrome is pre-wrap.

We could reproduce the observed "normal" behavior if we want to by making up a -moz value to style the kid with that inherits the parent's white-space as-is unless it's "normal", in which case it inherits "pre-line".  We have something like that already for <th> elements, albeit without actual syntax.  See http://hg.mozilla.org/mozilla-central/rev/5ab823ef8518 for how that was done.

Reproducing the observed "nowrap" behavior, on the other hand, requires adding new values for white-space and supporting them in layout.  I would rather we did not go there, and just treated "nowrap" like "pre", without collapsing spaces...

        Attachment #8507568 -
        Flags: feedback?(bzbarsky) → feedback+

    
    

    
  
> We could reproduce the observed "normal" behavior if we want to 

Oh, and it's not clear to me that we want to.

    
    

    
  
So I just tested IE 11.  It has the following behavior:

pre -- just use it (albeit with some word-break-like weirdness)
normal -- Not describable via CSS: looks like collapses newlines, preserves spaces, allows
   wrapping.
nowrap -- Not describable via CSS: collases newlines (!), preserves spaces, does not allow
   wrapping.
pre-wrap -- just use it
pre-line -- looks identical to pre-wrap

I also tested a recent WebKit nightly and Safari 7.  They have the following behavior:

pre -- just use it
normal -- just use it
nowrap -- just use it
pre-wrap -- just use it
pre-line -- just use it

I believe Brian's patch should give us the Safari/WebKit behavior, which happens to also be the spec behavior.  I would be totally fine with shipping that and filing bugs on Chrome as needed.

    
    

    
  
(In reply to Boris Zbarsky [:bz] from comment #66)
> I also tested a recent WebKit nightly and Safari 7.  They have the following
> behavior:
> 
> pre -- just use it
> normal -- just use it
> nowrap -- just use it
> pre-wrap -- just use it
> pre-line -- just use it
> 
> I believe Brian's patch should give us the Safari/WebKit behavior, which
> happens to also be the spec behavior.  I would be totally fine with shipping
> that and filing bugs on Chrome as needed.

Thanks for the feedback! That sounds good to me. Ehsan mentioned that collapsing newlines in textareas defeats their purpose. Having the white-space property work as-is with textareas makes sense too, however.

If that's the behavior we're going with, I'll make some reftests for it and update the patch.

    
    

    
  
I think that's the behavior we should go with.  It's simple, it matches the spec, and it seems web-compatible enough if Safari has it.

    
    

    
  


  
Added reftests and rebased after content/ moved to dom/.
Assignee: nobody → bmarsd

        Attachment #8507568 -
        Attachment is obsolete: true
Status: NEW → ASSIGNED

        Attachment #8511696 -
        Flags: review?(bzbarsky)

    
    

    
  
Comment on attachment 8511696 [details] [diff] [review]
Support CSS white-space property on textareas

Thanks for the tests!

I think for the layout reftests it would be better to have one test per value, to avoid issues with tests not being visible in the viewport and hence getting ignored by the screenshot the harness takes.

It might also be good to have two blank lines, not just one, before "This is a long line that could wrap." in those reftests (and adjust the references accordingly) to make sure multiple newlines in a row don't get collapsed when they shouldn't.

>+++ b/layout/style/forms.css
>+input > .anonymous-div,

Blank line before that line, please.

r=me with those nits picked.

        Attachment #8511696 -
        Flags: review?(bzbarsky) → review+

    
    

    
  


  
Thanks for the fast review. Updated the patch.

I removed the `pre` and `pre-wrap` layout reftests, since the reference and non-reference code was identical for them. They preserve all whitespace, so I can't manually collapse whitespace for comparison like I can with the other tests. `pre` and `pre-wrap` are still tested in non-reference files, though.

Asking for another review - could you take a look at the tests again?

        Attachment #8511696 -
        Attachment is obsolete: true

        Attachment #8512347 -
        Flags: review?(bzbarsky)

    
    

    
  
Comment on attachment 8512347 [details] [diff] [review]
Support CSS white-space property on textareas

r=me.

In the pre-wrap/pre-line cases, does it make sense to manually line-wrap the "long line" in the reference to the correct spot?

Might be a bit fragile, so I'm OK not doing that too.

Do you have try access, or should I push this to try?
Flags: needinfo?(bmarsd)

        Attachment #8512347 -
        Flags: review?(bzbarsky) → review+

    
    

    
  
Yeah, manually wrapping might be fine, but I'm not sure how reliable it is.

I don't have try access. If you could push it, that'd be great.
Flags: needinfo?(bmarsd)

    
    

    
  
OK, so try caught a problem: need to #include nsRuleData.h in HTMLTextAreaElement.cpp.  Everything else looks good.
Flags: needinfo?(bmarsd)

    
    

    
  


  
Added nsRuleData.h include. Carrying forward r+.

        Attachment #8512347 -
        Attachment is obsolete: true
Flags: needinfo?(bmarsd)

        Attachment #8512827 -
        Flags: review+

    
    

    
  
Brian, thank you again for fixing this!

    
    

    
  
You're welcome! Thanks for helping me.

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/df77d2235225
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED

    
    

    
  
BTW: With Visual Studio 2012 I get this error on m-c with the patch:
[...]
Unified_cpp_dom_base6.cpp
e:\mozilla\comm-central\mozilla\dom\html\HTMLTextAreaElement.cpp(447) : error C2
601: 'attributes' : local function definitions are illegal
        e:\mozilla\comm-central\mozilla\dom\html\HTMLTextAreaElement.cpp(446): t
his line contains a '{' which has not yet been matched
e:\mozilla\comm-central\mozilla\dom\html\HTMLTextAreaElement.cpp(448) : error C2
143: syntax error : missing ';' before '}'

I can file a new bug if needed (if the bug fix is more complicated).

    
    

    
  
I think that's because of a missing = on HTMLTextAreaElement.cpp:447. It ends up using list initialization by accident, which isn't supported by all compilers. Not sure how I missed that, sorry!

Boris, what's the best way to get a fix checked in? Should I attach it to this bug and ask for review?

    
    

    
  
(See comment 82.)
Flags: needinfo?(bzbarsky)

    
    

    
  
can you post a fix here in the mean time so we can work around this?

    
    

    
  
Normally you'd file a new bug for a followup, but in this case it's a simple build fix and all.

I just checked it in, r=me.  Thank you for posting that!

https://hg.mozilla.org/integration/mozilla-inbound/rev/aec14e7888f0
Flags: needinfo?(bzbarsky)

    
  
Target Milestone: Future → mozilla36

    
    

    
  
(In reply to Jean-Yves Perrier [:teoli] from comment #88)
> I added a note in the compat table:
> https://developer.mozilla.org/en-US/docs/Web/CSS/white-space

The compat table reads as v36 released in 2014. Can you update the year to 2015?

    
    

    
  
(In reply to mlhDevelopment from comment #89)
> The compat table reads as v36 released in 2014. Can you update the year to
> 2015?

Fixed https://developer.mozilla.org/en-US/docs/Template:CompatGeckoDesktop .

    
    

    
  
Is there any chance that this bug is related to why the following site's <textarea> fields don't have line breaks in my Firefox nightly but they do in Chrome?

http://inventwithpython.com/blog/2014/12/02/why-is-object-oriented-programming-useful-with-an-role-playing-game-example/

Firefox Nightly: 37.0a1 (2014-12-02)

    
    

    
  
Presumably, since the site has explicit style="white-space: nowrap" on those textareas.  See comment 63 and comment 66 for what other browsers do here.

The site is broken in IE and Safari for the same exact reason, and I'm willing to claim that the styles it has are just buggy and should be fixed...

    
    

    
  
I see and understand now. Thank you very much for looking at this :bz.

    
  
Depends on: 1137650

    
  
Depends on: 1166335

    
    

    
  
I'm using the newest Firefox and when I press enter I just get a space. Really frustrating!
Website I encounter this bug / issue / problem is www.promo-cloud.com

When I used Firefox 35, enter was a new line. Firefox 36, enter was a space.

Is it possible to investigate this, it's really driving me nutz that I have to use notepad every time to copy paste my feedback on music and talk to the artist(s)!

    
    

    
  
(In reply to MISTERAMD from comment #94)
> Is it possible to investigate this

Given that this bug was fixed end of last year and Firefox now correctly implements the specification and matches other browsers (but not Chrome, which is broken), I think you want to file a (new) web compatibility bug instead.

    
    

    
      
  

    
    

    
      
  

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: