Description
The spec for initial-letter says that it computes to
the keyword normal or a number paired with an integer
(so if the drop or raise keyword is specified, this will compute to the appropriate integer, either floor(size) or 1). So far, so good: we won't see those keywords in the computed value.
The spec also says that the drop keyword
Computes to an initial letter sink equal to the initial letter size floored to the nearest positive whole number
and that
If the initial letter sink value is omitted, drop is assumed
The shortest-serialization principle then implies that if the computed sink value (whether specified as a number or as the drop keyword) equals floor(size), we should omit the second value from the serialization altogether.
There are currently WPT tests that do not match this expectation:
https://wpt.live/css/css-inline/initial-letter/initial-letter-valid.html asserts that drop 1.23 and 1.23 drop both serialize as 1.23 drop, but according to the shortest-serialization principle, the drop keyword can (and therefore should) be omitted.
https://wpt.live/css/css-inline/initial-letter/initial-letter-computed.html asserts that drop 1.23 and 1.23 drop both compute to 1.23 drop, which is wrong in two respects: drop should compute to an integer, and it should then be omitted from the serialization.
It also asserts that 1.23 raise and raise 1.23 both compute to 1.23 raise. But according to the spec, the raise keyword should have computed to 1. And given a size of 1.23, the sink value of 1 is also what drop would compute to, and therefore can be omitted. To check the computed value where raise was specified, it would be better to use a larger size such as 3.14 instead of 1.23, so that raise and drop will compute to different integers.