Last Comment Bug 282126 - What to do about the 'ch' length unit? (Mozilla vendor specific)
: What to do about the 'ch' length unit? (Mozilla vendor specific)
Status: NEW
: css-moz
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: -- normal with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 363573 363706 371043
Blocks: css3-values 281630
  Show dependency treegraph
 
Reported: 2005-02-13 08:06 PST by Mats Palmgren (:mats)
Modified: 2013-04-02 11:58 PDT (History)
15 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Mats Palmgren (:mats) 2005-02-13 08:06:20 PST
What to do about the 'ch' length unit? (Mozilla vendor specific)

(Followup from bug 281972)

The only real internal dependence is:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/html/content/src/nsHTMLPreElement.cpp&rev=1.63&root=/cvsroot&mark=127,145,146#125

That is, to wrap a <pre> exactly at the number of characters specified by
WIDTH (or COLS) we need a unit that is based on the width of a character
in the current font.

The problem is that all the relative widths that are font based are
relative the height, not the width:
http://www.w3.org/TR/CSS21/syndata.html#length-units
http://www.w3.org/TR/2001/WD-css3-values-20010713/#lengths

So, to get rid of this Mozilla vendor unit I see two options.
1. convince the CSS working group that 'ch' is needed
2. remove it and introduce a "nsPreFrame" that looks at the
   WIDTH/COLS attr to set its width during reflow (similar to what
   nsTextControlFrame does).
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/forms/nsTextControlFrame.cpp&rev=3.191&root=/cvsroot&mark=1583,1606,1607#1582

http://lxr.mozilla.org/mozilla/search?string=eStyleUnit_Chars
http://lxr.mozilla.org/mozilla/search?string=eCSSUnit_Char
http://lxr.mozilla.org/mozilla/search?string=eCSSKeyword_ch
Comment 1 Anne (:annevk) 2005-02-13 08:17:35 PST
It has been proposed:
 <http://lists.w3.org/Archives/Public/www-style/1999Dec/0026.html>

(I could not find any other emails about it.)
Comment 2 Mats Palmgren (:mats) 2005-02-13 09:42:54 PST
I suppose this is an alternative as well:
3. drop the 'ch' keyword and only use eCSSUnit_Char internally
Comment 3 David Baron :dbaron: ⌚️UTC+1 (busy September 14-25) 2005-02-13 11:00:01 PST
Or (a variant of (3)) we could rename it to -moz-ch to allow round-tripping.

That said, it's needed to allow the cascade to work correctly, and we should
probably be using it for input and textarea as well for exactly that reason.
Comment 4 Mats Palmgren (:mats) 2005-02-13 13:53:04 PST
I agree with the cascade argument, but input and textarea is using
nsIFontMetrics::GetAveCharWidth() rather than the width of a 'M',
so it's not the same measure. Hm, -moz-avg-ch perhaps? 
Comment 5 Mats Palmgren (:mats) 2005-02-13 14:38:16 PST
Given that 'ch' is only intended for use with fixed width fonts at the moment,
I suppose we could change this:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsHTMLReflowState.cpp&rev=1.218&root=/cvsroot&mark=2277,2294-2306#2276

to use nsIFontMetrics::GetAveCharWidth() instead.
I think it's reasonable to expect it to be equal to the width of a 'M' in a
fixed width font, yes?

If so, we can use it for input and textarea too.

Also, I would like length units to be universal, at the moment 'ch' can't
be used to specify 'height' for example (it results in zero height).
Comment 6 Boris Zbarsky [:bz] (TPAC) 2005-02-13 22:23:03 PST
So there are two issues here:

1)  Should we have an internal "ch" unit that we use for <pre> and <input>?  I
think the answer is yes.

2)  Should this be accessible from CSS stylesheets (that is, parsed)?  I think
the answer here should be "not unless it's a -moz unit".

For the rest, having this work for all lenths could be interesting -- the "ch"
unit depends on the font metrics, which depend on the lang group, which comes
from the "visibility" struct.  But we have lengths in the "display" struct,
which makes "display" depend on "visibility".  I don't think that's desirable
(and I'm not sure it doesn't introduce a circular dependency).  Also, should
"ch" do all the weirdness that nsTextControlFrame does right now for
non-fixed-width fonts?  I suspect it should...
Comment 7 Ng Ming Hong 2005-02-13 23:34:56 PST
If there is a "ch" unit, what will be the impact to characters that is wider
than "M", especially double-byte characters. Consider this:
<pre style="width: 10ch">
1234567890
&#19968;&#20108;&#19977;&#22235;&#20116;&#20845;&#19971;&#20843;&#20061;&#21313;
</pre>

Should Mozilla wraps the second line at "&#20116;" or "&#20845;" (around the tenth charcter
on the first line), or "&#21313;" (exactly the tenth character)?

If it is the former case, maybe it should be name "byte" so as to reflect the
fact that it is not counting character-width but byte-width.
Comment 8 Boris Zbarsky [:bz] (TPAC) 2005-02-14 10:09:08 PST
> If there is a "ch" unit, what will be the impact to characters that is wider
> than "M"

That's up to the GetAveCharWidth implementation in the relevant nsIFontMetrics.
 You can test it using <input size="10">, since that already uses the function.
 And yes, this should be counting characters, not bytes.

Comment 9 David Baron :dbaron: ⌚️UTC+1 (busy September 14-25) 2005-02-14 12:38:34 PST
The algorithm used by text inputs handles both fixed-width and proportional
fonts.  Perhaps something like that algorithm would provide a reasonable
definition for 'ch' for all cases?

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/forms/nsTextControlFrame.cpp&rev=3.191&mark=1602-1644#1582
Comment 10 David Baron :dbaron: ⌚️UTC+1 (busy September 14-25) 2005-02-14 12:40:13 PST
(In reply to comment #6)
> For the rest, having this work for all lenths could be interesting -- the "ch"
> unit depends on the font metrics, which depend on the lang group, which comes
> from the "visibility" struct.  But we have lengths in the "display" struct,
> which makes "display" depend on "visibility".  I don't think that's desirable
> (and I'm not sure it doesn't introduce a circular dependency).

Yeah, this is a problem.  I've said a few times that the CSS WG should have a
dependency map for computed value calculation.  We probably need to do the same,
and make sure that we don't get dependencies across structs.
Comment 11 neil@parkwaycc.co.uk 2005-03-27 15:29:40 PST
The rationale for bug 281630 which this bug has been marked as blocking is that
although the default Windows and Linux UI fonts are reasonably similar so that
dialogs designed on one work on the other their aspect ratio and that of the
default Mac UI font differ sufficiently for us to have had to put various hacks
into e.g. the preferences and account manager windows to size them appropriately
which a native "ch" (or whatever) unit would have accomplished automatically.

Of course the bug also affects people who change their UI font to something
sufficiently dissimilar but they've currently just had to live with it.
Comment 12 Mats Palmgren (:mats) 2006-12-13 06:08:58 PST
"CSS3 Values and Units" now includes a 'ch' unit:
http://www.w3.org/TR/css3-values/#relative0

Should we morph this bug into a meta bug with dependencies to the bugs that
handles the specific errors?
Comment 13 David Baron :dbaron: ⌚️UTC+1 (busy September 14-25) 2007-05-03 16:27:48 PDT
css3-values says:

  The width of the "0" (ZERO, U+0030) glyph found in the font for the font size used to render. If the "0" glyph is not found in the font, the average character width may be used.

AddCoord in nsFrame.cpp and GetAbsoluteCoord in nsLayoutUtils.cpp use the width of the "M".

nsTextControlFrame::CalcIntrinsicSize does something more complicated, "for compatibility with IE".

(If my memory is correct, the wording in css3-values is there because it's what the IE folks said IE does.  So it might be even more compatible with IE.)
Comment 14 David Baron :dbaron: ⌚️UTC+1 (busy September 14-25) 2007-05-03 21:07:00 PDT
Oh, and nsTextControlFrame::CalcIntrinsicSize also accounts for letter-spacing, which is harder on a unit...
Comment 15 Zack Weinberg (:zwol) 2008-06-01 15:14:01 PDT
See patches just added to bug 363706 - we could make CalcIntrinsicSize use GetZeroOrAveCharWidth() instead and possibly take out some of the "for IE compatibility" complications.
Comment 16 j.j. 2009-02-16 05:21:58 PST
Isn't this fixed with bug 363706?
Comment 17 Boris Zbarsky [:bz] (TPAC) 2009-02-16 05:41:03 PST
Not really, no.

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