Bug 257682 – WPT Test 'wrap-enumerated-ascii-case-insensitive.html' depends on 'font-family: monospace' UA rule

• Component: Forms
• Status: NEW

[Ahmad Saleem]

Hi Team,

While trying to see differences in textarea font, I realised that we don't have below in UA stylesheet for 'textarea':

font-family: monospace;

But it is also not in spec (HTML > Rendering section) but Blink does have it in their UA stylesheet but Firefox does not but they do have mono-spaced font (IMO).

While doing local testing and then adding above, it seems that it leads to passing following WPT test (test depending on 'font'?):

WPT Test: https://wpt.fyi/results/html/semantics/forms/the-textarea-element?label=master&label=experimental&aligned=&q=wrap+enumerated

Live Link (Test): http://wpt.live/html/semantics/forms/the-textarea-element/wrap-enumerated-ascii-case-insensitive.html

Just wanted to raise it so if we need to add 'font-family: monospace' to fix the testcase or we have any rationale to stay away from this.

Thanks!

[Anne van Kesteren]

When wrapping is enforced to some column width, it shouldn't really matter what font is being used. If we use a layout code path for determining the break points it might make sense to pretend monospace is in use there, but we shouldn't have to change the test or our UA style sheet I think.

[Ahmad Saleem]

(In reply to Anne van Kesteren from comment #1)
> When wrapping is enforced to some column width, it shouldn't really matter
> what font is being used. If we use a layout code path for determining the
> break points it might make sense to pretend monospace is in use there, but
> we shouldn't have to change the test or our UA style sheet I think.

Then should we consider this as known WPT failure? I think if the test is depending on font-family being monospace but it is not mandated by spec to have monospace, should we update WPT. Although, if monospace is by spec then we should update our UA stylesheet and as a result, get win on this test?

I looked into code side and we are using 'equalIgnoringLetters...' similar to Chrome / Blink, which progressed for them and only difference seems to be this.

Just trying to understand how should we go about this? Sorry, web-spec is not my strong side and still need to learn a lot. Sorry for just asking more questions.

[Karl Dubost]

Good catch Ahmad,
The test is also failing on Firefox. 

It was created during this commit 
https://github.com/web-platform-tests/wpt/commit/4d00984a61358a8c3a743f60cb49ccc1ccffeae4

which is tied to https://codereview.chromium.org/2811793004/patch/1/10109
and related to https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt


Adding this to the test make it pass in Safari, but still fails in Firefox.
<style>textarea {font-family: monospace;}</style>

Firefox has a number of issues with textarea wrapping 
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=textarea+wrap


https://github.com/web-platform-tests/wpt/blob/e5d3dd0d81879bd700149fc6cd2873a458ed1a56/html/semantics/forms/the-textarea-element/wrap-enumerated-ascii-case-insensitive.html#L26-L39

https://html.spec.whatwg.org/multipage/form-elements.html#attr-textarea-wrap

Maybe Myles has a better answer on the source of the issue.

[Myles C. Maxfield]

I see what's happening. The test is setting cols=7, and expecting that this will cause "hello world" to have a line break in it. This is totally bogus with a proportional-width font, like system-ui which we use.

I don't think we should change the look of text areas in WebKit just because of a WPT test failure. I think we should update the test to just add:

```
textarea {
    font-family: monospace;
}
```

instead.

Firefox's failure looks real: their <textarea>s have the line break, but they're failing the test anyway.

[Ahmad Saleem]

(In reply to Myles C. Maxfield from comment #4)
> I see what's happening. The test is setting cols=7, and expecting that this
> will cause "hello world" to have a line break in it. This is totally bogus
> with a proportional-width font, like system-ui which we use.
> 
> I don't think we should change the look of text areas in WebKit just because
> of a WPT test failure. I think we should update the test to just add:
> 
> ```
> textarea {
>     font-family: monospace;
> }
> ```
> 
> instead.
> 
> Firefox's failure looks real: their <textarea>s have the line break, but
> they're failing the test anyway.

Thanks Myles. I will raise an issue on WPT or if possible, would do PR. Although if someone else want to do PR for WPT, please go ahead.

[Anne van Kesteren]

Myles, why is it bogus? The HTML Standard specifies:

> If the element's wrap attribute is in the Hard state, insert U+000A LINE FEED (LF) characters into the string using an implementation-defined algorithm so that each line has no more than character width characters. For the purposes of this requirement, lines are delimited by the start of the string, the end of the string, and U+000A LINE FEED (LF) characters.

And "character width" here is defined as a number and is meant as such, not as a CSS width.

[Myles C. Maxfield]

Ah, I read “width” as in the width CSS property, which describes lengths.

What is the purpose of this attribute? I can’t imagine why anyone would want this behavior.

[Anne van Kesteren]

I was recently asked by someone to wrap my commit messages. It's essentially for that. Text-based exchange of information that is wrapped by the browser rather than the server. It's an old and a somewhat dated feature, but that's how it's supposed to work.

[Myles C. Maxfield]

Ok.

In that case, this is a real bug, we shouldn’t update the test, and the fact that a change of font causes the test to pass is also just part of the bug. Sounds like we shouldn’t use font width to determine where to insert line breaks.

[Radar WebKit Bug Importer]

<rdar://problem/110588811>

[Ahmad Saleem]

Issue seems to be here - https://searchfox.org/wubkat/rev/904d209b92e989c17e5133a96c75eb75d2941d5a/Source/WebCore/html/HTMLTextFormControlElement.cpp#811