text input with default size are too tall in vertical writing modes

RESOLVED WORKSFORME

Status

()

P3
normal
RESOLVED WORKSFORME
a year ago
9 months ago

People

(Reporter: bugzilla, Unassigned)

Tracking

(Blocks: 1 bug, {testcase})

Trunk
testcase
Points:
---

Firefox Tracking Flags

(firefox57 affected)

Details

Attachments

(10 attachments)

(Reporter)

Description

a year ago
Tests
-----

http://www.gtalbot.org/BugzillaSection/input-text-too-tall-vrl.html

http://www.gtalbot.org/BugzillaSection/input-text-too-tall-vlr.html


Actual results in Firefox 57.0a1 buildID=20170804193726
- - - - - - - - - - - - - - - - - - - - - - - - - - -
The used content height of the text inputs is 545px. 


Expected results
- - - - - - - -
When I set 'writing-mode' to 'horizontal-tb', then the used content width of the text inputs is 263px. Therefore, I would expect that the used content height of the text inputs would also be 263px. Otherwise, it should be tall enough to display 20 characters. 20 characters being the default number of characters according to HTML5.


Notes
-----
- 
"
The size attribute gives the number of characters that, in a visual rendering, the user agent is to allow the user to see while editing the element's value.
(...)
The size IDL attribute (...) has a default value of 20.
"
HTML 5, section 4.10.5.3.2 The size attribute
https://html.spec.whatwg.org/multipage/input.html#the-size-attribute
- I now remember that I intentionally set size to 12 in this test:
http://test.csswg.org/suites/css-writing-modes-3_dev/nightly-unstable/html/form-controls-vrl-005.htm
because of this bug
- I use Linux 4.10.0-30-generic x86_64, Qt: 5.7.1, KDE 4.14.30; Kubuntu (zesty) 17.04
- I've searched for duplicates and did not find any.
(Reporter)

Updated

a year ago
Blocks: 145503
Keywords: testcase
Priority: -- → P3
Seems this works for now.
Flags: needinfo?(bugzilla)
I see expected results in both Firefox 58 and Firefox 60a Nightly Build on Linux.
(In reply to Gérard Talbot from comment #0)

> Expected results
> - - - - - - - -
> When I set 'writing-mode' to 'horizontal-tb', then the used content width of
> the text inputs is 263px. Therefore, I would expect that the used content
> height of the text inputs would also be 263px.

Actually, I think this expectation is mistaken, for the example here. The sizing of the input element is based on the average character advance for the chosen font, but in vertical writing-mode this is likely to be considerably greater than in horizontal mode.

If text-orientation:sideways is applied to the element, I'd expect the height of the vertical <input> to be the same as the width of a horizontal one. But if not, then we assume the vertical writing-mode element is intended primarily for CJK text, which will be rendered with upright glyphs. And so the average character advance will generally be about 1em, whereas in horizontal text it will usually be much less.
(In reply to Jonathan Kew (:jfkthame) from comment #3)
> (In reply to Gérard Talbot from comment #0)
> 
> > Expected results
> > - - - - - - - -
> > When I set 'writing-mode' to 'horizontal-tb', then the used content width of
> > the text inputs is 263px. Therefore, I would expect that the used content
> > height of the text inputs would also be 263px.
> 
> Actually, I think this expectation is mistaken, for the example here. The
> sizing of the input element is based on the average character advance for
> the chosen font, but in vertical writing-mode this is likely to be
> considerably greater than in horizontal mode.
> 
> If text-orientation:sideways is applied to the element, I'd expect the
> height of the vertical <input> to be the same as the width of a horizontal
> one. But if not, then we assume the vertical writing-mode element is
> intended primarily for CJK text, which will be rendered with upright glyphs.
> And so the average character advance will generally be about 1em, whereas in
> horizontal text it will usually be much less.

Right now, the <input> height in vertical mode is exactly the same as in horizontal mode, so it works from the point of view of the bug report. It must have been fixed in some other bug unknowingly.

I tested the vertical <input> in the default size, it can barely fit in 22 Chinese characters in the default text size, the font I use is Noto Sans CJK, other fonts with slightly taller height might fail the "20-character" principle. So I agree that the expectation is to default the vertical height to a bit taller then the horizontal one.

Having said that, the actual result as Gérard mentioned, was really too tall when he filed this bug.

Comment 5

10 months ago
Yes, this issue is exists now.
The height (width?) of input at vertical mode about three times taller than at horizontal mode.
And, the width ( height? ) of the td (tr?) is unusual too.

http://www.mongolfont.com/test/firefox/input.html

Comment 6

10 months ago
Created attachment 8955964 [details]
HeightOfInputInVetticalMode.png

Firefox Quantum 58.0.2 (64 ビット) on Windows 7 Ultimate.
(In reply to siqinbilige from comment #6)
> Created attachment 8955964 [details]
> HeightOfInputInVetticalMode.png
> 
> Firefox Quantum 58.0.2 (64 ビット) on Windows 7 Ultimate.

The results from my Firefox 58 on Linux differ slightly from yours even if we're using the same font face. So at least we can confirm that an <input>s' default inline-based size doesn't depend on, or depends not only on the estimated character advance for the chosen font.
Created attachment 8955978 [details]
my results on siqinbilige's testcase.png

The three vertical <input>s differ slightly from those for siqinbilige
(Reporter)

Comment 9

9 months ago
(In reply to Zhang Junzhi from comment #1)
> Seems this works for now.

As far as I can see, this bug report has been fixed and should be resolved as WORKSFORME.


- - - - - - - 


(In reply to siqinbilige from comment #5)
> Yes, this issue is exists now.
> The height (width?) of input at vertical mode about three times taller than
> at horizontal mode.

I do not see that on Linux with Firefox 60.0a1 buildID=20180305100134. The rendered layout I get is very close to attachment 8955978 [details]. Also, in your code,
<input type="text" value="chinese:中文" list="cnList">
will not necessarly be using a font-size of 18px. And so, this can affect width and height of rendered inputs.

> And, the width ( height? ) of the td (tr?) is unusual too.
> 
> http://www.mongolfont.com/test/firefox/input.html

First, we have several bug reports on tables and table cells. So, when creating a reduced test on inputs, you want to avoid using elements or code scenarios that are known to trigger bugs.

Second, please always use a doctype declaration (in tests but also in all your webpages) so that you always trigger the web standards compliant rendering mode (the best rendering mode) in all browsers (not just Firefox). I usually and normally use
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
but you can use
<!DOCTYPE html>
to trigger web standards compliant rendering mode in all browsers. More on this:
What are the Quirks mode and the Standards mode?
https://developer.mozilla.org/en-US/docs/Mozilla/Mozilla_Web_Developer_FAQ#What_are_the_Quirks_mode_and_the_Standards_mode.3F
You can use Tools/Information on the page (Ctrl+I)/General tab to see in which rendering mode your page is rendered.

Third, do not use -webkit- vendor prefix anymore: this is no longer needed anymore (for Chrome browsers) since november 2015:
Issue 533448: Unprefixed CSS Writing Modes with syntax updates
https://bugs.chromium.org/p/chromium/issues/detail?id=533448

Fourth: 'writing-mode: tb-rl;'
is only or mostly good for IE11. Recent versions of MS-Edge (version 15, 16 and 17) support the 'writing-mode: vertical-rl'. So, 'writing-mode: tb-rl;' and 'writing-mode: tb-lr;' should not be used unless you really want to test IE11.


- - - - - - - 


(In reply to Jonathan Kew (:jfkthame) [PTO, 5-16 Mar] from comment #3)

> this expectation is mistaken, for the example here. The
> sizing of the input element is based on the average character advance for
> the chosen font, but in vertical writing-mode this is likely to be
> considerably greater than in horizontal mode.

I agree.

> If text-orientation:sideways is applied to the element, I'd expect the
> height of the vertical <input> to be the same as the width of a horizontal
> one. 

I will create a pair of tests on that later.

> But if not, then we assume the vertical writing-mode element is
> intended primarily for CJK text, which will be rendered with upright glyphs.
> And so the average character advance will generally be about 1em, whereas in
> horizontal text it will usually be much less.
Flags: needinfo?(bugzilla)
(Reporter)

Comment 10

9 months ago
> please always use a doctype declaration (in tests but also in all your webpages) so that you always trigger
> the web standards compliant rendering mode (the best rendering mode) in all browsers (not just Firefox).

Choosing the right doctype for your HTML documents: Doctype switching and rendering modes
https://www.w3.org/wiki/Choosing_the_right_doctype_for_your_HTML_documents#Doctype_switching_and_rendering_modes


> You can use Tools/Information on the page (Ctrl+I)/General tab to see in which rendering mode your page is rendered.
This is what I mean:
https://support.mozilla.org/en-US/kb/firefox-page-info-window#w_general

Comment 11

9 months ago
(In reply to Gérard Talbot from comment #9)
> (In reply to Zhang Junzhi from comment #1)
> > Seems this works for now.
> 
> As far as I can see, this bug report has been fixed and should be resolved
> as WORKSFORME.

Thank you for your explanations and advice.
I added doctype to my samples.
The Length(or width) that does not match on mac.png and windows.png are my font problem ?

Comment 12

9 months ago
Created attachment 8956341 [details]
mac.png

Comment 13

9 months ago
Created attachment 8956342 [details]
windows.png
(Reporter)

Comment 14

9 months ago
Siqinbilige,

You can safely remove -webkit- vendor prefix from your tests and all of your webpages on your website: there is no need for that. Btw, most of your webpages on your website have line 5: <html dir="ltr" lang="en-US"> when it definitely should not; it definitely should use lang="mn".

- - - - - - -

Please remove 
line 23: -webkit-text-orientation: sideways-right;
Although it does not do anything in your 
http://www.mongolfont.com/test/firefox/input.html
it should not be in the test.

- - - - - - -

I examined your mac.png versus windows.png screenshot and there is - indeed - a strange difference of width (narrower in mac, wider in windows) for the mongolian (horizontal) input at bottom of page. Also, the vertical mongolian input is smaller on mac than on windows. I do not have and do not use Mac OS X. I do not have and do not use Windows. So I can not comment nor investigate on such differences. And such differences do not seem awkward or illogical or undesirable.

- - - - - - -

One other thing. I do not know what datalist HTML attribute does in your code. Is your datalist HTML attribute really important or determinant in your test? If so, then you may want to change

line 68: <input type="text" style="font-size : 20px;" value="japanese:日本語" list="cnList"><br>
line 69: <input type="text" style="font-size : 20px;font-family: 'Mongolian White', Serif;" value="mongolian:ᠣᠢᠭᠤᠷᠵᠢᠨ ᠮᠣᠩᠭᠤᠯ" list="cnList">

for

line 68: <input type="text" style="font-size : 20px;" value="japanese:日本語" list="jpList"><br>
line 69: <input type="text" style="font-size : 20px;font-family: 'Mongolian White', Serif;" value="mongolian:ᠣᠢᠭᠤᠷᠵᠢᠨ ᠮᠣᠩᠭᠤᠯ" list="mnList">

- - - - - - -

If you toggle the font-size in developer tools, this may avoid/prevent the table cells from overlapping. It does under my Linux system.
(Reporter)

Comment 15

9 months ago
Created attachment 8956365 [details]
mongolfont-firefox60-input.png

Screenshot of mongolfont.com/test/firefox/input.html with Firefox 60.0a1 buildID=20180305220117 under Linux Debian (stretch) 9.4

I toggled one of the font-size declaration in developer tools to help render the table cells (no overlapping).
(Reporter)

Comment 16

9 months ago
Unless I hear objections, I will resolve this bug report as WORKSFORME in 5 days, on march 11th.
(Reporter)

Comment 17

9 months ago
(In reply to siqinbilige from comment #11)
> The Length(or width) that does not match on mac.png and windows.png are my
> font problem ?

It could be the font size and/or (just an hypothesis) it could be also how the browser handle, manage the default size of 20 characters when 2 different fonts are involved. Your test has both latin-based graphems and asian-based graphems.
(In reply to Gérard Talbot from comment #17)
> (In reply to siqinbilige from comment #11)
> > The Length(or width) that does not match on mac.png and windows.png are my
> > font problem ?
> 
> It could be the font size and/or (just an hypothesis) it could be also how
> the browser handle, manage the default size of 20 characters when 2
> different fonts are involved. Your test has both latin-based graphems and
> asian-based graphems.

I don't think the specific characters in the input field are relevant; the width is based on the browser's idea of "average character width" for the default font (as specified in CSS, or browser defaults if not explicitly set; note that these defaults may be affected by lang).

Exactly how the "average" is calculated -- and therefore the resulting element size -- is quite variable between browsers. As a simple testcase (using fonts typically available on macOS), I tried:

data:text/html,<input style="font-family:impact"><br>
               <input style="font-family:avant garde"><br>
               <input style="font-family:american typewriter"><br>
               <input style="font-family:marker felt">

in Firefox, Safari, and Chrome; and the resulting widths of the input elements vary in quite different ways across the three browsers.
Created attachment 8956378 [details]
screenshot of comment 18 example, in Firefox / Safari / Chrome

Here's a screenshot showing how variable the <input> size is, across different fonts and browsers.
The above example is of course just horizontal, but as already noted, the same considerations apply in vertical mode: the size will be based on the browser's idea of an average character advance -- which will depend on the font specified (or default) -- with the added factor that average advance for vertical (upright) layout is generally much larger than horizontal.
(Reporter)

Comment 21

9 months ago
(In reply to Jonathan Kew (:jfkthame) [PTO, 5-16 Mar] from comment #3)

> If text-orientation:sideways is applied to the element, I'd expect the
> height of the vertical <input> to be the same as the width of a horizontal
> one.

This is the case with Firefox 60.0a1 buildID=20180306100123 and with Firefox 52.6.0 ESR with these 2 tests:

http://www.gtalbot.org/BugzillaSection/input-text-too-tall-vrl-002.html

http://www.gtalbot.org/BugzillaSection/input-text-too-tall-vlr-002.html

Comment 22

9 months ago
(In reply to Gérard Talbot from comment #14)
> Siqinbilige,
> 
> You can safely remove -webkit- vendor prefix from your tests and all of your
> webpages on your website: there is no need for that. Btw, most of your
> webpages on your website have line 5: <html dir="ltr" lang="en-US"> when it
> definitely should not; it definitely should use lang="mn".

There are two Mongolain language mn(traditional mongolian which means on this site) and mn-MN(cyrillic mongolian which used in Mongolia).
I do not know how far it is implemented.

-webkit-writing-mode: vertical-lr;
removed.

> Please remove 
> line 23: -webkit-text-orientation: sideways-right;
> Although it does not do anything in your 
> http://www.mongolfont.com/test/firefox/input.html
> it should not be in the test.

I can not remove -webkit-text-orientation: sideways-right;
Because it needed in Webkit based browsers like safari and opera for traditional mongolian.
If no this the glyph will not rotated clockwise 90deg.
See div.png and div2.png

> One other thing. I do not know what datalist HTML attribute does in your
> code. Is your datalist HTML attribute really important or determinant in
> your test? If so, then you may want to change
> 
> line 68: <input type="text" style="font-size : 20px;" value="japanese:日本語"
> list="cnList"><br>
> line 69: <input type="text" style="font-size : 20px;font-family: 'Mongolian
> White', Serif;" value="mongolian:ᠣᠢᠭᠤᠷᠵᠢᠨ ᠮᠣᠩᠭᠤᠯ" list="cnList">
> 
> for
> 
> line 68: <input type="text" style="font-size : 20px;" value="japanese:日本語"
> list="jpList"><br>
> line 69: <input type="text" style="font-size : 20px;font-family: 'Mongolian
> White', Serif;" value="mongolian:ᠣᠢᠭᠤᠷᠵᠢᠨ ᠮᠣᠩᠭᠤᠯ" list="mnList">

I wanted to test the list attribute which still not working well on vertical mode of input.
datalist.png

Comment 23

9 months ago
Created attachment 8956678 [details]
div.png

Comment 24

9 months ago
Created attachment 8956679 [details]
div2.png

Comment 25

9 months ago
Created attachment 8956680 [details]
datalist.png
(Reporter)

Comment 26

9 months ago
(In reply to siqinbilige from comment #22)

> There are two Mongolain language mn(traditional mongolian which means on
> this site) and mn-MN(cyrillic mongolian which used in Mongolia).

The country code MN is not as important as the language code mn. The language code mn is really important for search indexing.

> I do not know how far it is implemented.
> 
> -webkit-writing-mode: vertical-lr;
> removed.
 
The overall language of your webpages and website is "mn". 
You should use lang="en" to indicate a change to english language.
Authoring HTML: Language declarations
3. Declaring the overall language of a page
4. Identifying in-document language changes
https://www.w3.org/TR/i18n-html-tech-lang/#overall

> > Please remove 
> > line 23: -webkit-text-orientation: sideways-right;
> > Although it does not do anything in your 
> > http://www.mongolfont.com/test/firefox/input.html
> > it should not be in the test.
> 
> I can not remove -webkit-text-orientation: sideways-right;
> Because it needed in Webkit based browsers like safari and opera for
> traditional mongolian.

1- Then this should definitely be reported as a bug over at webkit.
This is https://bugs.webkit.org/show_bug.cgi?id=112488 , correct?
2- Have you tried
text-orientation: sideways;
or
-webkit-text-orientation: sideways;
instead?
3- You may want to add a comment in your code so that people trying to create a webpage in mongolian will know about this. Example given:
line 23: -webkit-text-orientation: sideways-right; /* required for Opera 40+ and Safari 8+ ; see bugs.webkit.org/show_bug.cgi?id=112488 */

> If no this the glyph will not rotated clockwise 90deg.
> See div.png and div2.png

Comment 27

9 months ago
(In reply to Gérard Talbot from comment #26)
> (In reply to siqinbilige from comment #22)
> 
> > There are two Mongolain language mn(traditional mongolian which means on
> > this site) and mn-MN(cyrillic mongolian which used in Mongolia).
> 
> The country code MN is not as important as the language code mn. The
> language code mn is really important for search indexing.

Actually, there are two Mongolian Languages.

  1. Traditional Mongolian ( classic ? ) which we talked now mainly used in Inner Mongolian of China.
    U+1800 - U+18AF ( Including Monglian(U+1820-U+1842), Todo, Manchu, Sibe and Aligali )

  2. Cryllic Mongolian ( New Mongolian ) which used in Monglia.
     U+0400 – U+04FF

We do not clearly know the mn pointing to which one.

> 1- Then this should definitely be reported as a bug over at webkit.
> This is https://bugs.webkit.org/show_bug.cgi?id=112488 , correct?
Yes.

> 2- Have you tried
> text-orientation: sideways;
> or
> -webkit-text-orientation: sideways;
> instead?
I tried the text-orientation: sideways-right; on latest version of browsers.
It seems to worked well.

> 3- You may want to add a comment in your code so that people trying to
> create a webpage in mongolian will know about this. Example given:
> line 23: -webkit-text-orientation: sideways-right; /* required for Opera 40+
> and Safari 8+ ; see bugs.webkit.org/show_bug.cgi?id=112488 */
I will.

Comment 28

9 months ago
Created attachment 8957037 [details]
mongol.png
(Reporter)

Comment 29

9 months ago
(In reply to Gérard Talbot from comment #26)
> (In reply to siqinbilige from comment #22)
> 
> > There are two Mongolain language mn(traditional mongolian which means on
> > this site) and mn-MN(cyrillic mongolian which used in Mongolia).

I knew about this but forgot.

"
Today, Mongolian is written using the Cyrillic alphabet, although in the past it was written using the Mongolian script. An official reintroduction of the old script was planned for 1994, but has not taken place as older generations encountered practical difficulties. The traditional alphabet is being slowly reintroduced through schools.
"
https://en.wikipedia.org/wiki/Mongolia#Languages
This is where your fonts and website could or would (or will?) do a difference.


"
Traditional Mongolian script (in China),
Mongolian Cyrillic alphabet (in Mongolia),
"
https://en.wikipedia.org/wiki/Mongolian_language

> The country code MN is not as important as the language code mn. The
> language code mn is really important for search indexing.
> 
> > I do not know how far it is implemented.

lang="mn-CN" for Mongolian Traditional script (and for your website) and 
lang="mn-MN" for Mongolian Cyrillic then?

https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#CN

https://en.wikipedia.org/wiki/List_of_ISO_639-2_codes#M

Comment 30

9 months ago
(In reply to Gérard Talbot from comment #29)
> (In reply to Gérard Talbot from comment #26)
> > (In reply to siqinbilige from comment #22)

> lang="mn-CN" for Mongolian Traditional script (and for your website) and 
> lang="mn-MN" for Mongolian Cyrillic then?
> 
> https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#CN
> 
> https://en.wikipedia.org/wiki/List_of_ISO_639-2_codes#M

Actually, I do not clearly know.
I think that specification is completely different.
Because, one is vertical and other is horizontal.
(Reporter)

Comment 31

9 months ago
A few min. ago, I asked Elika Etemad what would be the best way to tell, to indicate to a web browser to use the Mongolian Traditional script. She said to make sure you have

html { writing-mode: vertical-lr; } 

And if you use U+1800 - U+18AF characters in the page, then the browser should know how to handle correctly all of this.

Comment 32

9 months ago
(In reply to Gérard Talbot from comment #31)
> A few min. ago, I asked Elika Etemad what would be the best way to tell, to
> indicate to a web browser to use the Mongolian Traditional script. She said
> to make sure you have
> 
> html { writing-mode: vertical-lr; } 
> 
> And if you use U+1800 - U+18AF characters in the page, then the browser
> should know how to handle correctly all of this.

Thank you.
If all of the pages are use Traditional Mongolian ( U+1800 - U+18AF ), it is a best way, I think.
(Reporter)

Updated

9 months ago
Status: NEW → RESOLVED
Last Resolved: 9 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.