Closed Bug 77882 Opened 21 years ago Closed 11 years ago

getComputedStyle returns incorrect font-weight value if |font-weight:bolder| or |font-weight:lighter|


(Core :: DOM: CSS Object Model, defect, P4)






(Reporter: glazou, Assigned: dbaron)



(Keywords: css2, dom2, testcase, Whiteboard: WG)


(1 file)

If |font-weight:bolder| or |font-weight:lighter| is applied to an element, the
computed style value for |font-weight| is "401" or "399", which are invalid
values (cf. CSS spec section 15.2.3). Only multiples of 100 between 100 and 900
are valid.

See test case attached (click on the link).

I verified that getComputedStyle().getPropertyValue() only retrieves the weight
value that is internally stored. In my opinion, it is *not* DOM's job to modify
this value because the internal equivalent for normal is 400.

Please note that fixing this bug is *very important* for the CSSization of Composer.
Attached file test case showing bug
Blocks: 77705
Keywords: correctness, css2, dom2
Well. This actually probably cannot be fixed without WG involvement...

Internally we have to keep track of two numbers:

   the original value set by the author (a number from 100-900)
   the net number of times 'lighter' and 'bolder' were called

This is because while '100' and '400' might look the same, '100' followed by
'lighter' MUST be different if the font has different weights at all.

As I understand it, the way the code works now is to round to take the 100 
nearest to the current font-weight, and then step up (or step down) the weight 
by the distance that the weight is from the 100.

For example, if an element is 'lighter' than 'lighter' than '500', then we take
the font weight for '500', then go down by two physical weights (which could be 
anything, e.g. the weight that '200' would get).

Now the question is, *what is the computed value of font-weight*?

"Clearly" it is the weight that, if given explicitly, would give the same 
resulting weight as the weight that is picked based on the number of 'lighter'
or 'bolder' calls are made. Unfortunately this means that font-weight: lighter
on an element whose parent has 'font-weight: 200' could end up being '500' and
not '100'.

Why do you need this in the editor? I think if you are using this feature in the
editor then you will be having data loss -- if you ever see a non-round-number
then that means your user has used 'lighter' and 'bolder' instead of relying on
specific font weights: if you change that to '400' or '900' then you will be
causing data loss, just as if you changed percentage or 'em' widths into pixels.

I suggest you bring this up with the CSS working group. David will surely be
happy for seeing yet another lack of definition of computed values...
Assignee: karnaze → nisheeth
Component: Layout → DOM Style
QA Contact: petersen → ian
Whiteboard: WG
Reassigning to harishd, and futuring. When you get something concrete on how
this should be implemented, clear the milestone.
Assignee: nisheeth → harishd
Target Milestone: --- → Future
Depends on: 93725
Summary: Incorrect font-weight value if |font-weight:bolder| or |font-weight:lighter| → getComputedStyle returns incorrect font-weight value if |font-weight:bolder| or |font-weight:lighter|
->bzbarsky, getComputedStyle() bug
Assignee: harishd → bzbarsky
Keywords: testcase
Priority: -- → P5
Blocks: 173331
Blocks: 42417
# CSS 2.1 does not specify how the computed value of font-weight is represented 
No plans to work on this any time in the foreseeable future, so to default owner.
Assignee: bz-vacation → general
Priority: P5 → --
Target Milestone: Future → ---
I had a look at the relevant part of CSS2.1 while trying to fix bug 93275.

That spec *seems* to be saying that really, only numeric values that are a multiple of 100 are valid computed values for font-weight; there is some additional verbiage about "one of the legal[sic] number values combined with one or more of the relative values", but given the rules in the preceding paragraph about the actual meaning of the relative values, I don't see how the "combined with" situation would ever happen.  Thus, my patch for 93275 tries *only* the multiple-of-100 numeric values for weight, contra the previous code that could use intermediate numbers.

On the one hand, this means that checking in that patch would fix this bug.  On the other hand, the discussion in this bug seems to imply that bolder/lighter are supposed to be able to make intermediate distinctions.  On the left foot, I see no support for that possibility in the text of CSS2.1 - perhaps it was true in CSS1 but has been changed?  And on the right foot, perhaps you are meant to be able to get to "Ice Prawn ExtraBlack" (in the second example in CSS2.1 s15.6) with font-weight:900 + font-weight:bolder - so the code should be trying 001-099 and 901-999 as well as multiples of 100, and those values should be special cased in GetComputedStyle?  I am meh on this last possibility; it seems to me that saner behavior would be to assign "Ice Prawn ExtraBlack" to font-weight:900 and shove all the others down one.

What would Gecko actually *do* with a font with six weights named as in the "Ice Prawn" example?
I meant to refer to bug 93725 in my previous comment.
(In reply to comment #7)

I think there's a bit of a spec problem here.  The evaluation of bolder/lighter depends on the font family used and there can actually be multiple fonts used within a given span of text depending upon the contents of that span.  So the meaning of bolder/lighter will be different for separate subspans of text runs, you will have different weight calculations used.

The question with regards to the spec that needs to be answered is "What is the form of a computed value for font-weight when bolder or lighter is used?"
Assignee: general → nobody
QA Contact: ian → general
Partly fixed by in the sense that getComputedStyle no longer returns invalid values; it returns just 'bolder' or 'lighter'.  Those still don't represent the real computed value, though.
QA Contact: general → style-system
Fixed by changes in bug 93725 (since 'bolder' and 'lighter' are now computed in the style system).
Assignee: nobody → dbaron
Closed: 11 years ago
Priority: -- → P4
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
You need to log in before you can comment on or make changes to this bug.