WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
Bug 55202
Add missing length units to CSS unit category function
https://bugs.webkit.org/show_bug.cgi?id=55202
Summary
Add missing length units to CSS unit category function
Mike Lawther
Reported
2011-02-24 21:17:10 PST
Add missing length units to CSS unit category function
Attachments
Patch
(1.72 KB, patch)
2011-02-24 21:19 PST
,
Mike Lawther
ojan
: review-
ojan
: commit-queue-
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Mike Lawther
Comment 1
2011-02-24 21:19:54 PST
Created
attachment 83768
[details]
Patch
Andreas Kling
Comment 2
2011-02-25 02:31:52 PST
Comment on
attachment 83768
[details]
Patch How do we test this?
Mike Lawther
Comment 3
2011-02-25 16:06:37 PST
Normally I'd say a unit test :) After a chat on IRC with jamesr, I now think that the units are deliberately not there. The output of this function is used to determine whether units are convertible, eg picas->px (ie ULength->ULength) is OK, but khz->px (UFrequency->ULength) is not. Looking at the asserts in on line 559 and 563 of CSSPrimitiveValue.cpp, it's currently illegal to call unitCategory() with (em|ex|rem). I reckon this is because there is no simple conversion for them, since (ex|em|rem) depends on font metrics? I had thought that unitCategory() was a generic function, similar to isUnitTypeLength(), but it appears to have the more specific purpose of identifying categories where the units can be converted to a canonical type (eg px for ULength). If this is the case, then I reckon that CSS_EMS, CSS_EXS and CSS_REMS should be added to the default case of the switch so they explicitly return UOther, to make it clearer that this is intended, and not a simple omission. Thoughts?
Ojan Vafai
Comment 4
2011-02-27 20:09:59 PST
(In reply to
comment #3
)
> If this is the case, then I reckon that CSS_EMS, CSS_EXS and CSS_REMS should be added to the default case of the switch so they explicitly return UOther, to make it clearer that this is intended, and not a simple omission.
I'd rather see asserts at the top of unitCategory explicitly checking for these types. For now, I'll r- this patch since it seems the existing code is correct, albeit confusing. (right?)
Ojan Vafai
Comment 5
2011-02-27 20:10:33 PST
Comment on
attachment 83768
[details]
Patch r- per Mike's comment above.
Mike Lawther
Comment 6
2011-02-27 20:24:53 PST
Yes - my newfound understanding of the current code is that it is correct, but confusing. (aside: I don't think you want an assert, since it is legal to call unitCategory with these types, and the intent is that they come back UOther).
Ojan Vafai
Comment 7
2011-02-28 21:51:50 PST
(In reply to
comment #6
)
> Yes - my newfound understanding of the current code is that it is correct, but confusing. > > (aside: I don't think you want an assert, since it is legal to call unitCategory with these types, and the intent is that they come back UOther).
It's not really legal though since the only two callers of this function assert that it returns something other than a UOther. So to me it's not unlike doing the following (which is in many places in WebKit): ASSERT(foo); // foo shouldn't be null here, but early-return to make sure we don't crash if it is. if (!foo) return; I guess I find it weird to have a default case for the switch but then have a number of cases that do the same thing. Why have a default at all?
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug