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.

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...

Reassigning to harishd, and futuring. When you get something concrete on how this should be implemented, clear the milestone.

->bzbarsky, getComputedStyle() bug

FWIW: # 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.

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?"

Partly fixed by http://hg.mozilla.org/mozilla-central/rev/2dd63d12d6bc 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.

Fixed by changes in bug 93725 (since 'bolder' and 'lighter' are now computed in the style system).