This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Most methods in CSSMatrix don't raise exceptions on passing null or NaN values. For instance what happens with multiply if null gets passed? What happens if one of the attributes get set with NaN? What happens on translate, scale, rotate on passing NaN? What will be the resulting Matrix? What happens if multiply gets a CSSMatrix but some of its attributes are NaN? We should raise errors for all of these cases.
These are all handled by WebIDL. E.g., the declaration "CSSMatrix multiply(in CSSMatrix secondMatrix);" means that if anything other than a CSSMatrix is passed to multiply(), an exception will be thrown. This is the algorithm implementations must use for executing operations: http://dev.w3.org/2006/webapi/WebIDL/#es-operations It includes the step "Let values be the result of passing entry and arg0..n−1 to the argument resolution algorithm." That says: """ Initialize values0..m−1 to be a list of IDL values, where valuesi is the result of converting argi to an IDL value of type ti. These conversions must be done in order from arg0 to argm−1. """ http://dev.w3.org/2006/webapi/WebIDL/#dfn-argument-resolution-algorithm CSSMatrix is an interface type, and to convert to an interface type UAs must follow this algorithm: http://dev.w3.org/2006/webapi/WebIDL/#es-interface . . . which will throw a TypeError. So more specifically: (In reply to comment #0) > For instance what happens with multiply if null gets passed? Throws a TypeError, per above. > What happens if one of the attributes get set with NaN? Then it gets set as NaN. WebIDL allows any values for float/double that IEEE 754 does, same as ECMAScript. This is probably not desired, but it's a WebIDL bug, not a CSS bug. I filed bug 16075 against WebIDL. > What happens on translate, scale, rotate on passing NaN? What will be the > resulting Matrix? > What happens if multiply gets a CSSMatrix but some of its attributes are NaN? In theory, you should follow IEEE 754 rules for multiplication here. This will probably result in a bunch more matrix entries getting set to NaN or infinite values. This isn't wanted, obviously, which is why WebIDL should specify throwing a TypeError here.
(In reply to comment #1) > These are all handled by WebIDL. E.g., the declaration "CSSMatrix > multiply(in CSSMatrix secondMatrix);" means that if anything other than a > CSSMatrix is passed to multiply(), an exception will be thrown. This is the > algorithm implementations must use for executing operations: > > http://dev.w3.org/2006/webapi/WebIDL/#es-operations > > It includes the step "Let values be the result of passing entry and arg0..n−1 > to the argument resolution algorithm." That says: > > """ > Initialize values0..m−1 to be a list of IDL values, where valuesi is the result > of converting argi to an IDL value of type ti. These conversions must be done > in order from arg0 to argm−1. > """ > http://dev.w3.org/2006/webapi/WebIDL/#dfn-argument-resolution-algorithm > > CSSMatrix is an interface type, and to convert to an interface type UAs must > follow this algorithm: > > http://dev.w3.org/2006/webapi/WebIDL/#es-interface > > . . . which will throw a TypeError. > > So more specifically: > > (In reply to comment #0) > > For instance what happens with multiply if null gets passed? > > Throws a TypeError, per above. > > > What happens if one of the attributes get set with NaN? > > Then it gets set as NaN. WebIDL allows any values for float/double that IEEE > 754 does, same as ECMAScript. This is probably not desired, but it's a WebIDL > bug, not a CSS bug. I filed bug 16075 against WebIDL. > > > What happens on translate, scale, rotate on passing NaN? What will be the > > resulting Matrix? > > What happens if multiply gets a CSSMatrix but some of its attributes are NaN? > > In theory, you should follow IEEE 754 rules for multiplication here. This will > probably result in a bunch more matrix entries getting set to NaN or infinite > values. This isn't wanted, obviously, which is why WebIDL should specify > throwing a TypeError here. I agree. We should come to this topic later again. At the moment we delay it to CSS4 Transforms.